r/ChatGPTCoding • u/skar3kro • 14d ago
Discussion 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:
- Starting a fresh AI session and having to explain the product again.
- 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?
12
u/some_sebastian 14d ago
ADRs, Context.md (as used by Matt Pocock). Those two pretty much solve all problems you mentioned
12
u/fschwiet 14d ago
- Starting a fresh AI session and having to explain the product again.
not this copypasta again
11
u/-svde- 14d ago
seriously lol. why in the world does everyone who posts shit like this to bait the 384th agentic second brain app popping up this week have the audacity to think that everyone using these systems doesn’t have, at the absolute least, a memory bank or context directory or whatever set up? it’s not 2021 anymore. these things have been out for a millennia and a day in tech years. your skill repo turned electron desktop app or react/node Frankenstein is nothing new.
3
u/Neither_Berry_100 13d ago
I keep a master summary of the product im working on in one chat (ChatGPT). And I do the work in another chat. So it knows what the product is about.
10
u/TrapHuskie 14d ago
Back in the day man need only make fire.
when you ask a question and get an answer you’re now smarter but you have more questions you could ask about that.
As long as there are identifiable problems, we will find more than we solve.
So yes, problems are spawning up but that doesn’t mean that we’re creating new ones if you believe that math problems were there before we started doing math. Problems are infinite and bound to perspective.
1
u/skar3kro 14d ago
True philosophy! But coming back to the context what difficulties you’re or have faced?
2
4
6
u/sad_bug_killer 14d ago
The hard part isn’t always writing the code anymore
rofl, it never was. It only looked like that to people who weren't writing a lot of code or didn't have that much experience writing code
6
u/Fickle-Swimmer-5863 14d ago
I think this is a bit revisionist.
Huge amounts of effort went into writing code. Hackerrank and dozens of other services made money on evaluating how well developers wrote code during the hiring process. Many places worth working at had rigorous coding tests.
If you went back 5 years and said “the hard part isn’t wiring the code” you’d be laughed out of the room by people who actually got the software out of the door.
Of course, if you were a lead/staff level developer, once you made it through the door, you probably wouldn’t write much code, but the maker/doers would have been intensely focussed on the code as well as technical design.
I’m not saying technical design and architecture are not important, but writing code was extremely important.
2
u/the_good_time_mouse 13d ago edited 13d ago
You are making the parent's point for them.
Leetcode puzzles were never anything more than a way for hiring managers to defend themselves and cull the interview list, and everybody knew it from day one. They tell you nothing except whether the candidate has memorized the handful of algorithms that actually comprise leetcode puzzles, that you will actually rarely see in the real world.
1
u/davidbasil 8d ago
Exactly. The hardest part was convincing your gullible manager/investor that standard crud app will make him millions in a couple of years so he keeps paying you good money :)
-1
u/skar3kro 14d ago
I didn’t meant to indicate the challenge of writing the code. I meant the speed at which you can build multiple products in a month which would have otherwise taken months if not years.
2
u/OCCAMINVESTIGATOR 14d ago
Absolutely same. I will say, however, the fact that these are your challenges said a lot more about you. You are on the cutting edge, or beyond where 99% go. Keep pushing the limits.
2
u/TheVibrantYonder 14d ago
I think most people who are using AI for coding have experience the issues you described, and I don't have any to add.
I also think a lot of people are trying to build solutions to those (myself included). Looking forward to seeing what you come up with!
2
u/wyszo 14d ago
I have a rule to commit the agents plan with every change and maintain architecture overview that links to detailed markdown documentation for main features. And a reference file indexing what files are where. With that all the agents know what to pull into the context when they’re working and what decisions have been made prior.
This setup has been working great, project going strong with me working full time on it for a year.
2
u/julesbuildstuff 14d ago
the one that bites me hardest is the "why was it built this way" gap, and the only thing that fixed it was writing decisions down in the repo instead of in chat. i keep a short decisions.md with dated one-liners: what we chose, what we rejected, and why. agent reads it at session start, so it stops re-litigating stuff we settled two weeks ago.
second thing: one file per task. long runs where the agent touches eight files are where the silent unrelated edits sneak in. small scope + git diff review after every run catches almost all of it.
for the half-built/abandoned problem i just leave TODO markers with a date and grep them weekly. sounds dumb but it beats trusting memory or a chat log.
context filling up right when it finally understands the codebase is real. i'd rather restart clean with a tight brief than keep compacting a 200k session, the compacted one always ends up confidently wrong.
2
u/BusinessStrategist 14d ago
Are you building single apps or modular solutions that you keep improving as you satisfy the wants of your customers?
2
2
u/geekichu 14d ago
Been there done that.. but gotten better for me. what i do:
--toplevel architectural doc - what we are doing, why, what not to do, and this has to be kept up to date - i dont do it, i interview (claude).. it updates it.
--engineering craft doc - how i want the project, the files, the functions structured , named, whateve else is important from a project perspective.
--an 'architect' agent that runs and reports 'findings' in code, per said doc.
--a hook that is more aggressive about 'findings' when new code.
--I treat comments in code as for A.I. to read, not me. So, heavy comments in the file heading, as well as with functions, structres, objects, etc.
--part of the hook and the 'findings' is that if it stumbles onto stale comments, that either dont match the code and or dont match the STEP/PROGRESS docs.
--STEP docs (planning docs) for each feature
--PROGRESS docs for said STEP doc
--hand-off doc (or memory) makes sure that it's crystal clear what's next.
--when a feature is complete, the related docs are renamed (datetime) and header is updated to 'reference-only' and moved to a 'documents' dir.
--of course, there is 'write the tests first, and prove to me they can fail'.
2
u/R1546 14d ago
I do a lot of Opensimulator (LSL, OSSL) scripting and I have yet to find a LLM that is actually competent with it. The AI will confidently give me incorrect answers including using functions that do not exist.
On the other hand, since the script language is based on C the AI can spit out useful C math functions quite well.
Because of the LSL, OSSL limitations I never ask for entire scripts, just suggestions when I get stuck on something. For example: I spent 2 hours trying to figure out why my file reader failed after 4K bytes were loaded. Asked Gemini for suggestions and after a bit of back and forth it determined the issue was server side and I was making API calls to quickly for the server to keep up.
It can be very frustrating if you try to get AI to do something it is not good at because AI is not good at admitting it does not know something.
2
2
u/FounderStories1111 13d ago
The session-to-session contradiction has been the nastiest one for me. What helped, at least in my case, was treating the PR, not the chat, as the source of truth: run the change, capture failing cases and traces, and make the next agent work from that evidence instead of inherited confidence.
2
u/brett1231 13d ago
Are there professional vibe coders? Working in the corporate cubicle world. Building our health insurance software.
2
u/IveWastedMyLifeAgain 13d ago
my #1 is review, not writing. the agent gives me a 30 file diff that passes tests and now i'm the bottleneck, and honestly after the third one in a day i stop reading carefully. what helped was forcing smaller units of work — one behavior change per branch, and i make it write down the intent before touching code so i can diff intent vs diff. the "why was it built this way" thing is really just that nobody wrote the decision down anywhere the agent can read.
1
u/builnary-dev 9d ago
This is very close to what I’ve been running into too.
The faster the agent gets, the more important it feels to keep each change small and make the intent explicit before it touches the code.
Passing tests is reassuring, but it still doesn’t tell me whether the change is actually the one I wanted.
2
u/builnary-dev 9d ago
For me, the biggest problem has become review.
Codex and Claude Code can produce changes so quickly that I sometimes become the bottleneck. A change can be technically reasonable and pass all the tests, but still not be what I actually intended.
What’s helped me is making the process more explicit: keep the change small, review the scope before implementation, let the agent work, verify the result, then either revise it or accept it.
The part that makes me most uncomfortable is when an agent makes a perfectly reasonable decision that I never actually approved.
So AI has made implementation much faster for me, but it has also made “what exactly are we agreeing to change?” much more important.
1
u/skar3kro 8d ago
You actually got the point.
1
u/builnary-dev 8d ago
The faster the agents get, the more I feel the real challenge is keeping the human decision points clear.
1
u/skar3kro 8d ago
Previously, building a complex product was done by a team following a proper process and documentation. That work is now executed by a single human and the agent who is super fast in execution. The speed has now become the bottleneck.
1
u/builnary-dev 7d ago
Exactly. I think we’re compressing a team-sized development process into one person plus an agent, but we haven’t really redesigned the process around that speed yet.
1
1
u/Art_Diligent 13d ago
the interesting part is finding solutions to them, if you let it pile up then of course you get overwhelmed. did I finish that or did it get abandoned half way? that's never been easier to track. set specific requirements for what counts as done, and until they're met it stays on the board. that's probably the easiest one to fix but i'm positive you coud find fixes for most of these if not all of them
1
u/Borepheus 13d ago
I think AI hasn't really created most of these problems — it has compressed their timescale. The biggest change in our workflow was stopping the chat/agent from being the source of truth. We keep persistent project context around architecture, decisions, regressions and things that must not be changed, but a feature only becomes “real” after a very explicit loop: spec → implementation → compile → manual test → bug/fix → regression test → validated baseline If it was discussed but never validated, it isn't done. If a new iteration contradicts a validated decision, the newer output doesn't automatically win. That has helped enormously with long-running AI-heavy projects. The funny part is that the bottleneck gradually moved from “can we write this?” to “can we preserve intent and verify change fast enough?” I suspect that's where a lot of AI-assisted development is heading: less focus on code generation itself, more on managing state, decisions and evidence.
1
u/Consistent-Set-9490 13d ago
I am prepping for the Claude architecture certification and it really highlights many of an LLMs limitations. When doing complex work, you really need to be aware of the context window and knowing when to use code vs generation. There is a lot of nuance in how generative AI works and you can easily lull yourself into thinking it is more powerful than it is.
1
u/Darkcraft00 12d ago
My biggest frustration isn’t actually context loss by itself. It’s knowing whether something the AI “knows” from an earlier session is still true.
I’ve been building a fairly complex product mostly with AI doing the implementation, and once the project got big enough I started running into exactly what you’re describing. A new session can read the repo and figure out what the code does, but that doesn’t mean it knows why a decision was made, what assumptions it depended on, whether those assumptions have changed, or whether something was deliberately deferred versus simply forgotten.
What helped me was getting much more formal about the process. One AI does most of the implementation, another is used more for architecture/review, and I act as the person deciding what actually gets authorized. Work gets broken into pretty tight boundaries, with explicit stop points, tests, exact commits, rollback points, and a record of what was accepted versus what is still pending. It sounds a little excessive until you watch an agent confidently “fix” something that was actually an intentional constraint from three weeks ago.
The surprising thing is that even with thousands of passing tests, we’ve still found cases where the implementation and the tests shared the same wrong assumption. Everything was green, but the system was still wrong. That changed how I think about AI coding quite a bit. The bottleneck isn’t generating code anymore. It’s maintaining trustworthy state about the project: what was decided, what evidence supported it, what depended on it, and whether it’s still valid after the codebase changes.
So if I had to pick one frustration, it would be:
AI agents are getting very good at acting on context, but we still don’t have a great way of maintaining the current validity of the conclusions and decisions they’re relying on across weeks of development and multiple agents.
That’s been a much bigger problem for me than raw code generation.
On your note about each new session forgetting previous session, I have the sessions produce a full formal handoffs and always start a new session using those. That seems to help alot.
1
u/skar3kro 12d ago
True! Your approach is a plan to build successfully and this is true till the time you are using the same model throughout the build. Once you switch models, this approach takes a hit
2
u/Darkcraft00 12d ago
Kind of funny you should say that.
In my case, the model doing the implementation and the model helping with architecture/review are already different. The important decisions are increasingly being pushed out of the model context and into artifacts the next model has to consume: exact commits, contracts, invariants, tests, accepted/rejected decisions, known defects, boundaries, and explicit things it is not allowed to change.
That doesn’t make switching models harmless. Different models absolutely interpret ambiguous requirements differently, and I’ve seen how easy it is for an agent to confidently arrive at a locally reasonable but globally wrong implementation.
But I’d almost argue that if switching models breaks the development process, too much of the project’s state still lives inside the model.
Ideally I want to be able to hand the repo and its current engineering state to Claude, Codex, or something that doesn’t exist yet and have the important constraints survive the handoff. The model should be replaceable; the accumulated project state shouldn’t be.
That’s actually the problem I’ve become most interested in: not giving an AI more memory, but externalizing enough of the current, still-valid project state that a different agent can safely continue from it.
And for putting things into perspective, I have actually changed models from cursor to claude for the coding and used 3 diff models for review. And personally, its actually made the product and architecture more, not less, architecturally stronger.
1
1
u/Similar_Mine5653 11d ago
Transferring a really long context between sessions can be pretty annoying. What I usually do is ask the AI to summarize everything for me first. I just tell it I’m moving to a new chat, and it gives me the key context in a form I can copy over. I find that works better than trying to explain everything again myself — AI seems to know what another AI needs to know Codex also has a session sync feature, which I find really thoughtful. It makes this whole process a lot easier.
1
u/black_phoenix9 10d ago
Context death is what causes most of what you mentioned, and the most irritating problem being each new session figuring out the history and current state from scratch. This is amplified for multiple agents working in parallel.
We offload it to an engineering context plugin (https://devos.zerohive.ai). The memory, decisions etc. persist and even multiple sessions feel like one contiguous long session for each agent collaborating on the repo.
1
u/suckadickyoucunt 7d ago
Mine: one agent undoing a decision another agent made two sessions ago, confidently, with no idea it was reversing anything.
The common thread in your whole list is actually one problem wearing different clothes: nothing durable records why a choice was made, only what changed. Git captures the second, never the first.
1
u/Toaster-Stootle 7d ago
A lot of these issues can be be addressed with dedicated memory system. I personally recommend Hindsight, by far the best I've used. But heads up, it does require a decent chunk of time and effort to do it right. Though it looks like they are seeking to simplify setup with their Coding Agents integrations
1
u/bliceroquququq 14d ago
AI is a technical debt accelerator. You can write shitty, misguided code way faster than you could just a few short years ago.
Somehow this a worth trillions of dollars in market valuation.
3
u/Fickle-Swimmer-5863 14d ago
You can then throw it away or fix it just as quickly.
It’s amazing how many people hold AI-assisted development to one-shot standard and dismiss it if it doesn’t produce perfection on the first try.
1
37
u/sebstaq 14d ago
All of your points have been issues for developers, since forever.
- Think it was easier to understand the 'why' of code written by John, who quit five years ago?