AI Makes Coding Faster, So Why Do I Feel Like a Worse Developer?

A senior developer's confession struck a chord in the tech community: he used AI to help him learn Svelte and Go, and within days completed a personal dashboard project. Everything worked, but when he looked back at the code, he found he could barely understand it. Is the speed boost quietly eroding developers' core skills?

An Experiment: Learning a New Framework with AI

This developer had years of experience with React, Node.js, and Python, and his day job didn't require him to touch anything new. Out of curiosity, he decided to use AI to get up to speed with Svelte and Go, with the goal of building a personal dashboard that consolidated Jira tickets, PRs, build status, and meeting info.

He worked feature by feature, testing the UI after each module, letting Copilot fill in documentation, and pasting error logs to let AI help fix problems. A few days later, the dashboard was done. On the surface, it was an efficient learning experiment.

Svelte is a compiled frontend framework. Unlike React, which handles the virtual DOM at runtime, it compiles components into efficient native JavaScript at build time, resulting in lower runtime overhead and smaller bundle sizes. Its core features are reactive declarations and minimal boilerplate—developers just declare the dependencies between state and view, and the framework automatically tracks updates.

Go (Golang) is a statically typed, compiled language from Google, known for its concise syntax, native concurrency (goroutines and channels), and fast compilation. It's commonly used for backend services, CLI tools, and cloud infrastructure.

These two stacks occupy very different positions: Svelte targets the UI layer, Go targets server-side logic. For a developer long accustomed to React/Node.js/Python, both have mental models that differ from existing experience—Svelte's compile-time reactivity is unlike React's runtime re-rendering, and Go's explicit error handling and concurrency model differ from Node's event loop. This is exactly the typical scenario where AI-assisted learning makes it easy to "skip understanding and just take the result."

The Features Work, But the Code Isn't Mine

The problem surfaced the moment he read the code carefully. He understood the overall architecture, because the architectural decisions had come out of discussions with Copilot; but when it came to the implementation details of Svelte and Go, he found he could barely trace them independently.

If he had to fix a bug or add a small feature now, he'd have to debug the entire codebase first—and that was precisely the original motivation for starting this project.

He concluded: "I didn't really learn Svelte and Go. I learned how to get Copilot to build things with Svelte and Go." The difference between the two is far more important than it seems.

The Hidden Cost Behind the Efficiency Gain

What unsettled this developer wasn't just the technical unfamiliarity. He found he'd lost the satisfaction of "getting stuck—struggling—finally solving it." In the past, a hard problem might take hours or even days, but the sense of accomplishment afterward came from truly understanding the problem. This time, he got a finished product while barely experiencing that process.

More subtly, he developed a strange kind of FOMO—even right after finishing a project, he felt anxious that he "wasn't using AI enough." At the same time, he began to wonder: by letting AI handle every difficult step, how many practice opportunities had he given up?

FOMO (Fear of Missing Out) refers to the anxiety that comes from worrying you're missing out on valuable experiences others are having. In the context of AI programming, this anxiety shows up as: even after just completing a project, you still worry you're "not using AI enough, not using it fast enough," and thus keep handing more steps over to AI.

The risk is that the basis for decisions quietly shifts from "Do I truly understand and control this code?" to "Am I keeping up with AI's pace?" The former concerns engineering quality and long-term capability; the latter concerns only speed and peer comparison. When FOMO dominates the choices, developers actively give up the slow-but-high-value steps—manual debugging, line-by-line reading, independent design—ultimately creating a "use more, understand less" loop. Recognizing this emotion is the first step to putting AI back in its place as a tool.

Seven Practices for Staying Engaged

To find a balance between efficiency and understanding, he adjusted his way of working:

• Understand the deliverable: Speed is great, but he didn't want a codebase he was afraid to touch once the chat window closed.
• Split into small tickets: Break features into manageable tasks and provide context to AI, rather than "here's my idea, see you when the app is done."
• Discuss before coding: Use plan mode to have AI ask clarifying questions, challenge unreasonable suggestions, and sometimes use another model to review the plan.
• Pause when encountering unfamiliar concepts: For example, when AI suggests using the circuit breaker pattern, first learn what it is and whether it's really needed.
• Review after implementation: Use cheaper models in appropriate scenarios, and sometimes have the planning model check the implementation.
• Read the code yourself and test it: If you don't understand, ask or step through the debugger. The smaller the change, the easier it is to understand.
• Move on to the next ticket after committing.

This process is much slower than letting AI run fully automated, but still faster than his old way of working—and it doesn't skip the parts he wants to learn.

plan mode refers to using AI coding tools in a way that has the model first output an implementation plan, step breakdown, and potential risks, rather than directly generating code. It shifts the center of interaction from "producing code" forward to "aligning on the approach," giving developers a chance to question assumptions, add constraints, and reject unreasonable designs before diving in.

Compared with direct generation, the value of plan mode is: first, it exposes AI's reasoning process, letting hidden misunderstandings surface early; second, it preserves the developer's architectural decision-making authority; third, it makes it easy to have another model or a human review the plan. Many AI coding tools (such as Cursor, Copilot, Claude Code, etc.) offer similar mechanisms. It's essentially a discipline of "discuss first, code later," and a key switch for turning AI from a ghostwriter into a collaborator.

Circuit Breaker Pattern is a fault-tolerance design: when some external dependency (such as a remote service or database) fails continuously past a threshold, the system "trips," directly rejecting requests for a set period rather than continuing to wait for timeouts or retry repeatedly.

It has three states: closed (requests pass normally), open (fail fast, don't call the dependency), and half-open (let a small number of requests through to probe whether the dependency has recovered). The benefits are preventing cascading failures, reducing wasted resources, and giving downstream systems time to recover. It's very common in distributed systems and microservices.

For learners, this pattern is worth treating as a classic example of "pause on unfamiliar concepts": AI may suggest introducing it even in scenarios that don't need it. First understand what problem it solves and whether the current system actually has that risk, then decide whether to adopt it—rather than taking it wholesale.

Redefining "Developer" in the AI Era

This developer's experience touches on an industry-wide tension: AI tools really do accelerate delivery, but the cost of that speed may be developers' deep understanding of the codebase. When production breaks, it's still the developer who has to explain it to the team—Copilot won't attend the incident postmortem.

He doesn't plan to give up AI, but he wants to stay engaged enough in the process that the code truly belongs to him. This balance may be exactly the skill most worth practicing in the era of AI-assisted programming: not rejecting the tool, but holding onto understanding while the tool accelerates you.

One-line Summary

AI assistance lets a developer finish a new project in days, but may cost him familiarity with the code and a loss of understanding.

Paragraph Summary

A senior developer used AI to help him learn Svelte and Go, completing a personal dashboard project in days with all features working. But when he looked back at the code, he found he could barely understand or modify it independently. He realized what he'd learned wasn't Svelte and Go, but how to get Copilot to build things with them. Alongside the efficiency gain, he'd lost the satisfaction of "getting stuck—struggling—solving" and the practice opportunities, and developed FOMO about "not using AI enough." He therefore proposed seven practices, centered on splitting into small tasks, discussing before coding, pausing on unfamiliar concepts, reviewing after implementation, and reading and testing code himself—to stay engaged and understanding amid an accelerated process, so the code truly belongs to him.