I’ve been building Greenflagged, a security-focused package registry, for a few months now, and I’ve noticed a handful of mistakes that agents have made while working on the codebase. The most striking thing about these errors is just how human the mistakes are.

Problem-solving

Prior to the widespread use of AI coding tools, I used to sit down with a problem I was trying to solve in code and “poke” at it for a while. This often involved setting up test environments, extracting pieces of code for isolation, and generally trying new things until finding a solution I liked.

As I’ve watched coding agents work, I noticed they generally fall into the same cycle. The difference is that they have a nearly endless knowledge of tools available to them. Agents don’t have to look up awk syntax or have large blind spots in their tool-use knowledge. I’ve watched them use CLI tools I’ve never heard of to validate ideas and then incorporate them into the larger solution.

Claude can work the same way that I work, but faster. One of the best traits I’ve noticed in software engineers is persistence. They don’t give up when a solution doesn’t work out as planned. They dig in their heels and figure out another way. This can be frustrating to humans and cloud judgment. Agents don’t care, however. They are happy to try an alternative method until they find something that works. A fresh context is like coming back to a tough problem after a good night’s rest.

Tuning your workflow

Your workflow and process are the most important things you can focus on when you want to create long-term sustainability. Just like humans, agents’ work needs to be reviewed. My current change review process is shaped very similarly to some of the most successful continuous delivery pipelines that I’ve built.

After defining the feature that I want to build (that’s another post…), an agent will plan the implementation, and then multiple agents review and iterate on the plan (read on to learn more about that). After the plan is finalized, an agent builds it and submits a Merge Request (MR). A new agent runs a change-review skill which attempts to validate the change. Different reviewers look at the MR from different perspectives and provide feedback. Fixes are made and another review round runs. CI runs tests and validations to make sure the project builds cleanly and the tests pass.

This is the same process I would use back in 2020 when humans were writing all the code by hand. As a senior reviewer at the time with many review requests, I often wore the hat of “how does this change impact the system” rather than checking for logical correctness. Other reviewers that were closer to the business requirements were able to validate those types of changes. Different humans looked at the change from differing perspectives.

Types of mistakes I see and how I mitigate them

So what do I do with this realization? Next I’ll highlight the three biggest leverage changes I’ve made to my Claude Code workflow. I’ve provided links to the agent definitions, but it’s probably best if you ask your agents to create your own versions of agents to solve the problems you face.

Assumptions

🙋🏻‍♂️ I’m guilty of making assumptions about how code works and being wrong. Generally this turns up at some point of the software development lifecycle, but I’ve certainly shipped bad assumptions to production before.

🤖 Agents only have the context you give them. Anything they don’t discover for themselves or are told is going to be an assumption.

The Skeptic

False assumptions are what led me to create my first subagent, The Skeptic. The skeptic is in charge of, well, being skeptical of all claims. It confirms assumptions and pushes back when it cannot find facts to support an assumption.

While trying to eliminate some false positives a few months back, an agent claimed that it could remove a piece of code because it was covered by another code path. The suggested fix would have added a blind spot to the Greenflagged alerting system. As part of the code review process (yes, code reviews are still important), the skeptic agent identified this new gap and prevented it.

Logical errors

🙋🏻‍♂️ When learning to code, you encounter logic errors and syntax errors. Syntax errors generally mean you typed something wrong, and machines can usually reformat the issues. Logic errors are more subtle, and while they can be based off a poor assumption, they aren’t always caused by that.

🤖 A real issue appeared in Greenflagged. When I approve a package, the AI shouldn’t be able to reject it again later. While planning a fix for that issue, a logic agent spotted an issue that could have let the system re-approve a package I had rejected. The review process caught this before any code existed.

The Logician

Enter The Logician. It is in charge of reviewing the structure of an argument, whether the conclusion actually follows from the premises. It returns a confirmation, names gaps that may need to be verified, and completely broken assumptions that more evidence will not verify.

I use this agent as part of the design and review process. It very usefully pushed back on me when comparing different models to do package evaluation. The agent was able to spot logical flaws in my plan and help come up with a solution that made sense.

The short-term thinking trap

Software only needs to be as good as its use requires. A script to sort through some files a single time doesn’t need to run as efficiently as possible. A prototype doesn’t need to scale. Operating software for the longer-term requires bigger and more long-term thinking. Storing 100 package versions and all their large blobs of metadata in a relational database is fine. Doing this for millions of package versions is going to take a lot of space for something that will rarely be used.

🙋🏻‍♂️ While trying to iterate as fast as possible, I didn’t pay close enough attention to keeping operational and request data away from larger shapes of data. Agents came up with designs that kept most everything in Postgres, when some of that should have been offloaded to object storage. Classifying the data types and access patterns up front and picking appropriate storage for the scale would have saved a lot of migration work later.

🤖 One small login change would have created millions of URLs that search engines would hold onto for months. The steward caught it, and the fix was one HTML attribute (nofollow).

The Steward

If you’re planning long term, The Steward is an invaluable addition to your agent workflow. It is able to narrow its view and focus on the long-term costs of the suggested changes. I advise it not to block, but to gently steer decisions in ways that will help grow gracefully.

Follow the process

An agent properly diagnosed a failing Redis instance. Redis was persisting things to disk, and Sentinel health checks timed out during that. The agent merged a change to disable persistence and assumed the change would take place automatically. It validated that the ConfigMap updated correctly but failed to restart Redis which caused it to continue to save to disk. The agent skipped a production validation step that would have caught and fixed the issue. As a result, I now make sure agents know how to validate the results of their effort.

These three agents are the highest leverage changes that I’ve made to my workflow so far. Shorten feedback cycles for both humans and agents. If it’s useful for a human, it will probably be useful to an agent. The reverse is not necessarily true.

Where the comparison breaks down

Of course agents are not going to behave exactly like humans. They lose context session to session, and model updates improve and change behavior. Even trying to enforce that they stick to a process can be difficult.

Agents also don’t get frustrated. As I said before, they will iterate on things until they find something that works. A robot will be perfectly happy to deal with normally frustrating user experiences. Greenflagged brings this idea to dependency management. Not only does it block malware spread via supply-chain attacks and credential theft, it also removes vulnerable dependencies as issues are discovered. This results in a broken CI build when dependencies fail to pull, which would be infuriating for a human. Greenflagged makes tools and dependency suggestions available to agents, keeping your production software safe when added to an automated development cycle.

Greenflagged currently serves npm packages and is free for individual use.