Forem: Jason Guo

Building a Cinematic 3D F-16 Takeoff Simulation Entirely in the Browser When we think of 3D flight simulations, we usually picture heavy game engines like Unreal or Unity. https://best-games.io/blog/building-a-cinematic-3d-f-16-takeoff-simulation-entirely

Jason Guo — Sat, 04 Apr 2026 08:57:44 +0000

Best-Games.io - Play 200+ Free Online Games Instantly | No Download

Play 200+ free online games instantly! Snake, Mahjong, 8 Ball Pool, racing, puzzle & action games. No download - play in browser.

best-games.io

I Built a Game Site with an iframe — Someone Hit a 210-Second World Record on It

Jason Guo — Tue, 31 Mar 2026 16:25:40 +0000

I'm not a game developer. I'm a Web developer addicted to side projects, and one afternoon I had a thought: instead of spending months building a game from scratch, what if I did something faster to validate the idea first — curate great games and build a genuinely useful game portal around them?

That's how taproad-game.com was born. The technical core is an iframe, but there's a lot built around it. This post is about the rabbit holes I fell into, the lessons I picked up, and why an "iframe site" can actually retain real users.

Why Tap Road?

Before deciding which game to build around, I did a round of keyword research. Tap Road is an HTML5 endless runner developed by AzGames.io — a glowing ball rolls down a neon-lit highway, and players tap or click to switch lanes, dodge obstacles, and collect gems.

The numbers caught my eye immediately: 7 million+ plays, a 4.2/5 rating, and nearly 11,000 reviews. This wasn't some obscure indie experiment — it was a market-validated product with a real player base.

More importantly, the gameplay is dead simple — one tap, zero learning curve. That means anyone who lands on the site can pick it up within 5 seconds, with no onboarding copy needed from me. For a traffic-funnel game site, that's the ideal anchor game.

Why the Game Actually Retains Players

Before building the site, I spent a serious amount of time studying what makes Tap Road work, because I needed to genuinely understand why it's fun before I could write content that would keep visitors around.

The answer lies in its gem economy. There are three gem tiers: common blue gems, purple gems worth 3x, and golden gems worth 10x. The golden gems are always placed in the most dangerous spots — you can go for them, but you'll probably die trying. This design turns every run into a series of micro-decisions: take the risk or play it safe? That tension creates the "just one more game" compulsion, rather than a pure reflex challenge.

Gems are spent in the shop on 30+ ball skins, trail effects, and track themes. The game also has a hidden skin system — the Ghost Ball requires dying 100 times total, the Rainbow Ball requires playing 50 games in a single day, and the Supernova Ball requires collecting 10,000 lifetime gems. These mechanics convert short-term "one more run" impulses into long-term return visit motivation.

The speed system is worth noting too. The game ramps up at three thresholds: 30 seconds, 60 seconds, and 90 seconds. The 10-second window after each speed bump is the most dangerous — top players' strategy is to completely stop chasing gems during that window, focus purely on survival, and only reintroduce gem collection once their hands and eyes have adjusted to the new tempo.

The community-verified world record currently stands at 210 seconds, held by a player known as "NeonRunner" with a full gameplay recording as proof. That number sounds modest until you experience the blistering speed the game reaches past 90 seconds — every tap has to be frame-perfect.

You can try it yourself at taproad-game.com — no download, no signup, runs instantly in any browser.

The Real Challenge of an iframe Site Isn't Technical

Embedding the game took me under an hour. What actually took time was building a valuable content layer around the iframe.

A page that's just an iframe offers no additional value to users and is essentially invisible to search engines. The core question I needed to answer was: why would a player come to my site instead of going directly to the original?

My answer was: become the best information hub for the game.

That meant genuinely researching the game and writing substantive guides — not "click to switch lanes" filler, but verified tips like "stop chasing gems for the first 10 seconds after the 90-second speed increase." It meant cataloguing the hidden skin unlock conditions, gathering world record discussions from the community, and explaining the underlying logic of the gem economy.

Once the content was in place, the site's bounce rate dropped noticeably. Users were spending more time on the page because they were reading guides and checking unlock conditions before and after playing — the content and the game were feeding each other.

The "Unblocked" Audience: An Underrated Niche

The most surprising traffic source after launch was users searching "tap road unblocked." School and workplace networks block a huge number of gaming sites, and students and office workers are exactly the core demographic for quick browser games during downtime.

I specifically optimized the site's technical setup for this — clean HTTPS, a domain with no history of being flagged by content filters — and wrote a dedicated access guide page. This segment now accounts for a meaningful share of traffic, and the user quality is high because they arrive with clear intent.

What I Actually Learned

Going in, I assumed an iframe site was a "low-effort" project I could set up and walk away from. The reality is that a low technical barrier means the competitive moat is entirely in content and execution. Anyone can replicate my technical setup in an hour. Nobody can replicate the guide content and community data I've compiled in an hour.

The other lesson was about product selection logic. Building a site around a game with 7 million verified plays is a fundamentally different risk profile than building around a game that just launched. The former is distribution on top of validated demand. The latter is a bet that demand exists at all. For an indie developer, the former has a dramatically higher success rate.

Finally, the "zero friction" nature of browser games is a real distribution advantage. Under 2 seconds from link-click to gameplay — no platform that requires a download or account creation can match that. If you're considering any game-adjacent project, HTML5 browser games are a seriously underrated space.

If you have thoughts on SEO strategy, content architecture, or monetization for game aggregator sites, I'd love to hear them in the comments. I'm also curious: what's the most "technically simple but operationally complex" side project you've ever shipped?

Shipping a game in 2026? Easier than ever. Getting noticed? Brutally hard. The teams breaking through don't just build better — they think like publishers. Full breakdown https://best-games.io/articles/2026-03-30-indie-game-development-brief-march-2026

Jason Guo — Mon, 30 Mar 2026 07:44:16 +0000

Best-Games.io - Play 200+ Free Online Games Instantly | No Download

Play 200+ free online games instantly! Snake, Mahjong, 8 Ball Pool, racing, puzzle & action games. No download - play in browser.

best-games.io

The game industry in March 2026: record Quest usage, Xbox showcases, 3M Crimson Desert sales — and mass layoffs. Demand didn't disappear. It just stopped protecting jobs. New piece on why player spending and employment stability have officially decoupled.

Jason Guo — Fri, 27 Mar 2026 10:13:22 +0000

I Built a Pixel Art Roguelite in Vanilla JS — Here Are 6 Things That Broke (And What I Learned)

Jason Guo — Mon, 23 Mar 2026 15:00:39 +0000

Full article:
Pixel dungeon dev log

I spent the last few weeks building a roguelite dungeon crawler using nothing but vanilla JavaScript and HTML5 Canvas. No React. No Phaser. No build tools. Just 6 JS files, a 16×16 pixel art tileset, and a growing list of bugs I didn't see coming.

The game has procedural dungeon generation, 5+ enemy types with AI state machines, a full camp system with crafting stations, procedural Web Audio music, and an equipment/inventory system. It runs from a single HTML file.

Here's what actually went wrong — and the fixes that made the biggest difference.

1. The Enemy That Disappeared When You Got Close

The most absurd bug I encountered: enemies became invisible when the player walked toward them.

The cause? State transitions. When an enemy switches from patrol to chase (triggered by proximity), there's a window of 2-3 frames where the state variable updates but the sprite reference hasn't resolved yet. Canvas drawImage() with an undefined source doesn't throw an error — it just silently draws nothing.

Takeaway: Canvas fails silently. Unlike DOM rendering, you get zero feedback when drawImage receives bad input. Defensive fallback chains are mandatory.

2. Players Couldn't Figure Out the Camp

After clearing floor 1, players enter a camp with 9 interactive stations — bonfire, workbench, anvil, furnace, alchemy table, etc. I thought it was self-explanatory.

The first person who played it immediately asked: "What is this? What am I supposed to do?"

The problem: in 16×16 pixel art, a bonfire is ~12 pixels of flickering orange. An anvil is a gray blob next to a different gray blob. Without explicit labels, it's all noise.

The fix was information layering at three distances:

Screen-level: Welcome banner with instructions
Room-level: Persistent icon + name labels on every station
Close-up: Pulsing highlight + "[E] to interact" + description

Takeaway: If you built it, you already know what everything does. That knowledge makes you blind to your own UX problems.

3. The Canvas Resolution Trap
Every Canvas tutorial starts with:

For pixel art, this is a disaster.

Pixel art requires integer scaling. A 16×16 tile at 1753px window width creates fractional pixel offsets. Sprites shimmer. Grid lines misalign. The whole thing looks "off" in a way players feel but can't articulate.

The fix is separating internal resolution from display size:

But then there's a follow-up trap: mouse coordinates break. event.offsetX maps to CSS display size, not internal canvas size. Every click-based UI element silently stops working.

And another follow-up: HUD elements using position: fixed anchor to the browser window, not the game canvas. When the canvas is centered with dark borders, the HUD floats off into the corner.

Solution: wrap everything in a position: relative container, use position: absolute for overlays.

4. Tile Caching is Non-Negotiable

Early builds re-drew every tile every frame. On a 40×40 map: 1,600 fillRect calls per frame, plus decorations like torches, cracks, and wall details.

Switching to an off-screen canvas tile cache — render the map once, blit it as a single drawImage — dropped draw calls from 2,000+ to under 200. On mobile, this was the difference between 60fps and slideshow.

5. Atmosphere is Just Math

The difference between "atmospheric dungeon" and "I can't see anything" is one float:

Same engine. Same radial gradient. Different emotional experience.

I also bumped the camp floor tile colors from rgb(68+v) to rgb(95+v) — a +27 shift. The camp instantly felt warmer, cozier, more safe. Atmosphere isn't a vague artistic quality. It's concrete numbers in your rendering pipeline.

6. Procedural Audio is Underrated

Zero audio files in the entire project. Every sound — sword slashes, footsteps, healing chimes, background music — is synthesized using the Web Audio API.

A sword attack is a filtered noise burst. A healing potion is an ascending C-E-G arpeggio. The dungeon BGM is a looping minor pentatonic pattern in square waves.

The best part: sounds become tunable. Boss hits play at lower frequency. Critical hits add a pitch sweep. Camp music shifts the filter for warmth. Sound becomes data, not static assets.

The Full Story
This post covers the highlights, but there's a lot more in the full writeup — the procedural dungeon generation algorithm, floor difficulty scaling, the complete camp station system, and how the entire architecture fits in 6 files with zero dependencies.

👉 Read the full dev log on InstantGames

🎮 Play the game (browser, no install)

Built with vanilla JavaScript + HTML5 Canvas. No frameworks. No build tools. The whole game is a single HTML file with 6 JS modules. If you're doing something similar, I'd love to hear about it in the comments.

A developer built 4 complete 3D games in 7 days.

Jason Guo — Wed, 18 Mar 2026 13:50:47 +0000

A developer built 4 complete 3D games in 7 days.
Zero lines of code written by hand.
Total cost: ~$20.
Here's how "Vibe Coding" is about to destroy the barrier to game development:
Instead of learning Unity or Unreal for months, you just... talk.
"Make a 3D arena shooter with weapon pickups and enemy AI."
→ AI writes the code
→ AI generates the assets
→ AI debugs the errors
→ You play and give feedback
→ Repeat until done
The stack he used:
🔧 Claude Code (primary) + Codex CLI
🎮 ThreeJS for 3D rendering
🎨 Meshy for AI-generated 3D models
🧪 Playwright for automated testing
In one week: endless runner, tower defense, Mario Party clone, arena shooter.
15,000+ lines of code. All AI-generated.
The full step-by-step guide is here:
👉 Game Daily

AI Daily Report: Foundation Models · Research (Mar 17, 2026)

Jason Guo — Tue, 17 Mar 2026 14:33:58 +0000

OpenAI’s GPT-5.4 isn’t just a bigger model; its 32x efficiency gain for reasoning tasks—dropping a complex ARC-AGI-1 task from $11.64 to a mere $0.37—changes the unit economics of autonomy.

We have moved from 'is this possible?' to 'how many millions of times per day should we do this?'

This is why NVIDIA is pivoting GTC 2026 toward the 'Agentic Scaling Law.' The bottleneck is no longer raw tokens-per-second; it’s the infrastructure required to manage sub-agent spawning, memory movement, and long-context tool calling.

If you are building for the chat interface, you are building for 2024. If you are building for the 'NemoClaw' and 'GPU+LPU' supercomputers, you are building for the agentic era.

Read full article:
https://windflash.us/daily-report/en/2026-03-17

I Built a Tower Defense Game With Zero Dependencies — AI Art, Procedural Audio, and ~3,200 Lines of Vanilla JS

Jason Guo — Mon, 16 Mar 2026 12:32:12 +0000

No React. No Phaser. No Pixi.js. No npm install. Just <canvas>, vanilla JS, and the Web Audio API.

🎮 Play it here · 📖 Full dev log

What I Built

Arcane Bastion is a crystal tower defense game with：

5 elemental towers（Fire / Ice / Lightning / Vine / Arcane）× 3 upgrade tiers
10 enemy types with status effects（freeze, burn, poison）
AI‑generated art — every sprite and map background
Procedural audio — every sound synthesized from oscillators, zero audio files
Dynamic tower rotation — smooth tracking with recoil feedback

The entire thing is 9 script files loaded via <script> tags in dependency order. Old school, but it works.

The Architecture

arcane-bastion/
├── js/
│   ├── sprites.js    ← async image loader (18 assets)
│   ├── map.js        ← 20×14 tile grid + AI backgrounds
│   ├── tower.js      ← 5 types, targeting, smooth rotation
│   ├── enemy.js      ← 10 types, waypoint pathfinding
│   ├── projectile.js ← homing missiles, chain lightning
│   ├── audio.js      ← Web Audio synthesis (~400 lines)
│   ├── ui.js         ← HUD, panels, bestiary overlay
│   ├── game.js       ← 60fps loop, wave state machine
│   └── demo-mode.js  ← scripted auto-demo + MediaRecorder

The Hardest Bug: Chrome's Autoplay Policy 🔇

This one wasted hours. My audio engine worked perfectly in local testing, but was completely silent on Chrome after deployment.

Root cause: Creating an AudioContext before the first user gesture puts it in suspended state — permanently. My Game.init() was calling AudioEngine.init() on page load.

The fix：

// ❌ BAD: Creates AudioContext on page load
function init() {
    ctx = new AudioContext(); // suspended forever!
}

// ✅ GOOD: Lazy-create on first user interaction
function init() {
    document.addEventListener('click', () => {
        if (!ctx) {
            ctx = new AudioContext();
            // now it works because user clicked first
        }
    });
}

And crucially — every sound function must call ensureContext() before the if (!ctx) return guard, not after. Get the order wrong and the context never gets created.

AI Art: Not Plug-and-Play

I generated all 18 visual assets（5 towers, 10 enemies, 3 maps）using AI image generation. Sounds easy, right?

The reality：

Consistency — Every prompt needed the same style anchor: “dark fantasy, pixel art, top-down, glowing magical effects”
Transparency — Early sprites had visible rectangular backgrounds. Each needed manual cleanup
Contrast — Sprites that looked great on a white canvas disappeared against dark map backgrounds. Had to add glow auras and brightness boosts
Scale — A beautiful 512×512 sprite becomes a blurry 50px blob at game scale

AI art saved weeks of illustration work, but the integration “last mile” still required significant manual effort.

Procedural Audio: Math → Sound

The most satisfying system to build. Every sound in the game is synthesized from OscillatorNode waveforms：

// Frost tower attack: crystalline "ping"
function frostShoot() {
    playTone(1200, 0.15, 'sine', 0.12);    // high shimmer
    playTone(800, 0.2, 'triangle', 0.08);  // harmonic
    playNoise(0.08, 0.1);                  // ice crackle
}

Fire, ice, lightning, vine, arcane — each element has a unique audio signature created by combining oscillator types（sine, triangle, sawtooth, square）at different frequencies and durations.

The background music is a multi‑oscillator ambient drone that evolves over time. The total audio system is ~400 lines — zero bytes of audio assets loaded.

Three Changes That Made the Biggest Visual Difference

AI map backgrounds replacing procedural tiles — went from “programmer art” to “atmospheric”
Glow auras on tower sprites（radial gradient circles behind each tower）— instant depth
Smooth tower rotation with Math.atan2 + lerp interpolation — made everything feel alive

None of these changed gameplay. All of them changed how the game feels.

Final Stats

Metric	Value
Lines of JS	~3,200
Code modules	9
AI-generated assets	18
External dependencies	0
Audio files	0
Build tools	0

I wrote a much deeper technical breakdown covering grid systems, pathfinding, chain lightning implementation, tower synergies, and how I recorded the demo video with audio using the browser's MediaRecorder API.

📖 Read the full 3,000+ word dev log →

🎮 Play Arcane Bastion →

Claude just launched Code Review for Claude Code, and I think this is a much bigger signal than a normal feature release. The next bottleneck in AI coding is no longer writing code. It’s reviewing code. https://claude.com/blog/code-review

Jason Guo — Tue, 10 Mar 2026 03:59:23 +0000

claude.com

I built a passive income gaming site in 7 days using AI — here's the exact workflow

Jason Guo — Fri, 06 Mar 2026 15:05:51 +0000

Last week I sat down with Cursor, a domain registrar, and a very specific niche keyword. Seven days later, the site was live, indexed, and earning its first AdSense impressions.
No team. No boilerplate repo I'd spent weeks perfecting. Just a clear prompt, an AI that could actually build what I described, and a keyword gap that nobody had filled yet.
Here's the part that surprised me most: the hardest part wasn't the code. Cursor handled the frontend. Claude Code handled the backend logic. GitHub Copilot filled in the gaps inline. The hard part was the judgment call — picking the right game, the right tool type, and the right search query that sits in that sweet spot of high intent and low competition.
The gaming niche looks saturated on the surface. It isn't. IGN and GameSpot own "best games 2026." Nobody owns "nicheRPGniche RPGnicheRPG damage calculator after patch 4.1." That's where a focused tool site walks in and ranks on page one within weeks.
The monetization side is equally concrete. Gaming sites on AdSense typically earn $3–$10 RPM. At 50k monthly pageviews from US/UK traffic, that's $300–$800/month passively. Hit 50k sessions and you can graduate to Mediavine for another 20–70% on top. It's not "get rich quick" math — it's compounding, predictable, and entirely driven by whether you picked the right keyword in week one.
The full guide covers everything I actually did:

    ul { list-style-type: disc; }
    ul ul { list-style-type: circle; }
    ul ul ul { list-style-type: square; }

How to choose between Cursor, Claude Code, and GitHub Copilot (and why stacking them beats picking one)
The three-layer keyword research method for finding gaps before competitors do
The 7 most profitable gaming tool site types ranked by traffic ceiling and monetization
A day-by-day 7-day build timeline with exact prompts
The AdSense approval checklist that gaming sites specifically need to pass

If you've been sitting on a side project idea and waiting for the tooling to catch up — it has.
Read the full guide on

Best-Games.io - Play 200+ Free Online Games Instantly | No Download

Play 200+ free online games instantly! Snake, Mahjong, 8 Ball Pool, racing, puzzle & action games. No download - play in browser.

best-games.io

Today, a game site I developed passed the Google AdSense review. After being rejected 4 or 5 times previously, this feels like a small step forward. https://best-games.io

Jason Guo — Thu, 05 Feb 2026 14:26:26 +0000

Snake, Mahjong, 8 Ball Pool & More - Best Free Online Games | Best-Games.io

Play 200+ free online games instantly! Snake, Mahjong, 8 Ball Pool, racing, puzzle & action games. No download - play in browser.

best-games.io

From “Vibe Coding” to “Agentic Engineering”: When Coding Becomes Orchestrating Agents

Jason Guo — Thu, 05 Feb 2026 09:54:41 +0000

More Articles please vist: Windflash AI Daily

In February 2025, Andrej Karpathy sent out a tweet that defined a moment. He christened a new style of programming "Vibe Coding"—a state where you surrender completely to the flow of AI generation. For a brief window, developers felt a unique kind of liberation: you simply spoke to your IDE, and code poured out like magic. Errors were fixed instantly, features appeared on command, and the only thing that mattered was the result. It was a dopamine-fueled joyride where we focused on the "what" and blissfully ignored the "how."

Fast forward to 2026. Looking back, the software world didn't collapse into a heap of unmaintainable sludge. Instead, it evolved. In his one-year retrospective, Karpathy noted that we have shifted from "vibes" to discipline, coining a new term: "Agentic Engineering." This isn't just a rebrand; it marks the maturation of the industry from weekend hacking to professional system orchestration. Today, the core skill for every developer is no longer just typing code, but mastering the art of guiding AI agents that code faster than we can think—while ensuring production-grade safety and quality. This post explores how we got here and provides a practical roadmap for the new era of agentic workflows.

What People Mean by “Vibe Coding”

To understand where we are going, we have to revisit where we started. In early 2025, tools like Cursor Composer integrated models like Claude 3.5 Sonnet, creating a quantum leap in developer experience.

Karpathy described this shift as "fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists." It was a shift away from precision and toward pure momentum.

Typical Symptoms of Vibe Coding
As originally described, this mode of work is characterized by several distinct behaviors:

Natural Language Driven: The keyboard gathers dust. You talk directly to your IDE using tools like SuperWhisper. You give vague commands like "decrease the padding on the sidebar by half" because you are simply too lazy to hunt down the CSS file yourself.

Accept All: You stop reading the diffs. The AI generates code faster than you can verify it, so you hit "Accept All" and trust the momentum.

Paste Errors as Prompts: When the build fails, you don't debug. You paste the stack trace directly into the chat window without a single word of commentary. Usually, the AI fixes it.

Abandoning Comprehension: The codebase grows rapidly, often beyond your mental model. If the AI can't fix a bug, you ask it to "randomly change things until it goes away" or find a workaround. You prioritize forward motion over understanding the root cause.

This pattern was incredibly seductive because it lowered the barrier to creation. As tools like SuperWhisper demonstrated, developers could act as commanders, dispatching orders to Cursor or Claude Code and watching ideas transmute into products in real-time.
For weekend projects, prototypes, or throwaway scripts, this was perfect—it offered maximum efficiency and instant gratification. However, as Karpathy later admitted, this was more of an "experience" than a rigorous engineering method. When this "don't look at the code" habit bled into long-term production environments, the cracks appeared: unmaintainable spaghetti code, hidden security vulnerabilities, and team friction caused by a total collapse of shared understanding.

One Year Later: From “Let It Rip” to Engineering Discipline

If 2025 was the year of the "Vibe Coding" party, 2026 is the year of the hangover—and the subsequent return to sobriety. In his retrospective, Karpathy admitted that the term went viral because it captured the excitement of the moment. But he was clear: while professional workflows now default to using LLM agents, they must be paired with significantly higher oversight and scrutiny.

This new paradigm is Agentic Engineering. The name itself signals a dual commitment:

Agentic: Acknowledging that for 99% of the work, you are not writing the code directly. You are orchestrating agents that do.
Engineering: Emphasizing that this is a discipline requiring expertise, structure, and science. It is not a slot machine; it is a skill you can refine and master.

This shift represents a fundamental change in how we operate. As Google Engineering Director Addy Osmani describes, we are crossing the chasm from "Imperative" to "Declarative" programming. We no longer tell the computer how to do something (write this loop, define that variable); we tell it what we want (pass these tests, handle this edge case). The table below contrasts these two eras:

As predicted, 2026 brings us improvements in both the Model Layer and the Agent Layer. These advancements allow us to build software that is more complex and robust than ever before—but only if we learn to effectively "manage" our digital workforce.

Bringing Agents to Production: A Safer Workflow

The biggest risk in bringing AI agents into production is what Addy Osmani calls "Comprehension Debt." When an agent generates code faster than you can read and understand it, you are borrowing against your future ability to maintain that system. AI can easily do the first 80% of the work. But the final 20%—the integration, the subtle bugs, the performance tuning—requires deep understanding. If you check out mentally during the first 80%, that final 20% becomes an insurmountable wall.

To mitigate this, we need a "Playbook for Production" that turns the luck-based "vibe" into a controlled process:

1. Prompts as Specifications
Stop giving vague instructions like "make this page better." Treat your prompts like requirements documents for a junior engineer. A qualified agent task description must include:

Acceptance Criteria: Specific conditions the feature must meet to be considered done.
Boundary Conditions: Expected behavior for empty states, network failures, or invalid inputs.
Non-goals: Explicitly tell the Agent what not to do to prevent "Abstraction Bloat"—the tendency of agents to over-engineer simple solutions.

2. Automated Verification as Guardrails
In the Vibe Coding era, we relied on our eyes. In Agentic Engineering, code does not enter the repository without passing automated checks.

TDD Revival: Have the AI write the test cases first. Once you verify the tests are correct, let the AI write the implementation until the tests pass. This is the most effective defense against hallucinations.
Strict Type Checking: Leverage the type systems of TypeScript or Rust. Let the compiler be your first line of defense, filtering out the low-level syntax errors and type mismatches that agents are prone to making.

3. Task Decomposition and Permissions
Never ask an Agent to refactor an entire module in one go.

Atomic Iteration: Break large tasks into atomic units, where each change touches only 3-5 files. This ensures the resulting diff is small enough for a human to actually review.
Require Explanations: Before accepting code, force the Agent to generate a "Summary of Changes" explaining what it did and why. If its explanation is confused, the code is almost certainly broken.

4. Fresh Context Review
Addy Osmani suggests a powerful technique: ask the AI to review its own code, but do it in a fresh chat window. In a long conversation, the AI often suffers from "Sycophantic Agreement"—it doubles down on previous mistakes to please you. A fresh context forces it to look at the code objectively, often revealing logic gaps it previously missed.

When should you NEVER Vibe Code?
Tools are powerful, but some domains require 100% human control. Do not delegate:

Security-Critical Logic: Payment processing, authentication flows, and encryption implementation.

Compliance-Heavy Data: Handling PII (Personally Identifiable Information) or medical records.

Infrastructure Core: A hallucinated Terraform configuration can lead to a cloud bill explosion or a total service outage.

Conclusion: Turn Vibes into Method
From 2025 to 2026, we witnessed AI programming settle from a dizzying "Vibe" into a replicable "Method." The value of Vibe Coding was that it shattered the barriers to creation, allowing us to splash ideas onto the screen like artists. Agentic Engineering builds on that freedom but reintroduces the discipline and rigor of the engineer.
In this new era, your value as a developer is no longer defined by your typing speed or your memorization of API parameters. It is defined by the clarity with which you define problems and the accuracy with which you judge results. As Karpathy envisions, 2026 will see the dual evolution of models and agents. Our job is to be the ones who define the destination and ensure the quality of the journey.
To ensure you aren't left behind by this wave, here are three actionable steps to start today:

Start as a Reviewer: In your next feature, try writing only the tests and documentation. Let the Agent write the implementation, then force yourself to review it as strictly as you would a colleague's code.
Practice Declarative Communication: When the Agent makes a mistake, don't paste code snippets to fix it. Instead, try to describe the logical fallacy in precise natural language. Train yourself to "direct" rather than "do."
Focus on Architecture, Not Syntax: Use the time you save to study system design, design patterns, and security architecture. These are the areas where AI is most likely to dig a hole—and the hardest for it to fill on its own.