The risk isn't being replaced
I'll get the obvious worry out of the way first, because it's the one everybody leads with. No, I don't think AI is going to replace good developers, at least not in the immediate future. The part of the job that's genuinely hard — knowing what to build, knowing when something feels wrong, holding the whole system in your head while you decide what matters — is exactly the part these tools are worst at.
But I think framing the entire debate around replacement is watching the wrong risk. The tools are here. They're genuinely good, they're improving every month, and crucially they're accessible — Claude Code, Cursor, ChatGPT and Codex are a subscription away for any engineer who wants them. They're going to be a line item in every company's monthly costs and a fixture in every engineer's toolset soon, if they aren't already. So the real risk isn't a model taking your job. It's working at half the pace of the person next to you who picked the tools up and learned to use them well.
That's the framing I've settled on. AI isn't here to do my work for me, it's here to augment it: to take the grind off my plate so I can spend my attention on the parts that actually need a human. And once you treat it that way, the question stops being "will this replace me" and becomes "how do I get the most out of it." For me, that turned into a repeatable loop.
The seven-step loop
This is the process I run when I'm building something real with AI in the mix. None of the steps are revolutionary on their own. The value is in running them in order, and in being honest about which steps are the AI's job and which are mine.
-
Idea. It starts where it always starts — a feature, or a whole app, that I want to exist. This step is entirely human. The agent can help me sharpen it later, but it can't want something into being.
-
Research. Before any real code, I point the agent at the problem space and ask it to do the legwork: competitor analysis, the established best practices for the feature, the common pitfalls. Deep research is something these tools are genuinely excellent at, and starting from a well-researched footing beats starting from my own assumptions every time.
-
Prototype. Then I get to code as fast as I possibly can. Usually that means asking the agent for a one-page HTML-and-JavaScript prototype, something I can open and click within minutes. Seeing the thing behave, even in a throwaway form, tells me more in five minutes than an hour of describing it ever would. This is where I find out what's actually working and what only sounded good in my head.
-
PRD. Once the prototype has taught me what I'm really building, I have the agent write a proper product requirements doc — a markdown file that spells out what the feature does, with a set of hypothetical user stories alongside it. It's the first time the idea gets pinned down in writing, and it becomes the source of truth for everything after.
-
Kanban. I turn that PRD into individual tickets, with real parent and sibling relationships and proper blocking dependencies between them, and load them into a task tracker like Linear. This is the step most people skip, and it's the one that makes the rest work. A well-structured board is what lets the agent run without me babysitting every line.
-
Execution. Now I let the coding agent loop through the board and actually build the tickets, ideally with the tracker connected so it can pick up the next unblocked piece on its own. This is the step everyone pictures when they imagine "AI coding," and it's honestly the least interesting one. By the time I reach it, the thinking is mostly done.
-
QA and test. Finally, I have the AI draft a QA and test plan written for a human to work through, not for the machine to mark its own homework. I review the completed work against it, and from there it flows into the pull request and the merge to production like any other change.
Why the loop keeps a human in it
Look at where the human sits in that list and you can see the whole augment-not-replace argument in miniature. The idea is mine. The judgement call on the prototype, does this actually feel right, is mine. The final QA review is mine. The agent does the research, the scaffolding, the ticket-grinding, the first draft of the code. It takes on the work that's laborious but not hard, and hands the hard-but-quick decisions back to me.
That division is the part that matters for anyone who cares about craft. An agent will happily generate a button with transition: all 0.3s ease and mark the ticket done. It won't notice that the duration is wrong, that the easing fights the interaction, that the empty state nobody specced looks broken. Noticing those things is still a human job, and I suspect it will be for a long while yet. AI got dramatically better at producing the code. It did not get any better at caring whether the result is actually good.
So I lean on these tools as heavily as I can for everything up to that line, precisely so I've got more attention left for the part on my side of it. That's the trade I'd make every time, and it's the one I'd gently nudge any engineer still holding these tools at arm's length to start making too. Not because the machine is about to replace you — because the engineer who's already fluent with it won't be waiting around while you catch up.