You need strong guys to move things around because you don't have a pneumatic crane.
Now you have pneumatic crane, you can move stacks and stacks of things around with ease. You need less strong guys around and instead there is a new need for fewer people that are well-trained on how to operate this pneumatic crane safely. You'll get more work done with less people.
That's what's happening with software engineering and LLM copilots; it's an industrialization of coding. You don't need 20 engineers to get that product out. You need a few that are really good operators of the machinery. Adept at prompting and reviewing code instead of writing code.
If there's one thing employers hate more than unskilled labor, it's skilled labor.
Oh, now instead of ten unskilled laborers carrying shit, each being paid $N, you can have one crane operator getting paid $5N? Wait, why can't we pay him $N? What do you mean, if he fucks up it costs us millions? What do you mean, his skill or lack thereof can double or halve the time it takes to move shit around? Ok, what if we pay him $1.1N?
That's a fantastic insight. There's a popular metaphor comparing software developers to blacksmiths, emphasizing the craft and trade aspects of the profession. Historically, blacksmiths were largely automated out of existence, replaced by highly skilled metallurgists and industrial automation engineers, albeit in much smaller numbers. As we look toward the future, we must consider what the equivalents for software development might be.
Yes, I think the blacksmith metaphor is also an excellent one because a single die stamping machine can produce thousands (if not tens or hundreds of thousands) of times the same output as a single blacksmith.
You still need people, but you need them to: 1) operate and maintain the machine, 2) check for quality, 3) do some fine, detailed work, 4) do the things that the machine is not good at. The skillsets are just different now and you need less people while producing significantly more output.
Whereas a 4'10", 100lb woman probably wouldn't have been a productive blacksmith, she can be adept at building fine metal parts with the industrial tools.
The problem with this analogy is that the hard part of writing software isn’t about bulk jobs that are easily specified with cut and dried success criteria. It’s about designing and implementing things where many tiny details matter and are connected to real world outcomes in ways that can not be fully deduced from the symbols present in code. If you get these things subtly wrong than programming is net negative because you now have more mess to wade through than if you were starting from scratch. LLMs in the hands of weak engineers will actually be net negative. I do think jobs will be lost because there are currently a lot of net negative programmers out there simply because knowing syntax and algorithms has historically been enough to get a lot of jobs even if higher level systemic thinking and communication is lacking. That will cause a reduction in overall numbers, but I would argue that was already an existing inefficiency and it will be interesting to see how much it impacts the big picture as ultimately we still need people to understand and debug all the biz critical code out there.
I think you're still thinking about it wrong. Once you have a hydraulic press that can stamp 600 copies of some die per hour, you are no longer hiring for blacksmiths. You're hiring for someone that knows how to operate the machine safely and maintain it as well as verify the quality of the output.
If you have a press that can produce 600 copies of some die and you are hiring a blacksmith, you're probably not going to get good results.
I'm not "thinking about it wrong", I'm saying that I don't like the analogy. Of course all analogies are imperfect, and I get that LLMs greatly accelerate the production of code, but here's the gap: code is not the product. Code is the instruction for the actual machines, and crucially, code is already repeatable and replicable.
In the software world a blacksmith is analogous someone crunching numbers in a spreadsheet. Programmers (combined with hardware engineers) are the ones that are creating the hydraulic presses. LLMs are analogous to CAD, a better tool-building tool to be sure, but at the end of the day if you're stamping out code in a way that an LLM can do it reliably, then you already have a problem that was automatable without an LLM, which code can already do.
>Adept at prompting and reviewing code instead of writing code.
Don't you need to write your own fair share of code (especially bad code) to judge what gets shipped? LLMs solve the problem of "producing code," but I don't think it necessary follows that LLMs solve the more important problem of "delivering value."
If you're Organization X and are in partnership with Organization Y to produce an integrated solution, an LLM might know how to call some bespoke API between the orgs. But you probably need to have skilled humans to know those APIs' inevitable weirdnesses: unintentional rate limits, resource-constraint edge cases, race conditions, etc.
> Don't you need to write your own fair share of code
Do you need to be good at playing football to be a coach? (Andy Reid)
Do you need to be good at making films to be a good critic of films? (Roger Ebert)
Do you need to be a great chef to be a Michelin reviewer or food critic?
Do you need to be a great singer to be a good judge of musical talent? (Simon Cowell)
I think you can tell if some output is "good" without being expert at the doing part. You need to understand the domain, the inputs, the outputs, the range, but not necessarily be expert at the doing part.
In fact, many, many more of us can tell "this book is good", but relatively few of us could write a very good novel. We have a sense that "this show or movie is entertaining", but few of us could produce one!
One of the teams I worked with, our support engineer was extremely adept at reading code. He would trace defect reports to the lines of code and write excellent tickets that deeply understood the root cause of the error because he had a good conceptual model of the design and he was skilled at reading code. However, when it came to fixing the error, he had no clue!
Good point, but maybe a little incomplete. Can you read a contract and tell whether the courts will accept it? No, you need a lawyer for that. Can you look at a bridge or dam and tell how long it will last and under what loads? No, you need an engineer for that. You can, of course, wait for a court to rule on a challenge to a contract and judge how well it was written that way, but by then it's too late, and you've wasted money. Programming can be like that too. You judge a program by throwing it in front of users and accepting the financial (or, worse, human) consequences, but usually it's more economical to hire someone who knows what they're doing.
> Can you read a contract and tell whether the courts will accept it
Of course you can, if you understand the law. It's the same with professional sports; a random guy off the street isn't going to be proficient as a coach, but someone that deeply understands the domain -- as I mentioned -- can create and review code for quality without being able to write the code at that level or proficiency.
Erik Spoelstra is a great example. Played basketball and had a short professional stint in lower leagues in Europe. Started off reviewing tape for the Miami Heat and went on to be a very successful coach. He doesn't make the plays, but he knows which players and which plays he needs. He knows when a player makes a good play and when a player makes a bad play. He substitutes players as needed for each situation. He deeply knows the domain, even if he can't himself play at that level.
When the LLM can code 100x faster than you, your job isn't to be a better coder, it's to be a better coach.
Unfortunately the new LLM stack is one hell of a dependency. I somewhat like what I've seen from it but its no guarantee it doesn't start to turn the screws back on you (in fact I expect it will turn out that way).
The industrialization of coding is not a new thing though, all sorts of tooling and standardisation could be described in the same terms. An LLM is just another gizmo that may or may not make the assembly line move faster.
Now you have pneumatic crane, you can move stacks and stacks of things around with ease. You need less strong guys around and instead there is a new need for fewer people that are well-trained on how to operate this pneumatic crane safely. You'll get more work done with less people.
That's what's happening with software engineering and LLM copilots; it's an industrialization of coding. You don't need 20 engineers to get that product out. You need a few that are really good operators of the machinery. Adept at prompting and reviewing code instead of writing code.