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

81–90 of 246 posts

Re: Measuring the sloppiness of code

#81

Post by dnikolovv »

danielvaughn wrote: post #68
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.

Right. It feels like we're living in a parallel world or something. Can agents code? Sure. Can you let them code on their own for a serious production project? Not a chance.

Re: Measuring the sloppiness of code

#82

Post by whatever1 »

mr_roboto wrote: post #74
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…

You come across as someone who has never worked on a real software project. Humans create tons of bugs on a regular basis. AI is already better than most programmers.

Better at writing one piece of code, maybe.

Better at writing code within a huge system, definitely not. Maybe in the future, but as of Astra, Fable 5.1, the answer is still no.

Re: Measuring the sloppiness of code

#83

Post by conqrr »

Coding is not just the program running in memory, its also the process of distributing the mental model of understanding among the team.

If humans increasingly are kept out of coding, then who holds the mental model?

If AI holds the mental model, by definition human prompts will be over lossy channel. This is true without AI too. Software quality is directly dependent on good devs that translate from business/PM speak to technical decisions.

So is coding solved now? it was already solved decades ago.

Re: Measuring the sloppiness of code

#84

Post by FiberBundle »

Does anybody actually know whether there's a limit to the complexity LLMs are capable of dealing with in a codebase? It's very obvious that they don't write code that is suitable for people to understand it (and it's gonna get worse and worse the more RL is used to train these models), but if there isn't a point at which LLMs also struggle due to the complexity they introduce, then I'm not sure it really matters anymore for a large part of non safety-critical software. I really hope there is, because steering them is, I feel, one of the last competencies through which I can still add value, but is there actually evidence that these models struggle more with poorly maintained code?

Re: Measuring the sloppiness of code

#85

Post by CuriouslyC »

I started Valknut (https://github.com/sibyllinesoft/valknut) when I saw the writing on the wall regarding Agent code structure/abstractions/etc being a limiting factor in the ability to autonomously build projects. My experience was that good linters helped, but it wasn't enough, you needed to be able to enforce information-theoretic related organizing principles in addition to file/function LOC and local complexity metrics to guide agents on how to structure code.

Originally I tried to walk the line between improved agent performance and human readability, but current models are so good I don't think human readability matters much, though at a high level, being able to grok the overall folder structure still matters. I've got my hands full polishing a demo for my game, but I intend to revisit Valknut by crafting an eval set that lets me calculate the difference in agent token consumption and task failure rate between ~isomorphic codebase structures. This will let me loop agents to discover organizing policies that improve them.

Truthfully though, with today's models I don't think this sort of codebase optimization is likely to have much impact below 250k-300k LoC projects, and it probably won't be a decisive win till you're near 1M. Also, the shelf life of a product like this isn't infinite as each generation of models pushes those numbers up while also having new policy preferences that require re-evaluating existing policies.

Re: Measuring the sloppiness of code

#87

Post by devin »

bunderbunder wrote: post #79
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'm not so sure that's a fair comparison. So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so…

This is happening all over the place right now. There is a ton of greenfield happening, which further adds to the illusion of speed. Eventually you produce a big old pile of shit that even with the help of the LLM is weird to reason about, and it slows way down. Many such cases.

Re: Measuring the sloppiness of code

#88

Post by mococa »

hankbond wrote: post #17
marginalia_nu wrote: post #10

Earlier quoted context omitted.

Congrats on your promotion to full time jira management!

very glib comment. thinking about how to accurately describe the problem at hand and figuring out the simplest way to approach it takes a lot of effort well before you get to the implementation step of coding.

Exactaly. Some tasks took me hours or days to change a line.

Re: Measuring the sloppiness of code

#89

Post by nucleative »

softwaredoug wrote: post #8

Coding might be "solved" but coding still is the best way to build your own mental model of the solution space. Which is more important to you: Velocity to a solution? Or velocity to understanding?

Interesting way to lay it out. For us understanding is obviously crucial for prod and repeatable business functions.

Velocity to solution is default for almost everyone else, especially one-off or low impact / low consequence of failure projects.

Re: Measuring the sloppiness of code

#90

Post by RickJWagner »

If coding is ever solved, and if software does it, sloppiness probably won’t matter much.

Code will become throwaway stuff, like the results of AI prompts. Cook it up, test it for adequacy, and run it. When something comes along that adds new requirements, just update the requirements/prompt and make a new one.

Test suites will be important.

Post reply on HN