Acceleration, its psychological costs, and the changed dynamics of building software. July 2026.
Abstract
Large language models have sharply shortened the distance between an idea and a working artifact. For small, well-scoped work that distance is now minutes or hours. For real systems the compression is significant but uneven. This does more than speed up existing practice. It changes the emotional, cognitive, and social structure of software work, and it does so differently at each level: the individual engineer, the team, the organization, and the customer.
A note on reading this document. Sections 1 and 2 can be read independently. Section 1 covers what happens to individual engineers and teams and will matter most to people managing or experiencing the work. Section 2 covers organizational economics, delivery dynamics, and customer effects. The two are connected: nearly every business effect in Section 2 is a psychological effect from Section 1 aggregated to institutional scale, and the disciplines in Section 4 only work if both halves are understood together.
1. Effects on People
1.1 The Individual Engineer
Lone-wolf acceleration and isolation. When one person can hold continuous context and produce working changes at high velocity, the cost of bringing others up to speed feels disproportionate. The rational response, moment to moment, is to keep going alone. Shared mental models erode and mentoring becomes rarer. The engineer gains agency but experiences a quiet alienation: meaningful progress happens mostly in private dialogue with models rather than with colleagues.
Feature accumulation and the collapse of generation friction. Anything that can be described can usually be prototyped quickly. This weakens classical ROI intuition, but not because effort has vanished. Effort has moved, from generation to verification, integration, and maintenance, where it is deferred and far less visible. The generation step feels nearly free, so the decision to build gets made against an effort estimate that no longer reflects where the real cost sits.
Each completed micro-feature also delivers a small, immediate reward. The work rhythm shifts from intermittent, high-intensity satisfaction, the feeling of finally cracking a hard problem, to a continuous stream of minor completions. In behavioral terms this resembles a variable-ratio reinforcement schedule: frequent, unpredictable small rewards, the pattern most effective at sustaining compulsive engagement. The word "addiction" deserves care, but several of its markers are visible in practice: the urge to start another prompt while one is still running, irritation when the tool is unavailable, and continued heavy use by engineers who admit it fragments their focus. The strongest version of this signal is an accident of research design. METR's 2026 follow-up study was partly compromised because between 30 and 50 percent of invited developers declined to work without AI at all, even for payment.
The transformed nature of flow, and context-switch overload. Classic programming flow was sustained immersion in a single hard problem. The new state is the management of parallel agents and several concurrent threads. Starting a new task is cheap and immediately rewarding, and waiting feels intolerable: while one agent works, the natural move is to fire off another. Engineers end up supervising three or four live threads at once.
Each individual switch feels free, but the cumulative cost is real. Attention residue lingers with the previous thread, working memory holds several partial mental models at the same time, and none of them reaches the depth that single-threaded immersion once produced. The result is high stimulation and a strong subjective sense of productivity, together with fragmented attention and a distinctive end-of-day fatigue: tired from switching rather than from thinking.
Cognitive offloading and skill atrophy. A practical response to limited human bandwidth is to route plans and generated code through additional models for review rather than reading every line. Trust moves from line-by-line comprehension toward higher-order signals: does the change match the stated intent, and do the tests pass? Research on comprehension suggests a cost. Developers who lean heavily on AI assistance tend to perform worse when later asked to explain or debug what they shipped. The friction that once built mastery was not waste. It was the training signal. Removing it makes each task easier and the person, over time, more dependent.
Ownership, identity, and imposter dynamics. When a large share of the code is generated, a quiet question surfaces: is this still my code? Pride, care, and long-term stewardship can soften. Professional identity shifts from "I write code" toward "I direct systems that write code." Imposter feelings cut both ways. The tools let people ship things that previously felt out of reach, and at the same time plant the doubt that none of it would have happened without the model.
New burnout and the responsibility gap. Old burnout was often stagnation: stuck, making no progress. The new variant is the opposite. Shipping constantly while the queue of generated work, and the verification debt behind it, never ends. Speed becomes the baseline against which one is judged, including by oneself.
When something fails in production, accountability feels diffuse. Me, or the model that wrote most of it? Precision matters here. Legal and professional accountability has not diffused at all. Only the feeling has. That gap between felt and actual responsibility is itself a hazard, because engineers may under-invest in verification exactly where they remain fully answerable.
Process is a weak remedy for this, because process addresses the feeling rather than the structure. What blunts responsibility diffusion reliably is ownership that cannot be delegated to a model: the team that ships carries the pager, the author of the change is the person paged for it, and the on-call rotation does not care who or what generated the diff. Organizations with that structure already in place report the identity question without the accountability drift, because production consequences arrive addressed to a person regardless of provenance. Organizations that separated authorship from operational consequence before AI arrived find the drift much harder to contain now.
Build-versus-adapt inversion. When generation is cheap, the default flips from finding and adapting an existing tool to building a tailored one. Code becomes a universal solvent. Small internal tools appear for every friction point, each individually rational, together a growing maintenance surface that nobody chose deliberately.
1.2 The Team
Erosion of shared context and the mentoring pipeline. High-velocity individuals pull ahead, and synchronization feels expensive relative to its immediate payoff. Juniors produce more output earlier, but the channels through which seniors pass on tacit knowledge, pairing and review conversations and watching someone struggle productively, become less natural when the intermediate work is mediated by models.
This has a consequence beyond any single team. If the friction that builds fundamentals is skipped at the start of careers, it is unclear where the next generation of senior engineers comes from. The capability gap widens in both directions: those with strong foundations gain leverage, those without gain speed while staying fragile. Organizations feel this as a hiring problem several years before they can trace it back to a mentoring problem.
Parallelism and conceptual merge conflicts. Worktrees plus multiple agent sessions make concurrent exploration trivial, so divergent implementations of the same intent get pursued simultaneously. When branches reconverge, the conflicts are often conceptual rather than textual: alternative designs that both work. Reconciliation becomes a concentrated decision burden landing on whoever holds architectural authority. It is the same context-switch overload described above, replayed at team scale.
Review capacity as the new bottleneck. Generating tests is cheap, so pipelines grow denser. Each test adds confidence in isolation; together, runtime and flakiness lengthen feedback loops. The bottleneck moves from human review to infrastructure, and then back to humans in a new form: field analyses of large developer populations report that AI-authored pull requests reach review faster and then wait substantially longer inside it. Generation accelerated. Trust did not. Test-suite hygiene competes with the more immediately rewarding activity of shipping the next feature, and predictably loses.
Dependency dynamics. Models show two opposing tendencies, and both cut in both directions. One is reinventing functionality in self-contained code, which brings subtle bugs and duplicated logic. The other is freely pulling in packages, which brings dense graphs, version sprawl, and lengthening security findings, along with occasional references to packages that do not exist.
The second tendency is frequently the safer one, and this is underappreciated. The classic human failure mode in security-sensitive code is hand-rolling: custom crypto, custom session handling, custom input parsers, written by someone who has not read the relevant literature and will not be maintaining it in three years. A model that reaches for a maintained, widely audited library instead is making the textbook-correct choice, and it makes that choice more consistently than the median developer does under deadline. This is the same competence pattern described in the customer section: models are reliable on well-documented flaw classes, and library selection is precisely such a class.
What remains genuinely worse is the aggregate. Individually sound dependency choices accumulate into a graph nobody designed, with transitive exposure nobody evaluated and upgrade paths nobody owns. The risk moved from the function to the manifest. That is a real shift and probably a net improvement in per-decision quality, paired with a net degradation in portfolio management, and it needs governance at the manifest level rather than suspicion at the import level.
2. Effects on the Business
2.1 The Organization
Token economics and the sustainability tension. In intensive environments, consumption has grown fast, in some organizations doubling over weeks to months as usage moved from individual experimentation to team-wide default. This trajectory does not fit fixed budgets.
The conflict is structural rather than a matter of anyone behaving badly. Engineers experience the tools as cognitive leverage and resist restriction. Teams fear losing competitive velocity. Finance sees an expanding, poorly bounded cost center with no unit economics attached. Resolving it requires three things: visibility through per-session and per-outcome cost attribution rather than aggregate spend, a shared vocabulary for distinguishing high-leverage from low-leverage usage, and cultural acknowledgment that unconstrained generation is a phase rather than an entitlement.
The inverted dynamics of building. Software construction used to proceed from the inside out: data model, core logic, interfaces, and only late in the process something a stakeholder could see. AI-assisted development inverts this. A convincing, interactive surface appears first, in hours, and the internals are filled in behind it.
Decisions that were once forced early, including data contracts, failure modes, and operational design, can now be deferred, because a working façade does not require them. Architecture becomes something excavated underneath a running system rather than designed ahead of one. And the prototype is no longer a disposable sketch. It is the seed the real system grows from, carrying whatever assumptions were baked in during the fastest and least considered phase of the work. Organizations that do not deliberately schedule the deferred decisions meet them later as incidents, migrations, or rewrites.
Underestimation of systemic impact from easy rewrites. Asking a model for a large architectural change often succeeds, superficially, in minutes. The surface result looks clean. The downstream effects on performance under load, operational complexity, migration cost, and conceptual consistency are routinely larger than expected. Because the generation step was contained, the change feels contained.
Combined with deferred architecture, this produces a characteristic drift: systems that were never designed get repeatedly redesigned, cheaply and locally, without anyone pricing the global cost.
2.2 The Customer
Expectation inflation and perceived completeness. The demo-first inversion is exactly why customers perceive near-completeness. What they can see and click appears finished, and the deferred internal work is invisible by construction. Stakeholders who experience rapid prototyping recalibrate their baseline for every later request, and the window in which "this is still early" stays credible keeps shrinking.
From abstract discussion to concrete interaction. Design conversations now happen against running artifacts rather than static mockups. This is a genuine improvement, because alignment is easier when stakeholders can interact with something real. It also inflates the perceived value of early artifacts relative to the engineering that remains, sharpening the expectation problem it helps solve.
What the customer actually receives. Expectation management is only half the customer story. The other half is the delivered artifact, and here the evidence supports a more specific claim than either the alarmist or the optimistic reading.
Longitudinal testing across more than 150 models found secure-generation pass rates essentially flat from 2025 through mid-2026, averaging in the mid-fifties as a percentage of security-relevant tasks completed without introducing a known flaw. Capability climbed steeply over the same period; this number did not follow. Models specialized for coding performed no better than general-purpose ones.
Comparative work against human baselines is thinner and should be read carefully. A July 2026 multi-tier verification study found AI-generated C++ substantially more vulnerable than human-written equivalents under dynamic analysis, with the effect surviving adjustment for correctness and clustering. That is stronger methodology than the vendor self-studies it supersedes, but its scope is narrow: one language, competitive-programming task shapes, and a vulnerability profile dominated by memory safety, which is not where most production risk sits for teams working in managed languages. The more important finding from that same work is methodological. Static analysis failed to detect the gap at all, and reversed direction once code length was controlled, meaning static warning counts are not a reliable security signal on generated code. Combined with the absence of any standardized method for comparing human, model, and hybrid authorship on equal terms, the honest position is that the comparative question remains open, and that most tooling organizations use to answer it is not measuring what they assume.
Against the optimistic reading, a different distinction matters. The newest models are becoming genuinely strong at security analysis while remaining unremarkable at secure authorship, and these are different capabilities. Frontier models now trace multi-step attack paths, generate adversarial test inputs, and find previously unknown vulnerabilities in widely deployed software. Vendors have begun treating this as a design target, with at least one recent release deliberately unblocking source-code vulnerability discovery on the reasoning that helping engineers find their own bugs reduces vulnerabilities in the world. Plausibly, current models already outperform the median developer on textbook flaw classes: parameterized queries, standard cryptographic primitives, obvious injection surfaces, and the library-versus-hand-rolling choice described at team level. What they do not reliably catch are context-dependent flaws, particularly authorization logic, where the vulnerability is not in the code but in what the code fails to know about the system around it. That is also the category humans are worst at, which is why it survives both.
The durable conclusion is not about any model generation. It is that security has become a budgeting decision. The capability to produce secure code exists and is improving, but it must be deliberately spent on review, scanning, and hardening rather than assumed as a byproduct of intelligence. The customer cannot see whether that spending happened. What they receive is a property of the discipline around the model, not of the model itself.
3. What Changed Over the Past Year
The evidence base matured, and it complicated the story rather than settling it.
The research program that produced the headline 19% slowdown in 2025 now estimates the effect near neutral to positive, while stating openly that it can no longer measure the question cleanly, partly because developers refuse to work in the no-AI control condition. Self-reported gains continue climbing well ahead of anything measurable. On quality, the security curve stayed flat while capability curves rose steeply, and tracked CVEs attributable to AI-generated code rose month over month through early 2026.
Practice changed alongside the evidence. Parallel-agent workflows moved from novelty to default, amplifying both the leverage and the context-switch overload. Token consumption steepened as usage became organizational rather than individual. Models began warning more often about large or risky changes, slightly raising the emotional barrier to careless rewrites even as the mechanical ease of performing them kept increasing. Stakeholder expectations adjusted upward faster than most organizations anticipated.
A counter-trend is emerging in review, though the evidence is still thin. As agent workflows mature and models improve at critiquing their own output, some teams report the review bottleneck easing rather than worsening, on the condition that they invest in scaffolding: writer-verifier patterns, routed ensembles where different models handle different review lanes, and dedicated security agents that threat-model rather than pattern-match. Reported volumes from agentic security review are large enough to suggest something real, though nothing yet separates genuine detection improvement from increased finding counts.
The psychological shift is more clearly observable than the productivity claim. Engineers increasingly report trusting an agent's review over a junior colleague's pull request review, and saying so out loud. This is a third identity shift, following the move from "I write code" to "I direct systems that write code": the move from reviewer to reviewer-of-reviewers. It also closes a loop with the mentoring problem described at team level, and not favorably. Review participation was one of the last remaining channels through which juniors learned by being taken seriously. If agent review is trusted more, that channel narrows for the same reasons the others did, and the narrowing will feel entirely rational at every individual decision point.
One further shift deserves naming separately, because it changes the shape of the problem rather than its content. Model releases now arrive faster than independent evaluation can follow. Security and productivity studies with credible methodology take months; flagship releases arrive in weeks. Organizations are therefore making policy on a permanent lag, and the correct response is to build policy around verification practices rather than around model-specific findings.
4. The Disciplines That Follow
The healthy path is neither unrestricted acceleration nor nostalgic return to pre-AI practice. It is a set of deliberate disciplines matched to the new psychology, and each follows directly from a specific diagnosis above. None of them is novel, and all of them are expensive to sustain in exactly the way that unmeasured costs always are.
Bounded parallelism, against context-switch overload. A personal and team norm for how many live threads one person supervises, treated as seriously as a work-in-progress limit. The cost of exceeding it is invisible in the moment and shows up as fatigue and shallow work.
Protected friction, against skill atrophy and the mentoring gap. Deliberately unassisted work, reviews where the author must explain the code rather than defend the diff, and pairing that survives the economics of speed. With agent review now competing for the same channel, this is the discipline most likely to be cut first and hardest to restore.
Scheduled reckoning, against deferred architecture. Explicit checkpoints where the decisions the prototype skipped get made on purpose, before they surface as incidents. The trigger should be calendar-based or milestone-based, because the system will never feel like it needs it.
Verification as first-class work, against the quality gap. Security scanning and review capacity planned to match generation capacity rather than lagging it, with the newest models pointed deliberately at review rather than only at authorship. Given that static analysis alone appears unreliable on generated code, this means multiple detection layers and human attention concentrated on authorization and business logic, where models are weakest.
Manifest-level dependency governance, against portfolio drift. Ownership of the dependency graph as an artifact in its own right, with someone accountable for transitive exposure and upgrade paths. The per-decision quality of library selection is probably improving; the aggregate is not managing itself.
Undelegatable ownership, against responsibility diffusion. Production consequences addressed to a person, independent of what generated the change. This does more than any process control to keep the felt and actual accountability aligned.
Transparent token economics, against economic drift. Cost attributed to outcomes rather than aggregated, so that conversations about spend can be about leverage rather than austerity.
Measurement, against yourself. The most consistent finding across two years of research is that self-assessed productivity is unreliable, including your own, including in the direction you expect.
All of these compete with activities that feel better in the moment, which is exactly why they have to be institutional disciplines rather than individual virtues.
Core Tension
The properties that produce extraordinary felt speed, cheap generation and parallel exploration and deferred effort, also produce isolation, compulsive engagement, verification overload, expectation mismatch, and economic pressure. They are the same properties viewed from different levels. The technology amplifies what software culture already contained, constructive and pathological alike.
Steering the amplification rather than being carried by it begins with seeing the psychology clearly, and with measuring what the psychology insists on misreporting.
References
Productivity
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
- METR, We are Changing our Developer Productivity Experiment Design, February 2026. metr.org/blog/2026-02-24-uplift-update
- METR, Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity, May 2026. metr.org/blog/2026-05-11-ai-usage-survey
Code security
- Veracode, Spring 2026 GenAI Code Security Update, July 2026. veracode.com/blog/spring-2026-genai-code-security
- Veracode, 2026 GenAI Code Security Report, July 2026
- The Illusion of Safety: Multi-Tier Verification of AI vs. Human C++ Code, arXiv:2607.00107
- Egli and Balebako, How to Compare the Security of Code Written by Humans to LLM-generated Code, arXiv:2606.00186
- Endor Labs, Agent Security League benchmark results, June 2026. endorlabs.com/learn/claude-fable-5-mythos-grade-hype
- Georgia Tech SSLab, Vibe Security Radar CVE tracking, reported March 2026 via Infosecurity Magazine
Review and quality
- CodeRabbit, model review benchmarks, July 2026. coderabbit.ai/blog/opus-5-model-review
- Cycode, 2026 State of Product Security Report
Top comments (0)