Not sure there's going to be a consensus, but I can tell you that when i have codex review claude-written code, it finds important gaps and fixes. The reverse is also true. Both are powerful, but even better when used in combination
TAP is not really about writing tests, it's more about making sure that a system under test emits plain text logs that can easily be consumed/validated
The markdown based tests described is more of an analog to gerken, robotframework, etc.
there's a number of similar efforts. turning english-like specs for a test into executable tests has seens lots of variants over the years but LLMs have reaaly stepped up the possibilities
stuff is getting goofy. I can blow through claude's session limit on sonnet, i don't even bother with opus now. same prompts and code for codex and it will hardly put a dent in the quota ($200/yr claude vs $20/mo codex). This is not with any crazy parallel agents, mcps, or skills.... pretty much vanilla installs, with some projects using beads.
I don't have the receipts, but I think they were somewhat closer in Jan/Feb.
-codex variant models in earlier version were just fine tuned for coding work, and had a little better performance for related tool calling and maybe instruction calling.
in 5.4 it looks like the just collapsed that capability into the single frontier family model
scam is a bit of hyperbole. also, ZEV has always explicitly referenced tailpipe emissions, which is also why there's been the odd sounding "partial zero emissions vehicle" category. It's certainly valid to be concerned about additional sources of fine particles, but eliminating engine emissions is not something to be dismissed as a scam.
Further, particle emission from brake dust is mitigated in EV's that use regen braking. One of my ev's can go days without phycical brake usage, and another uses the brake pads so infrequently it has an automatic mode to touch the discs occasionally just to keep them from building up rust.
tire particles --- different compounds can effect that, but will always be a side effect of tires on vehicles.
> tire particles --- different compounds can effect that, but will always be a side effect of tires on vehicles.
There's vehicles like trains, subways and bycicles, responsible for transporting hundreds of at least a billion people per day, which don't use tires whose particles are the biggest source of microplastics.
That happens when people are on variable rate or TOU plans, it's very common. "sneaky" may or not be part of it, since ostensibly there's a contract that defines the terms of the electrical service, so it shouldn't be a surprise. But for a lot of folks it's a lot to keep track of, there can be confusing terminology, and yes, some energy retailers are predatory in their plan marketing or contract terms. It's a double edged sword of free market choice in deregulated markets. People that have choices for their energy supply don't always have the time and knowledge to optimize their plan choices and electricity use to get "optimum" pricing. This is why there's pushback in some areas that have had deregulated energy markets to go back to regulated pricing, the "average consumer" isn't seeing the payoff of the free market (even if that is technically "their fault").
I kind of doubt a single surprise bill that happened to arrive in the winter is a TOU plan change.
If someone changes to a TOU plan and their bill shoots up, they’re smart enough to blame the plan change and cite that
Most surprise winter time bills are just excess electric heater usage, such as after the purchase of a couple space heaters without thinking about the overall cost.
> This is why there's pushback in some areas that have had deregulated energy markets
What areas have deregulated residential electricity?
The “optimum” pricing is one that rips off the customer the most. A deregulated free market for utilities doesn’t work because bad actors will find ways to do so through complex contracts.
not the OP, but beads is trying to solve a different problem, namely task organization/prioritization/coordination.
This looks more like a straight agent knowledge base to be used with or instead of .md files you might have in the repo that have information about the codebase. To use a bad analogy confluence vs jira.
for me it has varied based on the product type and scope, i.e release note for everyone like on a mobile app release or a SaaS platform, vs a tenant specific customized release. There are multiple ways to single source it, and now LLMs can help you out a bit.
If you just need a simple thing, query what you are releasing (from jira or whatever tracking system you are using) and package them up into categories of features/bug fixes and keep the release notes general.
if it's important to have an accurate curated set of release notes, create a field in your bug db for external release notes---leave those for tehncical product managers, support etc to edit as they want. THen you can have internal and external ones.
you always need to review for language and sensitive data, so human review (but again LLMs are helpful now fo this stuff too)
