From Stonemasons to Carpenters
Thread
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
From Stonemasons to Carpenters
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
smalltorch · · focus · HN ↗
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 · · focus · HN ↗
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.
globular-toast · · focus · HN ↗
> 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 · · focus · HN ↗
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 · · focus · HN ↗
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.
doodlebugging · · focus · HN ↗
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 · · focus · HN ↗
steve-atx-7600 · · focus · HN ↗