I often tell codex to launch a subagent without prior context to „remove BS phrases and make the prose sound more natural and higher readability“. That‘s usually enough to get better results.
7,123 karma · joined December 1, 2011
Living near Vienna, Austria.
meet.hn/city/at-Vienna
I often tell codex to launch a subagent without prior context to „remove BS phrases and make the prose sound more natural and higher readability“. That‘s usually enough to get better results.
And if you manage to do this automatically before committing, you’ve built the backpressure everybody is talking about.
You kinda lost me there. I‘m supposed to use a central technology whose author can’t be arsed to write a few paragraphs?
If you‘re specifically aiming for low glutamine, going vegan won’t cut it though, depending on what foods you leave in. Soy is high in it. Eg a glass of milk is lower glutamine than a serving of tofu.
I like using voice input a lot, I get way more info out of my brain and into the context that way.
Process wise, for bug fixes I usually just throw the ticket in and optionally some thoughts on how to fix. But if I don’t know the cause, I let it write instrumentation tests until the bug is reproed, and then the fix is easy.
For new features in brownfield projects, I usually need to align with team members because we‘re closely aligned between platforms. We iterate on what you could call a spec, which is just a mix of requirements, magic numbers we want, algorithms we‘ve picked (often by vibing prototypes), and sometimes going very specific on parts that must be done right. Eg for interfaces with other teams, and there’s not yet a document to describe that, we put that in the spec as well. We do use agents to shoot holes in those specs, and often they find inconsistencies. But architecturally, they seem to get caught up too much in what’s already in those specs, and personally I haven’t seen any worthwhile feedback that I‘d have taken up.
Sometimes we use this spec to vibe a first draft. Often the draft is so good that it can be bent to our liking. Sometimes, it just serves as a reservoir of ideas, and the feature must be implemented (with assistance) by re-assembling the pieces differently.
And the code will be good.
I don’t believe spec driven development is a good idea though. The architecture should be made with intention as well, or I feel we‘d end up with whatever happens to be ranked highest in the latent space. But the specs are great to align cross platform teams behind shared concepts, and they are a good input to automatic reviews.