The human layer, part 3: The four modes of AI coding (and why you can only be in one)

There used to be one way to write software properly. Now there are four, and most of the stress, and a lot of the bad code, comes from not being deliberate about which mode you are in.

Before I start any piece of work now, I decide which of four modes I am in. It is the single most useful habit I have picked up since AI tools took over the typing, and the one that has done most to stop my working day being stressful.

The idea is simple. There are four kinds of software you can build with these tools, and each one needs a different mindset. Readers of Kahneman will recognise the trick: System 1 and System 2 each have a job, and the trouble starts when you use one for the other's work.

Mode 1: playtime

Code that may not survive the session. You are exploring a new tool, trying a new way of working, or checking whether something is even possible. It is the equivalent of a scratch spreadsheet you knock up to do a quick sum and never save.

The mindset is play. No review, no tests, no thought about structure. If it does something interesting, good. If it falls over, also fine. I think this mode matters more than people give it credit for. It is how you find out what the tools can actually do, and engineers who skip it end up with second-hand opinions about the technology.

I probably have at least 30 minutes of this every day, as part of the time I spend learning.

Mode 2: the prototype

This is what most people mean by vibe coding, and it is what Andrej Karpathy meant when he coined the term in February 2025: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." That is exactly right for modes 1 and 2, and nowhere else. You are solving a real problem with something that you and a couple of colleagues will use. It has bugs. You don't care. You will vibe-code the small fixes, and anything bigger you will throw away and rebuild from scratch, because rebuilding is cheaper than reworking.

That last part is the mindset. Build it light on purpose, on the assumption that using it will teach you something that changes the design. It usually does. In old money, this is a working prototype, and the discipline is to treat it as one: learn from it, then let it go.

Seasoned engineers will recognise this mode. The the reason it's disposable, is that in the production of the prototype, you learned something about the problem that made you realise the whole approach was wrong. Trying to bend it into the right shape ends up being too messy, and so you'll discard the v1 and rebuild v2 based on what you learned.

It's the example of "stop over thinking it and just try building a prototype" - this is now more true than it ever was, because prototyping is so fast.

Mode 3: scaffolding

Tools that live inside your business but are not the thing your customers buy. Automation, document formatting, repeatable admin, the glue between systems. Tool-making, in other words.

The quality test here is simple: does it produce a useful output? A document formatter either formats the document or it doesn't, and once it has run, it never touches the document again. A bug is self-evident and contained. That is very different from a product bug, which can sit in the wild and wreak havoc for months before anyone notices.

Scaffolding is heavier than a prototype, though, and the mindset shifts with it. These tools start to encode how your business actually works, so you keep them, add to them, and take a bit more care over how they are put together. Not production care. Enough that you would rather maintain and extend them than rebuild them. But if they break, nobody dies.

Mode 4: the product

This is the software your customers use. For a SaaS company, that is the thing you ship. It could equally be the firmware inside a physical product, your customer smartphone app or the trading platform your whole client base sits on. It handles customer data, it gets fuzzed at scale by real users, bugs surface fast and can cost real money, and it is being built for a five to twenty year life.

The mindset here is old-school development plus a power tool. We review almost all of the code by hand. We design deliberately. We test properly. The AI is still doing a lot: on the actual coding it makes us two or three times faster, and on everything around the code (documentation, test scaffolding, framework boilerplate, the stuff that used to eat whole afternoons) it is much more than that. The net effect across a day is five to ten times, but the coding itself is a steady two to three, and that is the right number. Anyone claiming to vibe-code a production system in an afternoon is in mode 2 and has not noticed.

Why you can only be in one

The modes are useful individually. The real value is in selecting your mode consciously, and there are two reasons.

The first is personal. If you have not decided which mode you are in, you spend the whole task second-guessing yourself. Should I be reviewing this? Is this good enough? Am I being lazy, or being sensible? Should I have written tests? That questioning never resolves, because the answer depends on the mode and you didn't make a deliberate choice. I have had days like that and they are miserable. Pick the mode and the questions answer themselves.

The second is organisational, and it is already happening. Companies are shipping code that should have been mode 4 but was built in mode 2 or 3, with obvious consequences. The result is visible in the products: bugs that should have been caught, instability, poor performance, designs that were never really designed. Users are noticing. In Stack Overflow's 2025 developer survey, 84% of developers were using AI tools, 46% distrusted the accuracy of what they produced (up from 31% the year before), and two-thirds named "almost right, but not quite" as their biggest frustration. Those numbers are ageing fast, as everything in this field does, but the direction is the point: more use, less trust. A lot of organisations are going to learn the hard way that mode 4 needs mode 4 discipline, however fast the tools are.

None of that is an argument against modes 1 to 3. Most of the software a business builds belongs there, and being good at scaffolding in particular is a real competitive advantage. It is an argument for being deliberate. I now pause to think about what mode I'm in, before I touch the keyboard. It takes two seconds and it changes everything that follows.