DEV Community: Tyson Cung

Claude Opus 4.8: Effort Control Changes How You Work With AI

Tyson Cung — Fri, 29 May 2026 06:07:28 +0000

Anthropic released Claude Opus 4.8 yesterday, and it ships with something developers have wanted since GPT-3: a knob that controls how hard the model thinks. Not a prompt engineering trick. Not "think step by step." An actual slider that dials compute up or down depending on what the task needs.

Alongside this, they announced a $65 billion Series H at a $965 billion valuation. Big numbers, but the interesting part is what the model can actually do.

Let me walk through the three features that change how you work with AI, and why they matter for everyday development.

The Effort Slider Is Bigger Than It Sounds

Every developer has been here: you ask an LLM to review a PR, and it spots a missing semicolon but misses the race condition three lines up. Or you ask it to rename a variable, and it spends 30 seconds "thinking" about it.

The problem is that current models apply roughly the same compute to every request. Claude Opus 4.8 lets you decide.

Low effort     → Quick reviews, refactoring, boilerplate
Medium effort  → Architecture decisions, debugging, data analysis
High effort    → Complex multi-file changes, security audits, system design

This isn't just a UI gimmick. It changes the economics of using AI for development. Instead of paying for maximum compute on trivial tasks, you match compute to complexity and save money on the 80% of requests that don't need deep reasoning.

Cursor's CEO Michael Truell said Opus 4.8 "exceeds prior Opus models across every effort level" and that "tool calling is meaningfully more efficient, using fewer steps for the same intelligence."

Claude Code Gets "Dynamic Workflows"

If you use Claude Code (or any AI coding agent), you know the pattern: it works great on a single file or small feature, but falls apart on large-scale changes that span dozens of files and services.

Dynamic workflows are Anthropic's answer to this. Instead of a single linear chain of reasoning, Claude can now decompose large problems, work on sub-tasks independently, and synthesize results.

Here is what that looks like in practice:

Before (Opus 4.7):

"Refactor the authentication system" → model attempts it as one giant task
Loses context mid-way, misses edge cases, produces inconsistent code

After (Opus 4.8 with dynamic workflows):

Same request → model breaks it into: audit current auth flow, design new interface, migrate each service, update tests
Maintains consistency across sub-tasks
Catches its own mistakes and pushes back on unsound plans

A staff engineer at Anthropic described it perfectly: "In Claude Code, it asks the right questions, catches its own mistakes, pushes back when a plan isn't sound, and builds up confidence around complex, multi-service explorations before making big changes."

For teams building with AI agents, this is the difference between a tool that handles PR comments and one that can genuinely own a feature.

Fast Mode Got 3× Cheaper

Speed and cost are usually a tradeoff. Opus 4.8's fast mode runs at 2.5× the speed of standard mode, and it is now three times cheaper than fast mode was on previous models.

The practical impact: you can use Opus 4.8 in fast mode for real-time coding assistance without burning through credits. Think Copilot-level latency with Opus-level intelligence.

Here is a rough cost comparison for a typical development session:

Mode	Speed	Relative Cost	Best For
Fast	2.5× baseline	1×	Real-time pair programming, autocomplete, quick fixes
Standard	1× baseline	1× (same price as Opus 4.7)	Code review, debugging, architecture discussions
High Effort	Slower (more compute)	Higher	Complex system design, security audits

The headline: Opus 4.8 costs the same as 4.7 at standard mode, but you get more control over where your compute budget goes.

Benchmarks and Real-World Performance

The benchmark tables tell one story. What early testers say tells another:

On coding benchmarks, Opus 4.8 outperforms Opus 4.7 across SWE-bench, HumanEval, and agentic coding tasks. TR Labs' Super-Agent benchmark is particularly notable: Opus 4.8 is the only model to complete every case end-to-end.

On computer use, it scores 84% on Online-Mind2Web, a meaningful jump over both Opus 4.7 and GPT-5.5. If you are building browser automation or web agents, this is the strongest model available.

On enterprise workflows, Databricks reported that Opus 4.8 "unlocks a step change in agentic reasoning, tackling deeper, multistep questions faster than any prior Opus" at 61% cheaper token cost than Opus 4.7.

One pattern that keeps coming up in tester feedback: Opus 4.8 proactively flags issues in inputs and outputs that other models miss. A senior investment analyst noted that "the biggest differentiator was Opus 4.8's tendency to proactively flag issues with the inputs and outputs of an analysis, something other models routinely missed and left to the users to catch."

What This Means for Developers

Three practical takeaways:

1. Stop prompting for effort. Use the slider.
"Think carefully" and "take your time" prompts are guesswork. The effort control gives you deterministic control over compute allocation. Use low effort for mechanical tasks, high effort for reasoning-heavy work.

2. AI agents just got production-ready.
Dynamic workflows solve the biggest barrier to autonomous coding agents: handling tasks that are too large for a single context window. If you have been on the fence about agentic coding tools, this release changes the calculus.

3. The pricing model is evolving in your favor.
Same base price as the previous generation, with cheaper fast mode and controllable compute. The trend across all frontier models is toward more granular cost control. Build your tooling to take advantage of it.

The Bigger Picture

The $65 billion raise is eye-catching, but the product direction is more interesting. Anthropic is betting that the next phase of AI adoption isn't about bigger models, it's about more useful ones. Effort control, dynamic workflows, and tiered pricing are features for people who use AI to ship software every day, not just for benchmark leaderboards.

If you are using Claude Code, Cursor, or any AI coding tool built on Claude, these features are available now. The fast mode alone makes it worth switching from the default settings.

Claude Opus 4.8 is available today on claude.ai, the Anthropic API, Amazon Bedrock, and Google Cloud's Vertex AI. Claude Code users get dynamic workflows automatically.

The AI Free Ride Is Over: Why Your Token Bill Is About to Skyrocket

Tyson Cung — Thu, 28 May 2026 06:04:33 +0000

Simon Willison ran a tool to check his actual token usage last week. The result: $2,180 worth of API calls in 30 days. His subscription cost? $200. That's an 11x gap, and it tells you exactly where the AI industry is going.

Over the past two months, both Anthropic and OpenAI have quietly executed the same playbook: shift enterprise customers from flat-rate pricing to per-token billing. The free ride is over, and developers who depend on AI coding agents are about to feel it.

The Pricing Shift Nobody Noticed

Here's what changed and when:

Anthropic (Claude Code, Enterprise plans): Originally sold as "Claude seats include enough usage for a typical workday" at a flat rate. Sometime in the last six months, new enterprise contracts switched to $20 per seat per month plus API token pricing. Existing customers are discovering this change as their contracts come up for renewal. The Information reported on the shift on April 14, but an Anthropic spokesperson claimed the change actually happened in November 2025.

OpenAI (Codex, April 2026): On April 2, OpenAI switched Codex pricing from per-message to per-token billing for Plus, Pro, and ChatGPT Business plans. By April 23, this applied to all Enterprise plans, including Edu, Health, Gov, and ChatGPT for Teachers. The credits system maps directly to API token costs.

In both cases, the flat-rate era is dead. You now pay for every token your developers consume.

How Much Are Developers Actually Using?

Willison's ccusage tool breakdown is revealing:

$ ccusage
Anthropic Claude Code (30 days): $1,199.79
OpenAI Codex (30 days):         $980.37
Total:                          $2,180.16

He describes himself as a "moderately heavy user, certainly not running agents every hour." If a single power user hits $2k per month, imagine a 50-person engineering team.

Let's do the math:

Monthly AI tooling cost for a 50-dev team:
------------------------------------------
Light users (40 devs, ~$200/month):    $8,000
Heavy users (8 devs, ~$800/month):     $6,400
Power users (2 devs, ~$2,000/month):   $4,000
                                       -------
Monthly total:                         $18,400
Annual:                                $220,800

For context, that's roughly the cost of two additional senior engineers. Is the productivity gain worth it? For many teams, absolutely. But the bill still stings when you weren't budgeting for it.

The Hacker News Reaction

Simon Willison's piece hit 765 points and 400+ comments on Hacker News within hours. The top threads reveal three camps of developers:

Camp 1: "This is fine, still worth it"

"I would gladly pay $1k/month for Claude Code. It's replaced 2-3 hours of tedious work every single day." , top-voted comment

Camp 2: "I'm cutting back"

Multiple developers reported setting hard daily token budgets, switching to local models for boilerplate code, and being more selective about when they invoke agents. One developer built a wrapper that routes simple queries to Ollama and only escalates to Claude for complex refactors.

Camp 3: "We're building alternatives"

Several HN commenters shared projects to build cost-aware coding agents that track token usage in real time, display a running tally in the terminal, and cut off requests when they exceed a budget. These tools didn't exist three months ago because nobody needed them.

What This Means for the AI Industry

The pricing shift isn't just about revenue. It signals something bigger: product-market fit.

Simon Willison's title says it plainly: "I think Anthropic and OpenAI have found product-market fit." When customers complain about prices instead of switching off entirely, that's a strong signal. Enterprise users aren't leaving. They're paying.

But there's a second signal: the labs are under immense pressure to become profitable. The Verge's Hayden Field captured it perfectly in April with the headline "You're about to feel the AI money squeeze." The billions in venture funding and compute costs don't pay for themselves.

Anthropic is rumored to be approaching its first profitable quarter. OpenAI, with its massive infrastructure spend, is likely further away. But both are now acting like real businesses, not research labs with infinite runway.

Practical Steps for Developers

If your team relies on AI coding agents, here's what you should do now:

1. Audit your actual usage

Neither Anthropic nor OpenAI makes this easy. Willison built ccusage himself because the platforms don't surface per-user token costs. Until first-party tools arrive, here's a quick audit approach:

# For Claude Code users: check the usage log
cat ~/.claude/usage.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
total_tokens = sum(session.get('tokens', 0) for session in data)
# Rough estimate: $15 per million input tokens, $75 per million output tokens
print(f'Total tokens: {total_tokens:,}')
print(f'Estimated cost: ${total_tokens / 1_000_000 * 45:.2f}')
"

2. Set budgets before you need them

Most teams discover they have a problem when the CFO forwards a $50,000 invoice. Set per-developer or per-team monthly budgets now. If your platform doesn't support hard limits, implement soft limits with monitoring:

# Simple cost tracker for team AI usage
import json
from datetime import datetime
from collections import defaultdict

class AICostTracker:
    def __init__(self, budget_per_dev=500):
        self.budget = budget_per_dev
        self.usage = defaultdict(float)

    def record_usage(self, developer, tokens, model):
        # Approximate pricing (varies by model/provider)
        rates = {
            'claude-sonnet-4': 15,     # per million tokens
            'claude-opus-4': 45,
            'gpt-4o': 10,
            'gpt-4.1': 30,
        }
        rate = rates.get(model, 15)
        cost = (tokens / 1_000_000) * rate
        self.usage[developer] += cost

        if self.usage[developer] > self.budget * 0.8:
            print(f"WARNING: {developer} at {self.usage[developer]:.0%} of budget")

    def report(self):
        for dev, cost in sorted(self.usage.items(), key=lambda x: -x[1]):
            print(f"{dev}: ${cost:.2f} / ${self.budget} budget")

3. Route intelligently

Not every task needs Claude Opus or GPT-4.1. Build a triage system:

Task complexity        Recommended model       Cost per million tokens
------------------     -------------------     -----------------------
Boilerplate, types     Local (Ollama/Llama)    $0
Simple refactors       Claude Haiku / GPT-4o   $1-3
Complex debugging      Claude Sonnet           $15
Architecture design    Claude Opus / GPT-4.1   $45-75

4. Cache aggressively

If five developers ask Claude Code essentially the same question about your codebase, you're paying for that answer five times. A shared context cache or team-level prompt library can cut repeat costs dramatically.

The Bottom Line

The AI industry has crossed a threshold. Two years ago, AI coding tools were a novelty. Six months ago, they were a productivity boost. Today, they're essential infrastructure that costs real money.

The good news: if you're paying $1,000 per month for AI tools that save you 40+ hours of work, your ROI is absurdly positive. A developer's time is worth far more than $25 per hour.

The bad news: nobody told you the meter was running. And if you're not tracking it, you'll find out from accounting.

Simon Willison ended his piece with a telling observation: "I think they've found product-market fit. And they're ramping up." Developer tools that people complain about but keep paying for? That's exactly what product-market fit looks like.

Now go check your token usage. It's probably higher than you think.

MySQL's 20-Year Bug #11472 Is Finally Fixed: Here's Why It Mattered

Tyson Cung — Wed, 27 May 2026 06:06:22 +0000

After 20 years, 1,600+ Reddit upvotes, birthday celebration threads, and at least one postponed marriage proposal, MySQL Bug #11472 has been fixed.

This isn't just another bug fix story. It's a case study in how one design decision, buried deep in a database engine, can silently corrupt data integrity for two decades. And it's a reminder that the quietest bugs are often the most dangerous.

Let's break down what the bug was, why it survived 20 years, and what the fix means for your applications.

The Bug: When CASCADE Goes Silent

Here's a scenario that looks completely innocent:

-- Parent table: users
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    status VARCHAR(20)
);

-- Child table: orders, with a CASCADE
CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT,
    amount DECIMAL(10,2),
    FOREIGN KEY (user_id) REFERENCES users(id)
        ON DELETE CASCADE
);

-- Audit trigger: log every deletion
CREATE TRIGGER audit_order_delete
    AFTER DELETE ON orders
    FOR EACH ROW
    INSERT INTO audit_log (table_name, row_id, action, timestamp)
    VALUES ('orders', OLD.id, 'DELETE', NOW());

Now run this:

-- Delete a user; CASCADE should delete their orders
DELETE FROM users WHERE id = 42;

What you expect: The user is deleted. Their orders are cascade-deleted. The audit_order_delete trigger fires for each deleted order.

What actually happened (for 20 years): The orders were deleted. The trigger never fired. No audit log entries. Silent data loss.

The Architecture: Why This Happened

MySQL processes foreign key cascades before trigger execution. The execution flow looked like this:

The FK cascade system bypassed the trigger infrastructure entirely. It used an internal row-deletion path that didn't go through the standard DELETE handler, so triggers, which hook into the standard handler, were never invoked.

This is the kind of architecture decision that makes sense in a vacuum (FK cascades are internal operations, right?) but creates a deep violation of the principle of least surprise in practice.

What This Broke in Production

The cascade-trigger gap wasn't theoretical. It silently corrupted three critical patterns:

1. Audit Trails

Every system that relied on triggers for audit logging had invisible holes. When a parent record was deleted, the cascade-deleted children left no audit trail:

Expected audit log:
  [2026-05-27 14:02:01] orders | #8823 | DELETE
  [2026-05-27 14:02:01] orders | #8824 | DELETE
  [2026-05-27 14:02:01] orders | #8825 | DELETE

Actual audit log (pre-fix):
  (empty; triggers never fired)

2. Business Logic in Triggers

Teams that encoded validation or side effects in child-table triggers had them silently skipped:

-- This trigger NEVER fired on cascade deletes
CREATE TRIGGER refund_order
    AFTER DELETE ON orders
    FOR EACH ROW
BEGIN
    IF OLD.status = 'paid' THEN
        INSERT INTO refunds (order_id, amount, reason)
        VALUES (OLD.id, OLD.amount, 'user_deleted');
    END IF;
END;

Users who deleted their accounts would cascade-delete orders, but refunds would never be issued because the trigger never ran.

3. Denormalization and Caching

Triggers used to maintain denormalized fields or cache tables silently fell out of sync:

-- Keeps a running total, silently falls out of sync
CREATE TRIGGER update_user_total
    AFTER DELETE ON orders
    FOR EACH ROW
    UPDATE users SET total_spent = total_spent - OLD.amount
    WHERE id = OLD.user_id;

After a cascade delete, users.total_spent would remain unchanged, even though the orders were gone.

Why It Took 20 Years to Fix

Not because MySQL engineers didn't care. Because fixing it correctly required touching the most sensitive part of the engine:

Each subsystem represented a risk. A careless fix could:

Break existing applications relying on triggers not firing
Cause deadlocks in high-concurrency workloads (FK cascades + triggers = complex locking)
Create infinite loops (trigger fires → FK cascade → trigger fires → ...)

The MySQL team's solution in 9.7 is elegant: a new system variable foreign_key_checks_trigger (default: OFF) that explicitly opt-ins to the new behavior. This means existing applications with workarounds won't break, but new applications can get correct behavior:

-- Enable trigger execution on FK cascades (MySQL 9.7+)
SET foreign_key_checks_trigger = ON;

-- Now triggers fire correctly
DELETE FROM users WHERE id = 42;
-- audit_order_delete trigger fires for each cascaded order ✓

The Human Side: Internet Folklore

Bug #11472 became more than a bug. It became a piece of developer culture. Here's the timeline:

The original reporter, who filed the bug in 2005, is still active and commented on the fix in 2026. Two decades of waiting.

The most upvoted Reddit comment on the fix thread?

"WTF? I was relying on this feature! Change it back please." 987 upvotes

Developer humor at its finest.

What This Means for Your Applications

If You're Running MySQL < 9.7

You still have the bug. Your triggers on child tables are silently skipped during FK cascade operations. Check your applications:

-- Find tables with BOTH triggers AND foreign key relationships
SELECT 
    t.TABLE_NAME,
    tr.TRIGGER_NAME,
    tr.EVENT_MANIPULATION,
    k.REFERENCED_TABLE_NAME,
    k.COLUMN_NAME
FROM information_schema.TRIGGERS tr
JOIN information_schema.TABLES t ON tr.EVENT_OBJECT_TABLE = t.TABLE_NAME
JOIN information_schema.KEY_COLUMN_USAGE k 
    ON t.TABLE_NAME = k.TABLE_NAME 
    AND k.REFERENCED_TABLE_NAME IS NOT NULL
WHERE t.TABLE_SCHEMA = 'your_database';

If You're Migrating to MySQL 9.7

The fix is opt-in. Your existing code won't break, but you should:

Audit your triggers: Identify which ones depend on FK cascade behavior
Test with foreign_key_checks_trigger = ON: Make sure your triggers handle cascade events correctly
Watch for performance: FK cascade + triggers can increase locking overhead in high-write workloads
Update your workarounds: If you wrote application-level code to compensate for the bug, you can now remove it

The Migration Path

-- Phase 1: Enable in a staging environment
SET GLOBAL foreign_key_checks_trigger = ON;

-- Phase 2: Monitor for issues
-- Check slow query log for new trigger-related queries
-- Watch for deadlocks in FK-heavy workloads

-- Phase 3: Enable in production (gradual rollout)
-- Start with read replicas, then primary

The Bigger Lesson

Bug #11472 teaches something important about software architecture: silent failures are worse than loud ones.

If MySQL had thrown an error when triggers couldn't fire on cascade operations, every DBA would have noticed immediately. The bug would have been fixed in 2005. But because it failed silently (rows were deleted, triggers were skipped, everything looked normal on the surface), it survived two decades.

This is the same pattern we see in:

Distributed systems that silently drop messages
API clients that retry without logging failures
Database ORMs that swallow constraint violations

Silence is not a feature. It's a time bomb.

Key Takeaways

Bug #11472 caused MySQL triggers to silently skip execution during FK CASCADE operations. Rows were deleted but triggers never fired.
The fix in MySQL 9.7 is opt-in via foreign_key_checks_trigger. Existing applications won't break, but you should audit your trigger dependencies.
The architecture problem was a bypass: FK cascades used an internal deletion path that didn't route through the standard trigger dispatcher.
20 years of survival shows how deeply buried design decisions can create persistent, invisible bugs.
Audit your audit trails. If you use triggers for logging, make sure they're actually firing for all delete paths, not just direct DELETEs.

The MySQL 9.7 release notes include the full details of this fix. If you're running production MySQL with triggers + foreign keys, this is the upgrade you've been waiting two decades for.

Follow for more deep dives on database internals, software architecture, and the bugs that shaped our industry.

How Video-Native AI Actually Works — The Architecture Behind Gemini Omni

Tyson Cung — Tue, 26 May 2026 06:05:23 +0000

How Video-Native AI Actually Works — The Architecture Behind Gemini Omni

Google just dropped Gemini Omni, and the AI world is losing its mind. Not because it's another chatbot — because it's the first model that truly understands video.

Not "watches 3 frames per second and tries to guess what's happening." Not "transcribes the audio and ignores the visuals." Native. Every frame. Every pixel. Every timestamp.

Let's break down how video-native AI actually works — and why the architecture is fundamentally different from every model you've used before.

The Problem: Current AI is Legally Blind to Video

When you upload a video to ChatGPT or Claude today, here's what actually happens:

┌──────────────┐     ┌───────────────┐     ┌──────────────┐
│  30-second   │────▶│ Extract 1 fps  │────▶│ 30 still     │
│   video      │     │ (30 frames)   │     │ images       │
└──────────────┘     └───────────────┘     └──────┬───────┘
                                                  │
                    ┌───────────────┐              │
                    │  "The person  │◀─────────────┘
                    │   is walking" │
                    └───────────────┘

The model never actually sees motion. It sees a slideshow of still images and uses language reasoning to infer what's happening between frames.

This is why current AI:

Misses fast actions. A tennis serve at 30fps becomes 1 frame. That serve is invisible.
Can't track objects across frames. Every frame is a fresh analysis — no memory of the previous one.
Fails at temporal reasoning. "Did the person pick up the cup before or after they sat down?" requires tracking state across time.

It's like trying to understand a movie by reading the script one random page at a time.

The Architecture Shift: From Frame Sampler to Video Streamer

Gemini Omni processes video as a continuous stream, not a collection of snapshots. Here's the architectural difference:

Old Way: Frame-By-Frame

Video → Frame Extractor → Image Encoder → LLM → Text Output
         (1-2 fps)         (ViT/CLIP)    (text tokens)

New Way: Native Video Streaming

Video → Space-Time Tokenizer → Video Transformer → Multimodal Output
        (all frames)           (3D attention)      (text + video + audio)

The key difference is the space-time tokenizer. Instead of treating a video as a sequence of independent images, it creates tokens that span both space AND time:

# Traditional approach: each frame is independent
for frame in video.extract_frames(fps=1):
    tokens = image_encoder(frame)  # [256 tokens] × 30 frames = 7,680 tokens
    # No relationship between frame tokens

# Video-native approach: tokens represent spatiotemporal patches
tokens = video_encoder(video)  # [16×16×4] patches across space-time
# Each token covers: 16px×16px spatial region × 4 consecutive frames
# Tokens inherently carry motion information

This is the same leap that CNNs made over MLPs for images — moving from "process each pixel independently" to "understand spatial relationships through convolutions." Except now it's in the time dimension.

The Three-Layer Architecture

Here's what the full pipeline looks like:

┌─────────────────────────────────────────────────────────────┐
│                    VIDEO-NATIVE AI ARCHITECTURE              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────┐    ┌──────────────┐    ┌──────────────────┐  │
│  │  INPUT   │    │ SPACE-TIME   │    │   MULTIMODAL     │  │
│  │  STREAM  │───▶│ TOKENIZER    │───▶│   TRANSFORMER    │  │
│  │          │    │              │    │                  │  │
│  │ Video    │    │ 16×16×4      │    │ 3D Self-Attention│  │
│  │ + Audio  │    │ Patches      │    │ over all tokens  │  │
│  │ + Text   │    │              │    │                  │  │
│  └──────────┘    └──────────────┘    └────────┬─────────┘  │
│                                               │            │
│                    ┌──────────────────────────┘            │
│                    ▼                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              MULTIMODAL DECODER                      │   │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐          │   │
│  │  │  TEXT    │  │  VIDEO   │  │  AUDIO   │          │   │
│  │  │  OUTPUT  │  │  OUTPUT  │  │  OUTPUT  │          │   │
│  │  └──────────┘  └──────────┘  └──────────┘          │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Layer 1: Space-Time Tokenizer

This is where the magic happens. Instead of the standard ViT patch embedding (16×16 pixels), video-native models use 3D patch embeddings:

# Conceptual code — how space-time tokenization works
class SpaceTimeTokenizer:
    """
    Divides video into 3D patches: (time, height, width)
    Each patch spans multiple frames, so it naturally
    captures local motion within the patch.
    """
    def __init__(self, patch_size=(4, 16, 16)):
        self.temporal_patch = patch_size[0]  # 4 frames
        self.spatial_patch = patch_size[1:]  # 16×16 pixels

    def tokenize(self, video: Tensor) -> Tensor:
        # video shape: (T, H, W, C) — e.g., (120, 720, 1280, 3)
        # Extract overlapping 3D cubes
        patches = video.unfold(0, self.temporal_patch, 2)  # stride=2
                     .unfold(1, self.spatial_patch[0], 16)
                     .unfold(2, self.spatial_patch[1], 16)

        # Each patch: (4 frames × 16×16 pixels × 3 channels) = 3072 values
        # Project to model dimension (e.g., 4096)
        return self.projection(patches)  # (N_patches, d_model)

The crucial insight: by making the tokenizer operate on space-time cubes instead of space-only patches, motion becomes a first-class citizen of the token representation. A patch containing a tennis racket moving left-to-right has a fundamentally different embedding than a static racket — even if the pixel values at the center frame are identical.

Layer 2: 3D Self-Attention

Once you have spatiotemporal tokens, the transformer needs to attend across both space AND time simultaneously. This is the expensive part:

# Standard 2D attention (image models)
# Each token attends to all other tokens in the same FRAME
attention_scores = Q @ K.T  # (N_spatial, N_spatial)

# 3D attention (video models)  
# Each token attends to ALL tokens across ALL frames
attention_scores = Q @ K.T  # (N_spatiotemporal, N_spatiotemporal)

For a 30-second video at 30fps with 16×16×4 patches:

Standard approach: 30 separate attention computations, each over ~3,600 tokens
3D attention: One massive attention computation over ~108,000 tokens

That's 30× more tokens in the attention matrix — and attention scales O(n²). This is why video-native models need clever optimizations:

Ring Attention distributes the attention computation across devices in a ring topology. Each device computes attention for its chunk and passes intermediate results to the next:

Device 1 (tokens 0-27K)  →  Device 2 (tokens 27K-54K)  →  Device 3 (54K-81K)  →  Device 4 (81K-108K)
        ↑                                                                                     │
        └───────────────────────── Ring topology ──────────────────────────────────────────────┘

Layer 3: Multimodal Decoder

The decoder can produce multiple output modalities — not just text:

Text: Standard autoregressive decoding (predict next token)
Video: Diffusion-based generation or autoregressive frame prediction
Audio: Waveform or spectrogram generation
Mixed: The model can interleave text with generated video clips

This is why Gemini Omni can edit video natively — it's not calling an external video processing library. The same model that understands "remove the background noise" can generate the cleaned audio.

What This Means for Developers

1. Video Understanding APIs Will Change

Instead of the current pattern:

# Today's approach: extract frames, describe each, stitch together
import cv2
from openai import OpenAI

client = OpenAI()
video = cv2.VideoCapture("meeting.mp4")
frames = []

while True:
    ret, frame = video.read()
    if not ret: break
    frames.append(frame)

# Describe every 30th frame
for i, frame in enumerate(frames[::30]):
    description = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": [
            {"type": "image_url", "image_url": {"url": encode(frame)}},
            {"type": "text", "text": "Describe what's happening"}
        ]}]
    )

You'll be able to do this:

# Tomorrow's approach: stream video directly
client = VideoAI()

# Upload and analyze in one call
analysis = client.video.analyze(
    video="meeting.mp4",
    query="Who spoke longest, and what was their key point?",
    temporal_resolution="full"  # Every frame, not sampled
)

# Or stream in real-time
for event in client.video.stream(webcam=True):
    if event.type == "action_detected":
        print(f"Action: {event.label} at {event.timestamp}s")
        print(f"Confidence: {event.confidence}")

2. New Use Cases Become Possible

Applications that were science fiction 6 months ago:

Use Case	Old Limitation	Video-Native Solution
Sports coaching	Misses fast movements	Full-motion analysis at native FPS
Security monitoring	Can't track objects across frames	Persistent object tracking with temporal reasoning
Medical imaging	Ultrasound/endoscopy treated as stills	Full procedure analysis with temporal context
Manufacturing QA	Frame sampling misses defects	Continuous monitoring catches transient anomalies
Video editing	Separate AI for understanding + external tools for editing	Single model understands AND edits

3. Compute Requirements Are Massive — But Dropping Fast

Running 3D attention over 100K+ tokens is expensive. Current estimates:

30-second video analysis: ~10-50× more compute than text-only
Real-time streaming: Requires distillation or specialized hardware
Edge deployment: Not feasible yet for full models

But the pattern is familiar. GPT-3 took a datacenter in 2020. Today it runs on a phone. Video-native AI will follow the same curve.

The Bigger Picture: AI That Lives in Time

The shift from frame-sampling to native video processing isn't just an engineering optimization. It's a philosophical shift in how AI experiences the world.

Current AI models live in a world of static snapshots. They're like someone reading a photo album — they can describe each picture, but they can't feel the rhythm of the dance, the tension of a conversation, or the flow of a basketball game.

Video-native models live in time. They understand before and after. They can track a coffee cup as it moves across a desk and reason about when it was picked up, not just that it was picked up. This is a fundamental leap toward AI that interacts with the real, dynamic, moving world — not just the static, curated web.

Key Takeaways

Video-native ≠ frame-sampling. Native models process continuous streams with spatiotemporal tokens that inherently capture motion.
The space-time tokenizer is the breakthrough. By encoding patches that span both space and time, motion becomes embedded in the token representation itself.
3D attention is the bottleneck. Ring attention and other distributed strategies make it feasible, but we're still early in the optimization curve.
Developer APIs will transform. The video → extract frames → describe → stitch pipeline will be replaced by single-call video analysis and real-time streaming.
This is just the beginning. As compute costs drop (and they will), video-native AI will become the default — just like image-native CNNs replaced hand-crafted feature extractors a decade ago.

This article analyzes publicly available architectural patterns in video-native AI models. Code examples are conceptual illustrations of the underlying principles, not production implementations.

Follow for more deep dives on AI architecture and practical engineering insights.

How APIs Actually Work — The Simplest Explanation You'll Find

Tyson Cung — Sat, 11 Apr 2026 23:49:36 +0000

APIs are everywhere. Every app you use talks to other services through APIs. And yet most explanations make it more complicated than it needs to be.

Let me give you the clearest version I know.

The One Analogy That Works

An API is a waiter.

You're at a restaurant. You don't go into the kitchen. You don't cook the food yourself. You tell the waiter what you want, the waiter goes to the kitchen, the kitchen prepares it, and the waiter brings it back to you.

You never interact with the kitchen directly. The waiter is the interface.

In software:

You're the app (or the developer making the request)
The waiter is the API
The kitchen is the server/database with the data
The food is the response

That's it. That's what an API is.

What Actually Happens When You Use One

Say you're using a weather app. You type in your city and see the current temperature.

Behind the scenes:

The app sends a request to a weather API: "Give me the current temperature for Melbourne"
The API server receives that request
The server looks up the data (from weather sensors, satellites, whatever)
The server sends back a response: {"city": "Melbourne", "temperature": 22, "unit": "celsius"}
Your app reads that response and shows you "22°C"

The whole thing happens in milliseconds. You see a number. The app made an API call.

REST — The Standard

Most APIs you'll encounter are REST APIs (REpresentational State Transfer). REST isn't a technology — it's a set of conventions about how requests and responses should work.

The key ideas:

Resources — Everything is a resource with a URL. A user is /users/123. A list of products is /products. A specific order is /orders/456.

HTTP Methods — Different operations use different methods:

GET — Read data
POST — Create something new
PUT/PATCH — Update something
DELETE — Remove something

Status Codes — Responses include a number telling you what happened:

200 — Success
201 — Created
400 — Your request is wrong
401 — Not authenticated
404 — Not found
500 — Server error

JSON — Data travels in JSON format (key-value pairs, like a dictionary). Easy for both humans and machines to read.

A Real Example

Say you're building an app that shows GitHub repos. You'd call:

GET https://api.github.com/users/tysoncung/repos

GitHub's API receives that request, finds the repos for that user, and sends back a JSON array with all the details. Your app loops through that array and displays them.

You didn't need access to GitHub's database. You didn't need to know how their servers work. You just followed their API documentation and made a request.

Why APIs Matter

For developers: APIs let you build on top of existing services instead of reinventing everything. Need payments? Stripe API. Need maps? Google Maps API. Need user authentication? Auth0 API. Your app becomes a composition of specialized services.

For companies: APIs are how products become platforms. Twitter opened their API and an entire ecosystem of clients and tools emerged. Stripe's API is why developers love them — it's clean, well-documented, and predictable.

For you as a learner: Once you understand APIs, a massive part of modern software development clicks. Every mobile app, most web apps, and increasingly even desktop apps are built around API calls.

What You Should Learn Next

If you want to go deeper:

Authentication — How do APIs know you're allowed to make requests? (API keys, OAuth, JWT)
Rate limiting — Why APIs restrict how many calls you can make
Webhooks — The reverse of an API call: the server pushes data to you instead of you pulling it
API documentation — How to read and use API docs (Swagger/OpenAPI)

But for 80% of what you'll do as a developer, the waiter analogy is all you need to hold in your head. Request, response, JSON, HTTP methods. The rest is details.

What was the first API you integrated? What made it click for you?

Claude Code vs Codex CLI — Two Terminal Coding Agents, One Honest Comparison

Tyson Cung — Sat, 11 Apr 2026 23:48:30 +0000

The terminal got interesting. AI coding started in IDEs with Copilot autocomplete, moved to chat interfaces, and now we've got full agents that run inside your terminal and can edit code, run tests, and loop until they get it right.

Claude Code (from Anthropic) and Codex CLI (from OpenAI) are the two most talked-about examples of this. I've used both. Here's what actually matters.

What They Are

Claude Code is Anthropic's CLI that brings Claude Sonnet/Opus directly into your terminal. You run claude from inside a git repo, give it a task, and it reads files, writes code, runs commands, and iterates. It operates with explicit permission prompts before making changes, which is either reassuring or slow depending on your mood.

Codex CLI is OpenAI's terminal agent, using GPT-4 (and now GPT-4.1 class models). Similar concept: runs in your repo, takes tasks, makes changes. OpenAI's approach gives it a bit more autonomy by default — it'll chain commands without as many interruptions.

The Core Experience

Both are surprisingly capable at well-scoped tasks. "Add error handling to this function," "write tests for this module," "refactor this to use the strategy pattern" — these work well in both. You describe what you want in natural language, the agent reads your code, and it produces a reasonable implementation.

The difference shows up at the edges.

Claude Code is better at understanding context in large codebases. Anthropic has invested heavily in Claude's ability to hold large amounts of code in context and reason about the relationships between files. When I give it a task that touches five different modules, it tends to understand the architecture and make changes that are consistent with existing patterns.

Codex CLI is faster for single-file tasks. It's snappier, iterates quickly, and feels more aggressive (in a good way) about just getting things done. For focused tasks — fix this function, implement this endpoint — it's often the quicker path.

Agentic Behavior

Codex CLI is more autonomous. It'll chain tool calls, run tests, see failures, and try fixes without stopping to ask you. Sometimes this is great. Sometimes it goes down a rabbit hole. You can set safety levels (--approval-mode flags) to control how much it acts without permission.

Claude Code is more collaborative. It shows you what it's planning to do and waits for confirmation before executing. This feels slower but means you're always aware of what's happening. For production code, I actually prefer this — I want to review changes before they hit the filesystem.

Model Quality

This is the hard part to compare because it changes with every model update. Both agents are essentially wrappers around powerful LLMs, and the model quality matters more than the agent shell.

Right now: Claude's reasoning on complex architectural questions tends to be better. GPT-4 class models have slightly better code style consistency in my experience, particularly for Python and TypeScript.

Both will make mistakes. Neither replaces code review. The agent loop (write → run → fail → fix) helps catch some errors automatically, but you still need to read what it produces.

Pricing

Both are pay-per-use via API tokens. For intensive coding sessions, costs add up quickly — I've spent $5-10 in a session doing heavy refactoring. Neither is "free" at serious usage volumes.

Claude Code has a subscription tier through Anthropic's API. Codex CLI uses OpenAI API credits.

The Honest Take

If you're doing large codebase work, complex architectural changes, or tasks that require understanding how many parts of a system interact: Claude Code.

If you want a fast, aggressive agent for focused tasks and you're comfortable with more autonomous behavior: Codex CLI.

Both are worth trying. Neither is the magic wand that writes your code for you. They're tools that handle the tedious parts better than they used to, and they're getting better fast.

Are you using AI terminal agents yet? What's been your experience?

Your Dashboard Numbers Are Wrong — And Your Team Is Making Decisions Based on Them

Tyson Cung — Sat, 11 Apr 2026 23:47:58 +0000

I've sat in too many meetings where someone points at a number on a dashboard and says "look, it's working" or "look, it's broken" — and the number is measuring the wrong thing, or measuring the right thing wrong, or both.

This isn't a data engineering problem. It's a measurement problem. And it's more common than anyone wants to admit.

Why Dashboard Numbers Lie

Problem 1: The metric was defined in a meeting, not in code

Someone says "we need to track active users." Everyone nods. Nobody asks what "active" means. Is it users who logged in today? Users who performed any action? Users who performed a meaningful action (not a bot ping)? Users who paid?

The engineer implements something. The product manager had something different in mind. The exec reading the dashboard has a third interpretation. The number exists, it changes over time, and everyone is confidently wrong about what it means.

Fix: Define metrics in writing before building. "Active user: a user account that submitted at least one form in the last 30 days, excluding accounts marked as test or internal." That's a spec, not a vibe.

Problem 2: The data pipeline has bugs

Metrics pipelines are production code. They fail, they drift, they have edge cases. But unlike application bugs that show up as broken features, data bugs show up as slightly wrong numbers. Slightly wrong numbers are the most dangerous kind because they feel believable.

A query that's double-counting events because someone joins the wrong way. A timezone issue that moves events between days. A column that changed meaning when the schema evolved but the query didn't update.

Nobody knows these exist. The dashboard looks fine. Decisions get made.

Fix: Treat your data pipeline like you treat application code. Tests, code review, alerts when outputs go outside expected ranges. "This metric dropped 40% overnight" should be an automated alert, not something someone notices in a quarterly review.

Problem 3: The metric is easy to measure, not important to measure

Page views. Email opens. Time on site. These are easy to measure and frequently wrong proxies for what you actually care about.

Page views go up if your site is slow and people reload. Email opens are inflated by Apple's Mail Privacy Protection. Time on site goes up if your UX is confusing.

You optimize for what you measure. If you measure the wrong thing, you optimize in the wrong direction.

Fix: Work backward from business outcomes. What does success actually look like? Revenue, retention, task completion rate, NPS. Then find metrics that lead to those outcomes. Resist the urge to track what's easy.

Problem 4: Survivorship bias in the sample

Your dashboard probably shows data about the users you have. It probably doesn't show you much about the users you lost.

Churn dashboards that only track reasons given by departing customers miss the 60% who leave without clicking the feedback button. Conversion funnels show where people drop off but not why. Satisfaction scores track satisfied users more than dissatisfied ones who've already moved on.

Fix: Design for the data you don't have. Exit surveys. Cohort analysis that follows users from signup through churn. Win/loss interviews. The data you're missing is often more important than the data you have.

The Uncomfortable Conclusion

Most dashboards tell you what happened. The useful question is why it happened and whether it matters.

A metric without context is just a number. "DAUs up 12%" is not useful without knowing whether that's a trend or a spike, whether it's driven by the user segment you care about, and whether it maps to outcomes that actually matter for the business.

The best data teams I've seen spend more time on measurement strategy — defining what to track and why — than they do on building pipelines. The pipeline is the easy part. Getting the right number is hard.

What's the most misleading metric you've ever seen a team optimize for? I want to hear the stories.

AWS vs Azure vs GCP — Which Cloud Should You Learn in 2026?

Tyson Cung — Sat, 11 Apr 2026 23:47:27 +0000

This is the cloud question that comes up in every bootcamp, every career change conversation, and every "where should I focus" thread on Reddit. The answer isn't as complicated as the cloud vendors want you to think.

The Market Reality

AWS holds roughly 30% of the cloud market. Azure is around 22%. GCP sits at about 12%. The rest is distributed across other providers.

This matters because it tells you where the jobs are. AWS has the most adoption across the broadest range of companies — startups, enterprises, government, everything. Azure dominates in enterprises that are already deep in the Microsoft ecosystem (Office 365, Active Directory, .NET). GCP is strong in companies doing heavy data/ML work and startups that want to run Kubernetes on managed infrastructure.

If you're optimizing for job market breadth, AWS first.

AWS — The Default Choice

AWS has the widest service catalog (200+ services), the deepest documentation, and the largest community. There are more Stack Overflow answers, more YouTube tutorials, more blog posts, and more job postings for AWS than the other two combined.

The certification path is mature — Solutions Architect Associate is recognized across the industry and genuinely tests useful knowledge. The downside is complexity: AWS grew organically and the UI is notoriously confusing. Some services exist for historical reasons that no longer make sense. The pricing is opaque.

Learn AWS if: You want the widest job options, you're going into a startup or general tech company, or you're targeting cloud engineering as a career.

Azure — The Enterprise Path

If you're already working at a company in Microsoft's orbit (Windows, Office, SQL Server, Active Directory), you're probably already touching Azure or about to. Azure's integration with Microsoft's identity systems and developer tooling is genuinely better than the alternatives for Windows-heavy shops.

Azure DevOps is a legitimate competitor to GitHub Actions for enterprise CI/CD. Azure Active Directory (now Entra ID) is how most large enterprises handle identity. If you want to work in enterprise IT and cloud, Azure knowledge is often more valuable than AWS knowledge.

Learn Azure if: You're targeting enterprise clients, your company is Microsoft-heavy, or you're coming from a traditional IT background.

GCP — The Data/ML Play

Google's cloud has historically punched below its weight in enterprise adoption but has genuine technical advantages in certain areas. BigQuery for data warehousing is legitimately best-in-class. Vertex AI for ML workloads is excellent. GKE (Google Kubernetes Engine) is arguably the easiest managed Kubernetes to operate.

If you're going into data engineering, ML engineering, or you want to understand Kubernetes deeply, GCP is worth learning. The job market is smaller but the roles tend to be more specialized and often pay well.

Learn GCP if: You're going into data engineering, ML, or you want to work at companies that run large-scale data infrastructure.

The Real Answer

Learn one deeply, understand the others at a conceptual level.

The fundamentals transfer: VMs, storage, networking, databases, serverless functions, IAM — every cloud does these things. Once you understand how AWS does it, Azure and GCP are variations on the same theme. The vendor-specific details matter for day-to-day work but the concepts are portable.

Most companies that ask for "cloud experience" in a job posting are happy with any cloud background. They'll train you on their specific vendor. What they actually want to know is whether you understand how cloud infrastructure works.

So: pick the one most relevant to the jobs you want, get certified (it signals commitment and tests real knowledge), and don't overthink the choice. In 12 months you'll have enough experience that the original pick matters less than you think.

Which cloud are you using? Did you deliberately choose it or just end up there? Tell me below.

Windsurf vs Cursor — Two AI IDEs Walk Into a Bar

Tyson Cung — Sat, 11 Apr 2026 23:46:57 +0000

The AI-native IDE wars are heating up. For a while, Cursor was the obvious choice if you wanted an editor built around AI coding. Then Codeium shipped Windsurf and claimed the throne for a minute. Now we've got two serious contenders and developers trying to figure out which one to actually use.

I've been switching between both. Here's my take.

What Are We Actually Comparing?

Cursor is a VS Code fork with AI deeply integrated — not as an extension, but as first-class functionality. Tab completions, Cmd+K inline edits, the Composer (now called Agent) for multi-file edits. It uses a mix of frontier models and caches aggressively to keep latency low.

Windsurf is Codeium's full IDE, also VS Code-based, with their "Cascade" agent as the centerpiece. Cascade can take on multi-step tasks autonomously, browse the web, run terminal commands, and edit across multiple files. It's marketed as the more "agentic" of the two.

Day-to-Day Editing

Cursor wins here for most developers. The Tab completion is genuinely magical — it predicts multi-line edits with high accuracy, and the Cmd+K inline edit mode is fast and reliable. The UX has been refined over years of iteration.

Windsurf's editing experience is good but plays second fiddle to Cascade. If you're not using Cascade, you're leaving most of Windsurf's value on the table. The basic completions are solid (it's Codeium under the hood) but don't feel as polished as Cursor's Tab.

The Agentic Story

This is where Windsurf pulls ahead — or at least, where it's making its bet. Cascade is more autonomous than Cursor's Agent. It'll plan a task, execute steps, check its work, and loop back when something fails. For big refactors or implementing features from scratch, Cascade can handle more without needing you to guide it.

Cursor's Agent has caught up significantly in recent updates. It's also now capable of multi-file edits, running tests, and iterating. But in my experience, Cascade still takes on messier tasks with less hand-holding required.

That said, agentic AI is still unreliable enough that I don't trust either to run unsupervised on important code. Both are tools that require oversight.

Performance and Stability

Cursor is more stable. It's older, more battle-tested, and the VS Code base it's built on is rock solid.

Windsurf has had more rough edges in my testing — occasional slowdowns, Cascade sometimes losing track of what it was doing, and the occasional crash. It's improving quickly, but if stability matters to you (and it should), Cursor is the safer choice right now.

Pricing

Cursor: $20/month Pro, includes fast requests to frontier models and unlimited slower requests.

Windsurf: $15/month Pro. Codeium's free tier works in Windsurf for basic completions. Cascade is usage-limited on free.

Who Should Use Which

Cursor is the better default choice. It's more polished, more stable, and the Tab completion is class-leading. If you're a developer who wants AI that enhances how you already work, Cursor nails it.

Windsurf is worth trying if you're excited about agentic workflows and willing to tolerate some rough edges for the payoff of a more autonomous AI. If Cascade's roadmap keeps improving, this could flip.

Both are far better than using Copilot in a regular VS Code window. The fully integrated experience — completions, chat, and agents in one tool — changes how you code in a way that extensions just don't.

The honest answer: try both. They both have free tiers. Your preference will probably come down to whether Tab completion or Cascade resonates more with how you think about writing code.

Cursor or Windsurf person? Or are you still on vanilla VS Code? Let me know.

GitHub Copilot vs Codeium — I Used Both for a Month. Here's What I Actually Think.

Tyson Cung — Sat, 11 Apr 2026 23:46:28 +0000

The AI coding assistant market split somewhere between "pay for quality" and "free is good enough." GitHub Copilot sits squarely in the first camp. Codeium decided to be the second.

I've spent the last few months switching between them on real projects — not demos, not tutorials, just actual work. Here's what I found.

What Each Is Trying to Do

GitHub Copilot is built on OpenAI's Codex (and increasingly GPT-4 class models) with GitHub's training data advantage. It's deeply integrated into VS Code, JetBrains, and a growing list of editors. At $10/month individually or $19 for Business, it's not cheap for a single developer but is reasonable for a team.

Codeium is free for individuals and positions itself as the "Copilot but without the paywall." It covers 70+ languages, supports VS Code, JetBrains, Neovim, and a bunch of others. Enterprise tier exists for teams.

Completion Quality

Copilot has better context over larger files. When I'm in a module with 300+ lines, Copilot tends to understand the patterns I've established and suggests completions consistent with my code style. Codeium's suggestions are good but occasionally feel disconnected — like it's completing based on the local context without understanding the broader patterns.

For boilerplate (CRUD operations, tests, simple transformations), Codeium is nearly as good. The gap shows most on complex logic or when you're building on top of patterns you've established in the same file.

Speed

Codeium is faster. Noticeably so. I think this is partly infrastructure (they've clearly invested in latency) and partly model architecture choices. When I'm in a flow state and just want completions quickly, Codeium's responsiveness beats Copilot.

Copilot's latency is acceptable — maybe 300-500ms for suggestions — but Codeium regularly comes in under 200ms in my experience. That's a real difference when you're completing several lines per minute.

Chat / Explain Features

Copilot Chat (requires the separate chat extension or VS Code's built-in integration) is genuinely useful for explaining code, generating tests, and refactoring suggestions. The conversation quality is good.

Codeium also has a chat feature and it's solid, but Copilot Chat has the edge on nuanced requests. When I ask "what's wrong with this function" and there are three issues, Copilot is more likely to catch all three.

Privacy Tradeoffs

This is where many teams make their decision. Copilot Business offers code snippet exclusion (your code doesn't get used to train the model), dedicated enterprise options, and clearer compliance documentation.

Codeium's free tier privacy policy is... less detailed. For hobby projects and personal learning, this doesn't matter. For work on proprietary codebases, read the fine print before installing it.

The Actual Verdict

If you're a student, learning to code, working on open source, or just can't justify $10/month — Codeium is excellent for free. Don't let "free" make you assume it's bad. It genuinely accelerates your workflow.

If you're working on commercial software, especially in a team environment, Copilot's quality edge and clearer enterprise policies make the $10-19/month worth it. The suggestions are better on complex code, and the peace of mind on data handling is real.

The competition between them is good for developers either way. A year ago there was no credible free alternative to Copilot. Now there is. That's kept Copilot honest and improved both products.

Which AI coding tool are you using? Have you switched recently? Tell me in the comments.

Why Most APIs Fail — 3 Mistakes That Kill Developer Experience

Tyson Cung — Sat, 11 Apr 2026 23:45:56 +0000

I've integrated hundreds of APIs over the years. Some were a pleasure. Most were a chore. A handful were genuinely painful experiences that made me question the life choices that led me to this career.

The frustrating part: the same three mistakes show up over and over. They're not exotic bugs. They're design decisions that seemed fine at the time and became load-bearing walls of confusion later.

Mistake 1: Inconsistent Naming

This sounds trivial. It isn't.

I once integrated with an API where the user ID was called userId in the auth endpoints, user_id in the profile endpoints, and uid in the events endpoints. Same field. Three names. Zero documentation explaining why.

Inconsistent naming forces developers to check the docs for every single call. It breaks the intuition that good APIs build — the feeling that you can guess what a field is called because everything follows the same pattern.

The fix is boring: pick a convention (camelCase, snake_case, kebab-case — doesn't matter which) and use it everywhere. Make a linter rule if you have to. Never let "we just called it something different here" ship to production.

Bonus failure mode: Naming things what they are today, not what they'll need to be. isAdmin becomes a lie the moment you add a second role type. premiumUser breaks when you launch three tiers. Use abstract names that survive your roadmap.

Mistake 2: No Versioning

Every API will change. If you're not versioning, you're setting up for one of two bad outcomes:

You never change anything because you're afraid of breaking integrations (stagnation)
You change things and break integrations (chaos)

Versioning buys you the ability to evolve without punishing your existing users. /v1/users stays stable. /v2/users adds the new fields. Clients migrate on their schedule, not yours.

The most common excuse for not versioning: "We'll add it when we need it." By the time you need it, you have production clients that assume the unversioned endpoint is permanent. Adding a version prefix to existing routes is a breaking change. You've trapped yourself.

Start with versioning. Even if v1 never changes, having the habit in place means v2 doesn't cause a crisis.

URL vs Header versioning: Both work. URL (/v1/endpoint) is more visible and easier to debug. Header versioning (Accept: application/vnd.api+json;version=2) is cleaner architecturally but harder to test in a browser. Pick one and document it clearly.

Mistake 3: Poor Error Responses

This is the one that makes me lose my mind most often.

{"error": "Something went wrong"}

That's not an error response. That's an apology. It tells me nothing I can act on.

A good error response tells me:

What went wrong (specific, not generic)
Why it went wrong (validation failure? rate limit? bad auth?)
What I can do about it (retry? fix the request? check my credentials?)

The gold standard:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The 'email' field must be a valid email address",
    "field": "email",
    "docs": "https://api.example.com/docs/errors#VALIDATION_ERROR"
  }
}

I can read that, understand it, and fix my request without a support ticket.

Also: use the right HTTP status codes. 200 OK with an error body is a crime against HTTP. 401 vs 403 is not interchangeable. 404 vs 410 (gone vs not found) matters for caching behavior. These distinctions exist for a reason — use them.

The Real Cost of Getting This Wrong

Bad API design doesn't just frustrate developers. It costs you:

Support time — most support tickets are "what does this error mean" or "where is this field"
Integration time — slow, painful integrations mean fewer third-party developers bother
Churn — if your API is harder than a competitor's, the technical buyer notices

The best APIs are the ones where developers get to the first successful call in under 10 minutes. That's the goal. Consistent naming, versioning from day one, and real error responses get you most of the way there.

The boring stuff is usually the most important.

Which API gave you the worst integration experience? I want to hear the horror stories.

Tech Debt Compounds Like Interest — And Most Teams Are Already Bankrupt

Tyson Cung — Sat, 11 Apr 2026 23:45:22 +0000

Tech debt is the one thing every dev knows is a problem and almost nobody actually deals with it until it's too late.

I've watched teams go from "we'll clean this up later" to "we can't ship anything without breaking three other things" in under a year. The compounding isn't a metaphor — it's mechanical.

What Actually Happens

Every shortcut you take today creates friction for every engineer who touches that code afterward. That friction slows decisions, causes bugs, and makes refactoring scarier than it needs to be.

Here's the thing about compound interest: small rates don't feel dangerous until you do the math. 10% compounding annually turns $1,000 into $6,727 in 20 years. Tech debt works the same way — a "quick hack" that saves 3 hours this sprint could cost 30 hours across the next six months as it calculates wrong, misleads other devs, and generates bug reports.

The Three Phases Teams Go Through

Phase 1 — Ignorance is bliss. The codebase is young, features ship fast, nobody talks about tech debt because there isn't much of it. This is the honeymoon.

Phase 2 — Accumulation. Deadlines get tight, shortcuts get taken. "We'll refactor this after launch" becomes a running joke. Each sprint adds more interest to the principal.

Phase 3 — The wall. New features take three times as long. Bugs reproduce only in production. Onboarding new engineers becomes a multi-week affair because nobody can explain how anything actually works. This is the phase teams call "rewrite" — and that's almost always the wrong answer.

Where It Actually Comes From

Not just "bad developers" cutting corners. More often:

Deadline-driven decisions — someone above the team decided the date, and engineering bore the cost
Evolving requirements — code written for spec A doesn't gracefully handle spec B three iterations later
Context loss — the original author left, the code lives on, nobody knows why it works the way it does
Tooling drift — the ecosystem moved on but the codebase didn't

The last one is underrated. Code written with React 16 patterns in a React 18 codebase isn't "wrong" exactly, but it's drag.

How to Actually Manage It

You can't eliminate tech debt. Trying to is its own form of inefficiency. What you can do:

Track it explicitly. Create tickets for known debt. Not a shame list — a backlog item with an actual cost estimate. "This authentication module has three known race conditions, estimated 2 days to fix properly." When it gets expensive enough, it gets prioritized.

Budget for it. Some teams do 20% of sprint capacity on debt reduction. Others do one full "hardening sprint" per quarter. Either works. Nothing earmarked means nothing happens.

Pay debt at the point of touch. Before adding a feature to a module, spend 30 minutes cleaning it up first. Boy Scout Rule: leave the codebase better than you found it. Marginal cost is low when you're already there.

Don't let it block you. Some debt is fine to live with. A poorly-named variable in a stable module nobody touches isn't worth a dedicated sprint. Save the effort for the high-traffic, high-churn areas.

The Real Cost

Here's what nobody says in the business meetings: tech debt is a transfer of cost from now to future-you. Your team isn't saving time by taking shortcuts. They're borrowing it. And the interest rate isn't fixed — it tends to go up as the codebase grows and the shortcut touches more things.

The teams that consistently ship fast, year over year, are usually the ones treating their codebase like infrastructure worth maintaining. Not perfect — just maintained.

If you're in Phase 2 right now, the best time to start was six months ago. The second best time is this sprint.

What's the most expensive piece of tech debt you've ever had to deal with? Drop it in the comments.