Fast Code, Soft Skills?

Chris M. Ward Founder · Chief Executive Officer

Fifteen years ago, developers fought over whether IDEs were “cheating.” Now they’re arguing about AI assistants. The technology changed. The anxiety didn’t.

Fifteen years ago, a frustrated teenager confessed on Reddit:

I cannot handle coding without an IDE.

It was 2010, and the comment section erupted in predictable fashion, “real programmers use Vim”, “you’ll never learn fundamentals”, “autocompletion is a crutch.” The Integrated Development Environment (IDE) was simultaneously miracle and menace. Did it empower developers or infantilize them?

Fast-forward to 2025, and the argument hasn’t evolved. It merely upgraded its buzzwords. The new fight isn’t about IDEs, it’s about vibe coding with AI. Same drama, buzzier buzz.

What Is Vibe Coding, Anyway?

“Vibe coding” is the latest dopamine loop of the digital age: a heady mix of intuition, automation, and aesthetic confidence. You don’t memorize syntax anymore; you “manifest intent.” You open your AI-infused editor, whisper a half-formed idea about a data pipeline, and seconds later the machine scaffolds your repo, writes the unit tests, deploys to a staging container, and comments its own code.

You don’t write software anymore. You describe it.

For a moment, you feel like a wizard. Then something breaks, and you realize you’ve never actually read the code that just crashed production.

The Pattern Always Repeats

The software industry keeps replaying the same argument on progressively faster hardware:

• 1950s-60s: “Real programmers write in assembly”, at least until FORTRAN (1957) proved abstractions could ship.
• 1970s-80s: “Real programmers use vi/Emacs, not IDEs” …never mind that Turbo Pascal (1983) made integrated tools mainstream.
• 1990s: “Real programmers use C, not Java or Visual Basic,” …until Java (1995) and VB showed that managed runtimes and drag-and-drop UIs could build serious software.
• 2000s-2010s: “Don’t copy Stack Overflow answers,” …even as IntelliSense and Quick Info put those answers inside the IDE.
• 2020s: “Real programmers don’t rely on AI copilots” …despite LLMs becoming the new baseline for search, stub-gen, and refactors.

Different buzz, same insecurity. Every generation accuses the next of outsourcing the craft. But what’s really happening isn’t moral decline, it’s automation creep. Every layer of abstraction liberates us from tedium while quietly eroding a piece of hard-won intuition.

The Science of Losing Touch

AI didn’t emerge from the ether. It was built on decades of human expertise, expertise we’re now systematically choosing not to develop in the next generation.

Psychologists and human-factors engineers have spent decades studying this phenomenon, usually in cockpits and control rooms rather than code editors. But the parallels are uncanny.

• Automation bias: You trust machine output over your own judgment (Parasuraman & Riley, 1997; Goddard et al., 2012; Lee & See, 2004).
• Skill degradation: Your proficiency decays as the system does more for you (Wickens, 2008; Casner & Schooler, 2015; Bainbridge, 1983; Kosmyna et al., 2025).
• Out-of-the-loop problem: You’re a spectator until failure, then catastrophically unprepared to intervene (Endsley & Kiris, 1995; Bainbridge, 1983).
• Cognitive offloading: Pushing memory and work to tools reduces active processing; for experts, it can erode hard-won mental models and rapid recall (Kalyuga, 2007; Risko & Gilbert, 2016; Kosmyna et al., 2025).

When GitHub Copilot writes your function, you’re not coding. You’re auditing. And when the audit fails, you’re left staring at a stack trace in a language the AI invented on the fly. Or worse, a confident, apologetic chatbot message: “You’re absolutely right! I should not have bypassed the unit tests!”

Now amplify this with autonomous coding agents, and you’ve got a truly spectacular collapse of accountability.

The Friction Was the Point

Back in 2010, those IDE wars were exhausting but strangely formative. Fighting your compiler taught patience. Debugging your own stack traces built pattern recognition. That friction, the slow, agonizing dance between mistake and mastery, was how you internalized causality.

Now the friction is gone. Your AI assistant finishes loops you haven’t thought through. It names variables you’ll never understand. The cognitive calluses that once defined expert coding have gone soft. And when the AI hallucinates, our atrophied instincts let it slide.

Here’s a real conversation from a recent consulting engagement:

Consultant: “How are you preventing hallucinations in AI-generated code?”

Client: “We review every line of AI-generated code.”

Consultant: “You manually reviewed 720,000 lines of code?”

Client: [Silence]

Sound familiar?

The New Apprenticeship Crisis

Across industries, automation creates the same paradox: As the tools get smarter, humans get worse at the fundamentals. Pilots lose hand-flying skills. Radiologists overlook subtle diagnostic cues. Developers forget how memory leaks and recursion actually work.

AI copilots are the new autopilot, perfectly reliable until the weather turns. When your codebase spirals out of control at 3AM, you’ll wish you still knew how to fly manual.

The Same Anxiety, Better Branding

Yes, the tools are dazzling. Yes, they multiply productivity in the short term. But the cultural loop is identical to every previous wave: We celebrate convenience, then panic about competence.

The teenager who once felt guilty for needing an IDE has grown into a senior engineer defending the “right way” to prompt an LLM. The syntax changes. The anxiety persists. The fundamental tension between mastery and convenience remains unresolved.

Built on the Backs of Purists

Every AI assistant dazzling us today was trained on the painstaking labor of developers who came before, millions of open-source commits, bug reports, and forum posts written by people who actually understood what they were doing. They wrote the raw material that large language models now ingest by the terabyte.

They debugged so we could autocomplete. They suffered so we could vibe.

When we marvel at how effortless coding has become, we’re standing on a foundation poured by the very purists we now mock. AI didn’t emerge from the ether. It was built on decades of human expertise, expertise we’re now systematically choosing not to develop in the next generation.

So what happens when that well runs dry?

From Vibe Coding to Agentic Development

Calvin Ellis, a Principal Software Engineer at Cybrary, has the right take: the goal isn’t to ban AI, it’s to use it with intent. That means shifting from vibe coding to agentic development, where you stay the architect and AI handles the grunt work.

Vibe coding turns into Agentic Development when you are the one in control of what’s being written by the agent. It’s great for discovery, but as exploration turns into execution you need a strategy that can scale with your project.

Calvin Ellis, Cybrary

1. Start With Tests and Interfaces, Not Code. Define the acceptance tests, constraints, and API boundaries first. If you set the rules, AI can safely fill in the implementation without hijacking the design.
2. Offload the Stuff Everyone Avoids (Like Writing Tests). Seriously, nobody writes enough tests. Let AI generate the boring, repetitive parts: unit tests, scaffolding, fixtures, boilerplate. You keep control of the system’s shape; AI handles the drudgery we all pretend we enjoy.
3. Make Your Pipeline the Adult in the Room. Run every AI-generated change through a hardened CI/CD pipeline: tests, static analysis, security checks, coverage thresholds, provenance, and human review. A strong pipeline turns AI from a hallucination machine into a controlled subsystem.

Beyond these foundational steps are advanced techniques. Ellis describes a smart method of giving his agents a built-in understanding of his project code.

One strategy I enjoy using is proactively persisting context from agentic work into the codebase as agent rules, READMEs, comments, and example code. This creates a positive feedback loop where future agents can use and extend, this leads to a deeper agentic understanding of your code.

The debate has never really been about editors or copilots: it’s about how much of our own thinking (and what type of thinking) we’re willing to outsource to the tools. AI can speed up your work, but it can’t replace your judgment. When you surrender the thinking and verification, you’re just hoping the technology got it right. Agentic development keeps you in control while AI handles the repetition.

Stay the architect, not the passenger.

The Research

When developers worry that automation dulls expertise, they’re echoing research stretching back half a century. Here’s the essential reading list:

Automation Bias

• Bainbridge (1983). Ironies of Automation. Automatica, 19(6), 775-779.
• Parasuraman & Riley (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230-253.
• Goddard et al. (2012). Automation bias: A systematic review. Journal of Experimental Psychology: Applied, 18(4), 464-483.

Skill Degradation

• Wickens (2008). Engineering Psychology and Human Performance. Pearson.
• Casner & Schooler (2015). Thoughts in flight: Automation use and pilot cognition. Human Factors, 57(2), 311-321.

Out-of-the-Loop Performance

• Endsley & Kiris (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 37(2), 381-394.

Cognitive Offloading

• Kalyuga (2007). Expertise reversal effect and implications for learner-tailored instruction. Educational Psychology Review, 19(4), 509-539.
• Risko & Gilbert (2016). Cognitive offloading. Trends in Cognitive Sciences, 20(9), 676-688.

Trust in AI Systems

• Lee & See (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50-80.