6 ms·

I find it excellent news that all the techniques that make agentic coding more efficient also make human coding more efficient. There was a worry that code woul

I find it excellent news that all the techniques that make agentic coding more efficient also make human coding more efficient. There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite. Clear code is important for AI productivity, so it now matters even more, because the difference of productivity is immediately and objectively measurable. Before AIs what code was well factored or not was largely a matter of opinion. Now you can say; look how better Claude works on codebase A vs codebase B, and present your case with numbers.

v5v3 1y ago
"There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite." For now...
- soulofmischief 1y ago
  As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like. I understand programming for the sake of programming, chasing purity and really digging into the creative aspects of coding. But I get that same kick out of writing perfect interfaces, knowing that the messier the code underneath is, the more my beautiful interface gets to shine. But transformers are offering us a way to build faster, to create more, and to take on bigger complexity while learning deeply about new domains as we go. I think the more we lean into that, we might enter a software golden age where the potential for creativity and impact can enter a whole new level.
  - iDont17 1y ago
    Yeh, exactly. Code doesn’t matter. Correct and stable electrical states matter. Energy based models and machines that boot strap from models, organize their state to a prompt are on their way. The analog hole for coders is closing. Most software out there is the layers of made up tools and such to manage and deploy software. We’ll save a lot of cycles pruning it all for generic patterns. 5-10 more years it’s all hardware again. Then no longer need to program a computer like it’s 1970.
  - bluefirebrand 1y ago
    > As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like The thing is, code that does all of the things you listed here is good looking code almost by definition If AI was anywhere near capable of producing this quality then it would be so thrilling, wouldn't it? But it's not. The consensus seems to be pretty universal that AI code is Junior to Intermediate quality at best, the majority of the time That generally isn't code that satisfies the list of quality criteria you mentioned
    - Leynos 1y ago
      Do you give the agent a style guide? Do you perform (or have another agent perform) code reviews on the agent's code? Do you discuss architecture and approach with the agent beforehand and compile that discussion into a design and development plan? If you don't do these things, then you're just setting yourself up for failure.
      - bluefirebrand 1y ago
        Ah yes the tried and true "you're holding it wrong" By the time I did all the stuff you're suggesting, I could just build the damn thing myself
        Leynos 1y ago
        Would you skip these guardrails when working with a "Junior to Intermediate" developer?
        bluefirebrand 1y ago
        No, but the goal of mentoring a Junior or Intermediate developer is that they eventually learn this stuff on their own. The value of helping another human grow is worth the tradeoff AI is a tool, not a human. I'm not about to invest in it the way I would a Junior developer. If the tool doesn't do the job, it's not a good tool. If a tool requires the same level of investment that a human does it's also not a good tool
  - ath3nd 1y ago
    > As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like. Software engineers and anyone who'd get hired to fix the mess that the LLM created. Also, ironically, other LLMs would probably work better on...not messy code. > But transformers are offering us a way to build faster, to create more, and to take on bigger complexity Wow. You sound as if building faster or creating more is synonymous with quality or utility. Or as if LLMs allow us to take on a bigger level of complexity (this is where they notoriously crumble). > we might enter a software golden age where the potential for creativity I haven't heard of a single (good) software engineer whose creativity was stifled by their inability to code something. Is an LLM generating a whole book in Hemingway style considered creative, or a poem? Or a program/app?
diggan 1y ago
> There was a worry that code would become big mud balls That's always been a worry with programming (see basically all Rich Hickey talks), and is still a problem since people prefer "moving fast today" instead of "not having 10 tons of technical debt tomorrow" LLMs makes it even easier for people to spend the entire day producing boilerplate without stopping for a second to rethink why they are producing so much boilerplate. If the pain goes away, why fix it?
- jnwatson 1y ago
  Literally less than an hour ago, I reviewed a bunch of LLM-generated boilerplate. I then told the agent to show me a plan to refactor it. I suggested some tweaks, and then it implemented the plan and then tested that it didn't break anything. It isn't much different than dealing with an extremely precocious junior engineer. Given how easy it is to refactor now, it certainly makes economic sense to delay it.
  - diggan 1y ago
    But I'm guessing you're doing those refactors because you know they're ultimately worth it, because you have experience programming since before LLMs? Like I know boilerplate and messy code sucks because I've had to work with it, without LLMs, and I know how much it sucks. I think you do too, but I think we know that, because we had to fight with it in the past.
    - danielbln 1y ago
      Right now devs around the world are pushing ungodly amounts of reinforcement learning data into the big AI labs. There is no reason to believe these models won't handle this stuff themselves and our priors will become a useless relic.
    - jacobr1 1y ago
      LLMs start to bog down with it at a certain point too. For a couple of my side projects, I decided to let things rip and now worry about code structure at all. After a certain point some of the changes I wanted to make just started either failing work racking up large bills. It would try to make a change, run tests, realize it broke something somewhere else, try to fix that, cause another issue. Undo the original thing, fix the new issue, maybe try to refactor, partially, fail, revert that, decide to make the tests pass by removing the tests! and then keep some broken version of fix. With a few similar cycles of that on repeat as well. Deliberately telling it how to rethink the structure, refactor first, then seperate out components fixed things. IF LLMs stayed at the current level, I would expect llm-aided-coders to learn how to analyze and address situations like this. However, I do expect models to be better able to A) avoid these kinds of situations with better design up front or reflection when making changes and B) identify more systematic patterns and reason about the right way to structure things. Basically ambiently detecting "code smells." You can already see improvements both from newer models and from prompt engineering coming from the agentic tools.
physicles 1y ago
I was struck by this too. Good error messages, fast tools, stable ecosystems, simple code without magic, straight SQL… it’s what I always want. Maybe agents will be what raises the bar for dev experience, simply because they work so quickly that every slowdown matters.

v5v3 1y ago

"There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite." For now...

soulofmischief 1y ago
As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like. I understand programming for the sake of programming, chasing purity and really digging into the creative aspects of coding. But I get that same kick out of writing perfect interfaces, knowing that the messier the code underneath is, the more my beautiful interface gets to shine. But transformers are offering us a way to build faster, to create more, and to take on bigger complexity while learning deeply about new domains as we go. I think the more we lean into that, we might enter a software golden age where the potential for creativity and impact can enter a whole new level.
- iDont17 1y ago
  Yeh, exactly. Code doesn’t matter. Correct and stable electrical states matter. Energy based models and machines that boot strap from models, organize their state to a prompt are on their way. The analog hole for coders is closing. Most software out there is the layers of made up tools and such to manage and deploy software. We’ll save a lot of cycles pruning it all for generic patterns. 5-10 more years it’s all hardware again. Then no longer need to program a computer like it’s 1970.
- bluefirebrand 1y ago
  > As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like The thing is, code that does all of the things you listed here is good looking code almost by definition If AI was anywhere near capable of producing this quality then it would be so thrilling, wouldn't it? But it's not. The consensus seems to be pretty universal that AI code is Junior to Intermediate quality at best, the majority of the time That generally isn't code that satisfies the list of quality criteria you mentioned
  - Leynos 1y ago
    Do you give the agent a style guide? Do you perform (or have another agent perform) code reviews on the agent's code? Do you discuss architecture and approach with the agent beforehand and compile that discussion into a design and development plan? If you don't do these things, then you're just setting yourself up for failure.
    - bluefirebrand 1y ago
      Ah yes the tried and true "you're holding it wrong" By the time I did all the stuff you're suggesting, I could just build the damn thing myself
      - Leynos 1y ago
        Would you skip these guardrails when working with a "Junior to Intermediate" developer?
        bluefirebrand 1y ago
        No, but the goal of mentoring a Junior or Intermediate developer is that they eventually learn this stuff on their own. The value of helping another human grow is worth the tradeoff AI is a tool, not a human. I'm not about to invest in it the way I would a Junior developer. If the tool doesn't do the job, it's not a good tool. If a tool requires the same level of investment that a human does it's also not a good tool
- ath3nd 1y ago
  > As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like. Software engineers and anyone who'd get hired to fix the mess that the LLM created. Also, ironically, other LLMs would probably work better on...not messy code. > But transformers are offering us a way to build faster, to create more, and to take on bigger complexity Wow. You sound as if building faster or creating more is synonymous with quality or utility. Or as if LLMs allow us to take on a bigger level of complexity (this is where they notoriously crumble). > we might enter a software golden age where the potential for creativity I haven't heard of a single (good) software engineer whose creativity was stifled by their inability to code something. Is an LLM generating a whole book in Hemingway style considered creative, or a poem? Or a program/app?

diggan 1y ago

> There was a worry that code would become big mud balls That's always been a worry with programming (see basically all Rich Hickey talks), and is still a problem since people prefer "moving fast today" instead of "not having 10 tons of technical debt tomorrow" LLMs makes it even easier for people to spend the entire day producing boilerplate without stopping for a second to rethink why they are producing so much boilerplate. If the pain goes away, why fix it?

jnwatson 1y ago
Literally less than an hour ago, I reviewed a bunch of LLM-generated boilerplate. I then told the agent to show me a plan to refactor it. I suggested some tweaks, and then it implemented the plan and then tested that it didn't break anything. It isn't much different than dealing with an extremely precocious junior engineer. Given how easy it is to refactor now, it certainly makes economic sense to delay it.
- diggan 1y ago
  But I'm guessing you're doing those refactors because you know they're ultimately worth it, because you have experience programming since before LLMs? Like I know boilerplate and messy code sucks because I've had to work with it, without LLMs, and I know how much it sucks. I think you do too, but I think we know that, because we had to fight with it in the past.
  - danielbln 1y ago
    Right now devs around the world are pushing ungodly amounts of reinforcement learning data into the big AI labs. There is no reason to believe these models won't handle this stuff themselves and our priors will become a useless relic.
  - jacobr1 1y ago
    LLMs start to bog down with it at a certain point too. For a couple of my side projects, I decided to let things rip and now worry about code structure at all. After a certain point some of the changes I wanted to make just started either failing work racking up large bills. It would try to make a change, run tests, realize it broke something somewhere else, try to fix that, cause another issue. Undo the original thing, fix the new issue, maybe try to refactor, partially, fail, revert that, decide to make the tests pass by removing the tests! and then keep some broken version of fix. With a few similar cycles of that on repeat as well. Deliberately telling it how to rethink the structure, refactor first, then seperate out components fixed things. IF LLMs stayed at the current level, I would expect llm-aided-coders to learn how to analyze and address situations like this. However, I do expect models to be better able to A) avoid these kinds of situations with better design up front or reflection when making changes and B) identify more systematic patterns and reason about the right way to structure things. Basically ambiently detecting "code smells." You can already see improvements both from newer models and from prompt engineering coming from the agentic tools.

physicles 1y ago

I was struck by this too. Good error messages, fast tools, stable ecosystems, simple code without magic, straight SQL… it’s what I always want. Maybe agents will be what raises the bar for dev experience, simply because they work so quickly that every slowdown matters.