AI Replacing Developers? A Year Later, I Overturned My Own Judgment

A year ago, I wrote an article discussing whether AI would replace developers. My conclusion then was "no" — AI was just a tool that made good developers better, fundamentals still mattered, and most of the news was hype. Looking back a year later, some of my judgments were right, and some were wildly off.

From Autocomplete to Agent Orchestration: The Evolution of My AI Usage

There was an interesting detail in that article from a year ago: I barely mentioned how I actually used AI, only admitting it in the comments. At the time, I mainly used AI for basic inline autocomplete, quick syntax lookups, and debugging obscure stack traces — rarely touching Agent mode. I tried relying on it more heavily, but quickly felt it was a crutch — I felt like I wasn't learning anything and was gradually losing control of the codebase, so I pulled back.

Today, I hit Claude's 7-day usage limit almost every week. The change wasn't a sudden epiphany — it was forced by the daily pressure of delivery. By late 2025, I shifted from "autocomplete" to "task delegation," no longer asking "how do I write this function" but saying "go execute this task." By 2026, the company started paying for Claude subscriptions for everyone, switching from personal configuration to enterprise-level workflows, which forced me to rethink the entire development process.

Now I don't just "use Claude" in a chat box. I maintain a personal development framework, structured and version-controlled like a production repository. This private repo serves as my "personal engineering operating system":

• Rules: Non-negotiable boundaries on code quality, data integrity, test coverage evidence, and Git safety. Enforcing principles like "never silently swallow errors" and "must verify log output before marking a task complete."
• Roles: Structured multi-Agent workflows, including a dedicated review team, executors, a task slicer that breaks complex specs into independent PRs, and a mentor.
• Skills: Deterministic routines for PR creation, commit formatting, automated self-review, and dynamically scaling the review team size based on the impact scope of changes.
• Mods: Custom tweaks and extensions built directly on top of Claude Code.
• Personal knowledge base: A living knowledge base containing system context, architecture decision records, to-dos, known pitfalls, and context packages. Agents must read it before starting a session and update it after completing tasks.
• Migration guide: When switching to a new machine, clone the repo and tell Claude to "read and run" — it will boot the environment, configure tools, and immediately adopt my work methodology.

From isolated prompts to orchestration — Agents, sub-Agents, review roles, and deterministic rules — that's the bridge between generating cool demos and engineering production-grade applications.

Agent mode and task delegation are key to understanding this shift. Traditional inline completion is the model predicting the next piece of code based on the current cursor context — essentially pattern completion. Agent mode, on the other hand, gives large language models the ability to plan, call tools, execute multi-step tasks, and verify results. Users only need to give a high-level goal (like "fix this bug and submit a PR"), and the Agent will break down the steps, read and write files, run tests, and iterate based on feedback. Task delegation means developers shift from "writing code line by line" to "defining task boundaries, acceptance criteria, and safety constraints," then reviewing the Agent's output. This paradigm requires developers to have stronger architectural judgment and result verification skills, because errors can hide in seemingly reasonable multi-step execution.

Where I Was Wrong

Looking back at my predictions, I had several strong opinions that were wrong on multiple levels.

"Vibe coding is a dead end"

I once thought vibe coding was just a short-lived trend for non-developers. I was wrong. Vibe coding works, and it's here to stay. But with a caveat: only if used correctly. Vibe coding isn't blindly accepting generated code — it's guiding AI through rapid feedback loops like an architect. Without a clear plan you'll get lost quickly, but with good guardrails, it's a very fast way to build.

The term Vibe Coding was coined by Andrej Karpathy in early 2025, referring to a programming style where developers describe intent in natural language, let AI generate code, and iterate quickly by "feel" with minimal line-by-line review. It lowers the barrier to building prototypes, but the risk is: without clear plans, tests, and architectural guardrails, the codebase quickly accumulates hidden defects and unmaintainable coupling. The author's revised view is that vibe coding isn't blindly accepting generated output, but guiding AI through rapid feedback loops like an architect — start with a clear blueprint, let AI fill in the details, and back it with automated verification. Therefore it's better suited for exploration and low-risk scenarios; production systems still need rules and multi-layer review.

The S-curve judgment

I once argued that AI progress follows the classic technology S-curve, and that we had already passed the peak of hype. Honestly, if AI really is on an S-curve, I no longer know where the flat part is. I severely underestimated the speed of model improvement — new capability leaps keep surprising me.

"Advanced autocomplete"

I once called large language models "fundamentally sophisticated pattern-matching and autocomplete systems." That description is now too simplistic. A year ago, each distinct task required a specialized AI model; today, the latest models handle complex reasoning, planning, and tool use with high accuracy. They're not just completing patterns — they're executing real intent.

The technology S-curve describes the maturation process of a technology from slow early improvement, through rapid explosion, to eventual plateau. The author once used this to judge that AI had passed the hype peak, but actual observation shows capability leaps are still ongoing. One reason is that modern large models continuously unlock new abilities like planning, reasoning, and multi-Agent collaboration through scaling, post-training (like RLHF), and tool use, rather than just incremental progress along the same dimension. The limitation of the S-curve framework is that it assumes technology evolves along a single performance metric, while AI's capability boundary itself is being redefined — new application layers and orchestration methods repeatedly "extend" the curve into new stages. So using the S-curve to judge "peak passed" easily underestimates the nonlinear progress brought by paradigm shifts.

What I Got Right

Conceptually, the core arguments held up — even if the scale of execution exceeded my imagination.

• Prompt engineering is fading: I called it a temporary gap, and it was validated. You no longer need magic words. Models naturally understand domain context, help refine their own instructions, and independently orchestrate sub-Agents. You're not crafting prompts — you're defining intent and reviewing execution.
• The typing part has been commoditized: Exactly. The act of manually translating logic into syntax is no longer the bottleneck of software creation.
• Developers move up the stack: My daily work has shifted from writing code to intent specification, architectural direction, system bootstrapping, and code verification.
• Fundamentals still matter: More than ever. When code is generated in seconds, your ability to spot subtle architectural flaws, memory leaks, and concurrency bugs is the only barrier preventing system collapse.
• Panic was exaggerated: Technology shifts have always disrupted software engineering — AI just compressed the timeline.

The Speed No One Prepared Me For

At my last job, I was assigned a project with a standard delivery cycle of 2 years. Using Agent workflows, I delivered it in 6 months. More importantly, it wasn't a fragile prototype — it was secure, high-performance, resilient, and currently runs at national scale. That kind of leverage was mathematically impossible a few years ago.

In my current job, my biggest operational struggle is estimation. I constantly miscalculate timelines because my brain is still calibrated to manual coding speed. Estimation used to be "how long will it take me to write this implementation" — now it's "how long will it take to verify the solution, and how often will edge cases crash and require human intervention."

Where It Still Burns Me

Despite the capability leaps, the current paradigm still has obvious failure modes:

• Rule degradation: In long context windows, Agents still deviate from instructions and forget explicit constraints.
• Silent architectural errors: It can generate clean, syntactically perfect code that makes fundamentally flawed system design assumptions.
• Context laziness: If bad patterns or legacy tech debt exist in the codebase, the Agent treats them as authoritative examples and extrapolates those anti-patterns into new features.

Triggering an Agent, going to sleep, and waking up to working code is increasingly easy. But the remaining 5% gap — where subtle edge cases, race conditions, and security vulnerabilities hide — is exactly where strict rules and multi-layer review roles come into play.

Instruction drift refers to the model's adherence to early system instructions and constraints decreasing as the conversation grows within long context windows. When an Agent executes multi-step tasks, the large amount of intermediate tool output and code dilutes the initially set rules, causing it to forget hard requirements like "never silently swallow errors" or "must verify logs before completion." Mitigation methods include: solidifying key rules into repeatable skills or checklists, re-injecting constraints at key checkpoints, splitting long tasks into subtasks with independent contexts, and using deterministic scripts rather than model judgment for final gates. Understanding this failure mode is what turns "trigger the Agent and go to sleep" into a controllable engineering process rather than a gamble.

The Learning Trap Got Worse

A year ago, I worried that over-reliance on AI would erode technical growth. That concern hasn't gone away — it has evolved into a major industry trap.

When an Agent can solve complex bugs in seconds, the temptation to accept the diff and move on is enormous. But if you don't actively audit how the problem was solved, you'll gradually devolve from a software engineer into a glorified prompt operator.

To counter this, I've deliberately re-engineered learning into the environment:

• Mandatory explanation rules: Core instructions require Agents to explain the architectural trade-offs behind implementation decisions and explicitly flag non-obvious code paths.
• Friction injection: Settings that flag moments when I should implement logic paths manually, to maintain muscle memory rather than blindly delegate.
• Plan-first execution: No code is written until the Agent proposes a high-level architecture plan and receives explicit approval.
• Mentor role: After a feature is merged, a dedicated role breaks down the core concepts used, explains rejected alternative patterns, and records key lessons into the personal library.
• System tracing skills: When exploring unfamiliar codebases, I use custom routines to trace end-to-end event flows and generate targeted comprehension exercises for me to solve.

If tools are going to take over the typing, they must be configured to accelerate your understanding. Otherwise, you're quietly handing over your expertise.

Where the Future Lies

My answer is the same as last year — just with much higher stakes. Understanding underlying systems, domain modeling, system architecture, security, performance, and long-term maintainability remain crucial. The cost of code generation has dropped to near zero, which means value has shifted entirely to discernment, system integration, and domain expertise.

AI can write code and build platforms, but it won't understand your business domain, won't negotiate requirements with stakeholders, and certainly won't build the customer relationships that make software valuable.

"How" gets cheaper every month. "What" and "why" are your real job.