Comment by jader201
9 hours ago
> 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.
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.
5 replies →
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
3 replies →
> 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.
Businesses demanding high productivity and speed only encourages illicit drug use.
> 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.
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.
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
1 reply →
So... AGI in 6 months?
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.
> 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.
> 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.
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.
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?
> 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.
8 replies →
> 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 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.
[dead]