Conscious AI Coding – Skills, cognitive load and epistemic fragility

Cognitive load, boring work and team well-being

The AI productivity paradox and the cognitive role of “boring work”

The emotionally compelling narrative that AI assistants free developers from repetitive work so they can focus on higher-value activities assumes that constantly operating at a high cognitive intensity is beneficial. Research on cognitive load suggests the opposite: low-intensity tasks — such as writing boilerplate code, formatting documentation, or performing mechanical refactoring — serve a mental recovery function similar to rest, allowing consolidation and reflection processes to operate in the background.

Eliminating these activities does not simply “free up time”; it removes recovery opportunities from an already demanding workday.

This is the AI productivity paradox [1]: when workers are deprived of these cognitive breaks, they enter a state of continuous overload [2] that ultimately reduces the quality of thinking applied to genuinely complex tasks.

Martyn Redstone argues that those “boring” tasks often represented the only form of mental breathing space within a developer’s workflow. Their disappearance transforms the workday into an uninterrupted sequence of high-impact decisions, increasing the risk that decision quality deteriorates over time — often in ways that are difficult to measure in the short term, because developers continue producing output while their critical judgment gradually declines.

Sense of Control and Loss of Agency

The feeling of mastery and control over one’s work is a key factor in job satisfaction and resilience, consistently documented in research on workplace well-being. When most code is generated by an external system and the developer’s role increasingly becomes that of a validator, this sense of agency may diminish.

In its analysis of the cognitive structure of AI-assisted work, Citrix argues that many AI strategies focus on the wrong layer of the cognitive stack: they automate execution without providing sufficient support for understanding, context, and decision-making, leaving workers responsible for managing the most complex aspects of the process.

Skill erosion and its impact on engineering development

Skill atrophy and the impact on junior developers

In cognitive psychology, automation bias [5] — the tendency to place excessive trust in automated systems — has been documented for decades in fields such as aviation, medicine, and assisted driving.

The mechanism is similar in software development: continuously delegating cognitive tasks to AI reduces opportunities to exercise the corresponding skills. Cognitive abilities, much like physical ones, are maintained through use. Developers who no longer write algorithms from scratch, debug without assistance, or design architectures independently gradually lose fluency in these activities and become less capable of reactivating those skills when faced with unfamiliar challenges.

This risk is particularly acute for junior developers, whose engineering education largely occurs through hands-on experience: writing code that fails, understanding why it fails, and rewriting it with deeper comprehension.

When an AI assistant generates a solution to a problem that has not yet been fully understood, this learning phase is bypassed. The result is often working code, but without the cognitive process that would have built the understanding needed to reason independently about similar problems in the future.

The impact on experienced developers: from builders to validators

For senior developers, the primary risk is not the loss of foundational skills — the mental models built over years of experience are generally robust — but rather a qualitative transformation of their role: from active builders of complex systems to validators of AI-generated code.

Validation is cognitively different from creation. It requires identifying flaws in an existing artifact rather than constructing a correct artifact from first principles.

Over the long term, professionals who spend most of their time validating and rarely building may find their ability to start from a blank page in unfamiliar contexts gradually diminished.

Organizational dependencies and reduced autonomy

At the organizational level, one of the most significant risks is dependency on proprietary third-party tools for a core software engineering function.

Such dependency has implications for costs (pricing changes and vendor lock-in), security (data sent to cloud services), and operational continuity (service outages, API changes, and product end-of-life scenarios).

There is also a subtler risk: concentrating organizational know-how on “how to use AI tools” rather than on “how to build software.”

Epistemic fragility and the future of engineering thinking

Delegating reasoning: problem solving vs. prompt crafting

The deepest concern is what happens when not only code writing, but also problem analysis, solution identification, and trade-off evaluation are systematically delegated to AI.

The Frost & Sullivan Institute articulates this concern clearly: we are building systems that are increasingly capable of providing answers, but what effect does this have on our ability to ask the right questions? [6]

Formulating a precise and productive question requires sufficient domain understanding to know not only what one knows, but also what one does not know.

There is also a significant difference between “understanding a problem and building a solution” and “describing a problem in such a way that an AI system generates a satisfactory solution.” Both activities require real and non-trivial skills, but they are fundamentally different processes that produce different forms of understanding.

If training increasingly focuses on writing effective prompts rather than reasoning independently about complex systems, organizations may end up cultivating competencies that prove insufficient whenever AI is unavailable, inappropriate for the problem at hand, or produces flawed outputs that require correction.

Even in this new era, the Agile Manifesto’s principle [7] of “continuous attention to technical excellence and good design” remains as relevant as ever.

The disappearance of the ambiguous question and neuropsychological evidence

UNESCO education experts have identified an important phenomenon: AI systems favor well-formed, answerable questions, and users gradually adapt their questioning style to fit the capabilities of the system.

The result is the progressive disappearance of “ambiguous questions” [8] — those that are poorly defined, exploratory, and lacking a clear answer, yet often serve as the starting point for brainstorming, creativity, and innovation.

In software engineering, many of the most important questions belong to this category:

What problem are we really trying to solve?
What assumptions are implicit in this architecture?
How should this system evolve over the next five years?

These are not questions that can easily be delegated to an AI assistant, and they risk being sacrificed within workflows optimized for speed and output.

The most direct empirical reference comes from the MIT Media Lab study Your Brain on ChatGPT [9] by Kosmyna and colleagues, published as a preprint in the summer of 2025.

The study assigned 54 participants to three groups — “LLM,” “search engine,” and “brain only — and asked them to complete writing tasks over multiple sessions spanning four months, while measuring brain activity through EEG.

Neural connectivity was found to be inversely proportional to the level of external support. The “brain only” group exhibited the broadest and most active neural networks, while the “LLM” group showed the weakest overall connectivity.

When participants in the LLM group were later required to complete tasks without access to the AI tool, researchers observed under-activation of alpha and beta networks, difficulty recalling text written only minutes earlier, and a significantly lower sense of ownership over their work compared to the other groups.

The authors themselves highlight important limitations:

• a relatively small sample size (54 participants);
• geographic concentration;
• a context limited to academic writing;
• peer review not yet completed.

The study should therefore be viewed as preliminary evidence that frames the question rigorously rather than as definitive proof.

Nevertheless, the documented mechanism — reduced neural connectivity associated with increasing external support, coupled with retrieval difficulties once that support is removed — is conceptually consistent with the established literature on neural plasticity and automation bias.

If continuous AI usage gradually reshapes cognitive patterns, the implications for long-term engineering education remain both open and legitimate.

Conclusions

Summary of the key risks

The analysis presented across these two articles identifies a set of interconnected risks that reinforce one another:

• Quality and maintainability: AI-generated code, when insufficiently scrutinized, can accumulate into fragile and inconsistent architectures, creating technical debt that remains largely invisible in the short term.
• Security: Code generation speed can outpace security review capacity, producing an empirically documented surge in AI-related vulnerabilities.
• Workflows: Vibe coding compresses design and reflection phases, creating local optimization at the expense of overall system quality.
• Productivity: Productivity gains are real, but often concentrated in narrowly defined tasks and overstated when downstream costs such as debugging, reviews, and incidents are taken into account.
• Cognitive well-being: Eliminating “boring” work removes opportunities for cognitive recovery, increasing decision fatigue within teams.
• Skills: Continuous cognitive delegation contributes to the gradual erosion of engineering capabilities.
• Epistemic capability: Replacing independent reasoning with prompt crafting risks producing professionals who are less capable of understanding, modeling, and reasoning about complex systems.

A Balanced Position

None of the risks discussed here constitute a sufficient argument for abandoning AI tools altogether. Such a conclusion would be just as simplistic as their uncritical adoption.

AI is a powerful tool that, when used in appropriate contexts and supported by effective governance, can create genuine value.

But — and this is an important caveat — it is not a neutral tool.

Like any technology that profoundly reshapes cognitive and organizational processes, it introduces trade-offs that must be consciously identified, evaluated, and managed.

As an example, I want to be completely transparent about how these very articles were produced.

During the research, source collection, validation, and initial drafting phases, I used several AI tools as assistants: Claude, Perplexity, ChatGPT, and Gemini.

Their contribution was tangible and valuable. They accelerated the collection of references, helped uncover connections between sources, and provided an initial structure on which to build.

It would be dishonest not to acknowledge that.

However, it would be equally dishonest not to clarify that I reread and revised every section, rewrote substantial portions of the text, verified and replaced sources where appropriate, corrected passages that drifted away from their original references, and incorporated feedback and improvements suggested by colleagues who reviewed the draft.

In this regard, I would like to sincerely thank Manuel Bonini and Simone Recupero for their invaluable support and the insightful discussions we shared throughout the process.

AI contributed to the efficiency of the workflow, but intellectual responsibility for the content remains with the person who signs it.

This is precisely the kind of conscious and responsible use of AI tools that these articles seek to advocate.

Practical implications

For those working in software engineering, several practical directions emerge from this analysis.

Development practices

Reintroducing controlled friction into AI-accelerated processes is not a conservative reflex; it is a rational response to documented risks.

Amazon implemented such measures reactively after an incident. Organizations can choose to do so proactively.

In practice, this means maintaining explicit and non-compressible design phases and distinguishing between contexts where pure vibe coding is appropriate — such as prototyping and exploratory spikes — and contexts where it is not, such as production systems or security-sensitive code.

Several frameworks have emerged specifically to integrate established software engineering practices with AI-assisted development, and they appear to offer a promising path for managing complex systems.

In particular, Spec-Driven Development [10] frameworks such as BMad Method, Spec Kit, or OpenSpec deserve attention.

Education and training

Organizations that invest in AI without simultaneously investing in the preservation of core engineering skills are optimizing for the short term.

I do not claim to have definitive answers, but I believe training programs should continue to deliberately include difficult work — such as unaided debugging, architecture design from first principles, and in-depth code reviews — not as relics of a past era, but as exercises that preserve and strengthen essential engineering capabilities.

Metrics

Replacing throughput metrics — such as pull request velocity, lines of code, or features shipped — with outcome-oriented metrics is necessary to evaluate the true contribution of AI tools.

Relevant measures include:

• system stability;
• maintenance costs;
• mean time to incident resolution;
• review quality;
• long-term architectural health.

Only by measuring outcomes rather than output can organizations accurately assess whether AI is generating sustainable value.

The open question

At its core, software engineering is the discipline of building systems that solve complex problems in a reliable and maintainable way.

This activity requires — and has always required — a combination of technical knowledge, systems thinking, judgment regarding trade-offs, and a deep understanding of the human contexts in which software operates.

The question the industry must now confront is this:

Do we want to build an ecosystem of tools and practices that preserves, develops, and transfers these capabilities to future generations of engineers?

Or are we optimizing for short-term metrics that create the appearance of progress while quietly eroding the very foundations upon which that progress depends?

References

1. eLearncollege — “Paradox of AI productivity shows boring work need” https://elearncollege.com/business-and-management/paradox-of-ai-productivity-shows-boring-work-need/
2. Fortune — “AI workers’ productivity, brain recovery, cognitive offload overload” (apr.2026) https://fortune.com/2026/04/11/ai-workers-productivity-brain-recovery-cognitive-offload-overload/
3. LinkedIn / Redstone — “Why the boring tasks you are automating were […] keeping your workforce sane” (dic.2025) https://www.linkedin.com/pulse/why-boring-tasks-you-automating-were-actually-only-thing-redstone-o1dye/
4. Citrix — “Understanding the cognitive stack: why your AI strategy is focused on the wrong layer” (feb.2026) https://www.citrix.com/blogs/2026/02/25/understanding-the-cognitive-stack-why-your-ai-strategy-is-focused-on-the-wrong-layer/
5. Forbes — “Automation Bias: What It Is And How To Overcome It” (mar.2024) https://www.forbes.com/sites/brycehoffman/2024/03/10/automation-bias-what-it-is-and-how-to-overcome-it/
6. Frost & Sullivan Institute — “When AI generates the answers, are we losing our ability to ask the questions?” (mar.2026) https://frostandsullivaninstitute.org/when-ai-generates-the-answers-are-we-losing-our-ability-to-ask-the-questions/
7. Agile Manifesto – “I princìpi“ https://agilemanifesto.org/iso/it/principles.html
8. UNESCO — “The disappearance of the unclear question“ (giu.2025) https://www.unesco.org/en/articles/disappearance-unclear-question
9. Kosmyna N. et al., MIT Media Lab — “Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task“ (preprint, giu.2025) https://www.brainonllm.com/ — Preprint Arxiv: https://arxiv.org/abs/2506.08872
10. Medium — “Spec Driven Development“ (mar.2026) https://medium.com/@visrow/spec-driven-development-is-eating-software-engineering-a-map-of-30-agentic-coding-frameworks-6ac0b5e2b484
11. Augment Code — “6 Best SDD Tools for AI-coding“ in 2026 (mar.2026) https://www.augmentcode.com/tools/best-spec-driven-development-tools