DEV Community: Nico Acosta

Your background agent needs somewhere to pick up the task and file the result

Nico Acosta — Mon, 27 Jul 2026 13:17:51 +0000

A background agent is an autonomous coding agent that works a task on its own, off your machine, and hands back finished work. You give it a prompt or a ticket, it clones the repo in its own sandbox, writes the code, runs the tests, and surfaces a pull request for you to review. Cursor, Devin, OpenAI's Codex cloud, Ona, and a growing pile of open-source runners all do a version of this. The pitch is the same everywhere: kick it off, walk away, come back to a diff.

Almost everything written about background agents is about the middle of that loop, the part where the agent runs. This post is about the two ends, because that is where the actual friction is. A background agent is defined by two touch-points that have nothing to do with the model: it picks up a task, and it files the result. Both of those are reads and writes against a record. If that record is slow, private to one machine, or invisible to the other agents you are running, the fancy autonomous middle does not help you.

The loop is: pick up a task, do the work, file the result

Strip a background agent down and the shape is boring, which is the point.

Pick up. The agent needs to know what to work on. Somebody, or some other agent, put a task somewhere: an issue in a backlog, a ticket, a line in a queue. The agent reads it.
Do the work. This is the part the vendors compete on: the sandbox, the toolchain, the model, the test loop. It is genuinely hard and genuinely theirs.
File the result. The agent finished. Now what? It closes the task, links the branch or PR it opened, and often files the next task it discovered while working. If it does not write that back somewhere durable, the run evaporates the moment the session ends.

Steps 1 and 3 are tracker operations. The agent is reading its queue and writing its outcome. That is a system-of-record job, and it is the job most "background agent" setups leave undefined, which is why people end up wiring the agent straight into GitHub's API and then discovering it does not scale.

Where it breaks: one agent is fine, several is not

Run a single background agent against a single repo and you can get away with almost anything. Point it at GitHub Issues, let it poll, let it comment. It works because there is one reader and one writer.

The moment you run more than one, the record becomes the bottleneck. A developer on r/github described exactly this after building their own layer:

"The polling problem bites hard once you have more than one agent checking issue state at the same time."

Their fix was to stop letting the agents touch GitHub directly and put a single fast API in front of the issue lifecycle, so the agents read and write local state instead of hammering a remote API each. That instinct is right. When several agents are picking up tasks and filing results at once, they need one shared record that is fast to read, safe to write concurrently, and the same list for every agent and every human. A file in one clone is invisible to the other runners. A GitHub issue is a network round-trip and a rate limit away.

The record Radial is

Radial is a hosted issue tracker built to be the two ends of that loop. It is not the runner. It does not spin up a sandbox, launch your agent, or fire a webhook to trigger one. It is the fast, shared place the task lives before the agent picks it up and the place the result lands after. You bring the agent; Radial holds the record.

Here is the file-the-task side, from a human or a script queuing work for a background agent to grab:

radial create "Fix the flaky login test" -t ENG -p high --json

That returns the created issue as JSON, including its key (ENG-142) and URL, so whatever queued it can hand the agent an exact task id. On the other end, when the background agent finishes, it drives the same tracker over the CLI, the REST API, or the MCP server: it reads its queue, closes the issue it just finished, and with Radial's Git integrations connected, the branch and pull request it opened link straight back to that issue. If it found a second bug on the way, it files that as a new issue before it exits, so the next agent, or the next you, picks it up instead of losing it.

The point is that both ends are the same record, reachable the same way whether a person clicks a board or an agent calls search_issues and close_issue over MCP against mcp.radial.build. One canonical list. Fast reads for the pickup, safe concurrent writes for the filing, legible history for the human who reviews the PR later. That is the tracker your agents can actually drive, aimed specifically at the delegate-and-return loop.

Where the line is

One honest note, because it is the whole product. Radial is the record, not the intelligence and not the orchestration. It does not run your agent, host it, schedule it, or emit an event to kick one off. There is no copilot inside the tracker, no AI summaries, no auto-triage, and no AI credit meter, because your agent already does the thinking and you already pay for it once.

That is also why more agents never cost more. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat. You pay $50 per user, per year, flat, billed annually, for the humans on the workspace, locked at the rate you join. Run one background agent against the record or ten in parallel and the price does not move. The Plain Software Pledge is the binding version: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free.

FAQ

What are background agents?

Background agents are autonomous coding agents that pick up a task and work it on their own, off your local machine, usually in an isolated cloud sandbox with your repo and toolchain. You hand one a prompt or a ticket, it clones the repo, writes and tests the code, and returns finished work like a pull request for you to review, without tying up your editor. Cursor, Devin, Codex cloud, and Ona are common examples.

What are background agents good for?

They are good for well-scoped, verifiable tasks you can describe once and check later: fixing a flagged bug, adding test coverage, a mechanical refactor, or clearing routine backlog items. The pattern shines when the work is defined enough that the agent can run without hand-holding and the result is a diff you review. It works best when each task lives as a clear record the agent reads from and files back to, so you are reviewing outcomes, not babysitting the run.

Where should a background agent read its tasks from?

From a shared, hosted record that is fast to read and safe for multiple agents to write at once, not a file in one clone and not GitHub's issue API under polling load. A background agent's whole loop is read a task, do the work, write the result, so the record is load-bearing. Radial is built for that: the agent reads its queue and files results over the CLI, REST API, or MCP, and the same list is visible to every other agent and human on the workspace.

Does running more background agents against Radial cost more?

No. Agent credentials are clients of the API, not billed seats. You pay $50 per user, per year, for the humans on the workspace, and that number is locked at the rate you join. Connect one background agent or run ten in parallel and the price is the same. There is no AI credit meter anywhere in the product.

Does Radial run or trigger the agent?

No. Radial is the record, not the runner. It does not spin up sandboxes, launch or schedule your agent, or fire webhooks to trigger one. It holds the task the agent picks up and the result the agent files. You bring your own agent and run it wherever you already run it; Radial is the fast, shared place its work lives.

The short version

A background agent's job has two ends that are not about the model at all: it picks up a task, and it files a result. Both are reads and writes against a record, and that record has to be hosted, fast, and shared the moment you run more than one agent. Radial is that record, not the runner. Bring your agent, point it at the list, and let it read its work and write its outcome to the same place your team already sees.

Wire your agent up on the developers page, or read the Claude Code MCP walkthrough to connect one in about five minutes.

Originally published on the Radial blog.

How to Capture a Webpage Screenshot Programmatically (URL to Image via API)

Nico Acosta — Mon, 27 Jul 2026 11:43:30 +0000

To capture a webpage screenshot from your code, send the page URL to a screenshot API and it returns a hosted image. One HTTP request in, one image URL out. The headless browser that renders the page runs in the cloud, so there is no Chromium to install and no browser process to keep alive.

That is the fast path. Below are the ways to capture a webpage, when each one fits, and how to get the full-page, format, and timing options right.

The quick answer

If you just want a URL captured as an image from your code, this is the whole thing:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "height": 720,
    "format": "webp"
  }'

The response is JSON with a hosted image_url:

{
  "id": "grb_01jx...",
  "status": "done",
  "target_url": "https://example.com",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "height": 720,
  "format": "webp",
  "bytes": 62140,
  "execution_ms": 940,
  "created_at": "2026-07-27T09:00:00.000Z"
}

Store that image_url, embed it, or hand it to another service. The rest of this guide is about picking the right method and getting the capture right.

Manual versus programmatic capture

"Capture a webpage screenshot" splits into two different jobs, and the right tool depends on which one you have.

Manual, one page. You are looking at a page and want to save it. Your browser already does this. In Chrome or Edge, open the command menu with Ctrl+Shift+P (Cmd+Shift+P on Mac), type "screenshot," and choose "Capture full size screenshot" for the whole page. Edge has a dedicated shortcut: Ctrl+Shift+S, then "Capture full page." An extension like GoFullPage does the same through a toolbar button. For one page you are looking at right now, use one of these and move on.

Programmatic, repeatable. You need to capture pages from code, on a schedule, or across many URLs. The manual path falls apart here: you cannot click a browser menu inside a cron job, a CI pipeline, or a webhook handler. You need an endpoint you can call. That is the rest of this guide.

Capturing a webpage with an API

For anything repeatable, a screenshot API is the shortest path. You already saw the curl call. Here is the same capture in a few languages, since "how do I do this in my stack" is the real question.

Python, using requests:

import requests

resp = requests.post(
    "https://api.grabbit.live/v1/grabs",
    headers={"Authorization": "Bearer sk_live_..."},
    json={
        "url": "https://example.com",
        "width": 1280,
        "height": 720,
        "format": "webp",
    },
)
data = resp.json()
print(data["image_url"])

Node.js, using the built-in fetch:

const resp = await fetch('https://api.grabbit.live/v1/grabs', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://example.com',
    width: 1280,
    height: 720,
    format: 'webp',
  }),
});
const data = await resp.json();
console.log(data.image_url);

Every one of these is a plain HTTP call. No chromedriver, no 300 MB Chromium download, no async browser session to tear down. That is the whole reason to reach for an API over a local capture: the rendering machinery lives somewhere else.

Capturing the full page, not just the viewport

By default a capture stops at the viewport height you request. To grab the entire scrollable page as one tall image, set full_page to true:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

With full_page on, height is ignored and the render extends to the bottom of the document. This is the "scrolling screenshot" people ask for: everything below the fold, in one image. width must be between 320 and 1920 pixels; height, when you use it, between 240 and 1080.

Handling pages that load content late

The reason a real browser beats a raw-HTML fetch is that it runs JavaScript. Single-page apps, lazy-loaded images, and content that appears a beat after load all render the way they do for a visitor, because the capture happens in headless Chromium, not an HTML parser.

Two options control the timing:

delay_ms waits a fixed number of milliseconds (0 to 10000) after load before firing the capture. Use it when content animates or streams in.
selector waits for a specific element to appear and captures once it does. Use it when you know the exact node that signals "the page is ready."

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/dashboard",
    "width": 1440,
    "height": 900,
    "delay_ms": 1500,
    "format": "png"
  }'

This is also why an API can capture pages where a browser extension fails. A page can break extension-based capture with its layout, but a server that loads the URL like a normal visitor still gets a clean render of what the browser paints.

Choosing PNG, JPEG, or WebP

The format field takes png, jpeg, or webp, and picking wrong means either bloated files or lost quality.

WebP is the best default. For a typical webpage render it produces the smallest file at the same visual quality, which adds up fast when you store and serve thousands of captures. Use it unless you have a reason not to.
PNG is lossless and supports transparency. Reach for it when exact pixel fidelity matters, for example a baseline image in a visual regression test.
JPEG is the safest bet for older tooling that predates WebP. It is lossy, so text edges soften slightly.

Switching format is a one-word change in the request body, so you can experiment without rewriting anything.

When a local capture is the better call

An API is not always the answer. Capture locally instead when:

You are doing a single manual capture. Use the browser shortcut from earlier.
You already have the HTML, not a URL. If the markup lives in your app and is never served at an address, a local render avoids a round trip. See HTML to image for that pattern, including hosting your template at a URL and capturing it.
You cannot make outbound requests. In an air-gapped environment an API is off the table, so a bundled headless browser is the only option.

For everything else, especially anything on a schedule or in CI, the API path keeps your deployment small and removes a whole class of "it works locally but not in the container" failures.

Pricing is worth a word here because it is where these tools differ most. Grabbit charges a flat $0.002 per live capture as prepaid credits that never reset or expire monthly, so a batch that runs once a quarter does not forfeit an unused monthly allowance. That is different from the metered monthly quotas most screenshot tools bill on.

Next steps

The screenshot API covers the full parameter set, authentication, and rate limits. If you are wiring this into a job, the screenshot from a URL guide walks the request end to end, screenshot automation covers running captures on a schedule without a browser, and screenshot a list of URLs handles capturing many pages at once.

Originally published on the Grabbit blog.

The AI Coding Workflow That Ships One Feature: Idea to Merged PR

Nico Acosta — Mon, 27 Jul 2026 11:13:59 +0000

Last week someone on r/codex asked a question that has no business being asked anymore: "How do you use Codex like a professional AI builder?" The tools are a year past magic. The models are good enough that "build me a login page" produces a login page. And yet the most upvoted answer was not a clever prompt or a secret setting. It was a workflow, hand-assembled by someone who had clearly been burned: write a spec first, break it into a phased plan, give each phase a definition of done, plan before you code, then review the diffs like a lead engineer.

Read that again. The top answer to "how do the pros use this AI tool" was not about the AI tool at all. It was a process for working around it. The fastest path to shipping something real with an agent turns out to be the part of software development that has nothing to do with the agent. That is the contradiction this whole piece rests on, and it is the most useful thing you can learn this year: the AI coding workflow that actually ships is mostly the workflow you build around the AI.

The workflow everyone keeps reinventing

Spend an hour reading how working builders describe their setup and you notice they have all converged on the same shape without coordinating. Addy Osmani's LLM coding workflow going into 2026 describes a virtuous cycle where the AI writes code, automated tools catch issues, and the AI fixes them. The most-shared System Design newsletter version lists five steps and the second one is literally "Plan Before You Code." The dev.to post that keeps circulating is titled, with no irony, "Separate Planning From Execution." Different people, different tools, same skeleton.

Here is that skeleton, the one a thousand builders are rebuilding by hand in a thousand slightly different ways:

flowchart LR
  A[Idea] --> B[Spec: what done means]
  B --> C[Plan: slice into phases]
  C --> D[Build: agent writes the code]
  D --> E[Verify: check against the spec]
  E -->|passes| F[Merged PR]
  E -->|fails| D

The shape is not the interesting part. The interesting part is which step does the work. Most people assume the agent, the "Build" box, is where the magic lives, because that is the box that got a thousand times better. They are wrong, and you can prove it to yourself. Take a strong agent and give it a vague idea. You get a confident, plausible, wrong result. Now take a mediocre agent and give it a precise spec with a clear definition of done. You get something you can actually ship. The power is not in the model. It is in the box labeled "what done means," and that box is the one no tool writes for you.

One feature, start to finish

Abstractions are easy to nod along to and useless when you sit down to build. So walk one real feature through the loop: a password reset flow, the kind of thing every app needs and nobody wants to write.

The amateur version is one sentence. "Add password reset." You paste it into your agent, watch it generate four hundred lines across six files, see a form appear in the preview, and merge it because it looked done. Three days later a user emails that the reset link works twice, or never expires, or silently fails for anyone with a plus sign in their email. The demo worked. The feature did not. You shipped the gap.

Now the version the r/codex commenter was describing. Before any code, you write down what done actually means, in conditions a person can check:

The user requests a reset by email. A one-time link is sent that expires in 30 minutes and works exactly once. An invalid or expired link shows a clear error, not a crash. After a successful reset, all existing sessions are logged out. An unknown email address returns the same neutral confirmation as a known one, so the form cannot be used to discover who has an account.

That is five testable conditions, and notice what just happened. You did not write code. You did not need to. But you now have something the one-sentence version never had: a definition of done that exists outside your head, that the agent can build against, and that you can check the result against later even though you cannot read a line of the code that produced it. The spec is the deliverable. The code is downstream of it.

From there the rest of the loop has somewhere to stand. You slice the work into phases, send the agent off to build, and when the pull request comes back you do not stare at the diff feeling unqualified. You walk your five conditions. Request a reset, click the link twice, watch the second click fail. Wait thirty-one minutes, confirm the link is dead. Enter an email that does not exist, confirm the message gives nothing away. You are reviewing behavior against a checklist you wrote, which is exactly the kind of review a non-engineer is qualified to do. We went deep on that skill in reviewing a pull request when you cannot read code; the point here is that the checklist is what makes the review possible at all.

Why the spec is the workflow

There is a backlash worth taking seriously. A sharp comment on a recent Hacker News thread called the whole agentic-workflow paradigm "a narrative trend pushed by AI companies to get people to 10x their token consumption." That critic is half right, and the half they are right about is the half that matters. A loop with no definition of done is exactly what they describe: an expensive way to keep rolling the dice. You prompt, the agent generates, you squint, you do not like it, you prompt again, and every turn burns credits while you converge on nothing, because there is nothing for the loop to converge toward.

The thing that turns that slot machine into a workflow is the one ingredient the skeptics never mention. Not a better model. Not more autonomy. A spec the output can be measured against. With it, every loop iteration has a target and a stopping condition: done is when the evidence matches the spec. Without it, "done" is whenever you get tired of pulling the lever. The definition of done is not a nice-to-have step in the workflow. It is the workflow. Everything else is plumbing.

This is also why the workflow does not get easier as the models get better, which is the part that surprises people. A more capable agent makes more decisions per turn, and every decision you did not write down is one it makes for you, silently, in a direction you will discover later. The more the agent can do on its own, the more the written spec is the only thing standing between its speed and your weekend. The hard part moves toward planning, not away from it.

Where this stops being a hand-rolled process

You can run this entire loop yourself with sticky notes and discipline, and many good builders do. But look at what you are actually maintaining by hand: a definition of done for every feature, a way to slice it into buildable phases, a record of which conditions were checked and which were not, and a memory of what this product is supposed to do that survives from one session to the next. That is real work, and it is the same work whether you are one person or a team of fifty. The reason it keeps getting reinvented in Reddit comments is that nobody ships it as a product.

That is the gap BrainGrid sits in. You describe the feature in plain language, and the Planning Agent turns it into a requirement with explicit acceptance criteria, asking the clarifying questions you did not think to answer, the kind that catch the expired-link and plus-sign-email cases before any code exists. The Builder Agent then builds against that spec, either in a managed cloud sandbox with a live preview or in your own GitHub repo with Claude Code, Cursor, or Codex. When it is done, verification checks the result against every acceptance criterion, so the pull request arrives with evidence attached instead of a diff you have to decode. That is the full loop, Plan, Build, Verify, Repeat, and the part that does the work, the captured definition of done, is the part the product remembers so you do not have to rebuild it every project. We cover the planning half in depth in building the BrainGrid way, and the spec craft itself in how to write acceptance criteria an AI agent can verify.

The honest limit: a spec does not write itself, and a bad one ships a bad feature with full confidence. If you write down the wrong conditions, the agent will satisfy them perfectly and you will have built the wrong thing precisely. The workflow does not remove your judgment about what good looks like. It just makes sure that judgment gets recorded once, up front, where it can actually steer the build, instead of living as a fuzzy feeling you compare the result against at the merge button.

So the next time you catch yourself asking how the pros use the latest agent, remember what the pros actually answered. They did not share a prompt. They shared a workflow, and the center of it was the least glamorous step there is. Write down what done means before you build. The agent got fast. Deciding what it is allowed to call finished is still your job, and it is the only job that ships.

FAQ

What is an AI coding workflow?

An AI coding workflow is the repeatable process you wrap around an AI agent to turn an idea into shipped software, rather than just prompting an agent and hoping. In practice it has converged on a consistent shape: write a spec that defines what "done" means, slice the work into phases, let the agent build against the spec, then verify the result against your original conditions before merging. The agent handles the code generation; the workflow handles everything that makes the code generation aim at the right target. The most common mistake is treating the prompt as the workflow when the spec is the part that actually does the work.

How do I set up an AI coding workflow?

Start with the step everyone skips: before any code, write down what done looks like as a short list of conditions a person can check, not as a one-line prompt. Then break the feature into phases small enough to review one at a time, send each to your agent, and when it returns, walk your conditions against the running result instead of reading the diff. Keep a record of what this product is supposed to do so each new session does not start from zero. You can do this manually with notes and discipline, or use a tool that captures the spec, runs the build against it, and verifies the result for you.

Is planning really necessary if the AI model is good enough?

Yes, and counterintuitively it matters more as models improve, not less. A more capable agent makes more decisions per turn, and every decision you did not specify is one it makes on its own, in a direction you discover after the fact. A strong model with a vague request produces a confident, plausible, wrong result; a modest model with a precise definition of done produces something you can ship. The work that decides the outcome is in the spec, because that is the only thing the agent's speed has to aim at. Skipping planning is how a loop becomes an expensive way to keep rolling the dice.

How do I review an AI pull request if I can't read code?

Review the behavior, not the syntax. Read the summary and confirm the scope matches what you asked for, then open the preview and walk through your acceptance criteria the way a real user would, including the failure cases like expired links, wrong inputs, and empty forms. Notice how many files changed and be more cautious of a sprawling change than a small one. Approve only when the running feature satisfies every condition you wrote up front. This works precisely because you defined done before the build, so the review is checking a list instead of guessing against a fuzzy memory.

What's the difference between vibe coding and an AI coding workflow?

Vibe coding is prompt, generate, eyeball, repeat, with no written definition of done and nothing to verify against, which is great for prototypes and a fast way to ship hidden gaps when the app matters. An AI coding workflow adds the missing piece: a spec the output is measured against, so each iteration has a target and a clear stopping condition. The difference is not how good the model is or how fast you go. It is whether there is anything in the loop that can say "not yet," which is what turns generation into shipping.

BrainGrid turns your idea into acceptance criteria, builds against them with your choice of agent, and verifies every change with evidence, so the workflow you keep rebuilding by hand is just the product. Try it at braingrid.ai.

Originally published on the BrainGrid blog.

Why the results appear before the spinner would: how a tracker feels instant

Nico Acosta — Fri, 24 Jul 2026 13:16:51 +0000

There is a specific feeling you get from a fast tool: you type a filter, and the list is already right. You change a status, and it moves before you have finished letting go of the mouse. There was no spinner, because there was no moment to put one. The work happened where you were looking, and the network sorted itself out afterward.

That feeling is not a faster server. You cannot buy it with a bigger box, and you cannot A/B your way to it after the fact. It comes from one architectural decision made early: keep the working set close to the user, so the common actions do not wait on a round trip to feel done. This post is about how that works, and, just as importantly, where the honest limits are.

The default architecture makes you wait

Most web apps are built the obvious way. The source of truth lives on a server. The client is a thin renderer. Every meaningful action, filtering a list, editing a field, reordering a board, is a request: send it, wait, receive, re-render. Even when each request is fast, you are paying network latency on every interaction, all day.

We wrote about the extreme version of this in why Jira is so slow: a single ticket that fans out into a cascade of round trips before the page is usable. But you do not need 200 requests to feel the tax. One request per keystroke of filtering is enough. The problem is not the number, it is the shape: the client asks, the server answers, and you wait in between. As long as the data you are working with lives only on the server, the floor on "how fast can this feel" is set by the network, not by your code.

Keep the working set in the client

The fix is to stop treating the client as a thin renderer and start treating it as the place the working set lives.

When you open a Radial workspace, the issues you are looking at are loaded into a normalized in-memory store on the client (we use zustand; the pattern matters more than the library). From that point on, the interactions that used to be requests become local computations:

Filtering and sorting run as a predicate over the loaded slice. Narrowing by assignee, priority, or label does not call the server; it re-evaluates a function over data already in memory. That is why the list is right the instant you type.
Editing is optimistic. When you change a status, the store updates first and the UI reflects it immediately. The write to the database happens in the background, under row-level security. If it fails, the change rolls back and you get a toast. The common case, which is that it succeeds, never made you wait.
Realtime keeps the working set honest. When a teammate (or a teammate's agent) changes something, the update arrives over a realtime channel and reconciles into the same store, with the app's own echoes suppressed so your optimistic edit does not fight the confirmation of itself.

The through-line: the network is still there, but it moved off the critical path. You act on local state; the server catches up. The spinner has nowhere to live because the moment it would have filled is already over.

Where this is honest, and where it is not

It is easy to oversell this, so here is the line we hold.

Radial is not local-first software in the Ink & Switch sense: it is not offline-first, it does not use CRDTs, and your data is not primarily on your disk. It is a hosted, multi-tenant app backed by Postgres. What we do is narrower and more mundane: we keep the working set in the client and make the common actions optimistic, so the tool feels instant even though the source of truth is a server you are talking to.

Two consequences follow, and we would rather name them than imply they do not exist:

Global search is a server call, not a local scan. Typing into the ⌘K palette to find any issue in the workspace hits a database function, because the full corpus is not all in the client. It is fast, but it is a network request, not a local filter. The instant part is filtering and editing the slice you already have loaded, not searching everything you have never opened.
Staying small is what keeps it fast. This only works because the working set is small enough to live in the client. Radial is deliberately one thing, an issue tracker, with no 50-field forms and no dashboard suite fanning out behind every page. Speed here is a position you hold by saying no, the same discipline behind boring on purpose. Bolt on an everything-app and the working set stops fitting, and the trick stops working.

We also do not publish a latency figure as a measured benchmark, because the only honest claim is the design goal, not a marketing number. The goal is simply that the tool gets out of the way.

The same idea, from the terminal

The instant-feel is a property of the architecture, not of the web UI specifically, which is why the command line gets the same benefit. The CLI talks to the same fast surface, and every command takes --json, so you can pipe the working set straight into whatever you are already scripting:

radial list -a me --status "in progress" --json

That returns your in-progress issues as structured JSON in one call, no page to render, no spinner to watch. Your agent gets the same thing over MCP at mcp.radial.build, and the REST API at api.radial.build is plain JSON, not a GraphQL SDK you have to learn. The point is consistent across every surface: the tool should not make you wait, whether you are looking at a board, typing in a terminal, or driving it with an agent.

FAQ

What is local-first software?

Local-first software, as defined by Ink & Switch, is a set of principles where the primary copy of your data lives on your own device rather than a remote server, so the app works offline, stays fast, and keeps you in control of your data even without the cloud. It usually relies on conflict-free replicated data types (CRDTs) to merge changes across devices. Radial is not local-first in this strict sense: it is a hosted app that keeps your active working set in the client for speed, which is a different and narrower technique.

Does Radial work offline?

No. Radial keeps the issues you are working with in a client-side store so filtering and editing feel instant, but the source of truth is a hosted Postgres database and it needs a connection to sync. It is fast because the working set is local, not because it is offline-capable. If you need a fully offline, on-your-disk tracker, a true local-first or file-based tool is a better fit.

Why does filtering feel instant but search does not?

Because they work on different data. Filtering and sorting run over the slice of issues already loaded into the client, so they are local computations with no network in the loop. Global search across the whole workspace has to reach issues that are not loaded, so it calls a database function. One is a local predicate; the other is a fast server request. We would rather be precise about that than pretend everything is local.

How does optimistic editing avoid losing my changes?

Every optimistic mutation snapshots the previous state before applying the change to the client store. The database write then happens in the background under row-level security. If the write fails, the change rolls back to the snapshot and you get a toast, so you always know when something did not stick. Realtime updates from other users reconcile into the same store, with the app's own echoes suppressed so your edit is not double-applied.

Is a faster tracker actually worth switching for?

If your team touches issues dozens of times a day, the per-interaction wait is a focus tax you pay every day. The value is not a benchmark number; it is that the tool stops interrupting you. A tracker you forget you are using, because it never makes you wait, is the goal.

The short version

A tool feels instant when the working set lives in the client: filtering and sorting become local computations, editing is optimistic, and the network catches up in the background instead of blocking each action. That is the architecture behind Radial. It is not local-first software, and global search is still a server call, but the common actions do not wait, and that is where the feeling comes from.

See the one flat price on pricing, or wire the same fast surface into your terminal and your agent at /developers.

Originally published on the Radial blog.

How to Add a Screenshot Tool to Your AI Agent with MCP

Nico Acosta — Fri, 24 Jul 2026 11:41:38 +0000

An AI agent that writes frontend code has no way to see the result. It edits CSS, ships a component, and moves on, blind to whether the page actually renders correctly. The fix is to give the agent a tool that turns a URL into an image it can look at. Model Context Protocol (MCP) is the standard that makes wiring that tool a one-line job.

A screenshot MCP server exposes exactly one capability the agent was missing: send a URL, get back a rendered image. This walks through what a screenshot MCP server is, how to add a hosted one to Claude Code, Cursor, or any MCP host in a single command, and when a hosted server beats a self-hosted one that runs Chromium on your machine.

What a screenshot MCP server actually does

MCP is a protocol for connecting AI hosts to external tools. A host (Claude Code, Cursor, Claude Desktop, an agent framework) speaks MCP to a server, discovers the tools that server offers, and calls them mid-conversation. The agent never needs to know how the tool works internally, only its name, description, and inputs.

A screenshot MCP server offers a capture tool. The contract is simple:

The agent calls the tool with a URL (and optional width, format, and a few knobs).
The server renders the page in a real browser.
The server returns a hosted image, which the host passes back to the model as an image block.
The model looks at the pixels and reasons about them: spacing, overflow, a broken hero, a layout that only breaks at a real viewport.

That is the whole loop. What varies between servers is where the rendering happens. Some servers wrap a local Puppeteer or Playwright install and screenshot on your machine. A hosted server runs the browser on its own infrastructure, so there is nothing to install and nothing to keep alive.

Add a hosted screenshot MCP server in one command

Grabbit is a hosted screenshot MCP server at mcp.grabbit.live, spoken over Streamable HTTP. In Claude Code, adding it is one command plus a browser sign-in:

# Add Grabbit's hosted MCP server (Streamable HTTP)
claude mcp add --transport http grabbit https://mcp.grabbit.live

# Authenticate in your browser (no API key to paste):
#   /mcp   → select "grabbit" → Authenticate

That registers five tools with the host: grab (screenshot a URL), get_grab and list_grabs (fetch or browse past captures), get_usage (credits and plan), and get_pricing (an honest, dated comparison against ScreenshotOne, Urlbox, Browserless, and others). The agent can now call grab any time it needs to see a page.

Prefer a key over the OAuth flow? Pass a Bearer token as a header instead. A free test key (sk_test_...) returns placeholder renders at no cost, so you can prove the wiring before paying:

# Alternative: pass a key as a header instead of the OAuth flow.
claude mcp add --transport http grabbit https://mcp.grabbit.live \
  --header "Authorization: Bearer sk_test_..."

The same server works for any MCP host that speaks Streamable HTTP, not just Claude Code. Cursor, Claude Desktop, and agent frameworks point at the same https://mcp.grabbit.live endpoint and discover the same tools.

The see, fix, verify loop

The reason this matters shows up the moment an agent is doing visual work. Without a screenshot tool, a coding agent writes CSS and hopes. With one, it can close the loop:

You, in Claude Code:
  "Screenshot https://my-feature.preview.vercel.app and check the
   hero spacing against the mockup."

Claude calls the grab tool, looks at the returned image, edits the
CSS, then screenshots again to confirm the fix.

The agent captures the page it just shipped, looks at the rendered pixels, fixes what is off, and screenshots again to confirm. This is the same pattern practitioners keep landing on independently: give the agent a real rendered reference instead of asking it to reason about a page it cannot see. It generalizes past frontend work to visual QA after a deploy, verifying an OG card before a post goes live, or feeding a live competitor page into a vision step.

Because Grabbit captures public URLs and blocks localhost (SSRF protection is on by default), point the agent at a deployed preview or staging URL. That constraint is also what makes the loop work inside CI and remote runners: there is no local browser to drive, and the hosted render does not care.

When to self-host and when to use a hosted server

Search "screenshot MCP server" and most of the results are open-source repos that wrap Puppeteer or Playwright and run the capture locally. Those are a good fit when you want the browser on your own machine and are happy to maintain it. Be honest about what that maintenance is: a headless Chromium to install and patch, memory leaks to bound, fonts and locale to get right on Linux, and the same anti-bot walls a local browser hits on the open web.

A hosted screenshot MCP server removes that surface entirely. There is no Chromium in your environment, the render runs on infrastructure that already handles cookie and consent banners and JavaScript-heavy pages, and it works in sandboxes and CI where a local browser would have nothing to drive. The tradeoff is that you pay per capture instead of paying in devops time.

Grabbit's pricing is a flat $0.002 per live capture on the $50/year plan (25,000 captures), with prepaid credits that never reset or expire monthly, and test-environment captures are free. Browserless and Thum.io list a lower per-grab rate; Grabbit's edge is flat annual billing with no monthly-reset waste and the one-line MCP onboarding above. If your only need from a browser is a screenshot of a URL, a hosted server is the shorter path.

A screenshot server and a browser-automation server do different jobs

A screenshot MCP server is not a replacement for a browser-driving one. Playwright MCP gives an agent a real browser to click, type, and read the accessibility tree, which is what you want to walk through a login or a multi-step flow. A screenshot server has a narrower job: turn a URL into an image the agent can look at.

They pair naturally. The accessibility tree tells the agent what is on the page; a rendered screenshot shows it what the page looks like: visual bugs, CSS regressions, whether the thing actually looks right. Many agents use both. For the deeper pattern of feeding rendered images into a vision model, see Screenshots for AI Agents. To call the same capture from your own code without MCP, How to Screenshot a Website from a URL covers the plain HTTP path.

Calling the same capture over plain HTTP

MCP is the agent-native front door, but the same capture is one HTTP POST when you want it in a script, a cron job, or a framework tool you define by hand. This is what the grab MCP tool calls under the hood:

curl -X POST https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://my-feature.preview.vercel.app",
    "width": 1280,
    "height": 720,
    "format": "webp",
    "full_page": true,
    "delay_ms": 500
  }'

The response includes a hosted image_url you pass straight to a vision model as an image input. The knobs that matter most for agent work: full_page captures the whole document, delay_ms (0 to 10000) waits for late-loading content to settle, selector targets a single element by CSS selector, and format: "webp" keeps images small when you are passing them into a model. Width accepts 320 to 1920, height 240 to 1080.

Whether you wire it through MCP or call it directly, the point is the same: the agent stops working blind. It gets eyes on the web it is building.

For the full API reference, see the Grabbit screenshot API.

Originally published on the Grabbit blog.

Agentic Coding: How to Start When You Don't Have a CS Degree

Nico Acosta — Fri, 24 Jul 2026 11:15:15 +0000

The most useful skill in agentic coding is one you already have if you have ever managed a person. Not a framework, not a language, not a CS degree. The ability to say what you want clearly enough that someone else can build it, and to tell whether what came back is actually right. MIT's own course on this, part of its Missing Semester series, lands on the same mental model: you are not the coder anymore, you are the manager of an intern who does the nitty-gritty work but needs direction and occasionally does the wrong thing.

That reframe is good news and a warning at the same time. Good news, because it means the barrier to entry is judgment, not syntax, and judgment is something a domain expert often has in surplus. The warning is the part nobody puts in the tutorial: agentic coding will get you eighty percent of the way to a working product faster than you can believe, and then quietly strand you in the last twenty. Knowing where that cliff is, before you walk off it, is the difference between shipping and starting over.

What agentic coding actually is

Start with a clean definition, because the term gets blurred with everything adjacent. Google Cloud puts it plainly: agentic coding is a software development approach where autonomous AI agents plan, write, test, and modify code with minimal human intervention. The key word is autonomous. A traditional AI assistant waits for you to type and suggests the next line. A coding agent takes a high-level instruction, breaks it into steps, reads and writes files across your project, runs commands, checks its own work, and keeps going until the task is done.

That is the difference between AI coding and agentic coding, which is the question most beginners actually have. Autocomplete finishes your sentence. An agent runs the errand. MIT's course defines the agent as a conversational AI model with access to tools: reading and writing files, searching the web, invoking shell commands. The model is the brain; the tools are the hands. Give it a goal and it operates your codebase the way a contractor operates on a job site, not the way a dictionary suggests a word.

The tools you would actually start with are mature now. Claude Code and Codex run in your terminal and drive multi-step work from the command line. Cursor and Windsurf put the same agent inside a code editor. You do not need to know which is best on day one. You need to know that all of them are doing the same thing: taking your intent and turning it into actions, then showing you the result.

How to start without a CS degree

The first move is the smallest possible real task, not a whole app. MIT's example is a good shape: take a script you already have and tell the agent, turn this into a proper command-line program with argument parsing. One change, one file, something you can read the result of. You are not testing whether the agent is smart. You are learning the loop: describe, watch, correct, repeat.

The single skill that compounds from there is writing a good specification, and it is more art than science. The MIT course warns about both failure directions in one breath:

You want the input to the agent to be descriptive enough so that the agent does what you want it to do, but not overly descriptive to the point where you're doing too much work yourself.

MIT, "Agentic Coding," The Missing Semester of Your CS Education

Too vague and the agent guesses, usually wrong. Too detailed and you are writing the code in English, which defeats the point. The sweet spot is stating the what and the how-you-will-know-it-worked, and leaving the how to the agent. Here is the difference in practice.

Vague: "Build me a login page."

Specific: "Build an email-and-password login page. Show an inline error if the email format is invalid. Lock the account for five minutes after five failed attempts. On success, redirect to /dashboard. Unauthenticated users who reach /dashboard redirect back to /login."

The second one is not code. It is a clear description of done, written in plain language, and it is exactly the skill a non-engineer can own. The agent handles the implementation. You hold the standard.

The last starting habit is keeping a rules file. Every agent looks for a project-level file, usually AGENTS.md, where you write down your conventions and, more usefully, every mistake the agent has made before so it stops repeating them. Treat it as the onboarding doc for your intern. It is the lowest-effort reliability you will ever buy.

And yes, you can start for free. Most agents have a free tier or a low-cost entry plan, and open-source options run on your own machine. Cost is not the barrier. The barrier is knowing what to ask for and recognizing when the answer is wrong.

The trap: the 80 percent problem

Here is the cliff. Agents are stunningly good at the part of software that looks like a demo, and stubbornly weak at the part that makes it a product. The pattern is common enough that it has a name, the 80 percent problem:

The agent wrote code that works. The agent did not write code that survives.

Augment Code, "The 80% Problem"

The first eighty percent is the happy path: the feature does the thing when you use it the expected way. The missing twenty is everything that makes it real. Error handling for the inputs you did not anticipate. Security applied across the whole system, not one form. Logging so you can tell why it broke. The edge cases. And that twenty percent does not just sit there waiting politely. Left unaddressed, it compounds into technical debt that is more expensive to retrofit than it would have been to build correctly the first time, because by then the duplication and inconsistency are spread across files you never read.

This is the moment most beginners hit and misread. The demo worked, so the project feels ninety percent done, and then every new change breaks two old things and nobody can say why. We told one version of that story in I built a vibe-coding mess, and dug into why that final stretch is so stubborn in The Second 80%. It is not that you did agentic coding wrong. It is that generating code and producing a trustworthy product are different jobs, and the agent only volunteered for the first one. The honest trade-off of this entire approach: speed at the start, a debt at the finish, and the debt is invisible until you are standing in it.

The skill that closes the gap

So if the bottleneck is not generating code, what is it? Andrej Karpathy, who coined the term vibe coding and then this year declared it obsolete for serious work, drew the line that matters at Sequoia's AI Ascent:

Vibe coding is about raising the floor for everyone in terms of what they can do in software. Agentic engineering is about preserving the quality bar of professional software.

Andrej Karpathy, Sequoia AI Ascent 2026

Raising the floor is what gets you the eighty percent. Preserving the quality bar is what gets you the twenty, and Karpathy is explicit about how: you work with your agent to design a spec that is very detailed, basically the docs, and then get the agents to write against it. The skill is not coding. It is specifying precisely and verifying honestly. That is the thing the agent cannot do for you, because it is the definition of what right means, and the agent is the one being checked.

This is the gap BrainGrid was built to close, and it is built for exactly the person without a CS degree. BrainGrid is the system that takes an idea to a live product you can trust. You describe the feature in plain language, the way you described that login page above, and the Planning Agent asks the clarifying questions a senior engineer would, surfaces the edge cases you did not think of, and turns your intent into a requirement with explicit acceptance criteria. That requirement is the spec your agent works against and the standard your result is checked by.

From there you choose how to build. Hand the scoped tasks to Claude Code, Cursor, or Codex in your own setup, or let the Builder Agent build it in a managed sandbox with a live preview and open a pull request. Either way, verification closes the loop: every acceptance criterion is checked against the result, and the feature is not done until the evidence says it does what you meant. The twenty percent stops being the part you discover in production and becomes the part you specified up front. That is the whole loop, Plan, Build, Verify, Repeat, and it is the same discipline we cover in agentic engineering and in spec-driven development.

Strip away the tool names and the trending terms and the argument holds on its own: agentic coding lowered the cost of producing software to almost nothing, which means the scarce thing is no longer typing. It is knowing what you want and proving you got it. If you are a domain expert who has been told you cannot build because you cannot code, that equation just moved in your favor. The work that is left is the work you were always good at.

FAQ

What is agentic coding?

Agentic coding is a software development approach where autonomous AI agents plan, write, test, and modify code with minimal human intervention. Instead of suggesting the next line like autocomplete, a coding agent takes a high-level instruction, breaks it into steps, reads and writes files across your project, runs commands, checks its own work, and iterates until the task is complete. You direct it and review the result; it does the implementation.

What is the difference between AI coding and agentic coding?

Traditional AI coding assistants are reactive: they wait for you to type and offer suggestions or answer questions. Agentic coding tools are autonomous: they take a goal and execute it end to end, navigating files, running terminal commands, and self-correcting when a test fails. The simplest way to put it is that an assistant finishes your sentence, while an agent runs the errand.

What is the 80 percent problem in agentic coding?

The 80 percent problem is the gap between the working code an agent reliably produces, roughly eighty percent of a solution, and the production-grade remaining twenty percent: error handling, security, observability, edge cases, and compliance. Agents are excellent at the happy-path demo and weak at the parts that make software survive real use. Left unaddressed, that twenty percent compounds into technical debt that costs more to retrofit than it would have to build correctly from the start. The fix is defining the full standard up front so the agent builds to it, not just to the demo.

Can you do agentic coding for free?

Yes. Most coding agents offer a free tier or a low-cost entry plan, and there are open-source agents you can run on your own machine at no cost. Cost is rarely the real barrier to starting. The harder part is learning to write a clear specification and to recognize when the agent's output is wrong, both of which are free to practice on small tasks.

Do you need to know how to code to do agentic coding?

You do not need a CS degree, but you do need judgment. The skill that matters most is writing a clear specification, stating what you want and how you will know it worked, and verifying the result honestly. MIT's own framing is that working with a coding agent is like managing an intern: you provide direction and catch mistakes, the agent does the detailed work. Domain experts who know exactly what good looks like in their field often have the most important skill already. Tools like BrainGrid's Planning Agent turn a plain-language idea into a structured requirement with acceptance criteria, so the specifying and checking happen without writing code yourself.

BrainGrid is the AI Product Planner that turns your plain-language idea into a spec your coding agent can build against and be checked against, so the last twenty percent stops being a surprise. Try it at braingrid.ai.

Originally published on the BrainGrid blog.

GitHub stores the code, not the decision. Where the \"why\" should actually live.

Nico Acosta — Thu, 23 Jul 2026 13:16:05 +0000

An architecture decision record (ADR) is a short document that captures one architecturally significant decision: the context that forced the choice, the decision itself, and the consequences that follow. Michael Nygard proposed the format in 2011, and the convention that stuck is a numbered Markdown file in doc/adr/ in the repository, one page, written once and never edited. If the decision changes later, you do not rewrite the old record. You write a new one that supersedes it, so the log stays append-only and the history of your thinking stays readable.

That is the whole idea, and it is a good one. The rest of this post is about the part the format does not solve: most of the decisions that shape a codebase never become an ADR at all, and the reason is not laziness.

What goes in an ADR

The Nygard template has four sections, and nearly every variant since (MADR, the AWS and Microsoft prescriptive versions) is a reshuffle of the same bones.

Title. A short noun phrase naming the decision. "Use PostgreSQL for the primary datastore," not "Database discussion."

Status. Proposed, accepted, rejected, deprecated, or superseded. The status is what makes the log a log rather than a pile.

Context. The forces in play: the constraints, the requirements, the things that were true when you decided. This is the section people skimp on and the section future readers actually need. A decision without its context reads as arbitrary six months later.

Decision. What you chose, in active voice. "We will use PostgreSQL," not "PostgreSQL seems like it might be reasonable."

Consequences. What follows, good and bad. What this makes easy, what it makes hard, what you now have to live with, and what you ruled out to get here.

Keep it to a page. An ADR is a snapshot of a decision, not a design document, and the moment it grows sections it stops getting written.

When to write one

The rule of thumb from the AWS guidance and the Red Hat writeup agrees on the shape: write an ADR when the decision is architecturally significant, meaning it is expensive to reverse, it affects the structure of the system, or it constrains what the team can do later. Choosing Postgres over DynamoDB is an ADR. Choosing a variable name is not. Adopting an event-driven boundary between two services is an ADR. Bumping a patch version is not.

The useful test is the one Red Hat gives: an ADR is not a glorified changelog, and it does not replace good commit messages. If the answer to "why is this like this" is already visible in the diff, you do not need a record. You need one when the answer lives in a conversation that the diff cannot show, and when getting it wrong later will cost a rewrite.

The decisions that never make it to `doc/adr/`

Here is the honest gap, and it is worth naming precisely because ADRs are good, not because they are not.

The ADR format works well for the decisions you know are significant at the moment you make them. You recognize the fork, you convene the discussion, someone writes the file. But most architectural drift is not made of those. It is made of the smaller decisions that only look significant in retrospect: the retry semantics someone picked while fixing a flaky test, the approach that got ruled out in a pull request thread and never wrote itself down, the reason the third service does its own auth instead of using the shared middleware. Nobody stops mid-fix to open a numbered Markdown file for those. They are load-bearing anyway.

Those decisions do get made somewhere, and the somewhere is almost always the work: an issue, a comment thread, a pull request review, a session with a coding agent. Git stores the code that came out the other side. It does not store the four alternatives you rejected, the constraint that ruled out the obvious approach, or the argument that changed someone's mind. The commit is the artifact, not the reasoning.

This has gotten sharper with agents in the loop. When an agent plans an approach, rules out two others, and implements the third, all of that reasoning exists in a context window, and the context window compacts or ends. The code survives. The reasoning does not, unless something outside the model wrote it down.

Two records, one repository

The version that works in practice is not "ADRs or the tracker." It is both, doing different jobs.

Keep doc/adr/ for the big irreversible forks: the datastore, the service boundaries, the auth model. Those deserve a numbered, append-only, superseded-not-edited file that ships with the code and gets read on onboarding.

Then let the ordinary decisions land where the work already is, in the issue that produced them, at the moment they are made. The record is worth having only if writing it costs nothing, which means it has to happen in the same motion as the work, not as a separate ceremony afterward.

Radial is an issue tracker built so that motion is one command. It has a real CLI, a plain REST API, and an MCP server against the same issue lifecycle, so the same decision gets recorded whether you are in the terminal, in CI, or driving it with an agent. Every command takes --json.

# Record the decision on the issue that produced it, as it happens
radial comment RAD-482 -m "Chose optimistic locking over a row-level mutex. Ruled out the queue: adds a broker to a path that must stay synchronous. Revisit if write contention exceeds ~200/s."

# Link it to the issue that will actually have to live with it
radial link RAD-482 related RAD-611

# The constraint that ruled out the obvious approach is itself work: file it
radial create "Write ADR-014: locking strategy for the ledger writer" -t ENG -p high --json

That last command is the seam between the two records. The tracker catches the decision at the moment it is made, when the context is still in someone's head, and the ones that turn out to be architecturally significant graduate into a proper ADR in the repository. The ones that do not are still findable, still attached to the work, and still readable by the next person or the next agent.

Nothing about this is an AI feature. Radial does not read your code, summarize your diffs, or generate your ADRs. It is a fast issue tracker that people and agents can drive over CLI, REST, and MCP, and the durable record is what happens when decisions get filed the ordinary way. The intelligence stays in your agent, your model, your keys.

FAQ

What is an architecture decision record?

An architecture decision record (ADR) is a short document capturing one architecturally significant decision, along with its context, the decision itself, and its consequences. It is typically a numbered Markdown file stored in the code repository, often under doc/adr/, and it is written once rather than edited: if the decision changes, a new record supersedes the old one, keeping the log append-only.

What should an ADR contain?

The Nygard template, which most variants follow, has four sections: title (a short noun phrase naming the decision), status (proposed, accepted, rejected, deprecated, or superseded), context (the forces and constraints that made the decision necessary), decision (what you chose, in active voice), and consequences (what follows, including what you ruled out and what you now have to live with). Keep it to roughly one page.

When should you write an architecture decision record?

Write one when the decision is architecturally significant: expensive to reverse, structural, or constraining on what the team can do later. Choosing a datastore or a service boundary qualifies. Naming a variable does not. If the reason is already visible in the diff, a good commit message is enough. Write the ADR when the reasoning lives in a conversation the diff cannot show.

What tools are there for architecture decision records?

The common ones are Markdown-based and deliberately minimal: MADR provides a lean template, and adr-tools is a set of command-line tools that create, number, and supersede records in your repository. Both keep the records as plain files next to the code, which is the point of the format. For the smaller decisions that never reach a numbered file, an issue tracker with a comment thread does the job at the moment the decision is made.

Where should decisions live if not in an ADR?

In the work that produced them. Most decisions are not architecturally significant enough to justify a numbered file, but they still shape the system: the retry semantics, the ruled-out approach, the constraint nobody documented. Recording them on the issue keeps them attached to the work, findable later, and readable by the next person or agent. See agentic coding ships the 80% for the version of this argument that involves coding agents.

Do ADRs replace commit messages or a changelog?

No. An ADR is not a glorified changelog, and it does not replace good commit messages. A changelog records what changed; a commit message records what this change does; an ADR records why a significant structural choice was made and what it rules out. They answer different questions and the ADR is the most expensive of the three, which is why it should be reserved for decisions that are costly to reverse.

The short version

An ADR is a one-page, append-only record of a significant technical decision: context, decision, consequences, stored with the code. Use it for the forks that are expensive to reverse. But most of what shapes a codebase is decided in smaller moments, in an issue, a review, or an agent session, and Git stores what those produced, not why. Record those where the work already lives, and let the ones that turn out to matter graduate into a real ADR.

See the full CLI verbs and the API on the developers page, or read the manifesto for why the tracker stays a tracker.

Originally published on the Radial blog.

How to Run Playwright in Docker (and the Browser-Deps Tax It Adds)

Nico Acosta — Thu, 23 Jul 2026 11:39:40 +0000

Playwright in Docker is mostly a solved problem, and the solution is one line: use the official image. The reason people end up here anyway is the failure mode underneath it. Playwright drives a real browser, a real browser links against dozens of native shared libraries, and slim container base images do not ship them. Miss one and you get a launch error that names a .so file instead of anything to do with your test.

This guide covers the working setup, the errors that actually show up in CI, and the honest boundary where containerizing a browser stops being worth it.

Use the official image

Microsoft publishes an image with the browsers and their system dependencies preinstalled:

mcr.microsoft.com/playwright:v1.61.1-noble

Pin the tag to the same Playwright version your project depends on. This is not a style preference. The npm package and the browser binaries are versioned together, and a mismatch produces a launch failure that reads like a corrupted install. If package.json says 1.61.1, the image tag says v1.61.1.

A working Dockerfile for a Node project:

FROM mcr.microsoft.com/playwright:v1.61.1-noble

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .

CMD ["npx", "playwright", "test"]

Note what is missing: no playwright install, no install-deps, no apt-get block. The image already has the browsers and the libraries. What it does not have is your node_modules, which is why npm ci still runs. That distinction, the browsers are in the image but the package is in your project, is the thing the Stack Overflow threads keep circling.

Run it:

docker build -t my-tests .
docker run --rm --ipc=host my-tests

The --ipc=host flag is not optional in practice. Chromium uses shared memory heavily, Docker's default /dev/shm is 64MB, and the result is a browser that starts fine and then dies partway through a run. If you cannot use --ipc=host, use --shm-size=1gb instead.

Building your own image

Sometimes the official image does not fit: you need a specific base, a different runtime version, or a smaller final layer. Then you own the dependency problem, and the command that solves it is:

RUN npx playwright install --with-deps chromium

--with-deps is the important half. Without it you get the browser binary and none of the system libraries it dynamically links against, which is exactly the error people paste into forums: libnss3.so: cannot open shared object file. Naming a single browser (chromium) rather than installing all three cuts image size substantially when your suite only targets one.

Two things to know before you go this route. Alpine is not supported, because Playwright's browser builds link against glibc and Alpine ships musl, so start from a Debian or Ubuntu base. And installing browsers yourself adds a slow, network-dependent layer to every rebuild that the official image has already paid for.

The errors you will actually hit

The container exits immediately. Usually correct behavior rather than a bug: a container lives as long as PID 1, and if PID 1 is playwright test, the container stops when the run ends. Check the exit code before assuming it crashed. A non-zero code means the tests failed; zero means it worked and finished.

Browser closed unexpectedly, mid-run. Shared memory. Use --ipc=host or --shm-size=1gb.

A missing .so file at launch. Either a custom image without --with-deps, or an Alpine base.

Works locally, fails in CI. Nearly always a version mismatch between the image tag and the installed Playwright package after a dependency bump. Pin both, bump both together.

Screenshots differ between your machine and the container. This is expected, not broken. Font rendering and available font families differ across environments, so pixel comparisons made on a laptop will not match baselines made in a container. The fix is to generate baselines in the same container that verifies them, which is the main reason visual regression suites get containerized at all. There is more on that in visual regression testing in Playwright CI.

When Docker is the right call, and when it is not

Containerizing Playwright buys you a reproducible browser environment. That is worth real setup cost when your suite is doing browser work: navigating multi-step flows, logging in, filling forms, asserting on state, comparing screenshots against baselines that must be byte-stable. In those cases you need the whole browser under your control, and a container is how you make "the whole browser" identical everywhere.

The calculation changes when the browser is incidental. A large share of Playwright-in-Docker setups exist to produce an image of a page: an OG card, a report thumbnail, a nightly capture of a dashboard, a preview for a marketing site. There the container is not giving you determinism you need, it is giving you a browser you are obligated to maintain, so that an HTTP request can come back with a PNG.

If that is the job, the render can move off your infrastructure entirely:

curl -sS https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "width": 1280,
    "full_page": true,
    "delay_ms": 1000,
    "format": "webp"
  }'

The response carries an image_url pointing at the stored capture. No image to build, no browser version to pin, no --shm-size to remember, nothing to rebuild when a base image ships a new glibc.

The parameters map closely to what you would have written in Playwright: width (320 to 1920) pins the viewport the way setViewportSize does, full_page is the equivalent of fullPage: true, delay_ms (0 to 10000) replaces a fixed waitForTimeout after load, selector captures a single element the way a locator screenshot does, and format accepts png, jpeg, or webp.

The honest boundary: if the capture has to happen after a login, a click, or a form submission, none of this helps you and Playwright in a container is the correct tool. An API call renders a URL. It does not drive a session.

Cost, honestly

The relevant comparison is not per-request price against zero, because self-hosting is not free either. A containerized browser costs CI minutes on every build, image storage, and the recurring attention of whoever fixes it when a base image or Playwright version breaks the setup.

Grabbit is $0.002 per live grab, prepaid, with credits that do not reset monthly, which fits bursty work like a capture pipeline that runs hard some weeks and not at all in others. Test-environment keys return placeholder images at no cost, so you can wire the whole flow before any real capture runs. Other providers list lower per-grab rates, so if unit price is the only variable you care about, compare directly.

Where to go next

If you are keeping the container and just want the capture code to be right, how to take screenshots in Playwright covers the full-page, element, and CI cases. If you are weighing whether to keep running a browser at all, Puppeteer alternatives in 2026 walks the same decision from the other library, and the screenshot API page covers the hosted side in depth.

Originally published on the Grabbit blog.

Harness Engineering, Explained: What Separates Top Agentic Engineers

Nico Acosta — Thu, 23 Jul 2026 11:11:33 +0000

OpenAI spent five months building an internal product where humans wrote zero lines of code, and the engineers on that team were busier than ever. Roughly a million lines shipped across more than 1,500 pull requests, every one of them authored, reviewed, and merged by agents. The work did not disappear. It moved into something the team calls the harness, and in the four months since, the idea has completed its arc from insider habit to formal discipline. There is now an open-source framework, AutoHarness, whose entire premise is that an agent is just a model plus a harness, and the harness is the part you engineer.

Here is the claim worth testing: what separates the builders getting production-grade output from agents is not the model they picked or the prompts they write. It is whether they built the environment around the agent. And inside that claim hides a second one that matters even more, because the harness, for all its power, cannot generate its own most important input.

What harness engineering actually is

The term has a precise origin story. Mitchell Hashimoto, the creator of Terraform and Vagrant, described the practice in his AI adoption journey in early February 2026, as the step where his agent use stopped being frustrating and started compounding:

Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

Mitchell Hashimoto, "My AI Adoption Journey"

Six days later, OpenAI gave the discipline its formal name. Ryan Lopopolo's post described how their agent-first team operates: engineers do not write the code, they build the structure, documentation, and automated checks that keep agents on track. The post's core principle fits in four words: humans steer, agents execute. The metaphor is deliberate. A harness, in the original sense, is the equipment that channels a powerful animal's strength in a useful direction. Nothing about the harness makes the horse stronger. It makes the strength go somewhere.

So a working definition: harness engineering is the practice of designing the environment around an AI coding agent, the context it reads, the tools it can call, and the checks that catch its output, so the agent produces the right result instead of a plausible one. Your agent's raw capability is rented from a model provider, and it is the same capability everyone else rents. The harness is the part you own.

What a harness is made of

Birgitta Böckeler, writing the most rigorous treatment of the subject on martinfowler.com, defines the harness as everything in an agent except the model itself, and sorts its parts into two families. Guides act before the agent does: the AGENTS.md file that carries your conventions, the architecture notes, the bootstrap scripts that set up a working environment. Sensors act after: linters, type checkers, test suites, and review agents that inspect what came out and feed problems back in.

The whole practice reduces to one move, applied relentlessly. When the agent does something wrong, you do not correct it in chat. You encode the correction where every future run will hit it.

The difference is easy to see side by side. Chat correction: "No, use our date helper, not raw Date()," and the agent complies, and that knowledge evaporates the moment the session ends. Harness correction: a lint rule that flags raw Date() plus one line in AGENTS.md explaining the helper, and no agent in any future session ships that mistake again. The first is a conversation. The second is an asset. Top agentic engineers are the ones with eight months of accumulated corrections sitting in their repo, which is why their agents seem eerily reliable and yours seems forgetful. Same model. Different harness.

flowchart LR
    S[Spec with acceptance criteria] --> A[Agent run]
    G[Guides: AGENTS.md, conventions, scripts] --> A
    A --> C{Sensors: tests, linters, review}
    C -->|fail| F[Feedback to agent]
    F --> A
    C -->|pass| P[PR you can trust]

The harness governs how. It cannot decide what.

Now for the part the harness explainers skip, and the reason the diagram above starts where it starts. Every component of a harness shares one property: it evaluates the agent's output against a standard somebody already wrote down. The linter knows your formatting rules. The type checker knows your interfaces. The test suite knows the behavior somebody specified. Feed the harness a vague goal and it will happily help the agent build the wrong thing correctly, with clean types, passing tests it wrote for itself, and conventions intact.

Böckeler lands on exactly this limit, and her conclusion is the reframe that should change how you spend your effort:

A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important.

Birgitta Böckeler, "Harness engineering for coding agent users"

Where is your input most important? Not in the lint rules. The agent can draft those. Not in the test scaffolding. The agent writes that too, and the harness checks it. The one input the harness cannot generate, verify, or even detect the absence of is the definition of what you are building and how you will know it is right. A harness with no spec is scaffolding around an empty lot. This is also what distinguishes the harness from its sibling buzzword: the loop schedules and re-runs your agent, the harness shapes and checks each run, and the spec tells both of them what done means. We covered the loop layer in What Is Loop Engineering?; the punchline there was that the loop's verifier needs a standard. The harness is that verifier, and it needs the standard just as badly.

This is the gap BrainGrid fills. BrainGrid is the system that takes an idea to a live product you can trust, and it sits exactly at the harness's missing input. You describe the feature in plain language, and the Planning Agent interrogates it the way a senior engineer would, surfacing edge cases and turning intent into a requirement with explicit acceptance criteria. That requirement becomes the harness's reference point. Run the build either way: hand the scoped tasks to Claude Code, Cursor, or Codex over MCP inside your own harness, or let the Builder Agent build in a managed sandbox with a live preview and open the PR. Then verification closes the loop the way a linter never can, checking the result against each acceptance criterion and holding the feature short of done until the evidence says it does what you intended. Code review tells you the code is well-written. Verification tells you it does what you meant.

The honest costs

Two trade-offs, because the discipline has them. First, a harness is a second codebase. Hashimoto's rule sounds light, but engineering a permanent fix for every mistake is real, ongoing work, and on a legacy codebase with years of unwritten conventions, the backfill is steep. Budget for it like infrastructure, because that is what it is.

Second, the harness has a ceiling, and you should know where it is. Böckeler's warning is that no current check, mechanical or model-based, reliably catches the agent that misunderstood the assignment. The failure mode that actually burns builders is not malformed code. It is well-formed code that solves the wrong problem. That failure is invisible to every sensor in the harness except one: a written statement of what the right problem was. The better your agents get, the more this holds, because more capable agents produce more output per unit of your attention, and every unit of output that nobody specified is a decision nobody made.

If you are building with Claude Code or Cursor today, here is what this means concretely: your edge is no longer in the prompt box. An hour spent writing one more clever prompt is worth less than an hour spent adding the lint rule, the AGENTS.md entry, and the acceptance criteria that make the next hundred prompts land. The builders pulling ahead right now are not prompting better. They are accumulating a harness, and they are feeding it specs.

Start your harness this week:

Create an AGENTS.md file and add one entry for every mistake your agent has made twice. (Claude Code skills are the structured version of the same move.)
Wire your existing checks into the agent's path: tests, linter, type checker, so failures feed back automatically.
Before the next feature, write the acceptance criteria first, in BrainGrid or anywhere, so the harness has something real to check against.

Strip away the OpenAI post, the GitHub stars, and the new vocabulary, and the argument stands on its own: an agent's output is only as trustworthy as the environment that checks it, and the environment is only as good as the intent you wrote down. The harness is how the agent stops repeating mistakes. The spec is how it stops making the expensive one.

FAQ

What is harness engineering?

Harness engineering is the practice of designing the environment around an AI coding agent so it produces reliable results: the context files it reads (like AGENTS.md), the tools and scripts it can call, and the automated checks (tests, linters, review agents) that catch its output and feed problems back. The core move is encoding every correction permanently in the environment instead of repeating it in chat.

Who coined the term harness engineering?

Mitchell Hashimoto, creator of Terraform, described "engineering the harness" in his "My AI Adoption Journey" post on February 5, 2026. OpenAI formalized the term six days later in Ryan Lopopolo's February 11 post about building an internal product with zero human-written code. The underlying word is older: a harness has long meant the scaffolding around a model, and the equestrian metaphor, equipment that directs strength, is intentional.

What is the difference between harness engineering and spec-driven development?

They cover opposite sides of the same problem. Spec-driven development defines what to build before the agent starts: requirements, behavior, acceptance criteria. Harness engineering shapes how the agent works and checks what it produced: conventions, tools, tests, and feedback. A harness verifies output against a standard, and the spec is that standard, so each practice is incomplete without the other.

What is the difference between a harness and a loop?

The harness is the environment around a single agent run: what the agent knows, what it can touch, and what checks its work. A loop is the orchestration above it: the scheduler that finds work, runs the agent again and again, and decides when to stop. The loop re-runs the agent; the harness makes each run trustworthy. Both depend on a spec to define what done means.

Do you need to be an engineer to benefit from harness engineering?

The principle transfers even if you never write a lint rule. Any builder can keep a running file of corrections their agent must follow, and any builder can define acceptance criteria before the agent starts. Tools handle the rest: BrainGrid's Planning Agent turns a plain-language idea into a requirement with testable criteria, and its verification checks the build against each one, which is the harness's feedback layer without the infrastructure work.

BrainGrid is the AI Product Planner that gives your harness the one input it cannot generate: a spec with acceptance criteria to check every build against. Try it at braingrid.ai.

Originally published on the BrainGrid blog.

Agentic coding ships the 80%. Your tracker holds the other 20%.

Nico Acosta — Wed, 22 Jul 2026 13:17:18 +0000

Agentic coding is a way of building software where an autonomous AI agent takes a high-level instruction and plans, writes, tests, and revises the code with little step-by-step human input. Unlike an inline assistant that waits for you to type and then completes the line, an agent runs a loop: it decides what to do next, does it, checks the result, and corrects itself, until the task is done or it gets stuck. Claude Code, Codex, Cursor's agent mode, and Gemini's coding agent are all versions of the same idea.

That loop is genuinely fast, and it is why the term went from niche to everywhere in a year. It is also why a specific gap keeps showing up in the discussion: the agent reliably produces roughly the functional 80% of a working change, and the remaining 20%, the part that has to be right for the work to actually be done and remembered, does not live in the code the agent just wrote. This post is about where that 20% should go.

The 80% problem, stated plainly

If you search "agentic coding," one of the first questions Google surfaces is "what is the 80% problem in agentic coding?" The short version people have converged on: agents ship the working majority of a change quickly, and the hard, compounding remainder, the error handling, the security edges, the "why did we do it this way," the coordination between the change and everything else in flight, is where the debt accumulates when nobody captures it.

Notice that most of that remainder is not more code. It is context and decisions. Which approach was chosen and why. What was ruled out. What the agent noticed on its way through that nobody asked it to fix. Which of three parallel agents already touched this module. That information is real work product, and by default it lives in exactly one place: the context window of the session that produced it. When the window fills and compacts, or the session ends, it is gone. The code survives; the reasoning behind it does not.

So the 80% problem is not really "agents write sloppy code." It is that the fast part and the durable part have different homes, and agentic workflows are very good at producing the fast part and very bad at persisting the durable part.

Where the durable 20% should live

The cheapest durable unit for the 20% is an issue. Not a document, not a chat log, an issue: it has an owner, a status, a priority, and a comment thread, and it sits outside the model entirely, so it survives every context reset by construction. When an agent opens an issue for the work, comments on it as it makes decisions, and closes it with a note when the change lands, the reasoning stops being a casualty of the next auto-compact. The next session, or the next agent, reads the current state instead of reconstructing it from a summary that got squeezed out.

This is also the piece that lets more than one agent work at once without stepping on each other. A developer in a recent r/github thread described building the missing layer by hand: a single local API for the full issue lifecycle so that, in their words, "the agent never polls GitHub, it just checks local state and the sync layer handles the rest." That instinct is exactly right. The agents need one fast place to read and write the state of the work, separate from any one session's memory. The only question is whether you hand-roll it or point at one that already exists.

Radial is that record, built so agents can drive it directly. It is a fast issue tracker with a real CLI, a plain REST API, and an MCP server, all against the same issue lifecycle, so however your agent reaches it, it reads and writes the same state. Here is the loop an agentic coding session runs against it, using the CLI (every command takes --json, so the output pipes straight into the next step):

# The agent reads what's assigned to it, in progress, as structured JSON
radial list --assignee me --status "in progress" --json

# It makes the change, then closes the issue with a note the next session can read
radial close RAD-482 -m "Chose optimistic locking over a mutex; ruled out the queue approach, added in #611."

# It spotted a second problem on the way through, so it files that too
radial create "Token refresh retries on 401 instead of re-auth" -t ENG -p high -l bug -a me --json

Nothing in that loop is specific to one agent. The same three verbs run from a REST call in CI, from the MCP server a different agent is connected to, and from your own terminal, all against one shared record. The 80% (the code) ships however it ships; the 20% (the decisions, the follow-ups, the state) is now written down where it outlives the session.

Why this is a tracker, not an AI feature

There is a line here worth being precise about. Radial does not read your code, summarize your diffs, or try to be a smarter memory layer for your agent. It is a fast issue tracker that agents happen to be able to drive over CLI, REST, and MCP, and the durable record is a side effect of agents filing and updating issues the normal way, not an AI feature bolted on top. The intelligence stays in your agent, your model, your keys. Radial holds the record.

That is deliberate, and it is binding. There is no copilot in the product, no auto-summary, no AI triage, and no AI credit meter, because your agent already does the thinking and you already pay for it once. The Plain Software Pledge is the enforceable version: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

And because every agent credential is an API client, not a billed seat, running a fleet of coding agents against Radial costs nothing extra. The price is $50 per user, per year, flat, billed annually, for the humans on the workspace, locked at the rate you join. Ten agents writing to the same tracker is still just the humans. Agents ride free; that is the structure, not a promotion.

FAQ

What is agentic coding?

Agentic coding is a software development approach where an autonomous AI agent plans, writes, tests, and modifies code from a high-level instruction, with minimal human intervention. Instead of completing a line you are typing, the agent runs its own loop: it decides the next step, executes it, checks the outcome, and self-corrects until the task is done. Claude Code, Codex, and Cursor's agent mode are common examples.

What is the 80% problem in agentic coding?

It is the gap between the functional majority of a change that agents produce quickly (roughly 80%) and the durable remainder (the error handling, the security edges, the decisions, and the coordination) that compounds into debt when it is never captured. Much of that remainder is context and reasoning, not code, and it disappears when a session's context window compacts or ends unless it was written down somewhere outside the model.

How is agentic coding different from vibe coding?

Vibe coding is prompt-driven and exploratory: you describe what you want and iterate on the output by feel. Agentic coding is outcome-oriented and self-directed: the agent runs a plan-act-check loop toward a defined result and corrects itself along the way. In practice the two blur, but the agentic version produces more work product (decisions, follow-ups, state changes) that needs a durable home.

Where should an AI coding agent record its work?

In an issue tracker it can drive directly, so the record survives context resets and hands off cleanly to the next session or agent. An issue is a cheap durable unit: owner, status, priority, and a comment thread, all outside the model. Point your agent at Radial's CLI, REST API, or MCP server and it can read its queue, file issues, comment as it decides, and close them when done. See give Claude Code access to your issue tracker in 5 minutes for the MCP setup.

Does running multiple coding agents against Radial cost more?

No. Agent credentials are API clients, not billed seats. You pay $50 per user, per year, for the humans on the workspace, locked at the rate you join, and a fleet of agents writing to the same tracker adds nothing to that.

The short version

Agentic coding ships the functional 80% fast, and the durable 20%, the decisions, the follow-ups, and the coordination, is context, not code. By default that context dies with the session's memory. Give your agents one durable record they drive over CLI, REST, and MCP, and the reasoning behind the work outlives the window that produced it.

See the full tool list and the CLI verbs on the developers page, or read your Claude Code sub-agents keep losing the thread for the multi-agent version of the same argument.

Originally published on the Radial blog.

Screenshot Automation: How to Capture Web Pages on a Schedule

Nico Acosta — Wed, 22 Jul 2026 11:40:28 +0000

Screenshot automation for web pages comes down to two pieces: something that fires on a schedule, and something that renders the page. You almost certainly already have the first piece. The second is where people get stuck, because the obvious answer, running headless Chromium yourself, means owning a browser fleet to produce a single image on a timer.

This guide covers the scheduled-capture pattern: how to wire a cron job to a screenshot API, how to pick an interval, how to keep captures consistent enough to compare, and where to store the results.

One clarification first, because search results for this topic mix two unrelated jobs. Capturing your own desktop or phone screen on a timer needs a local screen-capture utility. Capturing a web page on a timer, from a server, with no one at the keyboard, is what this post is about.

The pattern: scheduler plus render

Every scheduled screenshot setup has the same three stages:

Trigger. A cron entry, a GitHub Actions schedule, a Vercel or Cloudflare cron, or a workflow tool fires on an interval.
Render. One HTTP request per URL returns a hosted image.
Store. Write the image URL plus a timestamp somewhere you can query later.

The trigger is a solved problem in whatever stack you already run. The render stage is the only real decision, and it comes down to whether you run the browser or someone else does.

Running the browser yourself

The DIY version is a scheduled script that launches Chromium through Puppeteer or Playwright, navigates to the URL, calls page.screenshot(), and uploads the result. It works, and for a single URL on a laptop it is genuinely fine.

The cost shows up when it has to run unattended. A scheduled job means a long-lived environment, which means keeping the browser alive across runs or paying the launch cost every time. Serverless runtimes do not ship the native libraries Chromium expects, so you end up on @sparticuz/chromium or a custom container. Chromium leaks memory over long runs, so scheduled jobs that never restart eventually get killed. None of these are unsolvable, but they are all maintenance on infrastructure whose entire output is a PNG.

The honest rule: if your scheduled job needs to log in, click through a flow, or fill a form before the capture, you need your own browser automation and this maintenance is the price of the job. If it just needs to render a URL, you do not.

Running it as an API call

If the deliverable is a rendered image of a URL, the render stage collapses into one request. A cron entry, once a day at 6am:

0 6 * * * curl -sS https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "width": 1280,
    "full_page": true,
    "delay_ms": 1000,
    "format": "webp"
  }' >> /var/log/pricing-snapshots.log

The response includes an image_url pointing at the stored capture. That URL is the artifact: append it to a log, insert it into a table, post it to Slack. There is no browser on your side, nothing to keep alive between runs, and nothing to patch.

The parameters are the consistency controls, and they matter more in a scheduled pipeline than in a one-off capture:

width (320 to 1920) pins the viewport. Fix it and the layout is identical every run, so a diff shows real changes rather than reflow.
full_page captures the entire document instead of just the visible viewport, so a change below the fold is not invisible to your pipeline.
delay_ms (0 to 10000) waits after load for lazy-loaded images and animations to settle. This is the single most common fix for scheduled captures that look different every run for no reason.
format accepts png, jpeg, or webp. For an archive that accumulates one image per run, webp keeps storage down.
selector captures a single element instead of the page. Scoping a monitor to #pricing-table removes noise from unrelated sections of the page.

Scheduling more than one URL

Most real automations track a list, not a single page. Loop the list in the scheduled job and make one request per URL. Keep two things in mind:

Grabbit rate-limits to 60 requests per minute per team, so a list longer than about 60 URLs needs to be paced rather than fired in one burst. For a nightly job this is a non-issue; add a short sleep between calls and it stays well under.

Second, be deliberate about the identifier you store. A screenshot is only useful later if you can find it, so record the URL, the capture timestamp, and the returned image_url together. Overwriting a single "latest.png" throws away the history that made the automation worth building.

There is a fuller walkthrough of the batch case in how to screenshot a list of URLs.

Picking an interval

The interval should track how fast the content actually changes, not how often you would like to look at it:

What you are capturing	Reasonable interval
Your own app, for visual regressions	On every deploy, not a clock
Competitor pricing or marketing pages	Daily
News, dashboards, status pages	Hourly
Legal or compliance archiving	Daily, retained long term
A page that changes weekly at most	Weekly

Running more often than the page changes produces a pile of identical images and a bill that scales with nothing. The exception is your own application, where the right trigger is not a clock at all: capture on deploy, because that is the moment the page can change.

From automation to monitoring

A scheduled capture on its own is an archive. Add an image diff between consecutive captures and it becomes a monitor that tells you when something changed, which is usually the actual goal. pixelmatch handles strict pixel comparison and resemblejs does a more forgiving perceptual comparison for pages with anti-aliased text.

The consistency parameters above are what make that diff trustworthy. A pipeline with a floating viewport width or no settle delay will produce diffs on every run and you will stop reading the alerts within a week. Monitoring a website for visual changes covers the diff and alerting side in full.

Cost, honestly

Scheduled automation is the case where per-request pricing compounds, so it is worth doing the arithmetic before you set the interval. Grabbit is $0.002 per live grab. Fifty URLs captured daily is 1,500 grabs a month, or about $3. The same fifty URLs hourly is roughly 36,000 grabs a month, closer to $72. The interval, not the tool, is what drives the number.

Credits are prepaid and do not reset monthly, which suits scheduled work specifically: a job that runs unevenly, or that you pause for a quarter, does not forfeit anything at a billing boundary. Test-environment keys return placeholder images at no cost, so you can wire and debug the full schedule before any real capture runs. Other providers list lower per-grab rates, so if raw unit price is the only variable that matters to you, compare directly.

Where to go next

If you are building scheduled capture into a product, automated screenshots covers the API side in more depth. If you are starting from a single URL and have not automated anything yet, how to screenshot a website from a URL is the shorter starting point.

Originally published on the Grabbit blog.

What Is Loop Engineering? Stop Prompting, Start Designing Loops

Nico Acosta — Wed, 22 Jul 2026 11:13:41 +0000

Every few months the AI building world agrees on a new thing you are supposed to be doing, and this month it is loop engineering. The pitch is clean: you do not prompt your coding agent one step at a time anymore. You design the loop that prompts it for you, point it at a goal, and walk away.

It is a real shift, and it is worth understanding. But the part the loop tweets leave out is the interesting part. The loop takes prompting off your plate and hands you back a harder job, one you cannot automate your way out of. Knowing what that job is tells you exactly where to put your effort.

What loop engineering actually means

Loop engineering is the practice of designing a system that prompts and orchestrates an AI coding agent on a schedule, instead of you typing each prompt by hand. Addy Osmani, whose explainer became the reference for the term, defines it plainly:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

Addy Osmani, "Loop Engineering"

A loop is roughly five pieces plus one. Automations that fire on a schedule and find work. Worktrees so two agents do not collide. Skills that write down project knowledge the agent would otherwise guess. Connectors that plug the agent into your real tools. Sub-agents, so the one that writes the code is not the one that grades it. And the sixth piece, the one that makes the whole thing hold together: a memory that lives outside any single run and remembers what is done and what is next.

The wave started with two sentences from people who would know. Peter Steinberger, who built the open-source agent gateway OpenClaw and now works at OpenAI, put it as a standing reminder:

Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

Peter Steinberger on X

Days earlier, Boris Cherny, who leads Claude Code at Anthropic, described on stage where his own job had gone:

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Boris Cherny, head of Claude Code at Anthropic

Steinberger's post hit 6.5 million views in a week. It landed because the pieces ship inside the products now: /goal in Claude Code defines a testable end state and keeps working until it is true, with a separate model grading whether it is done. The leverage point moved, and everyone felt it at once.

The job the loop hands back

Here is the contradiction at the center of the hype. A loop running unattended is also a loop failing unattended. Take prompting off your plate and you have not removed the work, you have moved it somewhere worse: into runs you were never watching, with far too much output to read by hand. Akshay Pachaar said it sharply this week:

Loop engineering takes you off prompting. It takes you off curating context. It takes you off babysitting a single run. It does not take you off debugging. It just moves the debugging somewhere worse, into runs you were never watching.

Akshay Pachaar on X

Stack the layers up, prompt to context to harness to loop, and one job survives all of them. Closing the loop on failure. You can only walk away from a loop if you trust the thing checking it, and a checker you do not trust drops you right back into reading every output by hand, which is the exact work the loop was supposed to take off you.

So the real question loop engineering raises is not "how do I build the loop." Both Claude Code and Codex ship the loop. The real question is "what does my checker check against." A loop with no definition of done is just a faster way to generate work you still have to inspect line by line.

Why this moves the work upstream, not away

Watch what happens to the human as each layer of automation arrives. Prompt engineering asked you to write a good message. Context engineering asked you to curate what the model sees. Loop engineering asks you to design the system that does both on a schedule. At every step the manual labor shrinks and the judgment concentrates. The thing you cannot hand off is deciding what you actually want and stating it precisely enough that a machine can check the result.

That is a spec. Not a vague ticket, not a paragraph in Slack, but a requirement with testable acceptance criteria: the agent built this, here is how we know it is right. The sub-agent that "verifies against the spec," in Osmani's words, needs a spec to verify against. The loop's memory, the file that survives between runs, has to hold something worth remembering. Both of those are the same artifact, and writing it is the work that does not disappear.

Consider the before and after. Before: you babysit a single run, catch the drift in real time, correct it prompt by prompt. After: the loop runs ten times overnight and you wake up to ten pull requests, half of them subtly wrong in ways no human would have written, and no clear standard to grade them against. The loop made you faster at producing work and slower at trusting it. The fix is not a better loop. It is a definition of done the checker can actually use.

Where BrainGrid fits in a loop

This is the gap BrainGrid was built for. BrainGrid is a product factory that runs the loop Plan, Build, Verify, Repeat, and it owns the two pieces a loop cannot generate for itself: the plan and the standard.

You describe a feature in plain language. The Planning Agent asks the clarifying questions a senior engineer would, surfaces the edge cases, and writes an engineering-grade requirement with acceptance criteria. That requirement is the spec your loop's verifier checks against. It is also the memory: it persists outside any single run, so when tomorrow's automation fires, the context is already there. The agent forgets between sessions. BrainGrid does not.

From there the loop runs either way. Load the scoped tasks into Claude Code, Cursor, or Codex over MCP and let your own harness drive them, or let BrainGrid's Builder Agent build the requirement in a managed sandbox and open a pull request, with AI code review checking the result against the acceptance criteria item by item. Verification stops being a thing you hope the loop got right and becomes a thing the loop can prove. That is what makes walking away safe. This is the same discipline we cover in agentic engineering, and the full five-stage version lives in The BrainGrid Loop.

So is it real, or just another buzzword

Both, the way most of these are. The mechanics are real and genuinely useful: scheduled, self-checking agent runs are a meaningful jump in capability, and if you have not tried /goal in Claude Code you should. The buzzword part is the implication that designing the loop is the whole job. It is not. It is the part that got automated. The part that did not, defining what done means and giving the checker something real to check, is where the work went. Put your effort there, and the loop pays off. Skip it, and the loop is just a faster way to dig the hole we wrote about in I built a vibe-coding mess. The loop-as-a-running-joke version is our take on the Ralph Wiggum plugin.

FAQ

What is loop engineering?

Loop engineering is the practice of designing a system that prompts and orchestrates an AI coding agent automatically, on a schedule, instead of typing each prompt yourself. A loop typically combines scheduled automations, isolated worktrees, project skills, tool connectors, and sub-agents that check each other's work, plus a memory that persists between runs. The goal is to move from holding the agent's hand through every step to designing the system that runs it for you.

Is loop engineering real or just another AI buzzword?

It is both. The underlying mechanics are real and shipping today in Claude Code and Codex, and scheduled self-checking agent runs are a genuine step up. The buzzword part is the suggestion that building the loop is the whole job. The loop automates the prompting, but it hands back the harder work: defining what "done" means so the loop's checker has a standard to verify against. Designing the loop is the easy half. Closing the loop on failure is the half that survives.

What is the difference between loop engineering and prompt engineering?

Prompt engineering optimizes a single message you send by hand. Loop engineering designs the system that sends those messages for you, on a cadence, and checks the results. Prompt engineering is one turn; loop engineering is the machine that runs many turns unattended. The skill moves from wording a request to specifying a goal precisely enough that an automated checker can confirm it was met.

Does Claude Code support loop engineering?

Yes. Claude Code ships the core pieces: /loop re-runs a prompt on a cadence, /goal keeps working until a condition you defined is true with a separate model grading whether it is done, and hooks plus scheduled tasks let you run autonomous work on an interval. Codex offers the same primitives through its Automations tab. The pieces are in the products now, which is why the term took off.

What does loop engineering not solve?

Verification and your own understanding. A loop running unattended is also a loop making mistakes unattended, and the more code it ships that you did not write, the larger the gap between what exists and what you actually understand. The loop can take you off prompting, context curation, and babysitting a single run. It cannot take you off deciding what you want and confirming the result matches. That is why a clear spec with acceptance criteria, which is what BrainGrid produces, is the piece that makes a loop trustworthy enough to walk away from.

BrainGrid is the AI Product Planner that gives your agent loops the one thing they cannot generate for themselves: a spec with acceptance criteria the verifier can check against. Try it at braingrid.ai.

Originally published on the BrainGrid blog.

DEV Community: Nico Acosta

Your background agent needs somewhere to pick up the task and file the result

The loop is: pick up a task, do the work, file the result

Where it breaks: one agent is fine, several is not

The record Radial is

Where the line is

FAQ

What are background agents?

What are background agents good for?

Where should a background agent read its tasks from?

Does running more background agents against Radial cost more?

Does Radial run or trigger the agent?

The short version

How to Capture a Webpage Screenshot Programmatically (URL to Image via API)

The quick answer

Manual versus programmatic capture

Capturing a webpage with an API

Capturing the full page, not just the viewport

Handling pages that load content late

Choosing PNG, JPEG, or WebP

When a local capture is the better call

Next steps

The AI Coding Workflow That Ships One Feature: Idea to Merged PR

The workflow everyone keeps reinventing

One feature, start to finish

Why the spec is the workflow

Where this stops being a hand-rolled process

FAQ

What is an AI coding workflow?

How do I set up an AI coding workflow?

Is planning really necessary if the AI model is good enough?

How do I review an AI pull request if I can't read code?

What's the difference between vibe coding and an AI coding workflow?

Why the results appear before the spinner would: how a tracker feels instant

The default architecture makes you wait

Keep the working set in the client

Where this is honest, and where it is not

The same idea, from the terminal

FAQ

What is local-first software?

Does Radial work offline?

Why does filtering feel instant but search does not?

How does optimistic editing avoid losing my changes?

Is a faster tracker actually worth switching for?

The short version

How to Add a Screenshot Tool to Your AI Agent with MCP

What a screenshot MCP server actually does

Add a hosted screenshot MCP server in one command

The see, fix, verify loop

When to self-host and when to use a hosted server

A screenshot server and a browser-automation server do different jobs

Calling the same capture over plain HTTP

Agentic Coding: How to Start When You Don't Have a CS Degree

What agentic coding actually is

How to start without a CS degree

The trap: the 80 percent problem

The skill that closes the gap

FAQ

What is agentic coding?

What is the difference between AI coding and agentic coding?

What is the 80 percent problem in agentic coding?

Can you do agentic coding for free?

Do you need to know how to code to do agentic coding?

GitHub stores the code, not the decision. Where the \"why\" should actually live.

What goes in an ADR

When to write one

The decisions that never make it to doc/adr/

Two records, one repository

FAQ

What is an architecture decision record?

What should an ADR contain?

When should you write an architecture decision record?

What tools are there for architecture decision records?

Where should decisions live if not in an ADR?

Do ADRs replace commit messages or a changelog?

The short version

How to Run Playwright in Docker (and the Browser-Deps Tax It Adds)

Use the official image

Building your own image

The errors you will actually hit

The decisions that never make it to `doc/adr/`