Dev.to CDP Publish Check

I’ve been watching how AI coding agents actually work — not the demos, the real day-to-day usage — and something keeps standing out: we’ve optimized the wrong things.

Agents have great editors now. They can read files, write files, run tests, search codebases, manage git. The tooling around code manipulation is genuinely impressive.

What they can’t do — what nobody seems to talk about — is run a development loop against the services their code depends on. And if you’ve built anything nontrivial in the last decade, that’s where most real development happens.

The development loop problem

When you build a feature that talks to an external API — Stripe for payments, your team’s user service, a third-party data provider — you need that service running and responding while you develop. You write code, test it, see what the API returns, adjust, test again. Tight loop.

AI agents do this loop too. Except faster. A lot faster.

A developer might hit an API endpoint 20–30 times while building a payment integration. They know the API, they’ve read the docs, they debug by reading error messages and adjusting carefully.

An AI agent doing the same work might hit that endpoint 200–400 times. It generates code, tests it, reads the response, adjusts, generates new code, tests again. Each iteration is cheap in human terms — it costs tokens, not hours — but each iteration still needs a real response from a real service.

And that’s where everything falls apart.

What happens when agents hit real services

Three problems, in order of how much they’ll derail your afternoon:

Rate limits. Stripe’s test mode allows 25 requests per second. That sounds generous until an AI agent burns through it in a tight iteration loop, gets rate-limited, spends 400 tokens parsing the 429 response, backs off, retries, gets limited again, and eventually asks you what went wrong. Your agent just hit a wall that has nothing to do with the code it’s writing.

Cost. Not every API has a free test mode. Third-party data providers, AI inference APIs, communication platforms — many charge per request even in sandbox environments. An agent making 200 exploratory calls during a feature build adds up fast. And unlike a developer who reads docs and makes targeted calls, agents are exploratory by nature. They try things. They test edge cases. That exploration has a dollar sign attached when it hits real services.

Availability. The API you depend on is maintained by a team in another timezone. They pushed a breaking change to staging at 3 PM their time — 7 AM yours. Your agent starts working at 8 AM and immediately hits 500 errors on every call. It doesn’t know the staging environment is broken. It thinks its code is wrong. It spends 45 minutes rewriting perfectly good code to “fix” an error that isn’t its fault.

Developers recognize these situations instinctively. We check Slack, we ping the other team, we context-switch to something else. Agents don’t have that instinct. They see a broken response and conclude they need to write different code.

The gap in your local dev stack

We’ve actually solved most of the “AI agent needs local infrastructure” problem:

• Filesystem? Agents have one.
• Terminal? Built in.
• Database? SQLite, Docker, your local Postgres — pick one.
• Git? First-class support in every agent.
• Editor/IDE integration? That’s… what they are.

What we haven’t solved: the services this application talks to over the network.

Your app makes HTTP requests to a user service. It connects to a WebSocket for real-time updates. It calls a gRPC service for search. It authenticates through an OAuth provider. Those services are remote, someone else owns them, and they may or may not be running right now.

That gap — the space between “my agent can edit code” and “my agent can develop against a real system” — is the bottleneck nobody’s addressing. Your agent has every tool it needs to write code, and no way to verify that code works against the services it’s designed to talk to.

Mock servers as agent infrastructure

I’ll be direct: this is the reason I built mockd.

Not because mock servers are a new concept. WireMock has been around since 2011. json-server since 2013. The idea of returning fake responses from a local server isn’t novel.

What’s new is the role. Mock servers aren’t just test utilities anymore. They’re development infrastructure that makes AI agents productive. The same way a local database makes a developer productive — it’s always there, it’s fast, it’s yours — a local mock server makes an agent productive against external service dependencies.

When you point an AI agent at a project that has a mock server running, the agent can:

• Make unlimited API calls with zero rate limits
• Get sub-millisecond responses instead of network-latency responses
• Work against services that don’t exist yet (the other team hasn’t built them)
• Work at 3 AM when staging is down for maintenance
• Work in complete isolation from other developers and their agents
• Hit intentional error responses you’ve configured, not accidental ones from broken staging

This isn’t a test-time convenience. It’s a development-time necessity.

Self-provisioning infrastructure

Here’s where it gets interesting. With MCP (Model Context Protocol), an agent doesn’t just develop against mock servers — it can manage them.

MCP is a standard protocol that lets AI agents call external tools programmatically. mockd exposes 18 MCP tools for creating endpoints, importing API specs, managing state, and inspecting request logs. Any MCP-compatible agent — Claude Code, Cursor, GitHub Copilot — can use them.

The workflow:

1. Agent reads the OpenAPI spec for the service you depend on
2. Agent calls mockd’s import_mocks tool to create endpoints from the spec
3. Agent develops against those endpoints as if they’re the real service

No human writes configuration. No human runs CLI commands. The agent provisions its own development infrastructure and immediately starts building.

This is a fundamentally different relationship between developer tools and AI. The tool isn’t something the developer configures for the agent. The tool is something the agent configures for itself.

The cost math

Let’s make this concrete.

A team of 10 engineers, each with an AI agent doing 4 hours of assisted development per day. Each agent averages 150 API calls to external service dependencies during that time.

Against real services:

Against local mock servers:

The mock server isn’t a nice-to-have optimization. It’s the difference between your agent spending tokens on your feature and spending tokens fighting infrastructure it doesn’t control.

This is just the beginning

Local mock servers for AI development is a bigger topic than one post can cover. Two things I haven’t addressed yet: why “return 200 OK with some JSON” isn’t enough (your agent needs realistic service behavior to build production-ready code), and how this scales when you have multiple teams with multiple agents all developing in parallel.

If you want to try this now:

# Install mockd
curl -fsSL https://get.mockd.io | sh

# Start the server
mockd start

# Create a mock endpoint
mockd add http --method GET --path /api/users 
  --status 200 
  --body '[{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]'

Your agent now has an API it can develop against. No rate limits, no costs, no downtime.

Learn more

• Quickstart guide — install mockd and create your first mock in under 60 seconds
• All features — MCP server, AI mock generation, 7 protocols, recording proxy, and more
• All 7 protocols — HTTP, gRPC, GraphQL, WebSocket, MQTT, SSE, SOAP
• Cloud tunnel — share local mocks via a public URL with one command

Links

• GitHub: github.com/getmockd/mockd (Apache 2.0)
• Docs: docs.mockd.io
• Install: brew install getmockd/tap/mockd or curl -fsSL https://get.mockd.io | sh

When the Guard Dog Bites: The Aave CAPO Oracle Incident That Liquidated $27.78M
A deep dive into how Aave’s automated anti-manipulation oracle became the source of a $27.78M liquidation cascade, and what Web3 developers should learn from it.
The Incident in Brief
On March 10, 2026, Aave’s CAPO Oracle — an automated system designed to prevent oracle manipulation — pushed a faulty snapshotRatio update for wstETH. The oracle priced wstETH at ~1.19 ETH instead of the market rate of ~1.228849 ETH. A 2.85% discrepancy.
That was enough. 34 E-Mode positions were liquidated. 10,938 wstETH wiped out. Total value: approximately $27.78M.
No hacker. No exploit. The safety system itself fired on friendly forces.
Understanding CAPO Oracle
┌──────────────────────────────┐
│ Chaos Labs Edge Risk Engine │ ← Off-chain computation
└────────────┬─────────────────┘
│ Submit update
▼
┌──────────────────────────────┐
│ AgentHub (BGD Labs) │ ← On-chain execution layer
└────────────┬─────────────────┘
│ Execute (1 block)
▼
┌──────────────────────────────┐
│ Aave CAPO Oracle │ ← Price feed for protocol
└──────────────────────────────┘

Design philosophy: Speed over deliberation. No time-lock. No multisig review. If the system makes an error, it executes in the same one-block window designed for emergency response.
The Root Cause
The official post-mortem states: “a configuration mismatch between two parameters that should have moved in sync.”
contract CAPOOracle {
uint256 public snapshotRatio;
uint256 public referenceRate;

function getAssetPrice(address asset) external view returns (uint256) {
    if (asset == WSTETH) {
        uint256 basePrice = chainlinkFeed.latestAnswer();
        uint256 effectiveRatio = (snapshotRatio * referenceRate) / 1e18;
        return (basePrice * effectiveRatio) / 1e18;
    }
}

function updateParameters(
    uint256 newSnapshotRatio,
    uint256 newReferenceRate
) external onlyRole(AGENTHUB_ROLE) {
    // ⚠️ No consistency validation
    snapshotRatio = newSnapshotRatio;
    referenceRate = newReferenceRate;
}

}

The Liquidation Cascade
2.85% oracle error → 34 accounts liquidated → 10,938 wstETH → $27.78M gone.
The Two Narratives
Omer Goldberg (Chaos Labs CEO): “A misconfiguration on Aave’s CAPO oracle resulted in wstETH E-Mode liquidations, causing 345 ETH in losses. All affected users will be fully compensated.”
Stani Kulechov (Aave founder): “Technical misconfiguration caused the liquidation of positions that were already close to liquidation threshold.”
Lessons for Web3 Developers

1. Automated Systems Need Automated Safeguards
   modifier withinSafetyBounds(uint256 newValue, uint256 oldValue) {
   if (oldValue > 0) {
   uint256 deviation = newValue > oldValue
   ? (newValue – oldValue) * 10000 / oldValue
   : (oldValue – newValue) * 10000 / newValue;
   if (deviation > MAX_DEVIATION_BPS) {
   emit SafetyBoundExceeded(oldValue, newValue, deviation);
   _scheduleTimelockedUpdate(newValue);
   return;
   }
   }
   _;
   }

2. Multi-Parameter Systems Need Consistency Checks
   function updateParameters(uint256 newRatio, uint256 newCache) external onlyOperator {
   uint256 oldOutput = (snapshotRatio * exchangeCache) / 1e18;
   uint256 newOutput = (newRatio * newCache) / 1e18;
   uint256 outputDelta = newOutput > oldOutput ? newOutput – oldOutput : oldOutput – newOutput;
   require(outputDelta * 10000 / oldOutput <= MAX_OUTPUT_CHANGE_BPS, “Output deviation too large”);
   snapshotRatio = newRatio;
   exchangeCache = newCache;
   }

3. Time-Locks Are Not the Enemy of Speed
   enum UpdateType { Routine, Emergency }

function scheduleUpdate(uint256 newPrice, UpdateType updateType) external onlyOperator {
uint256 delay = updateType == UpdateType.Emergency ? 0 : 30 minutes;
if (updateType == UpdateType.Emergency) {
require(hasValidMultisigSignature(), “Emergency requires multisig”);
}
_scheduleUpdate(newPrice, delay);
}

1. Independent Monitoring Should Be a First-Class Concern
   LTV Protocol, a third-party monitor, was the first to publicly flag the anomaly — before Aave’s official post-mortem.
2. Track Records Create Complacency
   CAPO had pushed 1,200+ payloads with zero failures. Then one failure caused $27.78M in liquidations.
   Conclusion
   The speed that makes CAPO effective against manipulation also makes it dangerous when it misfires.
   Automate safely. Validate consistency. Embrace monitoring. Design for failure.
   References:
3. Parameter Update TX
4. Execution TX
5. Aave Post-Mortem
6. LTV Protocol Alert

Advent of Code 2025 Day 4

The ease of Part 1 concerns me

I’ve solved this puzzle at least a dozen times throughout Advent of Code.

There is almost certainly going to be a unique twist in Part 2.

For now, it’s time to solve this yet again.

Writing another adjacent grid cell inspector

First, I want to ‘pad’ the grid with a border of .s so I can safely check each original cell without having to account for out-of-bounds errors.

I usually do this after converting the string into a 2-dimensional array.

But this time, I will opt to create a new string by adding characters from a stringified array and replacing newline characters with dot-padded newline characters.

Here’s the single, long concatenation statement:

let lineLength = input.indexOf('n')
input = new Array(lineLength + 2).fill('.').join('') 
    + 'n.' 
    + input.replaceAll('n', '.n.') 
    + '.n' 
    + new Array(lineLength + 2).fill('.').join('')

It turns this:

..@@.@@@@.
@@@.@.@.@@
@@@@@.@.@@
@.@@@@..@.
@@.@@@@.@@
.@@@@@@@.@
.@.@.@.@@@
@.@@@.@@@@
.@@@@@@@@.
@.@.@@@.@.

Into this:

............
...@@.@@@@..
.@@@.@.@.@@.
.@@@@@.@.@@.
.@.@@@@..@..
.@@.@@@@.@@.
..@@@@@@@.@.
..@.@.@.@@@.
.@.@@@.@@@@.
..@@@@@@@@..
.@.@.@@@.@..
............

And it works like a charm for any grid.

Next, my usual dictionary of relative coordinates for each adjacent cell:

let adjacents = [
    [-1,-1], [-1,0], [-1,1],
    [0,-1], [0,1],
    [1,-1], [1,0], [1,1]
]

Next, creating the grid, initializing the counter, and shell of the nested for loop:

let answer = 0
let grid = input.split('n').map(el => el.split(''))
for (let row = 0; row < grid.length; row++) {
    for (let col = 0; col < input[0].length; col++) {

    }
}

Lastly, checking each adjacent cell and tallying up the rolls:

answer += grid[row][col] == '@' 
    && adjacents
        .map(
            cell => grid[cell[0] + row][cell[1] + col] == '.' ? false : true
        )
        .filter(el => el == true).length < 4 ? 1 : 0

It is one statement that does the following:

• Increment answer by 1…
• As long as the current cell contains a @…
• And the number of adjacent cells containing a @ is less than 4
• Otherwise increment by 0

Testing it on the example input produces the correct answer, 13.

What about on my puzzle input?

…

I got the correct answer!

Nice!

And now…for Part 2’s likely diabolical twist.

Part 2

What a delightful twist

It is essentally Part 1 repeated until no change in state is produced.

Even as large as my grid is, I feel like brute-forcing this will still generate an answer fairly quickly.

I could be wrong, but that doesn’t change my approach to solve this part.

Building on Part 1

For Part 1, I processed a single iteration.

I now need a while loop to process as many iterations as it takes until no new rolls can be removed.

And I need to keep track of both the amount and location of rolls to be removed (a.k.a. turned into empty cells).

let changers = []
do {
    for (let row = 1; row < grid.length - 1; row++) {
        for (let col = 1; col < grid[0].length - 1; col++) {
            changers.push( grid[row][col] == '@' && adjacents.map(cell => grid[cell[0] + row][cell[1] + col] == '.' ? false : true).filter(el => el == true).length < 4 ? [row,col] : null)
        }
    }
    changers = changers.filter(el => el !== null)
    console.log(changers)
} while (changers.length > 0)

The code above successfully catalogs all cell locations of rolls that should be removed.

At least…after 1 iteration.

Since it never mutates the grid or clears the array, it repeatedly adds the same set of cell locations to the same array.

Time to fix that.

let changers = []
let answer = 0
do {
    answer += changers.length
    changers.forEach(cell => {
        grid[cell[0]][cell[1]] = '.'
    })
    changers = []
    for (let row = 1; row < grid.length - 1; row++) {
        for (let col = 1; col < grid[0].length - 1; col++) {
            changers.push( grid[row][col] == '@' && adjacents.map(cell => grid[cell[0] + row][cell[1] + col] == '.' ? false : true).filter(el => el == true).length < 4 ? [row,col] : null)
        }
    }
    changers = changers.filter(el => el !== null)
} while (changers.length > 0)

It was a simple addition of the forEach() loop early in the do-while loop.

I also added the answer variable to track the sum of removed rolls.

Running it on the example input generates the correct answer.

As always, fingers crossed it runs on my puzzle input…and generates the correct answer.

…

It worked!

Finished immediately and generated the correct answer!

Woohoo!!

That was a lot easer than I expected Part 2 to be.

It makes me worried for a much tougher Day 5.

Can’t wait to find out!

If you’re running an M-series MacBook or Mac mini in 2026, you already know the hardware is absurd. But are you getting the most out of it software-wise?

I’ve spent the last year curating my Mac setup specifically around apps that are native to Apple Silicon — no Rosetta, no Electron bloat, just fast, lean tools that feel like they belong on the platform.

Here are 7 that I think every developer should at least try.

1. Warp — The Terminal That Actually Feels Modern

warp.dev

Warp is a Rust-based terminal that runs natively on Apple Silicon, and you can feel the difference the moment you open it. Command output renders instantly, the AI command search is built in, and the block-based interface makes it easy to scroll through and share terminal output. If you’re still using the default Terminal.app, this is a free upgrade that will genuinely change your workflow.

2. Raycast — The Launcher That Replaces 5 Other Apps

raycast.com

Raycast is what Spotlight should have been. It launches apps, runs scripts, manages clipboard history, controls windows, and integrates with basically every tool you use — GitHub, Linear, Notion, Slack, you name it. It’s native Swift, so it opens in milliseconds on M-series chips. The extension ecosystem is massive and growing. Once you start using it, Spotlight feels like a toy.

3. CleanShot X — Screenshots and Screen Recording Done Right

cleanshot.com

If you share screenshots in Slack, PRs, or docs (and who doesn’t), CleanShot X is a massive upgrade over the built-in screenshot tool. Annotation, scrolling capture, screen recording with GIF export, OCR text grab — it does everything. It’s a native macOS app that launches instantly and stays out of your way until you need it. One-time purchase, no subscription.

4. TokenBar — Know What Your AI Workflow Actually Costs

tokenbar.site

This one’s a tiny menu bar utility that tracks your LLM token usage in real time across providers — OpenAI, Anthropic, Google, whatever you’re hitting. If you’re using Cursor, Copilot, or running agents that burn through API calls, TokenBar gives you a live count right in your menu bar so you’re never surprised by the bill. Native Swift, uses almost no resources, and it’s $5 lifetime. The kind of tool you install once and wonder how you lived without.

5. Monk Mode — Block Feeds Without Blocking Apps

mac.monk-mode.lifestyle

Most “focus” apps block entire websites or apps. Monk Mode is smarter — it blocks the feed inside apps like Twitter, Reddit, YouTube, and LinkedIn while still letting you use search, DMs, and direct links. So you can still look up a Stack Overflow answer or respond to a DM without falling into a 45-minute scroll hole. Native macOS, runs as a menu bar app, $15 lifetime. I run it basically all day when I’m shipping code.

6. Bear — Markdown Notes That Don’t Fight You

bear.app

Bear is the notes app I keep coming back to. It’s fast, beautiful, and does markdown natively without making you think about it. The nested tagging system is brilliant for organizing dev notes, meeting notes, and quick code snippets. It syncs via iCloud, which means no account to create and no data leaving Apple’s ecosystem. The Apple Silicon build is buttery smooth — I’ve never seen it lag, even with thousands of notes.

7. Fantastical — The Calendar That Actually Understands Natural Language

flexibits.com/fantastical

Fantastical has been around forever, but the native Apple Silicon version is noticeably faster than the old Intel build. The natural language parsing is what sets it apart — type “standup every weekday at 9:30am” and it just works. The menu bar widget gives you a quick glance at your day without opening a full app. If you juggle meetings and deep work blocks (and you should), this makes calendar management almost painless.

The Common Thread

Every app on this list is native macOS, built for Apple Silicon, and either free or reasonably priced. No Electron wrappers eating 500MB of RAM. No web apps pretending to be desktop apps.

The M-series chips are incredible — might as well use software that actually takes advantage of them.

What’s in your Apple Silicon toolkit? Drop your favorites in the comments 👇

I built this plugin to solve a very specific WordPress problem: adding pre-roll ads to Elementor videos without bolting on a second player, extra shortcodes, or theme-level hacks.

A lot of sites already use Elementor’s core Video widget for lessons, demos, and landing pages. The usual ad workaround is messy. Teams stack embeds, hide scripts in templates, or wire up custom JS that becomes fragile the next time someone edits the page. I wanted the ad workflow to live where editors already work.

So the plugin extends the Elementor Video widget itself. Inside the same widget panel, I add a Video Ads section where you can enable a pre-roll clip, define skip timing, and optionally attach a visit URL. That keeps the playback flow feeling like one component instead of two unrelated video systems.

Under the hood, the plugin separates configuration into two layers. The first is per-widget control inside Elementor, which is useful when a single page needs custom timing or a different ad. The second is a global admin layer in WordPress, where I can apply a shared ad across multiple pages and exclude content when needed. That avoids repetitive setup for larger sites.

I also added a statistics screen that records plugin-level activity such as impressions, skips, and interactions. It is not meant to replace a full analytics stack, but it gives editors and site owners a direct way to verify that campaigns are actually running and compare local widget settings against global rules.

The main technical goal was reducing editor confusion. If the ad settings live outside Elementor, teams have to remember which shortcode, script, or template owns the behavior. By attaching everything to the existing Video widget, the ownership is obvious.

If you want to see the product itself, I published it here: https://nexuwp.com/product/elementor-video-ads-dynamic-video-advertising-for-wordpress/

In practice, the plugin is less about ad tech buzzwords and more about keeping WordPress video monetization maintainable. One widget, one playback journey, and a cleaner way to manage pre-roll campaigns across Elementor pages.

How I built my portfolio with React + TypeScript (Lighthouse 97/100)

I’m an 18 y/o self-taught frontend dev and just finished my personal portfolio site.

🛠️ Stack

• React 18 + TypeScript — core framework
• Vite over CRA — faster builds, better DX
• Tailwind CSS — no time wasted on CSS
• Framer Motion — smooth animations without headaches
• i18next — multilingual (RU/EN/DE)
• EmailJS — contact form without a backend

⚡ Performance

😤 Hardest part

Getting Lighthouse performance above 95 — ended up optimizing images to WebP and fixing a few render-blocking issues.

🔗 Links

• Live demo: https://personal-portfolio-landing-theta.vercel.app
• GitHub: https://github.com/dorbinDevFRLNCR/personal-portfolio-landing

Feedback welcome! 🔥