AI Engineer Europe 2026
Your agent is blindfolded
Read the talk
Your agent is blindfolded
Coding agents need a way to see failures, operate the application, and verify repairs. Johan Lajili shows how application-specific tooling makes that feedback loop possible.
From a talk by Johan Lajili
Why does AI coding work for one developer and fail for another?
How can one developer stop touching code while another gets unusable changes in a production application? Johan Lajili, an engineer at Poolside, opens with this split in experience. Poolside builds its own foundation models and coding agents, but the problem is familiar across tools: one developer celebrates having AI do everything; another asks whether those successes amount to little more than to-do apps.
It is easy to dismiss the enthusiast as selling AI or the skeptic as someone who never really tried it. A more useful explanation distinguishes greenfield projects from brownfield applications: starting fresh seems easier than changing a system with years of accumulated decisions. Yet Lajili has used AI successfully in legacy applications. The age of the codebase alone does not explain the difference.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Plausible code needs feedback
In a new application, an agent's expectations often fit the environment it is creating. Put a component here, add a service there, and the resulting structure may work as expected. An existing application contains surprises: a promising code path may no longer be used, or behavior may depend on another part of the repository the agent has not inspected.
| Environment | What the agent can miss |
|---|---|
| Greenfield | Whether its newly created structure actually behaves as expected |
| Brownfield | Dead code, hidden dependencies, and existing behavior outside its inspection |
The distinction makes the feedback loop decisive. Intuition can suggest an implementation, but observations must establish whether that implementation works in this application.
When an agent announces that a new workflow works perfectly, its confidence is bounded by the capabilities and information it received. It may have verified the result; it may only have produced something that looks correct. A user who discovers a failure can supply logs and ask for another attempt, keeping the loop moving. Another user may conclude that the tool cannot be trusted and stop. The engineering opportunity is to let the agent obtain that corrective evidence itself.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent access to the application
At Poolside, Lajili built an internal CLI called Spoolside to let agents test the application. Its inspection capabilities include screenshots and snapshots: compact representations of what is on a page that an agent can consume without the full page content. He compares these capabilities with gstack.
Poolside's application is a VS Code extension, so ordinary webpage access is not enough. Spoolside supplies the additional access machinery that lets the agent interact with the extension much as it would with a webpage. It then extends that access across the running system:
- Service evidence: Extract logs from frontend and backend services.
- Service control: Restart services when needed.
- Navigation: Open a particular menu or go to a particular page.
- Conversation workflows: Send a message, wait for the agent's reply, send a follow-up, and upload an image.
These higher-level operations can be composed into a workflow. The agent gets both a way to act and a way to observe what happened.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reproduce the failure before proposing the fix
Application access changes where debugging starts. An eager agent may immediately suggest adding a margin or inserting some code. Lajili wants it to reproduce the bug before editing. That establishes that the agent can reach the failing state and recognize the problem it is trying to solve.
An intuitive fix might still be right. But if the agent cannot inspect the result, a human must verify it. That burden limits how much work can be delegated and makes unattended overnight runs difficult to trust. Reproduction is a first step toward that trust, not evidence that overnight autonomy has already been achieved. Spoolside itself is not offered as a reusable GitHub project; the recommendation is to build equivalent access for your own application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make verification part of the working environment
This shifts some engineering effort from directly building the product to making the product easier for an agent to work on. Better tools are one part of that investment. A more navigable codebase and better knowledge bases also help the agent understand what to change and how to check it. The interface can be a CLI, a skill, or an MCP integration. Lajili chose a CLI for simplicity; the appropriate form depends on the application and the problem.
More output is useful only if errors do not compound with it. Lajili contrasts the product engineer of 2025 with a proposed role he calls the AIX engineer: someone who makes it possible for AI to build the product reliably. That includes making verification easy and presenting the agent's work so a human can review it.
His analogy is the airline oxygen-mask instruction: equip the AI to help itself before asking it to work on more features. Building that capability may slow immediate feature delivery, but he expects the investment to pay off as more agents use the environment over longer periods.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Where do exploratory checks meet committed tests?
The audience asks where mechanical primitives such as screenshots and logs end and checked-in unit or integration tests begin. Should these checks be temporary, or should they become tests that always run?
Lajili describes his checks as fairly ephemeral and explicitly treats that as a personal preference. He sometimes finds automated tests too rigid and difficult to maintain, and favors tooling that lets the agent explore an application as a human tester would.
Consider a button that is visibly too far to the left. The immediate temptation is to tell the agent exactly what is wrong. Instead, Lajili steps back and asks what would let the agent discover the misplacement itself. The missing capability may be more consequential than the individual correction: once the agent can observe this class of problem, it needs less human intervention on subsequent tasks.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find missing commands in the agent's logs
After several rounds of work, inspect the interaction history. Lajili suggests asking an AI to review past logs for recurring issues and repeated actions. Repeated sleep(50) calls are a useful signal: the agent may be compensating for a missing command that waits for a particular condition. Repeatedly starting Storybook can similarly reveal a workflow worth packaging into a reusable operation.
The useful abstraction is a named readiness condition with a bounded wait. For example, this TypeScript helper lets an application-specific probe decide when an operation can continue:
typescript
async function waitFor(
description: string,
isReady: () => Promise<boolean>,
timeoutMs = 10_000,
): Promise<void> {
const deadline = Date.now() + timeoutMs;
while (Date.now() < deadline) {
if (await isReady()) return;
await new Promise<void>((resolve) => setTimeout(resolve, 100));
}
throw new Error(`Timed out waiting for ${description}`);
}
The short polling delay controls how often the probe runs; it does not decide whether the application is ready. A reply-wait command, for example, should proceed when the reply is available rather than after an arbitrary pause. This illustrates the missing-command pattern, without assuming a particular Spoolside API.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose an interface that fits the product
The right observation surface depends on what you are building. For a Unity game, Lajili proposes considering an ASCII representation of the 3D world: a representation the agent can inspect as it reasons about the environment. For an application with extensive permissions, it may need easy access to different logins so it can experience the product under different roles.
Those choices remain an engineering responsibility. A screenshot, a world representation, and a role-specific session expose different kinds of evidence. Build the access that lets the agent discover the failures your product can actually have.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Browser commands for screenshots, accessibility snapshots, page interaction, and verification workflows.
Use component stories for interactive development and automated UI testing.
Further reading
Poolside’s account of the infrastructure behind training, evaluating, and iterating on its foundation models.
How browser actions wait for visibility, stability, and other readiness conditions before proceeding.
Read the complete timestamped transcript
- 0:00
[upbeat music] Um, hi everyone.
- 0:16
So I'm Johan, uh, from Poolside. Uh, if you haven't heard of us, so we are one of the handful of companies, uh, that are making their own, uh, foundational model from scratch, uh, their own, uh, LLM, uh, and coding agents.
- 0:31
Uh, check us out if you're, if you're not aware of some cool stuff and, and you should hear more soon. Um, but what I want to talk to about today, uh, is this: you have people seeing AI and using AI and getting vastly different experiences.
- 0:48
If you're on Reddit, if you're on Twitter, you're going to see people that say, "Oh, yeah, I'm, I'm never, like, touching code anymore. The AI is the, is doing everything for me.
- 0:56
It's fantastic." Uh, and others that say, "What are you talking about? I'm trying it in my production app. Uh, it produces absolute garbage. Uh, what are you guys working on to-do apps?
- 1:07
Uh, what are you doing?" And there is multiple ways to try to, to understand what's going on there. One way is to say, "Oh, this guy is a shill from OpenAI trying to sell you AI," uh, or, "This one is an empty that doesn't care about anything, and he's just, like, lying.
- 1:23
He, he didn't even try it." Another, um, is to say, well, maybe someone is working on a greenfield app, and that's nice and easy. Uh, whereas someone else is working on brownfield, on a legacy application.
- 1:36
That's complicated and agents are not there yet. But personally, I think that doesn't quite hold up. Um, we've seen people using AI in legacy applications with good success. I have myself, so at least on my own experience, I know, uh, that can work.
- 1:54
So what's the difference? What's, uh, the difference really between, um, brownfield and greenfield? The difference is that with greenfield, the agent's intuition is correct. The agent's writing the code and expect, you know, if I write the components here, if I write the service, it's gonna work.
- 2:12
I, I, I think that's gonna be fine. Uh, and he's right 'cause it has very good intuition. Uh, on brownfield, however, uh, there be dragons. Uh, you're gonna have things that the agent is not expecting.
- 2:24
Um, maybe, you know, like dead-ends code that's not used anymore. Uh, thing that it's not aware of in, in different part of the code that it hasn't even looked at.
- 2:33
And that's where the big difference between those two is the feedback loop. And everybody has sort of like somewhat talked about it in, in, in the background of the talks we've seen over the past three days, um, but I think that's the difference with getting this result.
- 2:48
So you've, you've got your agent that says, "Yeah, I've implemented the new overflow, and it's all working perfectly." What the agent means really is, well, to the best of the capa- of my capabilities, to the best of what you have given me, that sounds like it should work.
- 3:05
Maybe the agent was able to verify its work, maybe it wasn't. But as far as it knows, it's working. If you're a skeptic of AI, you're gonna see that first quote, see that it's indeed not working and just says, you know, "I'm a liar, I'm incompetent," or like, "You cannot trust the AI."
- 3:25
Uh, and that's, I think, where this cleavage in between those two type of users. Like, the first category is going to see some things. "Oh, yeah, actually, you know what?
- 3:34
It's not working, agent. Uh, can you try again? Check those logs or whatever." Uh, whereas those ones are just going to give up. But I think we can make this still better.
- 3:44
Um, at Poolside, uh, I've created a little CLI tool called Spoolside. Yeah. Um, might be good at programming and not good at naming things. Um, that basically allows it, uh, to test our applications effectively.
- 3:59
Some of the stuff you've already seen, uh, in things like JSTAC, for instance, being able to take screenshots of the applications, uh, being able to take a snapshot, uh, that is to say like a very token-compressed, uh, version of, of what's going on, on a webpage and use it.
- 4:14
But our application is not a webpage. It's an extension within VS Code. So already, like, it takes an extra step to get there. Um, but with that, our AI can interface with it just like it would with a normal webpage.
- 4:29
But we take it further. Uh, we have thing to extract logs from different services, from the backend, from the frontend, ways to restart different services. Uh, high-level commands. Can you access a specific menu?
- 4:42
Can you go to this page? Can you send a message to the agent, wait for it to reply, send another message, upload an image and do that, and it can stack things, uh, like somewhat efficiently, um, a bit like we've talked with, uh, coding tools, uh, this morning.
- 4:57
Um, and that's pretty useful 'cause then the agent is able to test what it's doing. If it's working on a bug, it can actually reproduce the bug before it starts working on that, on that.
- 5:10
The agents are very eager, "Yeah, I, I know what's going on. You just need a margin there. You just need to go and add this code." But until it reproduces the bug, uh, uh, I don't trust you.
- 5:21
And that's the big thing. It's maybe without that, the agent is able to still have good intuition and fix the issues, but I don't trust it, and then I'm gonna have to go and verify it myself, and I'm wasting time, and I cannot then take that agent and start running it overnight, for instance.
- 5:37
Uh, this is a first step to trust. And the point of this is not, um, Spoolside. It's not something you're gonna find on GitHub to use for yourself. It's to build your own.
- 5:48
I think as engineers- Um, that's on your role. Uh, we are going to have to focus less on the product and more on trying to make the AI work on the product.
- 6:02
How can we make it easy for it? Uh, that can be those tools, that can be improving the code base so that it's easier to work on, that can be improving knowledge bases.
- 6:12
Uh, you can implement this as a CLI, as a skill, as an MCP. In, in my case, it's a CLI 'cause I like things simple. But, like, there are many different variations of it, and I think it's going to be different from people to people and problem to problem.
- 6:24
But yeah, I think in, uh, 2025, we had product engineers, uh, that were, you know, like, very focused on doing everything with the product. But now that AI is getting quite good, you want to focus more on making sure that that velocity is not a trap, that you're not going to multiply errors, uh, or compound errors, that
- 6:48
you're going to actually verify what you're doing, making it easy for you to, to verify as well with, like, presenting the work that the AI done and everything around that.
- 6:58
And so I think we're all going to become AIX engineers, uh, essentially. And yeah, it's a bit like when you're in an airline, uh, and they say, "Oh, you put your mask on yourself before you feed...
- 7:12
You, you put your, your mask on, on your children." It's the same with AI. You need to put the mask on the AI. You need to make sure that it's self-served before you try to work on features.
- 7:20
Even if it slows you down right now, it's an investment, uh, that pays off as soon as you start multiplying agents, uh, and running things over time. And that's me done with two minutes to spares.
- 7:33
So thank you very much. Uh, any question from anybody?
- 7:38
Yes.
- 7:39
Thanks for the talk. Um, when you're thinking about what to put in the CLI, it sounds like you have a bunch of base primitives. For example, screenshots, logs, et cetera.
- 7:48
Um, where do you draw the line? Or what's your mental model for building those mechanical primitives versus putting together, like, checking in, for example, unit tests or integration tests?
- 8:00
Like, how ephemeral are these things relative to actually, at limit, like, checking them in and always running them?
- 8:07
I, I, I think they're quite ephemeral in the sense... A- and that, I guess, is a personal preference, but I do feel like automated test can be sometimes a bit too rigid and hard to predict and hard to, like, work over time.
- 8:21
So I like something that mimics the way I would test it, like a human would go and test the application. The way, uh, I find those is, um, in the first stage where I work with the AI, um, I draw.
- 8:34
Even though, you know, like, I can see that the button is a bit m- to the left, and I want to tell the AI that, what I want is the AI to realize that by itself.
- 8:43
So whenever I encounter that sort of problem, I take a step back and try to think on how to make the AI realize the problem by itself. Uh, another thing is retroactive loop.
- 8:53
Uh, after you've done that many times, look past over your logs, ask an AI, "Oh, did you notice any issues? Any, like, um, um, any sync?" Or you're doing sleep, for instance.
- 9:03
Calling sleep (50) everywhere is a thing that, like, there is something that should be wait for whatever, like a comment that could be there. Uh, is there anything that you keep doing over and over, like running storybooks?
- 9:16
Um, and another thing is really think about, like, your own product. If you're making, say, a, a game in Unity, like, uh, do you want an ASCII representation of y- of your 3D world in, uh, for, for your AI?
- 9:30
If you're making something with lots of permissions, uh, different logins that your AI can take very easily. It's, it's really on your role to think about all that. That's what I think anyway.
- 9:39
And I think we're it for time. Thank you very much. [outro music]