If an agent writes code, what does a person become?

Andrey Karpathy in January 2026 coined the term agentic engineering and said: you don't write code 99% of the time, you orchestrate agents and provide oversight. Boris Cherny, head of Claude Code at Anthropic, reported that since November he hasn't manually edited a single line and ships over twenty pull requests a day. The agent writes all the code. The formulations are beautiful. Worse, none of them explain what exactly a human does during that 99% of the time and what happens when the process isn't well-established.

At the end of the previous article, I listed the breakdown of my workday: sixty percent of time goes to task formulation and context gathering, thirty to result verification, ten to process supervision. Zero to writing code. The numbers are subjective, based on my own practice, not claiming universality. But behind them lies a shift that this article explores.

Loss of the Usual Anchor

This part is usually left out of articles about agent-based development: it's uncomfortable and doesn't fit marketing well.

In January 2026, a thread appeared on Hacker News Ask HN: Identity crisis as a software engineer because of AI, gathering around a thousand comments in a day. The wording varies, but the essence is the same: I'm essentially a proxy for Claude Code; the skill I developed for years is devalued; it's like losing a profession while still being in a profession. Developers with ten years of experience describe a feeling of emptiness. Not career-wise, but professionally. Code gets written, the product works, but the moment when you were needed has disappeared from the process.

The first two articles were about the method. But before examining what a human does within this method, it's worth mentioning what usually stays behind the scenes of marketing. Without this, the five skills from the middle will read like a list of responsibilities for a new position. But these aren't positions. This is a reaction to the shift of the very ground beneath an engineer's feet.

For many years, a developer's self-esteem rested on a single ability: to open any file, decipher any line of code, and write from scratch everything that was needed. This isn't just a skill. It's part of who you are. The short definition I write code holds a lot. When the "write" leaves it, an uncomfortable gap remains. You're next to the work, but not inside it.

For me, this period lasted about three weeks. What pulled me out of it wasn't persuasion or self-analysis, but my own metrics, which I started tracking based on weekly results. The percentage of tasks closed on the first attempt increased. The number of defects that surfaced after closure decreased. The time from formulation to a working piece shortened. All of this improved measurably as soon as I stopped writing code simultaneously myself.

Letting go of the habit was uncomfortable: I had to stop opening files just to see what got generated, stop reflexively diving into code when a task got sticky and I wanted to close it quickly with my own hands, and trust the process I had built myself. After a while, the new position stopped feeling like a loss and began to feel like concentration: less energy on mechanics, more on conception. The work is different, and there's no less of it.

So what is the person doing then?

When I say I haven't touched code manually for a year and a half, the first reaction is almost always the same. Okay, but what did you actually do all this time?

The question is honest. By habit, we measure engineering work by hours spent inside code: the more a person sits over lines, the more seriously they seem to work. If they're not sitting over lines, it seems from the outside that there's no work at all.

In fact, there became more of it. Only it's different. It's easier to show this not with reasoning, but with one ordinary working day.

One Working Day

I open the task queue on Sortule. This is my personal project for saving links and notes, where the LLM categorizes them itself and can search by meaning. Since the evening, there's been a user complaint: a VK post with a carousel saves only one photo. A person forwarded a VKontakte post from a wall with four photos into Sortule's VK bot, but only one is visible in the interface.

By old standards, this would take half an hour to an hour: dive into VK's normalizer, find where attachments are parsed, and fix the obvious bug.

I start not with code. The first item in the task specification says: reproduce on dev. I forward the same post to a local bot, check the database, and see something strange. VK sent all four photos, the normalizer parsed them correctly, the background worker downloaded all four. The code ran cleanly. And yet, four records in the media files table point to the same path in storage.

Without the first reproduce step, I would have gone to fix the normalizer, because the task was formulated as a bug in the VK integration. The agent would have done exactly the same, with a perfectly convincing justification and green tests. Two hours wasted, nothing fixed, because the problem lives in a different layer.

The real cause turned out to be two floors deeper. The save layer built the filename from the bookmark identifier: for one photo that was enough, for four the same name repeated four times. Storage, receiving the same key, silently overwrote the previous file, leaving only the last one. Four records in the database pointed to one real file. On top lay a second, independent bug: the normalizer didn't set the content type for photos, the frontend filtered attachments in the gallery by the rule starts with image, and VK photos were excluded from the interface even in those rare cases when they did reach storage.

One user task, three layers: normalizer, save layer, frontend. None of the three knew about the other two, and in each layer the bug looked like a plausible part of its own responsibility.

I rewrite the formulation. Now it's not a fix for VK integration, but three subtasks: unique names for carousel files, correct content type in the normalizer, and a separate patch for already broken bookmarks in the production database. Each has its own acceptance criteria and at least one negative scenario. A post with one photo shouldn't create extra records. If the social network API returns an error on enrichment, we don't crash; we use what came in the original notification.

The formulation took about forty minutes. The agent spent twenty minutes on implementation. Ten more for review and test runs. The commit goes to the main branch.

Next is the deployment to production. Here comes another surprise: the build fails on an old, unstable test that sometimes passes and sometimes doesn't, and it's unrelated to my task. Skipping the check or rolling back are not great options. So, I do a third thing: manually take the exact tag of the fresh image, update the manifest on the server, and go through the usual deployment cycle. Eighteen containers come up healthy.

And then, the third surprise of the day. The additional data fetch for a broken bookmark doesn't work, the task goes into the queue, and there's silence in the logs. I check the configuration: the queue it's in isn't being listened to by any worker. For the new module, they forgot to set up the route. A quick fix would take a minute, but this is the third time I've caught the same issue this month. I stop and ask the agent to save a note like gotcha to the project memory. Any background task without an explicit route goes into the default queue, which nobody listens to, and we only find out about it when something breaks in production; when adding a new task, check the route, definitely. Next time someone works on queues, TAUSIK will pop up with this note right next to the task. Then the route is added, the data fetch works, and four photos appear on the bookmark page.

By the time I get up to pour some tea, the clock shows just after five. Twelve tasks are closed for the day: a carousel with two related data fetches, three small fixes from the backlog, one big feature on bookmark expiration reminders, three tests, and two notes in project memory. Not a single line of code written by hand.

I've never had such density in the old model: every forty to fifty minutes, a finished piece is ready. It's not a marathon or heroism; it's a steady pace forward without jerks.

You get tired differently. Not from typing a lot, but from holding the product, architecture, task requirements, boundaries, and areas the agent shouldn't touch in your head all day. By evening, your head hurts, not your back.

And there's one thing I didn't allow myself to say out loud at first. In the classical model, where a team of people stands between an idea and a working piece of code, twelve tasks a day are fundamentally impossible. Specification, implementation, review, return for revision: the same volume would be stretched over three weeks. Not because developers are slow, but because everything that previously slowed down the cycle has been removed from it: approvals, waiting, misunderstandings between minds. All that cognitive resource that previously went into managing people and trying to maintain context between meetings now goes where it's needed. To architecture, to product solutions, to accepting the result.

Not a prompt engineer

It's worth separately stating what a person in this model does *not* become. They do not become a prompt engineer, not in the sense of a profession, but in the sense of a meme in the Russian-speaking IT community, under which today walks every second person who has written a coherent "make a landing page" or "write a Python script" in ChatGPT a couple of times. The very phrase makes one shudder correctly. Formulating a request coherently is a skill, not a profession, and certainly not engineering work. The engineering work in this craft isn't visible at all.

From this easy substitution of words grows a convenient conclusion: since it's all about prompts, accumulated experience isn't needed, the barrier has dropped, the market can be stormed after a three-day course. The picture is simultaneously one of the most replicated in media and one of the most harmful in its consequences.

In practice, it's the opposite. Adi Osmani from the Google Chrome team published an essay in December 2024, which then spread throughout the industry as The 70% problem: AI confidently closes 70% of the task, and it is precisely this confidence that is dangerous. The remaining 30% are not leftovers; they are architectural decisions, negative scenarios, and system connections that cannot be delegated. The more complex the project, the more engineering work falls on the person; it's just that this work is of a different kind.

The data confirms it's tougher. In the report 2025 GenAI Code Security Report, Veracode tested over a hundred models on 80 tasks with known vulnerability classes: in 45% of cases, AI code had a security hole. Models defended against XSS and log injection in 14% and 12% of cases, respectively. Not because the models are bad: they lack product context, decision history, and understanding of what should not be done. This context is maintained by humans. If it's absent, tests are green, but the vulnerability exists.

That day with twelve tasks was possible not because I was good at formulating prompts. It was possible because I had years of experience with architecture and products. Knowledge of when a flat model is better than a hierarchical one. Understanding that a negative scenario is more important than a positive one. Habit of limiting the scope of changes.

Without this foundation, the same tasks would produce twelve formally working solutions, half of which would contain architectural mines.

There's a common analogy: the human as manager, the agent as executor. It's convenient but inaccurate. Traditionally, a manager doesn't need to understand the code they manage. In fully agent-driven development, this isn't an option. If a person doesn't read what the agent generates, they'll overlook architectural errors and a false sense of confidence in the outcome. You don't have to write code. You must read it.

In nature, this is the role of an architect or tech lead in a living team: decide what to build, set boundaries, accept the result, own the whole. Only meetings and code reviews have been replaced by specifications and quality gates, and the human team has been replaced by an agent that you re-contextualize each time and that never argues. As it turns out, silent agreement can be more dangerous than a person who always argues.

Five skills that define the new role

In a year and a half, I went through over thirty projects. The list below came together not from best practices, but from spots where projects consistently had issues: sometimes in the specification, sometimes in the context, sometimes in a forgotten negative scenario. By the eighth or ninth project, it was clear that these were the same five points. Skip even one, and the outcome suffers.

Decomposition

A large task for an agent is almost always a bad task. Not because the model is weak, but because in a large task there are too many hidden dependencies, unspoken decisions, and places where you need to understand for yourself what was meant.

A large task that I tried to give in its entirety always came back the same way: a beautiful, formally working result, lacking half of the nuances that make the function useful. On Sortule, this happened with the chat for bookmarks, with reminders about link expiration dates, and with the tagging system. The agent honestly implements the most direct scenario, the one that is read literally from the formulation. Everything else that I held in my head and forgot to articulate does not make it into the implementation. Not because the agent is lazy: it simply has nothing to hold on to. The difference from a live developer is exactly in this. A developer, seeing an unspoken assumption, will ask a question. The agent fills in the unspoken assumption itself, and fills it in incorrectly.

Decomposition here is not about cutting things into small pieces; it is about how to make each part understandable, limited, and verifiable. A bad task, cut into ten parts, yields ten bad subtasks. Good decomposition has a different sign: each part has clear inputs, outputs, and a criterion by which one can say done.

One sign by which I learned to distinguish good decomposition from bad: if, when describing a subtask, you have to write taking into account that in the neighboring subtask such and such will be done, it means the boundaries are drawn incorrectly. The subtask should be autonomous.

Context Assembly

Context here is not about giving the agent more files. It is about selecting exactly the information needed for a specific task and removing everything superfluous.

The phrase "reset password" for a human sounds like a working starting point. For an agent, it's a lottery. Without clear criteria, it will write a positive scenario and stop. It won't add a negative one (e.g., to return the same response to a request with a non-existent address as to an existing one, so that one can't find out who's registered in the system by brute force) unless it's recorded.

A classic situation: six tests, all green, and a security hole gaping wide, because neither the task nor the criteria described a scenario that closes it. This error is not the agent's fault, but the one who set the task. From such errors, the rule that now enters the SENAR quality gate grew: a task is not taken up until it has a recorded goal, acceptance criteria, and at least one negative scenario.

Again, data from the same Veracode report: AI models failed to protect code from XSS in 86% of cases, from log injection in 88%. Not because they can't. Because nobody wrote it in the criteria.

Diagnosing Systemic Failures

The most non-obvious skill. Being able to distinguish "there's a bug here" from "the task setup system is structured in a way that will regularly spawn such bugs".

On Sortula, three consecutive tasks on new web methods broke in the same way: the client received an unexpected redirect due to a minor discrepancy in the address format. The agent each time carefully corrected the specific handler and closed the task. The temptation was understandable: to fix it again and move on. Instead, I sat down and analyzed the cause. In the project's architectural context, there was no single rule regarding the address format. Five minutes for one record. After that, edits for this class of tasks came to zero.

At the moment, it seemed that three quick fixes were more cost-effective than five minutes for a record. In reality, these were three lost signals about a systemic flaw. It's exactly here that the line between "using an AI agent for coding" and "building a code production system" is drawn. The first can be mastered by anyone who can clearly ask. The second requires an engineer.

Why Manual Editing is a Bad Reflex

One of the strongest reflexes of the old model: if something is wrong, quickly fix it by hand. In regular development, this is often the best path. In a mode where an agent writes all the code, this reflex starts to harm from two sides at once.

The first side is obvious. If a person regularly fixes things for the agent, it means something is wrong in the task setting and context collection system, and this disorder won't fix itself until it's noticed. Every manual fix in such a model turns into a signal.

The second side is less obvious; I ran into it several times before I understood. The agent remembers what it generated itself, but doesn't remember your quiet fix over its code. Fixed silently, didn't announce it, and in the next task, the agent again relies on its previous version, as if the fix never happened. On the second or third iteration, a strange micro-conflict arises: I fix, the agent overwrites mine, I fix again. This is solved by one habit: accompany every manual fix with a short remark to the agent about what was changed and why. A couple of sentences that get into the project memory and won't throw it off again.

In the second article, I talked about the MIR metric, which is the share of tasks that required manual fixing after the agent's work. The point is not for MIR to be zero. Zero MIR means one of two things: either lying or working only with trivial tasks. The point is to notice every manual fix.

Suppose the agent generated a solution with an architectural error. The fastest path: go into the code and fix it. After that, a non-working production system remains. A locally good result is obtained, but the reason why the system produced a bad variant is not eliminated.

I'll show with an example. On one of the projects (cadastral utilities, processing data on land plots), the agent made an error in the formula when generating coordinate recalculation functions. The error gave a deviation of several centimeters, which for surveying is half of the allowable accuracy budget. Noticed, fixed by hand, moved on. After three days, when checking another module, I found the same error in two more utilities out of eleven: the agent used the same incorrect pattern everywhere where coordinate recalculation was required.

It would be more correct to figure out right away why the error occurred. The project context lacked descriptions of the recalculation formulas and the required accuracy. The agent reconstructed the formula from publicly available data, plausibly, but with an error in the coefficient. A single record in the context with the correct formulas would have prevented all three errors at once.

In the first month on Sortule, MIR was around twenty percent. I analyzed every case: why the agent missed, what was wrong in the specification or context. After a month, when architectural context accumulated, MIR dropped to five to seven percent on backend tasks. Not because the model became smarter. Because the environment in which it operated became more accurate.

For me, this is the line of integrity. If a person regularly writes and fixes code themselves, it means either the system hasn't been assembled yet, or their own rules are violated. Both options mean one thing: fix the system, not the code.

How the new role feels from the inside

From the outside, such work might seem easier: no need to spend hours over syntax, debug line by line, manually assemble implementation fragments. This model has its own weight.

You have to keep several layers in mind simultaneously: the product, architecture, task formulation, agent constraints. See the type of error behind a specific bug, and behind the error type, the process that regularly produces these errors. And each time catch yourself on the temptation to quickly fix it by hand and forget.

Review turns out to be the bottleneck of the entire system. Automatic tests, linters, type checking catch syntactic and stylistic errors. But they don't catch the main thing: whether the task is solved substantively and whether the generated code violates the architectural intent that exists only in a person's head. No linter will catch a logical error in a business rule. Only a person will.

Review requires a different type of concentration. Not creative, but critical: you're not building a solution, you're looking for cracks in it. This exhausts faster than writing code. By the fifth hour, it seems you're checking quickly and accurately. In reality, you start to miss things.

And the last, unpleasant part. If the result is bad, nine times out of ten the agent is not to blame. My system of working with them is at fault: somewhere a gap in the specification, somewhere a hole in the context, somewhere an acceptance criterion I missed. The stance is strict towards oneself. But only from such a stance does development with agents turn into engineering practice.

Closer to the Product

In classical development, five floors stand between the concept and the working product: requirements, analytics, design, implementation, testing. On each floor, something is lost, distorted, or added. Weeks and sprints pass from idea to code.

In this model, almost none of those floors remain. Between the concept and the working code stands only the agent, and nothing else. The decision on how the product is structured turns into a working module in minutes. Feedback is instant: you set the task, get it, look at it, reformulate.

In the cadastral utilities project, this was especially noticeable. The subject area is complex: the file formats of GKN and EGRN have historically been different, borderline cases at every step. To test a hypothesis about data structure, you previously had to assign a task to a developer, wait for implementation, discover the hypothesis was wrong, go back. The cycle took from hours to days. Here, the same cycle took fifteen to twenty minutes. Not because the agent is faster than a developer. Because coordination between people has been removed from the cycle.

It does not follow from this that one person with an agent is generally better than a team. A team has what a lone person does not: other eyes for review, collective experience, distribution of responsibility. But for a specific class of tasks where one person understands the subject area well and masters the architecture, the short distance from concept to result becomes a decisive advantage.

Where I Am Not Sure

All of the above is the experience of one person with a specific baggage. Not an excuse, but a description of the boundaries of applicability: where my experience ends, honest I don't know begins.

The most painful open-ended question: gradual degradation of architecture. Each individual task is done correctly. But after fifty or so tasks, a module that started as a thin, neat layer becomes overgrown with logic. Boundaries become blurred. The agent has no sense of the module as a whole; it only sees the task it was just given. I am trying to address part of this problem with the standard and framework that Vadim Soglayev and I are currently assembling: SENAR describes regular architectural review as a mandatory step in the process, not an optional one; TAUSIK embeds this step into the working cycle. This slows the drift but does not eliminate it completely. Every two or three weeks, I still sit down and review the architecture from a fresh perspective. This remains the only thing that actually holds it together.

The second question: scale. Everything I described was built in a mode where one person works on a project. How does this role function in a team of ten engineers, where each manages agents? There is still little open data on how fully agent-based development scales to teams of this size. I don't know. A one- to two-year horizon. The industry is figuring this out right now.

The third: beginners. The five skills I described all rely on accumulated experience. The ability to decompose a task so that the agent doesn't over-engineer comes only as a consequence of hundreds of tasks given by real people. The ability to design architectural boundaries arises from years of observing how boundaries become blurred in real projects. Can these skills be cultivated without a traditional manual phase? An unanswered question. Mathematics is still taught without calculators; perhaps this is not by accident.

The fourth: not all task types are equally amenable to this model. On the backend, the described approach works well. On tasks involving interfaces and product feel, it's worse. On Sortule, I spent two evenings formalizing *the button must feel responsive*: animation parameters, delays, a page and a half of text. The agent implemented it flawlessly to specification. Subjectively, it wasn't right. I reworked it three times. My first-attempt success rate on UI tasks is consistently lower: thirty to forty percent versus seventy-five to eighty on the backend.

It's worth knowing the boundaries because it's within them that an honest understanding of the model is formed. Without boundaries, all that's left is marketing.

If you take away one idea from the article

A person in fully agent-driven development mode is not a programmer who has stopped writing code. It's someone who maintains the framework: task setting, decomposition, context, boundaries, criteria, and is responsible for ensuring that this entire machine continues to produce usable code.

Less manual coding work. More engineering design of the process within which this code is produced.

The five skills I described (decomposition, context, architectural boundaries, acceptance criteria, fault diagnosis) eventually stopped being a set of personal habits. They formed a system. And what always happens to a system based on personal discipline happened: by the thirty-first task of the week, discipline began to wane. The tests are green, next.

When I noticed this, it became clear that personal skills were not enough. An external contour is needed to prevent skipping a step, even when tired. Throughout the article, I've already referred several times to the pair that Vadim Soglaev and I are assembling precisely for this purpose: the SENAR standard and the TAUSIK framework. The standard describes how the engineering discipline of working with agents should be structured: task specification format, context layers with relevance rules, architectural boundaries as a mandatory section, acceptance criteria as an input condition, fault diagnosis through MIR and FPSR metrics. The framework integrates all this into the work cycle: project memory with typed records, task settings, quality gates that prevent closing a task without meeting the criteria.

In the next article, I'll break down how this external contour is structured from the inside: specification, quality gates, metrics. Not as a set of recommendations, but as a mandatory step that cannot be skipped even on a Friday evening. More details about the standard can be found at senar.tech.

Glossary of Terms

Terms that appear or gain new meaning in this article. Basic definitions (SENAR, TAUSIK, MIR, FPSR, task specification, quality gates) are given in the dictionaries of the first and second articles.

Decomposition. Breaking down a large task into parts, each of which is autonomous, has clear inputs and outputs, and can be verified independently. In agentic engineering, the quality of decomposition determines the outcome more strongly than the choice of model.

Context in agentic engineering. Structured information that a person conveys to an agent along with the task: architectural decisions, conventions, module boundaries, records of dead ends. Not to dump more files, but to select exactly what is needed for the specific task.

Architectural boundaries. Explicitly stated constraints: which modules depend on each other, which should not intersect, and why. Without them, the agent optimizes locally and may violate system integrity without breaking any tests.

Fully agentic development (in English-language practice, 100% AI coding). A mode of operation where all code is created by AI agents, and a human manages the process: sets tasks, gathers context, verifies the result, and is responsible for the whole.

Agentic engineering. A term by Andrej Karpathy (2026): a mode of operation where the engineer does not write code directly but orchestrates agents and provides oversight. SENAR is an attempt to formalize how exactly this oversight should be structured.