[agarren]

> [Harper Reed] cautioned against being overly precious about the value of deeply understanding one’s code, which is no longer necessary to ensure that it works.

That just strikes me as an odd thing to say. I’m convinced that this is the dividing line between today’s software engineers and tomorrow’s AI engineers (in whatever form that takes - prompt, vibe, etc.) Reed’s statement feels very much like a justification of “if it compiles, ship it!”

> “It would be crazy if in an auto factory people were measuring to make sure every angle is correct,” he said, since machines now do the work. “It’s not as important as when it was group of ten people pounding out the metal.”

Except that the machines doing that work aren’t regularly hallucinating angles, spurious welding joints, etc.

[lolinder]

Also, you know who did measure every angle to make sure it was correct? The engineers who put together the initial design. They sure as hell took their time getting every detail of the design right before it ever made it to the assembly line.

Who's filling that role in this brave new world?

[alpaca128]

They took their time precisely specifying the robot movements so they're always repeatable. Almost like...some sort of carefully crafted code.

[b112]

This also seems, to me, like composer/npm issues.

An entire generation of devs, who grew up using unaudited, unverified, unknown license code. And which at a moments notice, can be sold to a threat actor.

And I've seen devs try to add packages to the project without even considering the source. Using forks of forks of forks, without considering the root project. Or examing if it's just a private fork, or what is most active and updated.

If you don't care about that code, why care about AI code? Or even your own?

[xeonmc]

Cory Doctorow described this cart-before-the-horse arrangement as Reverse Centaurs[0][1]

[0] https://pluralistic.net/2022/04/17/revenge-of-the-chickenize...

[1] https://pluralistic.net/2024/08/02/despotism-on-demand/

[d0gsg0w00f]

This is an underrated comment. Who's job is it to do the thinking? I suppose it's still the software engineer, which means the job comes down to "code prompt engineer" and "test prompt engineer".

[nothercastle]

Not true anymore, lots of places want to reduce engineering hours and let production eat the cost of defects.

[mrheosuper]

it would be the SA guy, but look like he will also be replaced by a bunch of "vibe coder"

[throwup238]

> Who's filling that role in this brave new world?

Us?

(Yeah, we’re fucked)

[RossBencina]

The whole auto factory thing sounds completely misinformed to me. Just because a machine made it does not mean the output isn't checked in a multitude of ways.

Any manufacturing process is subject to quality controls. Machines are maintained. Machine parts are swapped out long before they lead to out-of-tolerance work. Process outputs are statistically characterised, measured and monitored. Measurement equipment is recalibrated on a schedule. 3d printed parts are routinely X-rayed to check for internal residue. If something can go wrong, it sure as hell is checked.

Maybe things that can't possibly fail are not checked, but the class of software that can't possibly fail is currently very small, no matter who or what generates it.

[jasonwatkinspdx]

Additionally production lines are all about doing the same thing over and over again, with fairly minimal variations.

Software isn't like that. Because code is relatively easy to reuse, novelty tends to dominate new code written. Software developers are acting like integrators in at least partly novel contexts, not stamping out part number 100k of 200k that are identical.

I do think modern ML has a place as a coding tool, but these factory like conceptions are very off the mark imo.

[red_admiral]

On the auto factory side, the Toyota stuck gas pedal comes to mind, even if it can happen only under worst-case circumstances. But that's the (1 - 0.[lots of nines]) case.

On the software side, the THERAC story is absolutely terrifying - you replace a physical interlock with a software-based one that _can't possibly go wrong_ and you get a killing machine that would probably count as unethical for executions of convicted terrorists.

[jcims]

A buddy of mine was a director in a metrology integration firm that did nothing but install lidar, structured light and other optical measurement solutions for auto assembly plants. He had a couple dozen people working full time on new model line build outs (every new model requires substantial refurb and redesign to the assembly line) and ongoing QA of vehicles as they were being manufactured at two local Honda plants. The precision they were looking for is pretty remarkable.

[0xEF]

> Any manufacturing process is subject to quality controls.

A few things on this illusion:

* Any manufacturer will do everything in their power to avoid meeting anything but the barest minimums of standards due to budget concerns

* QA workers are often pressured to let small things fly and cave easily because they simply do not get paid enough to care and know they won't win that fight unless their employer's product causes some major catastrophe that costs lives

* Most common goods and infrastructure are built by the lowest bidder with the cheapest materials using underpaid labor, so as for "quality" we're already starting at the bottom.

There is this notion that because things like ISO and QC standards exist, people follow them. The enforcement of quality is weak and the reach of any enforcing bodies is extremely short when pushed up against the wall by the teams of lawyers afforded to companies like Boeing or Stellantis.

I see it too regularly at my job to not call out this idea that quality control is anything but smoke and mirrors, deployed with minimal effort and maximum reluctance. Hell, it's arguably the reason why I have a job since about 75% of the machines I walk in their doors to fix broke because they were improperly maintained, poorly implemented or sabotaged by an inept operator. It leaves me embittered, to be honest, because it doesn't have to be this way and the only reason why it is boils down to greed and mismanagement.

[lambdasquirrel]

It’s been said that every jetliner that is in the air right now has a 1in hairline fracture in it somewhere? But that the plane is designed for the failure of any one or two parts?

Software doesn’t exactly work the same way. You can make “AI” that operates more like [0,1] but at the end of the day the computer is still going to {0,1}.

[brundolf]

Something I've been thinking about is that most claims of AI productivity apply just as well (and more concretely and reliably) to just... better tooling and abstractions

Code already lets us automate work away! I can stamp out ten instances of a component or call a function ten times and cut my manual labor by 90%

I'm not saying AI has nothing to add, but the "assembly line" analogies - where we precisely factor out mundane parts of the process to be automated - is what we've been doing this whole time

AI demands a whole other analogy. The intuitions from automating factories really don't apply, imo.

Here's one candidate: AI is like gaining access to a huge pool of cheap labor, doing tasks that don't lend themselves to normal automation. Something like when manufacturing got offshored to China in the late 20th century

If you're chronically doing something mundane in software development, you're doing something wrong. That was true even before AI.

[fhd2]

100%. I keep thinking this, and sometimes saying it.

Sure, if you're stuck in a horrible legacy code base, it's harder. But you can _still_ automate tedious work, given you can manage to put in the proverbial stop for gas. I've seen loads of developers just happily copy paste things together, not stopping to wonder if it was perhaps time to refactor.

[Cthulhu_]

Exactly that. Software development isn't about writing code, never was, it's about what code to write. Doesn't matter if I type in the code or tell an AI what code it should type.

I'll admit that assuming it's correct, an AI can type faster than me. But time spent typing represents only a fraction of the software development cycle.

But, it'll take another year or two on the hype cycle for the gullible managers being sold AI to realise this fully.

[andyferris]

The correct analogy is that software engineers design and build the _factory_. The software performs the repeatable process as defined by code, and no person sits and watches if each machine instruction is executed correctly.

Do you really want your auto tool makers to not ensure the angle of the tools are correct _before_ you go and build 10,000 (misshaped) cars?

I’m not saying we don’t embrace tooling and automation as appropriate at the next level up, but sheesh that is a misguided analogy.

[brundolf]

Yes and this is just garden-variety abstraction and toolmaking, which is what programmers have done since the very beginning

[p_v_doom]

> The correct analogy is that software engineers design and build the _factory_.

This is, I think very important especially for non-technical managers to grasp (lol, good luck with that).

[lolbert6]

works for tesla

[red_admiral]

> It would be crazy if in an auto factory people were measuring to make sure every angle is correct

They are.

Mechanical engineers measure more angles and measurements than a consultant might guess - its a standard part of quality control, although machines often do the measuring with the occasional human sampling as a back-up. You'd be suprised just how much effort goes into getting things correct such as _packs of kitkats_ or _cans of coke_.

If getting your angles wrong risks human lives, the threat of prosecution usually makes the angles turn out right, but if all else fails, recalls can happen because the gas pedal can get stuck in the driver-side floor carpet.

Assembly-line engineering has your favour that (A) CNC machines don't randomly hallucinate; they can fail or go out of tolerance, but usually in predictable ways and (B) you can measure a lot of things on an assembly line with lasers as the parts roll through.

It was thankfully a crazy one-off that someone didn't check that _the plugs were put back into the door_, but that could be a sign of bad engineering culture.

[bumby]

>It would be crazy if in an auto factory people were measuring to make sure every angle is correct

To someone who used to automate assembly plants, sounds to me as a rationalization of someone who has never worked in manufacturing. Quality people rightly obsess over whether or not the machine is making “every angle” correct. Imagine trying to make a car where parts don’t fit together well. Software tends to have even more interfaces, and more failure modes.

I’ve also worked in software quality and people are great at rationalizing reasons for not doing the hard stuff, especially if that means confronting an undesired aspect of their identity (like maybe they aren’t as great of a programmer as they envision). We should strive to build processes that protect us from our own shortcomings.

[AlexandrB]

> Imagine trying to make a car where parts don’t fit together well.

Don't have to imagine, just walk over to your local Tesla dealership.

[namaria]

What strikes me the most is not even that people are willing to do that, to just fudge their work until everything is green and call it a day.

The thing that gets me is how everyone is attaching subsidized GPU farms to their workflows, organizations and code bases like this is just some regulated utility.

Sooner of later this whole LLM thing will get monetized or die. I know that people are willing to push bellow par work. I didn't know people were ready to put on the leash of some untested new sort of vendor lock-in so willingly and even arguing this is the way. Some may even have the worst of the two worlds and end up on the hook for a new class of sticker shock, pay down and later have these products fail from under them and left out to dry.

Someone will pay for these models, the investors or the users so dependent they'll pay whatever price is charged.

[pchristensen]

Harper talks a lot about using defensive coding (tests, linters, formal verification, etc) so that its not strictly required to craft and understand everything.

This article (and several that follow) explain his ideas better than this out of context quote.

https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/

[HenryBemis]

The issue is that, (the way I see it happening more and more in the real world): - tests are ran by machines - linters are (being) replaced by machines/SaaS services (so.. machines) - formal verification: yes - SHure, 5 people will review the thousands lines of code written every day, in a variety of languages/systems/stacks/scripts/RPAs/etc. or they will simply check that the machines return "green-a-OK" and ask the release team to push it to production.

The other thing that I have noticed, is that '(misplaced) trust erodes controls'. "hey the code hasn't broke for 6 months, so let's remove ABC and DEF controls", and then boom goes the app (because we used to test integration but 'come on - no need for that).

Now.. this is probably the paranoid (audit/sec) in me, but stuff happens, and history repeats itself.

Also.. Devs are cost center, not a profit center. They are "value enablers" not "value adders". Like everything and everyone else, if something can be replaced with something 'equally effective' and cheaper, it is simply a matter of time.

I feel that companies want to both run for this new gold-rush, while at the same time do it slowly and see if this monster bites (someone else first).

[wat10000]

More to the point, there are people who carefully ensure that those angles are correct, and that all of the angles result in the car’s occupants arriving at their destination instead of turning into a ball of fire. It’s just that this process takes place at design time, not assembly time.

Software the same way. It’s even more automated than auto factories. Assembly is 100% automated. Design is what we get paid to do, and that requires understanding, just like the engineers at Ford need to understand how their cars work.

[tdeck]

You're just not visionary enough to see the potential in vibe-CADing an automobile!

[zelphirkalt]

Seems like the more distanced we get from actual engineering methods, the more fucked up our software and systems become. Not really surprising to be honest. Just look at the web as an example. Almost everyone is just throwing massive frameworks and a hundred libraries as dependencies together and calls it a day. No wait, must apply the uglyfier! OK now call it a day.

[ThrowawayR2]

There's no incentive for engineering methods because there's no liability for software defects. "The software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability." It's long overdue but most people in the software industry don't want liability because it would derail their gravy train.

[fireflash38]

I'd love to blame shitty web apps on outsourcing of computing power to your users... But you'll hear countless stories of devs blowing up their AWS or GCP accounts with bad code or architecture decisions (who cares if this takes a lot of CPU to run, throw another instance at it!) , so maybe it's just a lazy/bad dev thing.

[Hilift]

> That just strikes me as an odd thing to say.

Is it though? It could be interpreted as an acknowledgement. Five years from now, testing will be further improved, yet the same people will be able to take over your iPhone by sending you a text message that you don't have to read. It's like expecting AI to solve the spam email problem, only to learn that it does not.

It's possible to say "we take the security and privacy of our customers seriously" without knowing how the code works. That's the beauty of AI. It legitimizes and normalizes stupid humans without measurably changing the level of human stupidity or the quality or efficiency of the product.

Sold! Sold! Sold!

[bartread]

And except that the factory analogy of software delivery has always been utterly terrible.

If you want to draw parallels between software delivery and automotive delivery then most of what software engineers do would fall into the design and development phases. The bit that doesn’t: the manufacturing phase - I.e., creating lots of copies of the car - is most closely modelled by deployment, or distribution of deliverables (e.g., downloading a piece of software - like an app on your phone - creates a copy of it).

The “manufacturing phase” of software is super thin, even for most basic crud apps, because every application is different, and creating copies is practically free.

The idea that because software goes through a standardised workflow and pipeline over and over and over again as it’s built it’s somehow like a factory is also bullshit. You don’t think engineers and designers follow a standardised process when they develop a new car?

It would be crazy for auto factory workers to check every angle. It is absolutely not crazy for designers and engineers to have a deep understanding of the new car they’re developing.

The difference between auto engineering and software engineering is that in one your final prototype forms the basis for building out manufacturing to create copies of it, whereas in the other your final prototype is the only copy you need and becomes the thing you ship.

(Shipping cadence is irrelevant: it still doesn’t make software delivery a factory.)

This entire line of reasoning is… not really reasoning. It’s utterly vacuous.

[fsloth]

It’s not only vacuous. It’s incompentent by failing to recognize the main value add mechanisms. In software delivery, manufacturing, or both. I’m not sure if Dunning-Krueger model is scientifically valid or not but this would be a very Dunning-Krueger thing to say (high confidence, total incompentence).

[fisf]

> The “manufacturing phase” of software is super thin, even for most basic crud apps, because every application is different, and creating copies is practically free.

This is not true from a manager's perspective (indoctrinated by Taylorism). From a manager's perspective, development is manufacturing, and underlying business process is the blueprint.

[kloop]

> The idea that because software goes through a standardised workflow and pipeline over and over and over again as it’s built it’s somehow like a factory is also bullshit.

I don't think it's bs. The pipeline system is almost exactly like a factory. In fact, the entire system we've created is probably what you get when cost of creating a factory approaches instantaneous and free.

The compilation step really does correspond to the "build" phase in the project lifecycle. We've just completely automated by this point.

What's hard for people to understand is that the bit right before the build phase that takes all the man-hours isn't part of the build phase. This is an understandable mistake, as the build phase in physical projects takes most of the man-hours, but it doesn't make it any more correct.

[shakna]

> You don’t think engineers and designers follow a standardised process when they develop a new car?

Apparently the Cybertruck did not. And that sort of speaks for itself.

[soraminazuki]

It's a reckless stance that should never ever come from a software professional. "Let's develop modern spy^H^H^Hsoftware in the same way as the 737 Max, what could possibly go wrong?"

[majormajor]

One of the reasons outsourcing for software fizzled out some compared to manufacturing is because in a factory you don't have "measuring to make sure every angle is correct" because (a) the manufacturing tools are tested and repeatable already and (b) the heavy lifting of figuring out all the angles was done ahead of time. So it was easy to mechanize and send to wherever the labor was cheapest since the value was in the tools and in the plans.

The vast majority of software, especially since waterfall methods were largely abandoned, has the planning being done at the same time as the "execution". Many edge cases aren't discovered until the programmer says "oh, huh, what about this other case that the specs didn't consider?" And outsourcing then became costly because that feedback loop for the spec-refinement ran really slowly, or not at all. Spend lots of money, find out you got the wrong thing later. So good luck with complex, long-running projects without deeply understanding the system.

Alternately, compare to something more bespoke and manual like building a house, where the tools are less precise and more of the work is done in the field. If you don't make sure all those angles are correct, you're gonna get crappy results.

(The most common answer here seems to be "just tell the agent what was wrong and let it iterate until it fixes it." I think it remains to be seen how well "find out everything that is wrong after all the code is written, and then tell the coding agent(s) to fix all of those" will work in practice. If nothing else, it will require a HUGE shift in manual testing appetite. Maybe all the software engineers turn into QA engineers + deployment engineers.)

[anonzzzies]

> outsourcing for software fizzled out

Any data on that? I see everyone trying to outsource as much as they can. Sure, now it is moving toward AI, but every company I walk into have 10-1000s of FTEs in outsource countries.

I see most fortune 1000 companies here doing some type of agile/planningexecution which is in fact more waterfall. The people here in the west are more management and client facing, the rest is 'thrown over the fence'.

[PicassoCTs]

The lead poisoning of our time, companies getting high on hype-tech, killed off because the "freedom from programmers- no code tools" create gordion project nods.

And all because the MBAs yearn for freedom from dependencies and thus reality.

[captainbland]

That's wild. You can't say this statistical, hyper-generalised system of "AI" is in any way comparable to the outputs of highly specific, highly deterministic machinery. It's like comparing a dice roll to a clock. If anything reviewing engineers now need to "measure the angles" more closely than ever.

[javcasas]

> It would be crazy if in an auto factory people were measuring to make sure every angle is correct

That cannot be any furthest from the truth.

Take a decent enterprise CNC machine (look in youtube, lots of videos) that is based on servos, not the stepper motor amateur machines. That servo-based machine is measuring distances and angles hundreds of times per second, because that is how it works. Your average factory has a bunch of those.

Whoever said that should try getting their head out of their ass at least every other year.

[ignoramous]

> Reed’s statement feels very much like a justification of "if it compiles, ship it!"

Not really. More like, if the fopen works fine, don't bother looking how it does so.

SWE is going to look more like QA. I mean, as a SWE if I use the webrtc library to implement chat and it works almost always but just this once it didn't, it is likely my manager is going to ask me to file a bug and move on.

[InsideOutSanta]

>It would be crazy if in an auto factory people were measuring to make sure every angle is correct

Yeah, but there's still something checking the angles. When an LLM writes code, if it's not the human checking the angles, then nothing is, and you just hope that the angles are correct, and you'll get your answer when you're driving 200 km/h on the Autobahn.

[lifeisstillgood]

>It would be crazy if in an auto factory people were measuring to make sure every angle is correct

They need to read “the code is the design”. When you are cutting the door for the thousandth car, you are past design and into building.

For us building is automatic - take code turn into binary.

The reason we measure the door is we are at the design stage abs you need to make sure everything fits.

[Neil44]

The ultimate irony being that they actually do measure all kinds of things against datum points as the cars move down the line as the earlier you junk a faulty build the less it's cost you.

[elmt35]

To me the biggest difference between a software engineer and an assembly worker is the worker makes cars, the software engineer makes the assembly line.

[agentultra]

It’s almost like he doesn’t know what a programming language is or what a compiler is for.

Agree, this comment makes no sense.

[otikik]

Let them do it. It will naturally explode on their faces. Let Amazon be the early adopters of this trend.

[intended]

The fact that they used the auto industry as an example is funny, because the Toyota way and six sigma came out of that industry.

So you are telling me, your AI code passes a six sigma grade of quality control?

I have a bridge to sell you. No, Bridges!

[lightedman]

"The fact that they used the auto industry as an example is funny, because the Toyota way and six sigma came out of that industry."

It's even funnier when you consider that Toyota has learned how bad of an idea lean manufacturing/6-Sig/5S can be thanks to the pandemic - they're moving away from it in some degrees, now.

[bigfatkitten]

> six sigma came out of that industry

Six Sigma came out of Motorola, who still practice it today.

It was then adopted by the likes of GE, before finding its way into the automotive and many other manufacturing industries.

[skeeter2020]

It's wild to think that someone who purports to be an expert would compare an assembly line to AI, where the first is the ultra-optimization of systems management with human-centric processes thoughtfully layered on top and the latter a non-deterministic black box to everybody. It's almost like they are willfully lying...

[Timpy]

I keep feeling like there's a huge disconnect between the owners/CTOs/managers with how useful they think LLMs _are supposed to be_, vs the people working on the product and how useful they think LLMs _actually are_. The article describes Harper Reed as a "longtime programmer", so maybe he falsifies my theory? From Wikipedia:

>Harper Reed is an American entrepreneur

Ah, that's a more realistic indicator of his biases. Either there's some misunderstanding, or he's incorrect, or he's being dishonest; it's my job to make sure the code that I ship is correct.

[baxtr]

His comment is a reflection of the future Software operating model they’ll have.

[Cthulhu_]

That's a weird / wrong analogy. Software engineers design and program the robots, they don't build the cars.

[discreteevent]

That analogy wouldn't give a person much confidence in the rest of his ability/judgement.

[kamaal]

>>That just strikes me as an odd thing to say.

This is along the same lines as why I don't doubt the syntactical features to break. I assume they work. You have to accept some abstraction work, and build on top of it.

We will reach some point where we will have to assume AI is generating the correct code.

[kriro]

Car factory is a funny example because that's also one of the least likely places you will see AI assisted coding. Safety critical domains are a whole different animal with SysML everywhere and thousand page requirements docs.

[harper]

It was not a strong metaphor! Can't win them all.

You are correct tho. I do think that we are approaching the point of "If it compiles, ship it"

[notyourav]

Agreed. Real world is governed by physics, which tend to work well very well with interpolations, predictability and statistics

[fock]

also software is a factory and the LLM is a workshop building factories. Also I strongly believe that people building factories still do a lot of a) ten people pounding out the metal AND b) measuring to check

[never_inline]

And yet people here keep arguing proper cs education is not important.

Without proper understanding of CS, this is what we get. Lack of rigour.

[ashoeafoot]

Companies with lack of engineering rigor are basically pre filtered customers packaged for a buyout by a company/vc able to afford more rigorous companies structure.

[bgwalter]

Amazing. What has Harper Reed written? Does he have any significant output?

This is frankly the most idiotic statement I have heard about programming yet.

[pchristensen]

This made the rounds recently: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/

That quote really misrepresents his writing.

[GrumpyNl]

In the beginning there was a saying, "nobody cares what your code looks like, as long as it works". We went full circle.