5 ms·

It largely depends on the person. We have several junior engineers who cannot solve a problem without AI. When AI can’t solve it, they just keep trying and fail

by olsondv 2mo ago

It largely depends on the person. We have several junior engineers who cannot solve a problem without AI. When AI can’t solve it, they just keep trying and failing. And I mean weeks to months late. Then rinse and repeat on the next task. It used to be that they would have been forced to seek help from a senior engineer. Combine the teaching with a real struggle is what makes them better. As it is now, they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. The produced code is a black box, and the AI’s development is a black box too. All they know is that running it produces something like what they asked for. They have no idea about failure modes which is a fundamental concept of engineering. The worst part is that AI is covering up their deficiencies. They don’t know what skills they lack. They don’t even know what skills are required because they haven’t put the effort in. There are obviously good junior engineers that are using AI judiciously and not as a crutch. They’re the ones who still interact with seniors to get help and actually learn. They would have been successful without AI too. These are the ones the author is talking about. In my experience, the momentum is moving towards the worse type of junior the more AI is adopted. Unless that changes, it will erase their value.

yolo3000 2mo ago
This is the direction many engineers (seniors included) are facing if they mostly rely on AI. You lose your skills, you become detached. We will all become 'architects'.
jtrn 2mo ago
[flagged]
- kibwen 2mo ago
  LLMs are not even remotely comparable to compilers. This attempt at analogy is neither humorous nor insightful.
  - jtrn 2mo ago
    It depends on the level of analysis. Both change the abstraction level one works at. So if you can't decode the message, I can do it for you. People believed that something important was lost by moving up one abstraction layer, because knowing the lower-level details was important, more so than having the possibility of doing more because complexities have been abstracted away for you. And almost every time in history this conflict has arisen, the stubborn people who want to stick to the "everybody should stay at the level of abstraction that I want to stay at!" have been proven wrong. So if you don't see the comparison, you lack imagination. It's the same comparison Torvald Linus made, and even though all the rabid anti-AI people try to deny that it's a valid comparison by willfully misunderstanding the comparison, it's perfectly valid. And I find both the article and the comment I responded to either ignorant of history, and worse than uninsightful, because they are just patently, historically, logically, and empirically wrong. And I'm getting tired of the arrogant senior devs, that are not a fraction as useful as they think they are, whining and complaining at younger people who are creating imperfect but useful work with AI. While the tools for AI coding are just exploding. How can you people say stuff like "They learn nothing" with a straight face is beyond me. I see people daily who use AI to solve problems and learn something in the process. I am having such a blast over the last couple of years seeing how AI development just relentlessly disproves the claims from bitter old developers who don't want to be forced to do anything useful. And when the transition is complete, the gatekeepers will be gone, and we will be left with people trying to solve real problems.
    - beej71 2mo ago
      Do you feel that layers of abstraction in project management and layers of abstraction in the technology being managed are the same thing?
      - jtrn 2mo ago
        Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall. While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?” Edit insertion for clarification: The compiler, framework usage, AI usage, are all tools and patterns for generating code. And they all stay neatly inside the technology, and more specifically the dimention of "creating code". Not relevant to the topic I was responding to tho. And project management is usually way harder than coding, with or without AI. At least if you measure it by how few people are able to do each well.
- glouwbug 2mo ago
  This analogy only works if you’re ready to commit _only prompts_ and have those prompts do a clean “compile” of your production runtime everytime you pull. Are you ready to do that?
  - jtrn 2mo ago
    See my response to the other comment if you don't understand that analogy is not the same as "identical". And to state that "This analogy only works if ...." is just PATENTLY wrong. The analogy works fine if you say that it compares analogous situations. Like if we focus on some encumbrance complaining that "kids these days are too stupid because they don't understand the fundamentals like I do" or "These new tools that make it easier for stupid people, not smart people like me, to make stuff is dangerous because they don't know what they are doing". That's just a few of MANY analogous observations we can make for the two situations. But I guess you think that only the thing you care about is the only thing that exists. And in the end, everybody who complains like this is just going to be shown to be just as mistaken as all the people who complained that "people who don't code in assembly are dangerous!" And it's just marvelous to watch it play out slowly over the last couple of years. And we are just a couple of years in. I'm just making a note of everybody who is mistaken, as a study in denial and biased thinking. The end for all of this was obvious after Opus 4.6 hit. And it's just getting more and more obvious with each model release and harness improvement. This is a gold mine for studying flawed thinking.
  - Kim_Bruning 2mo ago
    It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt. FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code. Mutating the docs then leads to mutations in the code. Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet?), and ymmv. Everyone is still figuring out the best practices I think.
    - jtrn 2mo ago
      Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there" The interesting thing in all of this to me is what must happen for the same spec to be deterministically certain to generate the same software. Could you delete the code, regenerate from docs alone, and trust the result? And obviously.... not yet. In practice, workflows drift, sometimes you patch the code directly because it's faster, and now code and docs have not been properly updated. But the entire flow and concept of: [Spec] -> [AI/Harness] -> [Finished software], and how we increasing determinism in that flow, is just immensely interesting to me.
- rstuart4133 1mo ago
  You are equating n LLM's output with FORTRAN? The only time you really need to look at core dumps of a FORTRAN compiler is when you think the compiler has a bug. Apart from that, the abstraction doesn't leak. You don't need to know any details of the CPU to debug what is going on, every compilation you do is deterministic and has a predictable outcome. When you make a change, you should be able to predict the exact outcome. Don't like it? Reverse the change, and you're exactly where you were before. I've coded on a few machines I've never bother to learn what the metal does. It is always like this, and it's fine. LLMs are nothing like that. Like FORTRAN the LLMs make you feel like they've abstracted you from the code. But you can't get by exclusively feeding instructions to an LLM. The OP made was making that point when he said "When AI can’t solve it, they just keep trying and failing". When your only undo is to say "fix the mess you just created", you can't replay instructions you gave yesterday to give you the same result, and you can't even say "explain what you did" and expect to get a reliable answer, there is no out. You have to look at the code. When the abstractions leak badly, you have to learn both the abstraction and the thing it's trying to simplify. They are little better than macros that save you typing. An LLM is a very leaky abstraction.
  - jtrn 1mo ago
    Oh thanks! I dident realize LLM are NOT the same as FORTRAN, how silly of me. I thought that they where identical! You are sharp as a tac!
xtiansimon 2mo ago
> “…they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. […] the ones who still interact with seniors to get help and actually learn.” You’re describing a gap between those who would otherwise fail in their jobs sooner, and those who already know what to do. Sounds like there is a new paradigm for management, too.
codegeek 2mo ago
"The worst part is that AI is covering up their deficiencies. They don’t know what skills they lack. They don’t even know what skills are required because they haven’t put the effort in." This is the biggest issue with AI. It is incredible when in the right hands (Senior devs who know good fundamentals and know how to code) but really bad when in wrong hands (Juniors with no fundamentals but they are made to believe that they know what they are doing).
- 21asdffdsa12 2mo ago
  So how do you design a harness that tries to grow the user? As in quiz the prompter in a way that forces them to reflect and improve? And if they can do that- could they do it to themselves- going from a junior to a pro conversation?
  - yifanl 2mo ago
    You can't, as that removes the main value add of the AI.
    - hawaiianbrah 2mo ago
      I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.
      - bluefirebrand 2mo ago
        From what I can tell, the value add for AI seems to be this behavior you're describing But the value add being marketed is something entirely different, which is where the disconnect is coming in
      - dns_snek 2mo ago
        "Understanding" someone else's solution is not comparable to solving it on your own, even if you can answer some questions about it. It builds extremely fragile surface-level understanding. That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.
spike021 2mo ago
>It used to be that they would have been forced to seek help from a senior engineer You still have standups, right? I'd be questioning why at the very least the team lead/manager isn't questioning the lack of progress during those meetings and immediately requesting a more senior engineer help out. Even before AI this was how it worked. Unless the junior engineer is being purposely secretive about lack of progress, which would have happened back then too, then this isn't an AI problem, it's a team culture one.
- hawaiianbrah 2mo ago
  Yeah, I can’t imagine having something “weeks or months” late without intervention. That isn’t a failing of AI or the junior, that’s a failing on the team processes/manager/everyone else on the team.
Varelion 1mo ago
I work at a workplace where the seniors use AI, and I am chastised for asking questions. I end up using the AI as a learning tool instead.
vrighter 1mo ago
I once (before ai) had a junior waste two months trying and failing to make a relatively simple change. As it turns out she it never occurred to her that she might want to copy the newly compiled executable ("it's the thing visual studio builds for you when you press build!" I had to explain this) to the server she was trying to run it on. So she never once managed to execute her changed code, which kept degrading as more and more changes accumulated trying to "fix" it

by olsondv 2mo ago

yolo3000 2mo ago

This is the direction many engineers (seniors included) are facing if they mostly rely on AI. You lose your skills, you become detached. We will all become 'architects'.

jtrn 2mo ago

[flagged]

kibwen 2mo ago
LLMs are not even remotely comparable to compilers. This attempt at analogy is neither humorous nor insightful.
- jtrn 2mo ago
  It depends on the level of analysis. Both change the abstraction level one works at. So if you can't decode the message, I can do it for you. People believed that something important was lost by moving up one abstraction layer, because knowing the lower-level details was important, more so than having the possibility of doing more because complexities have been abstracted away for you. And almost every time in history this conflict has arisen, the stubborn people who want to stick to the "everybody should stay at the level of abstraction that I want to stay at!" have been proven wrong. So if you don't see the comparison, you lack imagination. It's the same comparison Torvald Linus made, and even though all the rabid anti-AI people try to deny that it's a valid comparison by willfully misunderstanding the comparison, it's perfectly valid. And I find both the article and the comment I responded to either ignorant of history, and worse than uninsightful, because they are just patently, historically, logically, and empirically wrong. And I'm getting tired of the arrogant senior devs, that are not a fraction as useful as they think they are, whining and complaining at younger people who are creating imperfect but useful work with AI. While the tools for AI coding are just exploding. How can you people say stuff like "They learn nothing" with a straight face is beyond me. I see people daily who use AI to solve problems and learn something in the process. I am having such a blast over the last couple of years seeing how AI development just relentlessly disproves the claims from bitter old developers who don't want to be forced to do anything useful. And when the transition is complete, the gatekeepers will be gone, and we will be left with people trying to solve real problems.
  - beej71 2mo ago
    Do you feel that layers of abstraction in project management and layers of abstraction in the technology being managed are the same thing?
    - jtrn 2mo ago
      Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall. While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?” Edit insertion for clarification: The compiler, framework usage, AI usage, are all tools and patterns for generating code. And they all stay neatly inside the technology, and more specifically the dimention of "creating code". Not relevant to the topic I was responding to tho. And project management is usually way harder than coding, with or without AI. At least if you measure it by how few people are able to do each well.
glouwbug 2mo ago
This analogy only works if you’re ready to commit _only prompts_ and have those prompts do a clean “compile” of your production runtime everytime you pull. Are you ready to do that?
- jtrn 2mo ago
  See my response to the other comment if you don't understand that analogy is not the same as "identical". And to state that "This analogy only works if ...." is just PATENTLY wrong. The analogy works fine if you say that it compares analogous situations. Like if we focus on some encumbrance complaining that "kids these days are too stupid because they don't understand the fundamentals like I do" or "These new tools that make it easier for stupid people, not smart people like me, to make stuff is dangerous because they don't know what they are doing". That's just a few of MANY analogous observations we can make for the two situations. But I guess you think that only the thing you care about is the only thing that exists. And in the end, everybody who complains like this is just going to be shown to be just as mistaken as all the people who complained that "people who don't code in assembly are dangerous!" And it's just marvelous to watch it play out slowly over the last couple of years. And we are just a couple of years in. I'm just making a note of everybody who is mistaken, as a study in denial and biased thinking. The end for all of this was obvious after Opus 4.6 hit. And it's just getting more and more obvious with each model release and harness improvement. This is a gold mine for studying flawed thinking.
- Kim_Bruning 2mo ago
  It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt. FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code. Mutating the docs then leads to mutations in the code. Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet?), and ymmv. Everyone is still figuring out the best practices I think.
  - jtrn 2mo ago
    Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there" The interesting thing in all of this to me is what must happen for the same spec to be deterministically certain to generate the same software. Could you delete the code, regenerate from docs alone, and trust the result? And obviously.... not yet. In practice, workflows drift, sometimes you patch the code directly because it's faster, and now code and docs have not been properly updated. But the entire flow and concept of: [Spec] -> [AI/Harness] -> [Finished software], and how we increasing determinism in that flow, is just immensely interesting to me.
rstuart4133 1mo ago
You are equating n LLM's output with FORTRAN? The only time you really need to look at core dumps of a FORTRAN compiler is when you think the compiler has a bug. Apart from that, the abstraction doesn't leak. You don't need to know any details of the CPU to debug what is going on, every compilation you do is deterministic and has a predictable outcome. When you make a change, you should be able to predict the exact outcome. Don't like it? Reverse the change, and you're exactly where you were before. I've coded on a few machines I've never bother to learn what the metal does. It is always like this, and it's fine. LLMs are nothing like that. Like FORTRAN the LLMs make you feel like they've abstracted you from the code. But you can't get by exclusively feeding instructions to an LLM. The OP made was making that point when he said "When AI can’t solve it, they just keep trying and failing". When your only undo is to say "fix the mess you just created", you can't replay instructions you gave yesterday to give you the same result, and you can't even say "explain what you did" and expect to get a reliable answer, there is no out. You have to look at the code. When the abstractions leak badly, you have to learn both the abstraction and the thing it's trying to simplify. They are little better than macros that save you typing. An LLM is a very leaky abstraction.
- jtrn 1mo ago
  Oh thanks! I dident realize LLM are NOT the same as FORTRAN, how silly of me. I thought that they where identical! You are sharp as a tac!

xtiansimon 2mo ago

> “…they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. […] the ones who still interact with seniors to get help and actually learn.” You’re describing a gap between those who would otherwise fail in their jobs sooner, and those who already know what to do. Sounds like there is a new paradigm for management, too.

codegeek 2mo ago

"The worst part is that AI is covering up their deficiencies. They don’t know what skills they lack. They don’t even know what skills are required because they haven’t put the effort in." This is the biggest issue with AI. It is incredible when in the right hands (Senior devs who know good fundamentals and know how to code) but really bad when in wrong hands (Juniors with no fundamentals but they are made to believe that they know what they are doing).

21asdffdsa12 2mo ago
So how do you design a harness that tries to grow the user? As in quiz the prompter in a way that forces them to reflect and improve? And if they can do that- could they do it to themselves- going from a junior to a pro conversation?
- yifanl 2mo ago
  You can't, as that removes the main value add of the AI.
  - hawaiianbrah 2mo ago
    I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.
    - bluefirebrand 2mo ago
      From what I can tell, the value add for AI seems to be this behavior you're describing But the value add being marketed is something entirely different, which is where the disconnect is coming in
    - dns_snek 2mo ago
      "Understanding" someone else's solution is not comparable to solving it on your own, even if you can answer some questions about it. It builds extremely fragile surface-level understanding. That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.

spike021 2mo ago

>It used to be that they would have been forced to seek help from a senior engineer You still have standups, right? I'd be questioning why at the very least the team lead/manager isn't questioning the lack of progress during those meetings and immediately requesting a more senior engineer help out. Even before AI this was how it worked. Unless the junior engineer is being purposely secretive about lack of progress, which would have happened back then too, then this isn't an AI problem, it's a team culture one.

hawaiianbrah 2mo ago
Yeah, I can’t imagine having something “weeks or months” late without intervention. That isn’t a failing of AI or the junior, that’s a failing on the team processes/manager/everyone else on the team.

Varelion 1mo ago

I work at a workplace where the seniors use AI, and I am chastised for asking questions. I end up using the AI as a learning tool instead.

vrighter 1mo ago

I once (before ai) had a junior waste two months trying and failing to make a relatively simple change. As it turns out she it never occurred to her that she might want to copy the newly compiled executable ("it's the thing visual studio builds for you when you press build!" I had to explain this) to the server she was trying to run it on. So she never once managed to execute her changed code, which kept degrading as more and more changes accumulated trying to "fix" it