6 ms·

The babysitting work would still be impossible if you didn't actually know how to code.

deeprack4sure 4mo ago
And thats why noone should learn to code.
JumpCrisscross 4mo ago
> babysitting work would still be impossible if you didn't actually know how to code It will be fewer and fewer people with, probably, deeper and deeper knowledge (and job security and compensation to boot). Poet is a bad comparison. But something like low-level semiconductor physics or assembly is closer to the mark.
DrewADesign 4mo ago
Right, but if things progress as they promised, it will require far fewer people to do the same work, which means the industry already has all the people it so need for at least a couple decades. That’s what happened with tool and die guys when offshoring kicked off, and now they’re scrambling to get apprentices because the last of the OG ones are retiring. There were decades that pretty much nobody (relative to prior eras) got trained for that work.
- patch_dev 4mo ago
  You're making an assumption on what AI lab have promised? The same AI labs that have made a strategy out of lying for hype? Thats crazy man, regardless of whether anything else you're saying is valid.
  - DrewADesign 4mo ago
    That’s why I said “if” and not “when.”
- drTobiasFunke 4mo ago
  You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
  - david-gpu 4mo ago
    > You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been? How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
    - drTobiasFunke 4mo ago
      Not a fair comparison. Unlike shoemaker or coopers who do ONE thing, a SWE doesnt do just one thing.. atleast in general. I churned through basic, logo, c, c++, java, c#, python, go and now agents. The executable building on single machine died when distributed systems came in. It again evolved when cloud took over. We have been reinventing our work every few years. Every job change requires us to learn new skills. How much did a horse farrier have to learn if they switched their employers?
      - DrewADesign 4mo ago
        No profession uses only one skill. I’ve had a few, the longest-running as a developer, and there is nothing uniquely varied about working in software. One thing that is pretty unique to software is how superior they feel to most other professionals, when in reality, it’s a pretty mediocre discipline compared to electrical or mechanical engineering, medicine, chemistry… Cobblers design, make and repair shoes of various kinds, boots for various purposes, slippers and moccasins with leather, cloth, rubber, and many kinds of threads using punches, knives, various machines, glues… How much does a developer need to learn about their core competency when switching employers? Not even close to as much as a machinist. It’s not a useful comparison.
      - david-gpu 3mo ago
        You asked for counterexamples, so I gave you a few. Did I misinterpret your question?
left-struck 4mo ago
I think there’s potentially a future where software engineers learn how to “babysit” models instead of the details of programming. Kind of how software engineering students for the last decade at least haven’t learnt a great deal of assembly or cpu architecture. Maybe you had a unit on CPUs but it’s not central to the course. I’m not saying I like that future, but I can imagine it.
- bloppe 4mo ago
  Imagine managing a team of people with no knowledge of their craft, like a team of doctors when you know nothing about being a doctor. You might be pretty confident that you can do it really well. The doctors would probably think that your "management" is unnecessary and potentially counter-productive.
irjustin 4mo ago
For now, I can imagine a not too distant future where this is largely untrue. LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs? At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.
- skydhash 4mo ago
  > LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs The what is the semantic mapping between <some lang> and LLMs? I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism). Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.
  - tibbar 4mo ago
    The non-determinism is one of the relevant features of this layer of abstraction! And one can learn to validate that the translation is being done properly. Some of the tools you have include writing extremely detailed specs, generating visualizations of the internals of the tool, or (perhaps) reading the code, though that becomes less feasible with volume. Basically it turns out that code is full of incidental details and what you really want is to verify the important parts, while receiving a guarantee that the vast tail of incidentals is handled "reasonably."
    - bitwize 4mo ago
      LLMs will still blithely ignore the specs and steering documents, apologize profusely for doing so after the fact, and tell you "I'll do better next time" which they might do once or twice. But after the context is cleared or a new session opened, the Dixie Flatline gets reset and it doesn't remember it screwed up, or that you told it not to. This happened to a coworker of mine. Generally the response from one-shotted devs is a shrug of the shoulders and "wellp, them's the breaks! As long as it looks sensible from 10,000 feet up it's still a huge productivity win." But the devil, as they say, is in the details.
stronglikedan 4mo ago
I fear the capability of the models will quickly outpace the need for a human to validate their output. They won't be juniors for much longer.
- danielbln 4mo ago
  Agreed, you can feel this change strongly with Opus vs Fable. Fable doesn't feel like a junior developer anymore. And it requires a lot less ceremony to boot.
mellosouls 4mo ago
Consider the difference between capabilities when gpt3 was released and now - the "increasingly babysitting" is exactly right. Knowing how to code (and more generally software engineering and other roles in software teams) is definitely still extremely useful, but is rapidly becoming less vital as a human-provided skill as models and harnesses greedily hoover up the knowledge margin.

And thats why noone should learn to code.

> babysitting work would still be impossible if you didn't actually know how to code It will be fewer and fewer people with, probably, deeper and deeper knowledge (and job security and compensation to boot). Poet is a bad comparison. But something like low-level semiconductor physics or assembly is closer to the mark.

DrewADesign 4mo ago

Right, but if things progress as they promised, it will require far fewer people to do the same work, which means the industry already has all the people it so need for at least a couple decades. That’s what happened with tool and die guys when offshoring kicked off, and now they’re scrambling to get apprentices because the last of the OG ones are retiring. There were decades that pretty much nobody (relative to prior eras) got trained for that work.

patch_dev 4mo ago
You're making an assumption on what AI lab have promised? The same AI labs that have made a strategy out of lying for hype? Thats crazy man, regardless of whether anything else you're saying is valid.
- DrewADesign 4mo ago
  That’s why I said “if” and not “when.”
drTobiasFunke 4mo ago
You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
- david-gpu 4mo ago
  > You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been? How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
  - drTobiasFunke 4mo ago
    Not a fair comparison. Unlike shoemaker or coopers who do ONE thing, a SWE doesnt do just one thing.. atleast in general. I churned through basic, logo, c, c++, java, c#, python, go and now agents. The executable building on single machine died when distributed systems came in. It again evolved when cloud took over. We have been reinventing our work every few years. Every job change requires us to learn new skills. How much did a horse farrier have to learn if they switched their employers?
    - DrewADesign 4mo ago
      No profession uses only one skill. I’ve had a few, the longest-running as a developer, and there is nothing uniquely varied about working in software. One thing that is pretty unique to software is how superior they feel to most other professionals, when in reality, it’s a pretty mediocre discipline compared to electrical or mechanical engineering, medicine, chemistry… Cobblers design, make and repair shoes of various kinds, boots for various purposes, slippers and moccasins with leather, cloth, rubber, and many kinds of threads using punches, knives, various machines, glues… How much does a developer need to learn about their core competency when switching employers? Not even close to as much as a machinist. It’s not a useful comparison.
    - david-gpu 3mo ago
      You asked for counterexamples, so I gave you a few. Did I misinterpret your question?

left-struck 4mo ago

I think there’s potentially a future where software engineers learn how to “babysit” models instead of the details of programming. Kind of how software engineering students for the last decade at least haven’t learnt a great deal of assembly or cpu architecture. Maybe you had a unit on CPUs but it’s not central to the course. I’m not saying I like that future, but I can imagine it.

bloppe 4mo ago
Imagine managing a team of people with no knowledge of their craft, like a team of doctors when you know nothing about being a doctor. You might be pretty confident that you can do it really well. The doctors would probably think that your "management" is unnecessary and potentially counter-productive.

irjustin 4mo ago

For now, I can imagine a not too distant future where this is largely untrue. LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs? At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.

skydhash 4mo ago
> LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs The what is the semantic mapping between <some lang> and LLMs? I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism). Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.
- tibbar 4mo ago
  The non-determinism is one of the relevant features of this layer of abstraction! And one can learn to validate that the translation is being done properly. Some of the tools you have include writing extremely detailed specs, generating visualizations of the internals of the tool, or (perhaps) reading the code, though that becomes less feasible with volume. Basically it turns out that code is full of incidental details and what you really want is to verify the important parts, while receiving a guarantee that the vast tail of incidentals is handled "reasonably."
  - bitwize 4mo ago
    LLMs will still blithely ignore the specs and steering documents, apologize profusely for doing so after the fact, and tell you "I'll do better next time" which they might do once or twice. But after the context is cleared or a new session opened, the Dixie Flatline gets reset and it doesn't remember it screwed up, or that you told it not to. This happened to a coworker of mine. Generally the response from one-shotted devs is a shrug of the shoulders and "wellp, them's the breaks! As long as it looks sensible from 10,000 feet up it's still a huge productivity win." But the devil, as they say, is in the details.

stronglikedan 4mo ago

I fear the capability of the models will quickly outpace the need for a human to validate their output. They won't be juniors for much longer.

danielbln 4mo ago
Agreed, you can feel this change strongly with Opus vs Fable. Fable doesn't feel like a junior developer anymore. And it requires a lot less ceremony to boot.

mellosouls 4mo ago

Consider the difference between capabilities when gpt3 was released and now - the "increasingly babysitting" is exactly right. Knowing how to code (and more generally software engineering and other roles in software teams) is definitely still extremely useful, but is rapidly becoming less vital as a human-provided skill as models and harnesses greedily hoover up the knowledge margin.