Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by bobkb
- Sounds right to me. As AI has picked up, I have found myself drawn to resources that (I hope) help improve my taste and judgment not only of code but also of overall software design. The lessons in Code Complete, for example, have been helpful to me in thinking about managing the complexity of a codebase. It was useful before, too, but perhaps even more so now.by plourens
- Number of iterations solved correctly, on a very large set of iterations, seems like a very good metric. Better than anything else because it measures what we actually care about, not some proxy.
The only caveat is that it's the same model doing an iteration and then using that iteration as a starting point for the next step. So the model is allowed to write absolutely insane solutions, as long as it can read them back, even if no one else can.
One thing that could be done is to use a separately developed baseline coding model B to evaluate the outcome of each iteration. For model under test X to pass an iteration, not only should it be able to solve starting from the previous solution, but so should B, starting from X's previous solution.
by Kinrany - I hopped into this hoping it would land where it did! I recently built in basic observations about cyclomatic complexity, churn, and authorship into an 'analysis' view of codebases in ouijit[1].
Some benefits can be reaped immediately (cyclomatic complexity), but others emerge over time (churn). A good example of this is say something like a 500 line file that has experienced 2500 lines of churn, and if that rate of churn is trending down or up. Surprisingly useful for understanding you've got a hotspot with an opportunity to pay down debt by spending more time on API design, or just breaking out whatever subset of the code is experiencing thrash.
The funny thing about complexity is that assuming you're lintting/formatting well, you can do a poor mans check by just looking at something like average indentation per line, deepest line, etc.
[1]: https://ouijit.com
by pbjerkeseth - 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?by FiberBundle
- first you’d need to define how to define/measure the complexity of code when it comes to this case.by kolinko
- In theory - if an LLM could handle infinite complexity, I still think that the business issues + decisions end up getting in the way somewhere.
AI: "You asked to add feature X. Here are 25 questions that impact feature Z, B, and C in your gigantic codebase"
Developer: I can answer 8 of these questions... Guess I need to go figure out the rest of them.
Writing the code + building the functionality has always been the easy part.
- > I really hope there is, because steering them is, I feel, one of the last competencies through which I can still add value
Something as simple as output length is a hard linear floor for productivity, even putting aside the obvious context problems that you're intuiting, and it's far from being the biggest cost that arises from steering skill. Learning to make a smaller, faster model do the same work with less tokens is a technical domain that a lot of people don't seem capable of learning. I'm not just talking about "context engineering", but learning how to fine tune, post-train, create better harnesses, design inference setups, etc. If we're both using AI, but I'm beating you to market every single time and with a better product, what is your AI usage actually buying you? Yes, competency and skill is this meaningful right now, and it's highly technical. Not the least of which because you know how to describe the problem in way that gives it a smaller solution and requires less iteration.
Most of the labor who understand the technology enough to do those things lives at the companies selling you these services, but you can absolutely learn to do these things yourself right now. It's actually really fun! A hell of a lot more fun than fucking prompting that's for sure.
Where we're at, I would equate it to the early mainframe era where the programmers came with the computer. I'm placing calls that we follow a similar track and the two will end up decoupling, that "model engineers" are going to move in-house. OpenAI will have a ring to it like IBM does today.
by ux266478 - That kind of complexity is combinatorial so "a 4x4 doesn't stop you getting stuck, it just means you get stuck further from help."by gritzko
- Coding has been solved for 20 years at least.
90% of problems are easy once you know what you actually want well enough for you to be able to ask it from an LLM.
90% of code before LLMs was badly copied from StackOverflow anyway.
That 10% that's remaining, I've see 0, ZERO, nil progress. Windows is still awful. Spotify still doesn't work correctly offline. Youtube search is trash. Jira takes 20 seconds sometimes to load a task. LLMs haven't created a new database or a new game engine or a new renderer or anything like that.
The maths breakthroughs are really more of a testament to the efforts of the last 150 years for maths to be an organised verifiable principle. If LLMs had to practice math they way Euler did, they wouldn't be able to find shit.
(sorry if I sound incoherent, just some thoughts while I'm commuting)
by antoni4040 - >LLMs haven't created a
I don't think this is true. They very well might have, but a specific one, not a generic reusable version you find on GitHub or whatever.
by Pannoniae - This is once again RLHF loops.
the AI labs are and have been 100% focused on correctness because it is easy to setup and validate.
Adding one more function that almost does the same thing as another will not break anything.
I think this is just a matter of time. At some point there'll be less value to squeeze out of correctness and then the AI labs will start focusing on maintainability. It's probably a lot harder to set up environment to Train for this behavior though.
by mikkelam - Maintainability is hard because it requires much more planning than correctness. You need to think about how you can construct code which gives you the most amount of reusability while not compromising on readability and also thinking about future paths and how they are affected. It seems like solving the problem of constructing maintainable code is as hard as solving long scale planning in LLMsby vatsachak
- There’s one thing I constantly see agents tripping over, I’m not sure what the right word for it would be, but it basically boils down to “making changes in the right places”. They seem to have very poor grasp of where things are supposed to be and they have a tendency to work against the existing architecture. Even in a world where agents are the only ones touching the code you can see how this ends poorly. Unlike correctness I’m not sure there’s an easy way to verify.
I tried writing a few skills to encourage agents to spend time thinking about this but it doesn’t seem to generalize very well.
by brap - 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.
by CuriouslyC - Coding is solved, perhaps, with unlimited token spend on a frontier model. It remains to be seen if it that is prohibitively expensive forever. At my company, we token maxed while the getting was good. But when we had to switch to Anthropic's enterprise plan, and start paying per token, the shit really hit the fan. Now we're retreating back to sane cost levels and finding that - guess what? - people power might just be more cost effective. AI of course is an immense tool to leverage, but still too expensive to create loops and let it run. This will change over time of course, but assuming it is a solved problem is nonsense. Maybe if we solve cold fusion, yes. Until then, evolution is winning the war on entropy.by toddwprice
- How did the developers react when they had to go back to writing their own code instead of playing Nintendo Switch between prompting sessions?by greenowl
- I'm interested in hearing more about your experience here.
Were you all just full bore shipping a ton with the per token plans? Was it more effective? How many developers @ your company?
It's really interesting to hear that some companies are back-pedaling. We "slowed" down a bit but are still very much using AI and intend to continue using it for... almost everything.
- > Coding is solved, perhaps, with unlimited token spend on a frontier model.
Coding is also a solved problem with unlimited salary budget on the very best developers.
by suprjami - Having reached the same conclusions as the author led me to create my first agent to do architecture review, and that's how I learned about the metrics behind good practices that I'd been following for years. LCOM, cyclomatic complexity, that kind of stuff...
It's so easy to ship a lot of code, more effort should be put into ensuring the code is correct, with self-improving feedback loops that involve developers, and dedicated tooling...
But again, a while ago, everything was about prompt engineering, and now you can express you idea vaguely and get a somewhat working result, so this likely will evolve fast as well...
by justinmarsan - curious how did you set up your Architecture subagen?by datlife
- 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.
by conqrr - Mental models existed before coding. The pyramids were not built by just a couple of guys hauling some rocks together. It was a highly structured organization.
Or the East India Company or many other great organizations that achieved big things before computers.
by rolisz - Who says anyone needs to hold a mental model?
Imho a better way of thinking about it is in terms of views - you can have an unimaginably complex codebase that nobody reads in full, but either agents or humans receive views/perspectives on that codebase.
Before LLMs we couldn’t have built tools that would deliver such views, now we can.
by kolinko - Maybe I’m not even waiting for a model which is 100% at code, but one which is almost 100% at interactively exposing its (almost? correct) mental model.
If I put it like that, it seems to me we are much far away.
by pezo1919 - We'll invent other tools to help with the mental models, ones that are more intuitive.
Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected.
We're already in a sort of IDE when you think about it, we're operating a much larger mental model than any code-base, and we rarely remember that we're operating with such a model.
by w_for_wumbo - Really glad to see folks looking into quantitative approaches to give agents feedback on code quality. This post looks like a good start!
My main feedback for the authors would be, the most important problems for sloppiness are global properties, not local ones. In my experience an agent, like a human, has finite capacity for its attention, but if it runs into local sloppiness that gets in its way, it can fix it on a by-need basis. The technical debt issues that matter are usually global issues that aren't so easy to fix: they require global analysis and global refactoring.
I don't know the answer, but I think we're going to need ways to measure architectural properties, like separation of concerns, clear architectural layering, well-defined interfaces, etc.
by dherman - Do you have specific examples of what you mean here?by siscia
- All: please don't post generic reflexive reactions to titles. That's covered by this guideline, among others, in https://news.ycombinator.com/newsguidelines.html:
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
I've taken the provocative bit out of the title above, but please remember that we want reflective comments, not reflexive ones, in HN threads.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
by dang