You should do an experiment of splitting that up to multiple reviews that are logically together. My hypothesis is that you may be losing signal due to the amount of text expected back.
Or, alternatively, they feel like they finally cracked the code and think they can do it better. That's when Apple finally enters a market.
Consider how much money they put in to building a car to cancel it when they decided they couldn't, in fact, do it better. I'm sure there are hundreds - maybe thousands - of failed prototypes along the way.
It's the concern for the community who pays in higher prices, and the employees in their job stability.
Has everyone forgotten the social contract? We do not exist as communities to make a small number of people richer. If the trade doesn't work for all involved, we change the rules.
One thing that this misses is that in many fields, career retirement chooses you before you choose it. This is often true in development as ageism catches up with you. At some point, you keep doing interviews and nobody says "yes."
Then, even though you have enough money for retirement (or even if you don't), you are answering these questions simultaneously with handling rejection.
I'm so glad YouTube and other podcast players have moved to support 3.0 speed. As I get comfortable with one, I move it up some. For things like sports and "did you know" content, I can go 2.5 if I'm not multitasking. For technical content, sometimes I'm stuck at 1.0.
For people who did not grow up with hershey's, the butyric acid is what makes it taste off.
This is not a question of safety - it is a question of results. They stayed with old technologies and have optimized for cost, not flavor. (And yes, that processing was necessary in the days before a reliable milk source.)
First, no matter what you do, if a human has write access to the production database, the database can be deleted.
Second, there is a legitimate reason to destroy a database in development and automation. The biggest problem I see is often treating your development data like pets not cattle. You absolutely need to have safeguards that this cannot be run in production, but if a human has access to the credentials to run in production, the agent has access.
So, then, what do we do? In a larger organization, we can depend on the dev/ops split to maintain this. For a solo developer, or a small team, it takes a lot more discipline. Even before AI, junior and even mid-level developers didn't have the knowledge to segment. And senior devs often got complacent because they thought they knew enough.
But at that point you're past vibe coding. And from what I can tell, the successful vibe coders are quickly learning that they need to go past it pretty quickly with all these horror stories.
A corporation is not a person. If your organization cannot handle the load, then you need to adjust your practices. The organization needs to prioritize their paying users. The organization needs to shift people from new features to keeping the lights on. And maybe the organization needs to find another strategy to manage its azure transition.
(and my link to the Royce paper isn't working anymore - I need to fix that!) - I am planning on a followup that takes the last 3 years of change in mind.
This is a particular artifact of the government system process. These are contracted pieces of work that Company A would deliver, Company B would administer, and Company C would be contracted out for additional work. Further, all specifications were created ahead of time because changes would cost extra. (Anyone who has done government contracting can talk to the shenanigans involved with it - I have not lived in this world for a long time.)
That said, we still do ad-hoc versions of many of these. For example, a system/segment specification today is an OpenAPI document between microservices. Most larger SaaS companies have the equivalent of a Software Configuration Management plan - Who can change terraform or a GHA, what are the standards that they conform to (linter, peer review standards).
Oh certainly - I'm conflating the adjective of agile with the manifesto of agile. I've been on projects with multi-hundred page design docs and multi-week UATs. And nobody wants to go back to prince2 for example.
The point I was trying to make is we should be diving back into the older methodologies and accumulated wisdom and re-evaluate some of the older dead ends with new context.
Missing here: some organizations were rewarding high token usage as productivity without critical evaluation. People were afraid to be in the bottom because outcomes weren't being measured.
Humans have some repeatable bugs in our wetware, and it can be predictably exploited in a way that is hard to correct. It isn't "some people" - it's all of us, and the moment we think we're immune is the moment that we are most easily affected.
Yes, even the smartest of us are idiots in some very predictable ways.
Business/Enterprise accounts are billed at $20/seat + API prices, not subscription prices. You can give them a monthly dollar quota or let them go unlimited, but they're not being subsidized like in team. And team can't get a 20x plan from what I can tell.