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
71–80 of 157 posts
Re: You can't unit test for taste
#72Exactly 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.
> 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?
Re: You can't unit test for taste
#73[dead]
Re: You can't unit test for taste
#74Earlier quoted context omitted.
yup and I find it weird that people still remain so defensive of the Church of TDD even against empirical studies that show its limited benefits https://arxiv.org/abs/2602.07900
Many such churches. Substitute static typing for TDD in your comment, and it will remain equally valid statement.
Static typing is very useful and time saving. I can rename something, knowing my IDE can propogate the change. I can call a function and know what it expects, not just "a thing, hope they added a comment so I know what type/shape wont blow it up!".
Here I am talking about the basic static typing, and maybe some generics use occasionally, but obviously people also go overboard sometimes with type features and that hinders understanding for newcomers to the codebase.
Re: You can't unit test for taste
#75Earlier quoted context omitted.
It can't be written down as code, that's the point. I am more familiar with taste in coding and it can at best be described—that the resulting code is too subtly different from something else in the codebase, that you're masking a different bug, that you're not following what the code tells you. The good part is that while this cannot be unit tested, you can write documentation and code comments about it that tell pe…
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.
Re: You can't unit test for taste
#76Earlier 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.
Wasn’t it introduced on Tahoe? (Perhaps my memory is failing me here.) Do you mean it still persists on Golden Gate? They seem to have addressed the majority of issues I heard about - unless you mean the issue is that rounded corners exist at all.
Re: You can't unit test for taste
#77Earlier quoted context omitted.
I think Apple lost a bit of credibility after the round-corner fiasco that still persists on Tahoe.
Wasn’t it introduced on Tahoe? (Perhaps my memory is failing me here.) Do you mean it still persists on Golden Gate? They seem to have addressed the majority of issues I heard about - unless you mean the issue is that rounded corners exist at all.
Re: You can't unit test for taste
#78> Overall the evaluation of success was one of the most challenging parts of the project. As a developer, I’m used to building features that either work or don’t and there is often an objective way to measure how well a feature performs. For messy real world data it was hard to evaluate how good or bad the pipeline was. Furthermore, it was easy to start optimising for a specific parameter or route and find later that this work led to severe degradations in other areas.
> Verification becomes hard to reason about because there is no ground truth for points of interest, there are no red/green unit tests for taste. I’m sure these are familiar challenges to data scientists and that there are frameworks and evals for working on them. This will require more iteration and manual overrides. Hopefully with feedback and collaboration from the community. But for now I’ve shipped V1…
I suspect LLMs may be able to help us quantify our taste because they can keep track of so many data points all at once, where we have to lossily abstract these details away.
Re: You can't unit test for taste
#79> but it ended up merely in a supporting role This has been my experience, as well, but it’s a really big support. It just needs adult supervision. I can’t understand how vibe-coded apps, actually work. As far as “taste,” goes, I test my stuff constantly, checking for even minor “friction points,” sometimes, refactoring back to design, in order to resolve issues that many folks would ship. I’m pretty anal, and want m…
> I can’t understand how vibe-coded apps, actually work.
With a better process. e.g. plan->revision cycles, better instructions/docs like an ADR system.
I don't think vibe-coding is relegated to "build me reddit but with blockchain" and then it's done.
I think it instead describes the workflow where the software impl stays opaque but you evaluate the end product as an end user to step the product forward. It basically centers you as the tastemaker.
I'd say I vibe-code all of my personal projects now since December where AI had a breakthrough where it required less babysitting and developed good "taste" like smart sum types without being prompted to do so.
I've accumulated my own best practices like a heavy plan->revise cycle where plans ultimately promote into ./plans/impl/YYYY-MM-DD-{slug}.md, and an ADR system in ./docs/design/*.md that encodes arch/design invariants that accumulate over time, and new decisions/principles are folding back into it as they are discovered (by the AI).
During the plan revision cycles, the LLMs may ask me a multiple choice question about which decision branch to take, and lately I've just been responding with "take the ideal option" with good results -- either way it will take a well-reasoned position that I can't really argue with.
Meanwhile, my role is mainly to evaluate the end product and steer it directionally. How much I decide to prescribe and inject myself into technical decisions is a function of how serious the project is, but it's easy to notice that LLMs are simply better and better at arriving at well-reasoned decisions, and my interjections are more and more limited to technical/directional taste rather than necessity.
Re: You can't unit test for taste
#80You 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…
The bigger problem I have as a worker is that, once I externalize it (by writing a skill or whatever), it becomes a work-for-hire whose copyright is owned by my employer. Technically this is true of a few other things I do for work, like my .emacs and .bashrc files, small scripts I keep in ~/bin on my workstation, etc., but no employer cares to assert this unless they're being assholes for some unrelated reason. Agent skill files, especially ones that seem to semi-reliably do what they say on the tin (the white whale!), are not like that at all, and I can see them pursuing you if you try to use them at a future employer.