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.

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.

Then, even though you have enough money for retirement (or even if you don't), you are answering these questions simultaneously with handling rejection.

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.)

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.

They likely need some combination of https://www.cloudbees.com/blog/separate-aws-production-and-d..., introduction to terraform, introduction to GitHub actions, and some sort of vm where production credentials live (and AI doesn't!)

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.

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).

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.

Like, if waterfall of a project can be done in 2 weeks, is it agile now?

Yes, it's as stupid as it sounds.

It is a giant Goodhart's law lesson

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.

Second, they've started publishing new editions so quickly with only the problem sets changed (in general) so that students can't use previous editions. If you're learning on your own, you can get some good deals on older editions for just that reason.

And on top of that, they maintain their own platforms so that even if you buy them used, you have to subscribe to a service to take the tests! All of this lines up to finding as many ways to extract money from students and at interest after it's all said and done.

You need to show a real application with pieces of the system that coordinate and complex interactions. Recreate Jira's backlog and sprint board that can have an arbitrary set of business logic for how a ticket moves through a workflow. Put it through its paces, don't give me a toy.