Alexandru Nedelcu argues that the central risk in AI-assisted programming is not a single obvious error. It is the delayed accumulation of design choices that make software difficult to understand, change, and test. His warning is aimed less at the models themselves than at organizations that let generated code replace human judgment and the experience gained from correcting mistakes.
The argument begins with a measurement problem. Maintainability is not usually visible when a feature first works, and the effects of weak architecture may take months or years to surface. A codebase can appear productive while hidden dependencies, unclear invariants, duplicated logic, and brittle tests make each future change more expensive. Nedelcu therefore treats maintainability as a long-horizon property rather than a quality that can be guaranteed by a conventional linter or an immediate test result.
That distinction matters because machine-learning systems require measurable feedback. If the available reward reflects whether code runs today, a model can improve short-term behavior without learning whether the resulting design will remain coherent after several releases. This supports a narrower version of Nedelcu’s claim: automated code generation can optimize for outcomes that are easy to observe while missing consequences that emerge later. It does not establish that every model lacks useful architectural knowledge, nor does it show that all AI-assisted projects deteriorate.
Nedelcu also argues that expertise depends on experience with failure. Engineers learn which abstractions are genuinely reusable, which shortcuts create future constraints, and when a local simplification obscures the system’s intent. If developers stop reading or writing code, he argues, they lose opportunities to make those judgments and learn from their consequences. The resulting risk is institutional: knowledge about why a design works—or no longer works—may not be retained when responsibility is routinely transferred to a tool.
The supplied Dreyfus model of skill acquisition provides context for this part of the argument. It describes learners beginning with explicit rules and procedures, then gradually developing more intuitive, context-sensitive judgment through experience. It also warns that continued reliance on conscious rules can prevent progress beyond competence. That framework makes Nedelcu’s concern intelligible, but it is not independent evidence that AI coding produces the same effect. The model describes a theory of skill development; it does not test coding agents, measure software maintenance, or validate the article’s forecast.
A practical question follows: can teams use coding agents without surrendering architectural judgment? The evidence supplied does not settle that question. It does, however, suggest what responsible use would need to preserve: engineers must inspect generated changes, understand the design tradeoffs, maintain tests that exercise meaningful behavior, and revisit decisions as requirements evolve. Automation can handle repetitive work while people retain responsibility for boundaries, invariants, and the reasons behind a design.
The evidence also leaves important comparisons unresolved. It offers no controlled study of AI-assisted versus human-written code, no longitudinal measurement of maintenance cost, and no proof that a “no-AI” policy creates a competitive advantage. Nor does it establish that code quality has no useful metrics. The defensible conclusion is narrower: easily measured signals are incomplete proxies for long-term maintainability, and organizations should not treat a passing build as evidence that a design will age well.
For readers, the useful lesson is operational rather than anti-technology. Keep humans in the loop where decisions have consequences that will not be visible immediately. Record architectural rationale, require substantive review, and treat generated code as a proposal to understand—not as an autonomous source of wisdom. That approach preserves the efficiency benefits of automation while addressing the specific failure mode Nedelcu identifies: a codebase that works now but becomes increasingly difficult for its own team to change.