4 ms·

But the code is the easy part. Solving the right problem is the hard part.

by geetee 8mo ago

hn_throwaway_99 8mo ago
Repeating this banality does not make it true. There were tons of tech companies over the past 30 years or so who, despite solving the same problems, lost out to competitors because they had worse programmers.
- robertclaus 8mo ago
  I actually agree that the code is one of the most important things to get right at a software company. Still. I would argue very few companies win on code merit alone either though. Strategy, customer communication, market timing, etc on the business side; design, system architecture, dev velocity on the technical side. So many factors are important beyond the quality of the code.
- locknitpicker 8mo ago
  > Repeating this banality does not make it true. If anything matches the definition of banality in this discussion, it's the puerile assertion that writing code is software development. It isn't. Even at FANGs the first thing they say to newjoiners and hiring prospects for entry level positions is that the workload involving writing code amounts to nearly 50% of your total workload. And now all of a sudden are we expected to believe that optimizing the 50% solves the 100%?
  - YetAnotherNick 8mo ago
    Now we are shifting the goalpost. Who even claimed AI solves 100%. I would even be damned if AI can solve 50% and it would be huge. Personally I don't even think current AI solves even the 50%.
    - locknitpicker 8mo ago
      > Now we are shifting the goalpost. Who even claimed AI solves 100%. I think you lost track of the discussion. I pointed out that in the absolute best case scenario LLMs only focus on tasks that represent a fraction of a software engineer's work. Then, once you realize that, you will understand that the total gains of optimizing away the time taken on a fraction of a task only buys you a modest improvement on total performance. It can speed up a task, but it does not and cannot possibly eliminate the whole job. To see what I mean, see Amdahl's law. https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law Again, only a fraction of the tasks of a regular software engineering role involves writing code. Some high-profile roles claim their entry level positions at best spend 50% of their time writing code. If LLMs can magically get rid of said 50%,the total speedup is at best 2x speedup in delivery. You can look at that and think to yourself "hey that's a lot". That is not what's being discussed here. I mean, read the blog post you are commenting on. What's being discussed is that LLMs reduce time spent on a fraction of the software development tasks, but work on other software engineering activities increases as it's no longer blocked by this bottleneck. As others have wrote, the so-called AI doesn't reduce work: it intensifies it. https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... Also, why do you think the phenomenon of AI-induced burnout, dubbed AI fatigue, is emerging? Processes are shifting, but the work is still there.
      - YetAnotherNick 8mo ago
        > the total speedup is at best 2x speedup in delivery Which is just huge if we can get 2x speedup.

But the code is the easy part. Solving the right problem is the hard part.

by geetee 8mo ago

But the code is the easy part. Solving the right problem is the hard part.

Repeating this banality does not make it true. There were tons of tech companies over the past 30 years or so who, despite solving the same problems, lost out to competitors because they had worse programmers.

robertclaus 8mo ago
I actually agree that the code is one of the most important things to get right at a software company. Still. I would argue very few companies win on code merit alone either though. Strategy, customer communication, market timing, etc on the business side; design, system architecture, dev velocity on the technical side. So many factors are important beyond the quality of the code.
locknitpicker 8mo ago
> Repeating this banality does not make it true. If anything matches the definition of banality in this discussion, it's the puerile assertion that writing code is software development. It isn't. Even at FANGs the first thing they say to newjoiners and hiring prospects for entry level positions is that the workload involving writing code amounts to nearly 50% of your total workload. And now all of a sudden are we expected to believe that optimizing the 50% solves the 100%?
- YetAnotherNick 8mo ago
  Now we are shifting the goalpost. Who even claimed AI solves 100%. I would even be damned if AI can solve 50% and it would be huge. Personally I don't even think current AI solves even the 50%.
  - locknitpicker 8mo ago
    > Now we are shifting the goalpost. Who even claimed AI solves 100%. I think you lost track of the discussion. I pointed out that in the absolute best case scenario LLMs only focus on tasks that represent a fraction of a software engineer's work. Then, once you realize that, you will understand that the total gains of optimizing away the time taken on a fraction of a task only buys you a modest improvement on total performance. It can speed up a task, but it does not and cannot possibly eliminate the whole job. To see what I mean, see Amdahl's law. https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law Again, only a fraction of the tasks of a regular software engineering role involves writing code. Some high-profile roles claim their entry level positions at best spend 50% of their time writing code. If LLMs can magically get rid of said 50%,the total speedup is at best 2x speedup in delivery. You can look at that and think to yourself "hey that's a lot". That is not what's being discussed here. I mean, read the blog post you are commenting on. What's being discussed is that LLMs reduce time spent on a fraction of the software development tasks, but work on other software engineering activities increases as it's no longer blocked by this bottleneck. As others have wrote, the so-called AI doesn't reduce work: it intensifies it. https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... Also, why do you think the phenomenon of AI-induced burnout, dubbed AI fatigue, is emerging? Processes are shifting, but the work is still there.
    - YetAnotherNick 8mo ago
      > the total speedup is at best 2x speedup in delivery Which is just huge if we can get 2x speedup.