There's a sentence I hear more often than I'd like: "the AI wrote the code, so the feature's basically done." It isn't. The code arriving is the easy part of the job, and calling it "developing" is where the confusion — and the bugs — start. This post is about the line between the two, and why I care about it more now that a machine can produce a plausible first pass faster than I can type.
I've been doing this long enough that the fast output is a gift, not a threat. But a gift you don't understand is a liability. The distinction in the title isn't pedantry — it's the difference between a feature that ships and a feature that ships and then quietly costs you.
Coding is syntax. Developing is a decision.
Coding is the act of producing syntax that does a thing: a function, a loop, a migration, a template. It's a craft, and it matters — but it is also the part of the work that has always been the most mechanical. Developing is the set of decisions that decide what syntax should exist in the first place: what problem are we actually solving, for whom, under what constraints, and what happens when it breaks. You can be a brilliant coder and a poor developer, because the second job isn't about fluency with the language. It's about judgement.
A trivial example: I can ask a model for "a function that validates a South African ID number" and get working code in seconds. That's coding, done well. Whether the ID should be validated at all, where the check belongs in the flow, and what happens to a user who fails it — those are developing, and the model will not raise them unless I do.
What AI is good at — and where it stops
AI is, bluntly, a very good coder. Give it a well-scoped function and it returns one faster than I'd type it, often cleaner. That's real, and I use it daily. Where it stops is the part that isn't syntax: it doesn't know why this site runs the configuration it does, or what a real client will do with a setting they half understand, or which trade-off the business actually cares about. It produces the answer to "how do I write this?" long before it has earned an opinion on "should this exist, and in what form?" The first question is coding. The second is developing. The model is good at the first and silent on the second — and silent in a way that looks like agreement.
I'll give it this: on a known convention in WordPress, the speed is genuine. But "genuine on the known" is exactly the limit. The moment the question touches the unknown — your history, your client, your edge case — the fluency keeps going and the relevance drops. That's the stop line, and it's invisible unless you're looking for it.
Why my harness splits building from deciding
This isn't only theory for me; it's built into how I work. In the Bishop harness I use, the roles are deliberately split: the @orchestrator decides what should be built and delegates, the @junior-developer implements the syntax, and a @code-reviewer verifies the result before it's treated as done. The point of the split isn't to make the agent feel like a team. It's to keep the decision and the typing in different seats, so that "someone wrote the code" never gets mistaken for "someone decided this was right." The orchestrator is the developer; the junior is the coder. Separating them is how I stop fast output from masquerading as judgement.
The decisions AI can't make for you
Here's where it gets concrete. The decisions AI can't make for you, at least not honestly: scope — what's actually in and out of this change; trade-offs — faster now versus maintainable later; client context — what this specific client will do with the feature, and what they'll break; and maintenance burden — who pays when this pattern ages.
Scope: does "add a newsletter signup" mean a checkbox or a full preference centre? Trade-offs: the clever one-query solution versus the boring one your junior can maintain. Client context: this client will paste the same CSV twice and blame the site. Maintenance burden: who reads this in eighteen months, and will they hate you? Every one of those is a developing decision. The model can draft the code that follows from a decision you've already made, but it will happily produce reams of syntax for a problem you haven't framed yet, and present it as progress. That's the trap: output that looks like development but is only coding wearing its clothes.
[OPERATOR INPUT — needed before publish]: A project story where the hard part was not writing code but deciding what to build — what was the decision that mattered, and what would have gone wrong if the model had simply "coded" past it. (2–4 sentences)
What this means for hiring, planning, and estimating
If you manage or hire, this changes what you should measure. A team that ships lines of AI-generated code quickly is not the same as a team that develops well. When you estimate, the risk isn't the typing — it's the deciding, and that hasn't got cheaper. Plan for the review, the framing, the argument about scope; those are the hours that matter now, and they're human hours. The organisations that do well are the ones that treat the model as a fast coder and keep the developer — the decider — in the loop, accountable and awake.
I've started estimating AI-assisted work the same way I used to estimate junior work: generous on review, honest on the hard calls. The typing is cheap now; the deciding was never cheap, and pretending otherwise is how budgets slip. Hire for the developer, not the prompt-writer — the person who can frame the problem is the one the model amplifies.
If your team is measuring output lines instead of decisions made, you're optimising the wrong thing.
More in this series
- Up: How I Actually Work With AI
- Sideways: "Why I Assume AI Is Both Smarter and Dumber Than Me" (
ai-smarter-and-dumber-than-me) and "What I Stopped Delegating, and Why" (what-i-stopped-delegating-to-ai) — both to be published; URLs resolve at publish time.
Next: Why I Assume AI Is Both Smarter and Dumber Than Me — the post that takes the other half of this split apart: the places where the model is genuinely smarter than me, the places where it's clearly not, and why forgetting the "not" half is what gets teams into trouble.