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".

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.

> 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.

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.

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.

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

This is very much not my experience.

Not in many places I've worked at.

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)

> 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”.

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.

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.

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

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.

> 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.

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?

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.

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

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.

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.

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.

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.

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.

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.

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.

> 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.

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

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.

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.

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

You're still reading code in 2026? /s

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

> 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.

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.

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).

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

What do you mean by "solved"?

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!

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.

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.

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!

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.

I bet a lot of solo folks are thinking along the same lines. I'm curious how it influences the shape of these enterprises. I imagine that if something can't be done with AI, or can't be bought, it won't be done at all.

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.

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.

OK, then we are mostly in agreement. It does not sound like you are completely vibe-coding your way around.

We may differ in the level of review and steering we do a bit. I have worked in codebases approaching a 1 million LOC, and I am now working on a suite of products and libraries in a monorepo that would be the flagship products of my own small company.

I have defined a strong architecture, guardrails, and a way of working that the agents keep to. I approve almost every single edit they do in the terminal, but most of the time I do not have to read each line, because they are good enough. Every now and then, I catch them doing something egregious, and I correct or redirect them. Other times, they stop to ask me for direction. Still, I am faster and do more work with the help of the agents.

So, no I'm not saying the agents do not provide value; they help with a lot of grunt work, and they can write most code basically correctly. Where I am firmly still in the driver's seat is with architecture, UX, quality control, product invariants and standards, and the occasional tweak to lower level implementation details. These remain a lot of work, unless you are simply building CRUD forms.

This does not sound like "coding is solved". If coding is solved, then I can one-shot a complex software product into being, which is never going to be the case.

That's the most natural interpretation IMO.

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

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

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

Unfortunately for you, you probably do at some point.

Would you mind telling me what it is? Asking for a friend.

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.

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.

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

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.

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.

I still enjoy and use https://blitzmax.org/

Unpopular opinion, but I think the "Lofi" sound or style ruins perfectly fine songs.

*losing trillions

And my wallet is thought to contain a billion dollars, so long as I don't open it.

Seriously "thought to be" is such a baseless statement. Thought to be by whom? And on what basis?

It’s thought to be because it’s a private company but it’s very well cited.

You probably shouldn't believe leaks when a company has a financial incentive to appear profitable (particularly when attempting to IPO).

If they were cash flow positive they would tell it to everyone, be sure of that.

Anthropic is currently in an IPO quiet period and cannot publish such information.

Billions of long-term users for the most important technology in human history isn't a premise of fake cash in a circular economy.

You might as well pretend there's no money in search or social media.

1999. That Google, it has no serious business model, it'll never make real money. Hello GoTo.

2006. That Facebook, it has no serious business model, it'll never make real money.

One more: 2020. That Uber, I could clone an MVP and kill them over the weekend if I really wanted to. That's a side project at best. They're bleeding to death anyway, losing money hand over fist, they'll never make it. They have no moat at all.

Was google already selling ads in 1999 ? Because before that, NO, they did not have a viable long term economic model.

Funny thing is, they stated their reason for existence was because ad-based revenue models would corrupt search quality. Funny that!

Same as our OpenAI friends, who founded a non-profit because one company (Google) holding AGI would be dangerous for humanity. Turns out it's only dangerous when it's somebody else's company. When it's yours, it changes things slightly.

Eh. You’d have to clarify that. Google get started because other search engines at the time sucked. I had a soft spot for Ask Jeeves, but it was clear Google was better.

Advertising is the monetizing strategy from early on. AdWords came to be in 2000. Nothing fuzzy about that.

I don't get it... it looks flat to me?

I can't help you with that

Is anything really "free"?

XMPP always seemed great, buy I have yet to find a client that can replace Telegram's client on both desktop and mobile.

I use 'Conversations' (from F-Droid) on my Android and self-hosted 'XMPP Web' on my PC https://github.com/nioc/xmpp-web This combination covers 99% of my needs.

It still doesn't actually display a window my end until I press a keyboard key or move the mouse. So very often I sit and wait for it to open, only to realize I have to press a random key for it to unhide.

Terrible Linux support.

That's something I've never encountered on Linux/KDE/Wayland/Flatpak across Debian Trixie, Arch, and Fedora. Might be worth nuking your local Zed files and trying again.

I downloaded the Radicle desktop client yesterday, entered my new username and password and... nothing happened. Tried restarting the app and do it again, but I never got past the account creation/login screen. So my Radicle adventure ended there.

Try the getting started guide: https://radicle.network/guides/getting-started

Radicle uses a key for your identity. There is no username. You can self-assign an alias for a more human recognisable name.

I just run Gemma4 12B MLX via Ollama and it's been doing fantastic work!