Hacker News

points by Daunk 4 days ago | 0 comments

I believe that anyone who says that writing code is no longer needed, was probably not a very good coder to begin with. I have seen what the best models can do, and I've seen what people call "good", and I am not impressed.

However, I'm still split. Because this could mean that we see a jump in code quality, due to bad coders getting someone better to code for them. But we could see a decrease in code quality, due to less people "caring".

[–] Seattle3503 4 days ago

Most people I've seen saying coding is solved are ML engineers who write throw away code for running one-off experiments. If you can effectively "archive" code after getting the results you need, I can see why you would say coding is solved. Sustainment is a non issue.

[–] slopinthebag 4 days ago

yes and web people who are just gluing together api's or writing what essentially amounts to UI templates that can never really be "wrong"

[–] LeafItAlone 4 days ago

> I believe that anyone who says that writing code is no longer needed, was probably not a very good coder to begin with. I have seen what the best models can do, and I've seen what people call "good", and I am not impressed.

I envy you.

I believe that anyone who holds this position has been extremely lucky/fortunate to work with only top-tier developers. And does not read or work with open source projects.

Last year’s models are producing code better than _at least_ 50% of the developers I’ve worked with. Today’s frontier models are better than probably 75%. If the code that humans have been generating has been “good” (on average) or at least good enough, then the models that exist today are producing “good” code.

[–] hbrn 3 days ago

The problem is that in order to win you need to be in the top 1-10%, since you are competing against the same engineers. Being slightly above the average is only "good enough" to not get fired.

And the bar is already raised because every single one of those engineers now has access to the same models. So you need to be in the top 1% of the engineers armed with LLMs. You can't just rely on LLMs getting better. AI is not the great equalizer, it is, in fact the opposite.

[–] JBits 4 days ago

Code written by not very good coders has the possibility to be short and to the point. Even if I think the architectural decisions are wrong, the code still communicates a motive and an understanding of the problem at hand. This is all lost with LLMs.

[–] zahlman 4 days ago

> Code written by not very good coders has the possibility to be short and to the point.

This is very much not my experience.

[–] cicko 4 days ago

Not in many places I've worked at.

[–] wiseowise 4 days ago

> I believe that anyone who says that writing code is no longer needed, was probably not a very good coder to begin with.

I’m probably the best coder in my org, which doesn’t really say much, but at least allows me to judge about the room temperature. It is solved. I don’t say that’s you, but the only people who say it isn’t “that good” are the same people who used to yak shave, rename and move things 10 times until it “feels right”.

[–] XenophileJKO 4 days ago

I've had a realization recently. I was also probably the top craftsman in the teams I worked in throughout my career.

I think what people are missing is that people often become craftsman because we want to be able to keep the code adaptive and performant so we can provide business value quickly and efficiently.

The change is with models, the benefit dynamics of immaculately structured code changes dramitically. Now the real area you need to focus on is correctness and performance. Structure doesn't really matter unless it serves those two purposes, at least from the business value side.

[–] akoboldfrying 4 days ago

This is exactly right. Architecture -- in fact, using any kind of abstractions at all -- is basically a crutch that humans use to make ourselves more effective in implementing and evolving code over time, usually by either compressing the problem domain so that we can pack more of it into our limited brains, or making our own mistakes visible early. It's extremely valuable for humans who need to work on complex systems -- but it might simply be unnecessary overhead for entities with significantly more working memory, just as humans won't plan out a class hierarchy for a 5-line script, much less write a PRD.

[–] prmph 4 days ago

The let the agents work in assembly language then, or even better machine code. It's much more direct and avoids human weakness, right?

[–] akoboldfrying 4 days ago

Yes, directly emitting binaries will likely become practical at some point if LLM context lengths continue to increase. We may be there already for small programs, I don't know.

As with eliminating other forms of abstraction, there's not much gain from doing so. Writing source code and then compiling it offers many useful checks, and greatly simplifies making changes. It's just something that may no longer be necessary at some point.

[–] LeafItAlone 4 days ago

> I think what people are missing is that people often become craftsman because we want to be able to keep the code adaptive and performant so we can provide business value quickly and efficiently.

Nearly everyone I’ve worked with that would say this ended up being the in the bottom quartile of those shipping features and their code was often the most complex. At least in small, “fast”-moving companies.

A few people I have worked with have nailed it, but they were the ones to balance present and future weighted towards present.

[–] mzhaase 4 days ago

I just had an agent implement writing a DB row like this: copy the entire DB into memory. Change data in memory. Delete the DB. Copy everything back.

Spec was good, all tests green, app worked. If I didn't actually go in and try to understand the code I would have shipped it like this.

So here is my question to people saying it's solved : do you actually know that it is or does it simply appear so because all the tests are green?

[–] user43928 4 days ago

Yes, it is solved, and I say that after 500 hours of work on a commercial side project.

First of all, it sounds unlikely to me that such an implementation was made with Opus 5.5 while it never mentioned the workaround.

Secondly, if the performance was indeed inadequate, that's something I would have caught during QA testing and simply have had the agent fix it.

[–] n4r9 4 days ago

Sonnet 5.5 is within a percentage point or two of Opus 5.5 on Terminal Bench.

[–] user43928 4 days ago

I haven't tried Sonnet 5.5 myself since I find Opus 5.5 essentially unlimited in the subscription, and okayish at API rates with a $500 budget.

When I looked at a benchmark, it suggested Sonnet 5.5 wasn't much cheaper than Opus 5.5 at Low to Medium effort for similar performance. That might not be representative of real world use though.

[–] n4r9 4 days ago

My workplace disabled Opus access in June, saying that it is basically the same performance for most coding tasks at a lower cost. That might have changed now. But the main point I'd like to make is that even with Sonnet 5.5 I have a similar experience to OP - code that makes odd performance choices, is over-engineered, and arbitrarily ignores rules we put in the context. For small self-contained apps doing basic stuff it's okay. For 100k+ line codebases running fairly complex algorithmic routines it needs heavy supervision.

[–] user43928 4 days ago

My codebase has 500k lines and some 3D work that needed optimization on mobile. At no point was it needed to supervise the code in the implementation.

Optimizing performance is one of the tasks best suited to AI, since the outcome is measurable.

I can't comment on complex algorithms specifically, but it's not at all the case that this works only for basic apps or cannot handle complex, performance critical work.

[–] prmph 4 days ago

What a weird comment.

First, you question the model. I have reams and reams of conversations with Opus 5.5 that shows it makes architectural messes all the time

And then you are saying you needed to have performance tests (which many devs don't even bother with) to catch bad architecture?? lol

So what if the architectural problem is not one that would be caught with a performance test? It seems you lack imagination to think of all the ton of issues that that would be very complicated to catch with tests.

[–] user43928 4 days ago

Opus 5.5 is not normally copying the whole database to update a single row for no reason, and without mentioning a workaround. It's simply not my experience, and I don't think there is anything weird about me saying so.

I don't think I commented on performance tests at all.

Maybe I lack imagination here, yes, but generally I go by experience rather than talking about imagined issues. That is precisely what many here seem to do when it comes to explaining why AI couldn't work for them, and why reviewing the code remains necessary.

[–] prmph 4 days ago

See this basic architectural smell Claude Opus 5.5 produced just minutes ago:

Me: Why this:

> I'm adding a lookup to persistEphemeralVFolder so that a repeated search reuses the user's root vFolder with the same query instead of hitting the unique index.

Claude Opus 5.5: A search stores its query as an ephemeral root vFolder. The new unique index on (user, parent query, query) now rejects a second root vFolder with the same query. As written, persistEphemeralVFolder always inserts, so repeating a search would fail its insert, the retry with a fresh short code would fail too, and the search would return an error. The Ephemeral VFolder paragraph we rewrote in the SPECS also says a search reuses the existing vFolder with its query, so the user gets the same short code back.

The lookup I proposed would also copy the query-then-create logic already in the PUT /vfolders handler. A cleaner option is one shared engine function that finds or creates a vFolder by query, called by both the handler and persistEphemeralVFolder. Shall I do that, or keep the local lookup?

Churned for 6s · done 1:10 PM

Me: I mean, is it not cleaner to fix this: "persistEphemeralVFolder always insert"

And generally, we want the db and its indexes to do their work, not duplicating that in application code with pre-lookups and stuff

Claude Opus 5.5: You're right. Both persistEphemeralVFolder and the lookup I put in the PUT /vfolders handler should be replaced by a save with conflict keys (user, parent query, query), so the unique index decides whether a row is created or updated.

[–] user43928 3 days ago

What you're showing here seems to be a suboptimal choice being propagated, but with likely no practical impact at all if you kept the lookup.

[–] Arkhaine_kupo 4 days ago

> And then you are saying you needed to have performance tests (which many devs don't even bother with) to catch bad architecture?? lol

if the cost of writing code collapses, what are the barriers to including these kind of tests?

It seems like the flow and work when using LLMs has to change, spend longer on the plan, spend more time on defensive testing, have more comprehensive tests (input validation, cybersecurity, performance, data hygine) and less time on functionality

if you want to write code the old way where the architecture is human readable and the tests are an after thought, then thats on you if you then ignore the part where the human has to read it.

TLDR: either go full agent, or actually learn the code being produced, but not both.

[–] wiseowise 4 days ago

That’s why you steer it, read the code, and steer it again.

[–] zahlman 4 days ago

I don't understand how it's possible to acknowledge the need for this steering so casually, as though it's obvious and expected, while simultaneously holding that "coding is solved". It comes across that "solved" means something very different to different people.

[–] oortoo 4 days ago

It's, imo, a matter of language. "coding is solved" doesn't mean we never care about code ever again, and definitely doesn't mean we never care about the implications of code. But it does mean we never actually code, we always use a tool to automate it.

[–] wiseowise 4 days ago

“Fix ticket-12345” with minimal supervision and a couple of refining prompts is pretty much solved to me.

[–] spacechild1 4 days ago

You're still reading code in 2026? /s

[–] fapjacks 4 days ago

Your experience is aligned almost perfectly with mine. But to be fair, all those tests that are green, are tests that it wrote. :3

[–] zahlman 4 days ago

> but the only people who say it isn’t “that good” are the same people who used to yak shave, rename and move things 10 times until it “feels right”.

… Yes? Of course recognizing the flaws in the code correlates with having high standards. That doesn't mean the flaws aren't there.

[–] wiseowise 4 days ago

I’ve been there, your “high standards” is just noise and annoyance for other people, focus on business value instead of jerking on variable names and “perfectly” aligned folders.

[–] vkgcr 3 days ago

Do you also believe the same for other categories of products? For example, for a car, or for a building? Would you board a plane built by people who focus on business value at the expense of the annoying "high standards"?

Product quality is an emergent property of high standards (aka code quality).

[–] zahlman 3 days ago

I, too, have been there. You misrepresent what I do and why I do it; and I don't want your technical debt.

[–] Seattle3503 4 days ago

What do you mean by "solved"?

[–] wiseowise 4 days ago

You don’t need to write anything by hand at your run of the mill tech job.

[–] Seattle3503 4 days ago

Ah, I think some people who say "coding is solved" implicitly also mean "you don't need to read the code that AI generates". It's not a super clear proclamation, but it is certainly provocative!

[–] user43928 4 days ago

You really don't need to.

Between Opus 5.5 + GPT-6.1 Sol reviewer, most issues and unhandled edge cases are caught during implementation.

Then you QA test and provide the feedback.

I guarantee that this is enough to produce not only a working product, but is well capable of building apps much better than what is out there, without ever looking at the code.

Depending on your product and risk tolerance you may disagree. I believe that for the vast majority of use cases the approach I described, combined with extensive manual testing, is entirely adequate.

[–] senordevnyc 4 days ago

I run a solo SaaS that is closing in on $500k ARR, so I have real skin in the game here, and I agree with you. My experience of writing code with agents over the last 18 months in particular has been a steady erosion in my need to read the code. There are still a few parts of the codebase I'm particularly cautious about doing code review on, and I spot check PRs outside of that, but Opus 5.5 + Sol / Astra / Fable for reviews has been another paradigm shift. I don't think I"ve opened my IDE in weeks at this point.

It's worth noting that I also have a lot of guardrails and custom tooling around my own process to check code quality, QA functionality, limit blast radius of bugs, add observability, make deployments and rollbacks quick and low risk, etc.

[–] Seattle3503 4 days ago

I have solopreneur friend in a similar situation. I think solo businesses are another interesting case and in many ways a special case, because one person takes responsibility the entire business. Working in a large organization, one sticking point I see with AI is that it is very easy to externalize the cost of bad AI usage onto another employee or team. That problem doesn't exist in solo ventures.

I'm not sure if this means we will see smaller and smaller firms as a sort of market darwinism rewards good AI use by solopreneurs, and as large organizations tear themselves apart, or if we see the way big firms hold people accountable for their work change dramatically.

I also wonder what happens to these solo-businesses as they need to hire their second employee. What goes from a personal workflow will need to become a business process. I bet a lot of solo operators will resist employee #2 at nearly every cost!

[–] prmph 4 days ago

Of course, if your objective is simply to make money, this might be relevant. You can also make quick money by polluting the environment, or being devious, or... there are many more direct ways to make money.

If you want to provide a good, secure, user-empowering, performant product, you cannot delegate everything agents, I assure you. And, building your foundation on un-reviewed mess of code will come back to bite you (partly depending on how big you grow), the same way it does with humans, which management always think is not an issue until it becomes one.

Now, you don't have to take my word for. Think of this: why is every change to Claude Code making it worse now? It is not almost unusable for me after many regressions over past hew years in its UX. Is it because of a lack of AI being used in its development?

[–] n4r9 4 days ago

That's the most natural interpretation IMO.

[–] tempfile 4 days ago

That is not at all what "solved" means! If you're still reviewing and re-prompting, it is not solved by a long way.

[–] wiseowise 4 days ago

That’s where we disagree. Feel free to continue refining meaning of “solved” while I chill on HN while my agents are working.

[–] gunslinger_meta 4 days ago

Hopefully I'm not using any of the software you are 'working' on.

[–] wiseowise 4 days ago

Unfortunately for you, you probably do at some point.

[–] Cthulhu_ 3 days ago

At this point, arguably, any code written a year ago by the coding LLMs of the time can be rewritten with those of today, but "better", whatever metric of better you optimize for. This may get better in time, with either better models or better prompts and the like.

Refactoring and clearing up tech debt is faster now than it's ever been, and assuming it'll be even better in the near future, why should anyone care about what is "good" right now?

(This is a devil's advocate kind of remark by the way, I'm very much in favor of good / quality code, but also realistic enough that nobody has or gets time to finetune code nearly as much as they should)

[–] Paturages 4 days ago

In my experience, it's very good at following standards, so good in a structured project. Not so much in a freeform project where things get out of hand pretty quick.

[–] eigencoder 4 days ago

I've found this to be the case as well. In a greenfield project, it tends to go off the rails pretty quick. But when it has lots of examples and a style to follow, it does better.

[–] Veelox 4 days ago

I'm curious, what language do you code in? I use Go for a high scale backend service at this point it is better at writing code for a jira ticket than most of my team.

There is still questions about if that jira ticket should have been written but from ticket to mergable PR it's better than me.

[–] tonymet 4 days ago

maybe so but most of the code produced is low quality, so what do we have to lose?

[–] quantiq 4 days ago

Not to call you out specifically but I cannot believe people still use this as an argument in 2026. As if someone writing bad code while at least trying to learn how to write good code, and a prompter prompting a computer to write bad code that leads to the person learning nothing from the exercise are at all analogous.

I can virtually guarantee the bar for code can go so much lower as we rapidly deskill programmers.

[–] tonymet 3 days ago

Think pragmatically about the volume of software products produced in the last 20 years, and the quality of those products. Not just exceptional consumer facing products like Apple, but all of the low quality business bookkeeping crapware gluing industry together.

We actually have a fabulous opportunity to generate much higher quality code products with AI.

And even in your case, with the eager AI student -- AI code education is much better than reading docs and struggling with tools. Students can now focus on the important software topics.

I remember my intro C++ classes and how many students stumbled on pointless & transient tooling , that was completely orthogonal to their proper engineering skills.

Now students can focus on their area of expertise and produce the highest quality possible without any resource restrictions.