The Illusion of Degradation: Why Falling Exam Scores Are a Verdict on Schools, Not Students

A 20% drop in proctored exam scores is not digital dementia. It is the academic system’s public confession that it measures a skill the market has already devalued.

Education conservatives have found their culprit. The statistics are unforgiving: students who use neural networks for homework and study aids score on average 20% worse on proctored exams without gadgets than previous generations. The system's reaction was predictable: outrage over "digital dementia," calls to ban generative AI outright, and a push for stricter proctoring.

Continue reading “The Illusion of Degradation: Why Falling Exam Scores Are a Verdict on Schools, Not Students”

AI Is Eating Billable Hours. Most Firms Are Defending the Wrong Trench.

Faster code is table stakes. Margin and outcomes are decided one floor up — on the management layer where no one is pointing AI budget.

Every consulting and IT-services shop just got the same memo: AI writes code faster, so bill less time or sell outcomes instead. McKinsey already tied a quarter of its fees to results — the Acorn Plan. The billable hour is dying, and everyone knows it.

So the whole industry is sprinting to the same finish line: certify the engineers, plug in the copilots, ship code faster. Here's the uncomfortable part. That race is already over, and winning it buys you nothing.

Continue reading “AI Is Eating Billable Hours. Most Firms Are Defending the Wrong Trench.”

“The customer can’t write a production-ready spec” — the customer doesn’t have to. The model writes the spec itself.

Seventeen people wrote me this week to say AI in a customer’s hands is useless because the customer can’t formulate a production-ready spec. They missed one thing: the customer doesn’t have to. The model formalizes the spec itself.

Seventeen people wrote me this week to say the same thing: AI in a customer's hands won't produce results, because the customer is incapable of formulating a production-ready task specification. Seventeen adults among my active subscribers couldn't reason their way to the one thing that collapses their entire argument in a single move.

Continue reading ““The customer can’t write a production-ready spec” — the customer doesn’t have to. The model writes the spec itself.”

‘AI Code Needs Human Review’ — And That’s a Diagnosis of Your Manager

The manager who insists on eyeballing every line of AI-generated code has built a production critical path that runs through one specific person who might call in sick tomorrow.


# "AI Code Needs Human Review" — And That's a Diagnosis of Your Manager

There is a popular assertion that code and scripts generated by a model must be reviewed manually — a human eyeballing every line the model produced. It sounds like common sense, like responsibility, like mature engineering culture.

Stop for a second. The assertion is insane. It makes working with AI slower and more pointless. Why use a model at all if you still need to attach an engineer to it — like a worker bolted to a machine? AI was invented to replace the engineer, not to slow the engineer down further.

<!--more-->

And the problem is not speed. The problem is whose bet you are making when you say this.

## Who benefits from making adoption look idiotic

The first people to champion this position are the Luddites. Those who do not want AI adopted at all — and therefore implement it in the most idiotic way possible, so the client waves it off and drops it on their own. Attaching a live engineer to read every generated line is the perfect way to bury the idea while formally "adopting" it.

But saboteurs are a sideshow. At least they are conscious of what they are doing. The real problem is deeper, and it is not about the executor — it is about the person above them.

## The manager who put production on a human being

A manager who insists on this way of working is relying on human control. Their production cycle now depends directly on human error.

They are throwing the entire history of industrial evolution out the window.

For centuries, industry has worked to remove the human from the equation — or at least push them off the critical path. Any modern production line is automation with a thin layer of replaceable people on top. If you have worked in any conveyor business, the first thing you saw was a system of regulations and rules that keeps the process running regardless of which specific person is standing at the machine today.

That is the goal of progress. Any system that depends on a specific human is unreliable.

## Professionals build systems, not shift schedules

Professionals build automated systems for control, verification, validation, and testing. The price of not doing so shows on the numbers — with no AI in the picture.

One product business, before a process overhaul, was catching 5–10 defects per day and shipping releases every few months. Once quality control, build, and deployment were put on automated rails — QA, CI, CD — the defect flow dropped to five per week, releases went weekly, and revenue grew 50%. Reliability did not come from a brilliant tester who "holds it all in their head." It came from a system that does not care who is having a bad day today.

With AI the logic is the same, just with more layers of control:

- **Guardrails** — rules enforced by machine, not by declaration. Not an instruction that "the engineer must remember and check by eye," but a technical checkpoint that cannot be bypassed. An independent Guardian with veto power.
- **Eval harness as a release gate** — layers of automated checks that let a change proceed only if it passes them, replacing a demo-grade "looks like it works" approval.

This matters for a specific reason. An AI failure does not look like a red error in the console. It looks like confident, smooth, dangerous text. A human reading the generation by eye is trying to catch the exact thing that is hardest to notice — on fatigue, on page ten, on a Friday evening. A system catches it identically on any day of the week.

Examples of these systems are laid out in open articles — take them and build:

- guardrails — https://www.dobryakov.com/blog/2282/
- AI code review — https://www.dobryakov.com/blog/2262/
- eval-harness — https://www.dobryakov.com/blog/2246/
- kafka two-phase commit — https://www.dobryakov.com/howto/kafka-two-phase-commit.html

## Your best person will call in sick

This is where the full picture opens.

When a manager says they rely on a specific person in their critical chain — one who might call in sick tomorrow, or whose judgment depends on whether they slept last night, or who might be having a bad day — what I see is a manager who cannot build reliable organizational structures and systems.

Manual review of AI-generated code is not "engineering maturity." It is a bet on a human in the critical path, dressed up as a virtue. And it is a losing bet by definition, because moving away from that exact bet is what production has been doing for the last two hundred years.

A manager who bets on the human will lose to the ones who know how to build systems. Inevitably.

## Run

So however flattered you are that your company trusts you with something this important — eyeballing AI-generated code by hand — run.

Run, or in a year a competitor who automated this will wipe you out.

Your Perfect Prompt Is a Leash Strangling a Model Smarter Than You

Prompt engineering is a harmful absurdity. You pay for an intelligence that has ingested the entire internet, then immediately forbid it from thinking wider than you do.

Prompt engineering is a harmful absurdity. The industry has spent so long convincing us that working with neural networks requires special "incantations" that we started mistaking this crutch for a genuine requirement. We got used to treating AI as a dutiful but dim junior developer who needs every single thing spelled out, or they will inevitably wander off course. From this assumption, those multi-story monsters are born: "Imagine you are a brilliant marketer with twenty years of experience, write a text in three paragraphs, use these words, do not use those, breathe every other second."

The truth is that on modern, top-tier LLMs, writing a giant, rigidly algorithmic prompt risks trapping the model inside the walls of your own limited intellect.

Continue reading “Your Perfect Prompt Is a Leash Strangling a Model Smarter Than You”

Your Context Pipeline Is a Garbage Chute: The Arbiter Model Between Collection and the Target LLM

Automated context collection without semantic awareness funnels contradictory versions of truth into one prompt. A consistency evaluator model catches the conflicts before the target LLM generates confident nonsense.

Manual context engineering looks straightforward: find the right information, stuff it into a prompt, get an adequate answer. While your context fits in a couple of paragraphs or is assembled by hand, that model works. No questions.

The real trouble starts the moment context collection is handed to automation that parses dozens of files, databases, and third-party APIs. At that point, your context pipeline becomes a garbage chute.

Continue reading “Your Context Pipeline Is a Garbage Chute: The Arbiter Model Between Collection and the Target LLM”

You’re Not Competing With Another Practitioner. You’re Competing With the Model.

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.”

A Professional Builds an Alienable Tool. The Rest Is Rent for Presence

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”

«Judgment Must Stay Human» — Or Are You Just Guarding Your Chair?

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?”

Step Away From Me With Your Ruler

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."

Continue reading “Step Away From Me With Your Ruler”