In other projects (my work life revolves around Terraform and infrastructure as code) I absolutely check and re-steer on a regular basis. I _suspect_ I could resolve those issues with better Terraform SKILLs but writing Terraform is more natural to me that dealing with Swift so I haven't bothered.

Example: I'm building a music player in Swift for MacOS. I want to have visualizers that use Metal to render directly with the GPU. I don't understand GPU rendering. I never will. So, what do I do?

I tell a strong model like Opus or Fable to write a spec first. Tell it that I want "lesser/cheaper models" to be able to do the actual implementation without needing to guess or think too hard about it. It builds something exactly like this: https://github.com/bocan/bocan-music/blob/main/docs/design-s...

As you can see, I don't just tell it to build software. I tell it to build tests. My CLAUDE.md has guardrails. It knows that if it's told to build anything, it has to format, lint, run the new tests and old tests. It knows to keep my coverage above 80%. When it's done, it commits with a highly detailed commit message.

When all that's done. I test the software extensively by hand. Does it do exactly what I want? If so, great. Next feature. If not, I go back and have my lesser/cheaper model fix the code and add tests. I rarely if ever update the specs if it finds bugs as there's no need.

Am I using british english consistently? Are there any grammatical errors? Etc.

I still feel it's important to fix whatever it finds by hand though.

Opus 4.7, or 4.6 where it's still available at work: For spec'ing up projects or changes. The 15x multiplyer on Copilot means I rarely do this.

Sonnet 4.6 everywhere else. It rarely fails me.

What do you think? I feel it's like marmite. You'll either love it or hate it!

Either way, I'm probably right that I'm pushing my luck with the Microsoft and the VSCode team so I'll be ready to implement it locally via JS overrides if it gets rejected. I think there's an extenstion that lets you do that.

Comments URL: https://news.ycombinator.com/item?id=48179074

Points: 2

# Comments: 1

With the former, I build the app with my own API_KEY and SHARED_SECRET, then the actual user has to add their username/password, which gets stored in the Apple keychain.

With the latter, I don't need a API KEY built into the app, and they just login with a username and a token.

Would I be right that I could just duplicate the listenbrainz code with that new endpoint and it would work the same way?

- I've got a native, open source MacOS music player/library _finally_ past version 1. (https://bocan.app) That's been an ugly learning curve as I'm both not the greatest Swift developer and still I want to keep adding features that I didn't quite understand at the start like ReplayGain.

- Ongoing maintenance of my badly-named open-sourced tool called Codex (https://github.com/bocan/codex). It's like a file/git based 1 person doc store that I use at work to drop markdown into, display it, with a built-in MCP server that I can use to ask it questions. THAT one is typescript so much easier. But then you have to worry about the constantly shifting sands of outdated and vulnerably dependencies to look after.

Off Net:

- Went to open my greenhouse for the season and found a nest of robins in my trash/rubbish bin. FFS. Now I can't empty it all for a long time, have to time my visits to tend to the tomatoes and peppers, and absolutely not close the doors. Anyone know how long it takes robins to fledge?

(nor would the missus be pleased for me to buy them - but that's another matter)