I Shipped Three Apps Last Week. I Can't Write a Line of Code. Developers Should Be Relieved.

October 29, 2026

People keep asking the same question: "If AI can write the code, what's left for developers?"

I'm well placed to answer it - not inspite of, but because - I'm not a developer. I can't write a for loop. I couldn't tell you where the semicolons go.

Last week I published three apps. One has workflows with several steps, depends on multiple services, and has failure modes I had to think through properly. I didn't write any of the code.

What surprised me is that I worked harder than I expected to. The hard part wasn't typing. It was deciding.

The myth: developer = person who types code

Most people picture a developer as someone in a hoodie, lit by a dark-mode editor, turning coffee into syntax. Code is what they produce, so we assume code is the job.

That's like assuming a surgeon's job is holding a scalpel.

There are somewhere around 47 million developers in the world (this includes the hobbyists and people like me, professional developers are closer to 25 million). The good ones spend a surprising share of their time not coding. They're figuring out what to build, why it matters, what could go wrong and what to leave out. Code is how those decisions get written down. It isn't the decisions.

Last week the AI did the writing. Every decision was still mine.

What I actually did last week

Here's an honest list of what took up my time:

• Workflow design. What happens first? What happens when step 3 fails halfway through? Does the user wait, retry or get a message?
• Service isolation. Should these two parts share a database? If one breaks, should it take the other down with it?
• Resiliency. What happens at 2 a.m. when a dependency goes down?
• Cost and frugality. This setup works. Does it still make sense at 100× the traffic? Am I paying for capacity I'll never use?
• Performance. Where's the latency coming from, and does the user notice it?
• Security. Who can see what? Where do the secrets live? What's exposed that shouldn't be?
• Operational architecture. When something breaks, how will I know, and how fast can I fix it?

The AI handled all of these questions very well. It explained tradeoffs, suggested patterns and pointed out risks I'd missed. But I never let it assume a decision or tell me what to do or use its default settings. I made those deliberate choices based on my knowledge of who the users are, what the business needs and what I could afford to get wrong.

The AI did the driving. I picked the destination, the route, the speed, and the scenery.

Skill #1: Knowing which doors can be walked back through

Amazon has a useful idea about this. Some decisions are two-way doors: you walk through, and if you don't like what you find, you walk back. Others are one-way doors: once you're through, you're committed.

Early in a product's life, most decisions are two-way doors. Try the layout. Swap the library. Rename everything. With AI writing the code, going back costs close to nothing, so experimenting is almost free.

Some decisions are one-way doors whether you have three test users or a million production users:

• How your data is modeled
• Where identity and trust boundaries sit
• What you commit to in a public API
• Coupling services that should never have been coupled

The skill isn't making every decision perfectly. It's telling which kind of door you're facing. Rushing a one-way door is how you get rewrites. Agonizing over a two-way door is how you never ship.

AI makes the two-way doors faster. It does nothing to help you spot the one-way ones. That still takes judgment.

Skill #2: Translating the business into the build

"Customers should be able to track their orders" is a business requirement. It doesn't tell you anything about polling versus push, how fresh the data needs to be, what happens offline, who's allowed to see which order, or what it costs per request.

Someone has to turn intent into design. That means taking a fuzzy human need and producing specific, testable requirements a system can meet.

An AI will happily build whatever you describe. If what you describe is wrong, it builds the wrong thing very fast. Being fast at the wrong thing doesn't help.

Skill #3: Drawing the lines between now, later and never

I had a backlog last week. I still do, and I always will.

Having a backlog doesn't mean I'll get to everything. Some of it can wait for later. Some of it may never get built. Deciding which bucket each item goes in is one of the most valuable things anyone on a product team does.

Product managers are probably smiling at this. Welcome to the club, they're thinking. We've been doing this for decades. They're right. Deciding what not to build has always been the job. AI just made it easier to see, because building is no longer the bottleneck.

When anything can be built, choosing what gets built becomes the hard part.

Skill #4: Taste

This is the one I feel most strongly about.

AI tools are extremely capable, but they don't have taste.

They don't know that a button is technically correct and still feels off. They can't tell that a workflow is complete and still exhausting, or that a screen is accurate and still confusing. They don't know what feels right for this user, in this situation, on this day. In my own experiment, it presented some horrendous choices, which I had to course-correct.

Taste is deciding what makes sense in context and what looks and feels right. A lot of that is UI and front-end, but not all of it. Taste is in the shape of an API, the wording of an error message, and whether a workflow has five steps or two. Usability engineering is a science of its own, with decades of research behind it, and someone still has to apply it with judgment.

Code can be generated. Judgment still has to come from a person.

What we used to split up, AI is putting back together

Traditionally, the software industry divided this work among specialists:

That split made sense when every role was expensive and slow. Each specialist guarded their fort, and handing work between them was where context got lost.

Here's my main point: AI doesn't remove the developer. It removes the busywork that kept the developer from being all of these roles at once.

With the typing handled, a developer has time to think about the whole product. They can question the requirement, sketch the flow, weigh resiliency against cost, try the experience as a real user would and decide what goes in the backlog. The roles don't disappear. They come back together in one person who can now see the whole thing.

So, will AI make developers obsolete?

It will make one narrow version of the developer obsolete: someone whose entire value was turning clear instructions into syntax.

The developer who brings business context to technology is more valuable than ever. That's the person who makes architecture calls, guards the one-way doors, keeps the backlog under control and has the taste to know when something is right.

I'm proof, in a slightly odd way. I'm not a developer, and last week I did a developer's job. I didn't do it by typing. I did it by deciding.

Imagine what someone who really knows this craft can do when the typing isn't slowing them down.

The code was never the job. It was the evidence of the job. AI has just made that obvious.

Have you shipped something recently without writing the code yourself? What was the hardest decision you had to make? I'd like to hear about it.