At the Gates of Slop

The title is a riff on “At The Gates Of Sleep”, a banger Melodic Death Metal song by Insomnium. I was listening to it as the idea for this post came to my mind, and the pun was too good to give up. Give it a listen:

My position is simple: LLMs are excellent when they amplify your own work, tolerable when they automate short-lived transactional work, and corrosive when they are used to push unreviewed cognitive labor onto people who trust you. Read on to see how I got here, and whether you’ll land differently.

How AI Literate are you? Take this quirky quiz

Which Power Ranger are you? Take this quirky quiz

Obama sent the immigrants to vaccinate your kids

~Welcome to the Internet, Bo Burnham

This post is aimed at most software developers, but depending on your approach to Agentic Software Engineering practices (your “AI Literacy”), you will read this differently. So let’s have a small exercise. Score yourself:

Statement	Score (1 - Strongly Disagree, 5 - Strongly Agree)
For a full workday of software development, I use around X million tokens on a good workday. Replace X with: 1 -> 0M Tok/D, 2 -> 1M Tok/D, 3 -> 4 MTok/D, 4 -> 15M Tok/D, 5 -> 25M+ Tok/D	1 / 2 / 3 / 4 / 5
Code has now become compilation output; it can be completely and correctly regenerated by AI if the spec is good enough	1 / 2 / 3 / 4 / 5
AI Code Review is better than human code review, therefore human code review isn’t required	1 / 2 / 3 / 4 / 5
AI SRE agents are strictly better than human SREs; let’s give them production access so they can remediate production issues	1 / 2 / 3 / 4 / 5
The price of experimentation is asymptotically zero; “you can just do things”	1 / 2 / 3 / 4 / 5

These are just a few examples, but they should capture where you’re at in my highly unscientific classification. These strawmen, so usefully displayed here for my arguments, are closely related in my head to Steve Yegge’s “Flat Curve Society” definition of “AI Literacy”.

• 5: You don’t use enough AI to understand its benefits for software engineering. As the San-Francisco-koolaid-drinkers like to say, you’re “NGMI”.
• 10: You are a bit late, or maybe very disillusioned by AI output you’ve seen.
• 15: Single agent running all day, learning about new plugins or workflows, but still; there’s a deep and underlying sense of distrust whenever you see an em-dash.
• 20: Power user, multiple agents, productivity is high (for some definition of productivity). Code is a means only. Maybe you have a few managed agents running doing some drudgery for you, but you’re still there in the critical path.
• 25: You have transcended; instead of doing the work, your work is building a thing that will build a thing that will do the work. The only way to contact you with AI in the way is to find you in a dark alley and whack you over the head with a tire iron. People who have to interact with you often entertain this thought as they read yet another generated wall of text from you.

If you scored low; read this post explaining my position on agentic development as a hopeful sign that you’re not alone; there are people that share your distrust of AI, and YES, you can adopt it in a useful way. It’s not all or nothing.

If you scored high; read this post as a warning sign; some experienced people see hopium-based “we can replace our engineering org with a dark factory” influencers, but they don’t like it.

Generally, I hope this post will bring you to a good middle; I myself scored 18-ish, with high scores for usage, but low scores for palatability or no-review.

Why are we even talking about this? Just look at the numbers, man!

Clearly, using Agentic AI for software engineering is a really good, really bad, or a neutral idea, depending on your preconceived notion. It is also highly informed by whether you work for one of the AI labs or Dev Agent companies. What a coincidence!

On one hand there are many articles showing how good AI is for software engineering; it’s obvious it increases productivity! On the other side, articles showing that counting PRs isn’t the way to measure, that quality is plummeting, that most work is becoming re-work, etc.

It might seem like I’m cynical about this research. I’m not! It’s useful and interesting. I always read new research in this field; I have experience as a Developer Productivity lead so it’s somewhat in my wheelhouse (even if it’s not my day job right now). So far, my conclusions haven’t significantly changed:

1. It Depends ™. What works for Google doesn’t work for your startup.
2. It’s always been hard to measure software engineering productivity. DORA metrics, DX Core 4, lines per dev. All metrics are flawed, and Agentic software engineering hasn’t changed that; it only added MORE variables (token cost for example) that makes measuring even worse.
3. Increasing velocity != profit. A team member that consistently made mistakes and had bad judgement, with the ability to 10x themselves, will make 10x more mistakes. A vector isn’t only made of velocity, it also has a direction.

So I feel like I can’t “just look at the numbers” to understand what I should do; I need to develop a sense of taste for this… stuff. This post is my attempt to share this taste that I’ve developed over the last few months with you.

Standing at the gate

“Men rarely see their own actions as unjustified.”

~ Brandon Sanderson, Mistborn: The Final Empire

My original intro to computers was, as many other people, through video games. And I have some B.Sc.-level understanding of Game Theory. Therefore my allegory and internal monologue (not that internal anymore, eh?) will have a lot of that nomenclature.

So here’s my taste decision.

The good - where agents help

Agentic software development, applied well where it fits, is generally useful for productivity. This is, generally speaking, in (1) single-player scenarios, in (2) Fuzzy RPA scenarios, or in (3) one-shot & few-turn engagements. What do I mean by that?

(1) Single-player scenarios

Single-player scenarios in software engineering are things that you would have done mostly yourself or with “extreme programming”; brainstroming different designs, reviewing a design, writing code and tests, monitoring deployments and metrics after release. As an example, running a Coding agent to build a plan based on specs. Then running another one to develop a feature and test it locally using a browser tool. These are good uses of resources (time, tokens, attention). When it’s mostly used as a tool to enhance the operator.

This unlocks some really cool workflows as a single developer that didn’t exist before. Like, for example, “just trying things”; why not, overnight, set up a loop on a side branch to do a really big upgrade? Why not, over the weekend, let 7 different agents try to finally implement that E2E testing flow you always said you’ll get to, at some point? Why not review your code 3 different times with 3 different models before handing it in for human review? Other than your own attention and time and the token cost, these are things you can do now that I feel would have REALLY been difficult before.

I honestly think this is where a lot of the 10x/100x productivity claims you sometimes see on X and LinkedIn come from. It’s from solo hackers that just always work alone, and therefore most of their work is single-player. The agents can truly augment them.

(2) Fuzzy RPA scenarios

The Fuzzy RPA (Robotic Process Automation) scenarios are things that are clearly repetitive drudgery, like updating minor dependencies for security and testing that nothing got broken. Theoretically these are things that were 80% close to being deterministically automated, but the fuzziness of the world makes a while loop with an LLM and some tools really useful for these sorts of jobs. This meets me both with in-app AI features and custom agents.

In-app AI features: like Linear’s Slack bot. I like Linear because, amongst other things, it automatically moves tickets to “review” when the PR is ready for review and to “done” when the PR is merged. That takes care of some chores for me, without LLMs. The “take free text from Slack and create a ticket with all the fields filled out” feature takes off some grunt work as well. One of these features is deterministic, the second needs LLMs to operate; it’s a “Fuzzy RPA” scenario. Linear is also coming out with “loops” which are more agentic, and I’ll need to check those out as well.

Custom Agents: Of course, there are cases for this which aren’t “in-app”, but are actually workflows you build with your agent. “Review all customer call transcripts for mention of feature X to collect all the feedback over the last 7 days”. Or “Monitor my PRs and fix obvious CI issues until they pass”. Stuff that one could do with a human, couldn’t really automate with fully deterministic software, and is now possible with an agent.

To do this “good application”, human involvement is needed at various touchpoints. It seems to me, generally, like a bad idea to attempt to frontload everything. Like with junior employees, it will help the task at hand to have some check-ins. Concrete example for me would be using crit to review the plan before implementation. It also has meant to me a step back from trying to connect lots of MCPs and mostly focusing on defining each task well enough so the agent can do it without too many tools etc.

(3) Single-Shot and Few-turn engagements

The shorter the relationship, the less reputational debt you create by using low-attention automation. The longer the relationship, the more every sloppy automated interaction trains the other person to trust you less.

I feel like most interactions I have with other people are long ones. In my profession (Software Engineering) and industry (B2B), the people you interact to work with tend to stay the same; team members are the same team members, customers are the same practitioners in the same company (sometimes for YEARS). But, there are cases where there’s “few-turn engagements”, e.g. a support request to a vendor that’s a big corp, or a bug report to an open-source project that we don’t often talk to. Why does the “length” of the engagement matter? To me, it’s a “Prisoner’s Dilemma” strategy.

Ever since LLMs have permeated every corner of my world, I see lots of interactions with people and organizations as a “Prisoner’s Dilemma” game. Choosing a human-curated, lots-of-attention based approach is risky for me, but is nicer: that is the “cooperate” choice. Choosing an LLM-generated, no attention approach is not risky for me at all, I didn’t “pay” any attention on it, but it’s not very nice. This is the “betray” approach.

x vs y	Cooperate	Betray
Cooperate	Two humans engaging in conversation, perhaps aided by LLMs	One person talking to an LLM in a roundabout way, doing the work for both
Betray	One person talking to an LLM in a roundabout way, doing the work for both	Two LLMs talking to each other until one of the humans grabs the reins

Here’s the ChatGPT-generated version of this table:

Note that the “human”/“cooperate” choice requires SOME human attention but of course that human attention can be used to edit or review LLM output, doesn’t have to be manual.

Then, there’s the perception over time:

timeframe / “usual behavior”	I usually Cooperate	I usually Betray	Opponent’s strategy
“Single shot” engagement (e.g. a support request)	Doesn’t matter, it’s a single shot	Doesn’t matter, it’s a single shot	N/A
“Few-turn” (e.g. Open Source ticket)	There’s a better chance I’ll give this human attention	Better chance I’ll use LLMs for this	“Tit-for-tat”
Long-term (e.g. working with a team member or a B2B customer)	Over time, I’ll bias to giving this human attention, prioritizing this “player” over others	over time, I’ll bias to using LLMs for this “player”, deprioritizing my attention for them	Weighted “Tit-for-tat”

Over a short term engagement (for example; I put in a support request to a big corp), I can start with an (almost) fully LLM-based ticket given the right context. It’s what the other party expects so it’s polite enough, and it won’t have long-term negative impacts.

In short-term engagements it might also be the case that the 2 LLM approach (betray and betray) might be able to figure it out without any human. If on my end it’s a short term engagement and on the other side the agent is Fuzzy RPA (e.g. reset a password support request), then 2 LLMs can just “do the thing” without humans involved. That of course has risks of its own. But it’s important to highlight; in the normal Dilemma, there’s never a happy end to “both betray”, but in this case it might work itself out.

The bad - where agents suck

Agentic software development, applied as “agents can do everything, let’s only focus on building the factory”, is not useful for productivity. It’s also demoralizing to most team members. This is in multi-player scenarios, unlike the ones we tallied above.

Trust and respect - slop is attention debt

When you just send unreviewed slop at team members, when they talk to you and you let an LLM respond, when you avoid details; eventually a bug or a not-quite-right message makes it through your factory. And team members don’t see the factory, or the potential numbers you are promising. They remember the slop. “Oh, that dude(/ette) can’t be trusted, I can just send it to Codex myself”.

In the next few paragraphs, I’ll go through examples of this, trying to highlight the bad to help you avoid it. But the most important point I want to make is that this is about respect. There’s a really good quote I can’t place right now: “There’s only so much time, thank you for yours”. Sending people slop is first and foremost, disrespectful. If you’re a parent (like me) you can imagine how’d you feel if your teacher gave your kid LLM-generated, non-reviewed homework with mistakes and em—dashes throughout. You’d be upset, right? That’s really disrespectful to your child. The teacher had a job to do, but they preferred to prioritize THEIR “productivity” over your child. And I’m picking the teacher example because unlike in software engineering, the teacher is REALLY starved for resources, has no time, and has to deal with MANY students. Now let’s compare to a software engineering team… You can see why sending unreviewed slop to a colleague is disrespectful; they have a job to do, they expect you to do yours, and you are prioritizing your time and attention over theirs.

And you know what they say about respect…

LinkedIn, for example, is the public version of this failover mode. That’s why everybody I talk to feels that the feed on LinkedIn is kinda… disrespectful of their time. I feel like many people & brands on LinkedIn are disrespectful to me; they send out AI slop as a post, all the posts look and read the same, all the comments are AI generated. And don’t take it from me; LinkedIn are saying so, themselves. So you have people generating slop and they’re sending it out to thousands of followers, but… did they even read it?

How many people should we have on this?

To a point, it’s useful to develop productive workflows for agents; mostly, this aligns with developer productivity efforts your organization would have already. But for the most part, the people who work on improving the factory aren’t most developers. To know how many I always refer to the best blogpost I know about this: “Let a 1,000 flowers bloom. Then rip 999 of them out by the roots” by Peter Seibel.

The answer, turns out, is 0 people in a 10 person team, 2 people in a 100 person team, and 255 in a 1,000 person team. Sidebar: now that AI made everything easier, there’s a point to be made that you need even FEWER “develop productivity” people because everyone will do the extra automation themselves with an agent, or maybe MORE “platform” people, to work on agent effectiveness as well as human effectiveness. My sense is that you need FEWER people working on this kinda thing, because developers now “feel the pressure” of automation as their agents fail to scale. But maybe more authority to a few opinionated architects/staff engineers, to make sure all the devs’ ideas have good taste.

The important part for me is that not every outcome required from a software team requires a factory to deliver.

But you don’t need Seibel’s writing to get a sense for this. Would people want you to build and bring a large factory into their kitchen? Probably not. And in software engineering, while there are organizations at huge scale, most good software is modular and small, managed by small teams that are in charge of some parts of it. So it turns out that it’s a lot of small kitchens.

What’s the bad part about all of this? Well, its that too many people want to be the factory owner, builder, operator. Just not the worker that actually does stuff.

2nd order effects

Making a few parts of the software development life cycle cheaper has 2nd order effects and doesn’t mean that the whole process is cheaper, immediately. If you’ve read The Goal this should make intuitive sense to you; making a cheap and fast machine on the factory floor cheaper and faster might introduce more backlog to more expensive, slow, and important machines.

One obvious one that I’d like to point out as a personal pet peeve of mine has been the thorny topic of Code Review. Creating code became cheaper, but the PRs aren’t getting merged as fast! Why? Oh, the pesky code review process. It’s a bottleneck. And what do we do with bottlenecks?

Removing bottlenecks as a pasttime activity

The toxicity of our city, of our city

~ Toxicity by System of a Down

Thinking about that word, bottleneck, as a negative, is really funny to me. Let’s see you pour wine out of a broken bottle, or merge two lanes into one without cars slowing down, yeah? Looking up the definition, it’s focused on SPEED, and SPEED only:

bottleneck, noun: A point of congestion in a production system that prevents it from operating at full speed.

So, here’s my taste decision: Yes, I am a bottleneck. I will do outrageous things such as review code (“Really? You read EVERY line? How?”) to find bugs, maintainability issues, readability issues. I will question priorities. I will suggest improvements. I will look for root causes. I’ll take PRs as an opportunity to teach, and to learn.

The one about AI Code Reviewers

Yes, we can use AI to do a first pass on the code. I think this is a relatively good spend of time and tokens - the developer pushing the PR can use an adversarial mode to find relatively basic issues. I think we should do this not only at the code review stage - that’s often too late - but also in the design and planning stages. This is classic “single-player” unlocks that didn’t exist before! You can get 7 code reviews on your code really quickly before showing it to your coworker. That’s really cool and respectful (if you actually look at it yourself).

BUT - after trying out many different AI code review software vendors, they are not good enough to totally replace human code review.

To cover my ass, I’m willing to add the word “yet” here. But I don’t think it’s a matter of model capability. The CR is today the best place to sync up the team’s mental model on where the software is going to, and whether they agree. So I guess I’ll amend my “yet” to say “as long as software engineering is a team sport”.

WHY? Do you hate progress?

My feelings are separate from the reality I’m trying to understand and present here… But we are emotional animals, so let’s address the feelings as well. Because they do exist, and they do matter.

I am not a luddite. I use these LLM things all day every day. I use AI features in my normal consumer apps. I actually find the underlying technology fascinating. But, at the same time, the identity crisis is real. There are fears, and rationalizing them – even if the rational is correct – doesn’t make the underlying fears go away, normally. Is my job changing? Is my career path dead? Is my skillset becoming redundant?

There are other feelings - it does feel really cool to solve big problems fast, cheap, and well. I remember specifically being able to run a pretty good pentest while on vacation with a multi-agent Claude Code setup, all for ~$400, and ending up with some real findings and an in-depth report. That was really cool. I remember another day where I have 7 agents running in parallel worktrees (basically as many as my machine could handle), and closing more than 12 PRs in a day, with two of them being actually important ones. I remember conversations with really interesting people in San Francisco about AI; “It’s like an alien life form that landed here, and we’re asking it to re-write our emails”.

It does bad, stupid things. It was created relatively immorally. It costs a lot of money to use, and have real environmental impact. But, I’ve seen it really help people in their work. Recently, a (relvatively old and not-tech-savvy) family member of mine used Claude to present a strong anti-exploitation case to their employer, a greedy private hospital. Is AI bad if it helped someone do a good deed?

I’ll summarize and say that unlike the AI Antagonists or LLM Lovers of Twitter 𝕏, my feelings about LLMs, AI, and Agentic Software Engineering are… mixed.

When in Rome

But, I do live in the San Francisco Bay Area. People literally present themselves in AI meetups as “Hi, I’m X and I use over 4 million tokens a day”. And I do work in an AI-native, AI-focused company. So I will continue to use, push, and experiment with Agentic Software Engineering, LLMs, etc. etc.

Flat Curve point-making

The context of this post is right around the Fable re-release, and the GPT Sol Luna Terra models. But I’ve had something like this in mind for over 6 months. Why is this important? At ElevateDev ‘26 I heard a really good point; we tend to look at the last three months, and the upcoming three months, and say “this is not advancing; we’re in a flat curve”! So just remember this when reading this post; models may improve enough that some of the points I’m trying to make here won’t be true. But I’d like to think that since most of them are actually about culture and behavior, they’re kinda orthogonal to model advances, and therefore evergreen.

I will not accept slop, and I’ll do my best to not produce it.