I find they serve two purposes: 1) they give you a 10,000 foot/metre view of the technology so you know what the building blocks are and roughly what is (claimed to be) possible; 2) helps you load up on the vocabulary, so when you run into issues you know the language to use when searching for help.
July 26, 2025 at 12:09 PM
I find they serve two purposes: 1) they give you a 10,000 foot/metre view of the technology so you know what the building blocks are and roughly what is (claimed to be) possible; 2) helps you load up on the vocabulary, so when you run into issues you know the language to use when searching for help.
I use it regularly in my development. I prefer to go test first and very much focus on the “if I were calling this code, how do I wish I could call it” aspect. Red Green Refactor. I don’t tend to apply TDD if I’m making a “simple” automation transaction script e.g. file manipulation.
May 25, 2025 at 12:08 PM
I use it regularly in my development. I prefer to go test first and very much focus on the “if I were calling this code, how do I wish I could call it” aspect. Red Green Refactor. I don’t tend to apply TDD if I’m making a “simple” automation transaction script e.g. file manipulation.
I don’t think we should be using this technology to write our tests at all. I get that some people find writing tests onerous but they are the specifications that prove our software works. Asking an LLM to infer the specification from the written code assumes the code is correct and prevents TDD.
May 10, 2025 at 1:58 PM
I don’t think we should be using this technology to write our tests at all. I get that some people find writing tests onerous but they are the specifications that prove our software works. Asking an LLM to infer the specification from the written code assumes the code is correct and prevents TDD.