Grigoriy Dobryakov's blog: management, development and testing
The myth that clients can’t use AI as well as you do rests on one assumption: that AI is an extension of your hands. It isn’t. The person who beats you isn’t using it for execution — they’re using it for judgment.
While everyone panics about finding a stable earning strategy in the age of AI — which I haven't seen work reliably yet — I keep running into one assumption I keep seeing. Generalized, it sounds like this:
"The client won't be able to use AI as professionally as a professional. As me."
The weak point in this argument is this: Here is the issue. It depends on one question.
Continue reading “You’re Not Competing With Another Practitioner. You’re Competing With the Model.”
If your AI system needs you to stay for it to work, you haven’t built a tool — you’ve built a dependency. Customers know the difference.
A Professional Builds an Alienable Tool. The Rest Is Rent for Presence ===
I regularly get told why AI projects need a specific person attached to them. You have to know the nuances. You have to check the model's answers. You have to understand the domain. The conclusion is presented as obvious: every AI system needs a knowledgeable engineer permanently attached, and that participation is necessary.
I'll be honest with you — don't take it personally: in nine cases out of ten, "necessary participation" is not about engineering. It is about who collects a fee for being present.
Continue reading “A Professional Builds an Alienable Tool. The Rest Is Rent for Presence”
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”
