Articles // ai

Agentic Development: A Personal Experience

Sergey Grachev
published: ⏰ 25
article image

A spontaneous article on agentic development, written after some time and attempts at using this approach. Below are general theses, some of which I probably already touched on about a year ago. Overall, things turned out as expected. There was no revolution, and the bubble is deflating here and there, even though everyone pretends everything is “on plan”. The promised AGI, for some reason, still hasn’t taken over the world :)

Here there will be no recommendations for specific tools, models, and so on. All of this is constantly changing, and it takes time for open solutions to emerge as leaders while the rest die out for natural reasons. It is important to understand that this is personal, subjective experience, and I may have simply forgotten some of the quirks and problems, because there was a lot. A separate topic – team work – is also not covered here.

TL;DR

  • Always explicitly require the use of up-to-date information from the internet: current libraries, approaches, architectures, and so on. The agent uses data from the point in time it was trained on, which almost never matches the current state of things. The exception – basic algorithms and approaches that have been established over decades and don’t change drastically. If you don’t do this, the agent will use outdated libraries or reinvent the wheel (LLMs love doing that).

  • When porting or migrating, always explicitly state that reference code or data should be used as an example of functionality, not as instructions to follow. Do not port one-to-one. LLMs don’t think in abstractions and don’t hold the entire project in context. They will try to replicate the original literally, even at the expense of architecture and code or documentation quality. The same applies to compatibility: LLMs will try to preserve it even when it is not needed and there are far better solutions and approaches.

  • Agents don’t remember past tasks or what was done. The result is constant duplication of code, functions, and documentation. This also includes the inability to fit the entire project into context. Without additional mechanisms/plugins for persistent memory, sessions are not connected to each other at all. To avoid duplication, the agent must remember the context of the entire project, which is impossible without additional mechanisms. Compression when reaching the context limit doesn’t help either, because it is lossy.

  • Compression when reaching the context limit loses important information and requires re-reading data and code. Often breaks the process. Similar to the previous problem, but within the local context of a session. Can be solved with persistent memory or plugins that compress reasoning steps and tool calls to save context, at the cost of increased token consumption.

  • Using the same model for different agents degrades reasoning and task formulation. A single model (or one from the same provider) of the same generation tends to make the same wrong assumptions or inferences. A second agent will most often agree with them. Using different models from different providers noticeably improves the situation, as it introduces more variety into reasoning and adds new solution approaches.

  • The workflow should consist of several specialized agents with their own instructions and constraints. This allows each agent to be more focused on its domain and task. An all-in-one agent tends to “make things easier” for itself by introducing workarounds or simplifying the task at the expense of correctness and optimality. On top of that, context compression has a very strong impact, leading to overall degradation of the result.

  • Full-fledged work requires prior tuning and setup of the agent harness: skills, tools, MCP, agent instructions, and so on. The tooling around agentic development heavily influences the final quality. Without it, even a strong model will make mistakes on medium/small projects. The tooling must always be selected to fit a specific project or domain.

  • Different types of agents require the right model choice. The claim that with the right harness the model doesn’t matter much – is a lie. The model very strongly influences agent behavior and the result, especially in complex scenarios. First and foremost, this concerns orchestrator agents and planning agents. For them, the smartest possible model with a large context should be used – one that doesn’t lose focus during multi-step reasoning and agent invocations. Other models can be simpler, as they perform narrow tasks within a limited domain and context. Most often, this is said by people who are “selling” their own platforms (IDP).

  • Giving agents tasks like “just do this well” – doesn’t work. As mentioned above, LLMs are very sensitive to task formulation. In most cases, a prompt is an order to execute: if some details are not specified, they will be invented and adjusted to fit the main prompt. The result is almost always suboptimal. Therefore, task specification should be as precise as possible: the problem, dependencies, constraints, acceptance criteria, expected outputs, past revisions.

  • Using SpecKit, OpenSpec, BMAD in their pure form is not required and not always effective. These frameworks, like SDD itself, are more of a recommendation and a starting point for adapting AI-assisted workflows. None of these approaches is a silver bullet that will deliver even just a good result on its own. Often it is simply overcomplication. You need to run pilot implementations, selecting the right framework or adapting/developing your own (which is not that hard in reality)

  • If you are working with UI/UX, you will need VLMs. The model must “see” what it produces in order to fix or refine it. Otherwise it switches to workarounds – DOM analysis, pixel-level image inspection, and so on. Workarounds noticeably complicate the task and lead to poor-quality results.

  • For large codebases, grep, rg, glob, read tools are not enough. A clarification is needed here: this mainly applies to models with small context. Models with 1M context can handle large amounts of data, although they lose focus. Otherwise, additional tools like graph RAG with MCP are needed, so the model can quickly find the data it needs without re-reading half the project.

  • High token consumption. A natural problem if persistent memory between sessions and project indexes are not used. Additionally, skills with instructions can be used to reduce the model’s “wordiness”.

  • Low quality of generated solutions. Junior/middle/senior + LLM replaces a team and delivers a good result – this is not true. The main problem is that LLMs produce not the best and not always correct solutions, but an average or often bad result. Without enough experience to evaluate – including systems thinking and planning several steps ahead – you can’t catch LLM “mistakes”. That is, the code may work and do its job, but it will contain huge technical debt that you will pay for later. The final cost of the project may turn out no cheaper than manual development. The survivorship bias of small one-day projects is not worth factoring in.

    This conclusion is based not on theory, but on the practice of development and porting applications (table below) to unfamiliar languages and ecosystems. Without long past experience of development in different languages and manually debugging problems, most incorrect LLM suggestions and solutions simply would have gone unnoticed. And even now, many of them remain in the code: understanding that something is wrong comes only with experience working in a new language.

  • LLMs accumulate errors, leading to a compounding error effect. Even a small inaccuracy at an early step of code generation becomes “truth” for the next iteration. The model relies on its own generated incorrect code and facts as a baseline pattern. The result is complete degradation of logic in code or documentation without manual control.
    Agentic development without a human simply delivers poor results. The hype around, for example, AI platforms and human-free development (specification only – intent) looks like snake oil and/or self-promotion by IT companies trying to sell themselves and their products.

  • Quality development with LLMs ultimately costs more in resources and time. This is a cumulative effect of all the previous problems. After implementing LLMs in the process, it may turn out that achieving the result that professional employees delivered is comparable to, or often more expensive than, using LLMs, oddly enough. There is nothing to recommend here but a reasonable approach to implementation; some people simply have to experience all the problems themselves to understand how to properly integrate AI into processes.

  • Stagnation and degradation of professional skills. This topic is currently debated, and it needs to be viewed on a 1–2 year horizon. It is obvious that it is already physically impossible to review such volumes of AI slop. And if you multiply that by natural human laziness, it often comes down to console operators with an LLM.

Knowledge and context

Up-to-date information from current sources

Always explicitly require the use of up-to-date information from the internet: current libraries, approaches, architectures, and so on.

A model is trained on a snapshot of the internet, and that snapshot almost always lags behind the current state of the ecosystem. As a result, the agent either pulls outdated library versions or, worse, makes things up. The problem is not hypothetical: the “Importing Phantoms” study (arXiv 2501.19012) showed that LLMs systematically hallucinate non-existent packages, and a separate empirical study (fabriziosalmi) found 1000 verified non-existent packages committed to public repositories. In other words, the agent confidently writes an import or a library, and the build fails – and this is exactly the case where an LLM’s reinvented wheel is not the worst outcome.

What can be done about it:

  • explicitly state in the agent’s instructions (AGENTS.md, rules): before using an external dependency, verify its existence and current version via web search or the package registry;
  • enable web search and documentation-reading tools by default for tasks involving external APIs and libraries;
  • pin the project’s stack versions in the instructions so the model doesn’t “upgrade” versions mid-task;

Large codebases

For large codebases, grep, rg, glob, read tools are not enough.

On small projects, sequential searching via grep/rg/glob/read is enough: the agent finds a file, reads it, and continues. On large codebases this approach breaks down: the agent either re-reads half the project or works without the needed context and produces solutions by guessing.

An important clarification here: this mainly applies to models with small context. Models with 1M context can indeed handle large volumes, but “fits” doesn’t mean “is used”. The Chroma “Context Rot” study (2025) ran 18 LLMs and showed: without exception, all of them degrade as input context grows, and the 10,000th token is processed worse than the 100th. NVIDIA’s RULER (arXiv 2404.06654) confirms: models’ actual useful context is significantly smaller than advertised.

Working options:

  • graph RAG via MCP: an index of the project structure (modules, dependencies, key entities) that the agent navigates with pinpoint queries instead of re-reading files;
  • project-level persistent memory (AGENTS.md, module notes) that the agent updates as it works – context is loaded when needed;
  • task decomposition so that the context of each subtask fits within the model’s “working” range rather than its theoretical maximum.

Memory and sessions

Agents don’t remember past tasks

Agents don’t remember past tasks or what was done. The result is constant duplication of code, functions, and documentation. This also includes the inability to fit the entire project into context.

Each agent session starts from a blank slate: it doesn’t know what was done last time. Without additional mechanisms, sessions are not connected to each other at all, and to avoid duplication the agent must remember the context of the entire project.

At the codebase level, this is visible in GitClear’s data (211 million lines, 2020–2024): a spike in duplicated code blocks, an increase in short-lived code changes, and a continuing decline in code reuse – code written last week is rewritten this week.

Persistent memory became a standard feature in 2025–2026. Claude has memory – plain files that the agent reads and writes itself (documentation), plus team memory. A separate branch: various auxiliary layers like Letta (MemGPT), Mem0, Zep, LangMem, and so on.

An important nuance: memory should be transparent – files that can be read and edited by hand, not a black box. Then the agent maintains it as working documentation, and the duplication problem is solved at the process level.

Context compression loses information

Compression when reaching the context limit loses important information and requires re-reading data and code. Often breaks the process.

A similar problem, but within the local context of a single session. When the agent approaches the context limit, compression begins – summarization of what happened. It is lossy compression: important details, decisions made, and intermediate conclusions are lost, and the agent starts re-reading data and code, or simply breaks the process.

“Context Rot” (Chroma) is also relevant. All models degrade as context grows, so “let’s just increase the context” doesn’t save you. Anthropic describes this mechanism directly in its multi-agent systems research. For contexts longer than 200K tokens, the task plan is saved to external memory so the agent doesn’t lose its direction after compression (anthropic.com).

Solutions:

  • persistent memory: the agent writes key decisions and task state to files as it works, instead of keeping them “in its head”;
  • plugins that compress reasoning steps and tool calls – this saves context but increases token consumption, so it is the price of session length;
  • decomposition: split a long task into stages with explicit checkpoints, so each stage starts with a clean but prepared context.

High token consumption

High token consumption.

This is not a standalone problem, but a consequence of the two previous ones: without persistent memory, the agent re-reads the same files in every session; without project indexes, it re-discovers the structure from scratch; without compression control, it gets stuck in re-reading loops.

Anthropic showed the scale of consumption in the same study: token spend explains about 80% of the variance in results, agents consume about 4x more tokens than chat, and multi-agent systems – 15x. The “agentic” way of working is objectively more expensive per unit of task, and without optimizations the token bill grows faster than productivity.

What reduces consumption:

  • persistent memory between sessions and project indexes – fewer repeated reads;
  • skills with instructions that reduce the model’s “wordiness”: a clear answer format, a ban on restating source code, limits on output volume;
  • caching of system instructions;
  • an honest choice of model for the role, since narrow executors don’t need the most expensive model.

Agent architecture

One model for all agents

Using the same model for different agents degrades reasoning and task formulation.

A single model (or one from the same provider) of the same generation tends to make the same wrong assumptions or inferences. If a second agent with the same model looks at the first agent’s result, it will most often agree with those assumptions – errors correlate. Different models from different providers introduce variety into reasoning and add new solution approaches.

Cognition’s article “Don’t Build Multi-Agents” (June 2025) is about exactly this scenario: parallel agents sharing context make the same mistakes, and the result is fragile. The MAST study “Why Do Multi-Agent LLM Systems Fail?” (arXiv 2503.13657, NeurIPS 2025), based on 1600+ annotated traces from 7 frameworks, showed that the gain from multi-agent systems on benchmarks is often minimal, and coordination itself – is a new class of failures.

On the other hand, different model assignments by role work. In Anthropic’s research, a lead agent (Opus 4) with subagents (Sonnet 4) performed 90.2% better than a single Opus 4 on research tasks.

Specialized agents and areas of responsibility

The workflow should consist of several specialized agents with their own instructions and constraints.

Here it is important to distinguish two things that are usually lumped together in the single word “multi-agentic”.

Parallel “writers” – this is a problem. Several agents writing code simultaneously in the same space are fragile: change conflicts, identical errors, incompatible decisions. Cognition stated this explicitly in 2025 – “Don’t Build Multi-Agents” – and MAST, based on agent work traces, showed that coordination – is an independent source of failures.

Separation of areas of responsibility – this is the solution. Orchestrator, executor, reviewer – each with its own instructions and constraints and a narrow domain. An all-in-one agent tends to “simplify” its task by introducing workarounds or making it easier at the expense of correctness and optimality, while specialization removes this pressure.

There is more evidence for the second interpretation. The paper “United Minds or Isolated Agents?” (arXiv 2506.06843) shows that LLMs have a performance ceiling on complex multi-faceted tasks and that heavy context engineering exceeds the effective attention budget – which is a direct analogy to cognitive overload theory. An all-in-one agent gets cognitively overloaded, while roles with a narrow area of responsibility reduce the load and raise quality. Anthropic builds its research system on exactly this separation of concerns – each subagent has its own context and its own task. And in Cognition’s 2026 study (“Multi-Agents: What’s Actually Working”), they acknowledge that a narrow class of tasks works, following the formula “intelligent processing – in parallel, editing – single-threaded”. For example, a review agent with a clean context (without the shared task context) catches an average of 2 bugs per PR, 58% of them critical – the best result precisely without a shared context (cognition.com).

That is: parallel code writing by several agents – is a problem. Role specialization with separation of areas of responsibility – is the solution, and it reduces the cognitive load on each agent.

Model selection by role

Different types of agents require the right model choice. The claim that with the right harness the model doesn’t matter much – is a lie.

The model very strongly influences agent behavior and the result. First and foremost, this concerns orchestrator agents and planning agents. For them, the smartest possible model with a large context is needed – one that doesn’t lose focus during multi-step reasoning and agent invocations. Other models can be simpler, as they perform narrow tasks within a limited domain and context.

The opposite thesis – “the right harness matters more than the model” – is actively promoted. One example is “AI-Disrupt PDLC” (ЦИПР-2026, ai-pdlc.com): 98/2 – 98% of the pipeline’s engineering value comes from the deterministic harness (permission gates, recovery, evals, audit, context management, tool routing), and only ~2% from the model. But this is their specific document with a product showcase (an in-house platform: Agent Runtime, Agent Marketplace, Context Supply Chain), and the breakdown on Habr (23.05.2026) assesses 98/2 as “engineering rhetoric, not a measurable metric”. That is, the facts are fitted to a thesis that sells the platform. It sounds convincing, but can’t be verified – classic snake oil.

Counter-facts in favor of “the model matters” are concrete:

  • Anthropic notes in the same study: a model upgrade delivers a bigger gain than doubling token consumption;
  • mini-SWE-agent (100 lines of Python) with a strong model achieved 65% on SWE-bench Verified (July 2025) – a minimal harness, a top-level result;
  • on SWE-bench in 2025–2026, the gap between top and mid-tier models remains significant – new evaluations from CodeClash (November 2025) and ProgramBench (May 2026) confirm this.

Conclusion: a correct harness does not compensate for a weak model. For the orchestrator and planner, the model is critical; the harness – for executors. Both layers matter, but the weight of the model is higher than its platform vendors paint it. I have also seen this very well in my own development: the difference between models can be radical.

Task specification

“Just do it well” doesn’t work

Giving agents tasks like “just do this well” – doesn’t work.

And this is probably the most common way to get burned by agentic development. A prompt for an LLM – is an order to execute. Anything not specified, the model will invent and adjust to fit the main prompt. The result is almost always suboptimal, because the “invented” part is an average over training data, not what the project needs.

Therefore, task specification should be as precise as possible:

  • the problem – what exactly is wrong and what result is expected;
  • dependencies – what already exists, what to rely on, what must not be touched;
  • constraints – stack, versions, architectural decisions, style;
  • acceptance criteria – how to verify that the task is done;
  • expected outputs – a concrete artifact, not “improve”;
  • past revisions – what has already been tried and why it was rejected.

The more precise the specification, the less “inventing”, and therefore the less error accumulation further down the chain. This is, in essence, the foundation of SDD approaches, covered in the frameworks section below.

Porting: reference is an example, not an instruction

When porting or migrating, always explicitly state that reference code or data should be used as an example of functionality, not as instructions to follow. Do not port one-to-one.

LLMs don’t think in abstractions and don’t hold the entire project in context, so when porting they try to replicate the original literally – even at the expense of architecture and code quality. Reference code is perceived as instructions, not as an example of functionality. The same applies to compatibility: the model will try to preserve it even where it is not needed and there are far better solutions and approaches.

In practice it looks like this: you port an application to an unfamiliar language and get not “the same application in Rust” but a literal translation – with the original’s architectural flaws, unnecessary compatibility, and the source language’s idioms.

The solution – always state explicitly in the task:

  • reference code and data – are an example of functionality, not instructions to follow;
  • do not port one-to-one; the target architecture and idioms of the target ecosystem take priority;
  • compatibility is preserved only where it is explicitly required;
  • acceptance criteria – based on functionality, not on structural similarity with the original.

Harness

Skills, tools, MCP

Full-fledged work requires prior tuning and setup of the agent harness: skills, tools, MCP, agent instructions, and so on.

The tooling around agentic development heavily influences the final quality, and “out of the box” almost no agent is ready for a specific project. Skills, tools, MCP servers, instructions – all of this needs to be tuned and configured for the domain before handing over real tasks.

MCP itself has stopped being an Anthropic experiment during this time and become an industry standard. In December 2025, the protocol was transferred to the Agentic AI Foundation – directly funded under the Linux Foundation umbrella. By that point, SDKs were being downloaded 97 million times a month, and there were more than 10,000 public MCP servers (announcement).

At the same time, the maturity of adoption varies. According to JetBrains AI Pulse (January 2026, 11,000 developers), 90% use AI at work, but only 22% already use AI coding agents, and only ~25% regularly use agentic tools (official). The gap between “using AI” and “using agents” – is adoption maturity itself, and it is mostly determined by the harness.

Practice:

  • before real tasks – a pilot tuning of the harness on typical project tasks;
  • selecting tools and MCP servers for a specific project or domain, not “everything at once”;
  • agent instructions (AGENTS.md, rules, skills) as part of the codebase: they are reviewed, updated, and live in the repository.

VLM for UI/UX

If you are working with UI/UX, you will need VLMs.

The model must “see” what it produces in order to fix or refine it. Otherwise, the agent switches to workarounds – DOM analysis, “pixel-level” image checks, reading CSS – and this noticeably complicates the task and leads to poor-quality results.

With a VLM (vision-language model), the “generate → look at the screenshot → fix” loop becomes direct: the model sees the render, compares it with expectations, and makes pinpoint fixes. The same works in review: an agent that can look at the result catches defects invisible in the markup.

A separate point – screenshots give a single “source of truth” for iterations. There is no need to keep interface descriptions in the prompt, which quickly become outdated. For frontend tasks, VLMs are built into the harness from the start.

Frameworks

SpecKit, OpenSpec, BMAD – a starting point

Using SpecKit, OpenSpec, BMAD in their pure form is not required and not always effective.

These frameworks, like SDD itself, are more of a recommendation and a starting point for adapting AI-assisted workflows. None of these approaches is a silver bullet that will deliver even just a good result on its own. Often it is simply overcomplication.

All three are alive and evolving in 2026:

  • Spec Kit – a toolkit for SDD development, works with any AI agent;
  • OpenSpec – change tracking for projects, easier to integrate into an existing codebase;
  • BMAD – a multi-agent method with roles and artifacts.

This site already has an article about Spec-Driven Development, which covers the approach itself and its risks.

A practical conclusion: run pilot implementations, selecting the right framework for the size and type of the project. If none fits – adapt or develop your own. It is not that hard in reality. Essentially it is a set of specification templates, agent instructions, and scripts that connect the stages. Your own harness can end up shorter and more precise – it is built for a specific process, not for the “average project”.

Quality and cost

Junior/middle/senior + LLM doesn’t replace a team

Low quality of generated solutions. Junior/middle + LLM replaces a team and delivers a good result – this is not true.

The main problem is that LLMs produce not the best and not always correct solutions, but an average, often bad result. Without enough experience to evaluate – systems thinking, the habit of thinking in abstractions several steps ahead – you can’t catch an LLM on its “mistakes”. That is, the code may work and do its job, but it will contain huge technical debt that you will pay for later. The final cost of the project may turn out no cheaper than manual development.

The perception gap has already been measured. METR ran an RCT in July 2025: 16 experienced OSS developers, 246 tasks, mature codebases – with AI tools they were 19% slower, while they themselves estimated their gain at +20% (metr.org, arXiv 2507.09089). Errors are invisible without experience – and this is the main trap of “Developer + LLM”.

Survey data points in the same direction. Stack Overflow Developer Survey 2025 (49,000 respondents): 84% use or plan to use AI tools, but trust in accuracy – only 3.1%, and the most cautious – are experienced developers: high trust 2.5%, high distrust 20.7% (survey). DORA 2025 notes that AI – is an amplifier: strong teams get a multiplicative effect, weak teams – an aggravation of their problems: 45% save time on code, but 42% spend more on review (dora.dev).

And the most interesting thing – “re-hiring” (CNBC, July 2026). Companies that cut people for AI are starting to reverse their decisions. Ford brought back hundreds of experienced engineers after the quality AI experiment failed (~350 hired, BBC). Commonwealth Bank of Australia reversed the reduction of 40+ operators when the voice bot couldn’t cope. IBM couldn’t handle the remaining 6% of HR requests that AI didn’t close, and will increase hiring 2–3x in 2026. Orgvue: 55% of leaders who cut staff because of AI admit the decision was a mistake. Robert Half: 32% of hiring managers removed a role because of AI and then rehired it (cnbc.com).

For scale: at Google Cloud Next 2026, Sundar Pichai stated that 75% of new code at Google is generated by AI – but with the caveat “approved by engineers”. The human review layer remains, and 75% does not mean “the team was replaced” (blog.google).

This conclusion is based not on theory, but on the practice of development and porting applications (the table below) to unfamiliar languages and ecosystems. Without long past experience of development in different languages and manually debugging problems, most incorrect LLM suggestions and solutions simply would have gone unnoticed. And even now, many of them remain in the code: understanding that something is wrong comes only with experience working in a new language. The survivorship bias of small one-day projects is not worth factoring in.

To give you an idea of the size: the app was written mostly using AI (plus human cleaning) and then ported to Rust.

Text 
───────────────────────────────────────────────────────────────────────────────
Language            Files       Lines    Blanks  Comments       Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                    225      61,086     8,201     3,231     49,654     12,415
TypeScript             56       1,801       164        71      1,566         64
Markdown               42      10,239     2,250         0      7,989          0
MDX                    40       4,862     1,145         0      3,717          0
JSON                   20         663         0         0        663          0
CSS                    19       2,807       399       273      2,135          0
YAML                    7         575        53       110        412          0
SQL                     5         163        21        17        125          3
XML                     5         511        51        80        380          0
Go Template             4         120        19         0        101         14
SVG                     3          34         5         0         29          2
Shell                   2         168        25        30        113         12
Dockerfile              1          43        13        12         18          0
License                 1         202        33         0        169          0
Makefile                1         117        24        16         77          3
Plain Text              1          36         0         0         36          0
───────────────────────────────────────────────────────────────────────────────
Total                 432      83,427    12,403     3,840     67,184     12,513
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $2,239,878
Estimated Schedule Effort (organic) 18.69 months
Estimated People Required (organic) 10.65
───────────────────────────────────────────────────────────────────────────────
Processed 5098527 bytes, 5.099 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

Compounding effect of errors

LLMs accumulate errors, leading to a compounding error effect.

Even a small inaccuracy at an early step of code generation becomes “truth” for the next iteration. The model relies on its own generated incorrect code and facts as a baseline pattern. The result is complete degradation of logic in code or documentation without manual control.

The math is simple – 10 pipeline steps with 95% accuracy each give 0.95^10 ≈ 60% success for the whole pipeline. The MATC study “Multi-Agent Taskforce Collaboration: Self-Correction of Compounding Errors” (arXiv 2508.04306) describes exactly this. Multi-step LLM processes inevitably accumulate errors, and this is partly treatable with explicit self-correction – separate checking agents at stages, rather than one “big run”.

Agentic development without a human simply delivers poor results.

Cost of quality development

Quality development with LLMs ultimately costs more in resources and time.

This is a cumulative effect of all the previous problems: duplication, re-reading, compression, average quality, technical debt. After implementing LLMs in the process, it may turn out that achieving the result that professional employees delivered is comparable to, or often more expensive than, using LLMs, oddly enough.

External data confirms this. DORA 2025: 45% save time on code, but 42% spend more time on review – the savings on generation move to review. Gartner (June 2025) predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 – rising costs, unclear business value, insufficient risk control (press release). The bubble is deflating – this is not an opinion, but an analyst forecast.

There is nothing to recommend here but a reasonable approach to implementation. Some people simply have to experience all the problems themselves to understand how to properly integrate AI into processes.

Skills

Stagnation and degradation of professional skills

Stagnation and degradation of professional skills.

This topic is currently debated, and it needs to be viewed on a 1–2 year horizon. It is obvious that it is already physically impossible to review such volumes of AI slop. And if you multiply that by natural human laziness, it often comes down to console operators with an LLM.

METR RCT (July 2025) – experienced OSS developers (16 people, 246 tasks, mature codebases) were 19% slower with AI tools, while they themselves estimated their gain at +20%. → metr.org, arXiv 2507.09089. Confirms: the perception gap, “errors are invisible without experience”, degradation of skills.

Supporting data already exists. METR: experienced developers with AI tools worked slower but didn’t notice it themselves – the perception gap. If you don’t write code by hand and don’t review it carefully, the ability to tell good code from bad simply atrophies. JetBrains Ecosystem 2025: 11% of developers cite the negative impact of AI on skills as a source of concern. DORA: AI – is an amplifier, and for weak teams it works against them.

Conclusion

One more point. Long ago I went into IT and development because it was interesting, not for the money (a salary of 8–10k was my pay for the first couple of years). One of the important motivators was interesting tasks done with my own hands, while the financial side was a lower priority. With agentic development, the interest in the task and the work seems to fade; probably there is no sense of authorship, and the financial side moves to the forefront. On top of that, there is no sense of ownership of the generated result, and overall it feels like a dreary conveyor with endless attempts to achieve a quality result. It is a strange paradox: agentic development was supposed to make work cheaper, but for cheap, there is just no desire to do it. The financial and career side becomes the priority in this kind of work.

To paraphrase an immortal classic – “Happy debugging after vibe coding, {censored}” :)

Agentic Agents Multi-Agent Llm Ai Genai
Agentic Development 2 of 3
← Spec-Driven Development and last days of frameworks, smart assistants, low/less-code Porting an MCP Server from Go to Rust Using LLMs →