Posted by azhenley 5 days ago
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.
> 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.
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.
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.