Code vs No Code

Two camps. Again. Or so they tell you.

Team Code says: you can't engineer around writing code. Plain-language descriptions are wishes. People who claim they "don't write code anymore" are either lying or shipping toys.

Team No Code says: I described what I wanted, an agent built it, I shipped it. The motor act of typing was never the point. Code is the regenerable output, not the artifact.

Before I steelman either side, I want to argue that the debate, as commonly stated, is a fiction. Almost every time you hear "code vs no code," people are arguing about three different things at once and confusing each other on purpose.

This is the fifth post in Don't Pick a Side. Same premise: the loudest debates in AI engineering resolve into context-dependent decisions once you name what's actually being argued. With this one, half the work is just naming it.

When someone says "code vs no code" in 2026, they usually mean one of these three things — but they almost never tell you which:

Debate 1 — Type-code vs Describe-intent. You either type the code yourself, or you describe what you want and let an agent emit it. In both cases, code exists. Somebody typed it; it was just an LLM, not you. This is the debate that actually matters.

Debate 2 — Custom code vs No-code platform. You either own the code, or you build on a platform (Bubble, Make, Zapier, n8n) where code exists but is hidden behind a UI and owned by someone else. This is "build vs buy" with a 2026 paint job. Real debate. Not the same debate as the first one.

Debate 3 — Code-emitted vs No-code-emitted. An end-to-end LLM workflow that produces output without writing code in the middle. Rare in practice. Almost everything labeled "no-code AI" is generated code under the hood.

Once you separate these, the room calms down. The interesting fight — the one that changes how engineers work — is Debate 1.

Three things made this a real engineering choice in 2026.

Intent-described workflows actually work for real things — internal tools, dashboards, integrations, side projects that earn revenue. The barrier to "make a thing that solves the problem" has collapsed.

The maintenance bill is coming due — but not in the way you'd expect. Code you didn't write should be code you eventually read. In practice, almost nobody is doing that at the rate the agents emit. Karpathy's "embrace the exponentials" line is about exactly this: the curves are accelerating, and insisting on linearly-scalable human review is a bet you've already lost. The question stops being "did you read it?" and becomes "what did you decide to verify when you knew you couldn't read it all?"

The hiring market bifurcated. Senior engineers who can specify, supervise, and verify at speed are being hired aggressively. Juniors whose advantage was "I can type a CRUD app in a week" are being squeezed, because now everyone can.

The strongest version isn't "agents are toys." It's something more uncomfortable.

Writing is thinking. You don't know what you want until you've typed it. The motor act of writing the function, choosing the data structure, is what forces the contradictions to surface. Describing in plain language lets you skip the precision and feel like you've designed something, when really you've just emitted ambitions.

Codebases reward the people who shaped them. When you've written the code, you know where it bends, where it's brittle. That knowledge doesn't transfer through code review. It lives in the muscle memory of typing. Engineers who lose this muscle become tourists in their own systems.

Replacing typing with prose lowers the fidelity of the confrontation. Software design is mostly the act of confronting your initial guess with the reality of an implementation. The medium of that confrontation, for thirty years, has been code. Swapping it for English makes you miss things you would have caught typing.

The cleanest version of Team Code: typing isn't a chore engineering grew out of. It's the act in which the engineering happens.

The strongest version isn't "engineers are over." It's more practical.

The code is the regenerable artifact. Code rots; APIs deprecate; models update. The thing that survives is the description of what you wanted. Engineers who treat the code as the asset are about to be heartbroken. Engineers who treat the intent as the asset are about to compound.

Most typing wasn't thinking. Be honest about how much of your typing was ceremony — the fifth React component mostly like the fourth, the CRUD endpoint structurally identical to twenty you've written. Reclaiming that time isn't a loss of craft. It's a recovery of attention for the parts that actually require you.

Reach beats depth in a market that rewards being early. A team that describes-and-ships can attack ten times the problem surface a type-and-write team can. Even if your typed code is slightly better, the un-typed system that shipped two months earlier has already taught the team three things you didn't get to learn.

The cleanest version of Team Describe-Intent: the code was never the deliverable; the working system was. Skipping the typing to get to the system faster is the discipline, not the cheat.

I don't pick a side. I pick the mode per artifact, and I admit a thing the rest of the debate is avoiding.

Type the code when the artifact is durable; when others will read it; when the thinking is unfinished; when the blast radius is high; when you're still learning the domain.

Describe the intent when the artifact is throwaway; when the thinking is already done; when the boilerplate is dominant; when you're the only consumer.

But more important than either: the skill that's actually changing — and that almost no one is naming honestly — is calibrating trust in code you are never going to read.

Team Code pretends the reading is still happening; in practice, at the rate the agents emit, it mostly isn't. Team Describe-Intent pretends the reading doesn't matter; in practice, the systems still ship to production and still break in production. The honest position is between them: I describe, the agent emits, I ship, and I don't read most of it — because at this generation rate I literally can't, and pretending I can is a worse strategy than admitting I can't.

The unit of measurement, for me, is Time-to-Trust — how long it takes before a human stops double-checking the agent on every step. Most "agents in production" right now have an infinite Time-to-Trust: the human never stops checking, which means there is no agent, only a faster interface to the same work. Pushing that number down is the discipline. Not reading more. Reading less, with better infrastructure underneath.

What actually lowers Time-to-Trust is three things you build around the agent, not in the agent:

With those three, the question of whether you read every line stops being the question. You move from I read therefore I trust to I instrumented therefore I trust. That's the move. It's the same move good organizations made decades ago when they stopped trying to personally inspect every transaction and started building auditable systems. It is engineering. It just isn't the engineering most engineers were trained in.

This is what I mean by don't pick a side. The right answer isn't a tribe. It's a rule for when each tribe is right — plus a discipline (observability, least privilege, refusal) that holds whether you're reading the code or not.

Put the three debates back on the table cleanly:

If you find yourself in a strong opinion about "code vs no code," check which debate you're actually in. The disagreement usually dissolves once both people admit which fight they showed up for.

These are not philosophical questions. They affect cost, incident rate, hiring, training, and what your team becomes after a year of practicing whichever discipline you actually instilled.

I described what I wanted, an agent built it, I shipped it. That sentence is true about more of my week now than it has ever been. The honest follow-up sentence, the one nobody writes on LinkedIn, is the one I owe you here: I don't read most of what gets shipped under my name anymore. Neither do you, if you're being honest about your week.

The skill I'm actually building isn't reading more code. It's deciding, for each artifact, what I have to verify when I can't verify it all — the tests, the outputs, the behaviors that matter, the blast radius, the refusal path — and trusting the rest because the system around the trust is doing its job. Some weeks I get the calibration right. Some weeks I don't, and the system catches it for me, and that's exactly the point of building the system. Some weeks neither happens, and that's the cost of where the practice is right now. I'm not going to pretend it isn't.

The debate, framed as code vs no-code, is fake. The discipline — observability, least privilege, refusal, and a working number for Time-to-Trust — is real. Whichever side you end up on, the infrastructure under the trust has to be there. Without it, "I stopped writing code" is not engineering. It's just hoping.

This is the fifth issue of Don't Pick a Side. The next one is about prompt engineering — what's dead about it, what's more important than ever, and the distinction the loudest voices keep skipping. If you build with agents and want the next post when it lands, subscribe — and tell me which tribal debate is annoying you most right now.