"most developers optimized for shipping code"...

This PHP situation exemplifies when your in the fire to find a solution and look forward and not get into the "why didn't we do X". You can do that later. This comes to mind because I'm seeing "well you should have done..." replies which is absolutely useless to people looking for guidance and help.

Iterate and review. I find the "don't need to review" statements to be naive without context.

Are you doing the design up front? Do you only care about the outcome or do care about the implementation?

"if the tests pass"... There so much to unpack with that

"We switched to Event Driven Architecture. Now we cant debug anything." A lot of the pain is from lack of tooling, visibility, and a misunderstanding of when to use events versus commands, or when something should even be asynchronous in the first place! Event Driven Architecture isn't your architecture. Its just part of it. codeopinion.com/event-driven…

I find it comical all the "domain knowledge matter more now". No.. it mattered just as much before. Still the same. Nothing changed.

Yes to both included in meta data of the event

Stop Modeling Everything as CRUD. Task-Driven isn't always the answer either. Ask: What is the user trying to accomplish?

I always say directly below you. That doesn't mean lower than that necessarily. A lower level for most developers is understanding SQL that their ORM is generating. How HTTP works that their web framework abstracts.

Exactly

A recent example of this was pulling some metrics for a dashboard. The query made sense but was it efficient? Depends on the DB, amount of data, indexes, etc. Cache aside could be useful for partial values of the data set for historical data with a short expiry. But a cache would be more moving parts and complexity. Did the agent just magically decide it should use a partial cache or not? Are we deferring that answer to it without even any of that understanding? The answer can be yes, but it sure better have all the context to make that decision. But who is accountable?

"design patterns don't matter because AI writes code" is like saying "architectural blueprints don't matter because power tools cut wood faster." Ex: architectural (distributed, messaging) patterns like say a claim check or cache aside, do you need them? Depends on the context. But you can't say you do or don't unless you know what they are and the trade-offs. Otherwise you're just offloading decisions.

Ask a model to build out a public http API. It will be horrific to you. Why? Because is doing what it's told. You need to tell it how to handle your resource model, conventions, consistency, rate limiting, etc. None of this is "best practice" or a default, it's specific to your context that you need to define. And if you don't to ask you're left with, for example, a resource model that leaks your data model, that you can't change.