AI Agents Write More Code. Who Makes the Decisions?

A small MIT study found that excessive reliance on AI can contribute to cognitive atrophy and the shrinking of critical thinking skills. A separate Microsoft study found that the more confidence a worker placed in an AI tool's ability to handle a task, the less critical thinking effort they applied to it.

Both findings appeared in an engineering-governance analysis dated November 13, 2026. The source frames a practical risk for engineering and IT leaders: AI can raise coding output at marginal cost while quietly transferring decisions from people to models. The danger will not appear as a drop in activity. It will emerge later as a gap between what the product does and what customers need.

What changes when AI writes the code?

Engineering and IT teams use AI for structured, predictable work, including boilerplate code, test scaffolding, system migrations and access provisioning. The analysis also places those tools across the full service lifecycle, from research and requirements through implementation, deployment and incident management.

That reach matters because output measures do not reveal who makes consequential choices. A team can count pull requests, commits and merges, but those figures cannot show whether a developer or an AI agent called the shots.

The analysis argues that AI has moved the main constraint in software development from writing code to choosing the right thing to build. Leaders therefore need to measure how their teams decide, not simply how much they use AI.

The source warns that teams may hand off more decisions as they grow comfortable with AI, often without noticing. Activity dashboards will not flag that decline. The visible failure will come later, when software behavior drifts further from customer needs.

What do the studies say about critical thinking?

The Microsoft result describes a confidence effect: greater trust in an AI tool's task-handling ability corresponded with less critical-thinking effort. The small MIT study points to a longer-term risk, linking excessive reliance to cognitive atrophy and weaker critical thinking skills.

The analysis treats those findings as relevant to agentic AI, which makes decisions and takes actions rather than only suggesting code. When a system can execute an entire process, developers and IT leads may see no obvious point at which to intervene.

That setup can make engineers complacent and push them toward deferral. The source warns that AI-use metrics cannot detect the change in decision ownership. They record production activity, not the erosion of human judgment.

Can reflection preserve human judgment?

Anthropic launched a reflect feature to acknowledge the problem and begin addressing it. The tool lets users examine how they have used the large language model and evaluate the platform's role in their life.

One question available through the feature is: “What's one thing you want to keep doing yourself, even if Claude could do it faster?” The prompt turns reflection toward work that people may want to retain even when an agent can complete it faster.

The analysis says reflection only becomes useful when teams connect it to outcomes. Teams should identify AI outputs they accepted without verification and later caused rework. They should also record where AI actions improved a customer, product or business result, and where activity produced only motion.

Under the source's framework, that record separates useful assistance from unexamined acceptance. It gives leaders evidence about the results of AI work rather than treating usage volume as a proxy for performance.

Where should humans keep the decisions?

The source sets an explicit operating rule: “AI generates options and code, but humans decide what to build.” Leaders must state that standard directly because measurement alone will not preserve judgment.

The analysis also warns against automating every tedious function. Manually outlining code architecture, investigating edge cases and mapping product dependencies can look routine, yet each forces engineers to reason through architectural trade-offs and real-world needs.

A hasty, unstructured rollout treats AI as a quick fix for broken processes. According to the source, that pattern creates unwarranted trust and encourages engineers to use the tools as shortcuts. Starting implementation with structure matters because the adoption process sets the tone.

The proposed boundary leaves AI with mechanical busy work while developers retain ownership of choices tied to business value. Product judgment, architectural reasoning and customer fit remain on the human side of the handoff.

How should leaders govern AI agents?

Development and IT teams already govern employees through defined boundaries, assigned roles and explicit operating expectations. The analysis recommends extending those frameworks to AI agents rather than treating an agent as another ungoverned tool.

The source uses employee onboarding as an analogy and requires administrators to establish three controls:

• Create each agent's unique identity.
• Designate its operational scope.
• Establish its exact responsibilities.

According to the source, distinct identities should make each agent traceable and auditable across the entire IT portfolio. The record must show exactly what actions the agent took.

The system should also expose whether a human verified an action or allowed a model to execute it blindly. That visible step should prevent developers from handing over responsibility simply because the software ran the process.

Hard-coded restrictions can block strategic product choices, including an auto-generated feature specification that drifts from customer needs. The source presents these limits as guardrails for agents with authority to act, not as optional guidance.

How should product scoping work?

During feature scoping, an unconstrained AI might generate a product roadmap and draft user stories from market averages. The analysis says those averages can push the work away from the customers and context that product leads must evaluate.

Under the governance model in the source, an agent should instead synthesize user feedback and identify pattern gaps. Those tasks gather evidence without deciding which opportunity deserves engineering capacity.

A hard-coded halt before product requirements forces product leads and engineers to assess market fit and choose which features merit engineering resources. Human ownership returns at the point where customer evidence becomes a build decision.

This sequence implements the source's call for deliberate friction. It also prevents an agent's speed from turning into an unquestioned roadmap, preserving the product decisions that require accountable human judgment.

What becomes the competitive advantage?

The analysis argues that coding speed is no longer a durable differentiator when the market has broad access to the same tools. More code can carry less strategic value when nobody can explain why a feature should exist or which customer problem it solves.

Its proposed advantage is judgment: knowing which features will help customers and retaining accountability for choices that affect business value. Clear governance, bounded agent identities and deliberate friction should make technology a lever for human expertise rather than its substitute.

The test for AI-enabled engineering teams will not be how much code they ship, the source concludes, but whether people remain accountable for the product decisions that determine customer and business value.