Hacker News
points by wiseowise 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’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!

[–] senordevnyc 4 days ago
Haha, it's funny you mention that: my goal is to never hire a second employee. I want to see how far I can go with just me + agents.
[–] 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?

[–] user43928 4 days ago
On what basis do you assure us that?

Because by my estimation we did build our products in such a way and have that experience, while you presumably did not.

As for Claude Code, they recently delivered a significant upgrade to the desktop app where some commented that it felt like they upgraded Opus 5.5 to 5.6.

It's in fact working great, and the days where it was buggy are in my view in the past.

[–] senordevnyc 4 days ago
I mean...yeah, my objective here is to make money. It's a business. It provides for my family. I find it humorous that you feel the need to diminish it and compare it to polluting the environment or being devious, but you do you.

As for the rest, I assure you that the product is much more performant, secure, and delivers far, far more value to my users than I ever could have done prior to AI-assisted coding. And I'm a staff level engineer with 25 years of coding experience across all kinds of organizations. I'm not the best coder, but I'm at least decent. AI has been a massive force multiplier for me, even as I agree that it's not perfect.

Unpacking a little more, I think the area you might be running into issues with is the idea that because I rarely open my IDE, I'm "delegating everything to agents". I'm really not. I review PRs (just not in my IDE), I steer higher-level abstractions in the broader system. To me, automated coding with a frontier model is definitely good enough that it's utterly pointless of me to read the internals of 99% of functions, even classes. Assuming the inputs are correct, the agents will get those details correct. And for the tiny fraction of the time when that's not the case, that's why we have adversarial review, guardrails, tests, o11y, quick rollbacks, etc, etc. Working at the level of how the broader building blocks of the system fit together, bisecting the software into low / medium / high risk areas so I can direct more of my scarcest resource (my attention) towards the highest ROI portions, and building the infrastructure (the "software factory") that the agents work within building and improving the product is where I can add the most value in November 2026.

Have you ever worked in a bigger tech company with tens of millions of lines of code and senior staff / principal engineers? In my experience, sure they're reading and writing code here and there, but that's not the value they provide. The value they provide is the broader architectural view of the systems and how they fit together. It's no different with AI.

[–] 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.
[–] gunslinger_meta 4 days ago
Would you mind telling me what it is? Asking for a friend.