I like the analogy as someone who is a carpenter by trade and have dabbled in creating a few working things over the last years only because of the advancement of LLM code generation.
As a carpenter, you come up with *stuff* from your mind and just make it exist. LLM building feels very similar to how quickly you can from idea to something that works for a given purpose.
I do think a more accurate analogy would be to place the software engineer as the construction superintendent.
The superintendent is jack of all, master of none. They may specialize in plumbing, electrical, hvac, masonry, or carpentry but relies on experts where they lack. They can fix any issue with any of these trades, but only when needed. They know enough to know when something is wrong and needs corrected (and may even be able to correct it themselves), but they are not actively building or laying each wire or stick of wood during construction.
Steering the LLM is closer to this than just carpentry alone, as software consists of many specialties within one building if you will.
cladopa 10 hours ago [-]
Well, the Romans also used Carpenters for building things on Stone, only that wood is much harder to preserve.
In Spain multiple big ferris wells were found in mines and also some parts of machines that were using to pulverise rock. There were machines for hammering the rock using water, made in wood.
The Romans probably used machines for polishing the stone also so it could fit with other stones, as they did everything this way and those machines were done also with wood.
We also know that they had machines for lifting the enormous rocks as we can see the marks that the gripper left, done in wood.
And every arch done in Stone needs to be build first in wood. The romans loved to use the same arch so they could reuse the wood. The romans standardised everything so everything could be reused or mass produced.
doodlebugging 6 hours ago [-]
I like the analogy of the carpenter building the form that the masons used to build the bridge.
I think it is pretty accurate for today's software construction based on a lot of posts here and on other forum threads.
Software programmers today using AI just flesh out the frame of the product that they want to build then they fill that frame with AI slurry, their concrete, and that becomes the new application. There's likely a lot of stuff in there that they didn't need but it serves as structural elements once the slurry sets and the product is ready for use. Some of those elements doom it to failure in the same way that rusty rebar dooms a concrete structure with enough time.
caidan 3 hours ago [-]
These analogies are all hilarious because they are prima facie idiotic. This thing that has never happened before in human history is exactly like this other thing that happened very frequently in human history because of hand wavy thing about tools. Except, that this time, we ARE the tools that are being replaced. The human mind being completely replaced is in fact new under the sun my loves. It’s not the same as a calculator. When was the last time you asked your calculator to run your entire life for you and run your military campaigns and all your businesses and all your legal cases and every last tiny aspect of everyone’s life overnight. Christ we capitulated quickly! Lazy lazy lazy pieces of shit, reads our epitaph.
And yes it’s not entirely true today but the entire field of software engineering changed in the last twelve months. A blink of an eye. In five years, game over, in 10 or 20 good night. It must be so flattering to think you still have a role to play. But you don’t. You ARE the thing that is being replaced. Whether that is good is bad I don’t know but I wouldn’t be surprised to see data center strikes (as in attacks) become much more common very quickly. And they’ve already started. Game this out and the most likely scenario is that we enter mutually assured data center destruction with strategic deterrents against the operation of major data centers which drives them underground into hardened bunkers with independent nuclear power sources. All of which means superpower access to AI and none for the little person at threat of death.
Or maybe I’m just nuts and it really is just like carpenters building frames for cement meaning that masons don’t exist (which I suppose they’d be surprised to find out given that there are apparently 200,000+ in the us alone) and some other muddled half baked wishful thinking nonsense. Calculator compiler etc etc. Look! The heathens are coming! No that smell and dust on the horizon is not the mongol horde my friend, it is of course just a summer breeze like the time that your nephew farted. Ah ok then, no need to worry.
steve-atx-7600 39 minutes ago [-]
I think the analogy works for the near term. I don’t see the point of thinking past that. If I can’t enjoy building things for compensation even if it’s managing AI, and I can’t afford to do so for fun, I don’t see the point of being around as long as I don’t have dependents to take care of. I’ll live without worry - hopefully for a long time - until I’m gone or circumstances do in fact get too bad.
globular-toast 10 hours ago [-]
I like the analogy, even if I find it a bit depressing. However, this caused me pause:
> Instead of the most important question being “how to build this”, or “can we build this”, now the most important question is “what should we build”.
Do people really think software is just a matter of paying for the tokens now? If that were true we should be able to ask for a web browser that is faster, leaner, more secure and more capable than all existing browsers, or otherwise be told why it can't be done. Given that the standards are all written down I shouldn't need to give any further direction. I would have thought AI companies would have tried this before trying something like Navier-Stokes.
za_creature 9 hours ago [-]
Treating code as a low-entropy amorphous blob is a quick way to see bridges collapse.
It works for concrete because its tensile and compressive strengths are well known for a given composition, but for high-entropy products like software you pretty much need to also generate a formal proof to have any assurances.
Which, ignoring the production costs and assuming that the proof is in fact correct, is only ever as good as the specification.
If you were looking for a physical analogy for software development, it's closer to growing crystals than pouring concrete.
dasil003 6 hours ago [-]
That's a good point, and I don't think the author would disagree with your take. "How to build" can refer to many things at once, some which still matter and some which don't. In the case of the analogy it means you're no longer optimizing the micro-structure of cut stones, in favor a homogenous slurry that is quick to produce. Of course the macro decisions still matter. A well-built roman bridge could last centuries (depending on the nature of erosion it was contending with), a concrete/rebar structure cannot. When it comes to computer systems the tradeoffs are just different, for example, how we model, validate and persist data is much much more important than the details of the code that processes it.
I have a slightly different angle on the quoted sentence though. In my mind "what should we build" was always the most important question. Code becoming cheaper to produce just highlights that more than ever. But even before agentic coding, the world was full of software that was not fit for purpose because the people calling the shots lacked some dimension of how to translate a problem statement into a workable system (computerized or otherwise), and built by programmers who were content (or at least complicit) in not probing any of those questions with decision makers.
That's why I don't think AI is inherently bad for software—it at least has the potential to empower those with better judgment since the sheer cost of production can no longer be an excuse for why something makes absolutely no sense from the end-user perspective. There are other, larger risks with AI at a societal level, but I don't think it's inherently bad for software quality.
Rendered at 23:17:08 GMT+0000 (UTC) with Wasmer Edge.
As a carpenter, you come up with *stuff* from your mind and just make it exist. LLM building feels very similar to how quickly you can from idea to something that works for a given purpose.
I do think a more accurate analogy would be to place the software engineer as the construction superintendent.
The superintendent is jack of all, master of none. They may specialize in plumbing, electrical, hvac, masonry, or carpentry but relies on experts where they lack. They can fix any issue with any of these trades, but only when needed. They know enough to know when something is wrong and needs corrected (and may even be able to correct it themselves), but they are not actively building or laying each wire or stick of wood during construction.
Steering the LLM is closer to this than just carpentry alone, as software consists of many specialties within one building if you will.
In Spain multiple big ferris wells were found in mines and also some parts of machines that were using to pulverise rock. There were machines for hammering the rock using water, made in wood.
The Romans probably used machines for polishing the stone also so it could fit with other stones, as they did everything this way and those machines were done also with wood.
We also know that they had machines for lifting the enormous rocks as we can see the marks that the gripper left, done in wood.
And every arch done in Stone needs to be build first in wood. The romans loved to use the same arch so they could reuse the wood. The romans standardised everything so everything could be reused or mass produced.
I think it is pretty accurate for today's software construction based on a lot of posts here and on other forum threads.
Software programmers today using AI just flesh out the frame of the product that they want to build then they fill that frame with AI slurry, their concrete, and that becomes the new application. There's likely a lot of stuff in there that they didn't need but it serves as structural elements once the slurry sets and the product is ready for use. Some of those elements doom it to failure in the same way that rusty rebar dooms a concrete structure with enough time.
> Instead of the most important question being “how to build this”, or “can we build this”, now the most important question is “what should we build”.
Do people really think software is just a matter of paying for the tokens now? If that were true we should be able to ask for a web browser that is faster, leaner, more secure and more capable than all existing browsers, or otherwise be told why it can't be done. Given that the standards are all written down I shouldn't need to give any further direction. I would have thought AI companies would have tried this before trying something like Navier-Stokes.
It works for concrete because its tensile and compressive strengths are well known for a given composition, but for high-entropy products like software you pretty much need to also generate a formal proof to have any assurances.
Which, ignoring the production costs and assuming that the proof is in fact correct, is only ever as good as the specification.
If you were looking for a physical analogy for software development, it's closer to growing crystals than pouring concrete.
I have a slightly different angle on the quoted sentence though. In my mind "what should we build" was always the most important question. Code becoming cheaper to produce just highlights that more than ever. But even before agentic coding, the world was full of software that was not fit for purpose because the people calling the shots lacked some dimension of how to translate a problem statement into a workable system (computerized or otherwise), and built by programmers who were content (or at least complicit) in not probing any of those questions with decision makers.
That's why I don't think AI is inherently bad for software—it at least has the potential to empower those with better judgment since the sheer cost of production can no longer be an excuse for why something makes absolutely no sense from the end-user perspective. There are other, larger risks with AI at a societal level, but I don't think it's inherently bad for software quality.