Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring the sloppiness of code

earendil.com

Post reply on HN
Print view View original

61–70 of 246 posts

Re: Measuring the sloppiness of code

#61

Post by binary0010 »

danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

I just setup a large refactor with Astra and was feeling super lazy and let it mostly do it without my usual extreme micro managing.

The refactor ended up adding 22,000 loc.

I went in there and quickly read through it, laughed my ass off. Reverted the work tree. Micromanaged a new refactor. Net lines of code for something really elegant and easy to reason about was -3k loc in the project.

In case you are wondering why vibe coders are doing 30k loc a day, this is why.

Re: Measuring the sloppiness of code

#62

Post by JodieBenitez »

softwaredoug wrote: post #22
scronkfinkle wrote: post #12

There is some sense of rose-tinted glasses of pre-LLM coding. A lot of human written code, particularly at the enterprise level, was of low quality well before AI automated it.

I don't doubt that. But humans still need to be responsible for understanding what they're shipping. And IMO you get your best understanding by actually writing some code. Even if you don't actually ship what you wrote.

Yeah... like we all get to start green field projects and write all the code we should understand. Many of us cut our teeth on bad legacy stuff with no proper documentation made by "engineers" long gone. At least a LLM can easily make sense of this mess.

Re: Measuring the sloppiness of code

#63

Post by avgDev »

cheney_2004 wrote: post #37

Ya, now that I have some solid AI coding experience under my belt, there does seem to be some gaps between practice and reality. I have a fairly complex codebase which I pretty much hand code everything. When I add a new feature, I spend a lot of time designing and refactoring that feature into the codebase. Either the feature dovetails into the existing design or the feature creates new designs which will then facil…

I encountered bugs created by AI. No matter how many times it tried it could not fix the bug, it was introducing so much slop to work around the issue.

I finally gave up and read documentation for 15 minutes and solved the problem.

I will never push AI generated code to production without understanding it, and this is why I only generate small code snippets and copy/paste most of the time.

Re: Measuring the sloppiness of code

#64

Post by softwaredoug »

FloorEgg wrote: post #38
softwaredoug wrote: post #22

Earlier quoted context omitted.

I don't doubt that. But humans still need to be responsible for understanding what they're shipping. And IMO you get your best understanding by actually writing some code. Even if you don't actually ship what you wrote.

> But humans still need to be responsible for understanding what they're shipping I don't necessarily disagree. That said... Why? I've been grappling with this myself. There is an easy/obvious answer, but I wonder how stable/permanent it is. If you feel strongly about this, are you willing to unpack your judgement?

Certainly the population of people that need to know how something works is much smaller.

But even still, cognitive debt is a real, documented phenomenon where we lose our ability to change projects.[1]

We also know coding agents tend to accumulate slop in projects over time without some human intervention[2]

There's also the concern of whether its a good idea to be dependent on an addictive slot machine run by a trillion dollar company to do your work.

1 - https://simonwillison.net/2026/Feb/15/cognitive-debt/

2 - https://www.scbench.ai/

Re: Measuring the sloppiness of code

#65

Post by ahalay-mahalay »

zsoltkacsandi wrote: post #26
danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

That is very well put and summarizes what distinguishes real software development from vibe coding.

I’m pretty sure that same discourse was seen every mass production epoch, from textiles to electronics. Yet here we are, hand-crafted high quality things are rare and expensive.

Re: Measuring the sloppiness of code

#66

Post by Supermancho »

danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

> Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability

My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify:

* Efficiency. Marginal by default. Coding efficiency problems often appear because LLMs dont usually consider the entire codebase or future plans (although they do guess at some futures). Sometimes they write/name things in ways that are lazy/wasted cycles. Most of the time, they don't.

* Security. Marginal by default. I say they do pretty good. Considering all the failure modes, not so much.

* Maintainability. Marginal by default. Mostly due to the careful consideration of modularity, upgrade paths, etc. while often taking wildly different approaches to solutions without having specific broad instructions. Even then, there can be big gaps in quality.

* Observability. Not acceptable by default. There's usually some consideration and can often one-shot.

* Portability. Not acceptable by default. Good, if you specify what those targets are. Regardless, testing validates this above the coding and models are very good at hitting functional test targets. This is less of an issue in something like Java ofc.

Re: Measuring the sloppiness of code

#67

Post by bobkb »

Coding just a stage in the software development. Design and specifications which can help in coding is not solved at all and may never - the end result is software reliability is not a solved problem.

Re: Measuring the sloppiness of code

#68

Post by danielvaughn »

danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

Yes. I use these models day in and day out, on all sorts of tasks. I cannot believe I hear people say that coding is solved.

Re: Measuring the sloppiness of code

#69

Post by echelon »

testaccount121 wrote: post #58
echelon wrote: post #29

Earlier quoted context omitted.

And all of these things will be solved one by one. It's astounding to me that people can see coding get solved and not think every single one of these tasks won't be solved too. Why do you not think these things aren't going to be completely automated? What makes these tasks special? Fable and Astra can one-shot video games with compelling novel game loops. They can do systems programming, distributed systems, roboti…

..

People are ego-centric and pull a blindfold over their eyes.

Re: Measuring the sloppiness of code

#70

Post by Dlemlo »

mbernstein wrote: post #60
echelon wrote: post #29

Earlier quoted context omitted.

And all of these things will be solved one by one. It's astounding to me that people can see coding get solved and not think every single one of these tasks won't be solved too. Why do you not think these things aren't going to be completely automated? What makes these tasks special? Fable and Astra can one-shot video games with compelling novel game loops. They can do systems programming, distributed systems, roboti…

I think you need to define what solved means and what better means. Have you tried one-shotting real distributed systems problems? What was the result and how did you verify correctness?

Like the 0.1% we do is your counter example?

But lets be fair, if an expert would use AI today to build something with this, I would feel a lot more confident than not doing this.

I would start with the base architecture and add all the guardrails for a distributed system, i might even go so far to leverage the math skills of a frontier model like fable or astra. I would for sure have the proper budget for using Fable/Astra.

Post reply on HN