Item — HN Reader

> But a big yes for still typing code by hand, and not leaving it to the llm. Except it has to be the code generated by your brain.

> That is what will create new neurons and new connections, which is what will keep away the cognitive decline.

100% agree with this.

The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.

I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code, or are in denial that employers will be ok with lower levels of productivity.

If you have the luxury of working for an employer that either doesn’t care or is oblivious to this, then 100% continue writing code by hand.

Or if you do work on the side (whether for fun or for profit) and are ok with lower productivity, then yes, stick to handwritten code.

But just because handwriting code is better for your brain and cognitive development, doesn’t mean that the industry will be in support of it.

11 comments

> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.

Which is why businesses, tech and otherwise, are falling apart constantly unless they achieve gigafuck scale status, at which point they're unkillable no matter how much of this cancer infests their management.

I don't know how we arrived at a social norm where it's just completely fine that leadership in massive companies is just absolutely useless at their jobs, but the firms that last another hundred years are going to be the ones that figure out how to fire them all.

I feel like there is an unspoken assumption of long term maintainability when it comes to LLM generated software. We are still very early in this, so I don't want to make assumptions. In principle, it shouldn't be impossible to both write and maintain stable software, purely with agents.

At least, I'm not aware of any actual reasons, backed by a proper theory.

On the other hand. I've noticed some persistent issues with code generated by agents, especially poorly supervised agents. If engineers become less vigilant, agents never get to the point of not needing supervision and juniors never pick up required skills, this could lead to real trouble.

> long term maintainability

Did business ever cared about this? Like ever?.. I've seen too many code bases with awful code by humans, now AI simply exacerbated the issue but this is nothing new in our field.

I just don't see how this is going to be a battle engineering departments can win. As long as AI is brining money to the business, they are not going to listen.

LLMs aren't perfect and they have problems, but often they write better code than humans. At least this human.

It seems they run into problems with larger concepts and general organization and need guidance at the moment but for a single code file they often do better then I would have.

If an LLM writes better code than you, that says more about you than anything else (either your ability to write code or your ability to evaluate LLMs). The code they write is garbage.

They write garbage if you turn off your brain. They write code as good as yours if you work together.

I broadly agree with you about improving quality through working together. But even with tons of discussion, they still write code that seems fine from a distance but is weird when you actually get down to actually reading it and thinking about it, line by line. It is not junk but sure as hell I can write tighter and cleaner code and I am a very mediocre programmer. The abundance and frequency of "what, why?!" and "why not just..." reactions I have at LLM code throughout the day has made that much clear to me.

If you write more good code by hand than by agent in 2026 that says more about you than anything else (either your ability to give instructions or your ability to delegate). The code they write is above average.

> The code they write is garbage.

This is trolling right?

No. Sometimes they produce code that's ok in small units, but definitely not all the time.

I agree with everything you said.

I’m simply playing devil’s advocate, because engineers can believe one thing, but until employers believe it, it doesn’t matter much.

I’m also not convinced that the reality of LLMs will never catch up with what employers think they can do.

It may never happen, but it very well could.

Either way, I feel the days of employers being ok with handwriting code are limited.

The complexity of code is combinatorial. Code is harder to understand than it is to create. The LLMs will be creating code that they will not (nor will any human) be able to understand later, or it won't be the same understanding that was used to create it. We'll find that systems that were created with LLM code will be impossible for LLMs to contextualize, or will be cost-prohibitive to do so.

The wages for the LLM will increase as the codebase gets larger, the only inhibitor is how fast customers are willing to pay for new features. I don't think that cost ever goes higher than human wages for maintainable software.

In theory (never happens) the software will become feature complete and you only pay the LLM for security updates.

It's a moot point. In Mag7 companies internal code gets thrown away within 2 years on average because of contract negotiations, new opensource projects that obviate need for the internal codebase, license changes, layoffs, etc, etc. We don't need long term maintainability because its already on its way to the garbage bin. Frankly it's always been this way.

Its' the exact opposite ... Google, nVidia, Amazon, Apple, etc. all have a deep bench of code that is a moat. They have lots of throwaway code too, but those companies are precisely the ones that pay attention to code quality, and comprehensibility by experts

A rough proxy for this would be if they say contribute to the C++ standards process, which Google Microsoft nVidia do, and basically zero "normal" companies (say SaaS) do. It means they are investing in multi-decade maintenance of their codebase

"Contribute" is an interesting word, since those companies are so big they can just dictate the standards they prefer. Also they are so big and have so much cash pouring in that they can afford to pay employees with nothing better to do than spend time drafting C++ standards. The average normal SaaS company is hoping they can make payroll next month.

Is google still a big contributor to the c++ standard? I thought they are far less involved than a decade ago.

I’m talking back of house, you’ve sort of mistakenly missed my point and made a rebuttal to some completely different question and I agree with you.

> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.

It was/is a struggle to get them to recognize and balance tech dept, we must now push to balance cognitive dept as well.

Some employers will eventually get it as they have with tech dept. And those will be the ones we see succeed.

It is game theory optimal to use LLMs as little as possible even if your employer wants you to use it. The less you use it, the more competitive you are in the market, and probably also in your current workplace, LLM usage metrics notwithstanding. This fact will remain true forever, even if LLMs always outperform handwritten code and all employers want you to use them.

Probably what you want to do is use it a lot when you first start a job to establish some productivity credence, then as you become ready to switch jobs, use it less and less until you're writing everything by hand and taking interviews.

Interesting idea. I hope you're right: but have you tested this idea on the job market?

Well there’s a lot of middle ground between “don’t use AI” and “generate everything, exclusively.”

When the bill for the latter lands with a heavy thud, moderation and common sense start to look like a pretty good idea.

> Well there’s a lot of middle ground between “don’t use AI” and “generate everything.”

Sure, but again, this assumes both that handwriting code sometimes outperforms LLMs, and also that your employer agrees with this.

I think it’s only a matter of time (again, if we’re not already there) before LLMs outperform handwritten code nearly all of the time.

And, even if that’s not the case, I’m pretty convinced nearly all employers believe this is true, whether it is or not.

So your employer only sees a “middle ground” as room for higher productivity.

Perhaps the thing we’re going to learn to leave behind after all the dust settles … will be shitty management at shitty companies?

Because to be honest, more and more it seems many businesses have no real purpose other than to act as a sort of adult daycare for otherwise useless people.

this pure speculation. maybe you're right that it's a matter of time but /maybe you're wrong/. neither of us can actually know, because you're making predictions about the future rather than claims about what is true today

I'm REALLY REALLY not enjoying this current middle ground where we may be on the cusp of LLMs writing all code better than I could OR we may be on the cusp of realising that this is a chimera.

Mostly I just want to skip forward to the point where we find out which track we're on, because until we know, I feel constantly tense.

So... AGI in 6 months?

> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.

I feel like this is an odd thing to be reticent about. You're working for someone who doesn't care about you and, in this changing landscape, you're compartmentalizing that in order to determine how best to care for yourself. Logically, to care for yourself you'd need to find an environment in which your needs aren't being neglected.

> or are in denial that employers will be ok with lower levels of productivity.

More like sweeping the dust under the rug for later. The initial productivity boost is massive but at the cost of massive upfront tech debt. Given that LLMs aren't as good at removing code as they are at generating it, this is a problem.

> I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code...

They certainly don't today. Perhaps they will in the future, but based on the lack of improvement thus far it seems unlikely that they will get to this point. But whether or not they do improve to that point, the reality is that today, LLMs do not give you a productivity boost unless you give up on quality and just YOLO stuff the LLM gives you without actually checking it. And nobody should be willing to do the latter, because that is how you get software/infrastructure that doesn't actually work.

> I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code, or are in denial that employers will be ok with lower levels of productivity.

Cooking a steak and then flushing it straight down the toilet outperforms all the slow and tedious business of eating and digesting it, too.

Why should I use an LLM to write code? It cannot do the job I want it to. It cannot type the code I've already written and it cannot generate correct code.

> Cooking a steak and then flushing it straight down the toilet outperforms all the slow and tedious business of eating and digesting it, too.

That would be more equivalent to writing the code and immediately deleting it.

Except this code is being deployed, and it is still (mostly) functional, at least functional enough to satisfy your employer (their “hunger” in your analogy).

> Why should I use an LLM to write code? It cannot do the job I want it to.

Because your employer is convinced that it can do the job they want it to (whether it does the job you want it to do is irrelevant, unless you're the employer, in which case 100% handwrite your code).

> Except this code is being deployed, and it is still (mostly) functional, at least functional enough to satisfy your employer (their “hunger” in your analogy).

Bzzzt. Wrong. I don't give a fuck who's satisfied by my code. I only care about writing it.

> Because your employer is convinced that it can do the job they want it to

Bzzzt. Wrong. The code is incorrect because it is not precisely the code I would have written.

LLMs are useless to me because they don't solve the problem of actually typing the code I've written into a computer.

Again, unless you’re the employer, then you’re getting paid by someone that cares more about productivity than whether you think LLMs produce incorrect code.

All that matters is whether they agree with you.

The only control you have over this is to either a) work for yourself, or b) keep looking until you find an employer that agrees with you.

My argument is that the number of employers that fall under (b) is shrinking.

> My argument is that the number of employers that fall under (b) is shrinking.

That's great. Sucks to be them. I've doubled my prices and doubled my time estimates and I'm still turning work away.

Thing is, companies don’t care if it’s not your code or your view of it. If it works, that’s what they want. Since I stopped typing code I’ve been using my time to play some video games, read some books etc while the agents do the boring stuff (work itself). I get paid, the company is more productive, I got a bonus and a raise, everyone’s happy.

With the rise and rise of LLM slop in code, I've just had to jack my prices through the roof.

The first thing I do when I'm asked to clean up the LLM slop is "rm -rf ." and start from scratch.

You will pay a fortune for this.

Alright. My company’s money is not my money, so not my problem!

This is cope.

What is "cope"?

"I am the world hence everything i say must be correct and there can be no counter opinions because i know everything. bzzzt."

> It cannot do the job I want it to.

I mean in your case, you are not able to use LLMs effectively to build features, so you should type the code by hand.

However, upper management is excited about AI because it can push features quickly to production. Granted, they will be giant balls of slop but they don't care. As long as it works in the UI, they are happy.

If no one could get anything done with AI, there wouldn't be billions invested i n it.

> I mean in your case, you are not able to use LLMs effectively to build features, so you should type the code by hand.

I never write code sitting at a computer. Mostly I write it in the car, when I have no distractions. I just type it in when I'm sitting at the computer.

I've been using Claude as an experiment for some "fun" projects that I'm unlikely to release, just to see how it is.

The thing is, at least for the stuff where it's getting deep into the far edges of synthesizer firmware, disk image decoding, audio generation and the like, Claude is mostly just quoting my own github repositories back to me.

So, I guess I'm doing something right then, or maybe I'm doing it wrong.

I mostly do reading in front of the computer (not code, docs), but that's before I'm used to the project. Usually I spend more time on the couch than in front of the computer. Because that's where I think best. If I'm writing code, I already have the solution.

Yup, that's what I do to, although like I say I mostly write my code in the car. I work on things all over Scotland so quite often I'm spending six hours driving to do a ten minute repair, and it is *great*. No, you can't phone me, I'm driving. No, I can't just jump on your teams call real quick, I'm driving? Email? No, driving.

It is *great*.

Businesses demanding high productivity and speed only encourages illicit drug use.

Not shocked to see here that people believe "manually writing code" is the way to build brain power.

How about moving up the stack?

This is what I've been focusing on. Writing good user stories, defining the definition of "done", acceptance testing. Thinking about the high level design decisions. Never thinking about how I'm going to implement feature X is honestly a breath of fresh air.

I've been writing code for nearly 30 years, and I'm done.