4 ms·

Sure, for humans. Not sure they'll be the primary readers of code going forward

tombert 6mo ago
I'm pretty sure that will be true with AI as well. No accounting for taste, but part of makes code hard for me to reason about is when it has lots of combinatorial complexity, where the amount of states that can happen makes it difficult to know all the possible good and bad states that your program can be in. Combinatorial complexity is something that objectively can be expensive for any form of computer, be it a human brain or silicon. If the code is written in such a way that the number of correct and incorrect states are impossible to know, then the problem becomes undecidable. I do think there is code that is "objectively" difficult to work with.
- ahepp 6mo ago
  What do you think about the argument that we are entering a world where code is so cheap to write, you can throw the old one away and build a new one after you've validated the business model, found a niche, whatever? I mean, it seems like that has always been true to an extent, but now it may be even more true? Once you know you're sitting on a lode of gold, it's a lot easier to know how much to invest in the mine.
  - eloisant 6mo ago
    It hasn't always been true, it started with rapid development tools in the late 90's I believe. And some people thought they were building "disposable" code, only to see their hacks being used for decades. I'm thinking about VB but also behemoth Excel files.
    - ahepp 6mo ago
      I guess the question is, are the issues not worth fixing because implementing a fix is extremely expensive, or because the improvements from fixing it were anticipated to be minor? I assume the answer is generally a mix of the two.
  - tombert 6mo ago
    I actually think that might actually be a good path forward. I hate self-promotion but I posted my opinions on this last night https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-Pushing-AI-Generated-Code-to-Git https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-... The tl;dr of this is that I don't think that the code itself is what needs to be preserved, the prompt and chat is the actual important and useful thing here. At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store that in Git.
    - alephnerd 6mo ago
      This is actually a pretty good callout. Observability into how a foundation model generated product arrived to that state is significantly more important than the underlying codebase, as it's the prompt context that is the architecture.
      - tombert 6mo ago
        Yeah, I'm just a little tired of seeing these pull requests of multi-thousand-line pull requests where no one has actually looked at the code. The solution people are coming up with now is using AI for code reviews and I have to ask "why involve Git at all then?". If AI is writing the code, testing the code, reviewing the code, and merging the code, then it seems to me that we can just remove these steps and simply PR the prompts themselves.
        alephnerd 6mo ago
        Yep. Also, the approach you described is what a number of AI for Code Review products are using under-the-hood, but human-in-the-loop is still recognized as critical. It's the same way how written design docs and comments are significantly more valuable than uncommented and undocumented source.
        zephen 6mo ago
        > why involve Git at all then? I made a similar point 3 weeks ago. It wasn't very well received. https://news.ycombinator.com/item?id=47411693 https://news.ycombinator.com/item?id=47411693 You don't actually need source control to be able to roll back to any particular version that was in use. A series of tarballs will let you do that. The entire purpose of source control is to let you reason about change sets to help you make decisions about the direction that development (including bug fixes) will take. If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners, or are they still using it because they don't want to admit to themselves that they've completely lost control?
  - tracerbulletx 6mo ago
    Someone has to figure out how to make the experiences of the two generations consistent in the ways it needs to be and differ only in the ways it doesn't still.
- hollowcelery 6mo ago
  There are a number of things that make code hard to reason about for humans, and combinatorial complexity is just one of them. Another one is, say, size of working memory, or having to navigate across a large number of files to understand a piece of logic. These two examples are not necessarily expensive for computers. I don't entirely disagree that there is code that's objectively difficult to work with, but I suspect that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has much less overlap than you're suggesting.
  - tombert 6mo ago
    Certainly with current models I have found that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has actually been remarkably similar, I suspect because it's trained on a lot of terrible code on Github. I'm sure that these models will get better, and I agree that the overlap will be lower at that point, but I still think what I said will be true.
  - bccdee 6mo ago
    I wouldn't expect so. These machines have been trained on natural language, after all. They see the world through an anthropomorphic lens. IME & from what I've heard, they struggle with inexpressive code in much the same way humans do.
- eloisant 6mo ago
  All the good practices about strong typing, typically in Scala or Rust, also work great for AI. If you make sure the compiler catches most issues, AI will run it, see it doesn't build and fix what needs to be fixed. So I agree that a lot of things that make code good, including comments and documentation, is beneficial for AI.
nkohari 6mo ago
Because LLMs are designed as emulators of actual human reasoning, it wouldn't surprise me if we discover that the things that make software easy for humans to reason about also make it easier for LLMs to reason about.
pydry 6mo ago
AIs struggle with tech debt as much if not more than humans. Ive noticed that theyre often quite bad at refactoring, also.
pylua 6mo ago
I think someday it will be completely unreadable for humans. Ai will have its optimized form.
tracerbulletx 6mo ago
Entropy and path dependence are unavoidable laws of mathematics. Not even evolution can avoid them.

I'm pretty sure that will be true with AI as well. No accounting for taste, but part of makes code hard for me to reason about is when it has lots of combinatorial complexity, where the amount of states that can happen makes it difficult to know all the possible good and bad states that your program can be in. Combinatorial complexity is something that objectively can be expensive for any form of computer, be it a human brain or silicon. If the code is written in such a way that the number of correct and incorrect states are impossible to know, then the problem becomes undecidable. I do think there is code that is "objectively" difficult to work with.

ahepp 6mo ago
What do you think about the argument that we are entering a world where code is so cheap to write, you can throw the old one away and build a new one after you've validated the business model, found a niche, whatever? I mean, it seems like that has always been true to an extent, but now it may be even more true? Once you know you're sitting on a lode of gold, it's a lot easier to know how much to invest in the mine.
- eloisant 6mo ago
  It hasn't always been true, it started with rapid development tools in the late 90's I believe. And some people thought they were building "disposable" code, only to see their hacks being used for decades. I'm thinking about VB but also behemoth Excel files.
  - ahepp 6mo ago
    I guess the question is, are the issues not worth fixing because implementing a fix is extremely expensive, or because the improvements from fixing it were anticipated to be minor? I assume the answer is generally a mix of the two.
- tombert 6mo ago
  I actually think that might actually be a good path forward. I hate self-promotion but I posted my opinions on this last night https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-Pushing-AI-Generated-Code-to-Git https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-... The tl;dr of this is that I don't think that the code itself is what needs to be preserved, the prompt and chat is the actual important and useful thing here. At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store that in Git.
  - alephnerd 6mo ago
    This is actually a pretty good callout. Observability into how a foundation model generated product arrived to that state is significantly more important than the underlying codebase, as it's the prompt context that is the architecture.
    - tombert 6mo ago
      Yeah, I'm just a little tired of seeing these pull requests of multi-thousand-line pull requests where no one has actually looked at the code. The solution people are coming up with now is using AI for code reviews and I have to ask "why involve Git at all then?". If AI is writing the code, testing the code, reviewing the code, and merging the code, then it seems to me that we can just remove these steps and simply PR the prompts themselves.
      - alephnerd 6mo ago
        Yep. Also, the approach you described is what a number of AI for Code Review products are using under-the-hood, but human-in-the-loop is still recognized as critical. It's the same way how written design docs and comments are significantly more valuable than uncommented and undocumented source.
      - zephen 6mo ago
        > why involve Git at all then? I made a similar point 3 weeks ago. It wasn't very well received. https://news.ycombinator.com/item?id=47411693 https://news.ycombinator.com/item?id=47411693 You don't actually need source control to be able to roll back to any particular version that was in use. A series of tarballs will let you do that. The entire purpose of source control is to let you reason about change sets to help you make decisions about the direction that development (including bug fixes) will take. If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners, or are they still using it because they don't want to admit to themselves that they've completely lost control?
- tracerbulletx 6mo ago
  Someone has to figure out how to make the experiences of the two generations consistent in the ways it needs to be and differ only in the ways it doesn't still.
hollowcelery 6mo ago
There are a number of things that make code hard to reason about for humans, and combinatorial complexity is just one of them. Another one is, say, size of working memory, or having to navigate across a large number of files to understand a piece of logic. These two examples are not necessarily expensive for computers. I don't entirely disagree that there is code that's objectively difficult to work with, but I suspect that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has much less overlap than you're suggesting.
- tombert 6mo ago
  Certainly with current models I have found that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has actually been remarkably similar, I suspect because it's trained on a lot of terrible code on Github. I'm sure that these models will get better, and I agree that the overlap will be lower at that point, but I still think what I said will be true.
- bccdee 6mo ago
  I wouldn't expect so. These machines have been trained on natural language, after all. They see the world through an anthropomorphic lens. IME & from what I've heard, they struggle with inexpressive code in much the same way humans do.
eloisant 6mo ago
All the good practices about strong typing, typically in Scala or Rust, also work great for AI. If you make sure the compiler catches most issues, AI will run it, see it doesn't build and fix what needs to be fixed. So I agree that a lot of things that make code good, including comments and documentation, is beneficial for AI.

nkohari 6mo ago

Because LLMs are designed as emulators of actual human reasoning, it wouldn't surprise me if we discover that the things that make software easy for humans to reason about also make it easier for LLMs to reason about.

pydry 6mo ago

AIs struggle with tech debt as much if not more than humans. Ive noticed that theyre often quite bad at refactoring, also.

pylua 6mo ago

I think someday it will be completely unreadable for humans. Ai will have its optimized form.

tracerbulletx 6mo ago

Entropy and path dependence are unavoidable laws of mathematics. Not even evolution can avoid them.