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.

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.

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.

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.