6 ms·

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking

• deleted 1y ago
  [deleted]
• deleted 1y ago
  [deleted]
• gherkinnn 1y ago
  That matches my experience. Decomposing a problem so that it is solvable with ease is what I enjoy most about programming and I am fine with no longer having to write as much code myself, but resent having to review so much more. Now, how do we solve the problem of people blindly accepting what an LLM spat out based on a bad prompt. This applies universally [0] and is not a technological problem. 0 - https://www.theverge.com/policy/677373/lawyers-chatgpt-hallucinations-ai https://www.theverge.com/policy/677373/lawyers-chatgpt-hallu...
  • ben30 1y ago
    Agreed on the review burden being frustrating. Two strategies I've found helpful for managing the cognitive load: 1. Tight issue scoping: Making sure each issue is narrowly defined so the resulting PRs are small and focused. Easier to reason about a 50-line change than a 500-line one. 2. Parallel PR workflow: Using git worktrees to have multiple small PRs open simultaneously against the same repo. This lets me break work into digestible chunks while maintaining momentum across different features. The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly. When each PR has a single, clear purpose, it's much easier to catch issues and verify correctness. Im finding these workflow practices help because they force me to engage meaningfully with each small piece rather than rubber-stamping large, complex changes.
    • davnn 1y ago
      > The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly. I am not sure if that is the real insight. It appears to me that most people prefer small, well-bounded changes, but it's quite tricky to break down large tasks into small but meaningful changes, isn't it? To me, that appears to be the key.
      • ben30 1y ago
        Exactly - and that's where AI becomes really valuable as a thinking partner. I use Claude Code to have conversations with my codebase about how to slice problems down further. The issue definition itself becomes something you can iterate on and refactor, just like code. Getting that definition tightly bounded is more critical than ever because without clear boundaries, the AI doesn't know when to stop or what constitutes "done." It's like having a pair programming session focused purely on problem decomposition before any code gets written. The AI can help you explore different ways to break down the work, identify dependencies, and find natural seams in the problem space.
• dgb23 1y ago
  I want to add something to this which is rarely discussed. I personally value focus and flow extremely highly when I'm programming. Code assistance often breaks and prevents that in subtle ways. Which is why I've been turning it off much more frequently. In an ironic way, using assistance more regularly helped me realize little inefficiencies, distractions and bad habits and potential improvements while programming: I mean that in a very broad sense, including mindset, tooling, taking notes, operationalizing, code navigation, recognizing when to switch from thinking/design to programming/prototyping, code organization... There are many little things that I could improve, practice and streamline. So I disagree with this statement at a fundamental level: > The technical skill of writing code has been largely commoditized (...) In some cases, I find setting yourself up to get into a flow or just high focus state and then writing code very effective, because there's a stronger connection with the program, my inner mental model of how it works in a more intricate manner. To me there are two important things to learn at the moment: Recognizing what type of approach I should be using when and setting myself up to use each of them more effectively.
  • thrwthsnw 1y ago
    Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents. Could also write really polished example code to communicate the style and architectural patterns and add full test coverage for it. I do notice the same lack of flow when using an agent since you have to wait for it to finish but as others have suggested if you set up a few worktrees and have a really good implementation plan you can use that time to get another agent started or review the code of a separate run and that might lend itself to a type of flow where you’re keeping the whole design of the project in your head and rapidly iterating on it.
    • bluefirebrand 1y ago
      > Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents This doesn't work because you still have to read and verify all of the stuff your agents produce So the new workflow is: Move up an abstraction level to use an agent to produce code Then move down an abstraction level to review the code it produces This sounds like way more cognitive overhead and way harder (and therefore probably slower) to do than just writing the code by hand in a good flow
• prmph 1y ago
  What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have some magic sauce for prompting, they should post a session or chat that can be verified by other (even if not exactly repeatable). Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet. Having to hand hold it every step of the way, continually keep correcting basic type and logic errors (even ones I had corrected previously in the same session), and in the end it just could solve the challenge I gave it. I have to be cynical and believe those shouting about LLMs taking over technical skill must have lots of stock in the AI companies.
  • coffeefirst 1y ago
    Indeed. All this “productivity” has not resulted in one meaningful open source PR or one interesting indie app launch, and I can’t square my own experience with the hype machine. If it’s not all hat and no cattle, someone should be able to show me some cows.
    • lazide 1y ago
      Why do that when they can ignore you and keep living in their bubble?
    • DontchaKnowit 1y ago
      I find this hard to believe- how would you even know if someone used AI in producing a PR or indie product? Are you omniscient? Further, there are articles here on HN all the time about people using AI for actual serious work. Heres a pretty significant example : https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/ https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-...
    • tonyedgecombe 1y ago
• steveBK123 1y ago
  So really the same two skills that a senior engineer needs to delegate tasks to juniors & review the results..
  • skydhash 1y ago
    Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
    • steveBK123 1y ago
      Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
      • strgcmc 1y ago
        I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.
        • skydhash 1y ago
          > Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear. A very small team of good engineers will get you much further than any army of intern level coders.
• TaupeRanger 1y ago
  That's a narrow view of the issue described in the blog post. You're coming at this from the perspective of a software engineer, which is understandable given the website we're posting on, but the post is really focusing on something higher level - the ability to decide whether the problems you're decomposing and the code you're reviewing is for something "good" or "worthwhile" in the first place. Claude could "decompose problems" and "review code" 10x better than it currently does, but if the thing it's making is useless, awkward, or otherwise bad (because of prompts given by people without the qualities in the blog post), it won't matter.
• eweise 1y ago
  "these require deep understanding of the domain, the codebase, and good software engineering principles" Most of this AI can figure out eventually, except maybe the domain. But essentially software engineering will look a lot like product management in a few years.
  • deleted 1y ago
    [deleted]
  • virgilp 1y ago
    As a (very good I would say) product manager once told me - the product vision and strategy depends very much on the ability to execute. The market doesn't stand still, and what you _can_ do defines very much what you _should_ do. What I mean to say here is that not even product management is reduced to just "understand the domain" - so it kinda' feels that your entire prediction leans on overly-simplified assumptions.
    • eweise 1y ago
      pretty big logic leap you made there. I didn't say understanding the domain was the only requirement. But certainly not understanding it will cause you to fail.
• bcrosby95 1y ago
  This would be at least the third time in history we've tried to shunt writing code to low paid labor. We'll see if it's successful this time. The problem tends to be that small details affect large details which affect small details. If you aren't good at both you're usually shit at both.
  • mlinhares 1y ago
    The problem wasn't low paid labor, it was just incompetent labor. You can find competent developers in all these countries offering lower pay, India, Brazil, Romania, Poland, China, Pakistan, its just that they would already be hired by other higher paying companies and what is left for the ones that are looking for the lowest paid possible workers are the incompetent ones.
    • Suppafly 1y ago
      >its just that they would already be hired by other higher paying companies and what is left for the ones that are looking for the lowest paid possible workers are the incompetent ones Reminds of me working in IT. One company tried to outsource my job to India five different times before they were mostly successful at it. The companies that are successful aren't the ones that assume it'll cost 1/10th the price, they are the ones that know it'll cost 60+% of the price and still require some handholding. If you're hiring on price alone, you're already selecting the pool that doesn't contain the most competent labor.
      • ryukoposting 1y ago
        "Never buy the cheapest version of something." I don't remember who told me that, but it was good advice. There's always a reason.
    • deleted 1y ago
      [deleted]
  • wvoch235 1y ago
    IMO attempts to make it low paid work will fail, just like almost every STEM profession. But... the number of engineers that we need who operate as "power multipliers" on team will continue to decrease. Many startup and corporate teams already aren't needing junior/mid level engineers any longer. They just need "drivers", senior/lead/staff engineers that can run independent tracks. AI becomes the "power multiplier" in the teams who amplify the effects of the "driver". Many people pretend that 10x engineers don't exist. But anyone who has worked on an adequately high performing team at a large (or small) company knows that skill, and quite frankly intelligence, operate on power laws. The bottom 3 quartiles will be virtually unemployable. Talent in the top quartile will be impossible to find because they're all employed. Not all that unlike today, though which quartile you fall into is largely going to depend on how "great" of an engineer you are AND how effectively you use AI. As this happens, the tap of new engineers who are learning how to make it into the top quartile, will cutoff for everyone except for those who are passionate/sadistic enough to programming without AI, then learn to program WITH AI. Meanwhile the number of startups disrupting corporate monopolies will increase as the cost of labor goes down due to lower headcount requirements. Lower head counts will lead to better team communication and in general business efficiency. At some point the upper quartile will get automated too. And with that, corporate moats evaporate to solo-entrepreneurs and startups. The ship is sinking, but the ocean is about to boil too. When economic formulas start dividing by zero, we can be pretty sure that we can't predict the impact.
• esafak 1y ago
  You still need to be able to code to recognize when it's done poorly, and to write the technical specification.
• deleted 1y ago
  [deleted]