No AI has been used in this project. How can you tell? README is out of date, there is no documentation and it has 1207 TODO comments.
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 14 hours ago (5 children)

Yep, and that's where I wonder if AI written code might, eventually, be more maintainable... at least by AI.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 11 points 14 hours ago* (last edited 14 hours ago) (1 child)

    From what I've seen and heard, AI seems to do well for test-driven development. That doesn't necessarily translate into good code, but it does translate into tested code.

    At the very least it can translate the documentation of an API into the appropriate tests to verify the documentation is correct, and I'm being quite humbled by that.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 hours ago

    The thing I have to constantly adjust for is: it does things at 10x my speed (on average, some things it does slower, but some things it does 100x faster), and about 80% of my accuracy. So, I have to really aggressively apply the bug catching methodologies that a lot of times I would get away without "because I'm that good..." not really, but there are some things I do that I have justifiably high confidence in, others that definitely need testing which I try to do before handing over to the test team. The reason I don't apply those bug catching methodologies to ALL my code is because that slows me down 3-5x, and it seems to slow down the LLMs about 2-3x, so they're only 3-5x faster than me, on average, when they are writing all the tests and multiply reviewing all the docs and code, compared to me "winging it."

    Where I think all this LLM stuff is going to pay off bigger is 10 years in the future, looking back at old code, yeah all that documentation is a bit of overkill, but we tended to underkill the documentation 10 years ago and we're still not doing as much as we probably should when we do things the "just before LLMs came on the scene" ways.

  • source
  • parent
  • [–] 5 points 12 hours ago (2 children)

    One problem I could see with the aggressive testing (which also happens in human-written codebases) is that it becomes hard to tell essential behaviour apart from details. If you nail everything down with a unit/integration test, nothing can be changed anymore.

    I could imagine that this is part of the reason why LLMs love to duplicate code rather than adjusting existing code.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 11 hours ago (1 child)

    Well... That's why you test the public API and not the internals. And if you need to change the API you should have a good enough reason that changing the tests is okay too.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 hours ago

    Well, since it's "just" LLM time writing the tests, test the internals too, but clearly mark which tests are the public API and which tests are intnernal, so it knows to never ignore / update a public API test without consultation, but it an internal test fails it can make the call: did this test start failing because I unintentionally broke something, or because the test was testing something that no longer matters - I have seen Claude go both ways, fixing its own mistake due to a test catching an unintended consequence of a change, and also just patching the test because the old test was... old.

  • source
  • parent