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.
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").
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)
This is what worked for me… clone the pb repo and stick reference to it in my agents.md. I put additional notes in my own addendum.md in the line cloned repo. ChatGPT-codex variants handle it nearly flawlessly and no issues with being out of date. I use the same pattern for all “niche” libraries
That's mentioned in the beads doc, it could have decent but beads is optimizing for agent use, semantic issue relationships, conflict resolution, etc. I've had success with just using gh issues and agents are pretty good at looking for new issues and closing them when done. I have a couple of toy projects where maintaining the code is basically filing a bug report or feature request.
Also when you say 'never heard of beads' --- it spits ou onboarding text to tell the agent exactly what it needs to know.
Requires a deep dive, but this is an interesting direction for agent tooling
this is is a distinction without a difference in many instances. I can easily ask an llm to write a python tool to produce random numbers for a given distribution and then use that tool as needed. The LLM writes the code, and uses the executable result. Then end black box result is the LLM doing the work
not really an accurate take -- it's less of a pause and more of a slowdown from original plans to move non 911 platforms. Macans and Cayennes still are more than half of their business, EV Macans outsold ICE mayans, and a new EV Cayenne is about to be launched.
The profit collapse is more a matter of accounting write downs for their R&D
Make no mistake, they still have issues because sales are collapsing in China (and much of that pressure is from EV upstarts), and there's been a pushback in US on EVs in part due to political shifts.
So we'll continue to se EV, ICE and hybrid development from Porsche, just at a different mix. But it's not going to be easy for them regardless. They have a precarious place in the upmarket mix where a lot of competition is coming for the intro luxury segment, and the volume in the exotic segment is too low to really sustain operations at Porsche's scale.
Still in a better spot than, say, an Astin Martin which would have been better off financially last couple of years just giving customers cash instead of letting them buy cars and lose money on every one
Different take: depreciated EVs mean they are more affordable on the used market, making them accessible to more people that can't make a $50-80K+ new vehicle work for their budgets. First adopters and EV enthusiast will continue to push the new market, but the tent opens up for more drivers. The next hurdle will be solving disparity of convenience between those that can have home chargers and those that live in apartments or with street parking.
At least in the 4-5 years ago, there was not much of a used market, not much vehicle choice beyond Tesla that was good price/performance, and tough going on charging infrastructure (again outside of Tesla)
That landscape has not completely changed, but it is much different. There's a lot of actual vehicle choice (even if most are still some type of SUV/CUV), and charging situation is reasonable, especially with opening up of NACS
There's a big component of political action against EVs, solar, etc but I think it will just slow, not stop the momentum in the US. With 2 BEVs and a PHEV, I don't see our family going back to ICE vehicles. I miss manual transmissions, that's about it
Got a PHEV first, then an EV . Having both at the same time is nice, they have slightly different use cases (just like we've always had one 'large' car, one 'small' car). Can easily see going EV only within 5 years, and could do it now with little fuss if I had to.