Agentic Stack for Solidity Development 2026

We’ve been quiet for a while. Not because there was nothing to say, because the way we write contracts changed underneath us, and I wanted to ship the new workflow before writing about it. This channel is pivoting: less “here’s a cool library,” more “here’s how AI and Solidity actually fit together in production.” Starting here.

The shift to new realities

A year ago, “AI for Solidity” meant autocomplete and a chatbot in a side panel. In 2026 it’s a different shape entirely: an agent with tools, running a loop. It reads your repo, calls a compiler, runs your tests, inspects on-chain state, proposes a diff, and iterates — without you in every step.

That’s powerful and dangerous in equal measure. The same loop that lets one dev scaffold a protocol in a weekend also lets an attacker point a model at your verified source and ask it to find the money. So the stack below isn’t “tools that make you faster.” It’s a discipline: agents write, deterministic tools verify, you sign.

Here are the five layers.

Layer 1 — The coding agent

This is the core of the loop. Claude Code and Cursor both write Solidity natively now and both run in an agentic mode that can edit files, run commands, and read output across turns.

The model matters less than what you feed it. A bare agent pointed at a Foundry repo is mediocre. The same agent with project context, the right tools wired in, and hard verification gates is a different animal. Layers 2–4 are what turn the toy into infrastructure.

Pick one, commit to it, and put real effort into its config file (CLAUDE.md, .cursorrules, etc.). That file is where you encode your protocol’s invariants, your style, your “never do X” rules. It’s the highest-leverage thing in the whole stack.

Layer 2 — Skills

Skills are reusable expertise packs an agent loads on demand — a folder of instructions, checklists, and reference code for a specific domain. Instead of re-explaining “how we audit a vault” every session, you write it once and the agent pulls it in when relevant.

Start with the solidity-security skill we shared earlier in the channel:

https://skills.sh/wshobson/agents/solidity-security

Then write your own. The most valuable skills are the ones nobody else can write for you: your protocol’s invariants, your deployment runbook, the specific reentrancy and oracle-manipulation patterns that bit you last time. A skill is just markdown plus example files — there’s no excuse not to have one per repo.

Layer 3 — MCP servers (the agent’s hands)

A coding agent without tools can only talk. MCP (Model Context Protocol) servers are what give it hands. The three that matter for Solidity work:

1. Foundry MCP — compile, run tests, and fuzz directly inside the agent loop. The agent writes a contract, builds it, sees the actual compiler error, and fixes it — instead of hallucinating that the code works.

2. Blockscout MCP — live on-chain reads and verified-source inspection. Ask the agent “what does this proxy point to on Base right now” and it actually checks, instead of guessing from training data.

3. A simulation layer (Tenderly, or a plain forked RPC) — simulate the transaction against mainnet state before anything touches a real key.

The pattern to internalize: anything the agent claims should be backed by a tool call, not by its confidence. Compilers and chain state don’t hallucinate.

Layer 4 — Deterministic verification gates

This is the layer people skip, and it’s the one that saves you.

Agents are probabilistic. Your CI should not be. Keep a hard, non-negotiable wall of deterministic tooling between “the agent finished” and “this merges”:

• forge test with meaningful fuzz runs and invariant tests

• Slither and Aderyn for static analysis

• Coverage thresholds that block the merge, not just warn

The agent is allowed to propose. The gate decides what’s true. If an agent-written change can’t survive your fuzzer and your static analyzers, it doesn’t matter how clean the diff looked.

Layer 5 — Adversarial agents

Here’s the uncomfortable part, and the reason this pivot matters.

The same technology writing your contracts is now writing exploits against them. Research this year showed that AI agents can generate working exploit code directly from a contract’s verified source. There are now formal benchmarks for this: OpenAI’s EVMbench evaluates frontier models on their ability to detect and exploit real-world Solidity vulnerabilities on EVM chains, and the academic side is moving fast too, with multi-agent frameworks built specifically for finding and repairing vulnerabilities in Solidity and Move.

The takeaway is blunt: if you are not running an attacker-agent against your own contracts, you are choosing to let someone else be the first to do it. Add a red-team step to your pipeline. Point a security-skilled agent at your deployed source with one job — break it — and feed whatever it finds back into Layer 4.

What the loop actually looks like

1. You describe the change → coding agent (Layer 1)

2. Agent loads protocol context → skills (Layer 2)

3. Agent writes + compiles + tests → Foundry MCP (Layer 3)

4. Agent checks live chain state → Blockscout MCP (Layer 3)

5. CI runs Slither/Aderyn/fuzz → deterministic gate (Layer 4)

6. Red-team agent attacks the diff → adversarial agent (Layer 5)

7. You review and sign → you

Notice where you are: not in the typing, but at the two ends — defining intent at the start, holding the keys at the end. That’s the right place for a human in 2026. The middle is automatable.

What does your agent loop look like? What’s wired into your MCP config? Drop it in the comments — I want to build a community reference stack from what people are actually running.
News & proposals: @hirama