91–100 of 157 posts
You can’t even unit-test for correct program logic, unless you’re able to enumerate all possible inputs and states within a short time frame.
You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can. Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want. Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I…
Yes, it is called accepting the concept of "good enough".
If you go for perfection, with the help of AI or not - you will never be done, at least not if your concept of perfect is like mine.
And more concretely here, well you can feed the LLM with enough context about you, so it can better guess what you want. And in some years maybe use a brain computer interface. But I doubt there is a magic bullet here. Just better tools, that we can build. But they won't be perfect either (hard for me to write that, as I set out building the perfect tools).
Unrelated to code, but along the same lines. I've been keeping track of the Reckless Ben case to fuel my unhealthy indignation, and we just had a like-for-like comparison between a human and an LLM. Human: well-scoped argument that does just enough to get the job done with minimal risk. AI: Extremely clever and correct legal argument that almost any lawyer would have said not to file (at least as written). It tries t…
Earlier quoted context omitted.
Apple's human interface guidelines says that some things can be written down though. It's a very thurough look at UX and while they don't adhere to them perfectly themselves, it's very much a north star to a some ideals. You can't unit test for taste, but you can integration test that bad tastes haven't happened.
I think Apple lost a bit of credibility after the round-corner fiasco that still persists on Tahoe.
Exactly one of the reasons I never went down with all the TDD dogma of only writing code to fix broken tests. There is a reason conference talks are always about plain algorithms and data structures.
The biggest flaw I've seen with TDD is the fact that correctness does not compose upward. Every time two units come into contact, you've got an entirely new kind of unit. The tests from constituents do not cover emergent properties of the new things. You will repeat this same exercise the entire way up to the top, and the moment you come into contact with the customer (they want to change everything), the house of ca…
Even if I write down every single thing it did wrong and how I’d do it, and even if I turn those into rules, it will know how to follow these specific rules, but for some reason it can’t seem to generalize beyond that. And the real list of rules seem truly infinite.
After this line all the references becomes *we*. I can't help but be a little disturbed by that
> To begin with we downloaded ... For instance we excluded ... We also selected ... We used this as a notoriety ...
I am increasingly concerned about how LLMs are anthropomorphizing and how that affects our judgement?
Earlier quoted context omitted.
> TDD dogma of only writing code to fix broken tests. Isn't red-green-refactor pretty ingrained in TDD? Only write code to make a failing test pass; then refactor while making sure the tests still pass? Then write a test that fails, repeat?
Now do a games engine with that approach regarding shaders and the desired visuals.
I had a quick look at godot tests, and seems to me they cover some parts of the shaders?
Anyway, I was more wondering who/how people are dogmatic about TDD, and manage to leave out one out of three core concepts from red/green/refactor ?