AI coding agents have not removed the need for senior developers. They have made senior engineering judgment more important by increasing the need for structure, debugging, review, context, and product discipline.
There is a whole genre of videos now on X, YouTube, and TikTok about software developers being sad, anxious, or cynical because “AI is replacing coding jobs.”
After spending real time using agentic coding tools inside production software work, my experience has been almost the opposite.
I am not watching AI replace the job of a serious software engineer. I am watching it expose how much judgment real software work actually requires.
I work on enterprise healthcare software and enterprise ERP-style systems. These are not toy apps. They involve authentication, privacy controls, mobile clients, backend APIs, database migrations, push notifications, role-based access, deployment environments, production bugs, and users who expect the thing to work.
In that world, the idea that someone can “one-shot” a reliable production product with AI is mostly fantasy.
AI can generate code. Sometimes it generates useful code. Sometimes it saves a lot of time. But to get useful work out of it, I have had to surround it with structure, context, instructions, review, debugging, and constant correction.
That is the opposite of replacement.
That is leverage.
The AI Needed a Lot of Help
To make Codex useful, I did not just say, “Build this feature.”
We had to set up a whole scaffolding around it.
We added BMAD-style planning and implementation artifacts. BMAD, in this context, is a lightweight method for giving agentic coding tools a more disciplined workflow: project context, story templates, implementation specs, QA checklists, and explicit constraints before the model starts editing files.
That matters because without context, the AI makes assumptions.
And even with context, it still makes mistakes.
It edits the wrong file. It invents call sites. It picks the wrong abstraction. It writes tests that prove very little. It misunderstands backend contracts. It assumes endpoints exist. It confuses iOS and Android sessions. It produces code that compiles in its imagined world but not in the actual repo.
More than once, the work was not “AI wrote the feature.” The work was:
- I wrote the ticket.
- I constrained the scope.
- I reviewed the plan.
- I corrected the plan.
- I told it not to overbuild.
- I inspected the diff.
- I ran the app.
- I used the breakpoint debugger.
- I checked network responses.
- I found the actual cause.
- I deleted or corrected bad assumptions.
- I made sure the code matched the product reality.
That is senior engineering work.
The Debugger Still Matters
One of the clearest examples was push notifications.
The iOS app was successfully generating an FCM token. The backend was storing it. Everything looked superficially close.
But notifications still were not arriving.
The answer was not obvious from staring at generated code. We had to trace the system:
- iOS APNS registration
- Firebase token timing
- backend token upload
- database rows
- backend send function
- Firebase Admin initialization
Eventually, the real issue was that the backend Firebase Admin client was not initialized because the service account credentials were missing. The function reached the send path but exited because fcm was null.
That is not something an AI “one-shots” reliably.
You need someone who understands the system well enough to ask: Where does the token come from? Where is it stored? Where is it sent? Is Firebase actually configured? Is the catch block even relevant if the SDK returns per-token failures instead of throwing?
The same thing happened with Android profile images.
The DTO was eventually correct. The image URL resolved. Coil attempted to load it. But it failed with:
HTTP 401: Unauthorized
That told us the image endpoint required the authenticated session cookie. The fix was not “make the URL better.” The fix was to attach the cookie from the app’s authenticated cookie jar to the Coil image request.
That is production debugging. Not prompt magic.
AI Can Create Work as Easily as It Removes It
A big myth in the AI coding conversation is that AI simply reduces labor.
Sometimes it does.
But sometimes it creates a new kind of labor: supervising a very fast junior developer with no durable understanding of the product.
It can generate code quickly, but speed is not the same as correctness. In fact, the faster bad code appears, the more important review becomes.
In recent production work alone, we dealt with:
- incorrect assumptions about whether uploads required cookies
- confusion between iOS and Android behavior
- wrong call-site signatures
- unwanted upload scope when display-only parity was enough
- React crashes from string dates being treated as Date objects
- backend Firebase credentials silently missing
- local-only privacy toggles needing real persisted settings
- mobile clients needing exact backend contract parity
None of that is solved by “write code faster.”
The hard part is deciding what code should exist.
You Are Not Hiring Me to Write One-Shottable Software
This is the deeper point.
If the software can be one-shotted by a prompt, it probably was not the valuable part of the business.
You do not hire a senior engineer because they can type syntax. You hire them because they can make the product reliable under real constraints.
They can find the actual bug instead of the plausible bug.
They can tell when a test is fake rigor.
They can stop an agent from turning a small fix into a sprawling refactor.
They can recognize when a mobile app is out of parity with the backend.
They can distinguish “the upload URL is wrong” from “the authenticated image request is missing cookies.”
They can say, “No, do not implement upload yet. First restore display parity.”
They can decide where risk belongs.
That judgment is the job.
AI Is an Amplifier, Not a Replacement
Agentic coding tools are useful. I am not dismissing them. I am using them heavily.
But the way they are useful is not the way social media often presents them.
They are not replacing serious software engineering. They are amplifying engineers who already have architectural judgment, debugging instincts, product context, and taste.
A weak engineer with an AI agent can now generate more weak code faster.
A strong engineer with an AI agent can cover more surface area, inspect more options, generate scaffolding faster, and move through implementation details with less friction.
But the leverage comes from the engineer.
The agent does not know what matters unless someone tells it. It does not know the business context unless someone supplies it. It does not know when it hallucinated unless someone catches it. It does not know when the code is technically working but product-wrong.
About the OpenClaw-Style Counterexample
There are impressive public examples of autonomous agent systems. OpenClaw, for example, is described by its own project as a personal AI assistant that runs on user devices and works across channels like macOS, iOS, Android, and messaging interfaces.
But even those examples do not prove that production software can simply be one-shotted without engineering oversight. Reporting around OpenClaw has emphasized scale, cost, agents, infrastructure, and operational complexity rather than “a non-engineer typed one prompt and shipped a reliable enterprise product.” One report described a month with hundreds of billions of tokens, millions of requests, and around 100 autonomous coding agents involved.
That is not a one-shot replacement story. That is an enormous engineering system.
Even if AI agents become far more capable, the pattern still looks like this: more automation, more orchestration, more review, more security concerns, more context management, and more responsibility for the people directing the system.
The Future Is Not Less Engineering
The future is not “no developers.”
The future is that developers who only type code from tickets will be under pressure.
But developers who understand systems, debug production behavior, manage complexity, define scope, review AI output, and protect product quality will become more valuable.
AI changes the work. It does not remove the need for judgment.
In my experience, it has made senior engineering feel less like typing and more like directing a very fast, very unreliable team member.
That is powerful.
But it is not replacement.
It is leverage.
