I was at a F500 sync in New York recently, and this idea came up: 100% of your developers should be building things to improve the workflow.
So I asked the room how many of their team are actually doing the work.
My answer: not many.
People were not surprised, but also wondered how to get their teams to think about the system.
Now you could probably comment me any one company that's breaking this paradigm, ships quickly, and has every engineer tuning their workflow all day. But I'd probably tell you this is like learning about Walmart in undergrad. There's always an example, and then there's the big middle. Which leads me to ….
Fixing the 'execution output' vs. fixing the machine
Most people blindly accept the output without considering what the output means. Or, if the build breaks, they fix the 'execution output' by hand just to close the task.
I don't have enough fingers and toes to count in my individual commits when I've tried to fix something and the commit messages become fix and really fixed.
I wrote recently about how agent lineage is really a SIPOC (Suppliers, Inputs, Process, Outputs, Customers) problem. If try 11 yields a bad result while tries 1-10 were fine, changing the output of try 11 by hand doesn't help you on try 12. The process step is still broken.
Take cosm as example. I've had forms of this while building it, where agents want to revert to what's in the existing knowledge base, and we repeat bad behavior.
Building the test cases in cosm was surprisingly difficult and I had to keep re-prompting agents to do the work. Eventually I found a set of adversarial prompting began to round out the work better. If you don't go back into the system and update the knowledge base (AGENTS.md, skills, or AST's), the agent just slides back to whatever it knew before.
Why aren't people thinking about the system?
I think it comes down to two things.
First, ownership is dirty.
You have to consider that when people are owning, it's on-call and other things that we don't like. If you just edit your own PR output and merge it, you don't own anything new. If you build a shared skill or a workflow check for the repo, now you're on the hook when it breaks.
And there's the dirty work of AI too: figuring out what the intent is, and the test cases or integration cases. But no one wants to own the harness because 'owning' implies 'overhead'. You have to support potentially many people, when, instead, you can just ship the code and move on to the next task.
Second, people are task oriented, they aren't incentivized to fix the machine, and they don't think they're qualified (we all are, everyone is figuring it out).
When people do code development, we've made an unconscious trade-off where the person writing the code is the knowledge base, and while we may have a few tests and docstrings or readmes / wiki's, let's be realistic, those are usually up to date at version 1.0 and then subsequently rot.
Ultimately, the incentives for developers are still task oriented: ship the code, close the ticket, report friction on a harness someone else built. The incentive has to change.
The reality: many are still figuring out the playbook. In my day to day, I regularly have sessions where I ask models to introspect, look at prior sessions, and see what happened. I rely on my developer experience to build mini systems of improvement so each project gets better over time (usually).
Getting teams to think about the system
I've been putting some of my own examples into agent-skills to showcase a few ways I'm improving the flow (AST plugin, other development skills).
I built it because I found the agent just scanning thousands of lines of code, being slow, and inefficient. I'm trying to build good things for an economic cost.
We're also using multiple harnesses and models, and building evals (using prior sessions as baselines).
I'll use for example Argon, then I'll ask Opus to validate the plan before implementing. Or I'll use one model for a bit, then ask in a new session for a different model or agent to validate the work and find bugs.
For evals, I ask for the equivalent of a sketch where the session is replayed with key components that have been swapped out. You could also do this with git commit branching and worktrees.
Developers have to own their systems, not the output.
AI is a 200 MPH (~320kph) sports car that goes fast on well built roads. If your pipeline forces offroading, and slow going, AI will compound a wreck.
For companies, if you want engineers to care about the roads, you have to reward the dirty work around intent, test cases, and the harness itself.
For the individual, keep investing in how you build and tune your own agent systems. Making your workflow better is transferable across whatever repo or company you work on next.
How are you getting your teams to think about the system? Hit me up in the comments!