6 ms·

"unless you're content with producing low quality work." - With the right guiding hand, it is a productivity multiplier without compromising quality. As a full

"unless you're content with producing low quality work." - With the right guiding hand, it is a productivity multiplier without compromising quality. As a fully autonomous developer, it is a disaster.

Forgeties79 2mo ago
> With the right guiding hand, it is a productivity multiplier without compromising quality This just reads like another variation of “it’s the user not the tool,” which is just endless runway for always blaming people and never acknowledging the limitations of LLM’s. I’d be curious to hear how the recipients of your work enabled by the “productivity multiplier” feel about the quality.
- deleted 2mo ago
  [deleted]
- inglor_cz 2mo ago
  You can't play an entire orchestra's sheet music on a single guitar either, but your playing ability still matters a lot. I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. For example, it pays off to prepare an implementation plan with one LLM and then let another LLM check it for flaws, then again. After several iterations like this, you will have a plan better than whatever you could come up with yourself. It often is the user and not the tool. LLMs are complicated, have nontrivial failure modes, and the user needs to steer them carefully. They might be the most complicated tools on the planet right now. Anecdotally, the recipients of my work have become visibly more happy in the last months. LLMs are great at diagnosing subtle problems which tend to appear at Friday night only, and this is the sort of problem that bugs actual people the most.
  - Forgeties79 2mo ago
    > I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. Totally agree, I don’t think I said or implied otherwise. And yes can it can be the user and often even is, but when it comes to any LLM conversation I’ve been a part of it seems people think the only answer is “you’re using it wrong.” Evangelists swear it’s a 100x multiplier and anything counter to that means you’re either a Luddite who is blinded by politics or are too dumb to use the tool.
    - throwaway7783 2mo ago
      I don't think it is "you are using it wrong". It is just that originally mediocre programmers still generate mediocre output (or worse sometimes) faster and originally good programmers generate good quality output faster. LLMs have not changed that yet.
- throwaway7783 2mo ago
  Yes. It is always people. Every tool will have limitations, including LLMs. We actually have trendlines on user reported bugs, and I am happy to report they show a significant downtrend.
ffsm8 2mo ago
[flagged]
- simonw 2mo ago
  I produce code that is significantly higher quality with the assistance of coding agents, because I no longer succumb to the temptation to cut corners due to lack of time. One example: everything I do is properly tested and documented now, even the most trivial of changes. Previously I would have weighed those tradeoffs and sometimes decided not to bother with the tests because they weren't worth the time.
  - janussunaj 2mo ago
    > because I no longer succumb to the temptation to cut corners due to lack of time No offense, but that says much more about the way you approach programming than about the quality of LLM outputs. In my experience, LLMs are the ultimate corner-cutting tool. With LLMs, I now succumb to the temptation to cut corners, build something I haven't properly researched and don't fully understand, prioritize shipping quantity over quality. Without LLMs, I have to understand the domain and the tools and ultimately my full solution (with all its warts and limitations). When I really care about the project and consider it "my baby", LLMs are out of the picture.
    - simonw 2mo ago
      Software engineering is about tradeoffs. The single most important tradeoff is always time: this feature would be better if I did X, but doing X would take me Y hours, is it worth the time or should I spend that time on something else? Not having to type in and then iterate on the code manually has a material effect on those time calculations. I absolutely agree that you need to understand the domain and code and tools. That's what I want to spend my human time on - not typing in the code and sweating over every line of syntax.
      - janussunaj 2mo ago
        I agree, good software engineering is largely about making good trade-offs. However, I completely disagree with your characterization of LLM coding as saving you "typing in the code and sweating over every line of syntax". Claude will happily architect complex layers of OOP, multithreading, SIMD (a "personal favorite" of both Claude and ChatGPT). If you don't immerse yourself in the details, you will never know if you made the correct engineering trade-offs, let alone whether the various "optimizations" and clever solutions by the LLM actually work. I think you're referring more to product strategy trade-offs than engineering trade-offs here; so yeah, getting something you don't understand out the door is often the fastest path to sales. This is also how we get so much low quality and unnecessary software out there (it was true before LLM coding, just amplified now). I think a reasonable tradeoff, in theory, would be: use the LLM to help you explore the space of solution, then dive into the details and choose the path that feels right. However, I highly doubt most people do that. It's also easy to let the LLM's first solution influence your understanding of the problem, so that you will never truly explore novel solutions that fall outside of the most likely token sequence prediction. Oh and LLMs when properly constrained can also do pretty good "auto-complete on steroids", which can definitely save you typing a lot of boilerplate. If that's how you use them, then your characterization is correct.
close04 2mo ago
How are junior devs becoming qualified “guiding hands” these days? If the expert with LLM assistance is multiplied, what’s a company’s incentive to pay for a junior, and how would they train to get good in these conditions?
- CuriouslyC 2mo ago
  Juniors are still useful, but not as pure "coders". The juniors you want to hire now can wear product, engineering and QA hats, and are self starters with good attention to detail and AI skills. These types of people are actually a bargain.
  - close04 2mo ago
    [dead]
  - throwaway7783 2mo ago
    Yes, but very few people are on that edge of product and technology. From that angle LLMs are destroying the junior engineer dev market
- throwaway7783 2mo ago
  I agree on this one. Junior developers are not yet good guiding hands yet. But for the motivated junior developers LLMs are a great onboarding and learning tool. A good senior engineer must still guide, and there are very large gaps on how it's being done

Forgeties79 2mo ago

> With the right guiding hand, it is a productivity multiplier without compromising quality This just reads like another variation of “it’s the user not the tool,” which is just endless runway for always blaming people and never acknowledging the limitations of LLM’s. I’d be curious to hear how the recipients of your work enabled by the “productivity multiplier” feel about the quality.

deleted 2mo ago
[deleted]
inglor_cz 2mo ago
You can't play an entire orchestra's sheet music on a single guitar either, but your playing ability still matters a lot. I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. For example, it pays off to prepare an implementation plan with one LLM and then let another LLM check it for flaws, then again. After several iterations like this, you will have a plan better than whatever you could come up with yourself. It often is the user and not the tool. LLMs are complicated, have nontrivial failure modes, and the user needs to steer them carefully. They might be the most complicated tools on the planet right now. Anecdotally, the recipients of my work have become visibly more happy in the last months. LLMs are great at diagnosing subtle problems which tend to appear at Friday night only, and this is the sort of problem that bugs actual people the most.
- Forgeties79 2mo ago
  > I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. Totally agree, I don’t think I said or implied otherwise. And yes can it can be the user and often even is, but when it comes to any LLM conversation I’ve been a part of it seems people think the only answer is “you’re using it wrong.” Evangelists swear it’s a 100x multiplier and anything counter to that means you’re either a Luddite who is blinded by politics or are too dumb to use the tool.
  - throwaway7783 2mo ago
    I don't think it is "you are using it wrong". It is just that originally mediocre programmers still generate mediocre output (or worse sometimes) faster and originally good programmers generate good quality output faster. LLMs have not changed that yet.
throwaway7783 2mo ago
Yes. It is always people. Every tool will have limitations, including LLMs. We actually have trendlines on user reported bugs, and I am happy to report they show a significant downtrend.

ffsm8 2mo ago

[flagged]

simonw 2mo ago
I produce code that is significantly higher quality with the assistance of coding agents, because I no longer succumb to the temptation to cut corners due to lack of time. One example: everything I do is properly tested and documented now, even the most trivial of changes. Previously I would have weighed those tradeoffs and sometimes decided not to bother with the tests because they weren't worth the time.
- janussunaj 2mo ago
  > because I no longer succumb to the temptation to cut corners due to lack of time No offense, but that says much more about the way you approach programming than about the quality of LLM outputs. In my experience, LLMs are the ultimate corner-cutting tool. With LLMs, I now succumb to the temptation to cut corners, build something I haven't properly researched and don't fully understand, prioritize shipping quantity over quality. Without LLMs, I have to understand the domain and the tools and ultimately my full solution (with all its warts and limitations). When I really care about the project and consider it "my baby", LLMs are out of the picture.
  - simonw 2mo ago
    Software engineering is about tradeoffs. The single most important tradeoff is always time: this feature would be better if I did X, but doing X would take me Y hours, is it worth the time or should I spend that time on something else? Not having to type in and then iterate on the code manually has a material effect on those time calculations. I absolutely agree that you need to understand the domain and code and tools. That's what I want to spend my human time on - not typing in the code and sweating over every line of syntax.
    - janussunaj 2mo ago
      I agree, good software engineering is largely about making good trade-offs. However, I completely disagree with your characterization of LLM coding as saving you "typing in the code and sweating over every line of syntax". Claude will happily architect complex layers of OOP, multithreading, SIMD (a "personal favorite" of both Claude and ChatGPT). If you don't immerse yourself in the details, you will never know if you made the correct engineering trade-offs, let alone whether the various "optimizations" and clever solutions by the LLM actually work. I think you're referring more to product strategy trade-offs than engineering trade-offs here; so yeah, getting something you don't understand out the door is often the fastest path to sales. This is also how we get so much low quality and unnecessary software out there (it was true before LLM coding, just amplified now). I think a reasonable tradeoff, in theory, would be: use the LLM to help you explore the space of solution, then dive into the details and choose the path that feels right. However, I highly doubt most people do that. It's also easy to let the LLM's first solution influence your understanding of the problem, so that you will never truly explore novel solutions that fall outside of the most likely token sequence prediction. Oh and LLMs when properly constrained can also do pretty good "auto-complete on steroids", which can definitely save you typing a lot of boilerplate. If that's how you use them, then your characterization is correct.

close04 2mo ago

How are junior devs becoming qualified “guiding hands” these days? If the expert with LLM assistance is multiplied, what’s a company’s incentive to pay for a junior, and how would they train to get good in these conditions?

CuriouslyC 2mo ago
Juniors are still useful, but not as pure "coders". The juniors you want to hire now can wear product, engineering and QA hats, and are self starters with good attention to detail and AI skills. These types of people are actually a bargain.
- close04 2mo ago
  [dead]
- throwaway7783 2mo ago
  Yes, but very few people are on that edge of product and technology. From that angle LLMs are destroying the junior engineer dev market
throwaway7783 2mo ago
I agree on this one. Junior developers are not yet good guiding hands yet. But for the motivated junior developers LLMs are a great onboarding and learning tool. A good senior engineer must still guide, and there are very large gaps on how it's being done