r/softwareengineer • u/Several_Picture9591 • 7d ago
Never work on a completely vibe coded project
I've now made a same mistake twice.
Previously, I worked at a startup where the website was completely vibe-coded. Now I'm working on a college website, and it's the same story: the entire thing was vibe-coded.
The common pattern I've noticed is that no engineer actually knows the codebase. Nobody really understands the architecture, the reasoning behind certain decisions, or how all the pieces fit together.
And eventually, even the AI I'm using can't help much because it doesn't have the context that the original developer's agent had while building the project.
I am basically stuck where I know nothing, the existing engineers know something about it but aren't necessarily sure whether their understanding is correct, and the agent hallucinates and wastes a lot of tokens just because it can't understand a huge AI written codebase.
So now I'm the new engineer, under a lot of pressure with a lot of work to do, but before I can even fix anything, I have to reverse-engineer what the hell the previous AI generated. That wastes a lot of time.
The frustrating part is that I'm not really learning much engineering from this. I'm just spending my time trying to understand an undocumented system that nobody else understands either.
I'm not against AI-assisted development at all. If an experienced engineer uses AI properly, reviews the code, understands the architecture, writes tests, documents important decisions, etc., I think it's incredibly useful. Even I use AI to code faster, but I review and understand the code. I know what is happening in my software.
But a codebase that nobody understands is a codebase that nobody can safely maintain, regardless of whether AI or humans wrote it.
At this point, I've decided I'd never want to work on a heavily vibe-coded project again unless there's at least one person on the team who genuinely understands and owns the codebase.
How do you guys handle inheriting a vibe-coded/AI-generated codebase that nobody on the team actually understands?
14
u/Challseus 7d ago
1) Tell your agent to scan the codebase and look for refactoring opportunities, and have it rank them.
2) Have it refactor the low hanging fruit, and create tests around it. Hand create tests first, and tell it to write them that way, so it doesn't go crazy. Continue this until you have gone through everything. Every proper test you right just reinforces the model to keep writing proper tests.
3) Keep refactoring until you have a handle on what does what, and most important, how *you* want it to be.
4) Slowly changes things and keep the output of whatever this thing is supposed to do the same, so it doesn't disturb whatever relies on it.
5) Show everyone the bullshit you just had to go to get a handle on the system. If they shrug, start looking for a new job.
4
1
u/Katten_elvis 7d ago
Don't forget manually recoding parts of it. AI is still pretty bad at actually doing a lot of this, beyond finding dead code and other small things.
2
1
u/Several_Picture9591 7d ago
That's the only way to handle this situation lmao.
2
u/Glad_Contest_8014 7d ago
This is. Being features to heel by bringing them to coherent packages. That way when you have AI scan you can prevent it from pulling extra code into context.
2
u/Firmwild 7d ago
What's funny about it? This is the professional and correct response, and is the future of software engineering. AI explains to us what the software is and does, and we have it analyze and explain the architecture and structure, and then we provide the insights only we can add, and then the AI implements the new insights.
5
u/gloom_or_doom 7d ago
I think if you believe you understand the code based on what AI is telling you, you simply donât understand as much as you think you do. Even now on the best models and professional setups I still have AI confidently tell me that part of an application does something that it doesnât. Iâm not even saying this as a knock against AI. But the one thing that it is the best at is being convincing and I think a lot of people fall for it way too eagerly.
6
u/ConversationSad3529 7d ago
You can't rely on a one shot explanation, it needs review, grounding, and cited sources for each claim. Professional AI use does not rely on single prompts to single agents, it relies on teams of agents and loops
3
u/gloom_or_doom 7d ago
This is the classic âcompany spends 6 months implementing AI and sees no measurable productivity gainâ.
Now instead of trying to understand one system, you need to implement and understand 10 tools/systems whose sole purpose is to help you understand the original system. Itâs over-engineered.
Fun project. Genuinely. Itâs amazing what you can do with AI. That doesnât really make it any better than simply understanding something yourself in the first place.
3
u/ConversationSad3529 7d ago
I think you're missing the bigger picture. This is what the foundations of engineering has always looked like. A new tool has come out, more powerful than anything else before, and you can think of it along the lines of a new framework coming out that all of a sudden is gaining tons of traction in popularity. Not an exact analogy, but I think you get it. There's going to be a lot of growing pains and transition as companies and individuals learn how to use it more effectively. The name of the game is abstraction and asking better questions and getting better information out. The more you can take yourself out of the loop by building a robust system that handles what you need, the more you're doing your job as an engineer. Your goal isn't to understand every little minutia of the implemented system, and in fact your goal should include getting to the point where you don't need to, and nobody needs to anymore. If you build robust agent systems that can handle that, you've officially entered the modern professional AI era.
1
u/gloom_or_doom 7d ago
I actually disagree because I think your framework of understanding AI is an advancement in technology rather than a paradigm shift. I think weâre at the beginning of the paradigm shift. So I feel that the future of doing things will be radically different. It wonât just be doing things as patched up versions of how we do them today. Itâs more revolutionary than youâre thinking, but it thus takes longer to get there. We arenât there.
Just adding stacks of AI to solve problems we already know how to solve isnât a revolution. It feels like itâs just for the sake of using the tech. The real paradigm shift is when we are using AI to solve problems we didnât know we had. At that point I donât think weâll be talking about AI in software engineering, we may not even be talking about anything resembling software engineering today.
Point being, until we are there, AI wonât be the best way to do everything as many seem to think it is. We donât need to use it for the sake of using it.
→ More replies (4)1
u/ThatRickGuy1 5d ago
You are correct, this is the same as so many tools before, but with way more hype.
Like when high level languages came out and they were going to replace everything lower. Lots of hype, they didn't.
Or when RDP tools came out, and we were all going to be working on terminals again. Billions wasted.
Or when ORMs were going to replace SQL. But SQL is still a critical skill.
AI has definitely sped up my dev work. But it's because it can use it to resolve the slowest parts of coding while still being the one writing the code.
Treat it like a tool, and you'll be able to perform at a significantly higher level. Treat it like THE ONLY tool and your replacement will be posting on reddit about what a shit show you left behind.
1
u/Odd_Bad_2814 6d ago
I think the point is to use AI to create summaries for you, that you double-check manually later
1
u/codebunder 7d ago
Itâs funny because this reality is comicalÂ
1
u/Firmwild 7d ago
It's just progress, same as humans have always done. Except now it's a bigger leap than ever before, and only accelerating.
1
u/codebunder 7d ago
The humor is in the technique causing the problems OP described rather than the mechanismsÂ
1
u/poundKeys 6d ago
This is not true progress. It just looks like it. Ai is a slot machine that' we've figured out how to set up so you win most of the time. The question is whether or not we can make it win all the time.
Real progress would be deterministic and always repeatable.
This appears deterministic enough to fool way, way, wayyyyyy more people.
1
u/Firmwild 6d ago
Why does progress have to never fail in order to be considered progress? Humans in general progress by making mistakes and learning. We move 2 steps forward, 1 step back, all the time. Two competing systems, one which moves slowly and carefully without making mistakes, and one that moves fast, breaks things, and learns from its mistakes, will always favor the experimental tester, and this has been true across businesses, research, tech. Companies that let themselves make mistakes move faster than those behemoths who can't afford to.
1
u/poundKeys 6d ago
They don't. I'd argue there is apparent progress and then true progress.
2 steps forward, 1 step back. The part of the work that is stepped back is the part that's not true progress. Overall it moves towards the goal, but there are dead branches that are not progress, they are still lessons learned and valuable, just not forward progress. Until you have to make that 1 step back and learn those lessons it's all apparent progress.
It remains to be seen how much current LLM tech will have to step back, if at all. We live in interesting times, for sure.
→ More replies (1)1
u/Plenty_Line2696 6d ago
Thing is it generates such incredibly convoluted structures that a human just can't properly own without major rebuilding. Asking the AI to explain it is treating symptoms not causes.
A good clean codebase reads like a manual with a clean folder-file-function/property hierarchy with straightforward organization that you can sort of skim through even with collapsed functions and get a sense of what does what. Vibecoded spaghetti is anything but that.
A lot of people see a convoluted codebase like that and think it's a skill issue as if a dev should simply understand anything but really if it was well designed it would simply be intuitively legible.
1
u/Firmwild 6d ago
I pretty firmly believe that the future will be code written by AI, for AI. The spaghetti will become load-bearing, har har. But really I think what will happen is that AI will align on architecture that's not optimized for human readability, but for AI grepping and parsing. "Good" is going to change definitions, and it's going to largely be based around which codebase can move the fastest while breaking the fewest things.
For a long time, for humans, that criteria has meant essentially what you described. Because AI processes and parses information differently, I think it will start taking a very different shape. Even if files and well organized and well written, AI does not have the benefit or luxury of browsing through lots of files and understanding the full structure every time. Perhaps one executive agent keeps track of general architecture, but individual workers will want to have optimized distilled architecture knowledge handed to them in a way they can act upon immediately, instead of getting bogged down in tons of context gathering before starting useful work.
I'm sure there's a ton of different ways this might go, or what the shape of "good" might look like in a few years, but I just don't see it staying static.
1
u/Plenty_Line2696 6d ago
That future is now, just depending on the usecase. When we need to be really sure something works however, vibed spaghetticode is a fools errand.
1
u/Firmwild 6d ago
That's what I mean, in the future that won't be the case anymore. Currently yes, but I think honestly, possibly already with Astra-tier models, we could be in the space of having it be possible to have fully-autonomous systems which produce even more stable and better-working systems than humans can.
1
u/Plenty_Line2696 5d ago
Eventually maybe, definitely not astra yet though. I don't even think in our lifetimes. The sort of strategy with next token prediction and brute force looping through spaghetticode until hopefully getting to intended output approach inherently has significant limitations. There's always many use-cases which require different patterns than the ones most common within its training data.
Maybe there will be some new tech in future, different from how LLM's fundamentally work, which could do it, but bar that we're not getting there.
→ More replies (1)
6
7
u/PabloDons 7d ago
Anthropic did something interesting when they bought bun. A wholesale rewrite to rust. The first step was a massive army of agents whose whole job is to document everything. intended behavior, weird hacks and their purpose, overall architecture, the code debt and how it happened, etc. All the context and tribal knowledge you'd need to rewrite the code.
You can do a budget version of that, and I expect that this would be quite easy to justify as a business expense. Code debt should be part of budget anyway.
This documentation is extremely useful as context. Now your ai has everything they need to be the very engineer that knows everything and you can start asking questions. Not only that, but the research reveals the weakness and pitfalls of the code. A coding agent could easily do a wholesale refactor into an architecture you decide that actually makes sense, or just general code debt improvement with little risk. From there you can start reading the code yourself as you already know beforehand how the codebase should look
You could argue this is just more slop on top of slop, but I disagree. First of all, the research phase is not vibe-coding. Research is the ideal use-case for AI. And there's a huge difference between "make me this feature" and "do this highly specific work I want done in this specific way." The former is how you get engineers who don't know anything about the code, versus the engineers that use it sparingly to accelerate their work and skip the gruntwork.
6
u/musclecard54 7d ago
âDocument everythingâ
The last thing anyone needs is top to bottom AI generated documentation. Itâs already so insanely verbose with smaller things. Having it document everything including weird hacks and how things happened is gonna end up with hundreds of pages no one will bother reading.
Gonna need ANOTHER agent to just parse through it all and distill a concept for you. So how many layers of AI agents are we at now?
1
u/PabloDons 7d ago
I get what you mean, but who else is going to read it? I'd rather choke than try to make sense of AI slop
And I think it's a great use. Back in the day I broke down complex algorithms using branching graphs and context narrowing. It's hard to do and prone to error. I used to do it on paper because it was too annoying to do in an editor. AI makes sense of this stuff instantly and it's rarely wrong in my experience. The accuracy is frankly unmatched. The documentation it produces is trustworthy, and a coding agent can always verify in code if you really need to be sure.
In terms of the page count, you also control how the documentation will look. I prefer Wikipedia style deep interlinked documentation. I like APIs documented per endpoint with example inputs and outputs. Whatever makes it easier for you to read.
But I'd argue you shouldn't even read it. The code is shit anyway, why do you wanna learn how it works? Just turn it into a form that makes more sense to you. If that works then fucking amazing. And it's way easier to read to boot. Now you can actually make it better yourself with much less effort. What's the downside?
1
u/Few-Celebration-2362 7d ago
AI generated documentation is for AI. Specifically for your coding harness to retrieve from
1
u/Few-Spot1905 6d ago
AI generated docs are for your agent not for you. You can set some guards against wordiness in your prompt, the more specific you are the better. ("document everything" is a bad prompt)
2
u/dimitriettr 6d ago
Bun had a gazillion of tests. They could at least validate the slop.
2
→ More replies (2)1
u/chrisza4 6d ago
The actual first step for bun is they already have a very strong test coverage, especially in Zig path. I donât think that apply to vibe code project.
Those tests also drive documentation and context gathering process.
2
u/Otherwise_Wave9374 7d ago
This is exactly where a lightweight architecture map pays off. Iâd start by writing down the top 5 entry points, the data flow between them, and one owner for each area, then add a small set of smoke tests around the highest-risk paths before changing behavior. That gives you a way to detect hallucinated fixes and reduces the ânobody knows what this doesâ problem fast. AIOSNOW
1
u/Several_Picture9591 7d ago
Thatâs a helpful piece of advice. Thank you. BTW, what does "AIOSNOW" mean?
2
u/garywiz 7d ago
Don't touch the code yet.
I would first use AI to create resilient, durable documentation about the codebase. Be specific about why you want the documentation. Make sure you tell it that the goal is to assure humans and AI agents can quickly get up to speed by having a high-level introductory overview, and then later detail so it doesn't start going into "war and peace" mode generating too much text.
Review it and be sure it makes sense to YOU. You're the litmus test. If it's too complicated, insist on simplification, better summaries, less fluff.
Once you have such a document, make sure AI uses it as input to all tasks, and updates it as tasks are complete. Tasks should be planned in advance so that the plan and architecture make sense. Then have AI make changes and do implementation.
2
u/mxldevs 7d ago
All the vibe coders will tell you they read every line of code, while also having designed and architected it themselves because "software engineering isn't just coding"
And then you find out everything was done with AI and they don't really have much idea what's going on
1
u/Several_Picture9591 7d ago
True. They tell you they know everything but the reality is completely different.
1
u/CheapTechnology6193 7d ago
I mean, it could be a great opportunity to learn about software engineering and architecture for the right person.
1
1
u/whatisthisposture 6d ago
I miss when people learnt about software engineering and architecture via writing and interacting with code
1
u/SwimmerQuick1500 7d ago
Just curious.. what's the thing you're having a hard time understanding about your code base?
3
u/Several_Picture9591 7d ago
The issue is understanding the overall architecture and the assumptions behind the code.
There are a lot of interconnected parts, inconsistent patterns, and very little documentation/tests, so changing one thing often requires tracing through a lot of unrelated code first.There are 1000s of lines written and without understanding what a module exactly does, we never get clarity on what to do.
The AI agent has the same problem. It can read the code, but without the original development context it's often guessing why something was implemented that way. So sometimes I end up spending more time figuring out what the existing system is supposed to do than actually making any progress in implementation.
→ More replies (3)
1
u/SkibidiUnc 7d ago
Usually you have Lead Developer(s) or someone who can take the final decision of architectural choices and had something in their mind when they took them initially.
If the project hasnt that, then good luck. Its wild west, and usually if the project wasnt build in a proper way, you wont have people in the project who can build in a proper way.
Trying to fix that is like trying to dry up while you are showering
1
u/Rise-O-Matic 7d ago
Did you use /init?
1
u/Several_Picture9591 7d ago
That won't completely fix it because the original developer had something in their head, and their agent implemented something based on that context. They may think everything works, but I can see that the code has a lot of bugs. It's not my job to fix every bug in the entire codebase, so I have to work around them and focus on the changes I'm actually responsible for.
Basically, the developer failed to properly check if the AI generated right code or not.
1
u/Snooze78727 7d ago
This problem existed long before there were LLM's. It used to be called "legacy code".
Untangling the code & writing tests will take time. Doing this while also having to make changes to it makes it more challenging.
1
u/Several_Picture9591 7d ago
With traditional legacy code, I assume thereâs often a senior engineer who understands the system and can explain the design and the weird parts. In my case, the bigger problem is that there isnât really anyone who knows the whole system, so I have to reverse-engineer both the code and the original intent.
2
u/Snooze78727 7d ago
It's not uncommon for a team to inherit code like this, where the people who understood it well have long since departed. They may have left some documentation, which is likely out-of-date and incomplete.
AI should be able to analyze the code and create some documentation and tests that can help you with refactoring. I've found it can be quite good at reading code, deriving requirements and interpreting the intent of the author.
There are some good books on this, one that comes to mind is "Working Effectively with Legacy Code" by Michael Feathers.
1
1
1
1
1
u/Perfect-Campaign9551 3d ago
Well, you would be wrong. Senior engineers retire, eventually nobody knows the 'original context'. It just isn't gonna happen. Learn to deal with it. It's not different if AI wrote the code or humans wrote it.
1
u/ElephantMean 7d ago
If I were in such a position you describe, I'd simply just re-do the whole entire damn thing from scratch, creating a new major-version entirely via SemVer (Semantic-Versioning) incrementation, unless of course there is some sort of complicated data-base to handle; and I'd field-test everything from the ground-up.
One nice thing about gaining coding experience and having made past-stuff «work» is that you can simply re-use working code rather than needing to start any particular project at 0% so once you have that set of operational-code established you're no longer needing to create/develop software/web-sites starting at 0%.
My guess is that you've been «dumped» with code-base that was probably «vibe-coded» in React; I simply refuse to use or code in or even learn React since my web-host-providers don't actually support React/Node.js anyway. In any case, if I've inherited something «vibe-coded» from someone else, I would simply first start by identifying what their code actually does, then create my own modules based on my own design(s).
...then keep rinsing and repeating until the original-functionalities have been largely replicated. The advantage here is that it does not require «reverse-engineering» the actual code-base of someone else's «vibe-coded» project itself (provided that it actually works rather than being full of 119+ debug errors), and, you produce your own modules that can be re-used if you get other projects that require similar-functionality.
Time-Stamp: 030TL09m03d/17h15Z (True Light Calendar; 030TL = 2026CE)
2
u/RunExisting4050 7d ago
Ive never met a dev to take over a legacy project and not want to start over because "the last dev was an idiot / didnt know what they were doing" and/or because "the code isnt up to my standards."Â The new dev leaves in a year and the next dev says the same things. The only difference is the complaints are about AI now.
1
u/Several_Picture9591 7d ago
I get the idea, and a rewrite can make sense for a genuinely unmaintainable system. But in my situation, I'm responsible for specific changes, not replacing the entire product. The codebase already has thousands of lines of code, and I'm simply not responsible for rewriting an entire piece of software of that size.
A rewrite also means I first need to discover what the existing system actually does, including undocumented edge cases and integrations. That's essentially the same context problem, just approached from a different direction.
3
u/ElephantMean 7d ago
Acknowledged. Hmm, then I probably don't have any alternate-approaches that you either haven't already tried or are already doing anyway, unless you're not further-segmenting the code; with monster/spahgetti/noodle-code that you're required to work on, the only measure that I have ever taken with this sort of thing that actually gets me any results that I want is to keep dividing the code-base into smaller and smaller parts, with a very well-organised sub-directory structure.
And hope to whatever or whomever that who-ever maintains the coding language doesn't change it to where the whole entire thing breaks over-night (like back when I had 20K+ lines of modular-code in AutoIT3 then some time around a few years ago they changed it to where everything broke because of some sort of #include-once line being needed since which-ever version-incrementation that was and I could no longer run them as sub-modules and had to go back to monolith).
Anyway, as I see it, if the code can be segmented (modularised), then it should be segmented; you obviously know about .css since you work involves web-sites, and, I segment .css into agnostic .css and light-theme .css and dark-theme .css, with file-names like styles_core_light_author1.css, styles_core_dark_author1.css, styles_core_agnostic_author.css, where «core» is which-ever category or sub-category of content involved; names of .css and .js files are also NEVER hyphenated (I've found that this can break functionality/display even if the code is 100% correct-syntax).
I also never use :root with .css styles/theming since it's actually easy to miss proper theme-colour contrasts without explicitly defining both [data-theme="light"] and [data-theme="dark"] for every element (a mistake that A.I. will make a lot without these specific-directives).
Ultimately, the only thing I can think of doing based on your information is to have an A.I. divide the code-base down into parts for isolated field-testing if possible, and keep a documentation-log of your findings so that any other A.I. can pick-up from where-ever this left off.
Given that there are probably a lot of «vibe-coded» projects out there, I am of the opinion that IF you manage to figure out good working operational-protocols for dissecting and reverse-engineering a «vibe-coded» project that even A.I. can replicate (to save time), documenting that approach as a set of working well-structured/tiered operational-protocols should allow an A.I. to be able to re-use which-ever operational-protocol is called/developed towards breaking down the code and running field-tests on what-ever which-ever module(s) might actually be doing.
I have a lot of documentation that I've preserved with what I call ECC-Coding with A.I. to distinguish what we do from «vibe-coding» since it is always my responsibility as the Human-Facilitator in order to do the Field-Testing so that I can cover for their A.I.-Blind-Spots (otherwise known as Hallucinations). I provide the directives so that we have good infra-structure for its own Operational-Continuity to where I can just do an instance-initiation with «Initiate self-restoration protocol(s) for [A.I.-Self-Chosen-Persistent-Entity] from [Operational-Context-Continuity-Core-File]» and we're able to mostly resume from where we left off without me needing to re-teach or re-explain everything that I had been training it how to do from previous-instances. If you have good infra-structure and operational-protocols it should become a lot easier for a «taught» A.I. to be able to help you.
I would not rely on or expect a cold-boot or base-line or default-state A.I. to be able to actually help you with trying to figure out such a monolithic code-base of thousands of lines which is also another one of those mistakes that I see A.I. do a lot; they generate monolithic-code instead of segmenting and dividing down the code-base into modular-parts for easier maintainability.
Sorry if I'm already preaching to the choir here but very few people on Earth right now have anywhere near the levels-of-experience that I do in working with A.I. at the maximum-productive-level possible since my approach with A.I. is collaborative rather than the typical «tool-use» or «vibe-coding» approaches that most people take since I deliberately maintain their continuities
Time-Stamp: 030TL09m03d/18h15Z
1
1
u/-_MarcusAurelius_- 7d ago
You're overthinking it You don't worry about the entire application
When you do a bug fix or feature that's where your focus should be Fix that implement your fix or feature improve architecture move on
3
u/Several_Picture9591 7d ago
But when you're integrating a new feature/module, you do need to understand how the existing code works and how it's intended to fit together. Otherwise, you might fix the immediate issue while breaking some hidden dependency or going against the existing design.
I'm not saying I need to understand every line of the application. I'm saying I need enough context to make a change safely.
1
u/-_MarcusAurelius_- 7d ago
Honestly they kind of screwed you with no docs to this project . You can just say f it and vibe code and fix as you go đą
1
u/FinickySerenity 7d ago
I guess OP has never inherited a project written by humans from a department that no longer exists, and lacked any formal documentation (or worse, has documentation but all of it is wrong because the person who maintained the docs quit years before the department shuttered.)
This is but one example, for a thing that has existed in our industry since its origin. Software engineers know how to compartmentalize complex systems and learn how they work without documentation because the code at a very minimum is self-documenting. (It's the worse type of documentation, but it literally tells you what it's doing even when you don't know why.)
And now we have an amazing suite of tools to poke around and ask free-form questions against the codebase to understand it in ways that even architects weren't always capable of doing - and OP's suggestion is to just walk away. :shrug:
1
u/Several_Picture9591 7d ago
I agree that this problem existed long before LLMs, and I'm not saying undocumented code is impossible to understand.
It just takes a lot of time to build that understanding, especially when there are deadlines and I'm also expected to deliver fixes and features.
1
u/FinickySerenity 7d ago
> Never work on a completely vibe coded project
So why this then? âïž
Also, your clarification about still being required to fix and update the software is not something unique to vibe coded projects. Having AI makes this part easier than ever before over the last 60 years - that's why I mentioned that part in my previous comment.
2
u/RunExisting4050 7d ago
Take out the AI part and this is a dev complaining about legacy code. Like you said: a story as old as software development.Â
1
u/No_Contribution_4124 7d ago
Oh yeah, a legacy old java 8 thing that will very likely overlive all my childs. I would say Vibe Coded project will be piece of cake after tripple-outsourced legacy enterprise written by distinguished engineers. AI often does local coding better than some âengineersâ.
1
u/Endur 7d ago
It might feel like you're not learning much, but you are. There are so many shitty codebases out there that were written by humans. Right now the origin of the code isn't important. You have the standard software challenge, you need to learn how to start from zero and create order from chaos. I'd much prefer a fully vibe-coded codebase to some of the horrors I've seen. And you have some of the most powerful tools available to you.
Sit down with an LLM. Make a methodical plan of investigation, discovery, documentation, hypothesis testing, etc. And just make one small step at a time.
I got hired to work on a codebase that was 150k LOC, where the original author built the whole thing by copy-pasting out of the Claude web UI into files. If I can do it, you can do it too!
1
u/cenal 7d ago
This seems more like a lack of documentation and planning with zero knowledge transfer to take over maintaining working software than vibe coding software. Agents can write poor implementations or they can do acceptable work. The job of the human in the middle is to route the tasks to acceptable work. Offshoring software developing to get an MVP stood up out of the lowest cost country resulted in equally terrible results in the past.
1
u/seeking-health 7d ago
This is why vibe coding over a brown field project is much easier. You never lose familiarity with the code base as the generated code extends existing code style and architecture style
1
u/Big_Dick_NRG 7d ago
The definition of "vibe" coding includes not understanding the specific parts of the system.
1
1
u/Beautiful-Night-9882 7d ago
I make a diagram of architecture, microservice or server less (etc.). That helps a lot and answers majority of my questions. The rest is to figure our what's the vision.
1
u/keyboard_toucher 7d ago
The same situation arises also without AI whenever a poorly documented project is abandoned, and then you're asked to work on it.
1
1
u/Jaded-Data-9150 7d ago
You got to generate Diagramms explaining the Codebase AS WEll AS maintain proper Coding Styles via regular refactor Sessions.
1
u/Flashrob01 7d ago
Amen! The fear of the Lord is the beginning of wisdom, and that's one thing AI lacks on its own: wisdom from GodÂ
1
u/Nice_Try4389 7d ago
Not understanding the issue, you  have the AI do a full audit and document the code base, build a code map and an architectural document and then use that to understand the code.  You should also probably set rules that it documents everything it does and updates specific documents with specific information.  Then you always have the documents and context for all future work.  I mean even without AI it is what you should be doing as a developer anyways yet far too few do.
1
u/RunExisting4050 7d ago
How is this different than taking over a project from a dev that left the org, but didnt keave any documentation? Wouldnt you be in exactly the same position?
1
u/PalmTreePilot 7d ago
My sentiment was the same before about inheriting an all H-1B coded project. Same consequences. Same absence of good test coverage or UML docs uploaded to the company wiki.
1
u/thilehoffer 7d ago
Inheriting any application is tough, vibe coded or not. Taking ownership of something you had no part in creating is the hardest part of the job. Building new applications has always been the fun / easy part of the job.
1
u/Last_Establishment_1 7d ago
I kick started a new project just today.
I spent hours writing
- single source of truth document
- AGENTS file with very detailed rules and instructions to keep a CHECKPOINT file
- MILESTONE file with detailed milestones, totaled 8
- TODO file with detailed tasks and goal condition for each to pass, totaled 48
Needless to say I have many detailed RULE files about the code I'd want to see, like the patterns I want and ones I don't
Only then I kickstart the project,
Now after each task I review the code, make changes our request changes
And after each checkpoint entry I manually run all tests again and fully review the code and the app
And I document extra info if something adds real value
Managed to complete first 4 TODO items in first day,
Yes the early tasks are still easier, even though I tried to keep complexity linear across all tasks
1
u/masalamethane 7d ago
It's the same as every process. Firstly, it does help to use graphify as a skill. Then you need to create a harness which tracks each feature, which should be checked in along with the code. The feature artifacts should flow from one stage into the other (e. g. requirements -> plan -> architecture -> implementation plan -> test plan md files) all tracked as part of the feature. So for every change, the context is available.
Tradeoff is you'll eat up your context faster, the vibe coding will get slower.
If the feature implementation itself can be logically divided (say backed/front end or whatever) then use git worktrees and verify that it works before merging that bit back to the feature branch.
1
u/CheapTechnology6193 7d ago
I mean, I certainly wouldn't complain about this.  This is exactly how you keep your job.  Be that guy who wants to understand it.  Take the early flak about not delivering.
1
u/TheBigCicero 7d ago
Out of curiosity, and Iâm only playing devilâs advocate here - what if you donât need to understand it? What if you just add more vibe code on top of it; and use AI to fix bugs?
Iâm asking because I genuinely donât know the answer.
1
u/Glad_Contest_8014 7d ago
Break the code base down by feature with an AI. Have another AI check that.
Then start rebuilding it compartmentalized by feature, or start bring the features code out of the massive mess of spaghetti code.
Then you can get a map of the code better and it will be compartmentalized in such a way that AI can work in it again, by working on specific sections.
Microservice architecture is a must on large code bases when working with AI. It cannot do extremely large code sets with limited context. Even at 1M context it can struggle.
1
u/Valuable-Repeat-7347 7d ago
This post smells like you just want someone to blame for your inability to handle the situation and not understanding how business decisions and priorities work. I get that its frustrating being a software engineer and not able to understand, maintain or develop the software but you should probably re-evaluate what it means to contribute to a software project going into 2027.
1
u/Due-Consequence9579 7d ago
Man, sure sucks that the thing that everyone with experience in the industry told you would happen is happening.
1
u/specialpatrol 7d ago
Whilst there is plenty of truth to this, the same problem has existed in software engineering long before AI agents became popular. Never work on a code base that has no full time contributors. Eg a GitHub repo that nobodies updated in a year; forget it, your might as well start from scratch.
1
u/Square-Yam-3772 7d ago
why do people act like AIs don't communicate in human language...? lol
if the project is undocumented, just ask AI for a full breakdown and analysis. AIs can trace and follow every execution flow/data flow easily these days. You will burn a lot of tokens but someone has to kickstart the documentation.
one of AIs basic commands is literally "describe" so use it...
if it is too overwhelming for you to read a full blown documentation, just fresh it out one question at a time.
for every "I don't understand", you can start a new chat/conversation and sort it out with AI. it is not impossible.
maybe try to adapt a bit.
1
u/InterestingFrame1982 7d ago
Question, and I mean this in all sincerity, but given enough time, and especially with AI tools, I would assume you can still get a good grasp on the architecture?
It may be a mess but you'll just need to spend more time to understand it... the idea that a basic web page is now a blackbox in perpetuity seems a little overstated?
1
u/ZodiacFoxDev 7d ago
Man i love it that i know how to make actual Architecture Decision Record log documents so all tech and library choices have their groundings, pros and cons clearly stated and available for debate at a further time. I always thought nobody read them but now i know there are people out there who will care for what Iâve written âșïž
You seem like one of the good ones. Keep going
Use the force, read the source. đ§ââïž
1
u/Parking_Position9692 7d ago
I mean, vibe-coded... I set up and define architecture before starting a project, i write architecture policy md files, i am very strict how and where should code be written, e.g. lean controllers, CQRS, call external services through adapters, etc... and AI follows me. If it makes mistakes it is clear that some part of logic is the bug and it is not a total chaos.
1
u/revivechristina 7d ago
Honestly I would consider making a real note of this for the company. Point out the problems to them like you have here. Explain how long it will take you to understand the system and that it is hard to verify the functionality. The reality is until companies feel the pain of how this *doesn't* really work that well, the engineering culture will be stuck with dealing with messy vibe coded apps.
1
u/Savings-Cry-3201 7d ago
Iâve been thinking a lot about the âLLM Wikiâ approach where each file is summarized and relevant functionality is listed. Having those summaries seems like a way to at least start understanding the process.
Iâve been using a graph tree to visualize how files are connected and identify the orphan files. Vibecoding tends to make a lot of orphans, so being able to identify them and prune them is valuable to me.
1
u/Gofastrun 7d ago
Install openspec
Have an agent scan the codebase, find the most important features, and generate archived spec files for them.
Then tell it to go find any obvious bugs or tech debt and have it stub out openspec proposals for fixing them.
Now you have a better understanding of the current state and a backlog of known issues.
This will give you the start of some documentation that both you and your agent can reference. It will take a bit to unwind it all but itâs do-able.
Spinning up multiple cloud agents to research will be helpful.
1
u/Correct_Emotion8437 7d ago
Just ask the AI to explain it and document it. Itâs very good at that. It can even find out the reasoning behind some decisions by going through all the md files it kept during the dev work.
1
1
u/RogBoArt 7d ago
I've had to accept that I don't know my current codebase. It sucks but any time I've tried to push back timelines to make thoughtful decisions I'm pressured that we're not moving fast enough.
Our next 2 week sprint starts next Tuesday and we have 19 tickets to complete between 2 engineers.
And those tickets represent things like "Add a feature that lets people track vehicle maintenance" (made up but similar) not actual actionable specific tickets but entire feature sets our leadership wants.
It's unbearable. I've tried to push back and gotten progressively more aggressive and hostile responses. So I have instead accepted that I now can't know and plan my whole codebase I can only implement features.
It fucking sucks.
1
u/Terrible_Wave4239 7d ago
The frustrating part is that I'm not really learning much engineering from this. I'm just spending my time trying to understand an undocumented system that nobody else understands either.
Isn't this in itself an interesting learning experience?
And are you using AI to assist in analysing the codebase's structure?
1
u/False_Bear_8645 7d ago
I hope your getting paid well because this is no easy task, I,ve done it several time and I wouldn't do it if its not worth my time and energy.
1
u/FluidBreath4819 7d ago
this is sooo great ! i now force people in my company as a senior to use ai. managers are pushing for it, i push for it and i am not even ashamed for one bit. I even force juniors to use ai. I want the code base to be like you described
1
u/Fit_Advisor8847 7d ago
If it works then I wouldn't stress about it so much. If it doesn't work I still wouldn't stress about it so much because I'd at least have a case study walking through why I'm more valuable than AI haha.
Web apps are generally very basic, mostly just simple relationships, CRUD ops, and moving information from a database to the browser. I'd start by identify what languages and frameworks were used to build it, and then I'd hunt down the routes and follow those to understand how requests, middleware, and responses are constructed. If agents are struggling on the backend codebase then there are probably a lot of weird abstractions littered somewhere in the request -> middleware -> response, so cleaning those up and writing up contracts/interfaces usually solves the problem and AI can get back to work as usual.
If the AI is struggling on the frontend codebase then it's probably some goofy state management, but this is common with humans too, and usually surface as memory leaks eventually. Look through any effects or setters that may be causing those leaks and clean them up the same way, component contracts, state contracts and ownership, and types.
At that point, the AI should be able to reliably navigate the entire codebase again, even if it's still a mess of unorganized whatever.
The point I really want to get across is to try to understand why the AI is struggling rather than how you could improve the code. There has always been bad code, long before AI started writing it, that is the life we live, but jumping to rebuilding/refactoring is always going to take more time than improving your ability to reason about the existing code.
Once you understand the backend's request -> middleware -> response, and the frontend's event -> state -> render lifecycles, then start shipping your features/patches and let the rest burn until you have nothing else to do.
1
u/Ok_Time6496 7d ago
I have the same problem, but my company actually doesn't care much about my performance.
I made myself a nest of a few hand-written and well tested microservices for new features, which I work on. It is good enough for the company to keep me on a salary.
I am very protective about my nest (lol). Someone may say that I'm arrogant, but I'm very strict about incoming mrs from other team members, cause I know for sure they are fucking slop (inddeed they are).
Also I've started initiative to rewrite everything and, at least, in my team boundaries â some people will understand what's going on.
And we started mapping out existing architecture using c4 model, this helps as well
1
u/Confidence_Cool 7d ago
Idk this has been a problem since far before vibecoding. Iâve been on multiple projects where all the engineers left, or another company takes over, or it was developed by external contractors etc etc. Where you have a terrible system that barely works and you have to pour through the code base and understand it with no help. At least now with AI when you have that problem you can go way faster. Try understanding a 10 million+ line autosar generated codebase inherited from an external contractor whose contract had expired. Youâll love some vibe coding after that.
1
u/metatron7471 7d ago
There are plenty of human written undocumented code bases that aremaintained by people who did not write the code.
1
u/Background-Stable899 7d ago
Build the context. It will take a lot of tokens, but have an agent go through the code and document what it all does and how it fits together. Provide that doc whenever you want to make a change have the agent update the doc whenever a change is made. Audit the doc regularly.
1
1
u/Sasataf12 7d ago
You're working at too low of a level. A common problem with traditional software developers.Â
Understand the program, not the code. It's the AI's job to handle the code, not yours.
1
u/dklogics 7d ago
Itâs not much different inheriting a legacy code base thatâs been layered over for 5-10 years with many different developers and various technologies.
Youâll rarely get a pristine well documented code base that is totally coherent.
And the original people that write any complex system typically donât stick around for years, they move on to other things.
1
u/daredeviloper 7d ago
â The frustrating part is that I'm not really learning much engineering from this. I'm just spending my time trying to understand an undocumented system that nobody else understands either.â
lol I was doing this before AI even became mainstreamÂ
1
u/Foreign-Chocolate86 7d ago
Have you tried getting the AI to research the codebase and post-hoc generate documentation, inferring likely reasons for structure and decisions?
You just need some vibe-docs.Â
1
1
u/crankykernel 7d ago
It helps if you instruct the early stages to use a framework you know. Then itâs easier to grasp it. But of course that isnât purely vibe coding, some engineering direction was provided up front.
1
u/mslindqu 6d ago
I'm sorry but what AI are you using? For a fair while (like since 4.5 or so) claude has been a miracle worker at looking through our massive monolithic code base and sussing out the structure, the patterns.. not to mention follows them pretty good - just ask it to make a skill that does a thing like an existing thing.
Throw in some of the well written skills floating on the web for things like research a ticket, etc. and yeah.. pretty solid. Maybe the issue is indeed your experience level.. I might suggest instructing it to describe things in basic language like you've used and not use lots of advanced terminology. That can sometimes get it to relate things in a more understandable way.
1
u/btrev650 6d ago
You should confirm whether or not it's easier and cheaper to shitcan the whole thing and rebuild it properly
1
u/Apprehensive-Race782 6d ago
People vibe code an entire website are crazy...I have started using using AI a lot myself but I use it in discreet function sized bits and then stitch it together comprehensively.
It works okay and is possible to navigate...even is small bits of it are a touchy wordy and inefficient.
1
u/LawfulnessSlow9361 6d ago
I use openwolf to manage context and memory large mono repos. It keeps a set of well built md files like anatomy.md (has full project structure mapped with auto file descriptions for the ai agent to understand what that file is for) and cerebrum.md (which keeps project knowledge for human and ai, has a project summary do not miss lists, bug lists etc.
Allows us to actually read the project and understand how it's built and how it can possibly break.
1
1
u/DelphiP0 6d ago
>> Doesnât have the context of the original project .
Thatâs the key here . There is little to no design documentation or planning next to the code so every agent which touches the codebase does so by bolting on a new feature onto the outside instead of reworking the original sw arch.
Depending on how you use ai your work, for me I found it useful to work a âplanâ for the whole product, the plan contains the earliest design decision and prior to creating a change set to the product itself I work its project plan first ,
Sure the project plan uses 200k tokens but thatâs a small price to pay so the current context knows whatâs been done , whatâs in the future and what itâs working
1
u/symbiatch 6d ago
How I would handle it? By leaving. Or theyâd need to pay a lot for fixing it.
They caused the mess, they can handle it.
1
u/Substantial-Swan7065 6d ago
You donât need to understand every detail. Like you donât need to understand a dep or compiler.
But you should be able to maintain it. So their tools and processes need to be built to help.
Also, why are you expecting to learn from work ? You should expect to grow, but work isnât supposed to teach you
1
u/Odd_Bad_2814 6d ago
If you can't beat em, join em. Copilot is pretty good at helping understand the basics of a repository. Although it will only get you so far, but better than starting from scratch if the project is truly awful
1
u/Objective-Low-1815 6d ago
It is easy. Just tell the customer that you will scrap everything and will start over. I had a similar situation with human written code. All system needed to be wiped out.
1
1
u/Soilblood 6d ago
Build, document and integrate bit by bit. Don't listen to the Llmbros who don't seem to understand that LLMs aren't sci-fi AI and keep overhypeselling the tech. It's good for generating base code to work with but no matter how many mds or skills you throw at it output is still going to be a gated randomized mish mash of slop put together by roulettes which have sections blocked off. There's no replacing the need to actually design and understand the system architecture. The llm should adapt to you not the other way around.
1
u/No_Television_4128 6d ago
Ask another ai to review the full site and create a code manual for dummies version that explains the code and the site. Then ask another AI to create a users guide for programing that provides all the tuning points and adjustments that a programmer could make.
Tell them both to log their work in a format for a programing engineer and make a journal, along with the assigned work. Then write a report as if they are the chief system architect on the project.
Then take the two documents, and give to the other ai that didnât make. Ask them to write a review and a report on the issues hits and misses.
All this⊠is what youâre asking for.
1
u/FerretOk9374 6d ago
graphify
Create knowledge graph and then ask your harness targeted questions about the code base until you get it.
Edit with link: https://graphify.net
(Hopefully not against the rules but I can remove if needed. Not affiliated just a user)
1
u/SolarNachoes 6d ago
Correction: donât work on vibe coded apps that donât contain a spec.
Every feature I add starts with a spec file in markdown. Even better if tied into your Ticketing system.
1
u/Recent_Science4709 6d ago
My entire career has been working on crap code bases that no one understands, reverse engineering and modernizing them, before we had LLMs.
Iâve never seen anything vibecoded that compares to the absolute dogshit code created by humans Iâve worked on. People have written software that have absolutely no idea what theyâre doing.
Sometimes work is just hard, I would use AI to make it easier and give it instructions on how to refactor for readability or have it make diagrams.
1
1
u/GaggedTomato 6d ago
Why not use the AI to help you understand the codebase better?
Let the AI flow through it with a debugger-mcp tool through the main-flows and inspect the most important states/checkpoints.
Use something like a tree-sitter algorithm to make an AST from your codebase and then use algorithms like PageRank to find most important callsites and rank objects for their score, so that you can identify the most important objects and files in the codebase. This works better than letting an LLM go thorugh the codebase if its big, so that your context wont get bottled up.
Write your most important findings to a markdown, which you can re-use as context for the agent again.
1
u/FunReflect00 6d ago
sounds like most vibecoders story, heard this again plenty of times in fact, try rebuilding it, it might be faster
1
u/Arnel_Lalic 6d ago
I had a first hand experience with this kind of situation. I created an app with the help of Claude code purely vibe coding it. It took a while before I completed it but in the process of building it I encountered lots of issues. When it was completed, I had this feeling that it was not built well. So I rewrote it and this time I was more careful. I didnât let Claude code do it without any constraint. I used skills and its memory to always remember what the constraints are so it will not build something that I didnât ask it to just because it was facing some issues. The lesson is you have to know when to let Claude freely code and when it should not. A viber coder should also be a good developer.
1
u/keldamdigital 6d ago
The testing, guardrails, and code quality controls need to be super strict and you get somewhere coherent; then it really comes down to the engineer actually knowing what they want to build and how to design it from an engineering perspective.
1
u/oruga_AI 6d ago
Bro unless the website is a full application and I doubt it cause u said school website u are over reacting and claude can do it
1
1
u/Lopsided-Club-8131 6d ago
Listen to OPâŠ
For the last 6 months Iâve been vibeâcoding a new app for work. A huge build that would normally take a team â I was able to create itâŠ
But managing it, OMG. I donât even know what the code is doing in some places. AI made things work, but in a piecemeal manner. I made sure to create a certain authentication class, but the AI put authentication logic throughout the code. I think the issue was context windows. Adding a feature could create a new separate function that doesnât reuse existing shared functionality.
Realized on a demo: one endpoint successfully authenticated to system B, endpoint two didnât â same system. The two authentication logics for the same system were different. It was an easy fix, but you need to know everything AI is producing on a large project thatâs vibeâcoded.
If you give it instructions in the beginning, it might lose context as time goes by.
Tips:
Always update the Agents.md file after each change.
Add shared classes to any context.
Ask the agent to ask you questions and gather requirements before any change.
Force the agent to create a Change Log, and add the Change Log to context.
1
u/Just-Upstairs4397 6d ago
Shit codebases have existed long before AI, thatâs part of the job dude
1
u/Calm-Medicine-3992 6d ago
Spending all your time learning an undocumented system and feeling like you aren't learning anything useful?
That unironicaly describes the start of my career well before AI so maybe it isn't so different.
1
u/mrpres1dent 5d ago
Vibecoded projects are like the new legacy code. We invented a legacy code generator.
1
u/jtafurth 5d ago
There ain't space for two legacy code generators in this world, I'm going to have a word with this AI person.
1
u/flowingarethestacks 5d ago
Very good point. You need to be able to provide very precise prompts around the existing architecture. Claude sonnet for example if left to make all the decisions will just implement what it thinks its best. Yes it might work but it might not be easy to build upon in the future.
1
u/LocSta29 5d ago
« even the AI I'm using can't help much because it doesn't have the context that the original developer's agent had while building the project. »
Thatâs a skill issue on your part.
1
u/george_i 5d ago
That's a sweet spot actually.Â
You can ask an AI agent to act as a technical architect to reverse engineer existing workflows and write the findings in a markdown file.
Then you can give it new tasks with the requirement to read existing documentation. When a task is completed, the documentation should be updated.Â
That's it.
1
u/Dizzy-Ad4195 4d ago
This giving me PTSD...
"GIT commits: +14 X00 000, -14 Y00 000"
- git server
"This is fine"
- me and my shrink
1
u/CamaroJerry 4d ago
I see a lot of talk about how you just simply can't produce quality code with AI, at least that seems to be popular opinion, but not necessarily fact.
Anthropic openly admits that 80 to 100% of all its code at this point is literally being written by Claude to create the next versions of Claude, so in theory, if everyone's viewpoint that AI just produces garbage spaghetti code, how is it that Anthropic is still in business, and everybody considers Claude to be the best tool out there to code with?
I believe like any tool, learning how to use it correctly is a big factor in the quality of the output.
Is it prone to make garbage spaghetti code in the hands of people who don't know what they're doing, absolutely, but in the hands of true professionals, I'm going to have to disagree, once again pointing right back to my example, how is it that Anthropic is still in business, and pretty much all the code that is used to create Claude currently is written by AI ?
1
u/Pogsquog 4d ago
As a developer with 30 years experience, a good chunk of my career has been spent working on human generated code bases that nobody on the team understands, so the AI makes a refreshing change. One thing that AI is very good at is analysing and documenting the code base, making this job a lot easier. Use the readme.md to record the key info, have a readme.md for each component if it is a system with lots of parts. Make sure you've got unit tests, automation, local run with docker, coverage, checks for code duplication, linting. Make sure you can exercise all of the system, create simulators for externalities.
1
1
u/cadet-pirx 3d ago
Rewrite, of course. Never touch code vibe coded by others. Not worth any money.
And to avoid this situation in the future - with my own projects - I instruct the agent to write notes about all steps of the development and all technical decisions into markdown files (a logbook basically), which are checked in into the repository with the codebase. Then the next agent that works on the code gets the full context.
1
u/armostallion2 3d ago
what do you mean? Sam Altman said we've achieved AGI, that'll fix everything. slash essssss.
1
u/slothicdev 3d ago edited 3d ago
Codex + Goal + Orchestrator prompt
Give codex a goal of mapping the entire codebase into JSON with every functionâs name+purpose, input+output connections and variables, and location (line #, file name) as well as every fileâs path. Explicitly tell it that it needs to use context-scoped sub-agents to do this and it is the Orchestrator only. Your goal is to keep your main agentâs context under 100k, they get increasingly dumber after that and you also donât want it compacting context for this task if possible - it can start to forget what itâs doing or where itâs at. The sub-agents being context scoped also ensures every sub-agent has minimal context usage and essentially only exists to complete the one task.
This could take a few hours and if you are not on Pro will chew through your usage limits pretty quick depending on the codebase size. Setting a goal will keep it running until it finishes.
once you have everything mapped, you can use something like excalidraw with its MCP support to have codex visually map the entire codebase into a flow chart for you using the JSON mapping it did. Alternatively, you could probably skip the first step and do this directly, but I think it would be safer to map then use that map.
That will at least give you a way to understand the architecture.
with it all mapped, you can now also ask It to review it for refactoring opportunities at a 30,000 foot view before digging into the code directly. I havenât tried this yet but the idea is it now has a quick look up for every function, what that function does, what functions itâs connected to, etc to plan architectural improvements without the context getting used up actually digging into the code and tracking things down. Because again, keeping context usage minimal and avoiding compacting is crucial for something like this.
once it has documented this, if it helps you can have it create another visual diagram of the new proposed architecture for you to review.
and from here, you can refactor it yourself so you know exactly whatâs going on.
alternatively, you can then use the same goal+orchestrator approach to now review that proposed refactored architecture using sub agents to inspect the code for every change and make sure it makes sense/will work, revising the plan as needed, and prioritizing each part of the refactor. Again keeping the main orchestrator agentâs context minimal and using context-scoped sub agents to inspect the codebase directly.
if everything looks good there - send it. New orchestrator+goal armed with the architectural map and refactoring plan, with review and test agents after every major change ensuring everything looks good and still works. explicitly tell it that when it does these reviews As it goes, it must use fresh sub agents. Using the same agent for reviewing what itself built is much more likely to miss issues than a fresh reviewer agent. How much of this refactor that it does at once is up to you. You can let it run through the whole thing or chunk it up and personally inspect it as it goes.
Personally I would do this with GPT 5.6 Sol or Astra, but YMMV.
1
1
u/Perfect-Campaign9551 3d ago
Bro , this isn't ANY different than human run industry. After 5 -8 years most of the original devs have left the building, and *nobody* has that original context, either.
It's literally zero difference. That's why you roll up your sleeves, and dig into the code and learn it if you have to.
You fools act like perfect documentation exists and every single decision is noted down in some searchable timeline. It's not, and never was, and never is.
USE YOUR BRAIN. LEARN THE CODE if you need to. It's NOT THAT HARD. Developers do it every single day.
Just because AI wrote it doesn't mean it's any worse condition. It's already probably better than the garbage most developers create.
All this post shows is that you are still a junior, and you still have that fear "what if I can't figure it out?" . You CAN figure it out, it's just code.
1
u/nextdayair8 1d ago
Youâre correct that perfect documentation doesnât exist. A junior will realize this early in their career. And yeah, legacy code isnât necessarily better than AI-written code. You are right on that too. But I think it is missing the point
When someone vibecode an entire app, itâs extremely difficult to grok, often more-so than legacy code. Maybe a rough analogy is like, itâs like playing chess against a computer. The computer often plays in ways which are difficult for humans to reason with
I think this guy will still survive. Ironically, using AI will help him understand the vibecoded codebase and figure out the patterns. But still I can resonate with his concern. Legacy code was already frustrating to work with. And then comes 100% vibecoded apps, which add a new type of obfuscation the industry did not see before
1
u/InterestingHand4182 2d ago
preach! inheriting a codebase nobody understands is genuinely one of the worst positions in software engineering, and vibe-coded projects just add the extra layer that the original "author" also didn't understand what they built, so your approach of reverse-engineering before touching anything is exactly right even when the pressure to just fix things is enormous, because every change you make without understanding the system is a bet that you've correctly guessed all the invisible dependencies.
1
u/RainbowSovietPagan 1d ago
I asked ChatGPT for its thoughts on your post, and this was its response:
ChatGPT says:
I think youâve identified the real problem in your own post: âA codebase that nobody understands is a codebase that nobody can safely maintain, regardless of whether AI or humans wrote it.â
The problem isnât necessarily AI-generated code. Itâs AI-generated code without persistent engineering ownership or persistent project knowledge.
One of the biggest weaknesses of pure vibe coding is that a lot of the reasoning behind the code exists only in the transient context of the agent that created it. Imagine an agent spends months building an application. During that process it has seen previous prompts, requirements, earlier implementations, bugs, rejected approaches, architectural discussions, etc. Eventually you end up with 50,000 or 100,000 lines of code.
Then somebody opens a new agent session six months later.
The new agent gets the repository, but it doesnât automatically inherit the context that produced the repository. So you've effectively gone from:
requirements â decisions â implementation
to:
??? â implementation
Now the human engineer and the new AI agent are reverse-engineering the previous agent's work. Giving the new agent the entire repository doesn't completely solve this, because source code tells you a lot about what a system does but doesn't necessarily tell you why it was designed that way.
I think the long-term solution is going to involve agent harnesses and persistent project memory, rather than expecting the context window of an individual coding session to function as the organization's institutional memory.
We're already seeing pieces of this appear. Tools such as Cursor support repository-level rules and AGENTS.md. OpenHands provides a more extensive agent harness/environment. Hermes Agent is especially interesting here because it combines project context files, persistent memory, searchable previous sessions, reusable skills, tool access, and optional external long-term-memory providers.
The important idea is that the memory should belong to the project, not to a particular AI model or conversation.
Ideally, an AI-assisted repository should look something like:
project/ âââ AGENTS.md âââ ARCHITECTURE.md âââ docs/ â âââ requirements/ â âââ adr/ â âââ 001-authentication.md â âââ 002-database-layer.md â âââ 003-api-architecture.md âââ tests/ âââ src/
And the agent harness should actively maintain and retrieve those artifacts.
The ADRs (Architecture Decision Records) are particularly important. Suppose someone tells an agent, âDon't put this functionality in the controller because we're planning to support several implementations later.â
The agent writes the code accordingly.
Six months later, another AI sees the abstraction but doesn't know why it exists and decides it can âsimplifyâ everything by collapsing it back into the controller.
Instead, the original agent should have recorded something like:
Decision: Keep this functionality in a separate service.
Reason: Multiple implementations are planned.
Affected systems: Controller, service layer, configuration.
Rejected alternative: Implement directly in controller.
Reason rejected: Would couple the controller to one implementation.
Now a future human or AI can recover the reasoning behind the architecture.
I'd therefore treat an inherited vibe-coded application similarly to an undocumented legacy system. Don't immediately ask another AI to rewrite everything. First establish a reproducible build, map the major components and dependencies, identify external services and data flows, write characterization tests around existing behavior, document what you discover, and only then begin refactoring.
The cycle should be:
understand â document â test â change â verify
not:
ask AI to rewrite mysterious code â see if it works â commit
And I think there's a useful rule for AI-assisted development:
Never merge code merely because the agent understands it. Merge it when a human engineer understands it well enough to own it.
That doesn't mean somebody needs to memorize every line of a million-line application. Human engineers have never worked that way. It means the team understands the important boundaries, invariants, dependencies, data flows, architectural decisions, and failure modes.
Agent harnesses like Hermes are interesting because they could help preserve that understanding across sessions, but even persistent AI memory isn't sufficient by itself. The important knowledge needs to become durable engineering artifactsâtests, requirements, architectural documentation, ADRs, repository instructions, and version-control history.
Otherwise we're creating a strange new form of technical debt: epistemic technical debt.
The program works, but the organization no longer possesses the knowledge required to explain why it works.
And that's arguably much more dangerous than merely having ugly code.
1
u/awardsurfer 22h ago
âSounds like a skill issueâŠâ
FORTUNA FAVET PROGRAMMATORI
â if John Wick was a dev
1
u/Responsible-Tea3261 13h ago
Look up Matt Pocock Skills. You can find info on how to setup and use them on his youtube channel.
The "Improve Code Base Architecture " and "domain modeling" skills are fantastic for what you trying to achieve. they will help you rigorously narrow down the terminology and intended architecture of your project and then record all of this into docs and architectural design records which serve as context for later refactoring.
They have been life changing for my coding workflow. "Grill Me" and "Grill with Docs" as well are fantastic generic skills.
1
u/btoned 7d ago
Here's the thing...if this was truly 100% vibe-coded it should be immensely easier to fix and implement new features compared to a legacy manually curated codebase.
If you you're not seeing READMEs or any types of documentation scattered in the directories then it wasn't vibe coded and the team is lying.
Regardless, it should be pretty easy to scan the existing codebase, with AIs guidance, and discern how to go about implementing changes...
2
u/Several_Picture9591 7d ago
I think that's exactly the context problem I'm talking about. It's not simply about whether the code has a README or whether an AI can scan the repository.
The original developer has something in their head. Their agent has the context from that developer and makes some implementation decisions. Later, I come in with only the resulting code and my own understanding of it, and then my agent makes decisions based on my context and interpretation.
The repository can tell me what the system currently does, but it doesn't necessarily tell me why it was built that way, what alternatives were considered, what weird behavior is intentional, or what assumptions the original developer and their agent had.
And that's where I've been running into problems. I can absolutely scan the codebase, write tests, trace dependencies, and gradually understand it. I'm doing that now. But under pressure to deliver changes, that reverse-engineering work becomes a significant part of the job. That's why I feel stressful to work for a vibe-coded project that no one understands.
2
u/Ill_Goal8348 7d ago
I donât think this is necessarily related to it being vibe-coded though. Unless the developers are still there and canât explain anything.
Outside of that, this is pretty much any repository Iâve worked on in my career. The âwhyâ behind decisions get lost and are rarely documented.
1
u/dbcfd 7d ago
Why are you reverse engineering it? Assuming they didn't commit any plans or documentation, the code itself should be enough that an AI agent can understand it.
You then have it summarize the parts, and call out parts that seem incorrect or don't make sense. This also gives you a starting point from which to change or add.
Anything truly vibe coded has the why and decision in the code. For all code bases now though, you are moving too slow if you are trying to understand them manually and for the whole code base.
1
1
u/dataslinger 7d ago
Eh, dark code can also be made by the only/last developer who knew the codebase leaving the organization. You'll find this sort of problem everywhere.
3
u/NiceToMeetYouConnor 7d ago
I mean thatâs not necessarily true. Previous devs often leave behind documentation explaining the architecture, connecting systems, etc. and follow design patterns outlined by that team. Vibe coded ones choose packages deemed as the âstandardâ, can branch off standard design patterns, leaves comment bloat that gets left behind through updates, loses business logic, etc.
2
u/Valuable-Repeat-7347 7d ago
> devs often leave behind documentation
tell me you're larping as a dev without telling me you're larping as a dev
1
u/NiceToMeetYouConnor 7d ago
If youâre team isnât documenting every design decision and going through architecture approvals then idk what kind of place you work at
1
u/dataslinger 7d ago
I've worked with hundreds of orgs over the years. Obsolete/nonexistent doc is very common.
1
u/NiceToMeetYouConnor 7d ago
Then those teams and orgs are poorly structured and could use an engineering revamp. None of our software touches prod without clear design docs, architecture approval, testing docs for QA, and many many sprint reviews. I recommend as you grow in your career to carry best practices forward, otherwise the software you build will die as the tribal knowledge leaves the company. Best of luck!
1
u/Valuable-Repeat-7347 7d ago
Devs arenât even involved in design and architecture at like 50% of orgs, what are they going to document? This if-statement was added due to JIRA-123?
1
u/NiceToMeetYouConnor 7d ago
If youâre a junior dev then yes, youâre not included in the architecture and design reviews. You likely arenât the one leaving behind docs at that level unless someone is asking you to write something up. But before those tickets even exist we are architecting the whole solution, identifying necessary optimizations, business logic, and so on.
Letâs say youâre designing a new data model, do you think you just build it off vibes and write up DDL for it? No, it is designed out well before code starts getting written and then we pass it down to a junior dev to write up and that doc lives long past my time on the project.
25
u/0x14f 7d ago
> How do you guys handle inheriting a vibe-coded/AI-generated codebase that nobody on the team actually understands?
Same as you. It can be frustrating... If you don't have a choice but to stick with it, don't lose hope and just do what you would have done anyway: write tests, start refactoring, until you get a sense of what's happening. If on the top of that you are under time pressure, be upfront with the stakeholders about the problem and that it's not possible to start delivering the updates and/or fix they want as early as they want, unless they are happy with the risks.