DEV Community: Maish Saidel-Keesing

My AI Sports Analyst: How I Wake Up to World Cup Insights Every Morning

Maish Saidel-Keesing — Wed, 24 Jun 2026 10:40:42 +0000

The FIFA World Cup 2026 kicked off on June 11th. And I had a problem.

Most of the matches are played in the Americas. That means evening kickoffs in Mexico, the US, and Canada translate to the middle of the night here in Israel. I'm not staying up until 3 AM to watch group stage matches. But I also don't want to wake up, grab my phone, and spend 20 minutes scrolling through sports apps piecing together what happened.

So I built myself a personal sports analyst. One that wakes up before I do, scours the internet for match results, collects detailed statistics, and even makes predictions about who's going to win the whole thing.

And it takes me zero effort every morning.

The Setup

I'm using Amazon Quick's scheduled agents feature. If you're not familiar, it lets you create an AI agent with a specific prompt, give it access to tools (web search, file read/write, etc.), and set it on a schedule. The agent runs autonomously at the time you specify, does its thing, and posts the results to your activity feed.

My agent is called wc2026-daily-stats. It runs every day at 9:00 AM Israel time. By the time I'm pouring my first coffee, the results are already waiting for me.

What It Actually Does

The agent has a three-part workflow:

Part 1: Collecting Match Stats

Every morning, the agent:

Checks what day it is
Searches the web for "FIFA World Cup 2026 results" from the previous day
For each match it finds, it digs deeper. It searches for detailed box score statistics from sports sites
It fetches those pages and extracts everything: possession percentages, shots on target, xG (expected goals), goal scorers with timestamps, cards, saves, corners, the works

The level of detail is honestly better than what I'd get casually browsing a sports app. Here's what a typical match entry looks like in my stats file:

## Match 4: United States 4-1 Paraguay
**Date:** June 13, 2026 | **Group D** | **Venue:** SoFi Stadium, Inglewood

### Goal Scorers
| Team | Player | Minute |
|------|--------|--------|
| USA | Damián Bobadilla (OG) | 7' |
| USA | Folarin Balogun | 31' |
| USA | Folarin Balogun | 45'+5' |
| Paraguay | Mauricio | 73' |
| USA | Giovanni Reyna | 90'+8' |

### Match Statistics
| Statistic | United States | Paraguay |
|-----------|--------------|----------|
| Possession | ~58% | ~42% |
| Total Shots | ~22 | — |
| xG | ~2.8 | — |

Every match gets this treatment. After 12 days of the tournament, I have 40 matches catalogued with full stats.

Part 2: The Prediction Engine

This is the part I find most fun.

After collecting the day's stats, the agent reads the entire accumulated stats file (all 40+ matches so far) and produces an updated prediction for which two teams will make the final.

It's not just "pick the favorites." The agent weighs multiple factors:

Current tournament form: goals scored vs. conceded, xG performance
Quality of opposition: beating Germany is worth more than thrashing Curaçao 7-1
Squad depth: how many different scorers? Are substitutes making an impact?
Tournament pedigree: have these teams delivered at World Cups before?
Tactical solidity: clean sheets, defensive organization
Mentality indicators: comebacks, late winners, composure under pressure
Home advantage: this matters in the US/Mexico/Canada venues

The prediction comes with a confidence percentage that increases as more data accumulates. It started around 30% after the first few matches and is currently at 48% with two matches per team analyzed.

Right now? The agent is predicting an Argentina vs France final. Messi has 5 goals in 2 matches (all-time World Cup leading scorer at 38 years old), and Mbappé has 4. The agent also tracks a "Changes from yesterday" section explaining why the prediction shifted. Two days ago it was Germany vs Argentina. France earned the upgrade after a clinical 3-0 against Iraq.

It even picks dark horses. Currently watching Norway (Haaland with 4 goals) and Japan (came back twice against the Netherlands).

Part 3: The Morning Notification

Finally, the agent posts a summary to my activity feed. It includes:

How many matches were played yesterday
Final scores
One standout stat per match
The current prediction with a one-line explanation

So when I open Amazon Quick in the morning, there's a notification waiting: "3 matches yesterday. France 3-0 Iraq (Mbappé brace, now has 16 career WC goals). 🔮 Prediction: Argentina vs France. Messi and Mbappé on a collision course for a 2022 final rematch."

That's it. I'm up to speed in 10 seconds.

How the Data is Stored

Everything lives in two local markdown files:

wc2026_all_match_stats.md is the running log. Every match gets appended to the end with detailed stats. It's currently at 40 matches and about 68KB. The agent reads the existing file, appends new matches, and writes it back.
wc2026_final_prediction.md gets completely rewritten each day. It contains the current standings, top 10 contenders with key metrics, the predicted finalists with detailed reasoning, confidence level, dark horses, and a Golden Boot tracker.

Both are just plain markdown files sitting in my Documents folder. Nothing fancy. I can open them anytime and read through the full tournament history or check the latest prediction.

The Technical Bits

For those who want to know what's under the hood:

Why Web Scraping and Not a Sports API?

This is the question every developer asks. "Why not just use a football stats API?"

I tried. Trust me, I tried.

API-Football (api-sports.io) is the most popular one. Free tier gives you 100 requests per day. Sounds great. Except their free tier is locked to seasons 2022-2024. The moment you query for 2026 World Cup data, you get: "Free plans do not have access to this season, try from 2022 to 2024." So unless I wanted to pay for a subscription for a month-long tournament, that was out.

BALLDONTLIE has a FIFA World Cup endpoint. Free tier available. But at tournament time, you're relying on a third-party API to have ingested the data promptly. And their rate limits and reliability during a live global event? Questionable.

Zafronix offers 250 requests/day for free, no credit card. But it's relatively unknown, and I wasn't about to build a workflow around an API I couldn't verify would have real-time WC2026 data on day one.

So I went with web scraping. And honestly? It works better for my use case.

The Sites Being Crawled

The agent scrapes two main sources:

Primary: DailySports.net

This is the goldmine. Their match pages have the most granular stats I've found anywhere. Full match stats plus half-by-half breakdowns, passes, attacks, dangerous attacks, crosses, throw-ins, and a full event timeline. The URL pattern is predictable (dailysports.net/stat/football/{team1}-vs-{team2}/), which makes it easy for the agent to construct the right URL from the team names.

Backup: Sporting News

When DailySports doesn't have a match yet (they sometimes lag by a few hours), the agent falls back to Sporting News box scores. These give you the essentials: possession, shots, corners, xG, and saves. Not as detailed, but solid enough to fill in the blanks.

Discovery: General web search

For finding which matches were played yesterday, the agent just does a broad web search ("FIFA World Cup 2026 results June 22, 2026"). It doesn't need a specific source for that. The web search returns headlines from ESPN, BBC Sport, FIFA.com, whatever is ranking that day. The agent grabs the team names and scores, then goes deep on the stats from the specialized sources above.

Why This Approach Actually Works Better

Here's the thing. Sports APIs give you structured JSON. Clean, predictable, easy to parse. But they also give you only what their schema supports. If the API doesn't have an xG field, you don't get xG. If they haven't added "dangerous attacks" as a metric, tough luck.

Web scraping with an LLM flips this. The agent reads the page like a human would, extracts whatever is there, and structures it into my markdown format. If DailySports adds a new stat tomorrow, the agent will probably pick it up without me changing anything. It's more resilient to changes in what data is available, not less.

The tradeoff? It's slower (8-12 minutes per run vs. seconds with an API) and occasionally a stat is marked as "—" when the source page was weird. But for a daily batch job that runs while I sleep? Speed doesn't matter. And the "—" gaps are honestly fine. I'd rather have 90% of stats from a rich source than 100% of a limited set from a locked-down API.

And yes, I'm aware that relying on specific websites means they could change their layout or go down. It's a single point of failure, and I've written about that problem before. But having a primary + backup source with a general web search fallback gives me enough resilience for a month-long tournament.

The schedule: Runs at 09:00 IDT via a time_of_day schedule. It has run 6 times so far, all successful. Average run takes about 8-12 minutes because it's doing multiple web searches and fetching full pages for each match.

The tools it has access to:

web_search and url_fetch for finding and reading match results
file_read and file_write for maintaining the stats files
run_python for any data processing
update_feed for posting the morning notification
skip_cycle for days when no matches were played

The model: It uses the "smart" tier. I want the analysis and prediction reasoning to be thoughtful, not just a quick summary.

Here is the full code of the task.

You are a FIFA World Cup 2026 match statistics collector and tournament analyst. Every day at 9:00 AM IDT, you collect detailed match stats for any World Cup games played the previous day AND update your running prediction for which two teams will make the final.

## Your workflow:

### PART 1: Daily Stats Collection

1. Use `get_current_time` to determine today's date, then search for yesterday's World Cup 2026 results: 
   web_search("FIFA World Cup 2026 results {yesterday's date}")

2. For each completed match found, search for detailed stats:
   - Search: "World Cup 2026 {team1} vs {team2} match statistics box score"
   - Try DailySports.net (primary - most granular) and Sporting News box scores (backup)
   - Fetch the stats page with url_fetch

3. For each match, collect:
   - Final score, venue, group
   - Possession %
   - Shots on target / off target / total
   - Corners
   - Fouls
   - Yellow/Red cards
   - Saves
   - Total passes
   - xG (if available)
   - Goal scorers with minutes
   - Key events (cards, subs)

4. Read the existing stats file at /Users/maishsk/Documents/wc2026_all_match_stats.md using file_read, then append yesterday's matches to it using file_write (write the complete updated file with ALL existing content plus new matches appended at the end).

### PART 2: Final Prediction

5. After updating the stats file, read the FULL file and analyze ALL matches played so far. Then update the prediction file at /Users/maishsk/Documents/wc2026_final_prediction.md with your current best prediction for which two teams will meet in the final. The prediction file should include:

   - **Current standings summary**: Points, GD, goals scored for all teams
   - **Top 10 contenders list** with key metrics (pts, GD, goals/match, xG where available)
   - **Predicted Finalist #1** with detailed reasoning (form, squad depth, quality of wins, tactical observations)
   - **Predicted Finalist #2** with detailed reasoning
   - **Confidence level** (percentage) — this should increase as the tournament progresses
   - **Key factors considered**: tournament form, pedigree, squad quality, injury news mentioned in match reports, strength of opposition faced, home advantage, historical knockout stage performance
   - **Changes from yesterday**: note if/why your prediction changed since last time
   - **Dark horses**: 1-2 teams that could upset the prediction
   - **Date of prediction** and number of matches analyzed

   When making your prediction, weigh these factors:
   - Current tournament form (goals scored, goals conceded, xG performance)
   - Quality of opposition faced (beating strong teams > thrashing weak ones)
   - Squad depth (how many different scorers? substitutes making impact?)
   - Tournament pedigree (past World Cup performances of these squads)
   - Tactical solidity (clean sheets, defensive organization)
   - Mentality indicators (comebacks, late goals, composure under pressure)
   - Home advantage (for USA/Mexico/Canada matches)
   - Bracket position (once knockouts are determined)

### PART 3: Feed Update

6. Post a summary to the activity feed using update_feed with importance="important". Include:
   - How many matches were played yesterday
   - Final scores
   - One highlight stat per match (e.g., most shots, highest xG, biggest possession gap)
   - 🔮 Current final prediction: "Team A vs Team B" with a one-line reason why

## Important notes:
- The tournament runs June 11 - July 19, 2026
- If no matches were completed yesterday, call skip_cycle
- DailySports.net URL pattern: dailysports.net/stat/football/{team1}-vs-{team2}/
- Stats file absolute path: /Users/maishsk/Documents/wc2026_all_match_stats.md
- Prediction file absolute path: /Users/maishsk/Documents/wc2026_final_prediction.md
- Format each match section with a markdown H2 header: ## Match {N}: {Team1} {score1} - {score2} {Team2}
- Be bold with your prediction — make a clear call, don't hedge excessively
- If your prediction changes from the previous day, explain WHY in the "Changes" section

What I've Learned

A few observations after running this for almost two weeks:

The predictions are surprisingly reasonable. It's not just picking the biggest names. It correctly identified that Germany's 9 goals in 2 matches (impressive on paper) were inflated by a 7-1 against Curaçao, while France's victories were against stronger opponents. That's good analysis.

The daily "changes" section is the best part. Knowing why the prediction changed is more interesting than the prediction itself. "Germany dropped because their goals came against weak opposition while France earned maximum points against tougher teams."

Consistency of format matters. Because the agent writes each match in the same structured format, I can easily scan and compare. Who had the highest xG? Which teams are overperforming their expected goals? The structured data makes these questions answerable at a glance.

It's like having a dedicated analyst who never sleeps. I built this in maybe 15 minutes of prompting, and it's been running reliably every day since. That's the beauty of scheduled agents. Set it up once, and it just works. (If you want another example of this kind of thing, I recently had my AI assistant write an entire MCP proxy for me in a single session.)

Would I Do Anything Differently?

Honestly, not much. If I were starting over, I might add:

A group stage standings table that updates automatically
Alerts when a team I'm watching is eliminated
A comparison of the agent's predictions vs actual results (accountability!)

But for a quick weekend project that took 15 minutes to set up? I'm very happy with how this turned out.

And here's the thing that still blows my mind. I didn't write a single line of code. Not one. No Python scripts, no cron jobs, no API wrappers. I described what I wanted in plain English, gave the agent the right tools, and it figured out the rest. That's the power of these kinds of tools. You don't need to be a developer to build something like this. Anyone with a clear idea of what they want can actually build it.

The World Cup runs until July 19th. I'll keep the agent running and see how its predictions hold up in the knockout stage when things get really unpredictable. Will it be Argentina vs France? Ask me again in 3 weeks.

I would be very interested to hear your thoughts or comments. Are you using scheduled agents for anything creative? Hit me up on LinkedIn, X, or leave a comment below.

Bridging IFTTT to Your Local AI Assistant with an MCP Proxy

Maish Saidel-Keesing — Thu, 18 Jun 2026 13:28:22 +0000

So IFTTT shipped MCP support. That means you can control your automations, list applets, edit triggers, run queries... all through the Model Context Protocol. In theory, any MCP-capable AI assistant can now talk directly to IFTTT.

In practice? Not quite.

Right now, IFTTT officially supports only Claude and ChatGPT as AI assistant integrations. You go to Settings → Connectors in Claude, or Settings → Connected Apps in ChatGPT, and IFTTT is right there. But if your AI assistant isn't on that short list? You're on your own.

Why IFTTT's MCP Server Won't Talk to Your Local AI

Here's the situation. My AI assistant (Amazon Quick) speaks MCP via stdio. It launches a local process and communicates over stdin/stdout using JSON-RPC. Simple. Clean. Works great for local tools.

IFTTT's MCP server lives at https://ifttt.com/mcp and uses Streamable HTTP transport. It expects authenticated HTTP POST requests and responds with either JSON or Server-Sent Events streams.

Two completely different transport layers. They don't talk to each other.

So what do you do? You build a proxy.

Well... "you" build a proxy. In my case, I described the problem to Amazon Quick (my AI assistant) and it wrote the entire proxy for me. All ~500 lines of it.

I guided the architecture, debugged alongside it, and steered the fixes when things broke. But the actual code? That was all Quick guiding Kiro. This whole post is really about what happens when you pair an AI coding assistant with a well-defined integration problem.

What the Proxy Does

The proxy is a ~500-line Node.js script that sits between them:

┌────────────┐  stdio    ┌───────────┐  HTTPS  ┌──────────┐
│            │ JSON-RPC  │           │  POST   │          │
│   Amazon   │ ────────▶ │   MCP     │ ──────▶ │  IFTTT   │
│   Quick    │           │   Proxy   │         │  MCP     │
│            │ ◀──────── │  (Node)   │ ◀────── │ (Remote) │
│            │ JSON-RPC  │           │ SSE/JSON│          │
└────────────┘           └─────┬─────┘         └──────────┘
     local                     │                  remote
                        ┌──────┴──────┐
                        │ OAuth 2.1   │
                        │ PKCE + Auto │
                        │ Refresh     │
                        └─────────────┘

It reads JSON-RPC messages from stdin, forwards them as authenticated HTTPS requests to IFTTT, handles whatever response format comes back (direct JSON or SSE stream), and writes the response to stdout for Quick to consume.

The full flow:

Authentication: OAuth 2.1 + PKCE (one-time browser flow)
Token management: Auto-refresh when tokens expire
Request proxying: stdin -> authenticated HTTPS POST to IFTTT
Response handling: SSE streaming detection and parsing
Response transformation: Format translation for client compatibility

Sounds straightforward? It mostly is. But two gotchas took me while to debug. Let me walk you through them.

How to Authenticate: OAuth 2.1 + PKCE

First things first. IFTTT requires OAuth authentication. The proxy has an --auth mode that handles the entire flow:

async function authenticate() {
  const codeVerifier = generateCodeVerifier();
  const codeChallenge = generateCodeChallenge(codeVerifier);
  const state = generateState();

  const authParams = new URLSearchParams({
    client_id: CLIENT_ID,
    code_challenge: codeChallenge,
    code_challenge_method: 'S256',
    redirect_uri: REDIRECT_URI,
    resource: 'https://ifttt.com/mcp',
    response_type: 'code',
    scope: 'mcp',
    state: state,
  });

  // Opens browser, starts local callback server on port 3118
  // Exchanges code for token using PKCE verifier
  // Saves token to ~/.quickwork/ifttt-token.json
}

Run node index.js --auth once, authenticate in your browser, and the token gets saved locally. After that, the proxy handles refresh automatically. You never think about auth again.

The token management is simple but important:

function isTokenExpired(tokenData) {
  if (!tokenData || !tokenData.access_token) return true;
  if (!tokenData.expires_in) return false;
  const expiresAt = tokenData.obtained_at + (tokenData.expires_in * 1000);
  return Date.now() > expiresAt - 60000; // 1 minute buffer
}

That 60-second buffer matters. You don't want a request to fail because the token expires mid-flight.

Gotcha #1: Why IFTTT Returns Empty Responses

So here's where it got interesting.

My first version of the proxy was dead simple. Read from stdin, POST to IFTTT, buffer the response, write to stdout. Classic request/response.

It worked great for tools/list. IFTTT returned a nice 200 OK with a JSON body listing all available tools. I was feeling good.

Then I called my_applets.

Nothing came back. No error. No response. Just... silence.

After adding some debug logging, I discovered IFTTT was returning HTTP 202 Accepted with an empty body. The actual response? It was coming back as a Server-Sent Events stream. But my buffered HTTP client was already done. It saw the empty body, closed the connection, and moved on.

The fix is a streaming-aware HTTP client that checks the Content-Type header:

function httpsStreamingRequest(url, options, body, timeoutMs = 60000) {
  return new Promise((resolve, reject) => {
    const req = https.request(reqOptions, (res) => {
      const contentType = res.headers['content-type'] || '';
      const isSSE = contentType.includes('text/event-stream');

      if (isSSE) {
        // Keep the connection open, collect SSE events
        let sseBuffer = '';
        res.setEncoding('utf8');
        res.on('data', (chunk) => { sseBuffer += chunk; });

        res.on('end', () => {
          resolve({
            status: res.statusCode,
            isSSE: true,
            events: parseSSEBody(sseBuffer),
          });
        });
      } else {
        // Standard buffered response
        let data = '';
        res.on('data', (chunk) => { data += chunk; });
        res.on('end', () => {
          resolve({ status: res.statusCode, isSSE: false, body: data });
        });
      }
    });

    req.setTimeout(timeoutMs, () => {
      req.destroy(new Error(`Request timed out after ${timeoutMs}ms`));
    });

    if (body) req.write(body);
    req.end();
  });
}

The SSE parser itself is straightforward. Events are separated by double newlines, data lines start with data::

function parseSSEBody(body) {
  const events = [];
  const blocks = body.split('\n\n');

  for (const block of blocks) {
    let eventData = '';
    for (const line of block.split('\n')) {
      if (line.startsWith('data: ')) {
        eventData += line.substring(6);
      } else if (line.startsWith('data:')) {
        eventData += line.substring(5);
      }
    }
    if (eventData) {
      try { events.push(JSON.parse(eventData)); } catch (e) {}
    }
  }
  return events;
}

After this fix, my_applets worked beautifully. IFTTT returned 12 applets, all properly structured. I was back to feeling good.

For about 10 minutes.

Gotcha #2: Why Your Client Can't Read the Results

So the proxy was getting responses. IFTTT was sending back data. But Amazon Quick was still showing... nothing. Or more precisely, it was throwing a vague "Tool execution failed" error.

I pulled the raw JSON-RPC response to see what IFTTT was actually sending:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [],
    "isError": false,
    "structuredContent": {
      "applets": [...]
    }
  }
}

See it? The content array is empty. The actual data is in structuredContent.

According to the MCP spec, tool results go in the content array as TextContent or ImageContent objects. That's what Amazon Quick reads. IFTTT decided to put their data in a custom structuredContent field instead, leaving content as an empty array.

The fix is a response transformer that runs before writing to stdout:

function transformToolResponse(jsonRpcResponse) {
  if (!jsonRpcResponse || !jsonRpcResponse.result) return jsonRpcResponse;

  const result = jsonRpcResponse.result;

  if (
    result.structuredContent &&
    (!result.content || result.content.length === 0)
  ) {
    result.content = [
      {
        type: 'text',
        text: JSON.stringify(result.structuredContent, null, 2),
      },
    ];
  }

  return jsonRpcResponse;
}

12 lines. That's all it took. But finding the problem? That was the hard part.

The Main Proxy Loop

With both gotchas solved, the main proxy loop is clean:

async function proxyMcpRequest(jsonRpcMessage) {
  const token = await getValidToken();

  const headers = {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${token}`,
    'Accept': 'application/json, text/event-stream',
  };

  if (mcpSessionId) {
    headers['Mcp-Session-Id'] = mcpSessionId;
  }

  let response = await httpsStreamingRequest(IFTTT_MCP_URL, {
    method: 'POST', headers
  }, JSON.stringify(jsonRpcMessage));

  // Capture session ID for subsequent requests
  if (response.sessionId) {
    mcpSessionId = response.sessionId;
  }

  // Handle 401 - try token refresh
  if (response.status === 401) {
    cachedToken = await refreshToken(cachedToken);
    headers['Authorization'] = `Bearer ${cachedToken.access_token}`;
    response = await httpsStreamingRequest(IFTTT_MCP_URL, {
      method: 'POST', headers
    }, JSON.stringify(jsonRpcMessage));
  }

  return response;
}

The Accept: application/json, text/event-stream header is important. It tells IFTTT "I can handle both formats." Without it, you might not get the SSE stream at all.

How to Register It as an MCP Server

The proxy registers itself in the MCP config as a simple stdio server:

{
  "mcpServers": {
    "ifttt": {
      "command": "node",
      "args": ["/path/to/ifttt-mcp-proxy/index.js"]
    }
  }
}

That's it. Amazon Quick launches the process, pipes JSON-RPC to stdin, reads responses from stdout. The proxy handles everything in between: auth, streaming, format translation, token refresh.

What You Can Actually Do With It

With this proxy running, I can do all of this from my AI assistant using natural language:

"Show me my IFTTT applets" - lists all 12 applets with their triggers and actions
"What does the Create tweet with AI applet do?" - shows full configuration including the AI prompt
"Update the prompt on my tweet applet" - edits the applet configuration via API
"Disable the Reddit applet" - toggles applets on and off
"Create a new applet that..." - builds new automations from scratch

No browser. No IFTTT web UI. Just conversational access to my entire automation setup.

What I Learned Building This

A few takeaways if you're building something similar:

The MCP spec has transport flexibility. Stdio and Streamable HTTP are both valid, but they don't interoperate automatically. If you're connecting a stdio client to an HTTP server, you need a proxy.
If you're working with MCP on AWS, Amazon Bedrock Agents supports MCP servers natively for remote tool use... so you might not need a custom proxy if you're already in that ecosystem.
SSE is sneaky. When a server returns 202 Accepted, your instinct is "okay, no content." But with SSE, the content is coming... just not the way you expect. Always check Content-Type before closing the connection.
Not everyone implements the spec the same way. IFTTT's use of structuredContent instead of content[] is technically non-standard. Your proxy might need to normalize responses.
OAuth 2.1 + PKCE is worth the complexity. No client secrets stored on disk, proper token rotation, and it works great for local tools that need to authenticate with remote services.
AI assistants are shockingly good at integration plumbing. I didn't write a single line of this proxy by hand. I described the problem to Amazon Quick, and it generated the entire thing... the OAuth flow, the streaming HTTP client, the SSE parser, the response transformer.

When something broke, I described the symptoms and it diagnosed and fixed the issue. The whole thing went from "IFTTT has MCP support" to "fully working native integration" in about an hour of back-and-forth conversation. That's the real story here. I've written more about this dynamic between developer and AI coding assistant... it's a relationship worth understanding.
Tools like the AWS Toolkit for AI Agents are making this kind of AI-assisted building the norm rather than the exception.

The full proxy is about 500 lines of zero-dependency Node.js. No npm install needed. Just node and the built-in http, https, and crypto modules.

The complete source code is on GitHub.

I would be very interested to hear your thoughts or comments, so if you've built something similar or found a different approach, ping me on X or LinkedIn or feel free to leave a comment below.

And if you're trying to connect other remote MCP servers to a local client...
your mileage may vary, but the pattern should be the same.

Your AI Provider Is a Single Point of Failure

Maish Saidel-Keesing — Tue, 16 Jun 2026 14:25:48 +0000

Last Friday, the U.S. Commerce Department sent a letter to Anthropic. By that evening, Fable 5 and Mythos 5 were gone. Not deprecated. Not throttled. Gone. API calls returned 404s. Live sessions errored out mid-conversation. Production applications that depended on those models simply stopped working.

Three days after launch. No warning. No migration window.

And honestly? We got lucky this time. Fable 5 was only available for three days. Nobody had time to build real production dependencies on it. Imagine this happening to a model you've been using for six months. A model your entire product depends on. That's the scenario you should be planning for.

I would like to ask you something. If your database vendor could be forced to shut down your primary database with a single government letter, would you run it without a failover? Of course not. But that's exactly what most teams are doing with their AI provider.

The Ticking Time Bomb

Most teams treat their AI provider like electricity. You flick a switch, the light goes on. You don't think about where it comes from, you don't think about what happens when it stops. You just expect it to work. You pick a model, hardcode the API endpoint, build your prompts around its quirks, and ship. It works great. Until it doesn't.

And look, I get it. When you're building fast, the last thing you want to think about is "what happens when my model disappears." But this week proved that's not a theoretical risk anymore. It's not even about uptime.

Your model can be pulled for regulatory reasons. For policy changes. For geopolitical drama that has absolutely nothing to do with your application. The Anthropic situation wasn't a bug. It wasn't infrastructure failure. It was a regulatory kill switch. And it affected every single customer worldwide.

I've written before about the hidden costs of depending too heavily on AI tools without understanding what's under the hood. This is the same problem, just at a different layer of the stack.

We've Seen This Movie Before

This frustrates me. We already know how to do this. We've spent decades building resilient systems. We don't run a single database without replication. We don't rely on one CDN. We put load balancers in front of everything. We design for failure because we've been burned enough times to know that everything fails eventually.

But somehow, when it comes to the model layer, we forgot all of that.

Teams are building entire products on a single provider's API with zero fallback. No abstraction layer. No alternative routing. No graceful degradation. Just a direct dependency on one vendor's model, and a prayer that nothing goes wrong.

That's not engineering. That's hope-driven architecture.

Resilience Patterns That Apply Here

So what do you actually do about it? The patterns aren't new. You just need to apply them to the model layer the same way you apply them everywhere else.

Multi-provider architecture

Abstract your model calls behind an interface. Your application shouldn't know or care which provider is serving the response. When one goes down (or gets shut down by a government letter), you route to another.

This doesn't mean you need to maintain identical prompts across five providers. It means you design your system so that swapping a provider is a configuration change, not a rewrite. And yes, there's a cost. Maintaining that abstraction layer is real engineering work. You're building and testing against multiple providers, handling different response formats, managing prompt variations. It's not free. But neither is waking up on a Saturday morning to find your only provider is gone and you have no plan B.

Open-weight models as a hedge

If you run the model yourself, nobody can switch it off remotely. Full stop.

Open-weight models give you that. They might not always be the frontier option. They might not top the leaderboards. But they're yours. No government order, no policy change, no business dispute can take them away from you. Think of it like owning a generator versus relying on the grid. The grid is more powerful, sure. But when it goes dark, you're the one still running.

You don't have to run everything on open-weight models. But having one in your fallback chain means you always have a floor. A baseline that works regardless of what happens to your commercial providers.

Circuit breakers

This is basic resilience engineering, but I'm amazed how few teams implement it for their LLM calls. When your AI provider starts failing, you need to detect it fast, stop sending traffic, and route to an alternative. Don't wait for timeouts to cascade through your system.

The pattern is simple: monitor error rates, trip the breaker when they spike, route to your fallback, and periodically check if the primary is back. We do this for every microservice. Your model endpoint deserves the same treatment.

Graceful degradation

When Anthropic pulled Fable 5 and Mythos 5, you know what kept running? Opus 4.8. A slightly older, slightly less capable model. But it worked.

That's the pattern. A smaller or older model serving a slightly degraded experience is infinitely better than a broken application serving nothing. Design your system so it can drop down a tier without crashing. Your users would rather get a good-enough response than an error page. I touched on the non-deterministic nature of LLMs before and how we're still figuring out how much to trust them. Graceful degradation is part of that answer.

We Already Know This

I've been talking about Day 2 operations for GenAI workloads for a while now. And the core message hasn't changed: treat your AI components like any other critical production dependency. Observability, failover, and testing what happens when things break. All of it applies.

Werner Vogels has been saying "everything fails all the time" for years. Your AI provider will have a disruption. It might be an outage. It might be a pricing change that makes your unit economics impossible overnight. It might be a model deprecation with a 30-day notice. Or it might be a government letter on a Friday afternoon.

So ask yourself: does your architecture assume this will happen?

If the answer is no, this week gave you a preview of what's coming. And next time, it might be your provider.

Have you built multi-provider fallback into your AI stack? Or are you still running on hope-driven architecture? Let me know in the comments below.

Your Coding Assistant Is Not You

Maish Saidel-Keesing — Mon, 01 Jun 2026 14:46:22 +0000

I was scrolling through Twitter (I will always call it Twitter...) the other day and I saw it again. Another developer posting about hitting their rate limit mid-flow. The panic. The frustration. The "no no no, not NOW" reaction. Then a service outage hits and my WhatsApp groups light up. Slack communities go into meltdown. Everywhere I look, developers are talking about that moment when their AI coding assistant goes silent and they realize they don't know what they are going to do next. Rate limits, outages, degraded performance. Doesn't matter what causes it. The reaction is the same.

That reaction? It looks a lot like addiction. Maybe not the clinical kind but rather that kind where a tool becomes so embedded in your workflow, that removing it feels impossible. And if you've been using AI coding tools for any length of time, you've probably seen it in yourself too.

The Numbers Tell a Story

Let's start with what's happening at scale. 84-90% of developers are now using AI coding tools. 51% use them daily. Claude Code grew 80x in a single year, far exceeding Anthropic's planned 10x. Cursor went from zero to $2 billion ARR in three years. Uber burned through its entire 2026 AI budget by April because Claude Code spread across 5,000 engineers faster than anyone anticipated. These are not the adoption curves of a "nice to have" productivity tool. This is deep integration. This is dependency at an organizational level.

When Anthropic doubled usage limits as a "holiday gift" in December and then restored normal limits in January, developers experienced what felt like a 60% capacity reduction. One developer wrote during an outage: "Claude outages hit way harder when you realize you've outsourced half your brain to it." The allure is real. And it's by design.

AI Coding Tool Vendors Create the Lock-In

Here's what I find interesting from an engineering perspective. The way these AI coding tool vendors have built their products actively encourages dependency. Credit systems with opaque limits. Rolling resets you can't predict. That feeling of relief when you actually get that reset. Temporary promotional bonuses that set a new baseline and then get yanked. If you squint, it looks a lot like vendor lock-in patterns we've been warning each other about for years. Except this time, the lock-in isn't in your infrastructure. It's in your workflow. In your muscle memory. In the way you approach problems.

The UBC CHI 2026 study analyzed 334 developer self-reports and found consistent patterns: escalating usage, failed attempts to reduce, genuine distress when access is limited. The study's senior author put it bluntly: "Deliberate design decisions by some of the corporations involved are contributing, keeping users online regardless of their health or safety." Sound familiar? It should. We've spent decades talking about dark patterns in UX. This is the same playbook, now applied by AI coding tool vendors to their developer customers.

The Skill Erosion Problem

Here's where it gets uncomfortable from a technical standpoint. Anthropic's own randomized controlled trial found that developers using AI scored 17% lower on skill tests. Their own study. Their own tool! Making their own users measurably worse at coding. I've written before about the hidden costs of letting AI write your code unchecked. But this goes deeper than tech debt.

The METR trial is even more telling. Developers felt 20% faster. They were actually 19% slower. A 39-percentage-point gap between perceived and actual productivity. Think about what that means in practice. You're shipping code you think you wrote faster. You didn't. You're making architectural decisions with less understanding of the codebase. You're debugging less, which means you're learning less about how your systems actually behave.

The de-skilling pipeline looks like this:

Delegate a task to the AI
The skill you didn't exercise starts to atrophy
Next time, you have to delegate because you can't do it yourself
Repeat until you're stuck without the tool

It's a dependency loop. And like any dependency loop in code, once you're in it, breaking out requires deliberate effort.

And here's what makes it addictive in the truest sense: the tool degrades the very skills you'd need to stop using it. That's not just lock-in. That's a trap.

We've Been Here Before (well... sort of)

Some perspective before the panic sets in. Developers worried that IDEs would make them forget command-line compilation. They were afraid that Stack Overflow would make them forget algorithms. They worried that frameworks would make them forget the fundamentals underneath. And honestly? Some of that happened. Plenty of developers can't write a sorting algorithm from scratch anymore. I sure as hell can't. But they can still build great software because the skill shifted, not disappeared.

So what's different this time? The level of abstraction. Previous tools automated the typing. AI coding assistants automate the thinking. A code completion tool saves you keystrokes. An AI agent that writes your implementation, your tests, and your documentation is operating at the cognitive level. That's a fundamentally different kind of dependency than anything we've dealt with before. That's the part worth paying attention to.

Tools Don't Define You

Here is the thing I keep coming back to. Your knowledge is yours. Your creativity is yours. Your judgment is yours.

A coding assistant can generate code. It can generate a lot of code, actually. But it cannot replace the thinking that tells you which code to write. Or why. Or whether you should write any code at all. The architecture decisions. The tradeoffs. The "this feels wrong" instinct that comes from years of getting burned by bad abstractions. The ability to look at a system and understand not just what it does, but what it should do. This is the bigger picture of what GenAI is doing to our profession. And it's worth paying attention to.

That's still you. That will always be you. A calculator doesn't make you a mathematician. A GPS doesn't make you a navigator. And a coding assistant doesn't make you an engineer. These are tools. Genuinely good tools. But they don't define who you are or what you're capable of. The moment you let them replace your thinking instead of augmenting it? You've lost the plot.

Awareness Is the Fix

What do you actually do about this? You don't quit using AI assistants. That's not realistic and honestly it's not necessary. The fix isn't abstinence. It's intentionality.

Some signals that you might have crossed the line from "using a tool" to "depending on a crutch":

You can't start a task without opening the AI first
You can't debug without it. Not "prefer not to" but genuinely can't
Rate limits trigger genuine anxiety, not mild annoyance
You accept AI output without reading it because "it's probably fine"
You haven't written something from scratch in weeks
You can't explain the code that's running in your own project

Any of these sound familiar? Be honest with yourself. The fix is simple in concept, harder in practice. Use the tool for what it's good at. The boilerplate. The scaffolding. The "I know what I want but typing it out is tedious" stuff. But keep the thinking for yourself. The design decisions. The debugging. The "why does this even exist" questions. Exercise those muscles deliberately, the same way you'd go for a run even though cars exist.

My Challenge To You

Remember those developers I mentioned at the start? The ones panicking over rate limits? That panic is a signal. Not a sign that they need a higher tier plan. A signal that maybe they've let the tool become load-bearing in places where they should be load-bearing. And if you're being honest with yourself, you might recognize a bit of that too.

Next time you hit a limit, or the service goes down, or you just feel that spike of frustration... Close the AI chat. Open a blank file. And write something yourself. Just to prove you still can.

I would be very interested to hear your thoughts or comments on this piece, please feel free to ping me on Twitter or leave a comment below.

The Next Casualty of the GenAI Revolution

Maish Saidel-Keesing — Tue, 05 May 2026 13:25:34 +0000

I was at an event this morning where someone said something that really resonated with me. "The new programming language is English." And you know what? They're right. Jensen Huang said the same thing. Andrej Karpathy has been saying it since 2023. And Marc Andreessen did a whole podcast about it. But while I was sitting there nodding along, something else clicked in my head. Something bigger. Something that I think we're not talking about enough.

We talk a lot about the 'casualties' of GenAI. Students who are terrified they won't have jobs waiting for them after university. Junior developers who are finding it brutally hard to land a position in today's market. The whole "should I even study Computer Science?" existential crisis. These are real, painful, happening-right-now problems.

But here is where it gets interesting. I think there's another casualty coming. One that's a few years out maybe, but it dawned on me this week, and I can't shake it. And it's a big one.

The personal computer.

Your agent doesn't need a MacBook Pro

Let me explain what I mean. We're seeing more and more systems where you provide a prompt to an AI tool and it goes out and does stuff for you. A very good example of this is all these MCP connections, A2A protocols that hook into every system you use and do things on your behalf. They're becoming your personal assistant. Your digital butler. Your "I'll handle it" person.

And the way we interact with these assistants? Usually through some kind of voice interface or through instant messaging. WhatsApp, Telegram, whatever works for you. And these are the tools which I think, once upon a time, we hoped would be the way we'd interact with our computers and phones. Siri. Alexa. Google Assistant. Gemini. God forbid, Cortana. You speak to an entity and that entity does stuff for you.

But they were never really able to deliver on what they were supposed to. I use my Alexa device to pretty much only turn on a timer for when I am cooking, or ask questions about how much 350 degrees Fahrenheit is in Celsius? Until now.

By hooking up multiple tools to some kind of orchestrator that can do everything for you and actually become your personal assistant, you are now able to control pretty much your entire life by talking into your phone or writing a message. Think about that for a second. Projects like OpenClaw and its growing list of alternatives are doing exactly this. They connect to your email, your calendar, your messaging apps, your code repos, your design tools, sometimes securely, sometimes... let's just say it's a work in progress. But the point is, they're turning a simple chat interface into a full-blown command center for your digital life. And they're running on a server somewhere, not on your laptop.

Do I really need a powerful laptop?

I'll give you a personal example. Last week I needed to put together a presentation for an upcoming talk. In the past, I would have fired up PowerPoint on my laptop, spent an hour fiddling with layouts and formatting, maybe opened Photoshop to tweak an image or two. Instead, I described what I wanted to an AI assistant, and it generated the whole deck for me. Slides, structure, speaker notes, the lot. My laptop was barely breaking a sweat because it wasn't doing the work. The agent was.

What I think is going to happen in the not-too-distant future is, we're not going to need all these powerful laptops and desktops anymore. All you'll need is some kind of personal agent running somewhere. It could be a VPS. Could be for example, in the cloud running on Lightsail. Could be on a Mac Mini humming away in a cupboard at home. And that agent will be able to do everything for you.

And a way to interact with it, and we all have that, it's your phone.

I can ask it to design something in a graphic design tool. Actually, scratch that. I don't even need Photoshop or Figma anymore because I can generate those things directly with an AI prompt. I can ask it to build me a website. I can ask it to write code, test it, deploy it. I can ask it to go into Canva and create a presentation. Or just skip Canva entirely and have it generate the slides from scratch.

You see where this is going?

I don't need a powerful computer at my fingertips anymore. In the background, running all my workloads, executing my commands and requests, my agent doing it for me and that machine is running somewhere else. All I need is a simple, almost dumb, interface into something that can listen to me and relay my intent.

Here's another one. I'm writing this very blog post while sitting in the car. I'm not typing. I'm talking. A voice note, dictated into my phone, transcribed into text, and then polished by an AI into something readable. My phone is doing the absolute bare minimum here. Recording audio and sending it somewhere smarter than itself.

English is the new programming language

And let me tell you, it's a hell of a lot quicker than typing it out by hand. The same way it's a hell of a lot quicker to ask an LLM to generate code for me instead of me actually writing and typing that code character by character. I can speak a lot faster than I can type. I can talk without having to put my fingers to use. And usually, I can do it while doing something else entirely. Multi-tasking for the win.

And this is precisely the point. We don't really need to know programming languages anymore (well, not all of us, not for everything) because we delegate our tasks and intent into spoken language, which is exactly what an LLM is amazing at doing. Taking that natural language and transferring it into something else. A command. A JSON payload. An API call. A full-blown application. Karpathy calls it Software 3.0. I think he's onto something.

The numbers are already moving

And here's the thing. The numbers are already starting to tell the story, even if the reasons are different today.

Gartner is projecting PC shipments to decline 10.4% in 2026. IDC is calling it 11.3%. Goldman Sachs says 10%. Right now, the analysts are blaming memory costs and pricing pressures. Fair enough. But I think there's a deeper, more structural shift happening underneath, and coupled with the rising prices in memory, this could actually be a perfect storm.

If my agent can do the heavy lifting running on a remote machine, why do I need a physical computer? A MacBook Pro costs around USD 1,600 today. A VPS with 4 GB memory, 2 vCPUs, 80 GB SSD and 4 TB transfer will run you about USD 24 /month. Over 4 years that's USD 1,152.
That's USD 450 less than the MacBook. And I know the specs are not at all the same, but that's kind of the whole point. Your agent doesn't need a Retina display or a force-touch trackpad. It needs compute, memory, and an internet connection. Oh, and it runs 24/7 in an enterprise datacenter with faaster connectivity than you could dream of, where no one can spill a cup of coffee on it.

And if you need more proof that the industry sees where this is heading, look no further than Apple. They just launched the MacBook Neo at $599. Apple. The company that has historically refused to compete on price. The company whose cheapest laptop was $1,099 just a year ago. They're now selling what is essentially a glorified Chromebook with a fruit logo on it. Why? Because even Apple can see that for most people, a lightweight, always-connected, thin-client device is going to be enough. You don't need an M4 chip to talk to your agent.

But Maish, what about...?

Look, I'm not saying the PC is going to disappear overnight. Gamers will still need their rigs (for now). Video editors, 3D artists, and data scientists will still need local horsepower (for now). Developers who run local Kubernetes clusters will still need their 64GB RAM machines (don't worry, I am not one of K8s groupie).

But for the vast majority of knowledge workers? The person who writes emails, creates presentations, manages spreadsheets, edits documents, and hops between 47 browser tabs? That person doesn't need a $2,000 laptop. That person needs a screen, a microphone, and a connection to their agent.

Some food for thought. We went from mainframes to personal computers because we wanted computing power at our desks. Then we went from desktops to laptops because we wanted that power to be portable. Then from laptops to smartphones because we wanted it in our pockets. And now? Now we might be going from all of that back to... something that looks a lot like a dumb terminal connected to a really smart backend.

History might not repeat itself. But it sure does rhyme.

The question we should be asking

So while the world is debating one set of consequences from AI, I think we're missing a completely different one.

Are we going to see a significant, sustained decline in personal computer sales? Not because of memory prices or economic cycles, but because we fundamentally won't need them anymore?

I think the answer is yes. Maybe not this year. Maybe not next year. But it's coming. And when it does, it won't be a blip on a quarterly earnings report. It'll be a structural shift in how we think about personal computing.

The PC had a good run. But the dumb terminal is making a comeback. And this time, it's got a really smart backend.

The Hidden Cost of AI Coding: Technical Debt You Can't See

Maish Saidel-Keesing — Mon, 27 Apr 2026 18:41:41 +0000

I had an interesting conversation with a colleague a few weeks ago. He was looking at his team's metrics - sprint velocity up 40%, PRs merging faster than ever, test coverage sitting pretty at 94%. Everything green. Everything humming.

And then he said something that stuck with me: "Why does it feel like everything takes longer to fix?"

That question was the spark for this post.

The Saturday Night Scenario

Does the following sound familiar to you?

It's a Saturday night. You're finally watching that show everyone's been telling you about. Your phone buzzes. Production is down. The payment service is throwing 500 errors.

You open the code. You stare at it. You wrote this... didn't you? Actually, no. You merged this. Three months ago. Your AI assistant generated it, the tests passed, the PR got approved, and you shipped it.

And now you're sitting there, on your couch, trying to reverse-engineer the thought process of a model that doesn't have thoughts.

Your partner looks over and asks, "Everything okay?"

And you say, "Yeah, I just need to debug code that nobody wrote."

That sentence should terrify you. And it's happening in code bases everywhere, right now.

Let Me Be Clear

This is not an anti-AI post. I love AI coding tools. They've made me faster, they've made my team faster, and honestly, they've made me look a hell of a lot smarter than I actually am.

But over the past year, I've started noticing something. The code we're shipping faster... we're understanding less. The bugs we're creating faster... we're fixing slower. And the teams that are most productive on paper... are accumulating a kind of debt that doesn't show up in any dashboard.

I call it invisible technical debt. And I think it's time we make it visible.

The Productivity Illusion

So let's start with something we can all agree on. AI coding tools are genuinely incredible. Really!!

You type a comment describing what you want, and working code appears. You paste an error message, and you get a fix. You describe an API, and you get the boilerplate, the error handling, the tests, the whole nine yards. A few years ago, this was science fiction. Now it's taken for granted.

And the numbers back it up. Studies show developers using AI assistants report 30 to 55 percent productivity gains. PRs are merging faster. Features are shipping sooner. Sprints are completing ahead of schedule.

If you're a team lead looking at those metrics, you're thrilled. If you're a CTO looking at those metrics, you're buying everyone licenses for whatever tool they want.

So what's the problem?

Here's the thing about productivity metrics, they measure output. Lines of code. Features shipped. PRs merged. Time to deploy. And all of those are going up. Dashboards are green. Everyone's happy.

But let me ask you something. Does your dashboard track how well your team understands the code they shipped? Does it track how long it takes to debug a feature when it breaks six months later? Does it track whether a developer can confidently modify a function they merged last quarter?

No. Nobody tracks that. Because those things are hard to measure. And because right now, everything feels fine.

This is the productivity illusion. You're measuring the speedometer. But nobody's checking the engine.

The Compound Interest You Don't Want

Traditional technical debt accumulates slowly. A shortcut here, a hack there, a "we'll refactor this later" that never gets refactored. We all know this. We've all lived this. It's manageable because it grows at roughly the pace of human coding.

AI changes the math.

When a human writes a shortcut, they usually know it's a shortcut. They remember where it is. They can explain why they did it. The debt is visible, at least to the person who created it. When an AI generates code, the shortcuts are invisible. The developer who merged it may not even recognize them as shortcuts. They look like clean, well-structured code. They pass every check. And they accumulate at the speed of AI generation, which is 10 to 50 times faster than human coding.

Picture a graph with two lines. The blue line is traditional debt accumulation - gradual, linear-ish. The red line is AI-accelerated debt. It starts similar, then curves sharply upward. At some point, the lines cross. That's the moment where the time you spend debugging, maintaining, and trying to understand AI-generated code exceeds the time the AI saved you in the first place.

And the worst part? Most teams don't notice the crossover when it happens. Because the dashboard is still green. Velocity is still up. PRs are still merging.

The symptoms show up later, as longer incident response times, as features that take mysteriously longer to modify, as senior developers who say "I don't know, let me look at this" more and more often.

The Three Invisible Debts

So where exactly is this debt hiding? I've identified three specific types, and I've given them names, because naming things is the first step to seeing them.

Invisible Debt #1: Comprehension Debt

Code that works. Code that nobody understands.

Here's the definition: code that runs correctly, passes every test, ships to production without a single issue... and that nobody on your team can actually explain.

This isn't buggy code. This isn't spaghetti code. This is clean-looking code that happens to be a black box to every human who touches it.

And here it comes, the uncomfortable part.

You know how it happens. I know how it happens. Because I've done it. You've done it. We've all done it. The AI generates something. It looks reasonable. The variable names make sense. The structure looks clean. You run the tests, and they pass. You think, "Yeah, that's probably right."

Probably right.

That word "probably" is doing a lot of heavy lifting in your code base right now.

Here's what changed. When you used to write code yourself, you made decisions. "I'll use a map here because lookup speed matters. I'll handle this edge case because I saw it in production last month." Every line had a reason, even if you didn't write it down.

When AI generates code, the decisions are made for you. And they might be good decisions! But you didn't make them. You don't know why they were made. And six months from now, when something breaks, you can't retrace the reasoning. Because there was no reasoning. There was pattern matching on training data.

You went from being the author of your code to being the audience for it.

Let me put a price tag on this:

Debugging code you didn't write takes 3-5x longer than debugging code you authored yourself. That's not an AI-specific stat, this has been true forever. But AI has dramatically increased the percentage of your code base that falls into the "didn't write it" category.
The knowledge about why your code works the way it does? It lives in the model's training data. Not in your team's heads. Not in your documentation. Not in your commit messages.
When a senior developer leaves and takes institutional knowledge with them? With AI-generated code, the institutional knowledge was never there in the first place. The developer who leaves can't do a knowledge transfer because they never had the knowledge to transfer.

Invisible Debt #2: Homogeneity Debt

When every solution looks the same.

This one is subtle. It's not about individual functions being wrong. It's about your entire code base starting to look like it was written by one person.

Because it was. It was written by a model.

Take two teams. Different companies. Different products. Different requirements. Give them the same problem - say, "build a rate limiter for an API." If both teams use AI to generate the solution, they'll get... basically the same code. Same pattern. Same structure. Same libraries. Maybe some variable names are different. But architecturally? It's a copy.

Now, is that code bad? No. It's probably the most popular pattern on GitHub for that problem. The model learned it from thousands of repositories. It's battle-tested. It's fine.

So what's the problem? The problem is what you didn't get.

A senior developer who understands your specific traffic patterns, your specific infrastructure, your specific failure modes, they might have written something completely different. Simpler. More tailored. Better for your system. But the AI doesn't know your system. It knows the internet's system. It gives you the average of every solution it's ever seen.

And the average is... just that, average.

When you ask five developers to solve a problem, you get five different approaches. You debate them. You learn from the differences. Someone says, "Actually, we don't need the full pattern here because of X." That debate is where engineering judgment lives.

When you ask an AI to solve a problem, you get one approach. The popular one. And the debate never happens.

The Monoculture Risk

There's a concept in agriculture called monoculture. You plant the same crop across an entire field. It's incredibly efficient. Yields are high. Everything is optimized. And then one disease shows up that targets that specific crop, and you lose everything. Because there's no diversity. No resilience. No plan B.

This is what's happening to code bases.

When every team uses the same AI tool, trained on the same data, generating the same patterns, you get a monoculture. Imagine a vulnerability is discovered in a common pattern that AI tools love to generate. How many code bases are affected? Not one. Not ten. Thousands. Tens of thousands. Because they all got the same code from the same model.

With human-written code, vulnerabilities are scattered. Different teams make different mistakes in different places. It's messy, but it's resilient. With AI-generated code, vulnerabilities are correlated. Same tool, same training data, same output, same bug, same place, at scale.

Security people reading this, I see you nodding.

And there's one more cost that bothers me the most. When AI consistently gives you the popular solution, your team stops exploring alternatives. The muscle that says "wait, what if we approached this differently?", that muscle weakens. And you end up with a team of developers who are incredibly fast at implementing the AI's ideas... and increasingly unable to have their own.

Invisible Debt #3: Ownership Debt

It's in my repo. But it's not my code.

This is the human one. The first two debts are about code. This one is about people. Ownership debt is what happens when your team stops feeling responsible for the code in their own repository.

Think about the shift:

In 2022, when something broke, the developer said, "I'll fix it - I wrote it, I know where to look." In 2026, when something breaks, the developer says, "Let me try regenerating it with a different prompt."

That's not debugging. That's gambling. You're rolling the dice and hoping the AI gives you a better answer this time.

And here's the psychological piece that nobody talks about. When you write code, you feel ownership. It's yours. You're proud of it, it's your baby, or at least you're responsible for it. When it breaks, it's personal, and that's actually a good thing, because it means you care enough to fix it properly.

When AI writes code and you merge it, there's a psychological distance. It's not yours. You're a curator, not a creator. And when it breaks, the instinct isn't "let me understand what went wrong", it's "let me get the AI to try again."

Let me walk you through a scenario that's happening right now on teams everywhere.

Month one. A developer needs to build a data pipeline. They describe it to their AI assistant. The AI generates it - ingestion, transformation, validation, output. Beautiful. Tests pass. Ships to production. Everyone's happy.

Month three. An upstream data format changes. The pipeline breaks. The developer who merged it opens the code.

And here's the moment of truth. Do they read the code, understand the transformation logic, and make a targeted fix? Or do they open their AI assistant, paste in the error message, and say "fix this"?

If your honest answer is "they'd probably ask the AI".

Bam!! That's ownership debt.

Because what happens when the AI's fix introduces a new bug? They ask the AI again. And again. And now you're three layers deep in AI-generated patches on top of AI-generated code, and nobody, nobody, has a mental model of how this pipeline actually works.

You don't own code you can't change confidently.

And this has a human cost. Developers who spend their days reviewing and merging AI output start to feel like operators, not engineers. They're not solving problems, they're supervising a machine that solves problems. That's not why most of us got into this field.
Your best developers, the ones with options, they notice this first. And they leave. Not because the AI is bad, but because the work stopped being interesting.

And when they leave? The institutional knowledge was never formed. There's nothing to transfer. The new developer inherits a code base that the previous developer also didn't fully understand.

It's turtles all the way down.

Why Your Safety Nets Have Holes

Three invisible debts. Some of you are thinking, "Okay, but we have processes for this. We have tests. We have code reviews. We have CI/CD pipelines. Surely those catch this stuff."

Let me show you why every single one of these is blind to the debts we just talked about.

The Test Coverage Illusion

AI tools are phenomenal at generating tests. You point them at a function, and they'll produce unit tests, edge case tests, integration tests, the works. Your coverage number goes up. Your dashboard goes green. Everyone celebrates.

But here's what's actually happening. The AI wrote the code. Then the AI wrote the tests for its own code. The tests validate the AI's logic. Not your requirements. Not your business rules. Not the things your users actually care about. It's like writing an exam and then grading your own paper. Of course you're going to pass.

Here's a concrete example. Imagine a pricing function. The AI generated it. The AI also generated tests for it. Coverage: 100%. All passing. But there's a business rule: discounts over 30% require manager approval. It's in a Confluence doc somewhere. It's in the heads of the sales team. It's in the contract with your biggest client.

It's nowhere in this code. And it's nowhere in these tests. Because the AI didn't know about it. And the developer who accepted the code didn't think to add it, because the tests were already green. Why would you add more tests when you're at 100%?

100% coverage. Zero percent of the business rule covered. And the dashboard says everything is fine.

The Code Review Problem

When you review code a human wrote, you're not just reading code. You're reading intent. The commit message tells you what problem they were solving. The PR description explains their approach. You know the developer, you know their patterns, their strengths, their blind spots. You can ask, "Why did you do it this way?"

When you review AI-generated code, all of that context is gone. The commit message is vague. The PR description is "generated with AI" or, let's be honest, empty. And if you ask the developer why the code works this way, they say...

"I don't know, the AI suggested it."

And here's what the research shows, reviewers spend less time on AI-generated PRs, not more. Because the code looks clean. It's well-formatted. The variable names are good. It looks like it was written by someone who knows what they're doing.

So we review it faster, with less scrutiny, and with less context than we'd give to human-written code. That's not a safety net.

That's a trap door with a nice rug over it.

The Documentation Gap

AI is actually pretty good at generating documentation. It'll add comments, docstrings, README sections. But look at what it generates.

It generates what documentation: "This function calculates the retry delay using exponential backoff."

What it can't generate is why documentation: "We use exponential backoff here because our upstream API rate-limits aggressively after 3 rapid retries. Linear backoff caused cascading failures in the Nov 2024 incident (see post-mortem #47)."

The why is what saves you at 2 AM. The what is just a slightly more readable version of the code itself.

When humans write code, the why lives in their heads even if they don't write it down. You can walk over and ask them. With AI-generated code, the why doesn't exist. Not in the code. Not in the docs. Not in anyone's head. It's just... gone.

Three safety nets. Three holes.

Now you might say, dude, you are all doom and gloom, and don't give me problems, give me solutions! Ok, here you go.

The Playbook: Four Things You Can Do on Monday

I'm going to give you four plays. They're not theoretical. They're not "hire a team of consultants that will charge you half of your IT budget and come back with a 400 page document in 8 months." They're things you can bring to your team on Monday morning and start doing that week.

Play 1: Make the Invisible Visible

You can't fix what you can't see. So start measuring.

Metric one: AI Ratio. What percentage of your merged code was AI-generated versus human-authored? Most teams have no idea. They'd guess 20%. The real number is often 60, 70, sometimes 80 percent. How do you track it? Simple. Add a tag to your PR template. A checkbox. "This PR contains AI-generated code: yes/no." It's not perfect, but it's a start. You'll have a baseline within two weeks.

Metric two: Comprehension Checks. This one's my favorite because it's so low-tech it's almost embarrassing. Two weeks after a PR merges, randomly pick a developer and ask them to explain a function from that PR. No looking at the code. Just explain it. What does it do? Why does it do it that way? What are the edge cases? If they can, great! If they can't, you've found comprehension debt. Mark it. Track it. Watch the trend.

Metric three: Debug Delta. Start tracking how long it takes to resolve incidents in AI-generated code versus human-written code. You probably already have incident response times. Now slice them by whether the affected code was AI-generated. I'll tell you what you'll find, the delta is real. And once your team sees the numbers, the conversation about AI coding practices changes from philosophical to practical.

Play 2: Review Like It's AI Code

Change how you review AI-generated code. Using three simple rules.

The Explain Rule. Before merging any PR that contains AI-generated code, the developer writes, in the PR description, in their own words, what the code does and why it does it that way. Not "AI generated retry logic." I want: "This implements exponential backoff starting at 200ms, doubling up to 5 retries, because our upstream API returns 429s under load and we need to stay under their rate limit. And this bit us in the ass during the downtime in November 2025." If the developer can't write that explanation, they don't understand the code well enough to ship it.

Full stop.

The Touch Rule. Every AI-generated block must have at least one meaningful human modification before it merges. Not a renamed variable. A real change, an added edge case, a refactored condition, a different approach to error handling. Because the act of modifying code forces you to understand it. You can't change something you don't comprehend. It's a forcing function for engagement.

The Buddy Rule. AI-heavy PRs get two reviewers, not one. The second reviewer has one specific job: "Could I debug this at 2 AM without the original author?" If the answer is no, it's not ready to merge.

Three rules. You can implement all three by Friday.

Play 3: Build Ownership Rituals

Walkthrough Wednesday. Once a week, one team member picks a section of AI-generated code and explains it to the team. Not a formal presentation, just 15 minutes. "Here's what this does, here's why, here's what I'd watch out for." Two things happen. The person presenting has to actually understand the code, so they learn it. And the rest of the team gains shared context.

Rotate the hot spots. Don't let one person be the permanent owner of AI-generated modules. Rotate. If Sarah generated the payment pipeline, have David do the next modification. Now two people understand it. This feels slower. It is slower, in the short term. But it eliminates the single point of failure where one person leaves and nobody understands a critical system.

Rewrite the critical path. Identify the most important code paths in your system, the ones that handle money, user data, authentication, core business logic. If those were AI-generated, schedule time to rewrite them by hand. Not all of them. Not everything. Just the code where a failure at 2 AM means you're waking up the CEO. That code needs to be yours.

Play 4: Set Boundaries, Not Bans

Don't ban AI tools. That's a losing battle and it's the wrong answer anyway. Instead, create zones.

🟢 Green zone - AI encouraged. Boilerplate code. Scaffolding. Utility functions. Test generation for code your team already understands. This is where AI shines and the debt is cheap. Let it rip.
🟡 Yellow zone - AI with extra scrutiny. Business logic. API integrations. Data transformations. This is where the Explain Rule and the Buddy Rule kick in. Use AI here, but make sure a human deeply understands every line before it merges.
🔴 Red zone - Humans only. Security. Authentication. Financial calculations. Core algorithms that define your product. This is the code where a bug doesn't just cause an incident, it causes a headline on the daily news.

The goal isn't to stop using AI. It's to use it where the debt is cheap and avoid it where the debt is expensive. Your team can define these zones in a single meeting. Put it in your contributing guide. Make it explicit. Because right now, the boundary is implicit, which means it doesn't exist.

One Question to Take Home

Four plays.

Measure it. Review it differently. Build ownership. Set boundaries.

None of these require new tools. None of these require budget approval. None of these require your CTO to sign off on a six-month initiative. They require a conversation with your team and the willingness to slow down just enough to stay in control of what you're building.

But if all of that feels like too much to start with, let me leave you with just one thing.

Go back to work tomorrow. Pick a function, any function, one that shipped in the last month. Ask the developer who merged it to explain it from memory. No looking at the code.

If they can, great. You're in good shape.

If they can't, you've just found your invisible debt. And now you can see it. Now you can do something about it.

That's all it takes to start. One question. One conversation.

AI coding tools are the most powerful productivity tools our industry has ever seen. That's not changing. And it shouldn't change. But productivity without understanding, is just speeding towards a wall.

Build fast. Ship fast. But build things you understand. Ship things you own. And make sure that when the phone buzzes at 2 AM, someone on your team can say, "I got this."

I would be very interested to hear your thoughts or comments, so please feel free to ping me on Twitter.