{"slug": "tony-stark-vs-iron-man", "title": "Tony Stark vs. Iron Man", "summary": "A blog post argues that AI coding agents inherit the flaws of the codebases they work in, so developers should invest in deterministic tooling such as fast linters (oxlint for Node.js, ruff for Python) and pre-commit or agent stop-hooks to keep legacy code and bugs from compounding. The post contends that because building software and developer-experience improvements is now cheap, cleaning up codebases is roughly 10x more important for agent productivity, since agents tend to copy the patterns around them. It also describes using lint rules like no-restricted-imports to embed guidance directly in error messages for agents.", "body_md": "~~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.\n\nNow 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?\n\n# Remove the constraints\n\nNow 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.\n\nBut 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…\n\n# Hostile planets\n\nCodebases 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.\n\nBut 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.\n\n## Leveling the playing field\n\nThe (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.\n\n### Linting\n\nAh, 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](https://pre-commit.com/) hooks in git, or [stop-hooks](https://code.claude.com/docs/en/hooks) in your agentic harness.\n\nCombined with the [superpowers plugin](https://github.com/obra/superpowers), which likes to *git commit* intermediate work items from bigger plans, your AI agents are getting deterministic augmentations and they receive **+1 accuracy**.\n\nWhat about that “hidden capability” I just mentioned? Have a look at this example `.oxlintrc.json` file snippet:\n\n```\n{\n    \"rules\": {\n        \"no-restricted-imports\": [\n            \"error\",\n            {\n                \"paths\": [\n                    {\n                        \"name\": \"@packages/data-source/ambient-mismatch\",\n                        \"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.\"\n                    },\n                    {\n                        \"name\": \"@test-packages/jest-setup\",\n                        \"importNames\": [\n                            \"collectAmbientMismatches\",\n                            \"takeAmbientMismatches\"\n                        ],\n                        \"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.\"\n                    }\n                ]\n            }\n        ]\n    }\n}\n```\n\nWhen the linting rule is triggered, here is what the AI agent sees:\n\n``` python\n  x eslint(no-restricted-imports): 'takeAmbientMismatches' import from '@test-packages/jest-setup' is restricted.\n   1 | import { takeAmbientMismatches } from '@test-packages/jest-setup'\n     :          ^^^^^^^^^^^^^^^^^^^^^\n  help: Only the jest setup files and the check's own specs read ambient-mismatch reports. Clearing them hides\n        statements on the wrong connection: workspace/packages/CLAUDE.md § Repositories and transactions.\n```\n\nSee 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**.\n\n## A11Y\n\nThe Accessibility project, or [A11Y](https://www.a11yproject.com/) 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](https://developer.mozilla.org/en-US/docs/Glossary/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.\n\n[To quote Tara Agyemang from Google](https://youtu.be/ghJmWQCIHRM?t=185&si=tzhkbu-P-ZT-3_Pi) when she was giving a talk about WebMCP:\n\nMaking your site accessible for everyone makes it accessible to AI agents by default.\n\n# Mark v2\n\nLet’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?\n\nI’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.\n\nLet 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.\n\n## Observability tools\n\nOne 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](https://docs.datadoghq.com/mcp_server/) gives **+10 enhanced vision** to your agents, and enables various capabilities in combination with other tools. If your observability covers both logs and [APM](https://en.wikipedia.org/wiki/Application_performance_management), you’re already golden.\nSimilarly, tools like [Langfuse MCP](https://langfuse.com/docs/api-and-data-platform/features/mcp-server) give us even more tracing information for specific internal agentic flows.\n\n## Simulation tools [local development setup]\n\nThe 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.\n\nI have a dedicated `/local-stack` skill that knows how to use my own vibe-coded CLI tool built on top of [process-compose](https://terminaltrove.com/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](https://temporal.io/). 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.\n\n## Read-only dev database access\n\nSomething 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:\n\n- Discover DB schemas\n- Run SQL queries (read-only)\n\nThe 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](https://www.postgresql.org/docs/current/sql-comment.html) 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.\n\n```\nCOMMENT ON TABLE x.y IS 'This is a comment explaining some table details';\nCOMMENT ON COLUMN x.y.z IS 'This is a comment about column `z` of table `x.y`';\nCOMMENT ON FUNCTION fn IS 'Whatever really';\n```\n\n## CI Autopilot\n\nContinuous Integration (CI) is more important now in the age of AI. Here is a modified quote from [House of Cards](https://www.youtube.com/shorts/2lLUySXxtcs) that’s applicable:\n\nIt’s all about guardrails, guardrails, guardrails.\n\nAnd CI is the *ultimate guardrail*. It sits between you (with your agents) and production. Look at it as the [Stark Industries Satellite](https://marvelcinematicuniverse.fandom.com/wiki/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](https://linear.app/now/ci-bottleneck-reworked) about optimizing your CI to increase that throughput triggered by the increase in AI coding.\n\n## Using the full armor\n\nWhen 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.\n\n### Replaying scenarios\n\n```\nCan you reproduce this bug in staging?\n\n⏺ google-chrome (3 times), staging-db-mcp (5 times), datadog (3 times)                                         \n  ⎿  > \"env:staging service:backend-api status:error\" (datadog)                                                    \n     …  \n⏺ I'm able to reproduce it and found the issue. Do you want me to create a PR?\n```\n\nClaude can:\n\n- Traverse and click through your frontend application\n- Check your application database to make sure the app stored and retrieved the correct information *during its own runs. Step by step.*\n- Check error logs, APM traces *during its own runs* .\n\n### Testing new features locally\n\n```\nWhen you're done implementing plan X, spin up a /local-stack to verify it end-to-end.\n\n⏺ Skill(/local-stack)\n  ⎿  kdev up -1 --branch feat/some-feat\n⏺ google-chrome (10 times), staging-db-mcp (10 times), datadog (2 times)\n\n⏺ 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.\n```\n\n### Improve your `/local-stack` skill\n\n```\nCan you create a new database snapshot from staging, to be used for my /local-stack skills going forward? \nIt needs to contain a representative set of data covering scenarios X, Y, Z for testing purposes.\n\n⏺ staging-db-mcp (10 times)   \n  ⎿   …                                     \n⏺ I've compiled a new local database dump only containing entities A and B. They cover scenarios X, Y, Z best.\n```\n\nAlthough 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.\n\n# Mission Control\n\nSpeaking 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.\n\nOne 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](https://herdr.dev/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.\n\n## What’s next?\n\nWho knows? The only thing I do know is that *building things is cheap now*. So make the most of it. Go conquer a planet ;)\n\nLast modified on 2026-11-09", "url": "https://wpnews.pro/news/tony-stark-vs-iron-man", "canonical_source": "https://blog.codemine.be/posts/2026/20261001-lean-in/", "published_at": "2026-11-09 11:07:49+00:00", "updated_at": "2026-11-09 11:21:54.785527+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Tony Stark", "Iron Man", "oxlint", "ruff", "pre-commit", "superpowers plugin", "Claude"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/tony-stark-vs-iron-man", "markdown": "https://wpnews.pro/news/tony-stark-vs-iron-man.md", "text": "https://wpnews.pro/news/tony-stark-vs-iron-man.txt", "jsonld": "https://wpnews.pro/news/tony-stark-vs-iron-man.jsonld"}}