- Ensure the workflow is idempotent - if it stops or fails at any point, you should be able to start it from scratch and skip / happily redo various elements.

- Store the messages which trigger workflows.

- Track failures (if your log aggregation is good, even that's enough to start).

Then when the odd thing fails (or sometimes a bunch of things fail, because e.g. a core integration goes down) you can lookup the messages and have a little script or tool to go and re-queue them. This is an easy starting point that can keep you going for a long time until you really approach huge scale.

If I'm looking for a relatively straightforward and simple piece of information quickly (e.g. "wooden arch mirror stores linden") then the AI summary can be useful, because I don't need more than surface level info.

If I intend to analyze and understand something (e.g. "developer API issues Zoho Thrive"), then the AI summary and the general degradation in the quality of search results from Google really hinder me. I have to work to avoid a lazy and low value answer, whereas what I really want to do is go through various actual websites and reflect on them to gain insight.

There are many times when writing a feature that my spidey senses flare up and tell me that this thing is a lot more painful to code then I was expecting (and will be painful to maintain) and that a more elegant process may actually solve the problem, at which point I'll draw up an alternative option and talk to the product owner.

I've definitely started to see the consequences of the converse, which is large amounts of shite brittle code that solved the original spec narrowly, but is now an elephant on our back when we need to add other concerns to the system that cross over.

(BTW, this isn't against the use of coding agents entirely, its more against high-level agentic usage. I tend to use Claude Code to do little well defined tasks whilst I reflect on it).

Blaming the CLIENT for this is absolutely crazy.

No issues so far.

And this is what Markdown is for: its just enough above plain text such that you can get at least 95% of what you need for a blog post, whilst still have the source be easy to type and proof read.

Most importantly, they have the diligence and patience to methodically test subtly different cases, which I frankly don't have.

On the question of whether QA slows things down, I have to ask: slows down what? Slows down releasing something broken? Why is that something to optimize for? We should always be asking how long it takes to release the right thing (indeed I'm most productive when I can close a ticket after concluding nothing is needed).

After all, even if one has some slow and beastly, unoptimized Spring Boot container that chews through RAM, its not that expenseive (in the grand scheme of things) to just replicate more instances of it.