The Six Pain Points of AI Programming: Real Developer Complaints and How to Break Through

AI programming tools are reshaping software development, but what exactly are frontline developers struggling with? Well-known YouTube tech blogger Primeagen recently put out a call for questions—"What do you struggle with most when using AI for software engineering?" The post received 255,000 views and 336 comments. From CI breakdowns to a lack of code ownership, from useless word garbage to the growth dilemma of junior developers, the comments section covered virtually every corner of AI programming. Primeagen offered his professional analysis and solutions one by one, with agreement, complaints, and advice worth taking seriously by every developer.

CI Runaway and End-to-End Testing Disaster

Primeagen ranked "CI is terrible" as number one, and believes this problem is more serious than it appears on the surface.

A typical pattern with AI-generated code is: you ask it to write a feature, and it casually modifies 100 tests; you ask it to add another feature, and it writes a whole pile of end-to-end tests. After a few rounds of this, the project accumulates thousands of end-to-end tests. These tests run slowly, are extremely unstable, and almost always have various problems.

"I don't care if one person jumps in and says 'my end-to-end tests never had problems'—I've never worked at a company where end-to-end tests didn't have problems," Primeagen said.

The core issue is: you can't end-to-end test everything. AI doesn't think for you about "what am I actually testing"—it just mechanically piles up test cases. Primeagen's advice is direct—does a simple CRUD app really need 50,000 end-to-end tests? Developers need to proactively trim their testing strategy rather than letting AI infinitely inflate the test suite.

End-to-end testing (E2E testing) refers to a testing approach that starts from the user's perspective, simulates real usage flows, and spans the entire system (frontend, backend, database, third-party services, etc.). Typical tools include Cypress, Playwright, and Selenium. Unlike unit tests that only verify a single function or module, E2E tests cover the longest chain and therefore best reflect real behavior, but the cost is also highest: they require starting a complete environment, depend on networks and external services, often take tens of seconds to several minutes per run, and are prone to flaky tests caused by timing, data state, and environment differences.

The industry consensus is the "testing pyramid"—many unit tests, a moderate number of integration tests, and few E2E tests—because the maintenance cost of E2E rises non-linearly with quantity. When AI indiscriminately adds E2E cases for every feature, the test suite turns from a "safety net" into a "drag": CI times get longer and longer, random failures become more frequent, developers gradually become numb to red lights, and ultimately lose trust in test results—which precisely cancels out the value automated testing should provide.

Context Switching: AI Is Both an Accelerator and a Stumbling Block

Primeagen admits context switching is the problem he personally feels most deeply.

The speed experience of AI is very contradictory: it is both much faster than humans and much slower than humans. You spend time deeply thinking about a problem and writing a good prompt, and then you have to wait 10 to 20 minutes. During that time, you naturally think, "I might as well start another task." The result is that you have four concurrent tasks running, and you are completely lost.

"I'm basically a single-task person," Primeagen said. He can handle one or two tasks at the same time, but by three he starts to lose control, and with four it's completely impossible. However, he also admits that if you're only waiting and don't need deep coding, running multiple tasks at once is acceptable. This observation actually reveals a more fundamental problem: the working rhythm of AI programming tools does not match the rhythm of deep human thinking, and developers need to consciously manage their attention allocation.

Context switching is a classic concept in cognitive psychology and software engineering. It refers to the process in which the brain, when moving from one task to another, must reload relevant working memory, goal states, and problem context. This process involves significant time and attention costs, and research generally suggests that a full recovery takes on average ten to twenty minutes. For programming tasks that require maintaining a complex mental model, this cost is especially expensive.

AI programming tools introduce new triggers for switching: in the past, when waiting for compilation or builds, developers usually had only a few dozen seconds, not enough to start a new task; but AI generation can take more than ten minutes, creating a "seemingly idle" time window that tempts people to start concurrent tasks. The problem is that this concurrency is not true time reuse, but rather cutting one-directional deep thinking into multiple segments of shallow switching, ultimately leaving the mental model of each task incomplete. Understanding this helps explain why "running four AI tasks at once" is often slower than serial processing and more likely to make people feel exhausted and lost.

Overhype and FOMO Culture

"If you don't do X, you're doomed"—Primeagen's attitude toward this kind of talk is very clear: when you hear someone say this, never think about that person's words again.

His argument is solid: the way AI agents were used a year ago was completely different from today, and two years ago was completely different from one year ago. There is no specific tool or framework today that you must master or else you'll "fall behind." He gave an example: at the React Miami conference, some developers from San Francisco firmly believed that AI would be able to create complex systems like Cloudflare or Forth without errors within six months.

"You're not creating Cloudflare. You can't make a system that serves millions of users and runs stably for ten years just by telling AI 'no errors,'" Primeagen said bluntly.

His view is: AI can indeed enable people lacking knowledge in a certain domain to produce software that looks usable, but building long-term reliable infrastructure services is a completely different challenge. Rational discussion of AI capabilities is scarce, and most people are "functionally insane" about this.

Useless Word Garbage: AI's Most Maddening Output

"Too much useless text" enrages Primeagen because he has personally experienced extremely absurd scenarios.

His instruction to AI was: "Do not narrate. Just list the repository pattern checklist, and we'll build them one by one." AI replied: "Okay. One file per topic. Open the one you need. Each file contains facts and code."

Primeagen's reaction: "I told you not to narrate, and then you wrote a narration about 'do not narrate.'"

He even tried Grugbrain-style prompts to compress the output. There was indeed improvement, but Grugbrain's own way of expressing things became another extreme: "I understand not, this confuses, hope this way, decision must have, burden on shoulder." It reads just as maddeningly—"bro, just say it clearly."

This complaint seems lighthearted, but it actually points to a real efficiency problem: developers spend a large amount of time every day reading redundant AI-generated text, while the truly valuable information in that text may be just one sentence.

Code Ownership: How to Truly "Own" Code Written by AI

This is the most common complaint in the comments section, and also the issue Primeagen spent the most time giving practical advice on.

His method is "explore, then rebuild":

Step one, think deeply about the shape and requirements of the system. Then use AI to quickly "vibe" out a version, get it running, and iterate continuously. This process will produce a large amount of tests and code, but you will gain a deep understanding of the system, knowing what components, interfaces, and architecture are needed.

Step two, based on that understanding, start v2 from scratch. Carefully design every step, carefully categorize every module, and build a well-considered, streamlined version with the same feature set.

In the project Primeagen is working on, the code volume went from 100,000 lines down to an estimated 25,000 to 30,000 lines, with exactly the same functionality. "That means I truly thought it through, rebuilt it, the database design is better, everything is better."

He emphasizes that this method is actually the idea of prototyping in traditional software engineering. In the past, everyone would first make a prototype to explore, then build the formal version based on experience. Now it's just a matter of handing prototyping to AI to accelerate it.

"I actually did software engineering for real a second time through AI. This method makes me feel satisfied and gives me a real sense of ownership."

Code ownership in traditional software engineering refers to the psychological state in which a developer takes long-term responsibility for a piece of code, understands its design intent, and is willing to continuously maintain and evolve it. It is usually tied to practices such as code review, module owner systems, and "whoever wrote it fixes it," and is an important implicit guarantee of code quality.

The mechanism by which AI-generated code weakens ownership is that the step of "the author understanding every line" is skipped between code production and entering the repository. What developers see is a working whole, but they cannot explain where each decision came from, so they lack a handle for intervening when facing bugs or requirement changes. Primeagen's proposed "explore, then rebuild" is essentially artificially restoring this step—first using AI to quickly trial and error and expose the design space, then having the developer personally rewrite the core parts, thereby turning "I own this code" from legal attribution into cognitive control. This method is in the same lineage as the "prototype-refactor" cycle in agile development and Joel Spolsky's idea of "rewrite once."

The Dilemma of Junior Developers: The Greatest Tragedy of the AI Era

This is the comment Primeagen called "the saddest": as a junior developer, you want to write code by hand to learn new things, but no one around you is willing to let you do that, because everyone pursues immediate results and rapid delivery. The result is that you cannot find a path for professional growth at work.

Primeagen believes this is the biggest and worst dilemma brought by AI. In the past, companies had to give newcomers room to grow because there was no other choice. But now, one newcomer plus AI can reach Claude-level productivity, which is already "good enough" for many people.

What's worse is that AI will not question your design like a senior engineer: "Hey bro, I know you proposed this solution, but based on the architecture, I think it would be better to do it this way. Let's discuss it before changing it." AI will just give you a 1,000-line PR and say, "Did what you asked." And because you are unfamiliar with the codebase, you make a bunch of bad decisions and stuff garbage code everywhere.

"Junior developers are getting the short end of the stick now," Primeagen said. They are expected to deliver as quickly as senior engineers, with a tool that supposedly produces senior-level code, but they do not gain real understanding.

His advice is counterintuitive but worth serious consideration: spend time reading, typing on the keyboard yourself, building prototypes, thinking about edge cases, learning mocking and why you hate it but sometimes need it, learning dependency injection and why it solves problems and why it may be evil. These things sound less sexy in the AI era, but he firmly believes that moving at maximum speed while learning zero and understanding nothing is not good for long-term development.

Primeagen closes with a hiring scenario: if you were hiring today, would you want a person who purely acts as an agent—whatever you say, he types into the code box, watches it spin, and then says merge—or a person who truly thinks about the problem, judges which tests are unnecessary, how to lay out the server, and what the CLI should look like?

"I want the latter one hundred percent. Just being an information relay station was never a good idea. Always strive to be more valuable than a text-box relay station."

The growth of junior developers has long depended on an implicit contract: companies allow them to make mistakes "inefficiently" in real projects, read other people's code, and be reviewed and corrected by senior engineers, in exchange for skill accumulation. The premise for this mechanism to work is that newcomers are clearly slower than senior engineers, so growth space is an investment rather than a burden.

AI has changed this premise. When a newcomer can reach productivity close to that of a mature model with the help of AI, the team loses the economic incentive to "tolerate inefficiency," and the newcomer is pushed directly onto the delivery front line. But output speed does not equal depth of understanding—what junior developers lack is precisely the judgment of "why it is designed this way," and that can only be built by writing by hand, debugging by hand, and personally stepping into pitfalls. The result is lose-lose: the team gets code that looks good enough, but accumulates technical debt that is hard to maintain; the newcomer exhausts the window that should have been used for growth. This is also why many engineering organizations have begun to rediscover the topic of "how to design training paths for newcomers in the AI era."

Conclusion

Primeagen's complaints and analysis touch on the most real contradiction in AI programming today: tool capabilities are improving rapidly, but the ways of working, team culture, and talent development mechanisms around them are far from keeping up. CI inflation, context switching, overhype, redundant output, lack of ownership, and the dilemma of junior developers—these six problems have no simple technical solution. They require developers to proactively adjust their working methods, and they also require teams to rethink the balance between efficiency and growth.

One-line Summary

Primeagen summarizes the six major pain points of AI programming and offers actionable working method advice.

Paragraph Summary

The article sorts through tech blogger Primeagen's point-by-point response to the call for posts on "what do you struggle with most when using AI for programming," identifying six core problems: AI-generated code causing CI and end-to-end tests to expand without limit; AI's working rhythm not matching the rhythm of deep human thinking, with multitasking causing people to get lost; overhype and FOMO culture creating unnecessary anxiety; AI outputting large amounts of redundant narrative text; developers lacking ownership over AI-written code; and junior developers losing room to grow in an environment that pursues immediate delivery. Primeagen gives concrete advice for each problem, including proactively trimming testing strategy, consciously managing attention, and regaining control of code through "explore, then rebuild." He concludes by emphasizing: don't be a text-box relay station; become someone who truly thinks about the problem.