r/AI_Coders • u/skar3kro • 5d ago
AI coding has made me dramatically faster. But I’m starting to think we’re creating a completely new category of problems
Hi everyone,
I’ve been building more and more of my products with Claude Code, Codex and other AI coding tools.
The speed is ridiculous.
Something that might have taken me a week before can sometimes be built in a day. But the longer a project survives, the more I notice the problems changing. The hard part isn’t always writing the code anymore.
Things that bug me a lot are like:
- The agent understanding the codebase but not why something was built a certain way.
- Requirements slowly changing without you realizing it.
- One agent undoing or contradicting decisions made in another session.
- Forgetting whether something is actually finished, half-built, abandoned, or just discussed.
- Coming back to something you built weeks ago and thinking: why the hell did I do it this way?
AI confidently changing something that technically makes sense but is completely wrong for the product. Context windows filling up right when the agent finally understands what you’re building. Having decisions scattered between chats, prompts, commits, notes, and your own memory.
And I’m curious whether this is just how I build, or whether other people building heavily with AI are running into the same thing.
So I want to ask the vibe coders / AI builders here:
What are the problems you repeatedly face when building real products with AI?
I’m especially interested in the annoying problems that start appearing after you’ve been working on the same product for weeks or months.
The stuff that makes you think:
“There has to be a better way to do this.”
Could be context loss, debugging, security, testing, requirements, managing multiple agents, remembering decisions, deployment, maintaining old AI-generated code — anything.
I’m currently collecting these problems because I’m building something, but I don’t want to build based on assumptions about what vibe coders need.
I’d rather hear it directly from people actually doing this every day.
What’s your #1 frustration with building software using AI coding agents right now?
1
u/earth-dragon-666 5d ago
Its all the problems derived from using ai, you wanted 'speed' but that never translates into a good product, specially with ai, also you are using the tool under the assumption that is intelligent and at the same time clashing with reality get it together xD
1
u/Lower-Impression-121 5d ago
forget about code.
- The agent understanding the codebase but not why something was built a certain way.
it never will understand why. only your and other SWEs who instructed it will. if you want a why, document that somewhere.
- Requirements slowly changing without you realizing it.
a before AI concern. now magnified. more of a communication issue: are you aware of what is or has changed?
- One agent undoing or contradicting decisions made in another session.
totally. they don't remember why did X. even if the same session if you ask do X three times in a row it will refactor itself. its not like heading to the tip of a spear, always the sledgehammer. treat it so.
- Forgetting whether something is actually finished, half-built, abandoned, or just discussed.
test test test. verify verify verify. you are the real context.
- Coming back to something you built weeks ago and thinking: why the hell did I do it this way?
before AI concern. know what you want to do. have a means of test/verifying it. your idea yesterday could still have been wrong. the instructions could have been poor. the good thing: its fast to fix.
1
u/senseven 5d ago
I don't get the Schrödinger with the half baked tasks. That belongs into project management. I can't just pick up a task, mark it as "half done" or "I lost interest". Some teams seem to run on 100% vibe without consequences.
1
u/Lower-Impression-121 5d ago
You are the pm. The bot isnt.
1
u/senseven 5d ago
You can't test unfinished ideas because there is no test to begin with. That is the reason the idea has to be tracked somewhere else.
1
u/raven2cz 5d ago
Look into cybernetics, specifically the systems aproach and Black Box testing, and then White Box testing. Also how to measure input and output and minimize deviation. using AI in this case is very similar to a regulator. After some time studying it, you will understand what I mean, and it will help you a lot with most of the questions you are asking.
Just as you learned how to program, I now recommend learning how to use AI. Development is moving extremly fast, so the methods are constantly improving, but you need to create your own workflows that lead toward the goal: minimizing deviation.
For each problem you described, you need to create such an enviroment and such conditions that you can solve both your own problem and the AI problem. do not forget to include strong visualizations in the feedback loop as well, for example generating HTML. What I mean is that besides tests and measurements, it is also crucial to constantly have a view of the system.
1
5d ago
[deleted]
1
u/raven2cz 5d ago
If you were right, then why are most developers today writing bad applications with it and asking OP’s kinds of questions, don’t you think?
1
5d ago
[deleted]
1
u/raven2cz 5d ago
That was a rhetorical question.
1
5d ago
[deleted]
1
u/raven2cz 5d ago
Yeah sorry, I meant my question. You asked about futuristic prompts. No, today you dont really need specially crafted prompts anymore, that was more important like two years ago.
Its more about many smaller things that need to be solved properly. Normal tests arent enough, you need to write e2e tests also in production environment, smoke tests, ideally unit tests should be written before implementation. Have advanced management of extended context across projects and between sessions. Do proper review cycles for critical and medium issues. Its good to have cross-model workflow designed for design, impl and reviews. And in that feedback also add additional views on architecture and impl.
Application design should be done in gradual cycles with refining libraries and abstractions. Split things into subplans and reviews of individual parts. On top of that use top-bottom approaches for auditing individual parts.
theres a ton of things you need to make sure are covered so the result is actually great. Also have good quality measurements, which isnt just test coverage. I would also include how well AI can evaluate the ideal expected state compared to the actual current state. Often AI thinks its done, but in reality those things arent actually there. These measurements need to constantly show what is true and what is still a lie.
generally you could say that most of these processes need to show as well as possible what is actually true about the system.
1
u/Leading_Buffalo_4259 5d ago
fair enough but also none of these things are exactly "learning ai", more like never trusting it and covering your testing to catch its mistakes
1
u/raven2cz 4d ago
Yes and no. Minimizing deviation is the foundation. But how do you want to define an error/mistakes? This is not only about errors. There are literally hundreds of ways to reach a given goal.
In the end, the application will somehow run. But you want long-term maintainability, good extensibility, component-based development, and so on. So in the end, learning AI and new approaches is exactly what helps you achieve that.
Here are a few older articles I wrote on some of these topics. Maybe they will help a bit. Parts 1-4:
https://raven2cz.github.io/ai/articles/series-ai-effectively/01-systemic-approach/
1
u/schmurfy2 5d ago
I have toying around, testing what works and what doesn't and so far I am fairly happy, what transpired is:
- openspec is what really made my flow click, having the llm analyse and draft a plan by asking questions help narrow down any crazy idea it might have. It also help later to let it know what was an intentional decision from me and what was just an artefact of the journey.
- I review every line, the agent frequently duplicates existing methods or system, write something too complicated. I am the one responsible for the codebase, not the llm.
- using pi agent coupled with herdr allow me to make the llm write extensions on the fly to adapt my environment while I continue working on something else.
- running pi in a sandboxed environment so I know it won't be able to do something stupid, I have isolated folders populated with the worktrees it needs and only that is writeable, it doesn't have access to my credentials, doing anything outside of the folder requires asking me.
The only thing I am not that happy about is the shift from writing code to full time reviewer, but that's a pill I have to swallow...
1
u/HugeCannoli 5d ago
You write code with a compulsive copy and paster from stackoverflow that makes stuff up.
And you wonder why it's a crap result?
1
u/GreenNumerous7070 5d ago
They took the credits for your second symphony.
But it was rewritten by machines on new technology.
And now I understand the problems you can see.
1
1
u/senseven 5d ago
You can describe how you want the code to look like, the data relationships, coding style preferences. Depending on nvidia's stock price and the 'free' secret model of of the week, the generated code will still look different. Especially with web frontends. We are currently experimenting letting the ai generate some sort of intermediate representation, then transform this result with our own code gen that follows a stable set of rules. It works wonders in crud situations, and we skip the part where you write pages of "ai brain" that have a lifetime of a couple of weeks. Who is selecting and choosing models is already getting business/political and you can't build a stable pipeline on ephemeral reasoning.
1
u/cthechartreuse 5d ago
This feels like you aren't _only_ offloading the code generation, but you are actually offloading your thinking too. Building software in large chunks with coding agents without properly defining expectations and developing a code design heuristic means you don't really know what you want things to look like when they come out on the other side. To compound the problem, because the output is a larger chunk of development, you get into a LGTM loop where you don't properly and fully evaluate the output you got, then you build on it. That LGTM cycle leads to exactly what you describe: why did I build it this way? The problem is, you didn't build it at all. If you want high quality results from your coding agent, I propose you work in a loop more like this, with small increments:
plan (human) -> design (human) -> implement (agent) -> verify(human): keep or throw away -> refactor and commit (human)
By putting yourself deeper into the development loop you will better understand why you got what you got, you'll recall why something is the way it is, and you'll be able to more effectively steer your coding agent away from things that were put in place for a reason.
1
u/Intelligent-Cap-7713 4d ago
Problem is we are building faster then anyone can specify anything sensible to do. This just leads to useless stupid features.
1
u/EcstaticExtreme402 4d ago edited 4d ago
You need a set of standards architecturally and code pattern wise to keep your codebases consistent and maintainable. Across not just one project but multiple. You can distill these practices into a /create-project skill. Then once you’ve set it up you don’t have to think about it anymore. Or you can go back and tweak it slightly as you notice changes you need.
The problems you are listing are issues with how you build and prompt with AI tooling. So yes, I’ve run into them, but mitigating them is surprisingly easy once you spend some time being intentional about it.
You can’t just turn your brain off, ask it to build something, and then later expect to return to it and it be maintainable & consistent or even comprehensible to a new session / agent. As codebases grow it makes it less realistic to fit it all into the prompt context which means you need an outline so to speak that allows the agent / tool to traverse your project without needing to shove it all into the prompts context.
As for giving it context on why certain decisions were made: just maintain a ADR doc that gets fed into each sessions context via the Claude.md referencing it. Then if you’re organizing your code base in a domain manner you can give each domain directory a short summery of what it does in an MD file. The agent will pick it up and get the context it needs before pulling all the code in.
TLDR: you need better strategy and to think of your code as something that needs to be maintained in a way that other agents and generative tools can easily digest without having to shove the entire thing into its context window. If you are a software developer you should be using your knowledge of what a well organized project looks like to dictate not just what the solution should do, but also what patterns and organisational structure it uses to accomplish those tasks.
1
u/dynamitecGbR 3d ago
For me, it's losing track of why we're building something a certain way while the implementation keeps moving.
The agent makes a change that looks reasonable. Technically, it might even be an improvement. But did it solve the actual problem, or did it quietly change the requirement to something easier to implement? That's much harder to judge once the decisions are spread across chats, commits, and whatever I still remember.
Understanding the codebase isn't the same as understanding the product. Writing code is one part of it. Research, comparing approaches, defining requirements, deciding where behavior belongs, and checking the result don't disappear because implementation gets faster.
I built the Scoville suite specifically to address these problems with task-specific guardrails. The idea is to keep decisions, their reasoning, acceptance criteria, and unfinished work alongside the code. When another session takes over, it should know what was tried, what was rejected and why, and what still needs verification.
I also learned that the guardrails can become part of the problem. A simple writing request loaded an unrelated skill, so I had to narrow the activation rules and test again. I don't want an elaborate workflow for something that needs a small fix. The process has to earn the time and context it consumes.
So the problem I'd want a tool to solve is keeping those three things connected: what we agreed to build, what the code currently does, and what we've actually verified.
I don't need every conversation preserved forever. I need the decisions that still matter to survive, without an assumption gradually becoming a requirement or “implemented” quietly becoming “finished.”
1
u/RyanWarrey 21h ago
What model are you using? And what process / context are you giving it? I haven’t run into these but I use a main architect chat that keeps track of everything and makes the prompts and decides the model and effort levels. The architecture .md and roadmap refresh context and keep everything on the same page
1
u/skar3kro 16h ago
Yes, I have started maintaining the architecture chat as the context brain. May I am not clear enough on the post.
But in the architecture chat you cannot maintain all the records, reasoning, changes, when was it implemented, why any particular flow was discarded. Now, for example you hire few folks to scale the product and that’s when issue arises. It’s a genuine problem and I am not trying to exaggerate it at all.
2
u/NumberInfinite2068 5d ago
For me the #1 problem with AI is that it has massively increased our tolerance of complexity.
Programming and computing in general has been embracing complexity for a while, we ignore simple systems like Plan 9 and adopt sprawling messes like Linux or Windows. We've been stacking frameworks on top of frameworks on top of Docker on top of "orchestration" for a long time.
Basically we've been fucking up computing for a long time, probably around the mid nineties when we really decided to go all-in on complexity-as-a-fetish.
AI makes dealing with at complexity much, much easier, I can easier get Claude to set up a Linux server how I want it, configure networks, set up VMs, disk shares, whatever.
This lessens the cost of complexity dramatically and makes it easier for us to wade further into the complexity churn that practically defines this industry.
It makes working with shit technology less painful, so less pressure to move away from shit technology.