ai-native

3 posts with the tag “ai-native”

High-Speed AI-Driven Product Development with Gasoline MCP

Feb 7, 2026

Brenn Hill

What if your AI could see the UI, react to issues in real time, and tighten the feedback loop from “something looks wrong” to “it’s fixed” to under a minute? That’s the development speed Gasoline enables.

The Feedback Loop Is Everything

The speed of software development is the speed of feedback loops. How fast can you go from:

Idea to prototype?
Code change to visual result?
Bug report to fix deployed?
“This looks wrong” to “now it looks right”?

Every great product development methodology — agile, lean, continuous deployment — is fundamentally about making these loops shorter. The faster you iterate, the better the product gets.

AI coding agents just compressed the “code change” part of the loop from hours to seconds. But there’s a gap: the AI can write code fast, but it can’t see the result. It pushes a fix and then asks you, “Did that work?” You check the browser, describe what you see, and the loop slows back down to the speed of human communication.

Gasoline closes that gap. The AI sees the browser. The loop runs at machine speed.

Real-Time React: See It, Fix It, Verify It

Here’s what a high-speed development session looks like with Gasoline:

You: “The signup form looks broken on mobile. Fix it.”

AI observes the page:

observe({what: "screenshot"})
observe({what: "errors"})
observe({what: "vitals"})

The AI sees the screenshot — the form is overflowing its container, the submit button is off-screen. It sees a CSS warning in the console. It notes the LCP is 4.2s (should be under 2.5s).

AI diagnoses: “The form container has max-width: 600px but no horizontal padding. On screens narrower than 600px, the content bleeds. The submit button has position: absolute with a fixed top that pushes it below the viewport on mobile.”

AI writes the fix. Updates the CSS — adds responsive padding, changes the button positioning to relative.

AI verifies the fix:

observe({what: "screenshot"})
observe({what: "errors"})
observe({what: "vitals"})

The AI sees the updated screenshot — form fits the viewport, button is visible. No new errors. LCP dropped to 1.8s.

Total time: under 60 seconds. The AI saw the problem, understood the visual context, wrote the fix, and verified it — all without you describing anything beyond “looks broken on mobile.”

The AI as a Design-Aware Developer

Traditional AI coding assistants are blind to the visual result of their work. They can reason about code, but they can’t reason about what the code looks like when rendered.

With Gasoline, the AI becomes design-aware:

Visual Feedback

observe({what: "screenshot"})

The AI takes a screenshot after every significant change. It can compare before and after, catch layout regressions, verify that a modal actually appeared, confirm that an error banner is gone.

Performance Feedback

observe({what: "vitals"})

Every navigation and interaction includes Web Vitals. The AI knows if a change improved or degraded LCP, CLS, or INP. No separate performance testing step — it’s built into the development loop.

Error Feedback

observe({what: "errors"})

After every change, the AI checks for console errors. A CSS change that accidentally breaks a JavaScript selector? Caught immediately. A component that throws on re-render? Caught before you even look at the page.

User Experience Feedback

interact({action: "list_interactive"})

The AI can verify that all expected interactive elements are present, visible, and accessible after a change. Did the redesign accidentally hide a button? The AI knows.

Turning Feedback Into Polish

Here’s where it gets powerful. You’re not just fixing bugs — you’re refining the product at high speed.

You: “The dashboard feels cluttered. Make it cleaner.”

The AI screenshots the page, identifies the visual elements, and starts making targeted changes:

Increases whitespace between sections
Reduces the number of visible metrics (hides secondary ones behind a toggle)
Simplifies the header
Screenshots after each change to compare

You: “Better, but the chart is too small now.”

The AI adjusts, screenshots, verifies. Three iterations in the time it would have taken to write one Jira ticket describing the problem.

This is the Loveable model of development — rapid visual iteration where the AI handles implementation and you guide the direction. Every critique becomes a fix becomes a verification in under a minute.

Real-Time Issue Detection

The AI doesn’t just respond to your feedback — it proactively catches issues through Gasoline’s continuous capture:

During development

The AI monitors observe({what: "errors"}) and observe({what: "vitals"}) as you browse. It can interrupt with: “I noticed a new TypeError appearing on the settings page — it started after the last commit. Want me to investigate?”

After deployment

Run your natural language test scripts against production:

1. Navigate to the homepage
2. Verify no console errors
3. Verify LCP is under 2.5 seconds
4. Click "Sign Up"
5. Verify the form loads without errors
6. Navigate to /dashboard
7. Verify the WebSocket connects successfully

If anything regresses, the AI has the full context: the error, the network state, the visual state, the performance metrics. It can start debugging before you even know there’s a problem.

Cross-browser and cross-device

Take a screenshot on desktop, then tell the AI to check the responsive viewport:

interact({action: "execute_js",
          script: "window.innerWidth + 'x' + window.innerHeight"})

The AI can systematically check different viewport sizes and report visual issues at each breakpoint.

The Compound Effect

Each individual capability — screenshots, error checking, Web Vitals, interactive element discovery — is useful on its own. But the compound effect is what transforms development speed:

Traditional Loop	Gasoline Loop
Write code	Write code
Switch to browser	AI checks browser automatically
Visually inspect	AI analyzes screenshot
Open DevTools if something looks wrong	AI already checked errors
Check Network tab	AI already checked network
Describe problem to AI	AI already knows the problem
Wait for AI suggestion	AI already wrote the fix
Apply fix, repeat	Fix is applied, verified, and committed

The traditional loop has 8 steps with human bottlenecks at each one. The Gasoline loop has 3 steps that run at machine speed.

What This Means for Teams

Designers and PMs become directly effective. They describe what they want in natural language. The AI implements and verifies it in real time. The feedback loop between “I want this to look different” and “it looks different” drops from days (designer → Jira ticket → engineer → PR → deploy → review) to minutes.

Engineers focus on architecture, not pixel-pushing. The AI handles the visual iteration while engineers work on the hard problems — data models, system design, performance optimization, security.

QA shifts from catching bugs to preventing them. When the AI verifies every change visually and functionally in real time, bugs get caught at the moment they’re introduced — not three sprints later when QA runs the regression suite.

Product velocity compounds. Faster feedback loops mean more iterations per day. More iterations mean better product quality. Better quality means less time spent on bugs and more time on features. The cycle accelerates.

The Bottom Line

The gap between “AI can write code” and “AI can build products” is context. An AI that can see the browser, check the errors, verify the visuals, and confirm the performance isn’t just a coding assistant — it’s a development partner that operates at the speed you think.

Gasoline provides that context. Four tools, zero setup, everything the AI needs to see your product the way your users see it.

The fastest development teams in the world will be the ones where the feedback loop runs in seconds, not days. That future starts with giving the AI eyes.

Why AI-Native Software Development Is the Future

Feb 7, 2026

Brenn Hill

Software development is shifting from human-driven to AI-native. Tools built for AI agents — not adapted for them — will define the next era of engineering productivity.

Three Eras of Developer Tools

Era 1: Manual. Developers wrote code in text editors, debugged with print statements, and deployed by copying files to servers. The tools were simple because the human did most of the work.

Era 2: Assisted. IDEs added autocomplete, debuggers added breakpoints, CI systems automated testing. The tools got smarter, but the human was still driving.

Era 3: AI-native. AI agents write code, debug issues, run tests, and deploy changes. The tools are designed for agents as the primary user, with humans supervising and directing.

We’re at the transition between Era 2 and Era 3. Most tools today are Era 2 tools with AI bolted on — an IDE that can call an LLM, a debugger that can explain an error. They work, but they’re limited by interfaces designed for humans.

AI-native tools are different. They’re built from the ground up for machine consumption — structured data instead of visual interfaces, autonomous operation instead of click-by-click interaction, continuous capture instead of on-demand inspection.

What “AI-Native” Means

An AI-native tool is designed with the assumption that its primary user is an AI agent, not a human.

Characteristic	Human-native tool	AI-native tool
Interface	Visual (GUI, dashboard)	Structured (JSON, API)
Data capture	On-demand (open DevTools, look)	Continuous (always capturing)
Query model	Navigate menus, click tabs	Declarative queries with filters
Error context	Stack trace on screen	Error + network + actions + timeline bundled
Interaction	Mouse and keyboard	Semantic selectors and tool calls
Scaling	One human, one screen	One agent, unlimited parallel queries

Chrome DevTools is a human-native tool. It shows data visually, requires clicking through tabs, and captures data only while you’re looking at it. If an error happened before you opened DevTools, it’s gone.

Gasoline is an AI-native tool. It captures everything continuously, stores it in queryable ring buffers, and serves it through structured MCP tool calls. The AI doesn’t need to “look” at the right moment — the data is already there.

Why This Matters Now

AI coding agents are getting better fast. Claude, GPT, Gemini — they can write functions, fix bugs, refactor code, and understand architecture. But they’re bottlenecked by context.

An AI agent that can only see your source code is like a mechanic who can only read the manual. Give them the manual and the ability to hear the engine, see the dashboard, and turn the steering wheel, and they can actually diagnose and fix the problem.

Browser telemetry is that missing context. When an AI can see:

What errors the browser is throwing
What the network requests look like
What the WebSocket messages contain
What the page looks like visually
How the user interacted with the app

…it can go from “I think the bug might be in the auth handler” to “The auth handler returns 200 but with a null user object because the session expired between the WebSocket reconnect and the API call.”

The AI doesn’t guess. It observes, reasons, and acts — because the tools give it the data it needs.

Adapted vs. Native

Most browser debugging tools today are adapted — human-native tools with an MCP wrapper. They take Chrome DevTools Protocol, expose it through MCP, and hope the AI can work with it.

The problem with adaptation:

CDP was designed for DevTools UI. It assumes a human is navigating panels and clicking through tabs. An AI gets a firehose of unfiltered data.
On-demand capture misses context. If the error happened before the AI connected, it’s gone. Human-native tools assume someone is watching.
No semantic structure. CDP returns raw protocol data. The AI has to interpret Chrome-internal formats instead of working with structured, meaningful data.

AI-native tools are designed differently:

Continuous capture. Data is buffered from the moment the page loads. When the AI asks “what errors happened?”, the answer is always there.
Pre-assembled context. Error bundles include the error, the network calls around it, the user actions that triggered it, and the console logs — all correlated and packaged for the AI.
Semantic interaction. Instead of “click the element at position (423, 187)” or “click #root > div > button:nth-child(3)”, the AI says click text=Submit. The tool resolves the selector.
Declarative queries. Instead of “subscribe to the Network domain, enable, wait for requestWillBeSent”, the AI says observe({what: "network_bodies", url: "/api/users", status_min: 400}).

The Development Cycle Accelerates

When tools are AI-native, the development cycle gets shorter at every stage:

Debugging

Before: Developer opens DevTools, reproduces the bug, reads the console, checks the network tab, copies the error into the AI, explains the context, gets a suggestion, tries it, checks again.

After: AI observes the browser continuously, sees the error with full context, identifies the root cause, writes the fix, verifies it works — while the developer reviews the PR.

Testing

Before: Engineer writes Playwright tests, maintains selectors, debugs flaky tests, updates tests when UI changes, runs CI, reads test output.

After: Product manager writes test in natural language. AI executes it against the live app with semantic selectors. Tests break only when product behavior changes.

Demos

Before: Engineer scripts the demo, rehearses, recovers from mistakes, rebuilds for each audience.

After: Anyone writes a natural language demo script. AI drives the browser with narration. Replay anytime.

Monitoring

Before: Set up Datadog/Sentry/LogRocket, configure alerts, read dashboards, correlate events manually.

After: AI continuously observes the browser, catches regressions in real time, correlates errors with network failures and user actions automatically.

What Comes Next

The shift to AI-native development tools is just starting. Here’s what the trajectory looks like:

Now: AI agents use MCP tools to observe and interact with browsers. Humans write prompts and review results.

Next: AI agents chain multiple tools autonomously — observe a bug, write a fix, run the tests, generate a PR summary, request review. The human reviews the outcome, not the process.

Eventually: AI agents maintain entire product surfaces — monitoring production, catching regressions, generating fixes, deploying safely, and escalating only when human judgment is needed.

Each step requires tools that are designed for autonomous operation. Tools that capture data continuously, expose it structurally, and enable interaction programmatically.

Building for the Agent Era

Gasoline was built AI-native from day one. Not “DevTools with an MCP wrapper.” Not “Selenium but the AI types the commands.” A tool designed for agents:

Four tools, not forty. The AI picks the tool and the mode. No sprawling API to navigate.
Continuous capture. Data is always there. The AI never misses context.
Structured output. JSON responses with typed fields. No parsing HTML or reading screenshots to understand data.
Semantic interaction. text=Submit instead of #root > div > button:nth-child(3).
Zero setup. Single binary, no runtime, no configuration. The AI’s environment starts clean.

The future of software development isn’t “humans using AI tools.” It’s “AI agents using AI-native tools, supervised by humans.” The tools you choose now determine whether you’re building for that future or maintaining for the past.

Why Natural Language Is the Best Way to Write Tests

Feb 7, 2026

Brenn Hill

Test scripts written in English are more readable, more maintainable, and more accessible than any test framework. Here’s why natural language testing with Gasoline MCP is the future.

Tests Are Supposed to Be Documentation

The original promise of testing was simple: tests describe what the software should do. If someone new joins the team, they read the tests and understand the product.

That promise died somewhere between page.locator('.btn-primary').nth(2).click() and await expect(wrapper.find('[data-testid="modal-close"]')).toBeVisible().

Nobody reads test code to understand the product. They read it to figure out why CI is red.

Natural language testing brings the promise back. A test that says “Click ‘Add to Cart’ and verify the cart shows 1 item” is documentation that runs.

Everyone Can Read It, Everyone Can Write It

A Playwright test requires JavaScript knowledge, framework familiarity, and understanding of CSS selectors. The audience for that test is maybe 5 people on your team.

A natural language test requires knowing what the product should do. The audience is everyone — product managers, designers, QA, support, executives, and engineers.

Test: Password Reset Flow

1. Click "Forgot Password" on the login page
2. Enter "user@example.com" in the email field
3. Click "Send Reset Link"
4. Verify the page shows "Check your email"
5. Verify no errors in the console
6. Verify the API call to /api/auth/reset returned 200

A product manager wrote that. A designer can review it. QA can run it. An engineer can debug it when it fails. Everyone works from the same artifact.

Maintenance Costs Drop to Near Zero

Traditional test maintenance is a tax on velocity. Every UI change risks breaking tests. Teams either spend hours fixing selectors or stop running the tests entirely.

Natural language tests break only when the product behavior changes — and that’s exactly when you want them to break.

UI Change	Playwright breaks?	Natural language breaks?
Button class renamed	Yes	No
Form restructured	Yes	No
CSS framework swapped	Yes	No
Component library upgraded	Yes	No
Button text “Submit” to “Register”	No	Yes — intentionally
Checkout flow adds a step	No	Yes — intentionally

The test breaks when the product changes. It doesn’t break when the implementation changes. That’s the correct behavior for an acceptance test.

AI Fills the Gaps You’d Forget

When you write a Playwright test, you write exactly what you coded. Nothing more. If you forgot to check for console errors, the test doesn’t check for console errors.

When an AI executes a natural language test with Gasoline, it has access to the full browser state. You can write:

5. Verify no errors on the page

And the AI calls observe({what: "errors"}) to check the console, and looks at the page for visible error messages, and can check observe({what: "network_bodies", status_min: 400}) for failing API calls.

You described the intent. The AI was thorough about the implementation.

Tests Match How You Think About the Product

Product people think in workflows: “The user signs up, gets a welcome email, clicks the confirmation link, and lands on the dashboard.”

Engineers think in selectors: “Click #signup-btn, fill input[name='email'], submit the form, wait for [data-testid='welcome-modal'].”

Natural language tests match the product mental model, not the implementation mental model. This means:

Acceptance criteria become tests directly. The criteria in your Jira ticket are the test. No translation step.
Test reviews are product reviews. When a PM reviews a test, they’re reviewing product behavior, not code.
Gap analysis is intuitive. “We test the happy path but not the error case” is obvious when tests are in English.

Deeper Verification Than Code Can Express

With Gasoline, the AI can verify things that are awkward or impossible in traditional test frameworks:

8. Verify the WebSocket reconnects after the connection drop

The AI calls observe({what: "websocket_status"}) and checks the connection state. Try writing that in Selenium.

12. Verify the page loads in under 3 seconds

The AI checks observe({what: "vitals"}) for LCP. No performance testing library needed.

15. Verify the page is accessible

The AI runs observe({what: "accessibility"}) for a WCAG audit. No axe-core setup needed.

Natural language lets you describe what matters. The AI and Gasoline figure out how to measure it.

The BDD Promise, Finally Delivered

Behavior-Driven Development (BDD) tried to solve this problem with Gherkin syntax:

Given the user is on the login page
When they enter valid credentials
Then they should see the dashboard

But Gherkin still required step definitions — glue code that mapped English to implementation. Someone still had to write Given('the user is on the login page', () => page.goto('/login')). The maintenance burden just moved.

With Gasoline, there are no step definitions. The AI is the step definition. It reads “the user is on the login page” and navigates there. No glue code. No mapping layer. No maintenance.

BDD was right about the idea. It just needed AI to finish the job.

When to Use Natural Language Tests

Natural language tests are ideal for:

Acceptance testing — Verify the product meets requirements
Regression testing — Re-run after deploys to catch breakage
Exploratory testing — “Navigate the settings page and verify nothing looks broken”
Cross-product workflows — “Log in to the admin panel, create a user, then switch to the customer app and verify the user can log in”
Demo verification — “Run the demo script and verify every step completes”

They complement (not replace) unit tests and integration tests. Your engineers still write fast, focused unit tests for business logic. Natural language tests cover the full-stack, end-to-end workflows that live at the product level.

The best test is the one that gets written. And the test that gets written is the one that’s easy to write.