You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 11 minutes
Key takeaways:
- Authorship, memory, and comprehension are gone. Only runtime behavior tells the truth now.
- Patching now accelerates exploitation: disclosure-to-exploit time dropped from 771 days to 4 hours.
- Stop gating for comprehension. Invest in detection and blast-radius containment instead.
In 1563, Pieter Bruegel the Elder painted the Tower of Babel. If you haven’t seen it, picture this: an enormous spiral tower, wider than the city sprawled around it. It’s built in receding tiers, each level ringed with arches and passageways, with hundreds of tiny figures swarming across every level, hauling blocks, working cranes, laying stone.
This painting is the most honest picture of the AI tooling industry I can think of. Look closely and it resolves into dozens of half-finished stories stacked on top of each other, each built at a different pace, none of them waiting for the others.
The lower levels are already weathered and crumbling while the top is still being built. Scaffolding clings to every level. Some parts are solid stone, some are exposed brick and others are still just wooden frames waiting to be filled in. The whole thing is inhabited and operational, while simultaneously unfinished at every tier.
That’s what building on AI tooling feels like right now. We’re laying foundations and adding floors at the same time, on top of a base that’s still shifting.
Bruegel captures the hectic pace of it all, which we live daily: a model ships, gets pulled within days for policy reasons, comes back with guardrails and a timer on its availability. Before you’ve adjusted a competitor releases something that reshuffles the whole calculation, and the model you were told was temporary quietly becomes permanent. All in the span of a few weeks.
The unsettling part is the scale mismatch between how fast the tower is rising and how uncertain its foundations are. That’s the exact anxiety of building on AI right now: the construction is genuinely impressive but you can’t quite shake the sense that we’re adding floors faster than we’re verifying the ones underneath. The people doing the building are starting to feel it.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
The people building the tower are exhausted
The anxiety is surfaced clearly by the data. The LeadDev Engineering Leadership Report 2026 surveyed 600 engineering leaders and found rising strain across the board, with the majority reporting they feel emotionally drained from their work at least once a week.
CTOs show the most dramatic shift, with 54% reporting feeling emotionally drained at least once a week, compared to just 24% the year before. That’s a 30% jump in a single year.
It’s worth sitting with why. It’s exhausting to manage an infinitely hungry AI workforce while knowing there’s no longer direct human ownership over every line of code. I know leaders who live with a low-grade dread that a business-killing bug is sitting in some unread, AI-generated corner of the codebase, and no process they currently run will catch it before a customer does.
This is where the tower comes back. The usual reading of Bruegel’s painting follows the old story: the tower is doomed, ambition on this scale always ends in collapse. I don’t think that’s the right lesson for where we are.
The tower is at risk not because of its height but because nobody appears to be checking whether the lower floors can carry the weight of the ones above them. Everyone is building upward. No one is inspecting the lower levels.
That’s the part we can actually change. Building fast isn’t the problem, and slowing down isn’t the answer. The pace isn’t going to relent and pretending otherwise is a losing strategy. The problem is the assumption baked into every new floor: that the layer beneath it will hold simply because it hasn’t fallen yet.
So the question is how you check the floors below without slowing the progress above.
Moving at machine speed
Most of our development best practices were built for a world that ran at human speed. They assume code is written, read, and understood at roughly the rate a person can work. AI has broken that assumption, and the practices built on it are now colliding with problems moving orders of magnitude faster. Let me show you two places where the collision is already happening.
Ratio of unreviewed-to-reviewed code
The pager goes off. The service failing is one your team owns, but the code path that’s breaking was generated four months ago, merged after a clean CI run, and no one currently on the team has read it.
This has always happened occasionally. The engineer who wrote it left the company, and their knowledge left with them, but that was the exception, and it was bounded in two ways. It was a slice of the system, maybe 5 or 10%, and the rest of the team still understood the system.
The departed engineer left traces: design docs, a PR description written by someone who understood the change, commit messages explaining the why, a reviewer who at least skimmed it, a conversation at standup. Institutional memory is lossy, but it’s real. You could rebuild understanding from what was left behind, albeit expensively.
Agent-generated code, merged unread, has none of that. There’s no author to page, no reviewer who saw it, no design doc, no discussion. The comprehension step never happened. There’s a term emerging for this: dark code. Code that was never understood by anyone at any point in its lifecycle. Generated, passed its checks, shipped, and never held in a human head.
It isn’t a slice anymore. It’s becoming the majority of the codebase, and it grows every sprint. Code generation used to be the bottleneck. Now it’s the cheapest part of the process, and the expensive parts have moved to either side of it: deciding what to build, and understanding what got built. GitHub is projected to go from roughly 1 billion commits in 2025 to 14 billion in 2026. Whatever your team’s capacity to read and understand code was, it did not grow 14-fold this year.
None of this is entirely new. I’ve argued before that PR review was already showing cracks as a quality gate. What AI did was turn a spark into a bonfire, multiplying the surface area of the problem. The same agent produces excellent and subtly broken code in the same afternoon, so there’s no calibration signal: every line deserves equal suspicion, which is another way of saying suspicion stops working as a triage tool.
Engineering leadership is not only dealing with a failure of the existing software quality best practices, but a deeper question of “accountability”.
Software quality rested on a chain of ownership: someone wrote it, someone reviewed it, someone’s name is on the commit. Coding agents dissolve that heuristic and managing code you can’t attribute to anyone is genuinely new territory.
It shows up most sharply in incident response. Runbooks and dashboards were always aids, while the foundation of successfully managing an incident was human recall: the person who wrote the code remembering the tradeoff they made, the edge case they skipped, the assumption baked into a specific line. And if it was written by someone else, debugging became a conversation. Both approaches assume an author exists. When the author is a model that ran four months ago, the strategy of restoring per-line comprehension is not viable.
More like this
Accelerated offense and defense of vulnerabilities
The second collision is in security, and it runs in both directions at once.
In one direction, AI tools generate vulnerabilities: they produce plausible-looking code that passes tests, misses edge cases, and introduces security flaws that a careful human might not have written.
In the other direction, AI tools are extraordinarily good at finding vulnerabilities, including ones that eluded human reviewers for years. In February, Anthropic’s team, using Claude Opus 4.6, found over 500 vulnerabilities in production open-source codebases. We’re several model generations past that now.
Put those together and you get an accelerating loop: more vulnerabilities shipped, discovered faster, exploited sooner. The data on this is stark.
According to the Zero Day Clock, in 2018 the median time from a vulnerability being disclosed to the first observed exploit was 771 days. By 2023 that window was six days. By 2024 it was four hours. In 2025, the majority of exploited vulnerabilities were weaponized before they were publicly disclosed at all, and the volume is climbing. Over 40,000 CVEs published in 2025, with 2026 projections running from 60,000 to as high as 100,000 depending on how you account for AI-assisted discovery.
Here’s the part that should change how leaders think. Even when you catch a vulnerability first, the fix works against you. A security patch is, by necessity, a public description of the flaw it repairs. Anyone can compare the patched code to the previous version and reason backward to the vulnerability. That technique is decades old.
What’s new is that AI has collapsed the reverse-engineering-to-working-exploit step from days to minutes. So the moment you ship a patch, you’ve handed attackers a map, and they can weaponize it and start hunting for anyone who hasn’t deployed the fix yet, while your own rollout still takes weeks of testing.
The act of fixing a vulnerability now accelerates its exploitation. AI has lowered the cost of finding flaws for everyone, and right now the offensive side is converting that capability into working exploits faster than the defensive side can patch. If a vulnerability ships to production, the only safe assumption is that it’s already being probed.
The only source of truth
Step back and look at what we’ve established. Authorship is gone: no one wrote the code in the human sense. Memory is gone: there’s no author to remember the tradeoff. Comprehension is gone: the code is shipped without ever being held in a human head. Every traditional source of truth about what your system does has quietly stopped working.
When all three fail at once, only one source is left standing: the observable behavior of the system itself.
This is a genuine inversion: for the entire history of the discipline, code was the truth and telemetry was the hint. You read the code to know what the system did; you glanced at logs when the code alone didn’t explain something. That hierarchy is now reversed. What the code was intended to do no longer exists as a retrievable fact. What the code actually does under real conditions is still knowable, but only by watching it run.
Most leaders haven’t made this shift yet, and you can see it in what they reach for. Comprehension gates that require the merging engineer to explain the code in their own words. Mandatory human review of every AI-generated change. Documentation requirements. Each of these is an attempt to restore per-line human comprehension, and each runs into the same arithmetic: the volume is growing faster than any team’s reading capacity ever will.
You cannot gate your way back to a world where a person understands every line, because that world was already slipping away before AI arrived and AI has now put it permanently out of reach.
The same shift is forced on you from the security side, and the math there is even less forgiving. The average enterprise application pulls in hundreds of open-source dependencies, each with its own transitive tree, often five to seven levels deep. A single flaw anywhere in that tree is a flaw in every application that imports it, and you did not write, review, or in most cases even choose the code where it lives. Combine that with a time-to-exploit that has collapsed to hours, and the traditional security best practices crumble.
So what does adapting actually look like? It starts with accepting a premise most incident and security practices still resist: you will not comprehend your way to safety, and you will not patch your way to safety either. Breaches and failures will occur. The useful question is what you’ve built to limit the damage when they do.
That reframes the whole job around variables you can actually control. Patching tries to lower the probability that a breach happens, and you’ve just seen how little leverage that gives you now.
New York • September 15 & 16, 2026
Don’t figure it out alone. Learn what works at LDX3 New York.
Detection tries to shrink the time an attacker or a bug operates undetected, which means investing in the ability to see what your system is doing in real time rather than reconstructing it after the fact.
Architectural containment reduces the blast radius of any single failure, and it’s the one variable fully determined by design choices you make before any incident occurs. When you can no longer trust that the code is correct, you design so that no single piece of code can take down everything around it.
Underneath all of this is a change in what you’re hiring and training for. The valuable skill used to be holding the system in your head, the senior engineer who knew where every body was buried. That was real, and it’s worth mourning honestly, though it has probably been slipping away for longer than any of us cared to admit.
What replaces it is fluency in the system’s observable behavior: the ability to ask what the system is actually doing right now and get a trustworthy answer fast, without needing a human who remembers why it was built that way.
Which brings us back to the tower. The usual lesson is that it was doomed, that building this high always ends in collapse. However, the tower falls because it’s easier to add a floor than to confirm the one beneath it will hold. We are integrating models into production before they’re stable, building agents on protocols still being drafted, shipping features against APIs that will look different next month, and adding each layer in the confidence that the ones below will bear the weight.
That confidence is the actual risk. Not the height, not the speed, not the AI.
The teams whose towers stand will be the ones that stop trusting that assumption and start checking. Runtime evidence over recall. Verification over trust. A way to see whether the ground beneath you holds before you put your full weight on it.
