Introduction: The Ghost in the Codebase
I started my professional journey in 1986. It was the era of Honeywell systems, Commodore 64s, and developing management software in DataFlex on Concurrent-CPM. Back then, "compute" was a luxury; we planned every line of code because a single compilation could take enough time to grab a coffee—or two.
Fast forward to 2026. I am reading the latest Anthropic paper, "When AI builds itself". It describes a world where the "doing"—writing code, running experiments, and identifying bugs—is being delegated to autonomous agents. As a retired architect who still keeps his mind active by building, I see a fascinating but dangerous gap between the productivity metrics of big labs and the reality of sustainable, professional engineering.
1. The "8x Productivity" Illusion
The Anthropic report makes a staggering claim:
"Today, Anthropic engineers on average ship 8x as much code per quarter as they did from 2021-2025".
Furthermore, as of May 2026, more than 80% of the code merged into their codebase is authored by Claude. To a manager, this sounds like a dream. To a Senior Architect, it looks like a potential nightmare of technical debt.
Anthropic themselves admit a crucial limitation: while AI is superhuman at optimizing code (achieving up to a 52x speedup in specific tests), there are still "large performance gaps when it comes to Claude exercising judgement in choosing goals".
In my 40 years, I’ve learned that "choosing the goal" is the job. Writing the syntax is just the clerical work. If we automate the clerical part but lose the "judgment," we aren't 8x more productive—we are just 8x faster at creating complexity we don't fully understand.
2. The Economic Barrier: $18,000 for a "Thought"
One passage in the paper highlights the massive infrastructure gap facing freelancers and small shops:
"The agents recovered 97% of the gap [in a research project] over 800 cumulative hours and used roughly $18,000 in compute".
Most independent developers cannot afford an $18,000 "experimental loop" for a single feature. This is why I built LLM-Manager using Pure Bash. My goal is the opposite of a recursive loop that burns through thousands of dollars in cloud tokens. I want zero-overhead, OS-level access, and hardware-aware orchestration that allows a developer to run local models (Ollama/Llama.cpp) with the efficiency of a 1980s engineer but the power of 2026 AI.
3. The "Vibe Coding" Trap and the Need for Determinism
We are seeing a trend called "Vibe Coding"—the idea that you can just "talk" to an AI, trust the output, and let it build. But "vibes" don't catch critical bugs.
- The Moonwell DeFi Hack: In February 2026, a basic miscalculation in an AI-generated smart contract (authored by Claude Code) led to a $1.7 million loss in four minutes.
- The Responsibility Gap: AI does not feel the weight of a system downtime. It simply continues to generate "statistically plausible" answers.
This is why my project, RAG-System-Dist, prioritizes determinism and traceability over opaque automation. I don't want an AI that "vibes" its way to an answer. I want a system where every response is linked to a source that I, the human expert, can verify with a single "Point-and-Click".
4. My Philosophy: Code is Craft
On my site, nospace.net, I advocate for a simple principle: Code is Craft.
To me, being a developer in the age of LLMs isn't about knowing the syntax of C++, Python, or Java—the AI has already "saturated" those benchmarks. It is about the Architecture of Intent.
I even created a Hostile Architect Configuration for GitHub Copilot as a joke (but not too much). Why? Because AI is often too polite; it tells you your bad ideas are good ones. Real engineers need a reality check. They need to understand the why before the how.
5. The Path for the Next Generation
My fear for junior developers is that they might get trapped in an "addictive" cycle of AI-dependency, losing the ability to think through architectural trade-offs.
If you want to survive the next 40 years in IT:
- Master the Patterns: Understand the redundancies.
- Maintain Control: Use the AI to speed up the writing, but never delegate the thinking.
- Stay Deterministic: Build systems that are verifiable and auditable.
There isn't a single "right" way to implement a solution, but there is a way that follows your mind. If the code is part of your thinking, it will still be clear to you a year from now.
Final Thoughts: Responsibility and Ownership
Only an experienced engineer can evaluate architectural trade-offs, check if a solution fits the real business context, and take responsibility for the final product. Today, AI is not the brain of development, but its hands. It makes the process faster, but direction and meaning must still come from a human.
If the code is part of your thinking, it will still be clear to you a year from now. If it’s just a "vibe," it will be a ghost in your codebase.
P.S. Maybe I’m just "old-school"? Or perhaps 40 years in the trenches have given me a different perspective on what "craft" really means. What do you think? Are we gaining productivity or just losing control?
About the Author: I am an IT operator with 40 years of experience. I’ve seen the world move from floppy disks to recursive AI agents, and I still believe that the most important "compute" happens between the ears of the engineer.
Note: This post was originally written in Italian my native language and refined to English with the assistance of an LLM to ensure technical clarity.
