Grigoriy Dobryakov's blog: management, development and testing
The word «must» in «AI can execute, but judgment must stay human» is not a law of nature. It’s a doctrine protecting a comfortable seat.
People often say this as if it were self-evident:
— AI can be an excellent executor, but judgment about the result must stay with a human!
It sounds confident and tidy. And every time I hear it, the same question surfaces: why, exactly, must?
Continue reading “«Judgment Must Stay Human» — Or Are You Just Guarding Your Chair?”
Expert perfectionism isn’t care for quality — it’s a post-traumatic teacher’s role. The customer doesn’t choose AI because it’s smarter. He chooses it because it doesn’t sit him down at a school desk.
"A non-specialist simply doesn't see the mistakes!" they shout at me in chorus. "We, the real specialists, we see the mistakes. So only we should be solving problems — not some humanities graduate with AI in his hands."
For ten years I wrote and defended beautiful code. Now I can admit what it actually was: a tax on future maintenance convenience, billed to the client.
For ten years I wrote beautiful code. Aligned things on shelves, argued about variable names in code review, defended patterns as if a plane would fall out of the sky without them. And I was good at it. That is why it hurts to be the first to say it out loud: almost everything we called "clean code" — patterns, naming rules, tidy architecture — was not engineering necessity. It was a tax. And I was not the one paying it. The client paid it. We paid with ourselves.
Continue reading “Clean Code Was a Tax. We Just Paid It With Ourselves”
One of the most absurd beliefs about AI in software engineering is that the business doesn’t have enough ideas to justify the speed. The reality is uglier.
A common belief I keep hearing is about AI in software engineering is that the speed doesn't matter because the business doesn't have enough ideas to fill the pipeline.
Continue reading “The Business Has No Ideas for AI — No, It Just Gave Up on You”
Code tells an AI agent how the system works today. Specs tell it how the system should work. Without the second layer, the agent cannot tell a bug from a feature.
Suppose an agent can load the whole monorepo into context and generate a correct-looking function. The moment developers see this, some teams conclude: if the agent can read all the code at once, documentation is obsolete. Specifications, architecture descriptions, technical requirements — unnecessary process overhead. Why write text when the agent reads the code directly and sees ground truth?
Code is evidence of the current implementation, not proof of the intended behavior.
Continue reading “Why Documentation Still Matters When the Agent Reads the Code Directly”
Developers are physically merging separate projects into one git repository because they think it helps AI agents read code. It doesn’t. You’re paying a real architectural price for an imaginary benefit.
I ran into a misguided pattern going by the terrifying name "the monorepo." People are seriously merging different projects into a single physical git repository because they think it makes it easier for an agent to "walk the files" and understand the overall context of a large corporate system. Dozens of comments under the post: oh yes, we started doing this too, excellent mechanism, everyone is happy.
This is the wrong abstraction boundary.
Continue reading “The Monorepo Cargo Cult: You Broke Your Architecture for an Illusion”
Eight answer clusters for the questions HR and hiring managers actually ask an AI-driven engineering leader — hands-on proof, team enablement, governance, ROI, org design, and logistics.
Many AI-leadership candidates can present strategy, but fewer can show production artifacts. Hiring managers know this and look for evidence — not by claims alone, but by artifacts: running systems, repositories, evals, and production metrics. Below are direct answers to eight clusters of questions that HR and hiring managers ask about an AI-Driven Head of Engineering profile. Each section states the claim, the supporting evidence, and any limitation.
Sanctions hygiene: the employer-integrator is referenced by the descriptor "large systems integrator" — not by name; the named anchor for public cases is Askona.
Continue reading “AI-Driven Head of Engineering: What to Show HR and the Hiring Manager”
The first wave of AI automated execution. The second wave is coming for managerial judgment — and the corporate rent built on «unique intuition» is about to collapse.
Managers can no longer justify high compensation only by saying their decisions are too complex to formalize.
Continue reading “The Era of Algorithmic Management: The End of «Irreplaceable» Managers”
A reference review for hiring managers: concrete AI practices at each SDLC phase, from requirements elicitation in Jira to LLM-driven production monitoring, with public artifacts and commercial context.
https://www.dobryakov.net/lead-magnets/ai-sdlc-hr-proof.html?utm_source=None&utm_medium=None&utm_campaign=ai-sdlc-hr-proof
Continue reading “AI Across Every Phase of SDLC: Practices, Proofs, and Numbers”
From text generation to autonomous agents — and the emerging protocol stack that makes multi-agent engineering possible.
Since 2022, systems built on large language models have moved from "generate a paragraph" to autonomous agents. In production, an AI agent usually wraps an LLM with tool calls, state, and orchestration. It is an autonomous module that combines three capabilities: planning (breaking a goal into steps), memory (short-term in context, long-term in external stores), and execution (calling APIs, writing files, triggering other services).
In production deployments, teams run into interface fragmentation. The model lives in one place, the tools in another, other agents elsewhere, and the corporate security perimeter somewhere else entirely. All of these must be wired together. The classic formulation of this pain is the N×M problem: connecting N clients to M data sources requires writing N×M unique adapters. Five models and ten tools turn into fifty hand-coded connectors that nobody wants to maintain.
Vendors and open-source projects are proposing several protocol families. Several protocols now target different parts of agent integration — specifications that each take over a specific piece of the wiring: how the model reaches a tool, how an agent lives in time, how two agents negotiate, how data safely crosses the perimeter. Below is a breakdown of ten such protocols and standards, grouped by architectural layer.
Continue reading “The AI Agent Protocol Stack: A Map of the Layers”
