Back to articles

September 24, 2026

6 minute read

Death spiral

AI can be a powerful engineering tool, but the flood of automated output risks eroding judgment, context, and ownership if we stop steering.

"Doom slop" is a new term I heard this month.

Meaning: "Doom slop" combines the concepts of doomscrolling (obsessively reading negative news online) and slop (low-quality, mass-produced digital or AI-generated content).

Core meanings

  • Doomscrolling: Defined by slang dictionaries as endlessly scrolling through depressing, apocalyptic, or stressful news feeds. (1, 2)

  • Slop: Refers to cheap, uninspired, and repetitive filler content—often AI-generated—that clogs up modern social media and search results. (1, 2)

  • Combined ("doom slop"): The overwhelming stream of low-effort, dystopian, or anxiety-inducing digital garbage that feeds into burnout and endless negative scrolling.

From this combined core meaning is where I get my thoughts. AI is making everything seemingly "evolve" faster. Something new is being released each Monday that was built over the weekend by someone without full technical know-how, and new AI startups are spinning up weekly with seed funding falling out of the ether.

There was an article this month too from Jacob Coxon, who previously worked at both Anthropic and OpenAI, and posted this thread on X, further fuelling this doom loop around where this leaves the future of humanity, let alone our jobs in the next few years or even months.

Whilst at the same time we are still arguing about the foundational elements of agentic workflows within each of our own respective organisations. Several engineers racing to be the first to identify the best practices, each spinning up their own workflows and forcing a presentational “how-to” deck down our throats for us all to copy.

My take

Firstly, I believe that AI should be primarily used to augment your workflows, not replace them. I have a fear that we're achieving context collapse by letting the agents do every aspect of the work for us. I've witnessed this on several occasions when I've asked why we are doing something a particular way, only to be met with “I don't know, I asked the agent to solve it for me.”

Nowadays I spend my time reading through overly verbose JIRA tickets created by and for agents, fully automated pipelines scripted in Python that no one in the team knows how to read or maintain, and pull requests with a wall of text explaining every aspect of the diagnosis and solution, written by a multitude of sub-agents that ran through and verified a single-line change. See meat proxy.

I joined a new team recently and found everything was set up in a way that the human didn't need to do anything other than direct it where to go. I passed the ticket, it went off and resolved all the acceptance criteria, then it found some custom skills to run verification, take screenshots, and push the pull request. I completed 10 PRs that day and had little to no work left to do. So what now? I've been 4x'd in productivity but with no workstream to back this productivity. I luckily did have another stream of work in another team to lean on, and also raised with the team that my work was complete, which landed me a couple of extra tickets. But I imagine this to be a recurring trend going forwards.

I do believe that the real engineering work has shifted left into ideation and planning. This is where I sit in my own workflows. I tend to do my research by digging into the code to understand the problem and the domain area around it, then form a plan—either documented in an MD file for agent consumption or in my head—to allow the agent to use initiative so that I can watch and guide.

In my opinion you should be asking questions about whether that solution is really needed, whether it's what the customer actually wants, whether it adds value, and whether there are other solutions with fewer trade-offs. You may still augment with AI to do some discovery, rubber duck some solutions, or figure out the pros and cons whilst building a proposal. But I strongly think that it should be less about the production output and more about testing hypotheses and building prototypes to help inform the decisions that finally go to production.

At the end of it you are still the orchestrator. You have to stitch all the pieces together and refine the overall tasks that are required. At this point you can hand off to an agent to complete the task, because you know the context of what is required and the expected approach and direction. You should be able to explain why a change was made, the reason you did it that way, and support your decisions. The ownership and blame should still sit with you, not an agent.

Aside

I read an article on LinkedIn from a product manager recently. Typical social-media facade that clickbaits you into finding out how they did it. The headline read, “I created and published a new app to the app store in one evening.” But within a couple of paragraphs the contradictions were apparent: they had spent months planning and trying to understand what the agent was trying to do, and finally coaxing it into getting somewhere close to what they wanted for an MVP. What you also don't see is the understanding that goes behind a true app of any kind: the security measures, the pipeline for deployment, the performance and metrics for observability, understanding race conditions and debugging sessions, not to mention the nuances of any framework you work with.

This is the type of material that is perpetuating the "doom slop." It's abundantly available and constant, daily. I'm not against non-technical folk doing this type of work, but I would love to read the truth behind how it was built: the struggles around solving and debugging the issues, their newfound understanding of what engineers have to deal with when fabricating story points, and whether the product they built is tied together with jam and twigs, or honey and hope.

Where do we go from here?

Like with all advancements, there will be casualties. Jobs will be lost and companies will fold. At the same time, other jobs and businesses will be created that fit the supply and demand of the current market. Humans have a strong way of adapting to survive.

We are still, I believe, in the early days of AI. Yes, it's moving fast, but we still have an opportunity to learn and grow. Adapt to the change, adopt the new processes.

Like with a lot of frameworks and tools you've likely used in the past, there is always the right tool for the job, and you need to be conscious about how you use this one.

Let's stop idolising the tokenmaxxers and the senior-level types who expect you to work in a rigid process that doesn't fit your own workflows. Aim instead to find a process that works for you and build from there.

What am I doing differently

I'm valuemaxxing and trying to be deliberate about the way I use AI.

I have projects where I throw everything at AI and then refine and adapt as I go. There is no real roadmap or metric-driven analysis to direct features. But at the same time, I am its only stakeholder and developer so it's allowed.

Then I have commercial work that I do, and I am conscious about everything the AI is doing and whether it's the approach I would take. I utilise the agents to handle some of the idle work like documentation, updating test cases, quick research on some API documentation that's slipped my mind, or initial code reviews. I can then form my own opinions about what direction I go in and prompt the agents accordingly, reviewing and revising the plan and code changes as we go.

I've never been one to glorify metrics, especially around token spend, but in this new era, I haven't opted to steer clear of it either.

Command surface