Everyone is making the same argument: code is no longer the bottleneck, and the bottleneck has shifted to the phases before and after coding. But describing this as a moving bottleneck understates the change. Beyond the agency and identity attachment challenges I discussed in my previous essay, agentic coding changes not just the volume of work but what it takes to judge, validate, and understand it. Over the past two months, I went full speed with agentic coding to tease apart some problems. I got the outcomes I expected—hope to share more about those later—but the work was often cognitively draining: I experienced decision fatigue, sometimes struggled to form a mental model of how everything works, and had to disconnect and step back multiple times. That experience taught me one thing: while agentic coding compresses the cost of certain aspects of the SDLC (researching, initial problem decomposition, prototyping, coding, testing and debugging, document production, etc.), it makes other parts harder, forcing intense adaptation of problem-solving modes. Here is how I would edit a diagram from a recent essay on AI-native SDLC by folks at Anthropic. The cycle-time reclamation from build-time compression is real. However, the phases before and after must now compensate and evolve rapidly to absorb that compression. An hour saved on coding isn’t psychologically interchangeable with an hour of judgment. The effects show up differently in other phases. Cognitive capacity I sometimes prompted my code agent to “explain like you’re explaining to your grandma” when discussing decisions. The joke was on me, not AI. The challenge was my cognitive capacity. Cheaper building makes more problems tractable. You can let AI generate more options much faster than you can reason through them. You can rapidly and cheaply prototype those options without thinking clearly about them. You can also pick options without understanding their implications. Furthermore, since AI will fill in the gaps of what you have not explicitly described, it might also create nonsense options and steer you in the wrong direction. Sure, you can throw them away, but only if you can catch those before the code ships to production. I went through many of these in my building experience. As the number of decisions increased, the quality of my reasoning deteriorated. It then showed up as the implementation drifting from my intent and regressions. My coding agent imagined design constraints I didn’t specify and started arguing with me. The result was rework. Sound decision-making is always critical, but the difference is the volume of judgment. High-density judgment is effortful and fatigue-producing. Compressing consequential decisions into short bursts can leave too little time to absorb their implications. Our brain requires reflection, recovery, and memory consolidation. As I wrote earlier, our brains form schemas, which are generalizations and patterns, from overlapping or related information over time. AI operates on machine time, while our understanding develops on biological and experiential time. In my previous work, decisions of this kind were spread over weeks or months. Here, I had my brain cooked when reviewing four or five decisions in one single sitting. Validation Capacity I had nearly 400 PRs in two months, roughly 10 PRs a day going through CICD. Not a big deal, even though most PRs came from parallel worktrees. But such experience starts to crumble as more people work on the same codebase. I can’t imagine replicating my experience even to a 5-person team working on the same codebase. The challenge is not just the build and delivery infrastructure. There are known ways to scale those up for higher throughput. But agentic coding amplifies the challenge of confidently declaring that multiple simultaneous changes will work well together in production and still produce the desired outcome. A common brownfield case is when PRs in monolithic codebases land in large shared environments and sit there for a few days before being promoted to production every week or every other week. I’ve dealt with such cases in each of my three previous jobs. Each PR may have been tested independently, but what guarantees they work together correctly when you promote them to production? Add the common case where production differs from staging, and that some regressions show up only after prolonged production exposure. I once saw a benign-looking change that passed all the known checks independently lead to frustrating tail user behavior weeks later. The first reaction from the engineering team that saw customer complaints was disbelief. It was expensive to even validate the poor user experience, let alone trace that back to the change. Higher coding throughput forces teams to absorb more validation complexity than before. Reasoning Capacity Reasoning capacity is our ability to explain how complex systems work, anticipate how they might fail, and diagnose what happens when they do. In today’s production environments, that capacity is mostly human, supported by inside-out understanding of code, configuration, dependencies, and production telemetry. Above all, what makes the best SREs is their tribal knowledge and all the buried tripwires. Back in 2018, I spent several weeks analyzing production incidents at a large travel company where I worked then. As we were rapidly adopting AWS, we saw an uptick in incident frequency, so I set out to study incidents and drive change. I found two patterns. The first: a code or config change introduced a tripwire, and the system fell on it, or the change tripped a pre-existing tripwire everyone had forgotten about. The second pattern might surprise some, but incidents that resolve on their own are fairly common. As production conditions change, some tripwires disappear into the background, and people forget to follow through. Those tripwires may surface again, but their existence is usually lost in tribal knowledge. What’s common between these two patterns is pre-existing tripwires, which survive only in folklore and tribal knowledge. Last year’s Cloudflare incident, not AI-related, makes a related point about tripwires. A permission change increased the size of a feature file, which propagated rapidly across the network. The feature file was machine-generated every few minutes. Cloudflare’s proxy servers load these features when scoring customers’ bot rules. The file propagation was by design, but the tripwire was a software limit on the file size. That file size was an undeclared invariant, set years ago and likely lost to tribal knowledge. The impact was intermittent, depending on which nodes produced data. That led Cloudflare to initially suspect a DDoS attack. Only later, two hours into the incident, did they trace it to the file size. The analogy I’m making is this: can human reasoning capacity keep pace with the rate of change? What happens to organizations whose only reasoning instrument is tenured engineers, but the code is churning faster than the tenure that could explain it? Where does the learning come from? I argue the answer isn’t more observability and human-in-the-loop code reviews. The fundamental issue is that such an expectation is asymmetric. On the build side, we now expect humans to author better specifications and hand them off to coding agents. But on the operational side, the current answer to reasoning capacity is still experienced senior engineers. Coding agents aren’t going to hand off the hints to buried tripwires to the humans at the end of their coding sessions. Bracing for Rework Uncaught issues due to these capacity challenges in the SDLC loop eventually return as rework. A gap AI fills during the design phase might not surface until integration testing. That is cognitive capacity pressure lowering scrutiny during the design phase and returning as rework days or weeks later. Vibecoded commits that nobody understands increase diagnostic effort during incidents, and return as expensive rework. A DX report from a few months ago on the state of AI impact in engineering (link behind a marketing wall) shows a flat innovation ratio (time spent on creating new features vs. maintenance) since mid-2025, at about 57% (p. 26). Over the same period, AI-authored code rose from 24% to 52% (p. 30). What happened to the time savings? Their report makes one thing clear: “some organizations are simply shipping defects faster” (p. 22). Cognitive capacity constraint is real. Folks at the Boston Consulting Group and UC Riverside called it “brain fry” in an HBR article earlier this year. They pointed to rising errors and decision overload from constantly overseeing AI outputs. In my experience, this problem is more acute in the planning and design phase. More parallel agents make it worse for the brain, a lesson I learned quickly. Validation capacity is not new for brownfield enterprises. Though some solutions are known, I bet we need more to tackle the compounding effects and tripwires. Then we have the asymmetry of reasoning capacity — we’re comfortable with AI writing the code but are still expecting humans to build reasoning capacity at the same pace and keep catching tripwires. Contemporary approaches won’t cut it. Coping requires innovating the loop to catch more and work differently. But for that to happen, we need to shift away from productivity obsession and toward building systems that build and operate systems under the rules, constraints, and invariants humans set. The quick answer in the tech community may be agent factories. If that term survives, I would grade those factories on how well they handle the capacity challenges I outline here. This can be an exciting time to innovate the SDLC loop, or a chance to add yet another failed transformation to a leader’s resume. I’m betting my time on innovating the loop.