You Can't Edit What You Can't Write
You can only edit what you could have written.
An editor who has never written a paragraph cannot fix one. They can tell you they don’t like it, but they cannot tell you why, or what to do instead, because the judgment that makes editing useful is the same judgment you build by doing the work yourself. It transfers from the hands to the eye. Skip the hands and the eye never sharpens.
This is a pleasant truism when we are talking about prose. It is a governance problem when we are talking about a bank’s software.
Review Presupposes the Ability to Build
In a regulated institution, a human is supposed to stand behind every change. Someone reviews the pull request. Someone approves the merge. Someone signs the change record. Someone, eventually, sits across from an examiner and explains why the system does what it does. Every one of those acts presupposes a person who understands the code well enough to have written it.
Take that competence away and the acts continue, but they become hollow. The review is a scroll and a thumbs-up. The approval is a signature on something the signer could not reconstruct. The examiner asks how the interest calculation handles a leap-year boundary and the answer is “the agent wrote it, and the tests pass.” That is not a defense. That is an admission that nobody in the building can defend it.
The danger is not that agents write bad code. It is that they write plausible code faster than your people can build the understanding required to stand behind it. Approval without comprehension is the specific failure mode a bank cannot afford, because the entire regulatory model rests on accountable humans, not accountable machines. I’ve argued before that the institution can get dumber even as its output goes up. This is the mechanism.
How Competence Actually Drains
The erosion is not dramatic. It is quiet, and that is what makes it dangerous.
The research names the mechanisms plainly. A survey of human-AI interaction, “Ironies of Generative AI,” describes automation bias, the tendency to accept generated output without verifying it, and automation-induced complacency, the erosion of vigilance when a tool is usually right. The most unsettling part is skill decay through disuse: the paper notes it can be imperceptible to the person experiencing it. You do not notice the competence leaving. You notice, years later, that it is gone.
You learn a system by struggling with it. By writing the query that times out and figuring out why. By shipping the race condition and hunting it down at 2am. That struggle is not waste. It is how the mental model gets built, and the mental model is the thing that lets you review someone else’s change with real judgment instead of pattern-matching. When the agent does the struggling, the code still ships, but the model never forms. You get the artifact without the understanding.
For an individual, that is a career risk. For an institution, it is something worse.
The COBOL Problem, Industrialized
We already have a preview of what happens when a critical competence concentrates in too few hands. It is running in your core banking system right now.
The U.S. Government Accountability Office reported in 2016 that the federal government was spending more than 75% of its IT budget just operating and maintaining existing systems, some with components at least 50 years old. Several ran on COBOL. The Social Security Administration had to rehire retired employees because it could no longer find people who understood the code that runs the country’s benefits. The competence had aged out, and the systems were too critical to leave undefended.
COBOL is not a museum piece. As The New Stack summarizes the widely-cited Reuters figures from 2017, something like 220 billion lines of it are still in production, touching an estimated 43% of banking systems and 95% of ATM transactions. The reason banks fear the COBOL skills gap is not nostalgia. It is that a system nobody left alive fully understands is a system you cannot safely change, and cannot honestly defend.
Now run the tape forward. The COBOL concentration risk took forty years to develop, built by attrition as a generation retired. AI-driven de-skilling can manufacture the same risk in three, not by people leaving, but by people never acquiring the understanding in the first place. A team that let agents write the core ledger logic without ever building the model of how it works has produced a COBOL problem on a compressed timeline. The code is modern. The comprehension is already gone. And there are no retirees to rehire, because nobody ever knew it.

Not Every Competence Is Load-Bearing
Here is where the argument has to avoid its own trap. The answer is not “hand-write everything to stay sharp.” That is nostalgia, and it does not survive contact with delivery pressure or with the economics of the moment. You cannot, and should not, refuse the leverage.
The discipline is knowing which competences are load-bearing and defending those deliberately. The test is simple: for any given system, will someone have to review it under scrutiny, audit it, or defend it to a regulator? If yes, your organization must retain the ability to build it, not just to run the agent that builds it. Those are your core competences, and they are worth the deliberate cost of keeping humans genuinely fluent in them, even when the agent could do it faster.
The reversible, low-stakes, well-understood work, the internal tooling, the glue scripts, the report generators, is where you let the leverage run without guilt. Nobody is going to be cross-examined about the formatting of an internal dashboard. This is the same graduated logic I laid out in the trust ladder: the more consequential the surface, the more human capability you keep in reserve, and the less you delegate blind. Competence, like trust, should be spent according to stakes.
The Part I Won’t Overstate
I need to be honest about the limits of the alarm, because the honest version is more useful than the doom version.
The evidence for catastrophic de-skilling is not yet in. A controlled study of 151 professional developers, “Echoes of AI,” found a 30.7% median reduction in task-completion time with AI assistance and, importantly, did not detect a systematic maintainability penalty in the resulting code. The straightforward prediction, that AI-assisted code is a maintenance time bomb, was not borne out in that experiment. Anyone telling you the sky is measurably falling is ahead of the data.
So the case is not “AI is rotting your engineers, here is the proof.” The case is narrower and harder to dismiss: competence erosion is a known mechanism, it is imperceptible while it happens, and the consequences in a regulated institution are severe and slow to surface. That combination, plausible cause, invisible progression, catastrophic and delayed effect, is exactly the risk profile that responsible institutions manage before they have a body count, not after. You do not wait for the COBOL crisis to prove itself twice.
Competence Is Capital
The reframe that makes this actionable is to stop treating engineering competence as a personal attribute and start treating it as an institutional asset, like capital. Capital depreciates if you do not maintain it. It concentrates dangerously if you do not distribute it. And it is far cheaper to preserve continuously than to reconstruct after it is gone, as the Social Security Administration learned when it went looking for COBOL programmers who had already left.
An agent-heavy engineering organization can run for a long time on borrowed competence, the understanding built by senior people before the tools arrived, spent down a little each quarter as they review more and build less. It works right up until the day a system breaks in a way the tests did not cover, and you discover that the only entity that ever understood it was a model, and the model cannot sit across from your examiner.
Keep your hands in the load-bearing systems. Not out of craftsmanship. Out of the plain institutional requirement that someone in the building has to be able to write what they sign their name to. Everything else follows from that, including the judgment that turns out to be the only thing agents cannot hand you.
If this resonated, read Everything Is Skill Issue, on the organizational side of AI adoption, and The Bank Got Dumber, on how institutional knowledge leaks even as output climbs.
Find me on X @orestesgarcia or LinkedIn.