Who's Writing the Code — You or AI?

September 3, 2026

Who's Writing the Code — You or AI?

IDE vs. AI: Who Wrote the Code?

When we use an IDE, it clearly helps us write code: autocomplete fills in constructs, doc tooltips pop up as you type. Yet nobody would say, "You didn't write that code — your IDE did." Why? It's simple: as long as you're in control of the process, you remain the author. So why does AI raise the question of who actually wrote the code?

AI, just like an IDE, helps with code. But with AI, people feel a loss of control. Right now we're seeing a mass rollout of agents into developers' workflows. The message is: you don't need to write code anymore — write prompts instead, build infrastructure for LLMs. The whole idea behind an agent is full automation: if you still find yourself writing code by hand, you're simply using it wrong — or not well enough. But once your day revolves around infrastructure and prompts, your area of responsibility shifts. You become an LLM operator, not a programmer in the traditional sense. You're the author of prompts, of infrastructure, of whatever you like — but not of the project the model produced.

The Fork: Control vs. Quality Guarantees

So the LLM has implemented a feature in a massive codebase. You need to guarantee the quality of the result — yet the AI bears zero responsibility and has nothing to prove. That's the fork: on one hand, you're told to let go of control because "code is dead"; on the other, you're expected to verify everything the model wrote and guarantee it's correct.

A real-world case. An agent rewrites the order-processing flow. The reviewer looks at the diff — method names look familiar, tests are green, approved. A week later an order breaks in prod: a user cancelled and paid within the same second, and the order landed in an impossible state. The reviewer didn't miss it because they were bad at their job — they missed it because they weren't the one holding that logic in their head. The prompt was. And the prompt died with the agent's session.

You can only truly track a project's logic by working with the code itself. What you end up with is a surface-level review of code the developer most likely no longer understands. And there's an important distinction here: some stopped understanding because they stopped writing; others never really started.

"No Longer Understands" vs. "Never Understood"

"No longer understands" describes people who once wrote code but quit. "Never understood" describes those who entered the profession on the AI wave and simply never had time to build a foundation. In practice, the person isn't writing code and isn't getting any reps in. Theory without practice leads nowhere: someone might think they can code — they've read about it, watched tutorials, grasp how it works in theory. But throwing together a demo that follows every textbook rule is not the same as maintaining a project for years.

There's a precise parallel in another industry. Aviation has long recognized a phenomenon called automation-induced skill degradation: pilots who fly on autopilot lose their manual flying skills. The problem is considered serious enough that regulators have issued directives requiring regular manual-handling practice during actual flights — because when the automation fails, it's a human who hasn't touched the yoke in months who has to deal with it.

The exact same thing is happening with code. We risk ending up with people who are confident they can write code but actually can't. They can no longer guarantee results without an LLM, and their dependence on the model keeps growing.

To be clear: the problem isn't dependence on a tool per se. A programmer is "dependent" on a compiler, on a framework, on the standard library — and that's perfectly fine. The real problem is twofold: being unable to do the work without the tool, and being unable to verify its output. That's exactly why headlines claiming "AI will replace programmers" miss the mark: you can only replace someone who wasn't in control of the result to begin with.

AI Is a New Level of Abstraction, Not a Replacement

Programmers have been "replaced" before — by CMSs, low-code platforms, website builders. But every such "replacement" was simply a raise in the level of abstraction. Spin up a site on a CMS in five minutes and you get an admin panel with a limited set of features: plugins, themes, settings.

AI is no exception. When an agent builds a project, you get the same effect. The code exists, and technically you can edit it by hand — but if you don't understand it, you're effectively boxed in the same way you are inside a CMS admin panel. The only difference is the illusion: with a CMS you know you're limited; with an agent, you don't.

And this is a critical point. A hidden constraint is more dangerous than an explicit one. You discover a CMS's limitations at the moment you choose the platform — calmly, in advance. The limitation of "I don't understand the agent's code" reveals itself during an incident — when prod is down, the agent has generated its fifth broken fix in a row, and there's no one who can actually dig in. That's why adding a custom plugin to a CMS or manually patching agent-generated code increases system complexity — and why you can't do without real programmers.

What "Control" Actually Means — The Criteria

Should you ditch AI to protect your skills? No. But handing over full control isn't the answer either. AI is a tool, and everything depends on how you work with it.

But what does "control" actually mean? I'd propose three checks — each of us can use them to honestly assess ourselves:

  1. You can explain why the code is written this way. Not "what it does" — that's visible in the diff — but why this solution was chosen over alternatives, and which alternatives were rejected.
  2. You can predict the code's behavior before running it. Including edge cases, not just the happy path.
  3. You can reproduce the solution without AI. Maybe slower, maybe less elegantly — but you can.

If even one of these fails, control has been handed to the model — and authorship along with it. If all three hold, then AI is exactly what an IDE is for you: a helper, not the author.

Control grants authorship. But it also grants growth, high-quality code, and genuine understanding of the project.

Assistant vs. Agent — Different Contracts

When people say assistants are outdated and agents are their natural evolution, I disagree. Assistants and agents are built on fundamentally different interaction contracts. An agent is a path toward automation, where the developer becomes an LLM operator. An assistant, on the other hand, speeds up and simplifies your work — without surrendering control over the code.

With an assistant, you work as if with a pair. To solve a problem, you study the project yourself and deliberately feed it the context it needs — rather than asking it to figure everything out on its own. You run every response through your own knowledge and judgment. Essentially, the developer works the same way as always: we used to study the codebase, post questions on forums, dig through articles, read documentation. Now we just plug in a search MCP and ask the model. The call on whether the answer is correct is ours at every step — not after the fact, but throughout the process.

What This Looks Like in Practice

So this doesn't stay at the level of "just keep control," let me get specific. Here are practices that let you work with AI fast without giving up authorship:

Takeaway

Working with an assistant, we stay in control of the project and work the same way we always have: we learn ourselves and we teach the model through context during the conversation. This gives us high-quality code at minimal cost and significantly faster development. At the same time, control is what makes the developer the author — one who can, if needed, get by without an LLM.

The code is yours to exactly the degree that you control it. Everything else is just a CMS admin panel — only without the honest disclaimer about its limitations.