Where AI stops: the one decision we didn't automate
Yehor Skorniakov
CTO at Alty
July 9, 2026
There's a decision a lot of engineering leaders are quietly making right now: give AI more of the work, keep fewer people to watch it. The logic is easy to follow. If a model can write the code, run the tests, and push the release, why keep a person in the middle of every step?
The reason isn't that AI is weak. It's that AI has no culture of refusal. It will not tell you "I don't know." When it reaches the edge of what it can do, it doesn't stop. It invents, and presents the invention as fact. That single trait changes how you're supposed to build with it.
And the premise behind the headcount cuts is shakier than it looks. A 2026 study from Ramp and Revelio Labs, covering more than 21,000 US firms, found that companies investing heavily in AI grew their headcount by around 10% in the two years after adoption, while light adopters saw no meaningful change at all. The firms getting the most out of AI were the ones integrating it seriously enough to grow. That's what we've seen across banking and fintech projects too: the value comes from being deliberate about which decision stays human.
Automation is not the same as autonomy
It helps to separate two things that often get blurred.
Automation is handing a machine the mechanical, repetitive work — the parts where the answer is knowable and the rules are clear. Autonomy is letting the machine decide, on its own, what should happen next. AI is genuinely good at the first. It is not ready for the second, and in a regulated environment it may never be.
The reason is technical, but the consequence is a business one. AI is not deterministic: ask it the same question twice and you can get two different answers. Someone has to check those answers and pick the right one, and to do that they need to see the whole system, not the single file in front of them. That judgment is the job. It doesn't disappear because the code got written faster.
This matches what the broader data shows. McKinsey finds that the teams pulling real gains from AI — 16 to 30% in productivity — are the ones that redesigned how the work gets done around AI, rather than simply giving developers the tools.
You can see how serious this is at the very edge of the technology. Researchers using AI to model protein folding for drug discovery run several models in parallel, specifically so they can check one another. Without that, one model's hallucination travels downstream as a confirmed result. Even at the frontier of science, the human doesn't stand beside the machine. They stand above it.
What this looks like in practice
A while ago we rebuilt the deployment process for a leading Nigerian bank. Before, every release meant 30 to 45 minutes of hands-on work, many times a day. We had a capable CI/CD setup — services compiled and verified on GitLab, then pushed downstream to trigger the next stage — but every step still needed a person to evaluate it and press go. The result was a heavy, repetitive load, and the kind of process where it's easy to miss the one detail that brings a system down.
We handed the mechanical part to AI, built around purpose-specific skills rather than one general model. For each release type — an API release, an infrastructure release — a dedicated skill inspects the commit and the branch and creates the right kind of release, a candidate or a main one. An orchestration agent tags the release, starts the job, and follows it to completion. A separate agent does nothing but assess risk: it scores each release and flags the specific changes that deserve a closer look. After the release ships, a monitoring agent watches it live and reports errors or a clean finish.
What we deliberately did not automate was the release decision itself. A person reads the risk summary and confirms, or declines, what actually goes to production. One focused judgment, instead of a chain of manual steps.
The result was around 20 to 25 minutes saved on every deployment, many deployments a day, and most human errors removed. Risky changes are now rarely missed, because the scoring is consistent in a way tired people can't be. The machine took the mechanical work. The release decision — a person reading the risk summary and confirming what goes to production — stayed where it was.
The same principle held on a larger scale with a Swiss private bank. The brief there wasn't a single pipeline. It was a fragmented set of systems that had to become one coherent whole, without raising operational risk in a live bank. Growing further on the old foundation would have increased that risk, not reduced it. A previous agency had already tried and failed, because no one had owned the integration as a whole. The pieces were built, but nothing held them together. Automation cut the manual work, but the architecture itself — what to consolidate, what to keep, what to rebuild — was a chain of human decisions. This is the kind of problem we tend to be called in for when an existing product needs to regain momentum: hand that judgment to a model and you get plausible answers with no one accountable for them.
Where the mistake actually costs you
The common error is assuming AI can take in the full context, weigh the external factors, and make the call by itself.
In real development, as in real life, the right decision depends on things that aren't in the code: regulation, timing, what the business can absorb, what the last team already broke. A model doesn't hold that context. When it decides without it, wrong conclusions start to stack on top of one another, and the project drifts toward a wall no one saw coming. By the time it's visible, there's no one to ask what happened, because nothing, and no one, was accountable for the chain of choices.
On a serious build, a person in the loop is the cheapest insurance you can buy.
What actually changed for our team
On our team, the structure didn't change. The work did.
The routine now runs on AI, which frees engineers to think at a larger scale: to run several problems in parallel and validate the results at the points that matter. The work got harder: what's left is the part that needs judgment.
AI is a powerful tool, and it strengthens every stage of building a product. But it decides how the work gets done. What's worth doing, and why — those questions still belong to an engineer. If you're looking for a partner that owns the decision as much as the delivery, how we work.
Sources
Kharazian, A., Simon, L., & Stevens, R. (2026). A New Look at AI's Impact on Jobs: Firm-Level AI Spending and Workforce Adjustment. Ramp Economics Lab. Sample of 21,559 US firms. https://ramp.com/data/ai-jobs-impact
McKinsey & Company (2026). The AI revolution in software development. On top-quintile productivity and code-quality gains, and why value depends on redesigning the development process around AI rather than adding tools. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-ai-revolution-in-software-development
