Im currently in a really awkward situation, i started as a Founding Engineer at a startup after their first year, the founders built the codebase through lovable and kept working on it with freelancers for the first year, then i was the first official tech hire.
Since i started we ve been growing a lot, the problem is that the codebase at the core is still that lovable MVP, concretely it has:
Duplicated business logic → no single source of truth / a poor separation of concerns.
Zombie tables and columns → accumulated schema/structural debt and unclear ownership.
Manually tracking downstream effects → implicit dependencies and high change coupling.
And im pretty sure im not the only dev in this position, so i want to share how i handled this position and what are the results currently.
I found a meta article, describing the exact same issue and how they fixed it, the premise is 'make the architecture explicit instead of implicit' [https://engineering.fb.com/2026/04/06/developer-tools/how-meta-used-ai-to-map-tribal-knowledge-in-large-scale-data-pipelines/?utm_source=chatgpt.com]
It is basically a structured agentic workflow that studies the codebase and generates some files called 'compasses', which are short md files pointing the agents and stating clearly the 'tribal knowledge'.
Fast forward, its been some weeks without bugs generated by new features, ( of course we had untreated edge-cases and other kinds of bugs ), the next step ( that i already started ) is following the strangler fig pattern to slowly migrate from the current hono backend to a new nestjs one, but this workflow allowed us to keep developing properly.
I wrote an article and a public repo here https://dev.to/iacobandrei/how-i-documented-a-broken-codebase-without-losing-my-mind-74m
Hope this helps someone

DEV CommunityHow i documented a Broken codebase without losing my mind.If you want to use it straight away | Link here I believe we achieved a point in tech where having a...
commit bdd1d38