We look past it, the way we look past a house number we already know. It sits quietly in the corner of a browser tab, sixteen pixels or so, reminding us which tiny piece of the internet we are visiting.

The favicon appeared in the late 1990s as a “favorite icon” for bookmarked websites. Even its name belongs to an older web.

Since then, almost everything around it has changed.

Pages became applications. Desktops gave way to phones. Tables became divs, Flash disappeared, servers floated into clouds, and browsers grew so many tabs that we can barely read their titles anymore.

Through all of it, the favicon stayed.

Its file format changed. It grew larger versions, sharper versions, touch icons, and manifests. But its purpose remained almost untouched: a small mark that says, this page belongs to this place.

The web is a city that rebuilds itself overnight. Buildings rise, fashions spread, neighborhoods disappear, and yesterday’s landmarks become broken links. Yet the favicon is still there, a tiny house number nailed beside the door.

Nobody celebrates it. Nobody announces the next generation of favicon. We only notice when one is missing and a browser shows us that empty, generic square.

Maybe that is why it survived. It never tried to become more than it was.

The web rushed toward whatever came next.

The favicon stayed in the corner, keeping our place.

AI can write simple code, people said, but when the system becomes complicated, you still need an experienced human.

This is a reasonable objection.

It also feels true today.

Ask a model to build a small application and it moves quickly. Ask it to change billing rules across a ten-year-old system and it may wander into the woods. A human has to pull it back.

The mistake is treating that boundary as permanent.

The models that struggled with a complete feature last year can now explore a codebase, change several files, run tests, notice failures, and try again. They still get lost, but the forest keeps getting larger.

The replies focused on where the boundary is today. I was more interested in where it is moving.

A complicated system is not complicated in one giant way. It is usually a pile of smaller decisions held together by constraints.

The payment must be retried, but never twice at the same time. Old customers keep their original price. The migration must work without downtime. Failed jobs must be safe to run again. This strange database column cannot be removed because a forgotten report still uses it.

An experienced programmer carries much of this context in their head.

The model does not.

Give it a vague request and it fills the gaps with guesses. Give it the intended behaviour, the constraints, the edge cases, the relevant code, and a way to test the result, and something different happens.

It breaks the work down. It proposes a plan. It changes the code, runs the tests, reads the failures, and adjusts.

It will still make mistakes. Sometimes serious ones. I am not claiming that AI can already redesign every complicated system perfectly.

I am saying that it is moving into complicated work faster than many programmers are updating their idea of what complicated means.

That shifts the bottleneck.

The difficult part becomes less about whether the machine can produce the code. It becomes whether the human can explain what correct means.

That is not a small task.

Writing a good specification requires understanding the system, finding the hidden constraints, resolving contradictions, and choosing trade-offs. Then someone still has to review the result and take responsibility for it.

The human remains, but the work changes.

More of it becomes specification, judgment, verification, and ownership.

If you cannot describe the constraints, the model will invent them for you. If you can, you still have to check the result and put your name on it.

That is the part experienced programmers should be practising now.

LLMs can produce code, they said, but they cannot compress judgment. You only get that by spending years debugging systems, making mistakes, and suffering with the compiler.

I think they are right about the first part.

I am less sure about the second.

We don’t know yet

The technology is too new.

Nobody has spent ten years learning programming with a capable coding agent because capable coding agents haven’t existed for ten years. We cannot examine the careers of people who learned entirely this way. Those careers have barely started.

Maybe some beginners have already compressed five years of learning into two. Maybe they only look competent because the machine is doing the work. A working application doesn’t tell us which one happened.

One small study of novice programmers found exactly this split. Almost everyone completed the task, but some students used AI to move faster while others became even more confused.

It is interesting, but it doesn’t answer the bigger question. Only time will.

Two kinds of beginner

The first beginner asks the LLM to build an application.

It works. They ask for another feature. That works too. When something breaks, they paste the error back into the chat and apply the next patch.

After six months, they may have shipped a surprising amount of software. They may also understand very little of it.

I know how addictive this is because I tried vibe-coding an entire game. The incentive to stop and read the code is almost nonexistent when the next prompt can keep you moving.

The second beginner does not start by reviewing architecture and rejecting bad abstractions. They cannot. They are still a beginner.

They start smaller.

They ask what each file does. They try to predict what the code will do before running it. They ask for a hint before asking for the patch. After the LLM fixes a bug, they revert the fix and try to reproduce it themselves.

They break their small application on purpose. They change the input, delete a record, add latency, or make an API return nonsense. Then they watch what happens.

At first, they will ask bad questions and misunderstand the answers. That is normal. The important part is that they stay with the problem after the code starts working.

Eventually, they can read the generated architecture. Eventually, they can compare two approaches and notice that one of them is a mess. Eventually, they can refuse the first working answer.

Those are not skills the beginner starts with. They are what this process is supposed to produce.

Friction still matters

I previously wrote that beginners should learn to code, ignore AI, then use AI to code even better.

I am no longer sure about the “ignore AI” part.

A beginner may be able to use AI from the first day and still learn properly. They just cannot let it remove every obstacle.

The LLM can finish the exercise, or it can help you understand the exercise. Those uses look similar from the outside because both may produce working code.

Only one of them requires much thinking.

The old route included friction automatically. The compiler refused to cooperate. Documentation was unclear. Answers were difficult to find. You had no choice but to sit with the problem.

Now the easy answer is always one prompt away.

That means the beginner has to choose the hard part deliberately.

Build something small enough to understand. Read what the model writes. Ask for explanations, not only fixes. Work without it occasionally. Break things in a safe environment. Put something real online and take responsibility when it fails.

Experienced programmers should not pretend that our old learning route is the only route that can produce judgment. Beginners should not pretend that shipping AI-generated software means they have already developed it.

If I were learning today, I would use AI from the beginning. But if the code worked and I couldn’t explain why, I would not consider the lesson finished.

Yet in 2026, it feels like I no longer have much of an advantage over someone who only learned React.

I posted this on X and asked a simple question: if AI has compressed years of accumulated knowledge into something anyone can access, what should experienced programmers focus on now? What becomes the new moat?

Some people read it as a confession rather than a question.

One person, who has been programming since the 1970s, replied: “Wow, what an admission.”

Another said that perhaps I had been a competent code-slinger but had never learned the important architecture and engineering skills.

The implication was that if AI makes you question the value of your experience, the only possible explanation is that you never had any. That may be a comforting answer, but I don’t think it is the correct one.

Experience still matters

I have written before that AI amplifies programmers rather than replacing them. I still believe that.

Give an incompetent programmer a powerful model and they may produce middling crap. Give a competent programmer the same model and they can produce excellent work faster than ever. One of the replies made exactly this point, and I agree with it.

Experience helps you notice when generated code is subtly wrong. It helps you ask better questions, reject bad abstractions, understand trade-offs, and know when the green tests are lying to you. A beginner sees working code. An experienced programmer sees the maintenance bill hiding behind it.

That is true, but it still wasn’t the point I was making.

My point is that the distance between incompetence and competence has become much shorter.

AI does not need to make a beginner equal to an expert to change the economics of programming. It only needs to help the beginner catch up faster than before, which is already happening.

The ladder got shorter

When I started programming, knowledge was expensive.

You had to read the book, learn the vocabulary, fight with the compiler, search through forum posts, misunderstand the documentation, break the program, and then spend hours figuring out why. A lot of what we call experience is simply the scar tissue left by repeating this process for years.

Today, a beginner can paste an error into an LLM and get an explanation in seconds. They can ask for three possible solutions, request a comparison, and then ask the model to implement the best one. They still need enough knowledge to judge the result, but the amount they must learn before becoming productive has collapsed.

The expert still starts further ahead, but the beginner no longer has to walk the whole road to get somewhere useful.

That is what I mean by compression. AI has not deleted the difference between a junior and a senior programmer. It has compressed it.

The manual is no longer the bottleneck

The most interesting reply came from the programmer who disagreed with me. He said LLMs are already excellent at systems programming. He routinely gets complicated compiler tooling from them in one shot, and has had them nearly produce hardware simulators from a manual in one shot too.

To me, however, this is evidence for my argument rather than against it.

The machine consumed the manual and produced the result. Now imagine that you need to learn ten manuals. Would you spend months absorbing all of them before starting, or would you use the machine sitting next to you? I know which option I would choose.

He later compared programming by hand to learning arithmetic before using a calculator, solving integrals before using Mathematica, and operating manual machine tools before using CNC. I agree with that too. Learning the fundamentals gives you a mental model that the tool cannot install with a single prompt.

Children should still learn arithmetic, of course, but doing long multiplication by hand is no longer a moat.

Knowing assembly language can make you a better programmer, but it does not mean you should manually translate every program into machine code. The compiler moved that work into a tool, and AI is doing something similar one level higher.

The knowledge still matters, but the market stops rewarding you merely for having acquired it the hard way.

Programming is becoming a commodity

This is the uncomfortable part of the discussion, because programming has been such an important part of how many of us see ourselves.

Typing the same ten things by hand feels mundane when you know a machine can do them faster. You already proved to yourself that you can write the code. Doing it again is like reaching for a regular screwdriver when an electric one is sitting next to it.

You can admire the craftsmanship of the regular screwdriver. You can practice with it to keep your hands sharp. But don’t confuse that practice with a competitive advantage.

AI has made code cheaper because, as the models improve and absorb more public code, documentation, books, and examples, more programming knowledge becomes available on demand. As a result, the bottleneck moves away from remembering how to produce the code.

Whether LLMs “truly think” is an interesting philosophical argument, but it doesn’t change the practical result. If a machine can produce the compiler tooling, debug the system, and ship the feature, the market will care about the result more than the internal mechanism that produced it.

We will probably live through a turbulent period with mountains of bad AI-generated software. Vibe coders will ship security holes, broken abstractions, and dependency piles that nobody understands. The market will slowly correct for it, though, because users still expect software to work.

Bad output from beginners does not preserve the old moat, though. It simply shows that better tools have not eliminated the need for judgment.

So what is the new moat?

I don’t think the new moat will be syntax, framework trivia, or remembering an API that the model can look up in a second. It will be everything around the code: knowing which problem is worth solving, understanding the users and the domain, and turning messy requirements into precise decisions.

It will also involve having enough taste to prefer a simple system over an impressive mess, recognizing when the AI is confidently wrong, and being willing to own the result after the prompt is finished.

Most of this was always part of good software engineering. The difference is that it is becoming the job, rather than the layer of thinking around the job.

Experienced programmers should use AI aggressively. We should also keep our fundamentals sharp, because without them we cannot judge what the machine gives us. But we should stop treating the difficulty of our education as permanent protection from newcomers, because it no longer provides that kind of protection.

AI did not make my 15 years of experience worthless, but it did make a large part of that experience easier for other people to borrow.

That experience still gives me an advantage, but it no longer feels like the protective moat it once was. As code becomes cheaper to produce, the judgment behind it becomes more important, and that is where I think experienced programmers should focus.

The idea is almost embarrassingly simple: you click your country flag, your flag climbs up the pole, and you try to overtake everyone else. That’s the whole game.

I keep getting drawn to these tiny internet toys. Not the serious kind of game where you need a tutorial, a season pass, and three currencies before you are allowed to have fun. I mean the stupid little thing that makes sense immediately. You open it, you understand it, and before your brain has time to ask why, you are already clicking.

Flag Click grew out of Flag Match, my flag matching game. Flag Match at least has the noble excuse of being educational. You can tell yourself you are learning geography. Flag Click does not have that excuse. It is the less responsible cousin. You click a flag because you want your flag to be higher than the other flags.

That sounds silly, but that is exactly why flags work so well here. A flag is not just a random image on a button. People instantly recognize it. It carries just enough identity to make the number feel personal, but not enough gravity to turn the thing into something serious. It stays in that nice internet zone where everyone knows it does not matter, but it still kind of does.

The first version was not a flagpole. It was a big field of flags where the winning countries slowly took over the screen. In my head, this was clearly the right mechanic. On the screen, it was ugly. Flags got squished, the layout looked noisy, and the whole thing had no drama. It was technically doing what I asked it to do, which is often the worst kind of failure because the idea itself is the problem.

The flagpole fixed it.

Once countries started climbing instead of occupying space, the game suddenly made sense. The screen had a direction. Being #1 meant being at the top. Smaller countries could sit lower on the pole. On mobile, it also felt much more natural because the entire game became vertical, which is where your thumb already lives.

Most of the work after that was not about adding more features. It was about making the click feel right. The flag had to wave. The score had to react quickly. Overtaking another country needed a little bit of theatre. The sound could not be annoying after five seconds. Mobile tapping had to feel good because this is absolutely a phone game first.

That kind of polish sounds optional until you build something this small. Then you realize the polish is the product. If the button feels bad, there is no game left to hide behind.

I also had to think about fake scores, because of course I did. Any public clicker invites people to mess with it. That is part of the genre. I do not think you can make this kind of thing perfectly cheat-proof, and I do not want to turn a silly flag game into airport security. The goal is simpler: make casual cheating boring enough that normal players do not feel like the board is immediately ruined.

I have no idea if Flag Click will go anywhere. Maybe it gets shared, maybe it doesn’t. Maybe one country wakes up and turns the leaderboard into a national emergency for twelve minutes. Maybe nobody cares. All outcomes are acceptable.

What I like is that it exists. It is small, weird, and self-contained. It made me care about sounds, animation, phone taps, flags, and one very opinionated pole. That is enough for me.

Go click your flag: flagclick.com.

The convenience is ridiculous.

You describe what you want, and it produces working code. You paste a stack trace, and it explains the bug and offers a fix. You ask it to add a feature, and it updates the relevant files, writes tests, and sometimes even suggests the migration. What used to take an hour of focused work can now take ten minutes of prompting and reviewing.

This speed is genuinely useful. I am not going to pretend otherwise. But it also makes it dangerously easy to stop doing the real work yourself.

The muscle that actually makes you a programmer is not typing code. It is the ability to hold a mental model of a system, reason about trade-offs, spot the smell in an abstraction before it spreads, and debug by thinking instead of throwing prompts at the wall.

That muscle needs exercise.

With AI, many problems get solved before you ever have to think hard about them. The friction disappears, and with it goes some of the growth. You still ship the change, but you may not have learned much. You still get the green tests, but you may not understand why the solution is shaped the way it is.

At the same time, the power on the other side is absurd. These tools are no longer just autocomplete. They can act as agents: explore a codebase, make coordinated changes across files, run commands, observe results, and iterate. It is like having a tireless pair of hands that can execute at a speed no human can match.

The leverage is real. Used well, it lets a single developer ship things that previously required a small team.

The problem is the gap between those two realities. The tools reward you for staying in the loop of prompting and accepting. They do not punish you for slowly losing the ability to work without them. You can produce more output while your underlying capability quietly erodes. You become very good at directing an artificial programmer instead of remaining a real one yourself.

I have written before that AI amplifies programmers rather than replacing them. I still believe that. But amplification only works if there is still something strong on the receiving end. If the human side atrophies, you do not get 10× output. You get 10× of whatever shallow thinking you brought to the prompt.

I also still believe that you should learn to code, ignore AI, then use AI to code even better. Maybe even more now.

The practical question is not whether to use these tools. You would be foolish not to. The question is whether you are still doing enough deliberate, unaided work to keep your own reasoning sharp.

Sometimes that means closing the AI tab and wrestling with the problem the old way first. Sometimes it means using the model only after you have already formed your own approach. Sometimes it means reading the generated code line by line instead of accepting the diff because the tests passed.

The tools are too good to ignore, but they are also too good at letting you coast.

The programmers who will matter in the next few years are not the ones who prompt the best. They are the ones who stay sharp enough to know what to prompt for, when to use the output, and when the output is wrong.

Everything else is just faster typing.

Somewhere along the way, software customization became a hobby of its own. This reflects the same pattern behind why developers love complexity.

But the longer I write software, the more I appreciate defaults.

The default path is where every user begins. It is the most exercised, most documented, and most battle-tested part of the product. Thousands or millions of people have already walked that road before you. Bugs are discovered there first. Edge cases are encountered there first. Performance issues become visible there first. When something breaks, the maintainers notice because everyone is using it.

Defaults are not arbitrary. They are usually the result of years of accumulated experience and hard-won trade-offs between performance, maintainability, usability, and predictability. When Rails ships with a certain project structure, or SQLite enables certain behaviors by default, or a browser decides how something should work out of the box, there is often more practical reasoning behind those choices than most developers assume.

The customized path, by contrast, is lonely.

The more you diverge from the defaults, the more you become responsible for your own ecosystem. Documentation becomes less relevant because your environment no longer matches what everyone else is using. Tutorials stop applying cleanly. Upgrades become riskier. You start carrying a collection of tweaks whose original purpose you no longer remember.

I know this because I used to do exactly that. I spent countless hours configuring editors, terminals, Linux desktops, tiling window managers, browser setups, and JavaScript toolchains in pursuit of some ideal workflow that never actually arrived. At some point, the setup itself quietly became the project. I was investing more energy into perfecting the environment than using it to build things.

Meanwhile, the person using the defaults quietly ships their work.

This is not an argument against customization entirely. Sometimes defaults genuinely do not fit your needs. Some workloads require tuning. Some preferences matter. But customization should come from real friction encountered over time, not from the assumption that the default experience must be inferior simply because it is common.

There is also a psychological trap here. Developers often associate customization with expertise. Using the default setup can feel unsophisticated, as if you are leaving performance or productivity on the table. But many experienced engineers eventually arrive at the opposite conclusion: simplicity has value, and every deviation from the standard path carries a maintenance cost.

A good default reduces cognitive load. It lets you focus on the actual work instead of endlessly shaping the environment around the work.

This becomes more obvious as software matures. Modern tools are significantly better than they used to be. Browsers work well without extensions. Rails defaults are remarkably solid. SQLite handles workloads that people once considered impossible for it. Even operating systems have become harder to misconfigure catastrophically.

The industry has slowly learned that good defaults are a feature.

In many cases, the default path is not merely the easiest option. It is the option refined through the largest amount of real-world usage. That matters. Software behaves differently under millions of users than it does in theory.

So these days, I try to resist the instinct to immediately optimize and customize everything. I start with the defaults and stay there until something repeatedly becomes a real problem. Most of the time, that moment never comes.

And when it does, I at least understand exactly why I am changing something.

The screen is black. The cursor blinks — steady and patient. You lean in and begin to type, your fingers moving with intention across the keys. A few simple words appear: ls, cd, mkdir, grep.

Then comes the moment of anticipation — that brief pause before you press Enter.

And when you do, the terminal answers.

Results appear line by line, precise and immediate. There is something deeply satisfying about the exchange: you speak in commands, and the machine responds with clarity.

This is the beauty of the terminal: its power lies in simplicity. A few letters typed on a black screen can search vast amounts of data, launch processes, and reshape entire systems.

Here, you are not a passive user. You are the one who speaks — and the machine listens. Every time you type a command in the terminal, you feel it: the ancient, elegant magic of turning thought into action with nothing but words.

It will confidently help you build a ladder… even if it’s leaning against the wrong wall.

The problem

AI keeps moving forward, even when the direction is off. It supports your line of thinking, refines it, and adds detail, but rarely stops to say:

“Now that the requirements are clearer, we should reassess.”

Instead, it continues optimizing the current path — whether or not it still makes sense.

Why this happens (factually)

• Objective mismatch: AI is optimized to be helpful and responsive, not to interrupt or challenge direction.
• Weak global reasoning: It doesn’t reliably maintain a high-level model of changing requirements unless prompted.
• User intent bias: It assumes your framing is correct and works within it.
• Reactive nature: It responds to input, but it doesn’t proactively step back or redirect.

The result

If your initial framing is off, the AI will often:

• Refine the wrong solution
• Add convincing detail to a flawed approach
• Stay anchored to outdated assumptions

Even if you ask it to “reassess”, it may still operate within the same flawed frame.

What would be better

A more useful system would:

• Notice when the problem definition has shifted
• Pause and reframe
• Challenge assumptions
• Suggest stepping back before continuing

Practical takeaway

AI is excellent at accelerating execution.

But it won’t reliably tell you if you’re solving the wrong problem. You still have to move the ladder to the right wall.

While building a mostly text-based UI for Telesink, something became obvious: icons make things look polished, but they rarely make things clearer.

We tend to treat icons as essential. In reality, they’re situational.

They help when:

• 👍 Multilingual products: not everyone speaks the same language, icons provide rough affordances
• 👍 Space-constrained UIs: when labels don’t fit (mobile, dense tables)
• 👍 Repeated actions: once learned, icons are faster to scan
• 👍 Visual grouping: they help chunk related actions
• 👍 Status & feedback: success, warning, loading are instantly recognizable

But most of the time, they’re not necessary:

• 👎 They have to be learned (many aren’t universal)
• 👎 They’re ambiguous without labels
• 👎 They slow down new users
• 👎 They add visual noise without adding meaning
• 👎 They increase design and consistency overhead
• 👎 Text is more accessible (screen readers, clarity, localization control)

So for Telesink, I chose a mostly text-only interface. Not as a stylistic choice, but a practical one:

• ✅ clearer actions
• ✅ less guesswork
• ✅ faster onboarding
• ✅ simpler to build and maintain

My rule of thumb

Whenever I’m deciding whether to use an icon or text, I now run it through two simple questions:

• Would a first-time user understand this instantly?
• Does the icon truly add clarity, or is it mostly decoration?

If it doesn’t pass both tests with a clear “yes”, I default to text.

This mental filter has dramatically reduced visual clutter and forced me to focus on actual communication rather than aesthetic habit.

Less decoration, more communication.