Engineers will do anything to avoid learning from history
horn.gg
horn.gg
This is pretty much the crux of it. It's very similar to the strategy of undercutting a market with VC subsidies until it dies and can be replaced.
FOMO is going to kill more americans than COVID.
LOL gotta put that on my resume
Managing agents has some similarities with EM and program management but a whole lot of other dimensions like token use, avoiding drift, successful concurrency at scale, variations in prompting, testing, evaluation, etc., not to mention that the agents are hyperintelligent coders with zero common sense and a penchant for extremely literal interpretation and ultra-verbosity.
That’s why predicting the future is really really hard.
Ultra-verbosity, okay you got me, humans don’t do that. They do over complexity though, when it makes them feel smart.
You can't not reinvent something if you don't know it exists in the first place.
The thing about software is that it slots nicely into every other field, making it a _very_ good base to work off of to get concepts (aka the modern bootleg polymath) that have likely been invented in other fields (with different names).
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.
What? One of the first principles in doing Lean and Agile correctly is limiting Work in Progress and avoiding context switching whenever possible.
Everywhere I've worked claims to be doing Agile, but none of them have ever done anything to avoid context switching or limiting work in progress
meanwhile the business runs on quarterly projects that have to be done by a certain marketing date, so its usually scrum + waterfall over and over
I'm thinking some people are approaching agentic development in the same manner, splitting work up across agents too aggressively, giving each agent new context/upfront plans, when the one session could have done the whole problem in the one context window.
The model output is fairly uniform because the models are fairly uniform, but the input is how I understand the prompter’s theory of mind for the LLM.
The higher fidelity the theory of mind, the more productive the resulting conversation is. Basic things, like knowing what the model is even aware of.
It’s okay at subjective product judgements with limited context, and so the best engineers make the most important decisions themselves, constraining the model’s solution space to something looking like success.
Maintaining consistent progress towards a common goal with a bunch of different perspectives is the job.
edit: this doesn't invalidate the OP thesis, which I strongly agree with. Except that it's not just engineers, this is a more general thing across many fields.
Formlabs recently launched a $80K industrial-grade machine that works better than it's $500K alternatives.
https://formlabs.com/blog/announcing-fuse-x1-industrial-sls/ https://formlabs.com/blog/diy-injection-molding/ https://www.youtube.com/watch?v=0TvjUVdn3YQ&t=2586s
Formlabs is used by Tesla to print car parts to Ukraine to print drones.
The thing about SLS is that it works with metal too. So you have startups like Divergent (recently raised $290M) in LA printing car engines https://www.latimes.com/b2b/space-tech/story/2026-06-23/dive...
Note that rocket engines are 3d printed too from SpaceX to India's Sky Roots https://www.selfcad.com/blog/how-spacex-uses-additive-manufa... https://3dprintingindustry.com/news/skyroots-vikram-1-reache...
So is injection molding more effective than additive manufacturing? This question is a bit like "no more interesting than the question of whether a submarine can swim".
But while you have metal at industrial scale you have "desktop" metal printers for ~$10K https://all3dp.com/4/first-look-at-the-scrap-1-desktop-metal...
For a certain aircraft part that I designed, that measured approximately 16"x8"x10", if you needed up to 12 of them it was cheapest to 3D print them using powerbed fusion from AlSi10Mg, but with a 25% weight penalty due to the lower mechanical properties of 3D printed aluminum compared to cast. If you needed between 12 and 50 of them, it was cheapest to use 3D printing to make a wax preform then use the preform to make a traditional metal investment casting from A356. For more than 50 of them, it was cheapest to invest in permanent closed die tooling.
Other than for prototyping and extremely low volume production, additive has been a total flop for real-world manufacturing, and has not at all lived up to any of it's lofty promises.
I’m thinking of say cooling channels built into walls of rocket combustion chambers, or car brake/axle assemblies, and some of the „organic“ designs that are lighter and stronger than a cast/machined part.
What I'm seeing is that companies like Formlabs (plastics) and divergent (metal) are changing the game and you have car parts to car engines to rocket engines being 3d printed.
See my other comment above for more links, but things seem to be changing fast in manufacturing.
Edit:
I think this quote sums the point though:
“With the increased throughput and decreased costs, Fuse X1 has completely changed our perspective on what kinds of projects our lab can support versus what we would have traditionally moved to an injection mold.” Cody Jepsen, Engineering Technician, Additive Manufacturing at Tesla Giga NV
30+ years ago, You had to be a -lot- more careful about how you handled releasing software. Your stuff was in boxes on shelves, most people didn't have internet access to 'download an update' so fixing anything had a long tail support cost (i.e. paying for the media containing the fix and shipping).
But there's a fine line. As an example, If your shop is having a vendor do brand new stuff, -compartmentalized from your other stuff-, using technologies that are actually out of support vs an in-support version is a free/zero effort update versus using the outdated stuff... Something went wrong on the management side.
Have you ever heard of an SLA? This "used to be" story about software has never been true. If you can't meet the agreement, then or now, you're done.
Software has always been a lot more diverse than just consumer goods. Why is that your only evidence of how you think software projects are managed?
I will admit, My judgement of 'non-consumer-software' is somewhat based on my corporate experience, where either:
- The contract with the vendor writing/providing software to the company is written so poorly that absolutely counter-intuitive decisions are made to try to steer the ship at the last moment, because the contract was written so bad there is no support
- For SaaS-ish offerings, the company would have some guy in a corner fixing the bugs in the data within the SLA, not necessarily fixing the actual bug causing the problem.
- You're lucky enough to be at a shop where the requirements are handled well enough that, yes, to your point, You have SLAs and things get fixed or there are penalties involved.
I will however stand by my original point; Before the days of the Internet and automatic updates (let alone 'SaaS web apps',) shipping an update could still be very expensive from a cost perspective.
How many updates did one apply to Windows 3.0 and Word in those days??
Sure, there might have been a “hotfix” available for download over a long distance BBS, but virtually nobody would have ever done so (even if they were lucky enough to have a modem). Maybe large companies applied such when impacted.
Even in the Windows XP days, I think windowsupdate.com was still a manually triggered process…
For a while, bundled drivers were a steaming pile of crap in quality and several generations of Windows suffered greatly until Microsoft got vendors in line and updates became common.
This is because the we have these periodic influxes of scammers into the IT the industry, with their empty promises and trust me bro culture.
Ha! I studied computer science and became a programmer because I knew I was too dumb for med. school and the other engineering paths.
So I think it sounds more than actual people who would be happy to be called software developers.
[1] https://www.hillelwayne.com/post/are-we-really-engineers/
I'm curious about this. I thought investors preferred safe bets?
On the other hand, I know that if you're too early, it can be impossible to make a business work (or even to pitch the idea in the first place).
Related: You can't tell people anything (2004)
https://web.archive.org/web/20091025030730/https://habitatch...
> One final point: I expect none of you to really get what I’m talking about here, because this principle also applies to itself. But I fully expect I’ll get the occasional email saying “Oh! so that’s what you meant.” or “Why didn’t you tell me that?” I did, but you can’t tell people anything.
Watch mechanical engineers design plastic rubbish.
Watch some electronic engineers design circuits that don't work.
Watch some geotech engineers make up overspecified bullshit: because they're paid per hour and their work is often just a glorified tickbox (where they have no real consequences for most of their failure risk).
Even with egregious design failures by engineers, they often get away with it for a variety of reasons. A building collapsed due to the Christchurch earthquakes - failures by different engineers with little harm to them.
What do you base this on? In my country, engineers are legally responsible for their designs.
Did the engineers have their certification revoked? Did the engineers go to jail for criminal negligence?
I found a couple of examples and counter-examples in European countries.
I'm no wonk, but too often major failures have seemingly small consequences.
Supposedly is heavily stressed, the Royal Commission investigating found a lack of communication between the official structural design engineers (Alan Reay Consultants), the actual engineer employed for the design (David Harding) and somewhat more critically the "engineer" on the ground implementing the building's construction (Gerald Shirtcliff).
Gerald Shirtcliff had faked his engineering degree.
Despite all this the building passed inspection and stood for 25 years, passing two additional inspections in 2010 (a year prior to collapse) after two separate earthquakes.
> they often get away with it for a variety of reasons.
The documents show police wanted to charge Harding and Reay with manslaughter. Christchurch Crown Solicitor Mark Zarifeh believed the evidential sufficiency test was met by expert evidence from engineering firm Beca.
Deputy Solicitor-General Brendan Horsley disagreed.
Horsley said for charges of negligent manslaughter, the Crown had to prove the conduct was so bad it deserved to be condemned as a serious crime. It would be difficult to show the conduct was one of the main causes of the deaths.
"A key difficulty for the prosecution would be in proving the CTV building would not have collapsed in the absence of the identified design errors," he said.
Another obstacle was the length of time between the design and when the deaths occurred.
That's the dot point overview, and FWiW the actual design engineers got professional black marks on their careers and the case is still heavily studied in formal civil engineering courses.
* https://en.wikipedia.org/wiki/CTV_Building
* https://www.stuff.co.nz/national/99399561/police-will-not-pr...
Exactly: certifications were irrelevant and toothless. Unfortunately so were the laws.
Similarly in the UK no individuals or engineers have been formally charged or convicted for any offenses relating to the Grenfell Tower fire. The causes were distributed more widely in that situation.
We need heavy criminal penalties for managers and other responsible people that are irresponsible.
And the corporations should not be able to hide behind limited liability. Additionally I suspect NZ lacks a good legal framework for chasing civil liabilities.
The bigger pattern is that organisations have systemic safety flaws, so instead they want to blame their frontline staff: pilots, teachers, engineers. Every time.
If the strongest incentives result in unsafe decisions, then the incentive to not sign-off will fail (because it won't trump the other incentives).
And professional indemnity insurance undermines some negative incentives.
Certificates are for the patsies. And certifications don't work across borders.
The consequences of criminal decisions are not nearly as bad as they should be.
Basically, within NZ certifications just don't seem to have the effects we imagine they should. Unfortunately the fix should be criminal negligence laws, but they seem to fail for other less obvious reasons some of which you mention (my further guess is that negligence would tar too many people involved including politicians, so every incidental person is keen to avoid doing the right thing).
Idealists believe in civil certifications. Realists believe in a criminal code.
Criminal negligence laws should also be able to deal with deadly software (although perhaps Facebook is too nebulous).
.. but the legal system felt it would be impossible to prove that the building was not built to the code that it should have been - a code that was likely insufficient in the face of the forces of the earthquake of 2011.
> You speak to me of perfection, but is there really any such thing? Or is it a siren, leading us astray. I happily predict that neither of us will ever summit that elusive peak, but I care little, as long as we walk together. Art gives us the perception of control. For a moment, as I paint, I find order among the chaos. That is, for me, a moment of pure contentment. And that is truly better than perfection.
The current world conceptions of engineers are that they're the negative ones, the naysayers.
Also what I learned back then was that accounting was invented for the same purpose the blockchain: to make fraud in the workplace very hard.
I remember engineers reinvent geospatial technologies, avoiding such thing as map projections, and in the end still came to them.
"We used to just call this stuff chemistry; but citations and funding didn't really take off until we started calling it nanotechnology."
> Working with AI feels more like leadership than coding
Matches my experience. Like 90% of the work is the spec.
Except instead of weeks researching its like a few hours talking with an agent.
Sometimes two or more developers may appear to coexist, but it's actually a simulated concurrency achieved by rapid context switching
Every time you close a file to open another, you are setting up a different context, therefore you are different agents.
Lawyers are informed by ancient case law and bankers leverage trade instruments with roots in medieval Italy. Why is the software profession so exceptional that replacing hundreds of years of engineering wisdom with blog posts on agentic workflows is considered best practice?
> We even reinvented bus stops.
Unless I am mistaken, buses do not descend in a lift and travel underground. It's pure fantasy of course, but no we didn't somehow forget buses exist and reinvent bus stops.
But TFA is ignoring the actual engineering side where you have to grapple with some primitives and assemble them in a way that do something valuable. And so in a way that is cost effective. That part is always answered by hand waves.
Or are people really just yoloing and not even verifying that the code generation is correct? I know it’s a bit of a meme, but are people actually doing the meme in irl where there are actual consequences??
You go to a 4 year Engineering school, get an actual Engineering degree. Then you apprentice with an Engineering company, and study for the state's license examination, one of the hardest tests you'll ever take. If you pass, then and only then are you an Engineer.
Real engineering is nothing like the slop portrayed in this article.
Engineering schools showcase failures of the past as a teaching tool. I still remember learning about the bridge that shook itself apart during my freshman year. Engineers value safety margins and failure analysis.
Engineers DO learn from history.
The post laments that it's hard to find Dr. Royce's original waterfall paper. That's probably true, I have my copy from a compilation book “Ideas that Created the Future: Classic Papers of Computer Science” edited by Lewis [1].
I do agree that it's important to do things like scope out your demands of your AI agent, check-in on progress, give as clear a requirement and test cases as you can. But you've always been able to do that with agile methods, and LLMs are fast enough that you don't need to go full waterfall (and if anything it would be counter productive).
Dr. Royce's paper talks about literally thousands of pages of documentation being needed for any reasonably useful system. Good luck fitting that into even a 1M context window :P.
But the main point to thesis, that you can't just let your coders loose to do whatever and expect the right results even pre-dates Fred Brooks. I'd argue it goes all the way back to the beginning, to the comments about Baggage's computing machine where British politicians asked if it would generate the correct answers even with incorrect inputs.
The answer then is the same answer today: of course not, and expecting anything different is foolishness.
That's front and centre as a concern in Food, Chemical, Civil, Electrical, Mechanical etc. engineering disciplines.
But the article has a big irony: the article accuses engineers of oversimplifying other disciplines and then does exactly that itself.
> "Data science was statistics with a cooler name"
The author mentions David Donoho's "50 Years of Data Science" but that work presents a much more complicated concept of data science: one with data exploration, transformation, computing, visualization, modeling, etc. Even the study of data-analysis practice itself.
Look at that XKCD he posted with it.
Horn took a nuance argument and converted it into the "human slop" formula mocked in the XKCD:
complicated subject = simple thing I already understand <new complicated thing> is really just <old familiar thing>
The cartoon is criticizing the same operation the article is doing. Maybe that is the joke?