Talk by Johan Lajili (Poolside AI) arguing that AI agents without adequate input or perception are effectively "blindfolded," and that providing them with better "eyes" — richer, higher-quality input — can substantially improve both agent performance and trust in their outputs. # Video Identity Observations: "Your agent is blindfolded — Johan Lajili, Poolside AI" ## Speaker & Channel Affiliation - Speaker introduces himself as **"Joan [Johan] from Poolside"** and describes the company as: > "one of the handful of companies that are making their own foundational model from scratch, their own LM and coding agents." - This is an **explicit self-description claim** by the creator/representative, positioning Poolside AI as a foundational-model and coding-agent builder. ## Format & Setting - The talk appears to be a **conference presentation** (~5–8 minute lightning-talk format: "that's me done with two minutes to spare"), part of a multi-day event: > "everybody is somewhat talked about it in the background of the talks we've seen over the past three days." - Includes a **Q&A segment** at the end (audience question about automated tests), indicating live event delivery. ## Intended Audience - **Practicing software engineers using or evaluating AI coding agents**, evidenced by: - References to Reddit/Twitter discourse on AI coding ("I'm never touching code anymore" vs. "it produces absolute garbage"). - Terminology assumed familiar: brownfield/greenfield, VS Code extensions, MCP, CLI, Storybook, logs. - Direct framing of the audience's future role: > "I think we're all going to become AIX engineers essentially." ## Claimed Scope of Content - **Core thesis**: The difference between successful and failed AI agent use is the **feedback loop** — agents on greenfield projects have correct intuition; on brownfield projects "there be dragons." - **Demonstrated internal tooling**: A CLI called "Spoolside" built at Poolside that lets agents test applications (screenshots, snapshots, log extraction, service restarts, message/send/wait interactions with the VS Code extension). - Explicit disclaimer about tool scope: > "the point of this is not Spoolside. It's not something you're going to find on GitHub to use for yourself. It's to build your own." ## Self-Description vs. Demonstrated Presentation - **Creator claims**: Poolside builds foundational models and coding agents from scratch; their internal AI can interface with and test their own product. - **Observable demonstration**: Practical engineering advice (reproducing bugs before fixing, avoiding `sleep(15)` "stinks", retrospective log review with AI, product-specific tooling design), delivered from a practitioner's perspective with first-person experience cited ("We've seen people using AI in legacy applications with good success. I have myself."). - **Opinion clearly labeled as personal preference** where applicable: > "I guess that is a personal preference. But I do feel like automated tests can be sometimes a bit too rigid." ## Notable Positioning Statements - **Shift of engineering roles**: "we are going to have to focus less on the product and more on trying to make the AI work on the product." - **Trust-building as theme**: "This is a first step to trust... I don't trust it and then I'm going to have to go and verify it myself." - Uses an **analogy to airline oxygen masks** to argue for making AI self-sufficient before feature work. ## Summary The video presents **Poolside AI as an AI-native developer-tools company** through a conference talk aimed at engineers, blending company self-description (foundational model builders) with demonstrated practitioner insight on agent feedback loops and verification tooling. No channel-level claims beyond the company affiliation are made; the talk self-identifies as opinion and personal experience in its Q&A portion. # Delivery Observations: Johan Lajili — "Your agent is blindfolded" ## Tone and Register - **Conversational, self-deprecating humor**: When introducing his tool, he jokes: *"Yeah, I might be good at programming. I'm not good at naming things."* — referring to the name "Spoolside." - **Casual, direct address to a developer audience**: Opens with *"Hi everyone. So I'm Joan from Poolside"* and invites the audience to engage with the company: *"Check us out if you if you're not aware some cool stuff."* - **Blunt, opinionated framing**: States disagreement plainly: *"But personally, I think that doesn't quite hold up. We've seen people using AI in legacy applications with good success. I have myself."* - **Emphatic trust language**: Repeats *"I don't trust it"* and *"until it reproduces the bug, I don't trust you"* — a strong recurring stance rather than hedged phrasing. ## Vocabulary and Framing - **Metaphors for the unfamiliar/dangerous**: Uses the classic programming phrase *"there be dragons"* to describe brownfield code, and calls the talk's premise an agent that is effectively **"blindfolded"** (per the title). - **Aviation safety analogy as the closing argument**: *"It's a bit like when you're in an airline and they say, oh, you put your mask on yourself before you fit… your mask on your children. It's the same with AI. You need to put the mask on the AI."* - **Domain vocabulary**: greenfield/brownfield, "feedback loop," "MCP," "CLI," "skill," "token compressed," "storybooks" — grounded in engineering jargon, used without explanation, suggesting an expert audience. - **Introduces a coined role**: *"I think we're all going to become AIX engineers essentially."* ## Teaching Habits and Structure - **Contrasting viewpoints as an opening device**: Sets up two strawman reactions to AI skepticism: *"One way is to say, this guy is a shill from open AI… Or this one is an entity that doesn't care about anything and is just like lying."* Then refutes a more charitable explanation (greenfield vs. brownfield) to arrive at his thesis: **the feedback loop is the real difference**. - **Anthropomorphizing the agent to make a point**: Voices the agent: *"yeah, I've implemented the new auth flow and it's all working perfectly"* then translates: *"What the agent means really is, well, to the best of the of my capabilities, to the best of what you have given me, that sounds like it should work."* - **Explicitly disclaims the tool as the takeaway**: *"The point of this is not Spoolside. It's not something you're going to find on GitHub to use for yourself. It's to build your own."* — teaching a principle, not promoting a product. - **Practical advice in the Q&A**: Offers a repeatable method: *"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"* and a log-review heuristic: *"ask an AI, did you notice any issues… Are you doing sleep for instance? Calling sleep parentheses 15 everywhere is a stink."* ## Communication Patterns - **Disfluency through repeated words**: Frequent doubled words in the transcript, e.g., *"in in in the background," "to to understand," "on that on that"* — rapid, unscripted delivery. - **Rhetorical questions to structure the argument**: *"So what's the difference? What's the difference really between brownfield and greenfield?"* - **Explicit time awareness**: Closes with *"And that's me done with two minutes to spares"* and later *"I think we're it for time"* — suggests a rehearsed, time-boxed talk. - **"I think" as a recurrent hedge**: Appears many times (*"I think that's the difference," "I think we can make this still better," "That's what I think anyway"*) — a stable verbal tic marking personal-claim framing. ## Uncertainty Notes - The transcript contains no timestamps beyond bracketed line markers, so patterns like pacing, pauses, or gestures **cannot be observed** from this source. - The speaker's name appears as both "Joan" (self-introduction) and "Johan" (title); the exact pronunciation cannot be verified from text. - Audience reaction (laughter at the naming joke, etc.) is **not recorded**, so humor delivery success is unconfirmed. # Observation Record — "Your agent is blindfolded" (Johan Lajili, Poolside AI) ## Speaker Identification - **Johan Lajili** (introduced as "Joan from Poolside"; title metadata gives "Johan Lajili"), speaking at what he describes as a multi-day conference event. Speaker identification comes from the title metadata and his self-introduction in the transcript. ## Stated Positions and Reasoning ### 1. Divergent AI experiences among users - Claim: People using AI report "vastly different experiences" — some say "I'm never like touching code anymore," others say on production apps "it produces absolute garbage." - He offers three candidate explanations: - Bad faith: "this guy is a shill from open AI trying to sell you AI" or "an entity that doesn't care about anything and is just like lying." - Greenfield vs. brownfield: greenfield apps are "nice and easy," while legacy "brownfield" applications are complicated and "agents are not there yet." - His preferred explanation: **the difference is the feedback loop** — "that's the difference with getting these results." ### 2. Skepticism of the greenfield/brownfield explanation (qualification preserved) - He explicitly rejects the brownfield-is-too-hard framing: "personally, I think that doesn't quite hold up. We've seen people using AI in legacy applications with good success. I have myself." - His reasoning on the real difference: - **Greenfield**: "the agent's intuition is correct" — if it writes components and services as expected, it works. - **Brownfield**: "there be dragons" — dead ends, unused code, dependencies in parts of the codebase the agent "hasn't even looked at." ### 3. Interpretation of agent claims of success - When an agent says "I've implemented the new auth flow and it's all working perfectly," what it really means is: "to the best of my capabilities, to the best of what you have given me, that sounds like it should work." - Qualification: "Maybe the agent was able to verify its work. Maybe it wasn't. But as far as it knows, it's working." - This explains the user cleavage: skeptics conclude "you cannot trust the AI" and give up; others respond iteratively ("check those logs or whatever"). ### 4. Tooling: "Spoolside" CLI - He built an internal Poolside CLI tool (self-deprecatingly named: "I might be good at programming. I'm not good at naming things") enabling agents to test applications. - Capabilities described: - Screenshots and token-compressed **snapshots** of application state (comparable to "G stack" / GStack, as he references it). - Their application is a **VS Code extension**, not a web page, requiring an extra step. - Log extraction from backend/frontend services, service restarts, high-level commands (access a menu, navigate to a page, message the agent, wait for reply, upload an image). - Explicitly not a product: "It's not something you're going to find on GitHub... It's to build your own." ### 5. Reproducing bugs as a precondition for trust - Position: "until it reproduces the bug, I don't trust you," even though agents are "very eager" to jump straight to fixes. - Reasoning: without reproduction, he must verify the fix himself, "wasting time," and cannot "start running it overnight." Reproduction is "a first step to trust." ### 6. Redefined engineering role ("AIX engineers") - Claim: engineers' new role is "to focus less on the product and more on trying to make the AI work on the product." - Means: building such tools (CLI, skill, or MCP — his choice of CLI is "a personal preference" for simplicity), improving the codebase and knowledge bases. - On the shift from "product engineers" (2025): as AI gets good, the goal is "making sure that velocity is not a trap" — avoiding multiplied or compounded errors, and making verification easy. - Analogy: airline oxygen masks — "You need to put the mask on the AI... make sure that it's self-served before you try to work on features," even if it slows you down now; "it's an investment that pays off as soon as you start multiplying agents." ## Q&A Positions (unidentified questioner; answers from Lajili) ### On preferring ephemeral/human-like testing over automated tests - "I think they're quite ephemeral... that is a personal preference." - Reasoning: "automated test can be sometimes a bit too rigid and hard to predict... I like something that mimics the way I would test it like a human would." ### On making the AI notice problems itself - Even when he can see an issue (e.g., "the button is a bit to the left"), he withholds telling the agent directly: "What I want is the AI to realize that by itself," then steps back to design ways for the agent to self-detect. ### Retrospective log review - After repeated loops, review logs with an AI: "did you notice any issues, any stink?" - Example smell given: calling `sleep(15)` repeatedly suggests something should be waiting on a condition instead; repeated redundant actions (e.g., "running storybooks" over and over) are similar flags. ### Product-specific tool design - Engineers should tailor interfaces to their product: "If you're making, say, a game in Unity, like do you want an ASCII representation of your 3D world for your AI?" If the product has many permissions/logins, make those easy for the AI to use. - Conclusion: "It's really your new role to think about all that. That's what I think anyway." ## Qualifications and Tensions Noted - He flags his brownfield-vs-greenfield analysis as partly resting on personal experience ("at least on my own experience"). - The ephemerality of tests and the CLI choice are both explicitly labeled personal preference, not universal prescriptions. - No contradicting speaker appears; the questioner's question itself is not preserved in the transcript. # Speaker Attribution & Provenance Record ## Video - **Title:** Your agent is blindfolded — Johan Lajili, Poolside AI - **Video ID:** `01a15ca8-afac-7d16-b06f-fbc908358d0d` ## Speakers ### Johan Lajili (introduced as "Joan" in transcript) — **Speaker / Presenter** - Self-introduces: *"I'm Joan from Poolside"* (title identifies him as **Johan Lajili, Poolside AI**; transcript spelling "Joan" vs. title "Johan" is a transcription discrepancy, not resolved by source). - Role: **Creator-side presenter** delivering a talk, apparently at a multi-day conference (*"the talks we've seen over the past three days"*). - Also handles an **audience Q&A** segment at the end (question not captured; only his answer is in transcript). ### Unidentified audience member(s) - At least one audience question is implied by the speaker's answer, but the question itself is **not present in the transcript**. ### Narrator - None present. ## Promotional Segments - **Flagged — company promotion** at talk opening: *"I'm Joan from Poolside... we're one of the handful of companies that are making their own foundational model from scratch, their own LM and coding agents. Check us out if you're not aware."* ## Referenced Sources & Third-Party Claims (as cited by speaker) - **Reddit / Twitter anecdotes:** secondhand reports of divergent AI coding experiences — claims not attributable to specific users and unverifiable from this source. - **G stack:** referenced as prior art for screenshot/snapshot tooling. - **VS Code:** mentioned as the platform his product's extension runs within. - **Storybooks, Unity, MCP:** mentioned in passing as tooling/concepts; no substantive sourcing. - **Poolside internal CLI tool "Spoolside":** described by speaker as internal, explicitly **not released** — *"not something you're going to find on GitHub to use for yourself."* ## Speaker Claims of Personal Experience - Personal success using AI on legacy/brownfield applications (*"I have myself"*). - Authorship of the "Spoolside" CLI tool at Poolside. ## Availability & Limits - **Comment availability:** no metadata supplied; unknown. - **Curated metadata:** none beyond title; speaker identity partially established by title vs. transcript ("Johan Lajili" vs. "Joan"). - **Audience questions:** not captured; only answers present. - No timestamps present in transcript; no external sources cited beyond those listed above. \>\> Hi everyone. So I'm Joan from Poolside. If you haven't heard of us, we're one of the handful of companies that are making their own foundational model from scratch their own LM and coding agents. Check us out if you if you're not aware some cool stuff and you should hear more soon. But what I want to talk to about today is this. You have people seeing AI and using AI and getting vastly different experiences. If you're on Reddit, if you're on Twitter, you're going to see people that say, oh yeah, I'm never like touching code anymore. The AI is is doing everything for me. It's fantastic. And others that say, what are you talking about? I'm trying it in my production app. It produces absolute garbage. What are you guys working on to do apps? What are you doing? And there is multiple ways to try to to understand what's going on there. One way is to say, this guy is a shill from open AI trying to sell you AI. Or this one is an entity that doesn't care about anything and is just like lying. He didn't even try it. Another is to say, well, maybe someone is working on a greenfield app and that's nice and easy. Whereas someone else is working on brownfield on a legacy application. That's complicated and agents are not there yet. But personally, I think that doesn't quite hold up. We've seen people using AI in legacy applications with good success. I have myself. So at least on my own experience, I know that can work. So what's the difference? What's the difference really between 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 going to work. I I think that's going to be fine. And he's right cuz it has very good intuition. On brownfield, however, there be dragons. You're going to have things that the agent is not expecting. Maybe you know, like dead ends, code that's not used anymore, things that it is not aware of in in different part of the code that it hasn't even looked at. And that's where the big difference between those two is the feedback loop. And everybody is somewhat talked about it in in in the background of the talks we've seen over the past three days. But I think that's the difference with getting these results. So you you've got your agent that says, yeah, I've implemented the new auth flow and it's all working perfectly. What the agent means really is, well, to the best of the of my capabilities, to the best of what you have given me, that sounds like it should work. 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 going to see that first quote, see that it's indeed not working and just sees, you know, I'm a liar, I'm incompetent or like you cannot trust the AI. 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? It's not working agent. Can you try again? Check those logs or whatever. Whereas those ones are just going to give up. But I think we can make this still better. At Poolside, I've created a little CLI tool called Spoolside. Yeah, I might be good at programming. I'm not good at naming things. That basically allows it to test our applications effectively. Some of the stuff you've already seen in things like G stack for instance being able to take screenshots of the applications, being able to take a snapshot, that is to say like a very token compressed version of what's going on on a web page and use it. But our application is not a web page. It's an extension within VS code. So already lucky takes an extra step to get there. But with that, our AI can interface with it just like it would with a normal web page. But we take it further. We have thing to extract logs from different services, from the back end, from the front end, ways to restart different services, high level commands. Can you access a specific menu? 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 like somewhat efficiently and a bit like we've talked with coding tools this morning. And that's pretty useful cuz 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. The agents are very eager. Yeah, 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, I don't trust you. 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 going to 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. This is a first step to trust. And the point of this is not Spoolside. It's not something you're going to find on GitHub to use for yourself. It's to build your own. I think as engineers, that's our new role. We are going to have to focus less on the product and more on trying to make the AI work on the product. How can we make it easy for it? 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. You can implement this as a CLI, as a skill, as an MCP. In my case, it's a CLI cuz 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. But yeah, I think in 2025, we had product engineers 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 or compound errors, that 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. And so I think we're all going to become AIX engineers essentially. And yeah, it's a bit like when you're in an airline and they say, oh, you put your mask on yourself before you fit you put your your mask 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. Even if it slows you down right now, it's an investment that pays off as soon as you start multiplying agents and running things over time. And that's me done with two minutes to spares. So thank you very much. Any question from anybody? Yes. I think they're quite ephemeral in the sense 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. So I like something that mimics the way I would test it like a human would go and test the application. The way I find those is in the first stage where I work with the AI, I try even though, you know, like I can see that the button is a bit to the left and I want to tell the AI that. What I want is the AI to realize that by itself. 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. Another thing is re-attractive loop. After you've done that many times, look past over your logs, ask an AI, did you notice any issues, any any stink? Are you doing sleep for instance? Calling sleep parentheses 15 everywhere is a stink that like there is something that should be wait for whatever like a comment that could be there. Is there anything that you keep doing over and over like running storybooks? And another thing is really think about like your own product. If you're making, say, a game in Unity, like do you want an ASCII representation of your 3D world in for for your AI? If you're making something with lots of permissions, different logins that your AI can take very easily. It's it's really your new role to think about all that. That's what I think anyway. And I think we're it for time. Thank you very much. \>\> \[music\]