Agents perform well on greenfield code because their intuition is usually enough, but brownfield systems contain unseen code paths and dependencies that break that intuition.
2
Agents become more trustworthy when they can reproduce bugs, inspect screenshots and logs, restart services, and interact with the application before declaring a task complete.
3
Engineers will spend more time building the tools, code structure, and knowledge bases that let agents verify their own work.
Summary
Johan Lajili argues that the difference between successful and disappointing agent use is often the feedback loop, rather than whether the project is greenfield or brownfield. In a new codebase, an agent's intuition is often enough to produce plausible code. In an old system, unused code, hidden dependencies, and unexpected behavior can make that intuition unreliable. Lajili describes Spoolside, an internal CLI at Poolside AI that gives an agent access to screenshots, compressed page snapshots, service logs, restarts, application navigation, messages, and image uploads. This lets the agent reproduce a bug and test its fix instead of merely claiming that the code should work. He says engineers will increasingly build these support systems as CLIs, skills, or MCPs, while also improving the codebase and its documentation. The goal is to prevent faster agents from multiplying unverified errors, especially when running agents overnight or at larger scale.
The feedback loop explains much of the gap between successful and failed agent use
Lajili opens with the sharp difference between people who say AI does everything for them and people who get garbage in a production app. He rejects the idea that the whole difference comes from greenfield versus brownfield work, since he has seen AI work well in legacy applications. In a greenfield project, the agent's intuition is often correct: it writes a component or service and expects it to work. Brownfield systems contain dead ends, unused code, and relevant behavior in parts of the codebase the agent has not inspected. The practical difference is the feedback loop that tells the agent when its assumptions are wrong.
An agent claiming success may only mean that its limited evidence looked plausible
When an agent says it has implemented an auth flow and everything is working, Lajili interprets that statement narrowly. It means the change seems correct given the agent's abilities and the information it received. Sometimes the agent has verified the result, and sometimes it has not. Users who check the result can send the agent back to inspect logs and try again. Users who see the first failure as proof that AI is incompetent may stop using it. Lajili says better testing can close this gap and give people a reason to trust the agent's work.
Spoolside gives an agent eyes and operational access to a VS Code extension
Lajili describes Spoolside, a CLI he created at Poolside to test applications. It can take screenshots and compressed snapshots of what is happening on a page, similar to capabilities he mentions from G Stack. Poolside's application is a VS Code extension rather than a normal web page, so accessing its state requires extra work. Spoolside also extracts front-end and back-end logs, restarts services, opens specific menus or pages, sends messages to the agent, waits for replies, and uploads images. These actions let the agent interact with the application instead of reasoning only from source code.
Bug reproduction should happen before the agent proposes a fix
Lajili's test for an agent working on a bug is simple: reproduce the bug first. Agents are eager to suggest a margin change or another code edit, but he does not trust the diagnosis until the problem appears in the running application. With the right tools, the agent can reproduce the issue, make a change, and test the result. Without that loop, the agent may still guess correctly, but the engineer has to verify every claim manually. That prevents the engineer from safely leaving the agent running overnight.
Engineers need to build the systems that make agent work easy to check
Lajili says the point of Spoolside is not for every engineer to download that particular tool. Each team should build the support layer that fits its product and problem. It might be a CLI, a skill, or an MCP. Engineers can also change the codebase so agents can work on it more easily, and improve the knowledge bases the agents use. Their work shifts toward making the AI operate effectively on the product, rather than focusing only on implementing product features.
Agent speed becomes dangerous when verification does not keep up
Lajili says engineers need to make sure increased agent velocity does not multiply or compound errors. They should make it easy to inspect what the AI produced and verify it. He compares this to putting on an oxygen mask before helping a child: the engineer should first make the AI able to sustain and check its own work. He accepts that this may slow development at first. The investment becomes useful when teams run multiple agents or leave them working over time.
Human-like testing can expose problems that rigid automated tests miss
In the question period, Lajili says automated tests can feel too rigid, unpredictable, and difficult to maintain. He prefers tests that mimic how a person would use the application. When he notices a UI problem, such as a button being too far left, he tries to make the AI detect it independently instead of simply telling it the answer. He recommends reviewing logs for repeated smells, such as inserting sleep calls everywhere or repeatedly running Storybook, because those patterns may indicate that the system needs a proper wait condition or clearer feedback.
The right interface depends on the product the agent is testing
Lajili asks engineers to design agent access around the product itself. A game made in Unity may need a useful representation of its 3D world rather than an ASCII dump. A product with many permissions and login states should make those identities easy for the agent to use. This is part of the engineer's new responsibility: deciding what the agent needs to see, which actions it needs to take, and what evidence will let it recognize a failure without being handed the answer.
"The difference is that with greenfield, the agent's intuition is correct."01:47
Who should watch
You are using coding agents on a legacy application and need them to test changes instead of making plausible guesses.
You want to run agents for longer periods or use several agents without manually checking every claim they make.
Your product has a difficult UI, many permissions, service dependencies, or other behavior that source code alone does not describe.
