DEV Community: Chris Olson

Give the agent the harder job

Chris Olson — Thu, 09 Jul 2026 04:19:17 +0000

The cost of asking an agent to attempt something has collapsed. Most people still scope their asks to what they already believe is possible — that is the mistake.

The case

The fastest way to find the edge of an agentic tool is to ask it for something you are fairly sure it cannot do. Not as a stunt — as a habit. The cost of the experiment used to be an afternoon. Now it is a sentence. When the downside of a failed attempt is thirty seconds and a re-prompt, the rational move is to attempt far more than feels reasonable. Most people do the opposite. They scope every request down to what they already believe the tool can handle, and then they conclude the tool can only do what they believed.

This essay is about the gap between the two. It is the most expensive habit I have had to unlearn while building with these tools, and unlearning it is where the actual leverage turned out to be.

The messy job is the job

The well-specified task is the one you didn't need an agent for. "Rename this symbol across the repo," "write a test for this function" — these are fine, and the tool does them, and you save a few minutes. The work that compounds is the work you can barely specify yourself.

I redesigned my site recently and asked the agent to "QA the redesign" before I shipped it. I did not tell it how. I expected a list of things to click through manually. Instead it stood up a headless browser, opened a debugging port, navigated to the interactive work index, and started dispatching synthetic clicks at the category filter — driving the real compiled page the way a user would. Within a few iterations it reported that the filter pills lit up correctly but the rows never actually filtered. The count label was frozen. It was a real bug, and it had already shipped.

I never asked for a browser. I asked for QA. The browser was its idea about what QA means when the thing under test is an interactive page. That distance — between the instruction and the interpretation — is where the value lives. A precise instruction gets you a precise result. An ambiguous one, given to a capable agent, gets you the result plus the approach you didn't know to ask for.

Tools it has that you didn't ask for

The filter bug is a good story because of what catching it required, which is more than "open a browser." The agent had to drive the page, observe that the DOM didn't change, and then cross a boundary most humans avoid: down into the WebAssembly island that owned the filtering, and the JavaScript bridge that fed it props.

The root cause was buried there. The page handed its island props as a hand-rolled JSON string; the framework expected a binary codec, base64-encoded, that the bridge decodes with atob before the WASM ever sees it. atob on a raw { throws, the error gets swallowed, the island hydrates with zero rows, and the filter has nothing to filter. The pills toggled because their state was static and didn't depend on the props at all.

// the bug: props as raw JSON — atob() rejects it, island hydrates empty const props = try buildJsonString(projects); // the fix: the framework's binary props codec → base64 const props = try verve.encodeProps(ctx, .{ .slugs = slugs, .cats = cats });
That is four distinct capabilities composed in service of one vague request: run a browser, simulate input, inspect a reactive DOM, and read across the WASM/JS boundary to a serialization mismatch. I would not have thought to ask for any single one of them. I would have written "check that the filter works" and accepted a screenshot. The creativity was not in my prompt. It was in the framing — verify this actually behaves — and the agent supplied the method.

This is the part that does not fit the autocomplete mental model people still carry. The tool is not finishing your sentence. Given enough room, it is choosing a strategy.

The work you didn't have time for

There is a second payoff, quieter than the first. Every codebase has a backlog of work that is obviously worth doing and never quite worth a human afternoon. The dead-code audit. The exhaustive edge-case sweep. The asset that should be generated instead of hand-drawn. These items live forever in a file called TODO because the value is real but sub-threshold for a person.

That threshold just moved. While cleaning up the same redesign I asked for an audit of unused CSS. The agent found ten candidate classes — and then, before deleting any of them, checked whether the were still in use, caught that six of the ten were live, and deleted only the four that were actually dead. That is the correct, careful version of a chore I would have done sloppily at midnight, if at all.

The 3D artifact on the site is the same story from the other direction. I wanted a piece of generated geometry and an image-based lighting environment baked at build time. That is a real graphics task, the kind that historically eats a weekend you don't have. It became a build step. Not because the work got easier in some abstract sense — because the unit of effort it cost me dropped to "describe what you want and review what comes back."

The backlog is not a backlog anymore. It is a queue, and the queue moves.

Be wrong about the ceiling

Here is the uncomfortable part. Your belief about what the tool cannot do has a shelf life measured in weeks, and you are almost certainly still operating on a stale one. The thing it couldn't do last quarter it can do now, and you will never find out if your prompts are calibrated to last quarter's ceiling.

The only reliable way I have found to stay current is to keep asking for the thing I assume will fail. Most of the time it does, and I have lost a sentence. Sometimes it doesn't, and I have learned that an entire category of work moved inside the boundary while I wasn't looking. The expected value of that bet is lopsided in a way that should change your behavior, and for most people it hasn't yet.

Fearlessness here is not recklessness. It is refusing to pre-decide the outcome. You do not get to know the ceiling by reasoning about it. You find it by pushing on it, and it has a habit of not being where you left it.

Verify like you mean it

The counterweight, because exploration without it is malpractice: the filter bug shipped in the first place because someone — a previous version of this same loop — explored creatively and did not verify. The redesign rendered, the SSR looked right, the markup was correct, and the thing was broken in a way no static check would catch. Creativity got the feature built. Only adversarial verification caught that it didn't work.

So the habit is not "ask for big things and trust the output." It is "ask for big things and then make the agent prove them." Drive the real page. Run the real binary. Diff the actual behavior against the claim. The same tool that will invent a browser-automation strategy to please you will also, asked the wrong way, assure you something works when it doesn't. The exploration and the skepticism are two halves of one practice. Run them together or you are just generating plausible mistakes faster.

The Paradigm Shift

The bottleneck has moved. For a long time the limiting factor on what got built was hours — yours, your team's — and so the discipline was about spending them well. That discipline is now aimed at the wrong constraint. The hours are cheap. What is scarce is the imagination to ask for the harder thing, and the rigor to confirm you actually got it.

Give the agent the job you think is too big. Give it the chore you were never going to do. Frame the ambiguous version, not the safe one, and then verify the result like you expect it to be wrong. The downside is a wasted sentence. The upside is finding out that the work you had quietly written off as impossible, or simply not worth your time, was neither.

Why I Built Verve: Crafting a Pure-Zig, Full-Stack Alternative to Tauri and Wails

Chris Olson — Tue, 07 Jul 2026 05:49:47 +0000

If you’ve ever built a desktop or modern full-stack web app using frameworks like Tauri or Wails, you know how brilliant the webview architecture is. Combining a lightweight OS webview with a fast backend language like Rust or Go beats shipping a bloated 150MB Electron runtime any day.

I love these tools and still build applications with them. But as an engineer, I started wondering what it would look like if we pushed the boundaries a step further. What if we could completely eliminate the multi-language context switch, throw away the heavy Node build toolchains, and build everything inside a single, unified systems language?

Enter Zig (and a wild idea)

Over the past six months, I’ve been diving deep into Zig. Coming from a background with plenty of Go, I completely fell in love with Zig's philosophy: extreme simplicity, no hidden control flow, no macros, a "standard library first" mindset, and a powerful build system that replaces messy Makefiles and CMake entirely.

With the recent async/IO overhauls in Zig 0.16.0 (std.io updates and native io_uring support), it felt like the absolute perfect time to see just how far the envelope could be pushed.

I looked at the current ecosystem and realized something was missing: A pure, unified, single-language framework for both web and desktop apps.

So, I decided to go on a bit of an adventure and build it. I call it Verve.

What exactly is Verve?

Verve is a full-stack, pure-Zig framework for building high-performance web and native desktop applications.

If you want to see the architecture in action right now, you can dive straight into the Official Documentation at verveframework.dev!

There is no Node.js toolchain, no virtual DOM, and no macros. Everything compiles down into a single, highly optimized binary. You run zig build, and you get your server or your native desktop application. Simple as that.

Here is a quick look at the architectural choices powering the project:

1. Unified Language, Unified Codebase

Instead of splitting your brain between Go/Rust for the backend and TS/JS for the frontend, your entire application UI and logic is written in pure Zig.

Web: The server renders HTML via native Zig functions.
Client Interactivity: Interactive components are written in Zig and compiled directly to WASM chunks using Zig's native WebAssembly compilation target.

2. Islands Architecture & Fine-Grained Reactivity

Verve takes inspiration from modern web frameworks but implements them natively. Pages are Server-Side Rendered (SSR) first, meaning every page is fully formed HTML that functions perfectly even if JavaScript is entirely disabled.

When you need interactivity, you opt into an Island:

The build system automatically code-splits every island into its own separate WebAssembly (.wasm) chunk.
Chunks are lazy-loaded on-demand and hydrated with typed properties.
It uses a fine-grained reactive graph (Signals and Effects) shared seamlessly between the server and the WASM client. Updates touch exactly the DOM nodes that change—no heavy Virtual DOM diffing required.

// A simple reactive route in Verve
const verve = @import("verve");

pub const routes: []const verve.Route = &.{
    verve.Route.init("/", renderHome),
    verve.Route.init("/hello/:name", renderHello),
};

fn renderHello(ctx: *verve.Context) !*verve.Node {
    const name = ctx.param("name") orelse "world";

    return ctx.div().class("card").children(.{
        ctx.h1("Hello"),
        ctx.p().children(.{
            ctx.span().text("Greetings, "),
            ctx.code(name),
        }),
    }).build();
}

3. Native Desktop

For desktop applications, Verve embeds the OS’s native webview window (WKWebView on macOS, WebView2 on Windows, and WebKitGTK on Linux).

Unlike other webview solutions, Verve sets up a highly secure verve://app/ asset scheme. Assets are embedded directly inside the binary as an AssetEntry table at compile time. Frontend modules communicate with your Zig backend through a deeply typed IPC bridge with strict compile-time route generation. No open local ports, no localhost footprint.

4. Zero JavaScript Toolchain (Yes, Really)

One of my primary goals was to completely strip away the complex web infrastructure. Because Zig's build system is incredibly robust, it acts as your compiler, linker, asset packager, and WASM orchestrator all at once. You don’t need npm, bun, vite, or esbuild.

Now, to be totally fair, browsers don't speak native Zig—so there is a tiny piece of JavaScript glue involved under the hood called verve.js. But here's the magic: you don't install it, build it, or manage it. The framework automatically serves it as a minimal, lightweight bridge at /verve.js. It handles mounting your compiled WASM islands, passing typed properties, and letting the client runtime talk back to your backend.

You just run zig build, and the framework orchestrates the entire puzzle for you.

Moving Beyond Tauri and Wails

Don't get me wrong: I still build applications using both Tauri and Wails, and they are phenomenal projects that paved the way for lightweight desktop apps. But I wanted to see what else could be built if we wiped the slate clean.

Verve shifts the paradigm in a few key ways:

Instant Compile & Dev Loops: Zig compiles incredibly fast compared to heavy macro-centric Rust code. With dev_assets configured, you can edit your frontend markup and live-reload instantly without rebuilding the binary backend.
Single Mental Model: You don't have to think about data-serialization boundaries between Go/Rust types and TypeScript interfaces. Everything uses native Zig structs. Comptime-generated, typed client stubs handle data transfers natively.
Batteries Included (Natively): Verve isn't just a webview router. It includes full server-side visualization capabilities (verve.viz renders everything from force-directed layouts to complex charts directly to server-side SVG), a declarative tween/timeline animation engine, and hardware-accelerated WebGL2/WebGPU 3D scenes out of the box.

The Journey So Far

Learning Zig over the last half-year has completely changed how I think about systems programming. Coming from Go, I missed the simplicity when dealing with complex Rust syntax or C-bindings. Zig gives you that exact same readability and predictability, but with absolute control over memory management and allocators (using explicit arenas per request context to completely eliminate leaks).

Verve is the result of taking that systems-level power and applying it directly to application developer productivity.

Now, I wish I could take all the credit and claim I built this entirely solo, but I have to give a massive shoutout to my friend Claude Code for the major assist along the way! 🤖

Give it a spin!

If you want to escape the massive Node ecosystem, skip the multi-minute compile times, and write lightning-fast full-stack web or desktop apps using a beautiful, modern language, come join the adventure.

Getting started is as simple as cloning the repo and executing your native toolchain:

git clone https://github.com/sirhco/verve
cd verve
zig build

I’d love to hear your thoughts, feedback, or any issues you encounter as you play around with it! Check out the GitHub repository, drop a star if you like the direction, and let me know what you think in the comments below!