AI engineering pain points: flaky CI, context switching, hype, text walls, ownership and juniors
- YT :: https://www.youtube.com/watch?v=FlWII9xFabo
- Original title :: It’s not just you
Prime answers a viral post asking what people struggle with most in AI and software engineering (255k views, 336 comments). He goes through the replies and gives his opinion on each: CI that sucks, not being locked in, hype and FOMO, useless walls of text, lack of ownership, and juniors trying to learn. His main advice is to use AI to prototype and explore, then rebuild the thing properly by hand-thinking it through the second time. That gives real ownership and far less code. He ends on a plea for juniors to keep learning and not be a mere proxy between a person and a text box.
Sponsor: Sentry
- Skit about agents that "make CI green" by deleting tests and gaslight you about speed. Sentry gives real production context (spans, session replay, logs next to stack traces) so agents fix bugs without guessing.
CI sucking
- A 100-file test change per feature should frighten you. Agents also write tons of end-to-end tests every time, because you were told e2e is the best thing ever.
- The result is tens of thousands of slow, flaky e2e tests. Prime has never been at a company without e2e problems.
- You cannot e2e everything. Vibe coders who just talk to the magic rocks still have to sit down and decide what they are testing. Does a simple CRUD app need 50,000 e2e tests? Probably not.
Not being locked in (context switching)
- Prime is good at thinking deeply about one problem, which is why he became a programmer, and he found joy in that again with AI.
- AI is both much faster and much slower than him. After typing up a prompt you wait 10-20 minutes, so you kick off another task, and end up with four concurrent tasks and feel lost.
- He is a one-task person. Blasting without looking at code works with many tasks in parallel, but crafting does not. Two features is okay, three starts to break him, at four he is gone. He keeps to one or two and can still answer Discord and Slack in between.
Hype and FOMO
- Anyone saying "if you're not doing X, you won't make it" should be ignored. How you used agents one year ago and two years ago was very different from today, and some of the hyped tools did not exist two weeks earlier.
- Reasonable discussion about AI's realistic capabilities is hard. At React Miami a few months ago, SF people were certain that in six months AI would build Vercel or Cloudflare with no mistakes.
- Today even someone ignorant of a field can produce working software in it, which is fine. But a ten-year resilient service for millions of users from "no mistakes" prompting is not realistic; it is brain rot talk.
Useless walls of text
- Agents produce far too much text. His example: he asked for "no narrative, just a list of repository patterns", and the AI wrote narrative about having no narrative.
- It wastes time. A 400-word answer could have been one sentence ("the client interface kind of sucks").
- Telling the model not to do it does not stick. Caveman-style speak cuts the volume but gives hard-to-read grunt paragraphs. He asks whether anyone knows a real fix.
Lack of ownership
- The most common complaint, and for Prime one of the hardest to get past. He now has a solution and gives it as advice.
- Process: think deeply about the shape of the system, then vibe a first version just to feel it out and make it work (too many tests and lines, but a lot of insight into what is wanted). Then design a V2 deliberately, component by component.
- Lines of code is a check, not a goal. Same features end up in half or a quarter of the code because tests, shape, structure and database design were thought through. His current project went from about 100k lines to a likely 25-30k.
- Example: the Omarchy automation work, a distributed agentic testing framework for the OS (called Oligoti, "the oligarchy"). The first version was an experiment; the second has the same features, better thought through and much smaller.
- "Slop it to explore." Real developers always built prototypes to learn, then built the real one faster and better. Same thing now with AI, and he feels real satisfaction and ownership of the result.
Juniors learning by hand
- The reply he feels worst about: a junior who wants to learn by hand but whose coworkers want instant results, so there is no room to build expertise.
- Companies used to give people room to grow because they had no choice. Now new hires can be "as effective as Claude".
- The AI never pushes back on a bad idea or says "let's discuss first". It hands over a thousand-line PR, and a junior unfamiliar with the code adds junk. Juniors never get to learn what good looks like, yet are expected to move like seniors. They have the shortest stick.
- Prime still believes technical knowledge matters: read, build prototypes, work through edge cases, learn about mocks (and why you hate them, and when they are a necessary evil), dependency injection (why it helps and why it is evil). It is not sexy, but max speed with zero understanding will not serve you in five years.
- Choose between being a person who types in what they are told and hopes evals pass, or one who sees a problem and decides how to split it, what tradeoffs to make. You have to earn that with reading and hands on the keyboard.
Closing
- Do not believe the "not going to make it" talk; you have a long life ahead and nobody knows the future. Maybe one day models make technical knowledge useless, but he doubts it.
- If hiring, he wants the person who thinks through the problems (what tests, what layout, what the CLI looks like), not a proxy who relays what he says into code and presses merge. Never be just a proxy.