[leduyquang753]

> Many software developers have argued that working like a pack of hyenas and shipping hundreds of commits a day without reading your code is an unsustainable way to build valuable software, but this leak suggests that maybe this isn’t true — bad code can build well-regarded products.

The product hasn't been around long enough to decide whether such an approach is "sustainable". It is currently in a hype state and needs more time for that hype to die down and the true value to show up, as well as to see whether it becomes the 9th circle of hell to keep in working order.

[jona777than]

I have flip-flopped more than ever in the last 365 days about prioritizing good code vs good product, in the AI age. This helps clarifies why.

I have come to the conclusion that we just do not know yet. There is a part of me that believes there is a point somewhere on the grand scale where the code quality genuinely does not matter if the outcome is reliably and deterministically achieved. (As an image, I like to think of Wall—E literally compressing garbage into a cube shape.)

This would ignore maintenance costs (time and effort inclusive.) Those matter to an established user base (people do not love change in my experience, even if it solves the problem better.)

On the other hand, maybe software is meant to be highly personal and not widely general. For instance, I have had more fun in the past two years than the entire 15 years of coding before it, simply building small custom-fitted tools for exactly what I need. I aimed to please an audience of one. I have also done this for others. Code quality has not mattered all that much, if at all. It will be interesting to see where things go.

[otabdeveloper4]

> if the outcome is reliably and deterministically achieved

It's not. My favorite example: due to vibe coding overload literally nobody knows what configuration options OpenClaw now supports. (Not even other LLM's.)

Their "solution" is to build a chat bot LLM that will attempt to configure OpenClaw for you, and hope for the best, fingers crossed. Yes, really.

[operatingthetan]

The openclaw situation is ridiculous. Configuring it is a nightmare, even with 3 different LLMs trying to help. Then I check their docs and it says three different things. Agents will take questions and turn them into a new config file, which consists of made up settings, causing the gateway to crash.

My setup is very simple too, just two agents, some MD files, and discord. Nothing else. These people using it for real work or managing their email and texts are in for a rough ride.

[watwut]

Imo, code quality genuinely matter for the outcome and customer happiness. Including in startups.

But, there is also quite a lot of confident "code quality" fluff claims that have nothing to do with maintainability, robustness or performance. Fairly often, a guy claiming "the code is garbage" is not actually concerned with code quality as much as he is concerned with asserting dominance. Or is confusing own preference with quality.

[lukewarm707]

it is better for security when code is simple.

i tried using litellm and it was 700mb! it does have a lot of features. postgres db, prometheus, api layer. really complicated. but simple help is missing. it assumes you will put passwords in an env file. how do you add chat completions in the ui? how do you add a custom provider?

but, what i wanted, a simple proxy, can be written in 30 lines of python in fastapi. memory fetch/push in 50 lines. different providers can be added with two lines, one import and one client create.

[mergesort]

Hey there, author of the post here. I actually agree with this! That is in fact why I used the word maybe — my comment really was meant to be more speculative than definitive.

[59nadir]

I think one thing that goes unmentioned is that maybe code quality is really not that important for trivial things, because they can be trivially reproduced if need be. I would argue Claude Code is exactly such a project; coding agents are incredibly simple and rewriting CC wouldn't be much of a problem.

Non-trivial things tend to be much more sensitive to code quality in my experience, and will by necessity be kept around for longer and thus be much more sensitive to maintenance issues.

[ulrikrasmussen]

I think code quality is always important, but it's less important for terminal code which implements a specific set of features using robust APIs underneath. Low code quality becomes a much bigger issue when the code is supposed to deliver well-defined abstractions on which other code can rely.

If you are a serious software developer, then you will probably be able to explain both what your code does (i.e. what spec it implements) and how it does it (what does it call, what algorithms does it use, what properties does it rely on?). With the advent of LLMs, people have started to accept not having a clue about the "how", and I fear that we are also starting to sacrifice the "what". Unless our LLMs get context windows that are large enough to hold the source of the full software stack, including LLM-generated dependencies, then I think that sacrificing the "what" is going to lead to disaster. APIs will be designed and modified with only the use cases that fit in the modifying agents context window in mind with little regard for downstream consequences and stability of behavior, because there is not even a definition of what the behavior is supposed to be.

[rakel_rakel]

> maybe code quality is really not that important for trivial things

I hear this narrative being pushed quite a bit, and it makes my spidey senses tingle every time. Secure programs are a subset of correct programs, and to write and maintain correct programs you need to have a quality mindset.

A 0-day doesn't care if it's in a part of your computer you consider trivial or not.

[59nadir]

Intrinsically simple and straight forward problems are easier to secure even with mediocre or bad code. They've already shown that Opus 4.6 can find and report on very sophisticated security issues[0] so I'm not sure that analysis (and perhaps especially security analysis) is the biggest issue with LLMs.

Mind you, I'm not using LLMs for professional programming since I prefer knowing everything inside and out in the code that I work on, but I have tried a bunch of different modes of use (spec-driven + entire implementation by Opus 4.6, latest Codex and Composer 2, and entirely "vibecoded", as well as minor changes) and can say that for trivial in-house things it's actually usable.

Do I prefer to rewrite it entirely manually if I want something that I actually like? Yes. Do I think that not everything needs to be treated that way if you just want an initial version you can tinker with? Also yes.

0: https://youtu.be/1sd26pWhfmg

[rakel_rakel]

> I'm not sure that analysis (and perhaps especially security analysis) is the biggest issue with LLMs.

I was replying to the statement that "maybe code quality is really not that important for trivial things", not whether LLM's are good at analysis nor not.

Thanks for the link though, looks like an interesting talk!

[otabdeveloper4]

> can find and report on some very sophisticated security issues sometimes

Fixed it for you.