Live data from Hacker News

Why write code in 2026

softwaredoug.com

21–30 of 321 posts

Re: Why write code in 2026

#21
post #13

Recently, even a tourist lost to OAI's model in competitive coding. To be honest, I haven't been able to beat AI at coding since around 5.2. People often say 'AI can't write good code,' but in reality, the quality of AI's output is layered depending on the level of the prompt input. The deeper the prompt, the better the code actually gets. Usually, when people say AI code is terrible, it's because they either don't u…

I don't write code anymore, because AI writes better code than me. I could write code, but the next AI would find 10 ways to make it better and more consistent with the rest of the AI-generated codebase. So I just let it write all of it. However, I inspect it all carefully and I constantly asks it to reflect on the code quality, to refactor, to reorganize, to make the code as good as possible. The end result is code that is much better than anything I could have written myself.

And I should mention that I have 30+ years of programming experience.

Re: Why write code in 2026

#23
post #21
post #13

Recently, even a tourist lost to OAI's model in competitive coding. To be honest, I haven't been able to beat AI at coding since around 5.2. People often say 'AI can't write good code,' but in reality, the quality of AI's output is layered depending on the level of the prompt input. The deeper the prompt, the better the code actually gets. Usually, when people say AI code is terrible, it's because they either don't u…

I don't write code anymore, because AI writes better code than me. I could write code, but the next AI would find 10 ways to make it better and more consistent with the rest of the AI-generated codebase. So I just let it write all of it. However, I inspect it all carefully and I constantly asks it to reflect on the code quality, to refactor, to reorganize, to make the code as good as possible. The end result is code…

To be honest, as you know, background knowledge is extremely important in programming. As you move into complex domains, the specifications multiply. So as a domain gets more complex, there comes a point where it exceeds my cognitive capacity. And that's when AI surpasses me and writes code I can't keep up with.

Usually, it produces code that would take three or four humans days to figure out—in just 20 minutes.

Even the professors and PhDs who hire me all use AI. Honestly, they hold PhDs and professorships, which puts them in a league I can't even touch—and even they use it. AI just does it really well.

Honestly, I learned from your book, 'rossant'—I never expected a programmer like you to say something like that. I thought my perspective was because I'm only an intermediate-level programmer. But you're in the 1% expert category I mentioned

Re: Why write code in 2026

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

Re: Why write code in 2026

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

Re: Why write code in 2026

#26
post #19
post #16

"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code" I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subc…

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

The observability people are correct. It’s not either-or though.

Re: Why write code in 2026

#27
> If we’re building a software factory, details matter. The details that establish architectural patterns. Down to algorithms and performance. Agents push us to evaluate, measure, and guard. They’ve made it cool to add CI into side projects early, not as an afterthought. That’s massive improvement to the state of software.

Why are you building a software factory though, and why weren't you immediately adding CI to every project?

> It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.

Again, why? Where are you working where this is considered a good idea? This would mean that the software engineers are not just being completely kicked out of all business decisions, but asked to build a moat that ensures they stay on the other side of it.

Any business that intentionally devalues the insights gained through implementation will eventually starve itself to death by making too many passive thoughtless moves. No insight will ever be gained just spot checking AI. Is their intention really just to make tiny amounts of profit while riding the thing into the ground? Crabs in a bucket, man.

Re: Why write code in 2026

#28

This is too generic. There's some code I need to write like core abstractions that are going to set the pace for everything. Or tricky steps that can look good without actually working well. Then there's the mass. I don't need that anymore. The mountains of boilerplate, etc. I write little islands which need high judgement that are then connected by the obvious goo.

this is the way

Re: Why write code in 2026

#29
post #14

Do ppl think that programmers just write code from sratch each time..?! Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.

+1, I don’t understand who these greenfielders are. Either I wait on the CI to finish, or I’m in a meeting.

Re: Why write code in 2026

#30
post #19
post #16

"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code" I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subc…

> 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 the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.

Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.

Sometimes the on-premise network stops working for whatever reason and data is lost.

Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."

So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.

And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.

Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.

There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.

Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.

Post reply on HN