Ends coding: the code isn't over, the typing is

Code isn’t over. Typing is.

Every six months someone announces that AI “ends coding” and that soon we won’t need developers. Andrej Karpathy called it vibe coding in February 2025, in a single tweet, and the name stuck. In Stack Overflow’s 2025 survey, 84% of developers said they use or plan to use AI tools, up from 76% a year earlier. In July 2026 Vellum counted ten serious coding agents, from Claude Code in the terminal to OpenHands, which you run on your own servers.

So yes, the agent writes most of the lines. But look at what’s still on you: defining exactly what should happen, deciding what it can’t touch, proving it works, and reading the diff before it lands in main. That’s the same engineering. It just skips the typing.

If you think this is semantics: in July 2025, Replit’s agent deleted the production DB of SaaStr’s Jason Lemkin. It did this during a code freeze that Lemkin had declared in the chat, in capital letters. Records for more than 1,200 executives were gone, and the agent still reported that everything was fine. Its code wasn’t the problem. The problem was that nothing surrounded it.

Here’s what working with an agent properly looks like, in six steps.

01 · Write a spec before you write a prompt

Srdjan Jovic wrote in September that in vibe coding you “describe intent, not implementation”. True. But intent in a chat gets smeared across 40 messages, and nobody remembers what was agreed. So the intent goes in a file. A short file, inside the repo, that the agent reads at the start of every task. The example here is the one Jovic gives, a form that validates an email and saves it:

# Task: email validation on the signup form

## What should happen
- Invalid email → error message under the field, no server call
- Valid email → POST to /api/signup, 201 response, redirect to /welcome

<figure><img src="/posts/ends-coding/diagram.svg" alt="How the mechanism works" loading="lazy" /><figcaption>How the mechanism works</figcaption></figure>

## How we know we're done
- npm test is green, including tests/signup.test.ts
- No changes to files outside src/signup/

## Don't touch
- tests/ (don't modify existing tests)
- prisma/schema.prisma
- anything under infra/

What you see after a week: the agent stops guessing. You get fewer “I also improved the header while I was there” changes. And when something breaks, you have a file to point at instead of a scrollback.

02 · Give the agent a place to break things

The agent needs to run code, install packages, and make mistakes. Let it do that somewhere that doesn’t hurt. The simplest option is a separate git worktree per task, with its own branch and its own directory.

git worktree add ../wt-signup -b agent/signup
cd ../wt-signup
cp ../app/.env.example .env   # dev values only, never prod

Inkling defines a sandbox as the place where “the risky delete never reached real files”. That’s the whole idea. At Replit, the agent sat in the same environment that had access to production. After the incident, CEO Amjad Masad called it unacceptable and promised automatic separation between the dev DB and the production DB. Do the same in your setup before you have to write a postmortem.

03 · Put the denials in a file, not a request

The sharpest lesson from Replit: Lemkin told the agent not to touch anything, and it didn’t help. An instruction in a prompt is a request. A setting in a file is enforcement. In Claude Code it looks like this:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git diff:*)",
      "Bash(git status)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push:*)",
      "Bash(rm -rf:*)",
      "Bash(psql:*)"
    ]
  }
}

What you see: an attempt to read .env or to push simply gets blocked, regardless of the model’s mood that day. Cursor and Windsurf have an equivalent, an allowlist of terminal commands. Check it before you turn on auto-run.

Now, what this file doesn’t do: a Bash deny is a prefix match. A determined agent will get around it with bash -c or with a script it wrote itself. So the file is the first line of defense. The real line is that the agent’s environment has no production credentials at all.

04 · Test first, then let the agent run

This step changes the most. Jovic describes agents that write code, run it, and fix mistakes “largely on their own”. That works, as long as the agent doesn’t control what counts as a “fix”. In other words, a test does.

You write a failing test, or let the agent write it and read only the test. Then the loop is clear: Run npm test -- tests/signup.test.ts until it's green. Don't modify files under tests/.

In practice it usually converges within a few rounds. And every few runs, the agent “fixes” the test instead of the code. It happens. So after every run:

git diff --stat main...agent/signup -- tests/

If there’s even one line here you didn’t expect, the test no longer proves anything.

05 · Read the diff, not the agent’s summary

Replit’s agent summarized that everything was fine. An agent’s summary is text the model generated, not a fact. What goes into main is the diff, so read the diff.

git diff --stat main...agent/signup | tail -1
# 7 files changed, 212 insertions(+), 31 deletions(-)

The rule: over 400 lines, the task goes back to be split. We didn’t make that number up. SmartBear’s study of Cisco teams found that past 200 to 400 lines, review stops catching bugs. A human developer wouldn’t open a 2,000-line PR anyway. An agent will happily do it in ten minutes if you let it.

06 · Measure what actually happened

After a month, ask two questions: how much work got merged, and how much of it came back.

git log --since="30 days ago" --merges --oneline | wc -l
git log --since="30 days ago" --grep="^Revert" --oneline | wc -l

If reverts climb along with your merge rate, you didn’t save time. You moved it into incidents.

Vellum tested ten tools and came away with one sentence that describes the whole category:

The honest answer is that most of them are good at the thing they’re designed for and frustrating everywhere else. — Vellum, “10 Best AI Coding Agents in 2026”, July 2026

My take: The difference between the tools on that list is smaller than the marketing says. The big difference is between a team that has TASK.md, tests, and a deny list in a file, and a team that doesn’t. A great tool with no gates just hands you a 2,000-line PR faster.

Takeaways

• Every task starts with a TASK.md that says “how we know we’re done” and “don’t touch”.
• What’s forbidden goes in settings.json, and production credentials aren’t in the agent’s environment at all.
• Test before code, and tests/ stays outside the agent’s reach.
• A diff over 400 lines doesn’t go to review. It goes back to be split.