7 ms·

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

> [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 1y ago
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 1y ago
  They took their time precisely specifying the robot movements so they're always repeatable. Almost like...some sort of carefully crafted code.
  - close04 1y ago
    You misconstrue the analogy. The robot isn’t equivalent to the code in this analogy. It’s the thing that generates the code. The robot operates deterministically, it has a fixed input and a fixed output. This is what makes it reliable. Your “AI coder” is nothing like that. It’s non deterministic on its best day, and it gets everything thrown at it so even more of a coin toss. This seriously undermines any expectation of reliability. The guy’s comparison shows a lack of understanding of either of the systems.
    - nojito 1y ago
      Except the code it creates is deterministic.
      - danparsonson 1y ago
        LLMs almost always operate at least partly stochastically.
        nojito 1y ago
        Of course but the code they generate only operates in one way.
        croon 1y ago
        Who determines if that code operates in the intended way?
      - close04 1y ago
        I don't know what you mean with "the code it creates is deterministic" but the process an LLM uses to generate code based on an input is definitely not entirely deterministic. To put it simply, the chances that an LLM will output the same result every time given the same input is low. The LLM does not operate deterministically, unlike the manufacturing robot who will output the same door panel every single time. Or as ChatGPT put it: > The likelihood of an LLM like ChatGPT generating the exact same code for the same prompt multiple times is generally low.
        33hsiidhkl 1y ago
        For any given seed value, the output of an LLM will be identical- it is deterministic. You can try this at home with Llama.cpp by specifying a seed value when you load a LLM, and then seeing that for a given input the output will always be the same. Of course there may be some exceptions (cosmic ray bit flips). Also, if you are only using online models, you can't set the seed value, plus there are multiple models, so multiple seeds. In summary, LLMs are deterministic.
- mrheosuper 1y ago
  it would be the SA guy, but look like he will also be replaced by a bunch of "vibe coder"
- throwup238 1y ago
  > Who's filling that role in this brave new world? Us? (Yeah, we’re fucked)
  - lukan 1y ago
    In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
    - zelphirkalt 1y ago
      I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
      - fao_ 1y ago
        I mean I already heard comments about myself when I went and RTFM'd "You read manuals?!?" "... Yeah? (pause) Wait, you don't?!?!?"
        vbezhenar 1y ago
        Imagine reading in 2025, when you can just watch tiktok about it! /s
        johnisgood 1y ago
        Pretty much. The hesitancy to read documentation was there long before TikTok and LLMs. "Teach me how to use Linux [but I hate reading documentation]". It infuriated me.
        lukan 1y ago
        To be honest, I do find most manuals (man pages) horrible to quickly get information how to do something and here LLMs do shine for me (as long as they don't mix up version numbers).
        1y ago
- b112 1y ago
  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?
  - noosphr 1y ago
    After putting off learning JS for a decade, I finally bit the bullet since I can talk to an LLM about it while going through the slog of getting a mental model up and running. After a month, I can say that the inmates run that whole ecosystem, from the language spec, to the interpreter, to packaging. And worse, the tools for everyone else have to cater to them. I can see why someone who has never had a stable foundation to build a project on would view vibe coding as a good idea. When you're working in an ecosystem where any project can break at any time because some dependency pushed a breaking minor version bundled with a security fix for a catastrophic exploit, rolling the LLM gacha to see if it can get it working isn't the worst idea.
    - skeeter2020 1y ago
      since you mention JS specifically, I think it's important to seperate that from the framework ecosystem. I'd suspect that most LLMs don't which is part of the problem. I had a similar experience with Python lately, where the LLM-generated code (once I could get it to run) resulted in code that I would generously evaluate as "Excel VBA Macro quality". It does the task - for now - but I didn't learn much about what production-grade python would look like.
    - tanseydavid 1y ago
      Interview with a Senior JS Developer (satire) https://www.youtube.com/watch?v=Uo3cL4nrGOk https://www.youtube.com/watch?v=Uo3cL4nrGOk (you've probably already seen it--everyone else has. But if not, you're in for a treat)
- d0gsg0w00f 1y ago
  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".
  - skeeter2020 1y ago
    Wild times where a task that used to be described as "good at using google" now gets the title of "Engineer". It was bonkers enough when software devs co-opted the title.
    - d0gsg0w00f 1y ago
      I mean, building applications that are maintainable, will fail gracefully, and keeps costs low, has all the same needs as any classic engineering discipline. You could spend just as much time designing a well thought out CLI as it could take to design a bridge or a sewer system. Whether people do, or not, is a different question.
    - bumby 1y ago
      Just wait to you hear what some traditional capital “E” engineers (meaning licensed) think about programmers usurping the title “engineer”. It’s been a joke for decades and decades that “engineer” is used to church up any job, including “domestic engineering” (housekeeping/homemaking).
      - genewitch 1y ago
        Sanitation engineer and custodial engineer are older than I am, as well.
- xeonmc 1y ago
  Cory Doctorow described this cart-before-the-horse arrangement as Reverse Centaurs[0][1] [0] https://pluralistic.net/2022/04/17/revenge-of-the-chickenized-reverse-centaurs/ https://pluralistic.net/2022/04/17/revenge-of-the-chickenize... [1] https://pluralistic.net/2024/08/02/despotism-on-demand/ https://pluralistic.net/2024/08/02/despotism-on-demand/
- nothercastle 1y ago
  Not true anymore, lots of places want to reduce engineering hours and let production eat the cost of defects.
wat10000 1y ago
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 1y ago
  You're just not visionary enough to see the potential in vibe-CADing an automobile!
  - darth_avocado 1y ago
    You just needs an MBA to see that
  - shakna 1y ago
    I see you're familiar with zoo. [0] [0] https://zoo.dev/design-studio https://zoo.dev/design-studio
  - palm-tree 1y ago
    You joke, but there are plenty of companies working on something similar to this, for example: https://www.sw.siemens.com/en-US/technology/generative-design/ https://www.sw.siemens.com/en-US/technology/generative-desig... I haven't touched CAD for a couple of years, but I get the impression that (inevitably) the generative design hype significantly exceeds the current capability.
majormajor 1y ago
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 1y ago
  > 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'.
  - ccppurcell 1y ago
    The point being made here is that the biggest software companies still employ lots of programmers but the biggest manufacturing companies don't employ lots of factory workers. I don't think you need data just think about Microsoft vs General Motors etc etc
bgwalter 1y ago
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 1y ago
  This made the rounds recently: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ That quote really misrepresents his writing.
  - bgwalter 1y ago
    Then one wonders what the agenda of the NYT is here. Does this also misrepresent Willison's writing? And just as the proliferation of factories abroad has made it cheap and easy for entrepreneurs to manufacture physical products, the rise of A.I. is likely to democratize software-making, lowering the cost of building new apps. “If you’re a prototyper, this is a gift from heaven,” Mr. Willison said. “You can knock something out that illustrates the idea.” Why do they cite bloggers who relentlessly push this technology rather than interviewing a representative selection of programmers?
    - soraminazuki 1y ago
      Probably because the author's main focus was about potential change in working conditions and not the veracity of the AI hype. But disappointing nonetheless. To be clear, I'm sure some critical software engineering jobs will be replaced by AI though. Just not in the way that zealots want us to think. From the looks of it right now, AI is far from replacing software engineers in terms of competence. The utter incompetence was in full public display just last week [1]. But none of that will matter to greedy corporate executives, who will prioritize short-term cost savings. They will hop from company to company, personally reaping the benefits while undermining essential systems that users and society rely on with AI slop. That's part of the reason why the C-suites are overhyping the technology. After all, no rich executive has faced consequences for behaving this way. [1]: https://news.ycombinator.com/item?id=44050152 https://news.ycombinator.com/item?id=44050152
agentultra 1y ago
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.
intended 1y ago
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!
- bigfatkitten 1y ago
  > 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.
- lightedman 1y ago
  "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.
  - intended 1y ago
    Technically, Toyota doesn’t use 6sig, and when you say they are moving away from it, what do you mean? Because I would be deeply amused (and shocked) if the Muda, Muri people would be giving up on quality control.
    - generj 1y ago
      Idk about Toyota moving away from Kaizen, but they certainly have moved away from JIT. Toyota pioneered Just In Time (JIT) part inventory which dramatically lowers inventory costs and makes balance sheets look far more attractive. What Toyota realized in 2011 due to the Fukushima disaster however is that this completely fails for computer chips because the pipeline is too long. So they kept JIT for steel, plastic parts etc but for microcontrollers, power supply chips, etc they stockpile large quantities.
  - pitaj 1y ago
bartread 1y ago
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 1y ago
  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).
- shakna 1y ago
  > 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.
- kloop 1y ago
  > 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.
baxtr 1y ago
His comment is a reflection of the future Software operating model they’ll have.
pchristensen 1y ago
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/ https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/
- HenryBemis 1y ago
  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).
  - bckr 1y ago
    > Devs are cost center, not a profit center. They are "value enablers" not "value adders". I don’t understand this and I think it would require breaking my brain in order to. A person pays the company to provide a service. The developers create and maintain (part of) that service.
    - kayodelycaon 1y ago
      It’s pretty simple. Software quality isn’t on spreadsheet. The cost to build it is. The value of the products coming from research and development are not on the spreadsheet everyone is looking at. The cost to develop them is. If it’s not on the spreadsheet, it doesn’t exist to the people who make the decisions about money. They have orders to cut spending and that’s what they’ll do. This may sound utterly insane, but business management is a degree and job. Knowledge about what you are managing is secondary to knowing how to manage. That’s why there is an entire professional class of people who manage the details of a project. They also don’t need to know what they are getting details for. Their job is to make numbers for the managers. At no point does anyone actually care what these numbers mean for the company as a whole. That’s for executives. Many executives just look at spreadsheets to make decisions.
andyferris 1y ago
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 1y ago
  Yes and this is just garden-variety abstraction and toolmaking, which is what programmers have done since the very beginning
- deleted 1y ago
  [deleted]
- lolbert6 1y ago
  works for tesla
  - margalabargala 1y ago
    Depends on your definition of "works". Do they YOLO the angles of tools and then produce 10,000 misshapen cars? Yes. But do they also sell those cars? Impressively, also yes, at least up until a couple months ago. Prior to Elon's political shenanigans of the last few months consumers were remarkably tolerant of Tesla's QC issues.
- p_v_doom 1y ago
  > 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).
brundolf 1y ago
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 1y ago
  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_ 1y ago
  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.
  - fhd2 1y ago
    Worse: If typing in code takes more time (i.e. costs more), there's a larger incentive to refactor. I spent quite a bit of time as a CTO, and at some point there's a conversation about the business value of refactoring. That's a great conversation to have I think, it should ultimately be about business value, but good code vs bad code is a bit hard to quantify. What I usually reached for is that refactoring brings down lead time of changes, i.e. makes them faster. Tougher story these days I guess :D
kamaal 1y ago
>>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.
PicassoCTs 1y ago
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.
GrumpyNl 1y ago
In the beginning there was a saying, "nobody cares what your code looks like, as long as it works". We went full circle.
soraminazuki 1y ago
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?"
elmt35 1y ago
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.
fock 1y ago
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
Cthulhu_ 1y ago
That's a weird / wrong analogy. Software engineers design and program the robots, they don't build the cars.
- discreteevent 1y ago
  That analogy wouldn't give a person much confidence in the rest of his ability/judgement.
captainbland 1y ago
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.
namaria 1y ago
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.
zelphirkalt 1y ago
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.
- fireflash38 1y ago
  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.
- ThrowawayR2 1y ago
  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.
never_inline 1y ago
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 1y ago
  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.
otikik 1y ago
Let them do it. It will naturally explode on their faces. Let Amazon be the early adopters of this trend.
RossBencina 1y ago
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.
- red_admiral 1y ago
  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.
  - rightbyte 1y ago
    THERAC was terrible. And intermittent to for extra horror. I am a strong proponent of hardware level interlocks for way more mundane things than that. It helps a lot in debugging to narrow down the possible states of things.
- jasonwatkinspdx 1y ago
  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.
Neil44 1y ago
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.
red_admiral 1y ago
> 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.
ignoramous 1y ago
> 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.
bumby 1y ago
>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 1y ago
  > 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.
deleted 1y ago
[deleted]
lifeisstillgood 1y ago
>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.
kriro 1y ago
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.
notyourav 1y ago
Agreed. Real world is governed by physics, which tend to work well very well with interpolations, predictability and statistics
Hilift 1y ago
> 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!
InsideOutSanta 1y ago
>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.
javcasas 1y ago
> 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.
skeeter2020 1y ago
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 1y ago
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.
deleted 1y ago
[deleted]
harper 1y ago
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"

lolinder 1y ago

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 1y ago
They took their time precisely specifying the robot movements so they're always repeatable. Almost like...some sort of carefully crafted code.
- close04 1y ago
  You misconstrue the analogy. The robot isn’t equivalent to the code in this analogy. It’s the thing that generates the code. The robot operates deterministically, it has a fixed input and a fixed output. This is what makes it reliable. Your “AI coder” is nothing like that. It’s non deterministic on its best day, and it gets everything thrown at it so even more of a coin toss. This seriously undermines any expectation of reliability. The guy’s comparison shows a lack of understanding of either of the systems.
  - nojito 1y ago
    Except the code it creates is deterministic.
    - danparsonson 1y ago
      LLMs almost always operate at least partly stochastically.
      - nojito 1y ago
        Of course but the code they generate only operates in one way.
        croon 1y ago
        Who determines if that code operates in the intended way?
    - close04 1y ago
      I don't know what you mean with "the code it creates is deterministic" but the process an LLM uses to generate code based on an input is definitely not entirely deterministic. To put it simply, the chances that an LLM will output the same result every time given the same input is low. The LLM does not operate deterministically, unlike the manufacturing robot who will output the same door panel every single time. Or as ChatGPT put it: > The likelihood of an LLM like ChatGPT generating the exact same code for the same prompt multiple times is generally low.
      - 33hsiidhkl 1y ago
        For any given seed value, the output of an LLM will be identical- it is deterministic. You can try this at home with Llama.cpp by specifying a seed value when you load a LLM, and then seeing that for a given input the output will always be the same. Of course there may be some exceptions (cosmic ray bit flips). Also, if you are only using online models, you can't set the seed value, plus there are multiple models, so multiple seeds. In summary, LLMs are deterministic.
mrheosuper 1y ago
it would be the SA guy, but look like he will also be replaced by a bunch of "vibe coder"
throwup238 1y ago
> Who's filling that role in this brave new world? Us? (Yeah, we’re fucked)
- lukan 1y ago
  In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
  - zelphirkalt 1y ago
    I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
    - fao_ 1y ago
      I mean I already heard comments about myself when I went and RTFM'd "You read manuals?!?" "... Yeah? (pause) Wait, you don't?!?!?"
      - vbezhenar 1y ago
        Imagine reading in 2025, when you can just watch tiktok about it! /s
        johnisgood 1y ago
        Pretty much. The hesitancy to read documentation was there long before TikTok and LLMs. "Teach me how to use Linux [but I hate reading documentation]". It infuriated me.
      - lukan 1y ago
        To be honest, I do find most manuals (man pages) horrible to quickly get information how to do something and here LLMs do shine for me (as long as they don't mix up version numbers).
        1y ago
b112 1y ago
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?
- noosphr 1y ago
  After putting off learning JS for a decade, I finally bit the bullet since I can talk to an LLM about it while going through the slog of getting a mental model up and running. After a month, I can say that the inmates run that whole ecosystem, from the language spec, to the interpreter, to packaging. And worse, the tools for everyone else have to cater to them. I can see why someone who has never had a stable foundation to build a project on would view vibe coding as a good idea. When you're working in an ecosystem where any project can break at any time because some dependency pushed a breaking minor version bundled with a security fix for a catastrophic exploit, rolling the LLM gacha to see if it can get it working isn't the worst idea.
  - skeeter2020 1y ago
    since you mention JS specifically, I think it's important to seperate that from the framework ecosystem. I'd suspect that most LLMs don't which is part of the problem. I had a similar experience with Python lately, where the LLM-generated code (once I could get it to run) resulted in code that I would generously evaluate as "Excel VBA Macro quality". It does the task - for now - but I didn't learn much about what production-grade python would look like.
  - tanseydavid 1y ago
    Interview with a Senior JS Developer (satire) https://www.youtube.com/watch?v=Uo3cL4nrGOk https://www.youtube.com/watch?v=Uo3cL4nrGOk (you've probably already seen it--everyone else has. But if not, you're in for a treat)
d0gsg0w00f 1y ago
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".
- skeeter2020 1y ago
  Wild times where a task that used to be described as "good at using google" now gets the title of "Engineer". It was bonkers enough when software devs co-opted the title.
  - d0gsg0w00f 1y ago
    I mean, building applications that are maintainable, will fail gracefully, and keeps costs low, has all the same needs as any classic engineering discipline. You could spend just as much time designing a well thought out CLI as it could take to design a bridge or a sewer system. Whether people do, or not, is a different question.
  - bumby 1y ago
    Just wait to you hear what some traditional capital “E” engineers (meaning licensed) think about programmers usurping the title “engineer”. It’s been a joke for decades and decades that “engineer” is used to church up any job, including “domestic engineering” (housekeeping/homemaking).
    - genewitch 1y ago
      Sanitation engineer and custodial engineer are older than I am, as well.
xeonmc 1y ago
Cory Doctorow described this cart-before-the-horse arrangement as Reverse Centaurs[0][1] [0] https://pluralistic.net/2022/04/17/revenge-of-the-chickenized-reverse-centaurs/ https://pluralistic.net/2022/04/17/revenge-of-the-chickenize... [1] https://pluralistic.net/2024/08/02/despotism-on-demand/ https://pluralistic.net/2024/08/02/despotism-on-demand/
nothercastle 1y ago
Not true anymore, lots of places want to reduce engineering hours and let production eat the cost of defects.

wat10000 1y ago

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 1y ago
You're just not visionary enough to see the potential in vibe-CADing an automobile!
- darth_avocado 1y ago
  You just needs an MBA to see that
- shakna 1y ago
  I see you're familiar with zoo. [0] [0] https://zoo.dev/design-studio https://zoo.dev/design-studio
- palm-tree 1y ago
  You joke, but there are plenty of companies working on something similar to this, for example: https://www.sw.siemens.com/en-US/technology/generative-design/ https://www.sw.siemens.com/en-US/technology/generative-desig... I haven't touched CAD for a couple of years, but I get the impression that (inevitably) the generative design hype significantly exceeds the current capability.

majormajor 1y ago

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 1y ago
> 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'.
- ccppurcell 1y ago
  The point being made here is that the biggest software companies still employ lots of programmers but the biggest manufacturing companies don't employ lots of factory workers. I don't think you need data just think about Microsoft vs General Motors etc etc

bgwalter 1y ago

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 1y ago
This made the rounds recently: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ That quote really misrepresents his writing.
- bgwalter 1y ago
  Then one wonders what the agenda of the NYT is here. Does this also misrepresent Willison's writing? And just as the proliferation of factories abroad has made it cheap and easy for entrepreneurs to manufacture physical products, the rise of A.I. is likely to democratize software-making, lowering the cost of building new apps. “If you’re a prototyper, this is a gift from heaven,” Mr. Willison said. “You can knock something out that illustrates the idea.” Why do they cite bloggers who relentlessly push this technology rather than interviewing a representative selection of programmers?
  - soraminazuki 1y ago
    Probably because the author's main focus was about potential change in working conditions and not the veracity of the AI hype. But disappointing nonetheless. To be clear, I'm sure some critical software engineering jobs will be replaced by AI though. Just not in the way that zealots want us to think. From the looks of it right now, AI is far from replacing software engineers in terms of competence. The utter incompetence was in full public display just last week [1]. But none of that will matter to greedy corporate executives, who will prioritize short-term cost savings. They will hop from company to company, personally reaping the benefits while undermining essential systems that users and society rely on with AI slop. That's part of the reason why the C-suites are overhyping the technology. After all, no rich executive has faced consequences for behaving this way. [1]: https://news.ycombinator.com/item?id=44050152 https://news.ycombinator.com/item?id=44050152

agentultra 1y ago

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.

intended 1y ago

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!

bigfatkitten 1y ago
> 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.
lightedman 1y ago
"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.
- intended 1y ago
  Technically, Toyota doesn’t use 6sig, and when you say they are moving away from it, what do you mean? Because I would be deeply amused (and shocked) if the Muda, Muri people would be giving up on quality control.
  - generj 1y ago
    Idk about Toyota moving away from Kaizen, but they certainly have moved away from JIT. Toyota pioneered Just In Time (JIT) part inventory which dramatically lowers inventory costs and makes balance sheets look far more attractive. What Toyota realized in 2011 due to the Fukushima disaster however is that this completely fails for computer chips because the pipeline is too long. So they kept JIT for steel, plastic parts etc but for microcontrollers, power supply chips, etc they stockpile large quantities.
- pitaj 1y ago

bartread 1y ago

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 1y ago
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).
shakna 1y ago
> 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.
kloop 1y ago
> 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.

baxtr 1y ago

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

pchristensen 1y ago

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/ https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/

HenryBemis 1y ago
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).
- bckr 1y ago
  > Devs are cost center, not a profit center. They are "value enablers" not "value adders". I don’t understand this and I think it would require breaking my brain in order to. A person pays the company to provide a service. The developers create and maintain (part of) that service.
  - kayodelycaon 1y ago
    It’s pretty simple. Software quality isn’t on spreadsheet. The cost to build it is. The value of the products coming from research and development are not on the spreadsheet everyone is looking at. The cost to develop them is. If it’s not on the spreadsheet, it doesn’t exist to the people who make the decisions about money. They have orders to cut spending and that’s what they’ll do. This may sound utterly insane, but business management is a degree and job. Knowledge about what you are managing is secondary to knowing how to manage. That’s why there is an entire professional class of people who manage the details of a project. They also don’t need to know what they are getting details for. Their job is to make numbers for the managers. At no point does anyone actually care what these numbers mean for the company as a whole. That’s for executives. Many executives just look at spreadsheets to make decisions.

andyferris 1y ago

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 1y ago
Yes and this is just garden-variety abstraction and toolmaking, which is what programmers have done since the very beginning
deleted 1y ago
[deleted]
lolbert6 1y ago
works for tesla
- margalabargala 1y ago
  Depends on your definition of "works". Do they YOLO the angles of tools and then produce 10,000 misshapen cars? Yes. But do they also sell those cars? Impressively, also yes, at least up until a couple months ago. Prior to Elon's political shenanigans of the last few months consumers were remarkably tolerant of Tesla's QC issues.
p_v_doom 1y ago
> 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).

brundolf 1y ago

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 1y ago
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_ 1y ago
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.
- fhd2 1y ago
  Worse: If typing in code takes more time (i.e. costs more), there's a larger incentive to refactor. I spent quite a bit of time as a CTO, and at some point there's a conversation about the business value of refactoring. That's a great conversation to have I think, it should ultimately be about business value, but good code vs bad code is a bit hard to quantify. What I usually reached for is that refactoring brings down lead time of changes, i.e. makes them faster. Tougher story these days I guess :D

kamaal 1y ago

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

PicassoCTs 1y ago

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.

GrumpyNl 1y ago

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

soraminazuki 1y ago

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?"

elmt35 1y ago

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.

fock 1y ago

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

Cthulhu_ 1y ago

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

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

captainbland 1y ago

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.

namaria 1y ago

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.

zelphirkalt 1y ago

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.

fireflash38 1y ago
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.
ThrowawayR2 1y ago
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.

never_inline 1y ago

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 1y ago
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.

otikik 1y ago

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

RossBencina 1y ago

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.

red_admiral 1y ago
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.
- rightbyte 1y ago
  THERAC was terrible. And intermittent to for extra horror. I am a strong proponent of hardware level interlocks for way more mundane things than that. It helps a lot in debugging to narrow down the possible states of things.
jasonwatkinspdx 1y ago
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.

Neil44 1y ago

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.

red_admiral 1y ago

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

ignoramous 1y ago

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

bumby 1y ago

>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 1y ago
> 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.

deleted 1y ago

[deleted]

lifeisstillgood 1y ago

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

kriro 1y ago

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.

notyourav 1y ago

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

Hilift 1y ago

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

InsideOutSanta 1y ago

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

javcasas 1y ago

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

skeeter2020 1y ago

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 1y ago

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.

deleted 1y ago

[deleted]

harper 1y ago

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"