Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why write code in 2026

softwaredoug.com

Post reply on HN
Print view View original

41–50 of 321 posts

Re: Why write code in 2026

#41

Post by yard2010 »

ataru wrote: post #38
h2aichat wrote: post #35

It seems to me that AI won the code Battle and that humans are just trying to justify the defeat. I will relax and wait for the Next AI generation to see how it fixed its problems. May be, everything will be ok.

I've got a coin that answers questions. You have to give it a heads or tails query, then flip the coin, and it returns an answer. It's incredible. Now, it doesn't get the right answer every single time, but we're all learning how to use the new coin technology, and this is only the first generation of coin. The next model of coin is going to be even better. Soon we're not going to need humans any more, for any questi…

I have a coin that can tell you whether a program would halt or not. But it's not always right. I think it's a coin like you have? Still trying to figure out how to use it to prove that p=np.

Re: Why write code in 2026

#42

Post by jurgenburgen »

zelphirkalt wrote: post #40
jurgenburgen wrote: post #37

Earlier quoted context omitted.

> For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. We already tried this with humans. It works so poorly that it got the derogatory name “ivory tower architect”. It usually results in theoretical designs that are unworkable in the actual system, implementation teams (or LLMs) that work around the architecture…

This happens when the architect is out of touch. If the architect themselves works on the code, writes code, deals with the imposed restrictions, then the chances of that happening is much lower. Assuming, that they are a good architect.

I agree, if the architect participates in the implementation then they avoid this anti-pattern. That’s not compatible with hands-off autonomous agents where you treat implementation as a black box.

Re: Why write code in 2026

#43

Post by lordnacho »

vips7L wrote: post #4

I still exclusively write my code. The quality is higher. I know exactly how it works. It’s more extensible. You don’t have to generate it.

But the attraction of LLM code is not that you get quality.

The selling point is that you know have a quality Vs time tradeoff that is a lot better than you used to have.

I can spend 10 seconds typing out a prompt that will generate ok code.

Before a couple of years ago, it might have taken me an hour to type out and debug that code.

Re: Why write code in 2026

#44

Post by girvo »

goodness4all wrote: post #25

I always hated writing code but loved debugging. LLM super charges systems thinkers & auditors, it’s just a different process and no different than copy and paste from stack overflow. It all comes down to the architecture design and LLM just exposes how bad people are at designing dynamic architectures.

> and no different than copy and paste from stack overflow

This isn't really the point of your comment, and for that I apologise, but: not all of us did that. For many good reasons, too.

Re: Why write code in 2026

#45

Post by b112 »

nmehner wrote: post #30
kqr wrote: post #19

Earlier quoted context omitted.

> With generated code you'll search for a long time The observability people will claim that if the dynamic runtime behaviour of your system makes it hard to find the source of a behaviour, your system must be made more transparent and observable. They would also claim this was always the case -- we should never have relied on people's mental models being amazing because people move around. (I don't know yet where I…

If it was only "my" system without any integrations, I might agree. But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ... Upwards there is an ERP integration (and some other systems). Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese. The ERP has…

And here's the thing... juniors become seniors become experts, by doing this their entire career.

By having an understanding built during their entire career.

Right now we live in a fairly-land of mixed capacity. LLMs being used in parallel with skilled people. But as time progresses, there will be no more skilled people, because no one will learn and develop those skills.

If you're in the world of LLMs now, you are basically completely stalled in your personal growth in this field. You will never improve, and some seem to say they lose capabilities as they rely upon LLMs.

The world always changes. But the decisions being made today, are being made by skilled people.

What will the world look like, when it's just all "bro, lol, just tell it to make your thing" and then done?

Re: Why write code in 2026

#47

Post by imtringued »

goodness4all wrote: post #25

I always hated writing code but loved debugging. LLM super charges systems thinkers & auditors, it’s just a different process and no different than copy and paste from stack overflow. It all comes down to the architecture design and LLM just exposes how bad people are at designing dynamic architectures.

I'm not sure this is a good combination?

I mean you're basically saying it is a good thing if the LLM messes up so you have a reason to debug the code.

Re: Why write code in 2026

#48

Post by TacticalCoder »

goodness4all wrote: post #25

I always hated writing code but loved debugging. LLM super charges systems thinkers & auditors, it’s just a different process and no different than copy and paste from stack overflow. It all comes down to the architecture design and LLM just exposes how bad people are at designing dynamic architectures.

> ... and no different than copy and paste from stack overflow.

It's even got a name: sloppy-pasta.

Re: Why write code in 2026

#50

Post by TacticalCoder »

prymitive wrote: post #24

I need to write code because otherwise LLMs will write too much code, it’s only when you fully understand the problem you can generalise it enough to not end up with 10k lines and 5 abstraction layers for “hello world”. LLMs are token predictors, so all solutions are you tokens, the more problems to solve == the more tokens (code) to output.

> I need to write code because otherwise LLMs will write too much code, ...

I second that and I can give an example that happened to me yesterday with a totally SOTA model (a US, not Chinese model).

I needed to display an information on the client-side. Something trivial. I ask the LLM to do it. The thing went onto a rampage: it somehow found a way to pass the information from the server to the client during the initial handshake (already: why, just why?). Modifying both server-side code and client-side code. And it worked.

To an unsuspecting programmer/tester (or automated test)/user: the info is there, what was asked has been done. So it's perfect, flawless LLM victory right?

Except none of that sloppy-pasta was necessary: the info was already available on the client-side and was a one-line change, purely client-side.

These thing shall definitely, as of 2026, write way too much code.

And btw the companies selling metered tokens have a very serious incentive to produce the most complicated, rube-goldberg, solutions that use as many tokens as possible, while still kinda solving the problem.

That way not only you consume tokens to produce the code, but later on you consume tokens when working on that code (which btw is a guaranteed thing: for the LLM just introduced new bugs in that gargantic amount of crap it output).

Funnily enough the very same people who made fun of copy-pasta happen to be in love with sloppy-pasta. Go figure.

Post reply on HN