A frontier AI coding agent Tony Stark is a highly intelligent and distinguished entrepreneur. When he was captured by bad guys, he was put in a cave and forced to deploy to production build rockets all day long. Although he was severely limited by his crappy corporate laptop given workbench tools, he still made it out of there alive using his wits and non- determinism.
Now suppose Tony Stark wasn’t hindered by his environment, was given proper tools, and the freedom to build whatever he wanted. How much more could Tony Stark achieve?
Now that we have powerful Tony Starks at our disposal, we would be mad to stick ’em in caves all day long. We want them to fly (build features), and have them crush our enemies (bugs) for us. So how can we do that? We’ll walk through the steps of building powerful Super LLM Soldiers in this blogpost.
But before going into the details of building them, we first need to get the lay of the land (in our case, our codebase) in which they’ll operate. After all, dropping Super Soldiers into a swamp isn’t always the best course of action…
Codebases are littered with bugs, legacy code and all kinds of traps looming underneath the crap that has accumulated for years. This part isn’t even specific to AI agents. As a developer, you’ve faced slowdowns because of incomprehensible code, slow CI, missing tool automation, etc. You’ve often just put up with it, because the work needed to improve these Developer Experience (DX) subjects sometimes just wasn’t worth the effort.
But the balance has shifted, because building things is cheap now, and so is building DX improvements. Keeping these slowdowns around also causes slowdowns (and extra costs) for AI agents. Suddenly cleaning up your “legacy code” is 10x more important because it compounds: You might have an army of Super Soldiers, but they are all stuck in the same swamp, barely moving forward. What’s more, AI agents tend to use the same patterns they see around them, meaning you’d better get your shit together, or they just keep piling on more crap.
Leveling the playing field #
The (deterministic) tools at our disposal to help us “clean up legacy code” (or at least to keep it at bay) are more important than ever. But some existing tools carry more weight now and can help our Super Soldiers do a better job overall. I’m going to highlight 2 topics that carry some surprising benefits for our Super Soldiers.
Linting
Ah, the good ol’ boring linting tools spamming us with warnings nobody cares about. But make no mistake, this superweapon has some hidden capabilities. First order of business is to make it fast (we want our Super Soldiers to fly, remember?). For node.js there is oxlint; for python you have ruff. Both are more recent linters, written in rust, and can get the job done quickly. Then you make sure they run when they need to, for example during pre-commit hooks in git, or stop-hooks in your agentic harness.
Combined with the superpowers plugin, which likes to git commit intermediate work items from bigger plans, your AI agents are getting deterministic augmentations and they receive +1 accuracy.
What about that “hidden capability” I just mentioned? Have a look at this example .oxlintrc.json file snippet:
{
"rules": {
"no-restricted-imports": [
"error",
{
"paths": [
{
"name": "@packages/data-source/ambient-mismatch",
"message": "Only the jest setup files route ambient-mismatch reports. Silencing them hides statements on the wrong connection: workspace/packages/CLAUDE.md § Repositories and transactions."
},
{
"name": "@test-packages/jest-setup",
"importNames": [
"collectAmbientMismatches",
"takeAmbientMismatches"
],
"message": "Only the jest setup files and the check's own specs read ambient-mismatch reports. Clearing them hides statements on the wrong connection: workspace/packages/CLAUDE.md § Repositories and transactions."
}
]
}
]
}
}
When the linting rule is triggered, here is what the AI agent sees:
x eslint(no-restricted-imports): 'takeAmbientMismatches' import from '@test-packages/jest-setup' is restricted.
1 | import { takeAmbientMismatches } from '@test-packages/jest-setup'
: ^^^^^^^^^^^^^^^^^^^^^
help: Only the jest setup files and the check's own specs read ambient-mismatch reports. Clearing them hides
statements on the wrong connection: workspace/packages/CLAUDE.md § Repositories and transactions.
See what is happening here? We are injecting additional instructions specifically for AI agents into our linting rules. Only when they go out of bounds do they get informed in this way. This trick gives our Super Soldiers +1 intelligence.
A11Y #
The Accessibility project, or A11Y for short, aims to help people with impairments better navigate our digital spaces. You might be wondering what this has to do with our Super Soldiers. Turns out that AI agents rely on the accessibility tree in our frontend applications to navigate the interface more efficiently. This has immediate benefits for your agents traversing your own frontend apps for development purposes. When I’m developing (generating) frontend features, I almost exclusively let Claude test them in Google Chrome. Having proper A11Y makes sure your Super Soldiers have +1 enhanced vision, spending less time (and tokens) testing your frontend application in the browser.
To quote Tara Agyemang from Google when she was giving a talk about WebMCP:
Making your site accessible for everyone makes it accessible to AI agents by default.
Let’s talk about the suits of our Super Soldiers! How can we equip our Tony Starks with the enhancements we need to do the best job they can?
I’m going to hurl a disclaimer grenade here that this blogpost is not advice you should take as-is. All the “advice” about doing “AI engineering” in the past year has aged like milk (“no, I’m not going to read the implementation plans”), so instead, I’m just going to show you how my Super Soldiers are equipped at this point in time. You can build and manage your own armor yourself based on your own environment in which they’ll operate.
Let me cover some of these specific types of equipment I’ve added to Tony. At the bottom, I’ll show a few examples of how those pieces of equipment could be used in tandem in various (and surprising) ways.
Observability tools #
One of the most useful ones - assuming you have already set up proper observability in your systems. These tools give valuable insights into all sorts of production and non-production systems. Equipping your agents with tools like Datadog MCP gives +10 enhanced vision to your agents, and enables various capabilities in combination with other tools. If your observability covers both logs and APM, you’re already golden. Similarly, tools like Langfuse MCP give us even more tracing information for specific internal agentic flows.
Simulation tools [local development setup] #
The workhorse of the armor. Manually setting up a local development environment has always been a bit of a pain. Not anymore, and especially if agents are able to spin up as many local environments as your system resources allow (my laptop can manage 4 stacks…). Being able to quickly spin up and tear down complete local environments, including all databases and local variants of cloud resources, is another game changer.
I have a dedicated /local-stack skill that knows how to use my own vibe-coded CLI tool built on top of process-compose. Striving to make sure you can run every part of your application stack locally (if resources allow) gives your Super Soldiers their own training simulator, and you’ll conquer those planets in no time. To illustrate, at Karomia, the core of our application landscape runs on Temporal. The neat part is that they have a temporal CLI specifically for development purposes, which makes your local stack setup that much simpler to manage. Hence, striving for those local CLI and Docker-based tools can be a real win for you and your troops.
Read-only dev database access #
Something I would never have said a year ago, but here we are. Giving agents (read-only, mind you) access to your dev/staging application database gives them +10 intelligence and +10 endurance. No more “can you run this query for me?” Let them figure it out themselves. I’ve built (let them build) an internal staging-db MCP server that gives AI agents direct read access. The MCP server contains 2 simple operations:
- Discover DB schemas
- Run SQL queries (read-only)
The nice thing about the “discover DB schemas” is that your agents are always able to see the latest DB table structures. By the way, did you know you can add COMMENT sections on database objects in PostgreSQL? A lot of our SQL migration files contain additional COMMENT sections now, which in turn helps any Super Soldier to find its way more efficiently in those environments. As with our linting tools, we’ve found another way to inject some additional context close to the source information.
COMMENT ON TABLE x.y IS 'This is a comment explaining some table details';
COMMENT ON COLUMN x.y.z IS 'This is a comment about column `z` of table `x.y`';
COMMENT ON FUNCTION fn IS 'Whatever really';
CI Autopilot #
Continuous Integration (CI) is more important now in the age of AI. Here is a modified quote from House of Cards that’s applicable:
It’s all about guardrails, guardrails, guardrails.
And CI is the ultimate guardrail. It sits between you (with your agents) and production. Look at it as the Stark Industries Satellite carrying “a plethora of defense systems”. You want to have those checks running at all times, checking the output of your non-deterministic Super Soldiers. And because we need to manage an army of those soldiers, the CI satellites had better have some decent signal bandwidth. Linear wrote a blogpost about optimizing your CI to increase that throughput triggered by the increase in AI coding.
Using the full armor #
When given certain tasks, AI agents are good at combining those tools in ways you wouldn’t have imagined. And that is where their true power comes from. Here are some examples I’ve experienced when working with these full Iron Man Soldiers.
Replaying scenarios
Can you reproduce this bug in staging?
⏺ google-chrome (3 times), staging-db-mcp (5 times), datadog (3 times)
⎿ > "env:staging service:backend-api status:error" (datadog)
…
⏺ I'm able to reproduce it and found the issue. Do you want me to create a PR?
Claude can:
- Traverse and click through your frontend application
- Check your application database to make sure the app stored and retrieved the correct information during its own runs. Step by step.
- Check error logs, APM traces during its own runs .
Testing new features locally
When you're done implementing plan X, spin up a /local-stack to verify it end-to-end.
⏺ Skill(/local-stack)
⎿ kdev up -1 --branch feat/some-feat
⏺ google-chrome (10 times), staging-db-mcp (10 times), datadog (2 times)
⏺ I've tested it end to end on the local database. The local stack is still running on http://localhost:14000 if you want to verify yourself.
Improve your /local-stack skill
Can you create a new database snapshot from staging, to be used for my /local-stack skills going forward?
It needs to contain a representative set of data covering scenarios X, Y, Z for testing purposes.
⏺ staging-db-mcp (10 times)
⎿ …
⏺ I've compiled a new local database dump only containing entities A and B. They cover scenarios X, Y, Z best.
Although these scenarios might seem straightforward, one of the big benefits is speed: Making sure the agent has access to useful tools allows it to reach its goal quicker, with more precision, and with fewer interruptions needed from you. You’re removing yourself as the bottleneck, and making them more autonomous in their missions.
Speaking of making them more autonomous: Now that you are building an army of these, you’ll need a way to manage them all. As you’re starting to send out more Soldiers on different missions, you’ll need a Mission Control System to keep track of the battlefield.
One option is to vibe-code it yourself, another option is to use the third-party tools that are starting to mature now. One example is Herdr TUI (they recently released a standalone app as well). These tools aim to sit at your highest level of operation: They mean to be the coordination layer between all your different AI agents (Claude, Codex, Pi, …), as well as across different systems (laptop, home servers, VMs). I can recommend herdr myself, but lots of other tools exist in this space as well.
What’s next? #
Who knows? The only thing I do know is that building things is cheap now. So make the most of it. Go conquer a planet ;)
Last modified on 2026-11-09