Skip to content
AI-native product development4 minSep 1, 2026

When AI Writes Most of the Code, My Job Is Deciding What Not to Build

Daniel Goldman on what's actually left for developers when AI writes most of the code: fast decisions about what to build, not typing.

The question "what's left for a developer when AI writes most of the code" assumes the job was always typing code. It wasn't. I've been building products solo for a few years now, with Claude Code on nearly every line, and what decides whether a product works has nothing to do with who typed the code. It's how fast I decide what to build, what to skip, and what to reject outright, plus how carefully I read what the AI produces before it reaches a customer.

The agent debate doesn't apply to me

There's a live argument right now about whether AI agents are a useful tool or an industry-wide bet that's about to fail. Both sides are right, depending on which kind of agent they mean. A general-purpose agent that's supposed to decide everything on its own, with no human looking, still doesn't work well in most cases. But that's not how I work. I don't let Claude Code decide what Tadam builds next. I decide, it executes, and I read every diff before it ships. The best agent I have isn't the one that replaces me, it's the one that shrinks the distance between a decision and a working feature down to almost nothing.

When product and engineering are the same person, the loop disappears

On most teams there's a gap between whoever decides what to build and whoever builds it. The meeting, the ticket, the handoff, the review cycle. On products like Tadam or Brainers Club there is no such gap, because I'm the same person talking to users and writing the feature with Claude Code, often the same day. That doesn't make me a faster typist. It shrinks the distance between "I spotted a problem" and "the problem is fixed in production," because there's no translation happening between two people speaking two different languages.

What I actually teach at nCode and in the workshop

When I teach this to my 600 students at nCode, or to the 600 business owners in the Claude Code Workshop, I'm not teaching them to write better prompts. I'm teaching them to read code they didn't write and decide, in seconds, whether it's correct, risky, or simply unnecessary. That's an editor's skill, not a writer's skill. Anyone who only learns to ask AI for things, without building that muscle, ends up with a product that looks finished and breaks the first week it meets real users.

  • Does this solve the problem the user actually reported, or a problem I imagined on their behalf
  • Is there a layer here that didn't need to exist
  • Did I read every line going into production, not just the final result
  • Can I delete this cleanly if it turns out to be wrong, without breaking something else

The real risk isn't unemployment, it's speed pointed in the wrong direction. AI lets you build the wrong thing faster than ever, and with 10,000+ paying users across the platforms I run, a wrong direction doesn't get caught after a pleasant week of development, it gets caught after it has already cost money and trust. So what's left for a developer when AI writes most of the code is almost everything except the typing: judgment, taste, and knowing when to stop. Those were never in the syntax to begin with.

FAQ

If AI writes most of the code, is it still worth learning to program?

Yes, but not for the typing. It's worth learning so you can read code and judge it, because that's the skill that actually decides whether a product works. That's exactly what I teach at nCode.

How do you know if an AI agent did good work on a feature without checking every line by hand?

You can't fully skip reading the code on anything critical, but you can cut down what needs manual review by defining upfront what the feature must do and must never do, then checking the result against that, instead of reading every line in isolation.

What's the difference between using Claude Code solo versus using it on a team?

Solo, there's no handoff, so the review happens right after the writing, by the same person who decided what to build. On a team, you need to explicitly assign who owns that review, otherwise features reach production without anyone having read them with a critical eye.

More from the blog