Live data from Hacker News

Measuring the sloppiness of code

earendil.com

111–120 of 247 posts

Re: Measuring the sloppiness of code

#111

Coding is solved, but AI companies are still hiring software engineers?

Are they really though? And if so, how much of that is due to the hyper growth in this specific space?

Meanwhile, the SWE job market across all companies seems pretty rough right now. Talk to someone looking for a job. Most companies seem to be in a holding pattern - little to no new SWE positions available.

Re: Measuring the sloppiness of code

#112
post #48
post #16

It will be solved when there is no more code left to write. Code is an abstract concept that is not bound to the physical world and I imagine that future will have some much more of it that it is difficult to comprehend. Everything will be code and more code will be written than ever before. Code will never going to be solved. The question is how much humans will be involved and I think the evidence is that perhaps j…

Code and software and applications are an intermediate stage. The final stage is an AI/LLM that just does the thing that is needed without any code being written, there are no applications or programs, just an AI that does everything.

Claude do the needful.

Re: Measuring the sloppiness of code

#113
post #29
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…

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…

[dead]

Re: Measuring the sloppiness of code

#114
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 think this is a two things can be true situation, where our colloquial meaning of coding is not quite adequate to indicate the full range of criteria that really matter, but also, that criteria as a totality (maintainability, reliability etc) is something that can also be targeted and optimized for.

This reminds me a bit of a PhD Comics webcomic that confidently claimed we would "never" cure cancer, on the grounds that cancer is not one thing. And I don't know that we will ever actually cure cancer, but that wouldn't be the reason. Correctly noting the problem space is bigger than a layperson would initially appreciate is a lot of things, most of them helpful, but the one thing it's not is a formal a demonstration of optimizing against the problem space as a whole.

Re: Measuring the sloppiness of code

#115

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.

Not "a lot of". "The majority of". I've been doing development, in one way or another, since the 90s. I've worked with dozens of teams from enterprises to startups. Hundreds of developers. The quality of work has been all over the place, but the majority was not great. I'm arguing that what people today call "AI slop" is already higher quality than what most developers created historically, and the fact that tests an…

This is off-topic, but I strongly dislike AI written documentation.

When I see AI house style my eyes glaze over. Just this morning I reviewed an RFC from a colleague that he said was a spec for a web service. The document had no introduction, no context, it described endpoints for 2 distinctly different services instead of 1, and made no effort to reconcile why there are 2. It was scattershot with details, some of them important, some completely irrelevant. It was replete with typical LLM-ism.

Basically, it was a dump of a conversation he had with an LLM. As a document to build shared knowledge, it was nearly useless. The only feedback I could provide was a polite "I do not understand what you are trying to build".

But, supposedly, another engineer is already working on implementing this spec. I assume the other engineer just cycled this "spec" into his LLM, and off the two of them went. \o/

They are trying to pull me into their project right now, I stood up some containerization infra for them. But, oh boy, do I not want to join. I looked over their codebase, by LOC the codebase is 35% comments, and a lot of the comments are contradictory, there are dependencies that are not used, there is no tooling of any kind (no type checking, no linting, no PR process), there is no auth (this code is already running in production lol -- they have public endpoints exposed that can be used to scrape/mutate internal company data). Another 30-40% of the codebase is unit tests that test trivial stuff like whether their framework's serializers and ORM work, ex: x=DB.create_x(arg=1), assert(x.arg == 1).

At the intuitive level, I do not understand people who say coding is solved... To me it seems like LLMs are a multiplier (LLMs are amazing, sci-fi level shit), but if you multiply a negative number or 0, you get something that is <=0. Making agentic coding work requires a lot of discipline & expertise.

Re: Measuring the sloppiness of code

#116
post #105

Earlier quoted context omitted.

They care in principle, for the most part bad code makes changes and extensions slow to implement and causes unnecessary production issues which costs time and money. But there is always the tension between implementing something quickly now and being able to implement things quickly in the future and unfortunately the preference is almost always quickly now despite everyone knowing that this is the way more expensiv…

Not even in principle. Like how often you had to fight a product manager to do this or that. "Does that code work?" "yes" "so lets ship it" "but its not good" "but it works right?"

But they also ask why the next feature is taking so long, because of the mess we created with the last feature, and I would consider this caring in principle. Unfortunately this almost always filed as unavoidable.

Re: Measuring the sloppiness of code

#117
> Qwen2.5-Coder-3B

Basing it's findings of LLM as judge on this model, and then proceeding to ignore it. This article can be safely ignored as well.

LLM as judge in harness evals is the way to go, for any of your custom needs. Design the eval well.

Re: Measuring the sloppiness of code

#118
post #75
post #53

Earlier quoted context omitted.

Many people were and still are simply terrible developers. Hand those people an LLM and they don’t suddenly become competent, but they do start slinging more code.

Nah, you're still blaming workers and not leadership. If leadership is okay with not training workers (something American corporations would do in the distant past) then it's not fair to continue to blame workers when leadership is clearly aware of the problem and would rather pocket the money than help workers. These companies pay management more than workers for a reason, if you can't even admit that they are to bl…

I've only worked at companies with great leadership. This is in the Nordics with very strong worker protection. And yet most of my colleagues including myself have been pretty terrible and write dirty code. It's not a management issue and it's not anti-worker to acknowledge this fact.

Re: Measuring the sloppiness of code

#119
post #46

Earlier quoted context omitted.

I have seen so much production code with garbage code and massive bugs, the industry doesn't care for 'real'.

They care in principle, for the most part bad code makes changes and extensions slow to implement and causes unnecessary production issues which costs time and money. But there is always the tension between implementing something quickly now and being able to implement things quickly in the future and unfortunately the preference is almost always quickly now despite everyone knowing that this is the way more expensiv…

It isn't necessarily the more expensive choice in the long run. Let's say that companies A and B are direct competitors who start from the same point. Company A quickly codes a bunch of buggy software and ships it in a month. Company B takes its time and ships good, clean, well-organized, mostly bug-free code in five months. Company A makes money. Company B goes out of business and its code is useless, its nice qualities irrelevant.

This is just a hypothetical example, I'm not saying that this is how it would necessarily go in all cases.

Re: Measuring the sloppiness of code

#120

Coding is solved, but AI companies are still hiring software engineers?

Are they really though? And if so, how much of that is due to the hyper growth in this specific space? Meanwhile, the SWE job market across all companies seems pretty rough right now. Talk to someone looking for a job. Most companies seem to be in a holding pattern - little to no new SWE positions available.

That's almost every industry, because most companies realize we are an extremely unstable point in time.
Post reply on HN