this post was submitted on 19 Aug 2025
1566 points (99.6% liked)
Programmer Humor
25885 readers
667 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
AI used extremely sparingly is sometimes helpful to an experienced coder. "Multivac, generate a set of unit tests for this function." Okay, some of these are dumb, but it's easier getting started on this mess than just looking at a blank buffer. Helps get the juices flowing a bit. But man, you try to actually do anything with it, and suddenly you're lost chasing a will-o'-wisp.
I don't want to dismiss your point overall, but I see that example so often and it irks me so much.
Unit tests are your specification. So, 1) ideally you should write the specification before you implement the functionality. But also, 2) this is the one part where you really should be putting in your critical thinking to work out what the code needs to be doing.
An AI chatbot or autocomplete can aid you in putting down some of the boilerplate to have the specification automatically checked against the implementation. Or you could try to formulate the specification in plaintext and have an AI translate it into code. But an AI without knowledge of the context nor critical thinking cannot write the specification for you.
Unit tests become the specification once they are written. ChatGPT can easily write unit tests from whatever your specification is before that -- such as documentation, a bunch of comments and stubs, or even a first draft of the function itself, given enough context from the rest of the project.
Unit tests are too klunky to think in. You don't prototype the specification by implementing unit tests. And you really only lay down a few critical paths even if you "write the tests first" because code paths always come up during implementation that demand more test coverage anyway.