[hootz]

But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code?

Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?

[jrflo]

I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?

[snek_case]

The difference is that LLMs are not compilers. You can't trust the output to be correct. They routinely make bad design choices. If you're prototyping some kind of throwaway MVP, you're just sketching something, it's probably fine not to review it. If you're trying to build a piece of software that's going to survive for years, why are you doing this? The tech is clearly not yet fully mature.

Just yesterday, I was trying to use Claude Opus 4.7 to debug an issue in a program that I wrote, and its solution was to remove a feature, change the design to eliminate the problem without consulting me. I only found out that it had removed this feature through testing. Imagine not reviewing things like that. How can people argue for this with a straight face? We'll probably get there eventually, but there's no need to rush before the tech is ready. Doing that is just being clueless.

[soraminazuki]

The comparison with compilers is absurd on its face, yet some keep pushing it as if repeating it enough times will make it true.

[snek_case]

The people who make that comparison are just showing how clueless they are IMO.

[DerArzt]

Why is it absurd?

[soraminazuki]

For the same reason others have explained here and elsewhere, with some writing entire articles on the topic. Compilers produce semantically equivalent translation of source code into target code. That's not at all what LLMs do. They produce unpredictable results from ambiguous specifications written by people who may or may not understand software engineering. Big difference.

[cguess]

It did atrophy, but more importantly understanding what's going on below the code you are writing, even if your project isn't assembly, also atrophied. When you're coding an Electron app with Javascript you're so far removed from any concept of the efficiency a modern CPU can achieve you stop caring about optimization. Speed and memory management don't matter and then you get... well, the modern web.

[hootz]

And the modern web being usable is basically thanks to the people who understand lower level optimization.

[hedgehog]

There's clearly a range of outcomes, from the people pushing the envelope in system performance (look at the state of networking ASICs and the code to drive them) to people adopting hyper-complex frameworks for cloud orchestration and job coordination that turn a few screens of code into system so slow and complex it needs a team to maintain it. It's all happening at once, and it's probably ok. Keep in mind, knowing how to write assembly and knowing how to get good performance out of a CPU are two different things, modern chips are insanely complicated and the mental model is a long way from the days of the 386 or 68030 (let alone pre-MMU computing).

[righthand]

This analogy is always weird to me, the change your talking about was still deterministic. Switching from programming to describing programming and having a machine make a best guess is not a deterministic shift as previously happened.

[dadoum]

The compiler has been written by a lot of very smart people, it is very well tested and sometimes has even been formally proven to output exactly what the language specifies, and I have a mental model of what the code it outputs does in relation to what I write.

Nobody can be sure of what the LLM will output for a certain prompt. If you don't review what it outputs, it will not necessarily match your expectations. You could argue that it is the same as when you assign an intern to the task, but I personally would check what the intern writes (and in my experience they are more reliable than current AIs, of course not as quick).

[cortesoft]

They absolutely did: https://vivekhaldar.com/articles/when-compilers-were-the--ai...

[linksnapzz]

The move to HLLs created new classes of problems that assembly programmers didn't face; so while the # of problems that necessitated understanding hw didn't shrink, it did relative to the list of things that could now go wrong.

[hootz]

And they did atrophy! I only know assembly because I deliberately studied it and practiced it for reverse engineering. But in my view, no longer being able to understand high level code is a much, much bigger problem than not understanding assembly.

[weakfish]

Especially because Markdown --> code is _non-deterministic_

[hootz]

Yeah. Actually, that's a cool thing to think about. Will it be possible in the future for an LLM to be deterministic enough to the point of becoming essentially a text to code compiler? Like, an entire class of LLMs that are meant to be deterministic to the point that even upgrades to the model wouldn't completely change the outputs (it could have some breaking changes).

[dijksterhuis]

reality is more nuanced. some people still need to inspect machine code by hand. people who primarily write SaaS django boilerplate don’t. the arguments were made back then, im sure.

but, according to the worst offending and persistent ai-hyper comments on this site, this is apparently a paradigm shift unlike anything that’s done before. according t them we don’t even need to understand high level languages, let alone machine code. which is frankly ridiculous.

i’m an “AI luddite”. but i accept there are useful use cases. that’s not where all the wasted money is going though.

[lenerdenator]

I don't think it's necessarily a question of laziness. It's more about velocity.

Your CTO was just shown a demo where a fairly complex piece of software was spat out in MVP form within a few hours. Something that used to take months is now more-or-less completed in a two-week period, including deployment.

The CTO knows that competitors are seeing the exact same thing and are going to try it for themselves. Now your company has to use the LLM because that's going to enable the development speed seen in the demo if they want to stay in business.

There's the iron triangle of engineering: fast, cheap, good. You used to have to pick two. And in reality, you still have to pick two, but a lot of this technology is sold as allowing you to pick all three. It lets you pump out a MVP:

1. fast - it's done in a few days 2. cheaply - you don't have to pay engineers as much or at all 3. it's "good" - it looks good enough for the client to accept it instead of suing you and give you revenue.

The third part is where this breaks down. Like you say, people aren't reviewing this code. It's probably 85%-95% of the way to fulfilling all use cases, but that 5%-15% is the critical part where there's SLA violations and risks to business, property, or people. The thing is, clients have to find that within the first 90 days to have it impact the books for that quarter, and they probably won't. Also, you have lawyers who can drag it out further. If the company really gets screwed by quality problems, well, sell to a competitor or someone and return value to shareholders that way. There's always some way to get cash back.

So we've pushed out code faster, gotten revenue booked, and have a way to not lose money in the short-term, which is ultimately the only term that matters. The goal was never making good code; it was making money as fast as possible. Velocity. LLMs deliver on that.

[soraminazuki]

Already happening. For many people, coding isn't the only thing they've abandoned. They've also traded science and engineering for LLM punditry. Rather than "focusing on solving problems," as they often claim, they spend their time chasing unscientific debates about which model or magic prompt "performs better." By unscientific, I mean there's nothing measurable, no reproducible methodology, and no way to validate their hypotheses. Or rather, their wild speculations that change every week.

[Glohrischi]

I think I read so much code over the last 15 years, that its not a thing i will lose.

But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.

[doug_durham]

Accountability is the key. You are accountable for the work product. You need to do what is necessary to make sure that the product meets standards. How you do it is of secondary importance. If reading code is what is needed to guarantee quality and you stop, that is on you.

[maxheyer]

Trust creep is the part I worry about too. Today I read every diff.

[infinet]

There is a saying that many countries have offshored building hardware, aka manufacturing. Now they are offshoring software building to AI. Perhaps the silicon valley will grow a rust belt.