AI Coding Agents Are Great. Until Someone Asks You to Code Without One.

Recently I decided to do something slightly unnatural for a solo founder: apply for a job, mostly to keep the lights on and the invoices paid. The SQL part of the technical interview felt familiar. The live coding part did not go well at all.

What bothered me afterwards wasn’t the failure itself, which happens to everyone. It was how little the exercise resembled the work I do every day.

For the past while I’ve been building AlturaQuantera on my own, which means I’m the architect, the implementer, the DevOps person, and the only code reviewer, all in the same week. It’s a multi-tenant SaaS built on Clean Architecture and CQRS, with RBAC, Hangfire background jobs, audit logging and traceability, idempotent operations, dependency injection throughout, unit and integration tests, Docker Compose stacks, and GitHub Actions pipelines. None of that is exotic, but all of it has to keep working together, and keeping it working is most of the job.

Then somebody puts me in front of an empty editor, starts a timer, and watches me type. A small algorithmic task sits on the screen. I’m not weighing a boundary between modules or tracing a production bug or reviewing a risky change. I’m trying to remember whether I just missed an obvious edge case while a human being looks on. Very different sport.

AI changed my workflow before it changed my job

I’ve been writing software long enough to remember when “developer tooling” mostly meant an IDE that could indent code properly. Then came better autocomplete, then static analysis, then Stack Overflow quietly became part of the unofficial runtime environment of software development, then GitHub Copilot, and now repository-aware coding agents.

None of it felt dramatic. I just noticed one day that I was spending less time typing predictable code and more time deciding what should happen next. AI didn’t take thinking out of my workflow. It moved the effort away from syntax and mechanics and toward framing, constraints, review, and validation.

What agent-assisted work looks like on a real project

On AlturaQuantera I almost never say “build this feature” and wait. Before any code is written, I work with the agent on a detailed implementation plan, then split it into slices, and each slice gets its own description and acceptance criteria. The agent can draft a lot of this, but I decide what a slice is allowed to touch and what “done” means.

For the stages where a mistake would be expensive (tenant boundaries, background job context, anything that changes state), I add a preflight AI audit before implementation starts. A separate agent reads the plan against the existing codebase and looks for conflicts with current boundaries, missing acceptance criteria, and assumptions that sound plausible but aren’t true here. It catches things I would have found in review anyway, only a day earlier and at a fraction of the cost. I wrote about this workflow in more detail in AI Coding Works Better When the Agent Has a Contract, including the actual prompts I use for task contracts and preflight audits.

Only then does the agent write code, usually a small slice at a time, with tests, and with me reading the diff. A prompt in the middle of that process looks closer to this than to “build this feature”:

Here is the current architecture.
Here is the invariant that must not change.
Here are the relevant files, and please stay out of the other areas.
First explain what you think needs changing, then make the smallest change, then run these tests, then show me the diff.

That’s still engineering. The skills that matter are picking the right context, defining scope, recognizing hidden constraints, protecting architectural boundaries, spotting false assumptions, and deciding when the agent has become more expensive than just writing the code yourself. Occasionally it also means saying “No. Stop. That’s not what I asked for,” which is a surprisingly useful engineering skill in 2026.

It is also a very confident junior developer

The metaphor I keep coming back to is an extremely fast junior developer with unlimited patience, perfect typing speed, and absolutely no embarrassment about being wrong. It will happily modify six files based on a misunderstanding you introduced in one sentence. It will produce a beautifully structured solution to the wrong problem, invent a helper abstraction because it feels architecturally pleasant, and maybe even write tests proving that its incorrect interpretation works exactly as designed.

That’s why the planning and the audits exist. The agent’s speed is only useful if something slower and more suspicious is steering it.

Some things should make you suspicious immediately

There are areas where I care much less about how elegant the generated code looks: money, authorization, tenant isolation, concurrency, data integrity, and anything that could send one customer’s data to another. Anything involving the phrase “exactly once” belongs on that list too.

If an agent writes a background job that looks plausible, the interesting question isn’t whether it compiles but whether it can run twice and do damage, which is why idempotency isn’t optional in my projects. If it touches tenant isolation, I care less about how pretty the repository pattern is and more about whether one missed filter just created a very bad Tuesday. The same goes for audit logging: it’s easy to generate, and much harder to make sure it records what an incident review will actually need. The AI can speed up implementation, but it can’t inherit accountability.

Real software is usually messier

Most production work I’ve done didn’t start with “implement this algorithm in 25 minutes.” It started with something closer to: something is wrong, nobody is entirely sure where, the system is old, three integrations are involved, one of them is barely documented, production data behaves differently from staging, please fix it without breaking anything important.

Or: we need this feature, but it has to stay backward compatible, survive retries, respect tenant boundaries, produce useful logs, and not make Friday-evening deployment exciting. Or, sometimes, just: this code works, so should we touch it at all?

Those tasks reward architecture, debugging, understanding the system, code review, operational judgment, risk management, and knowing when not to be clever. A developer can be strong at all of that and still look unimpressive solving an isolated puzzle while being observed. The reverse happens too: someone can be brilliant at algorithmic interviews and still be surprisingly dangerous inside a large production system.

What live coding does measure

To be fair, live coding tests real things: whether you can reason independently, decompose a problem, recall what you know, notice edge cases, and explain your thinking under pressure. Those are useful signals, and I don’t think the format is meaningless. I just think it’s easy to overestimate what that signal represents.

Developers have always used tools: IDE navigation, documentation, debuggers, profilers, static analysis, tests, git history. Nobody seriously expects production engineering to happen from memory. AI is another step in the same direction, only a much bigger one. Once it’s part of the normal workflow, taking it away during evaluation changes what’s being measured. That doesn’t make the evaluation invalid, only narrower.

Some muscles do weaken

There’s an uncomfortable part here. If I use AI heavily, I get worse at some things. I write less code completely from scratch, I remember fewer APIs exactly, some syntax leaves working memory faster, and simple algorithmic tasks feel less automatic than they used to.

There’s also a more dangerous failure mode, which is that AI can make shallow understanding look productive. The code compiles, the tests pass, the diff looks reasonable, and everything feels under control, right up until you try to explain exactly why the implementation is correct. AI makes it possible to generate code faster than you can fully understand it, which is both the feature and the risk.

“No AI allowed” is probably not the future either

The obvious reaction is to say interviews should just ban AI so candidates prove they can still think. There’s some value in that. But if the actual job involves using AI tools every day, ignoring that skill completely starts to look strange too.

Using an agent well isn’t the same as asking ChatGPT for an answer and pasting whatever comes back. It means giving useful context, constraining the task, recognizing when the model has misunderstood the architecture, catching a subtle mistake in a polished implementation, stopping the agent before it rewrites half the codebase because it spotted “an opportunity to improve consistency,” and being able to explain why the generated solution is safe. Those are increasingly practical engineering skills, and they seem worth testing.

If I were designing an interview today, I wouldn’t remove unaided coding completely, but I’d reduce its weight. A short task without AI can still test basic reasoning. Then I’d add something closer to real work: a code review exercise, a debugging problem, an architecture discussion, and a small repository where the candidate can use the tools they’d actually use at work. Do they immediately tell the agent to “fix everything,” or do they read the code first? Do they review the diff and notice when the AI makes something worse? That tells me something useful.

“The AI wrote it” is not a production incident strategy

Responsibility doesn’t move to the model. If generated code introduces a race condition, leaks tenant data, breaks authorization, or charges somebody twice, nobody in the incident review feels better after hearing “Copilot suggested it.” The engineer still owns the change.

So maybe the question isn’t whether someone can code without AI, or whether they can code with it. It’s whether they can use powerful tools without surrendering their judgment. I think live coding is an increasingly incomplete way to find that out, and the interview should probably change along with the work.

The part that still stings

I’d like to end on the tidy conclusion, but there’s a less tidy one.

The task I failed was the kind I used to solve at university. Dozens of them, for myself and for friends, in exchange for beer (please don’t tell anyone). I knew that type of problem the way you know a route you’ve walked a hundred times, and during the interview I stood at the start of it and couldn’t find the path.

I can argue all day that this skill matters less than it used to, and I mostly believe it. But I also notice a small, slightly sad feeling that something I was once quick at has quietly slipped away while I was busy getting good at something else. Maybe that’s the honest price of the trade. I’d make it again, though next time I might quietly practice a few of those old tasks first, preferably without beer.