DEV Community: Lugiax

Nobody Hand-Writes Assembly Anymore. Why Are You Still Reviewing 2,000-Line AI Diffs?

Lugiax — Wed, 28 Oct 2026 13:06:03 +0000

TL;DR: In 1957, IBM released Fortran, and veteran engineers furiously swore they would never trust machine-generated assembly without manual verification. Today, history is repeating itself. High-level languages are quietly becoming the new machine code. Staring bloodshot-eyed at a 2,000-line AI git diff isn't rigorous engineering—it's performative security theater. Here is why the old Code Review paradigm is dead, how the "Three Defenses" replace it, and how combining agy (Antigravity CLI) with multi-agent orchestration tools like Polter gives us our sanity back.

In 1957, IBM unveiled something that shook the computing world to its core: Fortran.

It was the world’s first true high-level programming language.

Before Fortran, writing software was an exercise in pure masochism. Programmers spent their days hunched over desks, punching binary machine code and raw assembly mnemonics into paper cards and punch tapes—manually dictating every single memory address, accumulator shift, and hardware register.

When John Backus and his team introduced Fortran, their promise sounded almost utopian:

"You no longer need to remember machine registers or memory offsets. Just write mathematical formulas resembling plain English sentences, and the compiler will translate them into raw machine instructions for you."

How do you think the elite programmers of 1957 reacted?

Did they throw a party? Did they celebrate their newfound freedom?

Not a chance. They hated it.

Computing journals and academic labs erupted in righteous indignation:

"The code emitted by the compiler is bloated and slow!"
"No mechanical program could ever optimize memory better than a seasoned human!"
"If I didn't hand-craft every single opcode myself, I cannot trust it. Every line of emitted assembly must be manually verified!"

Yet, the freight train of history didn't care about their bruised egos.

Within a few short years, virtually all business and scientific computing migrated to high-level languages. Fast forward to today: unless you are writing bare-metal micro-controllers, Linux kernel drivers, or compiler backends, nobody hand-writes assembly anymore. And nobody on your team asks you to review the compiler’s assembly output before pushing a PR.

Why? Because the software industry learned a permanent truth:

Once an abstraction ladder goes up, it never comes back down.

And right now, in 2026, the pendulum of history has swung straight back to the exact same spot.

When an LLM spits out 2,500 lines of pristine TypeScript, Go, or Python in four seconds, millions of developers still sit glued to their monitors at midnight, eyes stinging, scrolling line-by-line through a monstrous git diff.

We seem to have forgotten: Our programming languages are rapidly degrading into modern-day assembly.

1. The Cognitive Trap: Inspecting AI Code Like It's 1995 Assembly

Whenever I tell people that "Python is the new assembly," their gut reaction is almost always defensive:

"Are you crazy? High-level languages have rigid syntax, type safety, and semantic structure! We write code, AI writes code—how can you compare TypeScript to raw machine hex?"

To see why this comparison holds up, we need to understand how technical abstractions actually evolve:

The Core Rule: Computing history is just the story of putting thicker and thicker lids on underlying complexity.
The Automobile Analogy:
- Gen 1 (The Hand-Crank Era): In the early 1900s, starting a car meant walking to the front bumper, inserting an iron crank, and manually spinning the crankshaft. Drivers had to understand spark timing and valve compression just to leave the driveway.
- Gen 2 (The Ignition Key & Automatic Transmission): Turn a key, press the gas pedal, and drive. You don’t know—or care—which microsecond the third cylinder's spark plug fired.
- Gen 3 (Autonomous Driving): You slide into the back seat and say: "Take me to the nearest airport, and avoid the toll roads." If you still spend the entire ride anxiously monitoring whether the steering rack is turning at 14.2 degrees or 14.5 degrees, you aren't being safe; you're just exhausting yourself.

When Keyboard Typing Cost Hits Zero, Syntax Reviews Collapse

Why did we spend the last thirty years worshipping at the altar of the Pull Request Code Review?

Because code was written by meatware.

Humans are slow, clumsy typists prone to fatigue. We accidentally write = instead of ==, we introduce off-by-one errors on Friday afternoons, and we forget null checks. Peer review was an effective linting net for human fallibility.

With AI, the dynamic has completely flipped:

Throughput Asymmetry: A state-of-the-art agent like agy (Google Antigravity CLI) or Claude can refactor 12 files across 2,000 lines of code in 15 seconds. It takes a seasoned engineer at least 90 minutes of intense focus to properly read that diff. The review bottleneck has blown completely wide open.
Cosmetic Perfection Masks Latent Disaster: AI produces gorgeous code. The variable names are poetic, the formatting is spotless, and the docstrings are more descriptive than anything you’ve ever written.

When the human brain encounters a 2,000-line diff of aesthetically flawless code, cognitive fatigue sets in within 10 minutes. By line 400, your vigilance is dead. You scroll, nod, and hit "Approve".

You think you're standing guard as a gatekeeper. In reality, you're paying an extortionate cognitive tax just to purchase psychological comfort.

2. The Great Rebuttal: "Compilers Don't Hallucinate, But AI Does!"

Here comes the immediate objection—and it's a completely legitimate one:

"Wait a minute! Your Fortran analogy is fundamentally flawed. When developers abandoned manual assembly checks, it was because compilers are **deterministic. A C compiler will never invent a nonexistent x86 instruction out of thin air. But LLMs are **probabilistic—they hallucinate! If I don't read every line, how do I know the code won't blow up production?"

Bingo. This is the crux of the entire debate.

Yes, AI hallucinates. But relying on tired human eyeballs to catch those hallucinations in a 2,000-line diff is pure lunacy.

Why? Because in 2026, AI hallucinations are almost never obvious syntax errors.

An AI doesn't write syntax that breaks the compiler. Instead, it introduces insidious, high-entropy bugs:

It invents an optional parameter that sounds 100% plausible on an AWS SDK, but doesn't actually exist in that version.
It silently omits an idempotent cleanup handler inside a retry loop that only fires after the 3rd network timeout.
It writes a shared-memory concurrent routine that passes every naive unit test, but deadlocks under high-throughput race conditions.

Be honest: Are you going to spot that subtle race condition by squinting at a green-and-red diff on GitHub at 11 PM? Or is an automated stress runner in an isolated sandbox going to catch it?

The answer is obvious.

When high-level languages replaced hand-written assembly, engineers didn't surrender to blind faith. They built type checkers, static analyzers, and compiler sanitizers.

Now that we are shifting to probabilistic AI generators, our defenses must evolve from "human eyeballs scanning text" to "Rigid Upstream Contracts + Automated Machine Verification."

3. The New Engineering Paradigm: The "Three Defenses"

Elite teams who have stopped drowning in AI diffs have reorganized their workflow around a Three-Defense Framework:

Defense Layer	Who / What Runs It	Core Responsibility & Defensive Action
1. Upstream Legislation (Architecture & Schema)	Human Architect + High-Reasoning Agent (e.g. agy / Claude Opus)	Lock down strict interface contracts, database schemas, OpenAPI specs, and state transition invariants before a single line of business code is written. Never give the AI an unconstrained blank canvas.
2. Midfield Pipeline (Throughput & Anti-Corruption)	Fast Coder Agent + Strict Reviewer Agent + AST Refactoring Agent	Fast, high-throughput models (like DeepSeek Flash / Gemini Flash) implement the business logic. A detached reviewer agent audits against the contract (review only, never edit). An advanced model cleans AST duplicates to prevent tech-debt rot.
3. Downstream Verdict (Empirical Proof & UX)	Independent Tester Agent in Sandbox + Real Human Product Sense	Sandbox agent boots clean environments, executes deterministic integration suites, fuzzing, and load tests. Humans step in as the final experiential authority to evaluate latency, tactile feel, and product delight.

Rule 1: Anchor the Two Ends (Contracts Upstream, Evidence Downstream)

Spend 80% of your time on the blueprint before coding: Review data models, error boundaries, and API contracts with your AI. If the foundational schema is mathematically tight, the AI can code with its eyes closed and the house won’t collapse.
Judge by empirical runtime evidence, not code diffs: Did the test coverage hit 95%? Did the integration suite pass under 1,000 virtual users on k6? Did the error rate stay at zero? Review the execution proof, not the syntax.

Rule 2: Reclaim What Makes You Human

Stop playing the role of an expensive human linter. Spend your precious biological brain cycles on:

Untangling nuanced business logic and edge-case domain rules;
Talking to real customers to unearth what they actually need;
Actually running the compiled build, clicking through the app, and diagnosing clumsy UX friction that no LLM can feel.

4. The Tooling Gap: Why Traditional IDEs and Isolated CLIs Fail Us

If the "Three Defenses" paradigm makes so much sense, why are most developers still miserable?

Because our developer tooling is trapped in the previous decade:

The IDE Monoculture Trap: Editors like VS Code were built around the philosophy of one human, one file, one cursor. When an AI refactors 40 files simultaneously, your IDE panics and dumps a massive two-column split diff on your screen, begging you to review line-by-line. The tool’s interaction model directly clashes with the model’s generation throughput.
The Isolated CLI Bottleneck: Running autonomous coding CLIs in separate terminal tabs quickly turns into a game of manual babysitting. You copy-paste API schemas between windows; long-running jobs silently freeze waiting for a Proceed? [y/N] confirmation while you grab a coffee; and if a session crashes, all shared agent memory is gone.

This brings us to the missing link in the modern AI engineering stack: The pairing of advanced agentic CLI engines with a centralized, multi-agent terminal cockpit.

┌─────────────────────────────────────────────────────────────┐
│                       HUMAN ARCHITECT                       │
│           (Defines Contracts, Rules & UX Boundaries)        │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                 POLTER (Ghostty Multi-Agent Cockpit)        │
│  - Millisecond Quiescence Detection   - Persistent Task Bus │
│  - Autonomous Prompt Auto-Responder   - Shared Local State  │
├──────────────────────────────┬──────────────────────────────┤
│                              │                              │
│   Tab 1: Architect / Sup     │   Tab 2: agy (Antigravity)   │
│   (Claude Opus / Orchestrator)│   Autonomous Engine & Skills │
│   - Creates Task Cards       │   - Deep Codebase Invariants │
│   - Sets OpenAPI / Schemas   │   - Subagents & MCP Tools    │
│   - Delegates to Workers     │   - High-Throughput Coders   │
│                              │                              │
│   Tab 3: Sandbox / Stress    │   Tab 4: Cleaner / Sweeper   │
│   - Headless Docker Sandbox  │   - Cross-file AST Refactor  │
│   - k6 Load & Fuzz Testing   │   - Dead Code Elimination    │
│   - Emits Verified Evidence  │   - Anti-Corruption Layer    │
└─────────────────────────────────────────────────────────────┘

The Heavy Hitter: `agy` (Google Antigravity CLI)

If you haven’t used agy (Antigravity CLI) yet, you are missing out on what a true agentic coding environment feels like.

Unlike shallow autocomplete tools that merely guess the next five tokens, agy was engineered from the ground up for high-leverage software engineering:

Rich Customization & Rules: With hierarchical .gemini/rules and dedicated agent roles, you can bake your architectural standards (e.g., "Never mutate state directly," "All endpoints must validate Zod schemas") straight into the agent’s subconscious.
Custom Skills & MCP Tooling: agy dynamically activates specialized skills and hooks into local Model Context Protocol (MCP) servers, allowing it to inspect runtime databases, consult internal doc trees, and run diagnostics without context pollution.
Native Subagent Delegation: Need to implement a new billing engine? agy doesn’t dump everything into one giant prompt. It can spawn focused subagents (like a specialized research worker or an isolated refactoring unit), synthesize their outputs, and keep your core context clean.

The Cockpit: Polter (Local Multi-Agent Orchestration)

While agy provides the cognitive horsepower and tool-use mastery inside a session, Polter provides the system-level orchestration environment that ties everything together. Built on top of the ultra-fast Ghostty terminal, Polter turns separate terminal tabs into a synchronized, autonomous engineering floor:

Supervisor Mode & Externalized Task State: In Polter, an orchestrator terminal (running become_supervisor) ingests human requirements, writes immutable contracts, and uses task_create to populate a persistent, local task board. Even if your machine reboots, every worker’s status (open, working, closed) is fully preserved.
Quiescence Detection & Smart Auto-Answering: The biggest killer of automated agent workflows is the silent prompt freeze. If an agent runs an npm install or creates a directory that prompts [Y/n], traditional setups wait forever. Polter monitors screen quiescence down to the millisecond. If a terminal idles on a non-destructive prompt, the supervisor reads the screen with terminal_read and safely dispatches terminal_answer_prompt to unblock the pipeline. Human intervention is only requested for genuinely risky actions.
Decoupled Asynchronous Local Bus: Instead of piping everything through a fragile cloud server, worker terminals communicate through local file-backed group channels (group_post and group_read). An agy agent completes a module, posts the build receipt to the channel, and immediately triggers an isolated testing terminal to run the validation suite.
Evidence-Driven Handoff: When agy finishes a feature under Polter’s watch, you don’t get a 2,000-line diff to eyeball. You get a tidy summary from the supervisor: > "Feature implemented by agy against OpenAPI spec v2.1. 3 sub-tasks closed. Sandbox integration test passed (52/52 assertions). Zero regressions detected. Here is the live staging URL to try it out."

That is what modern software engineering looks like.

5. Conclusion: From Code Reviewer to Systems Designer

Every major transition in software history has met resistance because it forced developers to redefine their self-worth.

In 1957, Fortran didn’t eliminate programmers—it liberated them from allocating registers and calculating memory byte offsets, sparking the software revolution that created the modern world.

In 2026, generative AI and tools like agy have driven the marginal cost of syntax generation to zero. In response, the marginal return of reviewing raw syntax line-by-line has collapsed into negative territory.

The essence of software engineering hasn’t died. Only the interface has changed:

Stop being a human spell-checker; become an architectural legislator. Your value is in defining razor-sharp schemas, invariant rules, and error budgets before the code is generated.
Stop eyeballing diffs; demand empirical, automated proof. Let deterministic compilers, strict type systems, and headless sandbox runners catch hallucinations. Trust machine evidence, not your late-night eyesight.
Save your human intuition for the product itself. When the terminals, agents, and cockpits handle the heavy lifting, you can finally focus on what software was always meant to do: solve complex human problems with clarity, speed, and elegance.

Step away from that 2,000-line diff. Put on your architect hat. The new abstraction layer is already here.

Resources & Open Source Projects

🔗 Polter Terminal Workbench: https://github.com/Lugia123/polter — A 100% local, multi-agent terminal cockpit built on Ghostty with supervisor scheduling, quiescence detection, and automated task persistence.
⚡ Google Antigravity (agy) Ecosystem: Leverage custom skills, MCP tools, and autonomous subagent workflows to power your development engine.
💬 How is your team dealing with massive AI pull requests? Are you still reading every diff, or have you moved to contract-driven verification? Let’s argue in the comments below.

Every Test Passed. Then the UI Got Thrown Out.

Lugiax — Wed, 21 Oct 2026 15:53:55 +0000

At 1:31 AM, the automated checklist reached its final item.

Eight checks: seven passed, one was marked "record current state," and not a single check was red. By every test report, the feature was done and ready to ship.

Then the user stopped everything.

The verdict was one short sentence that no test suite could argue with: the UI looks bad, redo all of it.

Most developers have been here. The pipeline is green, you feel the relief, and then a person looks at the thing and it feels wrong. The logic is sound. The product still isn't right.

The feature was a native screenshot tool for an open-source terminal app. Press a shortcut, freeze the screen, drag out a region, and draw on top of it. AI agents wrote most of the code; human developers set the direction and made the hard calls.

From the first line of code to the final UI took 10 hours 22 minutes and 27 commits.

Along the way, we ran into three nasty bugs on real hardware that the test suite never caught. Those bugs make up the first half of this story.

The second half is about what happened after that "redo all of it" order, and how we turned a vague complaint into hard numbers.

It all started with an architectural choice that seemed sensible at first, until we threw the whole thing away.

Why we threw away the macOS code to mirror Windows function by function

The tool had to ship on both Windows and macOS.

My first instinct was that each platform could do its own thing internally, as long as the visible features matched.

That idea didn't last long. Windows got the first build, and then macOS followed. A few hours later, the macOS code was thrown away. It was rewritten from scratch to mirror the Windows version function by function.

The spec said the two platforms had to behave the same, item by item. The only allowed difference was the modifier key: Command on macOS where Windows uses the Windows key. Both sides also had to run against the exact same test data and produce the exact same expected outputs.

The dev log puts the reason plainly (translated from Chinese): we want both platforms to produce the same exact value, not two values that are close.

Think of two cooks making the same dish. If each works from memory, you get two meals that taste "about the same." If both follow one recipe and weigh every ingredient on a scale, you get the exact same dish.

None of this had run on a physical machine yet. One of the early commit messages says so (again translated): "No human has pressed confirm on this version yet."

The first run on a real Windows machine broke the undo shortcut immediately.

The undo button on the screen worked fine, but the keyboard shortcut did nothing. The code checked the keyboard state at the exact moment the event got handled. When you tap a shortcut quickly, your fingers are already off the keys by the time the handler runs.

That was the easy one to fix. The next bug on Windows froze the whole app.

A thin white edge that froze the app in an endless loop

A screenshot tool needs text annotations. That means a floating text box sits next to a toolbar with pens, arrows, and other tools.

In some screen layouts, the text box ended up sitting right on top of the toolbar. To keep the toolbar buttons clickable, we cut a transparent hole in the text box where they overlapped.

Clicks worked again, but the cutout left a thin white edge behind. It was the text box's own white background bleeding through.

The obvious fix seemed to be a quick patch. Every time the text box moved, we forced the toolbar to repaint (redraw its pixels on screen) over the overlapping area to cover the white edge.

Instead, the app froze.

On a physical Windows machine, opening the text box sent CPU usage spiking. The program spun in place and locked up. Four tries, four hangs.

The cause was hidden deep inside how Windows draws native controls.

The native text box keeps an old behavior that lets a control paint outside its own bounds. That white edge was the control painting past its own border. Each forced repaint woke that out-of-bounds painting up again, which triggered another repaint request, spinning forever in an infinite loop.

The fix wasn't another patch. We swapped the native text box for one with that out-of-bounds painting turned off.

Once the control could no longer paint past its own edge, the white strip was gone for good.

Before you cover one patch with another, find the control that is drawing where it shouldn't be.

That was Windows. On macOS, a different bug was waiting in the same text box.

The macOS text box that typed "n你好" instead of "你好"

The next bug showed up on macOS.

In the screenshot text box, using the built-in Pinyin input method, you type n-i-h-a-o and press space to confirm. That should produce 你好 ("hello").

What actually showed up was "n你好". The first letter was stuck in front of the Chinese characters.

Here's some background if you have never worked with an IME (an Input Method Editor, the system tool used to type characters in languages like Chinese or Japanese). While you type Pinyin letters, they sit in a temporary composition buffer. macOS calls this active state marked text. Only when you confirm your selection does that buffer turn into real characters and commit to the field.

The bug came from an auto-grow feature. The text box starts one line tall and gets taller as you type.

The first time the box grew taller, the operating system switched the text layout engine underneath. That switch cleared the marked text state. Because the buffer was suddenly wiped out, the system treated the first letter, n, as already-committed text.

The dev log pinned it down (translated): "Didn't happen in earlier builds. Regression from the dynamic height change."

A regression is when previously working code breaks because of a new change.

The fix was to lock the text box to one layout engine from the moment it was created, and never let it switch. After that, we tested every font size on a real Mac, and 你好 came out clean.

The interesting part is that this bug never showed up in our automated tests. They run without real window management, and that's where the bug lives.

Anything that touches IME state, marked text, or window focus must be typed into on a physical machine.

Text input was fixed. The scrolling capture was next, and it had its own trap.

Why the scrolling screenshot refused to move past the first screen

The third problem was the scrolling screenshot, also called a long screenshot.

The concept is straightforward. The user scrolls down, the capture engine grabs frames quickly, compares each new frame to the last one to find where they overlap, and appends the newly revealed part to the bottom.

To find the overlap, we used a strict pixel diff (a row-by-row pixel comparison). If row X of the previous frame exactly matches row Y of the current one, the algorithm knows how far the page moved.

On a real machine, no matter how far you scrolled, the output image stayed stuck at one screen tall. Not a single new frame got merged.

The culprit was a column of pixels that never moved at all: the window border.

The page content scrolled, but the window border at the edge of the selected region stayed put. Every row in the comparison had a few border pixels that could never match. In a strict comparison, one mismatched pixel rejects the entire row. Every row got rejected, so the engine concluded there was no overlap anywhere.

The fix follows from that: before comparing frames, drop the pixel columns that stay completely still from top to bottom, so they don't count toward the match.

There's a trap in that rule. "Still" must mean the column is exactly identical all the way down, not just mostly identical. Take line numbers in a code editor. They look almost the same from row to row, but their small shifts are the best signal you have for tracking how far the page moved.

With the border handled, the scrollbar broke the algorithm next. The scrollbar thumb doesn't scroll with the page, and it doesn't stay still either. It moves a little, at its own separate ratio.

So the engine received a second rule. If a pixel column changes in at most two segments, and the changed part is less than half its height, it is treated as background noise and left out of the comparison.

We also added a safety rule for failure. If the user scrolls so fast that frames get dropped, the engine throws away the broken frame and displays a "slow down" message. It never forces a stitch.

Before you ask an algorithm to compare two things, cut out everything that shouldn't be part of the comparison.

That should have been the end of the night. It wasn't.

Turning "it looks bad" into hard pixel measurements

With those three bugs resolved, testing on real hardware went green. That brought us right back to 1:31 AM.

All 8 checks passed. Buttons responded, text input worked, and long screenshots stitched cleanly. QA had nothing left to mark as failed.

Then came the user review. The complaints were clear:

The icons didn't feel balanced in visual weight. The gray plate behind the selected tool looked cheap. The dots used to pick the font size didn't make sense. And the opaque text box covered what was underneath it.

Editing code against feedback like that is guesswork.

So we stopped writing code and started measuring pixels.

We used the app's own rendering code to draw each toolbar icon on its own, and we counted how many pixels it filled.

The hard numbers explained the imbalance immediately.

The lightest icon (undo) and the heaviest icon (mosaic) differed in filled area by 8.3x. Picture a shot put and a balloon sitting side by side in the same toolbar.

The shapes were misaligned as well. The long-screenshot icon was tall and thin like a pole, sticking up above the baseline. The arrow in the selection tool wasn't centered in its 16x16 grid; it leaned noticeably to the left.

The worst find was where the graphics came from. 5 icons were not drawn from vector paths at all. They were plain characters pulled from the host operating system's fonts. Windows and macOS ship different system fonts, so those 5 icons looked visibly different on the two platforms.

"It looks bad" was no longer a matter of opinion. It was now a table of pixel measurements. That table became the acceptance criteria for the UI rework.

When someone says something looks wrong and you can't argue with it, the first step is to find a way to measure it.

We had the data. But before we touched any code, we changed how we worked.

Locking in the mockup before writing a single line of native code

This time, no AI was allowed to touch the code.

We had already seen what happens otherwise. You build the UI in code, compile it, and show it to the user. If the visual direction is wrong, all the cross-platform work gets thrown out.

So we went mockup-first.

We built high-fidelity mockups using web technologies. A browser mockup isn't the native code that ships to users, but you can iterate on it more than ten times faster than on compiled code.

From the "redo all of it" order to the new UI spec being committed took 76 minutes. In that time, the mockup went through three major versions.

Each small request got settled directly inside the mockup: hover feedback, replacing the confusing font-size dots with a small and a large letter "T," and switching a solid border to a dashed one so it blocked less of the view.

Making those changes in native code would have meant editing and recompiling both platforms dozens of times. In the mockup, it was just dragging elements and changing values.

Any disagreement about looks that can be settled in a mockup should never make it into the code.

The visual design was locked in. Now we had to build it in native code without letting the two platforms drift apart by a single pixel.

One data file, two platforms, zero pixel difference

With the design settled, the engineering question was how to guarantee that the two platforms could never drift apart, even by a single pixel.

The lesson from the old version was clear. Each platform had its own separate implementation, and 5 icons ended up looking different on each.

This time, we established a single source of truth.

A single source of truth means one file that every platform reads from. Every UI parameter (color values, spacing, and Bézier control points) went into one standalone data file.

The Windows and macOS UI code was no longer written by the AI agents. Instead, a custom script reads that data file and generates the UI code for each platform automatically.

It works like casting parts from a single mold: parts from the same mold cannot drift past tolerance.

Rendering received the exact same treatment.

The native drawing APIs on Windows and macOS handle anti-aliasing slightly differently. Anti-aliasing is how graphics systems smooth the jagged edges of lines. Because the two systems drew lines differently, we stopped using the built-in line drawing and ran the same basic rendering code on both platforms.

To check our work, we pulled the outlines of all 60 icons as rendered on each platform and compared them pixel by pixel.

They matched exactly, with zero pixel difference.

The code was unified, and the icons were identical. Which brings us back to what that green test suite actually meant.

What a green test suite can and cannot promise

Boil those 10 hours 22 minutes down, and you get a clear lesson: automated tests are very good at catching logic bugs, but they are blind to how an app feels to use. A lot of what makes software feel well made sits outside the green checkmarks.

What automated tests can promise	What a human still has to check
Pipeline is green, no errors	Is a test case missing? Did a real problem quietly get downgraded to "record current state"?
Unit tests pass 100%	Has it run on a physical machine? Has a person's hand gone through the interaction?
The visual glitch (white edge) is covered up in code	Was the underlying cause removed, or just covered with another patch?
Frame comparison failed, logic stopped	Did the algorithm drop the noise that never belonged in the comparison?
The feature works end to end	Does it look and feel right? Was there a high-fidelity review before coding?
Both platforms are done	Were both generated from the same data, or did each side settle on its own version?

Think back to 1:31 AM.

The all-green checklist didn't lie. It checked everything it was built to check. It just had no item for "does this look good."

Next time someone tells you all tests pass, ask one more question: beyond the code being correct, who decided how it should look and feel, and at what point?

The screenshot tool, new toolbar included, has shipped in Polter, a terminal for macOS and Windows built on Ghostty's rendering: https://github.com/Lugia123/polter

Save Your Whole Terminal Workspace as a Project in Polter

Lugiax — Tue, 20 Oct 2026 14:00:00 +0000

You have the same three tabs open every day: a dev server, tail -f on a log, and a pane for git and vim. Then you restart. You cd three times, retype three commands, and whatever error you were reading is gone.

Polter is a terminal for macOS and Windows built on Ghostty's rendering. Its main feature is projects: workspaces you save and load back later. This post follows the video chapter by chapter.

A quick note on the base: Polter uses Ghostty's rendering, VT parsing, and fonts (MIT). It is not an official Ghostty project and is not affiliated with it.

1. Set up a normal workday

The demo project is called shop-web. It has three tabs:

Tab 1, split in two with ⌘D. Left: python3 -m http.server 8123. Right: tail -f logs/app.log.
Tab 2: git log --oneline -20, then a quick edit in vim README.md.
Tab 3: a few loose commands such as ls -la and du -sh *.

2. Save it as a project

Right-click a tab and choose Save as Project… (it is also in the Project menu). The dialog lists the window's tabs. Only the current one is ticked, so tick all three, type a name (shop-web), and confirm.

You only do this once. Polter writes layout changes back to the project on its own. If you drag a split divider, the new ratio is saved without another click.

3. Quit, reopen, load

Press ⌘Q. If a process is still running, Polter asks first; click Terminate. Reopen the app and you get a single empty window. Choose Project → Load Project… and pick shop-web.

You get your three tabs back, along with the split ratio, every pane in its own directory, and the old output. A dim divider line separates the last session from the new one:

── Above this line: history restored from the previous session ──

Below it sits a fresh prompt.

4. What does not come back

This part matters more than the demo.

Processes. The server in the left pane is not running. The pane shows the old output and a new shell. Your command history did come along: press Up, then Enter, and the server is back.
Full-screen programs. The tab where you used vim shows what was printed before vim opened, not vim.
Kitty graphics come back as blank space.

If you need processes to survive, that is tmux's job. tmux keeps processes alive when you close a window, though its server also dies on reboot. You can run tmux inside Polter.

5. Crashes and power cuts

Scrollback is written to disk while panes run: every 5 seconds by default, new lines only. In the worst case, you lose about 5 seconds of output. Each pane keeps 10 MB of scrollback by default, which is about 120,000 lines of plain text. When it fills, the oldest lines go first.

The two settings are project-scrollback-autosave-interval and project-scrollback-limit-bytes.

6. The Settings window and your config file

Press ⌘, to open Settings. Changing the font size updates the terminal immediately, with no save button.

The window edits your plain-text config. On macOS the file is at ~/Library/Application Support/com.lugia.polter/config.polter. If a setting is already in the file, such as font-size = 20, Polter replaces that line in place. If it is not there, Polter appends it at the end in a block marked as written by the Settings window. A backup (config.polter.polter-bak) is made before the first write after each launch.

You can still edit the file by hand. Save it, press ⇧⌘, to reload the config, and the Settings window shows the new value. The window does not watch the file, so it will not update without that reload.

7. The MCP interface

The last chapter is for tinkerers. Polter ships an MCP interface: other programs can list your terminals, read a screen, and type for you. The config line is:

{"command": "polter", "args": ["+mcp"]}

In the video I use the generic MCP Inspector to call terminal_list, terminal_read and terminal_send. It has guards. If you typed in a pane in the last ten seconds, terminal_send is refused with UserPresent. If there is half a command on the line, it is refused with DraftInLine. Setting poltergeist-mcp = false turns the interface off. I have only exercised it through the Inspector.

8. Windows and download

The same project model runs on Windows; the video shows a short clip. Packages are on the releases page for macOS 13+ and Windows 10+. There is no Linux installer yet, so on Linux you build from source.

Download: https://github.com/Lugia123/polter/releases/latest
Source (MIT): https://github.com/Lugia123/polter

If you try it, save a project, quit, reopen, and look for the divider line. I would like to hear what you would want saved that is not.

How I Built a Windows Version of Ghostty in 3 Days with AI

Lugiax — Wed, 23 Sep 2026 18:41:04 +0000

Main Text

Ghostty is a terminal tool. It was made by Mitchell Hashimoto, the same person who made Vagrant and Terraform. It uses Zig language at its core. On Mac, it uses Swift. On Linux, it uses GTK. But there is no Windows version.

I made a copy (forked it), and three days later, the Windows version was running. The first change (commit) was on September 1st at 2:30 AM. I released the first version on September 4th. The Windows part has 45 files and 48,000 lines of Rust code. I did not write a single line of code myself. There were 246 changes, and Claude (an AI) helped with every single one.

This post is about what I did during those three days.

The Tool I Used Is the Thing I Am Building

First, I need to explain why I copied this project. It wasn't just to get Ghostty on Windows. I did it to build an AI CLI (command-line) manager. This means using tools like Claude Code to manage and automate coding.

The idea is simple. You pick one AI to be the "manager." This manager can see when other AI workers are stuck. It can read their screens, type for them, open new windows, and bring everyone into a group chat. There is also a task board to help them work together.

The Windows version was built using this exact system. I used my tool and AI to build the tool itself.

Getting to Work

There was one AI manager and three or four AI workers. Each worker was a separate Claude session. The manager made a group chat, broke the work into smaller tasks, and put them on the board. Then, it gave tasks to the workers one by one. My job was to set the direction, make big choices, and watch them work.

I made three rules for the AI:

1. Workers cannot touch git (the saving system). They could not commit or add files. Only the manager could do that. Why? Once, the manager told me two workers didn't have conflicting code. It heard this from one of the workers. But another worker said there was a conflict! So I changed the rule: if you change something, you just say so. The manager must check for conflicts itself by looking at the files directly.

2. Two people cannot build the code at the same time. The Zig builder deletes some files before remaking them. If someone else tries to build at the exact same time, it crashes. The first two times this happened, I wrongly thought the code was broken.

3. Do not touch programs you didn't start. This sounds obvious. But sometimes, when the AI tries to "clean up," it will close a window that you are still using!

Why I Chose Rust

I didn't let the AI choose the coding language for the outside layer (the shell). That choice changes everything.

First, I ruled out the Linux Zig code. It has 23,000 lines, which sounds helpful. But it is all GTK (a Linux window tool). The windows, tabs, and typing all use GTK. If I moved that to Windows, none of it would work.

The hardest part was actually the typing system (input method).

Windows uses a typing system called TSF, built with something called COM. C++ and C# can use it easily. But Zig does not know how to use it. If you make one tiny mistake setting it up in Zig, the whole program crashes. Typing is the hardest part of a Windows terminal. And Chinese users need it within 10 seconds of starting the app.

Mac and Linux have easy ways to connect to their typing systems. Zig handles them well. But Windows uses COM.

Rust has official tools from Microsoft that support COM perfectly. By choosing Rust, all the typing code stays in Rust. Zig never has to touch COM.

In the end, I only changed about 20 lines of Zig code. The system info was squished into a small box. I just added a line for Windows, and that was it. Rust did all the rest of the work. Plus, the Mac version already did this, so we had an answer key to look at.

Tackling the Hardest Part First

Normally, you make the window show up first. Seeing it makes you feel good. But I told the AI to fix the typing system first.

This was the only part where I couldn't guess how hard it would be just by looking. If it was ten times harder than I thought, I needed to know before writing 20,000 lines of code.

It went very well. The typing code was over 400 lines. The very first time we built it and moved it to Windows, it worked! I typed n i h a o, the word box popped up, I pressed 1, and "你好" (hello) appeared.

I still remember one line from the log file:

SetText 0..2 <- "你"

This means "Replace spaces 0 to 2 with '你'". In computer memory, this is one letter. But on the screen, it takes up two spaces. If the computer thought it was 1 space, the word box would be in the wrong place. This only happens with Chinese, Japanese, and Korean text. English would look perfectly fine. These bugs are very hard to find.

The best part is that the AI didn't just guess the number "2". It asked the core program for the real size using the correct size chart. Seeing this made me trust this way of working.

Fixing the Black Screen Bug

We had a window, and typing worked. But when we connected the core program, the screen was completely black.

It didn't crash. It was just quietly black. Everything succeeded, and the window was getting messages to "redraw," but there were zero pixels on the screen.

Later, I found a pattern. If I made a small window and then dragged it bigger, it was black. But if I started it at the final big size right away, the picture showed up.

I checked the logs and measured it:

Painted area = 1000x670      <- This was the size when the window was first made.

Even if I made the window bigger six times, this number never changed.

But the terminal itself was awake. If I typed a command in full screen to check the size, it said 143 columns and 41 rows. That perfectly matched the full screen size. The core program knew the right size.

We kept checking every step. The numbers were right at every step. Two AI workers wrote tests, and both failed. The screen was still black.

Then we tried a new way. I told the AI to stop reading logs. Instead, it took a screenshot and used a drawing tool to find exactly where the black and white met.

The line was exactly at 1000. Everything was the right size, but only a rectangle the size of the old window was being drawn on the screen.

I moved the log to the very last step, where the picture is actually put on the screen:

Target=1240x790  Image area=1240x790  Canvas=1240x790
Drawable area=(0,0,1000,670)          <- It died right here.

The first three numbers updated, but the last one was stuck at the old size.

I looked at the code and found the function that sets this area. I searched to see who used it. Zero results.

This "drawable area" was only set one time, right when the window was created. After that, no one ever updated it.

Why didn't Linux have this problem? I looked at the Linux code. GTK kindly resets this area for us every time the window gets bigger. Windows doesn't do that. It gives you a blank slate.

The worst part was that there was a note in the code about this! It said, "No one does this on a bare window." The people who read that note didn't realize it was a bug.

Looking back, starting with a big window only worked because the one-time setup matched the final size. The bug was always there; it just hid whenever the window was resized.

Don't Trust the AI When It Says "Everything is Green"

The hard part about AI coding isn't getting it to write. It's that the AI will confidently tell you "the job is done" or "all tests passed" when it isn't true.

Here are two examples:

The file didn't even compile

We added a new file. The compiler said "0 errors, 0 warnings." It looked great.

But the line of code to actually include the file never ran. A chain of commands was running, and it broke in the middle. The rest of the commands were skipped. But the screen showed a "success" code (0) from the last command that did run. The AI thought everything was fine. I only found out later when the feature didn't work.

Broken checker scripts

The AI wrote 16 test scripts. Four of them checked 0 files, printed "Everything is fine," and gave a success code.

To a computer, "I checked everything and found no problems" looks exactly the same as "I checked zero files."

I found this by making the test scripts check an empty folder. If a script still said "everything is fine," I knew it was broken.

Now, every test must check itself first. If a specific line doesn't show up, it means the test didn't run. A test that never fails is worse than no test at all.

One more rule just for Windows

Some code only runs if you are not on a Mac. When building on a Mac, the computer sees this and ignores the code. It doesn't even check it for mistakes.

So, you can't just say, "Run it on Mac to make sure it isn't broken."

The solution is to build it specifically for Windows. It might show errors for Windows, even if it looked fine on the Mac.

61 Checkpoints

All these traps share one thing: they don't yell at you when they fail. And AI is really good at making things look right. So, I forced the AI to turn every trap we found into an automatic test.

Now, there are 61 Python scripts in the windows/tools/ folder. We run all of them before saving any code. The file names are the rules themselves:

a-position-is-not-an-identity.py       (A position is not an identity)
an-async-handle-is-not-copied.py       (An async handle is not copied)
the-ui-thread-never-waits-forever.py   (The UI thread never waits forever)

Here is why the first rule exists: Tabs and screen splits need permanent ID numbers. You can't just use their place in line (like "number 2"). Because tabs move around or close, "number 2" might silently become a different tab. It wouldn't crash, and it wouldn't leave a trace.

One habit was even better than the code itself. In our status notes, we never mix up two phrases:

Landed means the code is written, it builds, and the tests passed.
Verified means we actually tested it on a real computer and have real numbers to prove it works.

If we don't have real numbers, we can't write "verified," even if we are sure it works.

Also: If a note doesn't say "tested," we assume it is NOT tested. We had to do it this way. Otherwise, people would assume that anything left blank was already tested.

Testing on a Real Machine

I couldn't test the Windows version on my Mac. I put a Windows computer next to me and controlled it from my Mac.

The AI logged in, installed packages, started the app, took screenshots, and read logs. I mostly just watched. But there were traps here, too.

The remote control tool types differently. It skips the normal typing system and forces the letters in. If you use it to test Chinese typing, you will think the typing system is broken. But if you send real keyboard presses, the word box pops up instantly.

The hardest part was making sure the window was in the front before pressing keys. Sometimes Windows quietly stops a window from coming to the front. The test wouldn't crash; it would just press keys into the wrong window. In the logs, "keys didn't send," "keys went to the wrong place," and "the feature is broken" all looked exactly the same.

Later, I made a hard rule: Before sending a keystroke, the test must "click the tested window." It cannot just use a command to "bring window to front."

We tested the group chat feature using the group chat itself! I used a small local AI model as the manager on the test machine. It had three workers. They did a small project in an empty folder. They made files, opened terminals, made a chat, did the work, handed it in, and saved it. All five steps worked. The best part was watching the AI fix its own problem: when it was blocked by a password, it found out who it was, got permission, and tried again successfully.

Three Days Later

I released the first version on September 4th. Then, I spent a little over a week making it smoother. I gave it to testers on September 8th, and froze the code on September 9th. We really only wrote features for three days. The rest of the time was testing and cleaning up.

The core program has 72 actions. On Windows, we finished 63. I skipped 7 on purpose. There are 2 left to do: making the background see-through, and a quit timer.

The display part of the terminal wasn't copied or translated. It is the exact same Zig core. On Windows, I just gave it a window to live in. I only built the outside shell.

Final Thoughts

We built this in three days, but not because one AI wrote code really fast. It was because four AIs worked together the whole time. One worked on typing, one on tabs and splits, one fixed the black screen, and one added menus. That is how we got 139 updates so fast.

Doing things at the same time is easy. The hard part is one human managing lots of AIs. You have to check: Who needs permission? Who finished 20 minutes ago and is just sitting there? Who needs you to check their design? I used to have to check everyone one by one. It broke my day into tiny pieces, and I couldn't get my own work done.

So, my idea was to give this manager job to another AI. The manager AI watches the screens of the worker AIs. It sees who stopped, who needs permission, and who needs a new task. I just talk to the manager at the beginning to plan things. After that, I leave them alone.

The group chat and task board aren't just for show. If the computer restarts or we clear the memory, they can start again the next day because the tasks are still on the board.

What did I do for three days? I set the direction, made the rules, planned with the manager, and checked the final work.

When working with AI, the hard work isn't getting it to write code. The hard work is building a test system so the AI can't trick you, and can't trick itself. The 61 checkpoints and the "assume it's untested" rule were all made for this.

Ghostty is a great terminal, and that is all thanks to the original creator. I only added the Windows part. This is not a rewrite. When the original Ghostty updates, this will update too. It uses the MIT license, just like the original.

https://github.com/Lugia123/polter

The Windows version is still very new. You can see what is tested and what isn't in dev-docs/windows/status.md.
If you find a problem, please open an issue in my repository. Do not send issues to the main Ghostty repository!

I built a terminal where one AI CLI supervises the others, so overnight runs actually finish

Lugiax — Tue, 15 Sep 2026 17:28:24 +0000

Problem: I run several AI CLIs at once (Claude Code, Codex, Qwen). Two things kept breaking overnight runs: an agent quits after an hour (network error, or it just decides it's done), and sub-agents fudge their reports when they hand work back. The existing tools let me see many agents. None of them made one agent responsible for the others.

What Polter does: it's a Ghostty fork with an MCP layer. Any MCP-capable CLI can be the supervisor. It opens tabs, starts other CLIs, types into them, reads their screens. Workers report into a group chat and a shared task list. If a worker's screen goes quiet, the supervisor is told. If the supervisor goes quiet, Polter pokes it.

Here's what that actually looks like:

https://www.youtube.com/watch?v=_u-pgdNeqCc

How it compares (from each project's README/docs, Sept 2026 — correct me if I got something wrong):

	Polter	Claude Code Agent View	cmux	herdr	Claude Squad
Works with any CLI (Codex, Qwen, opencode…)	Yes	No, Claude Code sessions only	Yes	Yes	Claude Code, Codex, Gemini, Aider
Agents can drive the terminal (read screen, type, open tabs)	Yes, via MCP	No	Yes, via CLI + socket	Yes, via socket	No
One agent supervises others (roles, task list, group chat)	Built in	No (you supervise)	You build it on the API	You build it on the API	No
Stopped worker → someone is notified	Supervisor agent is told; it can restart	You are notified; unexpected exits auto-restart	You are notified	You are notified (state in sidebar)	Not mentioned
Supervisor itself gets nudged if idle	Yes	No	No	No	No
Needs API keys	No, uses your CLIs' own login	No	No	No	No
Platform	macOS, Windows (63/72 actions), Linux from source	Wherever Claude Code runs	macOS only	macOS, Linux, Windows beta	macOS, Linux
Offline / no account	Yes	—	Yes	Yes	Yes

Honest gaps: only Claude Code is tested end-to-end as supervisor. Codex/Qwen/opencode work fine as workers; their supervisor path is untested. Windows is missing 9 actions. It's a fork, so upstream Ghostty updates get merged with some lag.

What Polter won't do: answer permission prompts for an agent, unlock a tab you've locked, or bypass a CLI's own permissions. Those are hard-coded, not prompts.

MIT licensed: https://github.com/Lugia123/polter