# What If the Biggest Bottleneck Behind AI’s 10× Promise Is the Human Engineer? > Source: > Published: 2026-08-04 13:26:42+00:00 # What If the Biggest Bottleneck Behind AI’s 10× Promise Is the Human Engineer? For the last year, a bold sentence has hung over engineers’ heads: with tools like Claude Code, **we will speed up our delivery by up to 10x**. I even personally wrote a bullet in our Internal Engineering Manifest stating it: It is no longer impossible to think that one engineer with Claude Code can produce what a team of three developers did 18 months ago. Our old ceremonies and structures were designed for a different era. We need to think outside of the box and habits, and think critically about HOW we operate. Expectations were set, and the year of execution began. But what should be read between the lines is that **a developer is not the same as an engineer**. ## The myth of the 10x developer Yes, we now have tools that can generate code and handle developer tasks, but this is just part of the engineering lifecycle, which now has a clear price. The new AI era demands even more from engineers; **we now expect engineers on steroids**. But no matter how advanced they are, engineers are still single-threaded by human design. Processes we built around the development cycle are complex. The architecture we built around physical-layer restrictions is complex. The 10x claim is a tempting goal, but it can still be applied only to code-generation throughput, not to the surrounding engineering system that keeps pace. What I realized is that **we are treating our engineers the way developers used to treat legacy Java applications**: by pushing an infinite stream of requests into a rigid, single-threaded system. At this point, we cannot state that we actually automated an engineering job; we have just dramatically increased the concurrency of our cognitive load. And this will not stop; this will continue to expand. **The analogy with Java’s evolution is impossible to ignore**. I will use a Java evolution comparison to further explain the complexity we need to overcome. What will happen if we just keep adding threads to a limited pool without upgrading the consumer’s architecture? **System failure is a mathematical certainty**. To fix thread exhaustion, we need to implement bounded queues (limiting Work-in-Progress) and strict rate-limiting on context switching. Sounds familiar? ## Why the old Java model couldn’t scale To understand how to navigate this new era of AI acceleration, we have to look at **how software engineers solved the problem of scale decades ago**. In the early days of Java, handling concurrent traffic relied on a straightforward architecture: the **Thread-per-Request model**. When a user interacted with a web application, the server spun up a dedicated operating system (OS) thread to handle that request from start to finish. It was simple, sequential, and highly predictable. But as the demand grew, this model hit a physical wall. OS threads are expensive; they require a fixed amount of system memory and CPU overhead to maintain. If a downstream datasystem also became slow, those **fast-moving request threads began to queue up**, block, and wait. Instead of processing code, the CPU spent all its energy swapping memory contexts between thousands of stalled threads. This led to **Thread Exhaustion** and system-wide livelocks. ## Putting the complexity on developers The Java Threading issue was not fixed by trying to force hardware to do the impossible, as we would demand of our human engineers to just type faster. Instead, the language underwent a **massive architectural evolution over the years**. Thread pools were introduced to strictly limit the amount of active work. Besides Java core changes, the dominant answer to thread exhaustion was reactive and **asynchronous programming frameworks like RxJava, Project Reactor, and Spring WebFlux**. These models worked by making blocking explicit: instead of a thread waiting, the code itself was restructured into chains of callbacks and non-blocking I/O operations. The result was dramatically better hardware utilization. The cost was equally dramatic: code became harder to read, harder to debug, and cognitively expensive to write correctly. **You solved the thread blocking problem by moving the complexity into the developer’s mind**. ## New human operating system Project Loom is Java’s answer to that bargain. Virtual Threads give you the hardware efficiency of reactive programming without the cognitive overhead. The code still reads as sequential, but the scheduler handles the yielding. Project Loom didn’t redefine what a thread does, but how it’s scheduled. Instead of tying one heavy, expensive OS thread to a single task, Java changed the underlying execution framework by **introducing a massive abstraction layer**. We are facing the same trade-off in AI-assisted engineering. We aren’t just managers assigning tasks and topics, **we are the architects of a new human operating system** where AI enhances human capability, not the other way around. ## AI is exhausting engineers? **We cannot patch the human brain to expand its working memory**, nor can we download more RAM into an engineer’s skull. When we try to force an engineer to context-switch across five complex initiatives at once, we are essentially trying to run legacy, heavy OS threads without an abstraction layer. The human brain blocks, thrashes, and enters **a state of total exhaustion**. When we brought Claude Code into our workflow, we fundamentally changed the execution speed of our inputs. An engineer can now use an assistant to generate a massive Pull Request in minutes, rather than days. While **the input and generation path is running at warp speed**, the specification, review, validation, and integration paths are still human and heavily constrained by the cognitive memory limits of our skilled engineers and their well-being. We don’t need to slow down the AI, nor can we change human biology. Instead, just like the Java architects of the past, we need to **rewrite the architecture of how work flows through our teams**. Our job is to design a human runtime environment that can handle this new level of concurrency. If we don’t upgrade our internal team operating system, if we continue to let engineers split their attention across product backlogs, technical initiatives, and nd workflow automations simultaneously and without introducing new headcount, the human system hits a cognitive livelock. They run at **100% mental capacity trying to manage the noise**, while their actual throughput on long-term technical architecture stalls. ## We need to redesign the system, not the engineers The first challenge before us is to understand **what work is best done by humans and what is better left to AI agents**. I started exploring these questions with my teams. The first thing we challenged was our Scrum ceremonies. We found that Kanban-like boards, with clearly prioritized topics and explicit engineering ownership, were a better fit, while keeping the sprint cadence intact. We also started bringing engineering into product discussions much earlier, **making sure engineers understood the “why” before diving into the “how”**. At first glance, this may seem unrelated, but it leads to better specifications and helps us classify different types of work more effectively. And once we understand those different contexts, we can make much better decisions about context switching within the same sprint. However, changing the scaffolding is only half the battle. To truly scale this new environment, we also need to **introduce highly skilled orchestrators **who deeply understand the system we are building, individuals capable of dynamically delegating tasks between human minds and AI assistants based on cost, complexity, and risk. **Brand-new engineering roles are emerging.** These engineers aren’t just writing code anymore, they are **acting as the “Team Core Architects” of our teams**, designing the very concurrency abstractions and execution rules that keep our human operating system from collapsing under its own speed. In an ideal future state, when a “Team Core Architect” designs a workflow, they **build an environment in which a human can step in to perform deep, high-value cognitive processing**, not to be wasted on something that can be automated. We aren’t asking our engineers to work harder or faster, we are changing the scheduling abstraction above them so that their finite mental energy is utilized only where it matters most. ## The Human Project Loom framework Transitioning to a “Human Project Loom” framework does not happen overnight by simply buying more enterprise Claude licenses. In reality, we quickly learned that **throwing tools at a burning team only increases the noise**. Instead, the true value of AI assistants over the past year was **buying us precious breathing room**. We needed our human time to draft ideas on how to work now vs. next period and turn ideas into concrete execution plans. But as we began rolling out this new architecture as an idea, we quickly realized: as the machine layer can grow faster, **humans require even more human interaction, mentoring, and deliberate guidance**. To safely scale our human platform threads without hitting a memory crash, we need to stop treating “software engineering” as a single, uniform role. Just as the Java Virtual Machine relies on a multi-layered stack, we will need to **redefine our engineering roles**. One option is to separate them into distinct, specialized layers of capability as an additional dimension on top of the traditional engineering roles. ## The Engineer At the foundation is the Engineer. In the legacy world, these individuals were predominantly in “developer mode”. Today, **we are stretching them into topic owners**, not just as architectural discovery phase owners, but to those who are starting their work with the thought: “Let us understand why we are doing this.” They are using AI context windows to rapidly learn system architecture, trace deep code dependencies, and upskill themselves at a pace that was previously impossible. **Perk**: They can now possess the technical knowledge of higher roles much sooner. **Cost**: They still need experience to gain seniority and mentoring investment. The skills of a senior engineer last year are not the same this year. ## The Orchestrator Engineer The next level is the Orchestrator Engineer. What I was informally calling “Team Core Architects” in the field now has a proper name within the proposed framework. These are the **senior engineers and tech leads who rode the initial AI wave early** and already comprehend how to amplify their individual output. But mastering personal productivity is a single-threaded victory. The challenge for an Orchestrator today is learning how to scale that velocity to other humans. You cannot be an effective tech lead without a deep understanding of your teammates’ cognitive limitations and thread exhaustion points. The Orchestrator’s job is to **act as the local thread scheduler**, determining which sub-tasks are delegated to Claude and ensuring other engineers don’t drown in the massive cognitive blast radius of AI-generated pull requests. **Perk**: Problem-solving mindset is a top skill; there are new and innovative ways to solve problems, a puzzle game for top engineers. **Cost**: One of the most used tools is other humans, which means broadening soft skillset and awareness of the impact on others. ## The OS-Level Engineers Finally, the last level is OS-Level Engineers. These are the **seasoned engineering managers and principal architects who view the entire system holistically**. They debug the JVM. They are the ones who define and track organizational metrics to see where thread starvation is occurring, dynamically allocate token and engineering resources, orchestrate the orchestrators, and inject mental “memory and heap space” into the team before burnout hits. They recognize that when a team is stuck in firefighting mode, it is a structural failure, and they step in to re-architect the environment so the machine loop serves the human, not the other way around. But at the same time, they need to define possible futures. **With the power of AI tools, they can now help their teams with delivery**. This does not mean falling into an antipattern of using vibe code PRs in team’s repositories, but rather giving them structure by drafting workflows and skills that could be a real time and cost saver for the whole organization. **Perk**: At the same time, our context is even more stretched, but we are closer to the core problem and are able to be hands-on more than ever. **Cost**: Context is overwhelming, and it is harder than ever to be on all 3 fronts: business, people, and technical. And it is not easy to introduce a new lead while undergoing a massive change ourselves. **We’re silently asking teams to change almost overnight** There is a crucial piece of context written in small letters underneath the history of Java’s evolution: Project Loom took nearly six years to design, test, and safely stabilize before it became a standard part of the runtime environment. Yet, we are silently pushing for our human teams to undergo a matching structural change almost overnight. Because t**he tools have advanced in months, we expect our organizational psychology to do the same**. But human adaptation cannot be fast-tracked with a software update. Empathy, psychological safety, and clear leadership are even more critically needed now than they were when we were single-threaded. If we commit to this new three-layer architecture, **every engineer is facing a massive “delta”**, a structural skill gap they must close to survive in this new framework. **The Engineer Delta **is shifting from syntactical output to intent comprehension. They must close the gap between knowing how to develop features and knowing how to critically evaluate an architectural pattern, and understanding why they are developing this feature in the first place. **The Orchestrator Delta**, on the other hand, is shifting from individual velocity to cognitive capacity management. They must learn to measure the mental load of the engineers they work with on the current assignment and master the art of safe, bounded task delegation. **The OS-Level Delta** is shifting from delivery management to ecosystem architecture. We must close the gap between tracking velocity, maintaining teams, connecting the business needs, and designing complex human-AI throughput environments. These are not abstract gaps, they are the live challenges every team is navigating right now. ## How do we onboard new engineers when our roles are still changing? But as we rewrite our human operating system, we are navigating unmapped territory with severe, systemic unknowns. The most glaring unknown is the onboarding: how do we successfully introduce new engineers to a team when we are actively redefining what our roles even mean? Because many organizations are considering to pause hiring to force efficiency out of AI tools, **we are inadvertently creating dangerous generation gaps**. If we don’t bring in fresh minds to learn the system from the ground up, who will step into the Orchestrator or OS-Level roles five years from now? Who will pass our human knowledge further? I strongly advocate **the continuous internship program** as the best way to introduce new human talent to our talent pools. Because the ground beneath our feet is constantly shifting, our team’s ceremonies must undergo their own architectural evolution. Look at the traditional agile retrospective. Historically, it was a highly transactional ceremony designed to celebrate wins, name out challenges and concerns, and assign action items. Today, that approach falls short. Who to assign action to? ## Staying human is our perogative In an AI-accelerated world, retrospectives must pivot to become a dedicated space for pure human connection. They must be treated as an environment for simply sharing thoughts, venting anxieties, and creating bonds between teams and managers. We don’t just need a list of Jira action items at the end of the hour, **we need a collaborative sanity check**. I do not need actions to be solved, but to hear and see the real load people are holding. And yes, 1:1s become more emotional, retros become more challenging, and we all in the end act more human than ever. We need a shared space to learn how to survive the fires together, ensure our mental heap space isn’t crashing, and remind ourselves that behind every hyper-accelerated AI execution thread, there is still a human heart driving the system.