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, 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.
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.
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, even if I find it a bit depressing. However, this caused me pause:
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.
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.