The Daily Model

The button was gone. Not hidden behind a menu, not collapsed into a hamburger icon. Gone. And the code that rendered it looked perfectly fine.

This is the kind of bug that lives in the gap between what source says and what a screen shows. A responsive layout quirk, a viewport assumption, a CSS rule that only fires at one screen width. You can read the diff line by line and find nothing wrong, because nothing in the logic is wrong. The problem only appears when someone actually looks at the running application on the device where it breaks.

Greptile, a startup that builds AI agents for code review, says it has a way to close that gap. In a customer story published by OpenAI on October 26, 2026, co-founder and CEO Daksh Gupta describes using GPT-6 Astra's computer-use capability to go beyond reading pull requests and instead test the running application itself (OpenAI). The concrete example Gupta gives: Greptile starts a development server for a pull request, resizes the browser to an iPhone-sized viewport, simulates a user moving through the application, and uses the model's visual understanding to inspect the screen and spot the hidden button.

The pitch is speed. "A QA firm testing all of your changes is just impractically slow considering how fast we're able to ship code with these models," Gupta says in the same piece. The argument is that AI-assisted development has accelerated shipping faster than human QA can keep up, so the testing layer needs to accelerate too.

Greptile also describes using Daybreak to strengthen security and connecting its codebase Knowledge Base to Codex through an MCP server, tracking how often AI-generated code gets reverted as a measure of whether context reduces rework. Gupta claims thousands of customers have made that Codex connection.

All of this comes from an OpenAI-published customer story, which means every performance claim originates from Greptile's CEO without independent verification. There are no published false-positive rates, no comparison against human QA teams, no data on how often the visual inspection misses what it's supposed to catch. The iPhone-button example is specific and plausible, but it is a described capability, not a benchmarked result.

Still, the underlying observation holds regardless of how well any particular tool executes it. The most stubborn bugs are the ones invisible in source. They need a screen, a viewport, a user's thumb. If computer-use models can reliably simulate that looking, the testing bottleneck shifts from whether someone checks to how many checks can run at once.

The button that wasn't there needed someone to look. The question now is whether a machine can look well enough, and often enough, to matter.