jacobian1d ago

Look this isn’t at all a defense of slop code, but it has me thinking — how much does code quality matter, and why?

It’s maintenance, right? We care about readability because we know we’ll have to make changes, fix bugs, etc.

But so … imagine a codebase that’s magically bug-free and feature-complete. (I’m aware this is a strawman - that’s the point, it’s a thought experiment.) Does it matter if this codebase is well-written? I’m not sure it does! (1/5)

Show threadjacobian1d ago
Code quality has always been ONE factor; it’s never been always the most important. Eg we often accept complex internals as the price for a clean external API; and we all write sloppy code for one-offs, prototypes, etc. So part of me accepts the “code quality doesn’t matter” argument. I can see a vision of agentic engineering with systems that prove correctness; if an agent produces code that is provably correct, maybe the quality really doesn’t matter! (2/5)
Show threadjacobian1d ago
I’m far from convinced that this is actually possible. It’s certainly not now — and I’m not talking about models. Testing and verification tools are nowhere near where they’d need to be, regardless of model quality. Today, code quality DOES still matter; even the best-case version of agentic engineering can’t produce code that’ll never require maintenance. But I can see a possible future where code quality might not matter, or will matter a lot less, and that’s FASCINATING. (3/5)
Show threadjacobian1d ago
Specifically what I find fascinating is: the tooling that would be required to make agentic engineering begin to live up to the hype — much better testing tools, formal business logic specification languages, more powerful and easier to use formal verification tools, better static analysis tooling, etc — would be massively useful to software engineering quite regardless of the existence/utility/quality of LLMs. (4/5)
Show threadjacobian1d ago
Will we actually build them? I sort of doubt it: the history of software development, and of course the current trajectory, suggests we’ll continue to yolo our way through it. I wouldn’t exactly say I’m optimistic, but hope springs eternal. (5/5)
Show threadRaphael14h ago

@jacob But aren't we then just shifting all the complexity, skill requirement and quality concerns to the business logic specification language, which will maybe be less verbose than code, but certainly not easier to reason about and write perfect specifications in?

The maintenance burden of software isn't just high because there's a bug in that manually-written for loop, it's mostly because requirements weren't clear enough or change.

Show threadjacobian12h ago
@rami I mean probably - but also you could say a similar thing about shifting the maintenance burden from assembly to compiled languages, from compiled to interpreted, etc. Higher level abstracts are A Thing, I don’t think it’s a huge stretch to imagine an even higher level where we’re specifying whole swaths of applications in a few lines. I guess if you want to be charitable you could say “that’s a prompt!” but the fuzziness and nondeterminism of LLMs make it real hard for me to be charitable.
Show threadRaphael
@jacob Oh yes, absolutely. Could happen! Going from "instructions" to "specifications that can be proven to be implemented" will be a useful abstraction, but writing specifications that are not only sufficiently detailed to prove the code but also prove the *right* thing feels like it's going to be harder than coding and prompting combined, because it combines the hard skills of both. (Still, the end result could be better, not denying that!)
6:02pmWeb