Hi. I’m back from my summer break that I spent traveling and tinkering. Now, back to our regularly scheduled programming.
This week, I wanted to do something a bit different. Instead of deep diving into one specific idea, I’m going wide and putting together a list of my favorite mental models that guide the way I work with and understand AI. The world of AI is opaque - both the models themselves and the rapidly evolving industry around them. Mental models are a way to map the territory so you can find your way through.
Most of these models took shape in my own head through trial and error. Others I stole from my favorite people. Some are new while others are references to ideas I’ve explored in detail previously. All of them earned a place in my carefully curated toolbox that I use to get the most out of AI and to understand the discourse around it.
Organizational note - I start with more practical mental models that will help you get better outputs when working with AI agents. As you go down the list, they get a bit more meta and less “applied” - the mental models that help me make sense of how AI is changing the tech industry and the discourse around it.
The more assumptions you make explicit up front, the less time you spend cleaning up weird agent behavior later.
There’s a famous computer science thought experiment that asks you to describe how to make a peanut butter & jelly sandwich in detail to a computer. The point is that it’s very hard, and it makes you realize how much of the process lives implicitly in your head. As you can guess, it’s meant to demonstrate how explicit you need to be with your instructions to get the expected output. Any assumption that remains implicit will lead to unexpected outputs.
This is even more relevant to working with LLMs because instead of erroring out, they will replace your implicit assumptions with their own, often without telling you. Your job is to catch as many of these assumptions as possible as early as possible. This is where the “upfront” part comes in - you should invest the most energy into your initial prompt & context that defines what it is you want. There’s a lot more ROI on your effort here versus trying to steer the AI later on when it’s going down the wrong track (see next mental model). In the end, you’ll likely actually save effort.
After the initial prompt, the best way to achieve alignment is through in-depth Q&A. I have this text snippet (which I found on X a long time ago) mapped to the “.ama” shortcut on my computer:
Interview me in detail using the AskUserQuestionTool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious.
I often drop this at the end of a very long initial prompt and then spend hours answering questions. Before the model starts building anything, I will have an extremely detailed spec with 99% of assumptions made explicit. When you start building, you should continue to extract latent assumptions through workflows like these:
Thariq@trq212
been asking others at Anthropic how they stay in the loop with Claude and fully understand the work being done this is one of my favorites from Suzanne:
8:29 PM · Jun 1, 2026 · 1.38M Views
210 Replies · 689 Reposts · 10.5K Likes
When an AI run starts wrong, restarting from better context usually beats patching over a bad trajectory.
When the initial output you get out of AI is not meeting your expectations, your immediate reaction is to try to steer towards what you actually want by providing negative feedback (”here’s what’s wrong”). While chat is the right metaphor for AI overall, it does trick us into working with it like we would with a human - if there’s a misunderstanding or an error, you overcome it or fix it. That’s just natural. You don’t just hit up your coworker Jeff in another empty chat window to retry the conversation you just had.
In reality, the process is often more akin to drawing - if you get too many initial lines wrong and lean heavily on the eraser, the canvas will bear the marks of your previous errors forever and will influence your resulting composition. The best solution in this case is to crumple the paper, toss it in the bin (go Knicks!), and start over.
LLMs are extremely susceptible to path dependence - “phenomenon of past events or decisions constraining or defining later events or decisions”. Their initial errors and your turn-by-turn desperate attempts to correct them compound into muddied context and duct-taped solutions.
So - if AI’s initial output is significantly far off from your expectations, you’re better off taking a step back and rewriting your starting prompt and the context around it. If the output meets your expectations but deteriorates as you continue iterating, you need to rewind (in Codex and some other apps it’s also called Forking) to the point before the deterioration happens and try again.
S/o to Juan Ramirez for clarifying this idea for me.
Agents can handle more of the setup, testing, and browser work if you give them the same tools you use.
One of the most annoying aspects of any project is all the instrumentation - getting the API keys, provisioning certificates, permissions, etc. At this point, the agents are capable of doing 99% of those things themselves through either a CLI (ideal), MCP (good), browser control and/or computer use (ok). So, for example, if you’re hosting on Cloudflare, make sure you install Wrangler CLI and sign in (or ask the agent to do it); if you’re using Supabase as a backend, install Supabase MCP & CLI; if you need to test a web / desktop / iOS app, Codex & Claude Code can do 99% of testing for you.
Oftentimes, you can find the most popular integrations in Codex’s plugin store and easily enable them from there. Lastly, if there’s no CLI or MCP available (ask your agent), I will now often sign in to whatever dev portal I need right inside the Codex browser and tell the agent to set everything up for me - it knows where to go, what to click, and what to type.
The point is - AI can do 99% of the things you can do on a computer, so let it - give it the right tools and ask it to use them.
Early bad outputs are not just failures; they are taste signals that help you find the shape of the thing.
The current internet discourse around AI is obsessed with “one-shotting” - the elusive experience of AI nailing your idea in one turn. At best, this is just engagement bait - cool-looking dashboards get likes. At worst, this is fantasy. In practice, like any first draft in any creative pursuit, your initial output will be bad.
But hold on, didn’t I just profess above that if your initial output is bad, you better start over with a different prompt? Yes, sort of. This depends on how early AI comes into your creative process. If your vision is fully crystallized and you have exact design mockups and PRDs, then AI failing to produce your vision up to spec is a prompting and context engineering problem.
On the other hand, if you use AI earlier in your creative journey to shape your vision, bad output is creative fodder. Your negative reaction is a signal, because it helps you understand what you do not want. In the early stages, this is often even more valuable than knowing what you want. “This doesn’t feel quite right” becomes information about your own taste and the creative direction you’re looking for.
Here, again, beware of path dependence - purely reacting to bad output can set you on an inherently wrong path. Use it to make novel connections, find new paths, and map the terrain.
When the target is visual, references beat long prose prompts almost every time.
Providing visual references is a more effective way to guide visual output, whether it’s front-end work or image & diffusion models. Giving an image model one reference of what you’re looking for is way more effective than writing a 1,000-word ultra-detailed prompt describing every detail (which is quickly becoming obsolete as models get better). If you often work with AI-generated images and videos and need to iterate to get to specific results, I highly recommend you try Flora.ai - it’s effectively this principle productized inside a node-based infinite canvas. And the best way to have visual references at the ready is to become a digital hoarder:
Your reference library is becoming a machine-readable map of your taste.
In my previous issue, I argued that the best way to become a better AI-pilled designer is to become a digital hoarder and start collecting references across all modalities, not just text:
More importantly, as AI becomes more “omni”, this growing pile of references gets increasingly more valuable as it (a) encapsulates your taste and (b) serves as raw material for AI as you begin morphing your products. Imagine your taste as a very blurry image - as you collect more artifacts that align with your taste, you slowly increase the fidelity of this “taste image” for AI. And as you jump into new projects, instead of asking Claude to “make it more modern”, you will have a rich library of references to draw from. You can now steer the output away from slop and towards taste.
Design is how you keep models from collapsing into the same average-looking sludge.
This may be my 3rd or 4th time linking to this tweet, but here we go:
hilary gridley@yourgirlhils
today’s amazing new AI-designed artifacts will look like slop in a month, once everyone learns to recognize the patterns the model falls back on. like AI-generated writing, the output isn’t objectively “bad,” (in fact it is often technically quite good), but once it becomes
Claude @claudeai
Introducing Claude Design by Anthropic Labs: make prototypes, slides, and one-pagers by talking to Claude. Powered by Claude Opus 4.7, our most capable vision model. Available in research preview on the Pro, Max, Team, and Enterprise plans, rolling out throughout the day.
1:50 PM · Apr 18, 2026 · 62K Views
40 Replies · 38 Reposts · 587 Likes
Without opinionated guidance, every model, however amazing, will regress towards the same patterns that we will recognize as slop. As designers, we’ll always have a job in steering models away from it.
Use one model to pressure-test another so your review bandwidth is not the bottleneck.
The more you work with AI, the more you find yourself to be the bottleneck of the process - your work moves as fast as you can define new tasks and review the output. While we’re still nowhere close to stepping out of the loop completely, you should start using AI to critically review the output for you before you have to review it yourself. This is called adversarial review - when you get one LLM to critically review the work of another model, specifically focusing on finding flaws, vulnerabilities, edge-case failures, etc. As someone wrote on Reddit, “adversarial reviews are stupidly easy and unfairly useful”.
In theory, you could do this with one LLM and get it to review itself, and Claude Code already has presets like /simplify and /review. But using a different model for an adversarial review helps you avoid one model’s blind spots and apply two different “intelligence shapes” to the same problem, giving you a broader coverage overall.
When I use Claude Code, I like to use the /codex plugin, and performing an adversarial review is as easy as tacking this onto your prompt: “Perform an adversarial review on your implementation plan with /codex, resolve the critical issues, and keep reviewing until no issues come up”. For a more manual setup, ask your main model to write a prompt for an adversarial reviewer, then pipe whatever output you want reviewed (a plan, a PRD, a migration spec, etc) together with that prompt into another model, and pipe the results back into the main model.
The only thing to be aware of here - adversarial reviews increase the chances of over-engineering, so you still need to keep an eye on the type of issues it’s flagging and set clear parameters - for example, specifying whether this has to be production-ready for a large user base or it’s an MVP prototype for a personal app.
Cheap execution should make you more ambitious, not more trapped in old MVP instincts.
The idea of the “MVP” is the product of the world where development is expensive in terms of time and money. For most of software, this is no longer true, and so the old idea of the MVP no longer holds the same meaning. There’s still value in the overall concept, but this is for another article.
The point is that we’ve been trained to be extremely diligent and selective with each small change, feature, and idea when deciding what to actually build. By extension, AI models have been trained to think the same way since they’re just the representations of the open internet up to now. This is why they always propose ways to make your project smaller, phase it out, shave down the MVP, and then estimate that it’ll take 2 weeks to develop (it’ll take 20 minutes).
You need to push against this thinking and in the opposite direction - you need to think bigger and get AI to do the same. In the overview of my Hermes & Obsidian setup, I wrote:
I’m always experimenting and throwing crazy use cases at my agent. Half the time, it fails miserably and I learn about the limits of the current models, my own tooling, or process. The other half of the time, I’m surprised and even stunned, like when it paid my bill on the first try from a photo or gave me a perfect analysis of my handstand form from a video.
Swapping your default from MVP thinking to always-on ambition has 3 positive outcomes:
More often than not, you’ll actually get the desired output. It dramatically raises the bar for what you can do.
It lets you get a visceral feel for the edges of the model and the shape of its intelligence. If you only use it for well-scoped, straightforward tasks, you’ll never know what it’s capable of. It’s like buying a Ferrari and never taking it out on track. The only way to understand the shape of something is to find its edges, and you can never find the edges if you don’t push against them.
It will calibrate your understanding of what you can build. And instead of wasting your time worrying about scope, you can shift your attention to more fundamental areas where AI is still weak (understanding the problem space, branding & taste, etc).
The more an agent can check its own work, the later you need to jump in.
As we already discussed, you’ll quickly find yourself to be the bottleneck when working with AI. Another crucial way to scale yourself is to give AI the tools to verify its own work against the spec so it has an internal feedback loop that it can run until it satisfies all the criteria you set for it. The more aspects of the work it can verify itself, the later you can come into the process to provide more high-level feedback vs resolving debug errors or pixel pushing.
For example, if you’re building a web app, make sure it has access to Chrome, internal browser (like in Codex), and/or Playwright. Ask it to write tests and verify the output visually. If you have a Figma spec, hook it up over MCP and ask it to explicitly compare it against the build. If you’re building an iOS app, tell it to build the app after every change and resolve any error before handing it off to you. You get the idea.
As you get into this mindset, you can start pushing this further by keeping it in a loop until it meets certain criteria. For example, I wanted AI to recreate the UI of my native macOS app on the web, so I put it in the loop where it (1) takes screenshots of my app, (2) builds it on the web, (3) compares the screenshot to the web version and scores the resemblance, and (4) starts over until a certain score is met:
Mete Polat@metedata
This worked astonishingly well - after a 107 self-evaluated iterations by Codex, I now have a full HTML recreation of my native app - all from the screenshots it also took itself. Will be great for use in landing page visuals, future design explorations, etc. Anyone interested in
Mete Polat @metedata
This issue - recreating your design / system in html for an existing native app - turned out to be very persistent. So I got Codex to build an auto-research loop where it takes a screenshot of my app, compares it to the html recreation, scores it, and iterates until it's 99%. https://t.co/0Nc5Kv43JV
3:11 PM · May 7, 2026 · 31.9K Views
11 Likes
When an agent makes a mistake, codify the lesson so you do not step on it again.
As you push agents to their limits, they will inevitably make mistakes. Each time that happens, build a habit of explaining the mistake to them and what the desired output was. Depending on your agent, it’ll save it into memory, like AGENTS.md, CLAUDE.md, or whatever memory system you may use.
Many agents like Hermes have self-improvement systems where they’ll review chat logs to do this automatically. This is going to become more prevalent and implicit, but it’s still a good practice to develop yourself.
LLMs do not have judgment; they have a very compressed version of consensus.
As the saying goes, “If you want to build a mediocre product, ask everyone what they think.” Asking AI what it thinks is basically the same as asking everyone.
An important insight to internalize about LLMs is that asking questions in the form of “What do you think about X?” or “What should I do about Y?” is effectively the same as asking “What is the internet (all training data) consensus on X or Y?”
This is not an opinion or a critique. It’s just an accurate (at a high level) mental model that helps you use it better and get more out of it - like asking better questions. This is why your own judgment (or taste or whatever you want to call it) is still your edge.
Good AI work is less about magic wording and more about clear direction, rich context, and knowing what good looks like.
When AI started gaining traction, “prompt engineering” was all the rage. And for a second there, it did seem like we all had to become AI-pilled literary wordsmiths where each turn of phrase could mean life or death (ok I’m being a bit dramatic). In reality, this turned out to be largely irrelevant - the exact syntax matters much less than knowing what you want, giving the model the right context, and recognizing what good looks like.
That said, the exact wording can still make a difference in a few cases. For example:
If you want to implement a very specific visual / motion effect, you need to generally be able to name it (or get the agent to understand it) like cubic-bezier, spring, etc. There are some great resources for this like this one.
LLMs are still fundamentally biased towards the content in the beginning and end of the prompt.
But again, with a clear vision and sufficient back-and-forth, you can find alignment with the agent without the exact words. As models improve, they get exponentially better at understanding latent intent without us having to find just the right words. The value is quickly shifting to the human parts: framing the problem, choosing the direction, and knowing what good looks like.
The less you know about the domain, the more dangerous impressive AI output becomes.
Karri said it best:
Karri Saarinen@karrisaarinen
A common dynamic I observe with AI: it feels most impressive when you don’t know much about the subject, don’t care or don’t have a clear idea of what the you want. This applies across design, code, legal, and more. If I don’t know code very well, every piece of code it writes
3:45 PM · Apr 25, 2026 · 573K Views
257 Replies · 392 Reposts · 3.45K Likes
If you’re working with AI on something way outside your usual domain expertise and you’re impressed with the output - think twice. Develop skepticism, look deeper, and seek additional verification where possible.
Tool-using agents become risky when private data, untrusted content, and external communication meet.
An important framework pioneered by Simon Willison on his blog:
If you are a user of LLM systems that use tools (you can call them “AI agents” if you like) it is critically important that you understand the risk of combining tools with the following three characteristics. Failing to understand this can let an attacker steal your data. The lethal trifecta of capabilities is:
Access to your private data - one of the most common purposes of tools in the first place!
Exposure to untrusted content - any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)
If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.
Whether you’re instrumenting your own AI agents on a local machine / VPS or giving ChatGPT access to your email, you need to understand the attack surface you’re creating.
As execution gets cheaper, choosing the right direction becomes the real craft.
This seems almost obvious, but as a principle I found it surprisingly hard to convey the essence of it. The obvious part - execution in software used to be expensive. You needed specialized talent, significant time, tight coordination, tons of process. A lot of our time, effort, and talent differentiation hinged on this complexity. Now, execution is becoming commodified. The process, coordination, and time still matter but quite a lot less. What matters now is deciding what to build, what direction to move in, and what good looks like. This always mattered. Now it’s (almost) the only thing that matters.
The analogy that really helps me understand this is music. Since humans digitized sound, any conceivable melody can be constructed on your laptop without needing years of education. I have the same tools as Daft Punk at my fingertips. I can put together a coherent cacophony in no time. But I’m unlikely to ever put anything together that will touch people’s souls to the same degree.
The other side of this coin is that mistakes are more expensive. Speed compounds both good direction and bad judgment.
A lot of SaaS AI transformation makes more sense once you stop seeing apps as tools and start seeing them as coworkers.
If you want one mental model to help you understand why all the SaaS tools you know are converging towards the same-looking tool with a chat bar at the front of it, this is the one. Most discourse around this shift is rooted in a wrong mental model. From my (unsurprisingly controversial) article:
The problem with this critique is that it’s grounded in the world of tools. And these are no longer just tools. Let me explain.
The best framework that bridges the past and the future here is Jobs-To-Be-Done: customers don’t buy your tools - they hire them to get a job done. Each SaaS app was effectively a toolbox. Our job as designers was to understand the job at hand, surface the right tools in a given context, and make those tools easy to use so you can accomplish the job. With LLM agents, a SaaS app is now more akin to a coworker that goes out and does the job. And how do you talk to a coworker? You chat with them.
The loudest AI debates often behave more like belief systems than evidence-based arguments.
I really liked this post from Benedict Evans:
People who are determined to believe that AI is fake move the goal posts almost as much as people who talk about AGI. First none of this works, then it works but it’s useless, then no one will pay for it, then they’re paying for it but not enough, then they’re paying $100bn this year, but it’s not profitable yet, and then…
Once I started understanding both of these camps as religions, things began making more sense. You don’t argue with religious people about whether god is really up there and whether the bible is accurate (if you are, good luck). In the world of religious fervor, you’re better off being a keen observer. You don’t have to join a church to form your own understanding.
The places where AI frustrates you are often the places new products and workflows need to exist.
This mental model is about reframing your frustration that’s inherent in building with AI. From my issue #12:
In summary, forming realistic (or even low) expectations when technological capabilities are opaque and rapidly evolving is basically a fool’s errand. It’s even more foolish to think one can push these capabilities forward without a vision rooted in high (often unreasonable) expectations. So if we agree that you have to operate on high expectations, we also must accept that the frustration arising from the capability gap is inherent to the process. … All this neatly leads me to the crux of my realization - the frustration is the opportunity. This is the space where we’ll need new tools, better harnesses, better orchestration, better processes, and sound judgement.
Frustration is information. Pay attention and see it as a new space to build, innovate, and educate others.
Before building a SaaS idea, ask whether a smart person with an LLM could already fake most of it.
This is less a mental model and more of a good question to ask for every new SaaS idea you might have - how hard is this to replicate for a smart person with an LLM? In more and more cases, the answer will be “very easy”. That doesn’t mean you shouldn’t build it. It just means that you’ll be differentiating on things beyond execution - convenience, brand, distribution, cost, speed, etc. It’s something I have to remind myself because building is often the most fun part, but now it’s the least important part. So if you’re committing to a new idea, understand where the differentiation will live and, hence, where most of your effort should go.
Programming note: the posts now will land once every two weeks without a specific day commitment. I’m carving out more time to build. Putting out a dence high-quality post weekly was taking away from my focus quite a bit.
What I’ve been up to: I’ve been traveling, I modded an iPod, and designed a website for my wife’s new ice-cream company (launching imminently), and getting deeper into some of the AI agent usecases I’ve been exploring (in particular exploring productizing some of them). I’ve read a few great books and recommend this one in particular - The Yahoo Boys: Love, Deception, and the Real Lives of Nigeria’s Romance Scammers. I generally consume any book / podcast on the topic of scamming, conning, and hacking and this one is easily in my top 3.
I want to ask you for a favor - if you’ve been enjoying the newsletter, please consider sharing it with your team / colleagues / friends. It really helps, especially in these early stages as I’m posting into the social media void and looking for like-minded people. To those who already shared - thank you, it means a lot. See you next week.