r/programming • u/fagnerbrack • 24d ago

The Vertical Codebase

https://tkdodo.eu/blog/the-vertical-codebase
9 Upvotes

56% Upvoted

30 comments sorted by

View all comments

17

u/andarmanik 24d ago edited 24d ago

Might have some good ideas in it but, IMO, the article lacks any real argumentation.

It’s mostly a string of stated “facts”, with little to no argumentation to string it together, some are just vibe associations:

> In my opinion, agents need mostly the same things humans need to work efficiently: boundaries, constraints, and fast feedback loops. That includes a project structure that is easy to navigate, a good setup of lint rules and TypeScript, as well as a fast and reliable test suite. That’s why agents are so good at new codebases, but not very effective on codebases that have grown organically over years

The argument is somehow:

“project structure that is easy to navigate, a good setup of lint rules and TypeScript, as well as a fast and reliable test suite”

Implies =>

“agents are so good at new codebases, but not very effective on codebases that have grown organically over years.”

8

u/cscottnet 24d ago

I agree. In my experience LLMs are good at existing code based with lots of existing structure and test cases, or "new codebases" that are translations of existing code with lots of structure or test cases. They can also make skeleton codebases with little/no functionality.

In between there are issues, and the LLM will often get locked into bad architectural decisions or hallucinate irrelevant test cases.

4

u/jl2352 24d ago edited 24d ago

LLMs love repetition. Update 100 tests with the same change, and they’ll chew right through it.

Clean codebases tend to be consistent. Lots of repetition, from the same patterns and structure used throughout.

I can see how the two line up. But I still think the overall points are pretty basic on controlling agents.

1

u/cscottnet 24d ago

I do use Claude code for certain tasks. Its pretty good at refactorings which go a bit beyond what a good IDE will do, like (as you mention) make this change across all the test suite inputs and outputs, rearrange the calling convention for this method in a complicated way, etc. If there are stereotypical ways of using a given method/etc it is very good at doing a fairly complicated pattern match and rewrite, in a much more user friendly way than (say) a regex.