Four Counterintuitive Observations on the "Full Automation" of Software Engineering

A tech professional recently shared observations on Twitter about the "full automation" of software engineering, and the conclusions are somewhat counterintuitive: the number of engineers is not decreasing but increasing, work intensity is not falling but rising, code is almost entirely written by agents, yet corporate profits have shown no obvious improvement. Together, these four observations point to a widely overlooked fact—automation is not the endpoint, but a migration of bottlenecks.

Observation 1: More Engineers, and Demand Is Still Growing

The first point in the original post is: there are more software engineers now than ever before, and demand is still growing. This directly conflicts with the popular narrative that "AI will replace programmers at scale."

The logic behind this is not complicated. AI has lowered the marginal cost of software production, but it has not reduced total demand for software. Once companies realize they can build systems at lower cost, they re-queue demands that were previously "not worth doing"—internal tools, data pipelines, customized integrations, experimental products. The speed at which demand is unlocked often exceeds the speed at which efficiency gains reduce jobs.

This is more like the story of the textile industry during the Industrial Revolution: machines increased output per unit, but falling textile prices created a larger market, and ultimately the number of workers employed rose. Software engineering is undergoing a similar structural change, only faster and broader in scope.

Observation 2: Engineers Have Never Been Busier

The second observation carries a bit of dark humor: software engineers have never worked as hard as they do now.

Efficiency tools are supposed to save time, but in reality they often fill the gaps they create. When coding itself is taken over by agents, engineers' attention shifts to higher-frequency activities: reviewing code produced by agents, validating edge cases, debugging cross-system interactions, and handling implementations that "look right but are actually wrong." The cognitive load of this kind of work is not lower than writing code; instead, it becomes more intense because output speed has increased.

One direct consequence is the review bottleneck. Agents can generate hundreds of lines of code in minutes, while the time humans need to review that code does not shrink proportionally. Acceleration on the output side shifts pressure to the verification side.

The review bottleneck is a classic system dynamics phenomenon in software engineering, referring to the constraint point in overall delivery pacing when code output speed exceeds human review and verification capacity. It shares the same origin as the concept of a "bottleneck process" in manufacturing: the output of the entire assembly line is determined by the slowest workstation, not the fastest one. Before AI coding tools became widespread, the review bottleneck was often masked by the time consumed by coding itself; when agents compress coding time to near zero, the relative cost of the review stage is sharply amplified. Research shows that the cognitive load of code review has a nonlinear relationship with the scale and complexity of code changes, and review of large-scale AI-generated code is especially prone to "rubber-stamp" perfunctory approvals, thereby planting hidden quality risks.

Observation 3: Code Is Almost Entirely Written by Agents

The third observation is the most radical: engineers have largely stopped writing code by hand, and agents handle close to 100% of coding work.

If you look only at this point, it is easy to conclude that "engineers have been replaced." But combined with the first two points, the real picture is a shift in the center of gravity of roles—engineers have moved from producers of code to designers of systems, makers of constraints, and gatekeepers of results. The act of writing code has been automated, but questions such as "what code to write, why write it, and whether it is trustworthy after it is written" still require humans.

You may not have noticed that this division of labor imposes different requirements on engineers' skill structures. In the past, the core skill was implementing logic quickly and accurately; now the core skills lean more toward problem decomposition, context provision, quality judgment, and system-level tradeoffs.

Observation 4: Corporate Profits Have Not Improved Markedly Because of AI

The last observation is the easiest to overlook, but it may be the most important: companies that employ these engineers and agents have not seen a clear change in their bottom line due to the introduction of AI.

The reason is that writing code is only one link in the software delivery chain. A complete delivery chain also includes requirements clarification, architecture decisions, environment configuration, testing strategy, deployment processes, online operations, and compliance review. Automating the coding link can indeed shorten local time, but the throughput of the entire chain depends on the slowest link. When coding is no longer the bottleneck, the bottleneck appears elsewhere—perhaps in review, perhaps in the test environment, perhaps in cross-team coordination.

This also explains why many teams, after introducing AI coding tools, feel that they are "writing more things that need to be handled, faster" rather than "delivering value faster."

Theory of Constraints was proposed by management scholar Goldratt, and its core claim is: the output of any system is determined by its weakest constraint link; locally optimizing non-bottleneck links will not improve the overall output of the system and may instead pile up work in progress and increase chaos. Mapping this theory onto the software delivery chain, coding is only one of many links; after AI greatly increases the capacity of the coding link, the system's constraint point naturally shifts to review, testing, deployment, and other links that have not been automated to the same degree. This also explains why companies have not seen obvious profit improvements after introducing AI coding tools—they optimized non-constraint links while the real bottleneck was not touched. The action recommendations from constraint theory are: identify the bottleneck, fully exploit the bottleneck, make other links subordinate to the bottleneck's pace, and then consider increasing the bottleneck's capacity.

Systems Perspective: Automation Migrates Bottlenecks Rather Than Eliminating Them

The final suggestion in the original post is: you must think from a systems perspective. Automating one link in a system creates new friction elsewhere and pushes the bottleneck to a new position.

This view is not new, but it is especially relevant now that AI coding tools are being deployed at scale. Local efficiency gains do not equal global efficiency gains, and may even create new chaos because of coupling between links. What truly determines delivery speed has never been the fastest speed of any single link, but the slowest segment in the entire chain.

For engineering managers, this means that after introducing AI tools, they need to re-examine the entire value chain: which link has now become the new constraint? Where has the team's time been reallocated? Which links are under disproportionate pressure because upstream has accelerated? These questions are more worth asking than "how much code can AI write?"

For individual engineers, the conclusion is equally clear: the scarcity of coding ability is declining, while the scarcity of system judgment, quality gatekeeping, and problem definition is rising. The wave of automation will not hit every link evenly; it will first swallow the parts easiest to standardize, then leave the pressure to the remaining parts.

The distinction between local efficiency and global efficiency is a key concept in systems thinking. Local efficiency refers to the output rate of a single link or individual, while global efficiency refers to the throughput capacity of the entire value stream from demand to delivery. In complex systems, pursuing maximum local efficiency in every link often backfires: if upstream links accelerate output and downstream links cannot absorb it in sync, queues, backlogs, and rework form, and global efficiency instead declines. This is especially true in software delivery because the links are highly coupled and contain feedback loops—defects found in review flow back to coding, test failures trigger debugging, and deployment problems force architecture adjustments. AI coding tools improve the local efficiency of the coding link, but may intensify system oscillation because the absorption capacity of downstream links remains unchanged. The truly effective improvement strategy is to make systematic optimizations around the bottleneck link, rather than pursuing isolated single-point speedups.

One-line Summary

AI-automated coding has not reduced the number of engineers or improved profits; instead, it has migrated the bottleneck from coding to downstream links such as review and testing.

Paragraph Summary

Based on observations from a tech professional's tweet, the article points out counterintuitive phenomena after the spread of AI coding tools: the number of engineers is not decreasing but increasing, work intensity is not falling but rising, code is almost entirely written by agents, yet corporate profits have not improved markedly. The author argues that these four observations together reveal one fact—automation does not eliminate bottlenecks; it migrates them. AI lowers the marginal cost of software production and unlocks more demand, offsetting job-reduction effects; after coding is automated, engineers turn to review, validation, and system design, and cognitive load does not decrease; and coding is only one link in the delivery chain, so local acceleration shifts pressure to review, testing, deployment, and other links, meaning global delivery capacity does not improve in sync. The article ultimately advises managers and engineers to re-examine the value chain from a systems perspective, focus on new constraint points, and notes that core competitiveness is shifting from coding implementation to system judgment and quality gatekeeping.