Comment by brabel
19 hours ago
> Making software debuggable, maintainable, layered, and composable – that’s still quite a trick. Quite a lot of that work requires extensive, thoughtful reasoning. And that’s where the LLM’s today, even the leading edge of the “capability” from frontier models, fall short.
It’s been my quest during my career to figure out what is maintainable software, what is composable or not, and how the two things, and many other things, are in direct conflict. There is no single answer. If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base. Composability may matter for integrators but can be entirely ignored in your CRUD backend. Beyond that, I don’t know of a good way to measure most of these intangible properties. Highly competent software developers disagree in even basic things, like whether OOP is a good idea, should we all be using pure functional programming etc. Hence, how would you expect an LLM to get good at figuring this out for you? If you describe exactly what trade offs you are willing to make, and give it ways to measure how well it’s doing, then I do think LLMs will be able to not fall short. Given the current state of things, it’s just a matter of opinion whether LLMs fall short, or humans fall short for that matter.
> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.
It's low priority in the sense that people in charge tend not to value it.
That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.
Software that needs to be babysat is an ongoing opportunity cost.
> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.
Is it? How long do you expect to keep your momentum after "taking over the market"?
Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.
Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.
So one of my thoughts is maybe AI makes this more viable. You continually refactor the code base. Often when you start something you do not know the correct abstractions anyway - so vibe-code it.
Then once you have the kinda-sorta prototype, do a full rewrite, try to do component modules with interfaces.
(maybe do multiple rewrites depending on architecture complexity)
Then incrementally improve the software quality of each of the components.
---
My thesis in this is that the cost of a refactor has dropped precipitously, LLMs are really good at doing translations, and are pretty good at finding good abstractions if you work them a bit. It is also much faster, becuase in your refactor you try and focus on the big picture and interfaces, and yolo the components... Make sure that they work, but if there is a particular edge case you can fix it later.
I don't know for sure, but I am testing this out and am halfway through a rewrite of a large project into rust from c++ (second step from above) - I am mostly vibe-ing the components, But am paying a lot of attention to the interfaces and layout.
>How long do you expect to keep your momentum after "taking over the market"?
A few years making millions is more than enough for leadership to be satisfied. Even if everyone underneath simply has broken dreams and an increasingly unstable work style. I guess in that lens the company "succeeded" compared to those who did things right and never took off.
Thoughtfully and coherently factorized, abiding a set of architectural rules (i.e: we compose "this" way here, re-evaluated as we go) and following up-to-date framework conventions. LLMs are terrible at this.
Chosing OOP or FP is irrelevant, fundamentals matter more