· 6 min read ·

What Programming Looks Like When AI Writes the Loop

Source: simonwillison

Simon Willison published “Coding After Coders” in mid-March 2026, and the title alone was enough to restart a debate that has been running quietly since Andrej Karpathy introduced the phrase “vibe coding” in February 2025. Willison’s argument is that we are watching the end of computer programming as a recognizable professional discipline, not its automation-assisted enhancement. That framing is worth taking seriously, even if the conclusion is more complicated than the title implies.

I build Discord bots and do occasional systems work. I have been using AI coding assistants daily for over a year. I hold a particular vantage point on this question, somewhere between the developer who generates entire features from a prompt and the engineer who stares at a segfault wondering why the AI’s suggestion compiles cleanly and still corrupts memory. Both experiences are real, and they point in different directions.

The Abstraction Shifts That Were Supposed to End Programming

The narrative of “programmers made obsolete by abstraction” is not new. COBOL, introduced in 1959, was explicitly sold as a language that business people could write without relying on programmers. Grace Hopper and her collaborators designed it around English-like syntax for exactly that reason. It did not eliminate programmers; it created an entire new class of COBOL programmer that persisted for six decades and still runs significant banking infrastructure today.

The fourth-generation language movement in the 1980s made the same promise. Tools like Informix 4GL and later Lotus Notes macros were supposed to let domain experts build their own software. What happened instead: the tools created a new category of accidental complexity, and someone with deeper programming knowledge ended up maintaining the results. Visual Basic democratized Windows application development in the 1990s, and the outcome was not fewer programmers but more software of highly variable quality, maintained by a larger and more distributed workforce.

Each of these shifts followed a pattern. A new abstraction layer lowered the barrier to producing working software in a specific domain. The people at the old abstraction layer moved up or sideways. The total amount of software in the world grew faster than the workforce shrank. Complexity expanded to fill available capability.

Brooks’ “No Silver Bullet” from 1987 argued that most of the difficulty in software engineering is essential, not accidental. Accidental complexity, the kind that comes from low-level details and verbose syntax, can be abstracted away. Essential complexity, the kind that comes from the problem domain itself, cannot. Better tools reduce accidental complexity and leave you more directly facing the essential kind.

What AI Actually Changes

Large language models are doing something qualitatively different from previous abstraction shifts, and it is worth being precise about why.

Previous abstractions raised the level of the notation. Assembly to C, C to Python, SQL replacing hand-rolled query engines: each step let you express computation in terms closer to the problem domain and further from the machine. But you still had to express computation. You had to think structurally about what the program would do, and translate that into the notation of the abstraction layer.

Karpathy’s vibe coding collapses that requirement. You describe the intended behavior in natural language, accept the AI’s output without deep examination, and iterate on the result by describing desired changes the same way. The skill being exercised is description, not construction. The artifact being produced is a specification, and the AI handles the translation to code.

This is genuinely different from raising the level of notation, because it removes the requirement to think in terms of the notation at all. Whether that is liberating or alarming depends entirely on what you are building.

Where Vibe Coding Works and Where It Fails

For Discord bot work, AI assistance has been transformative in specific ways. The ceremony of setting up an event listener, handling gateway intents, parsing slash command options, formatting embed responses: all of this is pattern-matched boilerplate, and AI handles it well. I can describe what I want a command to do and get a functional first draft in seconds.

But the interesting parts of Discord bot development are not the boilerplate. They are the rate limit budgets and how your command design interacts with them. They are the permission hierarchy and what happens when a user’s server role changes mid-interaction. They are the difference between a deferred reply and an immediate one in a high-latency command, and the subtle ways that getting this wrong silently degrades user experience. These decisions require understanding the system’s behavior model, not its syntax. AI can get them wrong with high confidence, and detecting the error requires knowing what correct looks like.

Systems programming makes the stakes explicit. When I ask an AI to help with concurrent code, the suggestions are frequently plausible, sometimes compile cleanly, and occasionally contain data races that will not surface in testing. The AI does not reason about happens-before relationships or memory ordering semantics in the way that would be required to reliably produce correct concurrent code. It pattern-matches against training data and produces something that looks like the code around it. That is useful for generating starting points. It is dangerous if you treat the output as correct by default.

The failure mode Willison gestures at, and that deserves more direct examination, is that vibe coding selects against the kind of deep understanding that lets you catch these errors. If you never think about memory ordering, you will not notice when the AI gets it wrong.

Specification Becomes the Core Skill

What shifts when AI handles implementation is not that engineering judgment disappears; it is that judgment migrates up the stack.

To get correct code from an AI, you need a precise specification of what correct means. Vague intent produces code that compiles and passes obvious tests but fails at the edges. The more complex the problem, the more your ability to specify it precisely determines the quality of the output. This is not a new insight: formal methods researchers have been making this argument for decades. AI coding tools make it practically important for everyday development.

Debugging AI output also requires more understanding than debugging your own code, not less. When you wrote the code, you know what you intended. When the AI wrote it, you need to reconstruct its intent from the output, compare that to your intent, identify the gap, and then communicate the correction. This is a different skill from writing code, but it is not a simpler one.

Architecture decisions remain almost entirely outside what current AI tools handle well. How a system decomposes into components, where consistency boundaries sit, what failure modes are acceptable and which are not: these are precisely the decisions where specification precision matters most and where the cost of getting it wrong is highest. AI can implement an architecture once specified; it cannot reliably discover the right architecture from an ambiguous description of desired behavior.

What the Title Gets Right

Willison’s framing, that we are watching the end of computer programming as we know it, is accurate about one specific thing. The version of programming where writing code is the primary cognitive activity is changing. The loop, the data structure, the function signature: these are becoming intermediate artifacts rather than the primary output. What persists is the thinking that goes into producing a correct, maintainable, well-specified system.

That is not the end of programming. It is programming shedding a layer of accidental complexity and being left more directly facing the essential kind. The developers who will struggle are those whose value was primarily syntactic fluency. The developers who will do well are those who can specify precisely, reason about system behavior, debug output they did not write, and hold the full invariant set of a complex system in mind while directing an AI through its implementation.

The career ladder changes shape. The tools change. The thinking that separates good software from bad software stays recognizable, even if the artifacts that thinking produces look different from what they did in 2020.

That is not nothing. But it is not the end of coders, either.

Was this interesting?