First, some context. ~7 months ago i was the first Engineering hire at a ( now ) 2 years old startup. The codebase started as a Lovable MVP built by our low level CTO, one month ago we hired a second dev and we are further expanding our engineering team and preparing the terrain for me to move to Staff. Now as you probably expected, the codebase is a mess since we simply built on top of the first MVP, of course with zero documentation, the main problems i identified in our codebase: - Duplicated business logic → no single source of truth / poor separation of concerns. - Zombie tables and columns → accumulated schema/structural debt, most of them look right, they are not - We manually track downstream effects since everything is scattered and duplicated in the most confusing way → implicit dependencies, implicit architecture and high change coupling. Changing a thing here also needs changing there and there ( this is mainly fixable by a codebase graph indexer )
Now quickly, so you dont get bored, ive identified as the sweet spot solution between speed and reliability to properly document the whole codebase and store that efficiently as a 'knowledge database' for our AI agents, so they are at least aware of the known gaps, constraints, decisions, business logic, where else to change something and the causes and effects of changes.
The closest and most interesting article that treats this exact issue is this one from Meta, which i want to start my approach from.
Now what im asking here is for some similar experiences, other startup engineers that had to go through a similar approach, what was their approach, experience, outcome and any tips on what should i avoid or be aware of.
Any help will be much appreciated
iacobandrei•4h ago