# Mary Rose Cook Mary Rose Cook's website. I'm a staff product engineer and tech lead at Airtable in San Francisco. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Using encapsulated development to code on my phone DevFeed: [Using encapsulated development to code on my phone]() Original publisher: [Read original article]() Published: 2026-05-25T07:00:00Z Content type: article Language: en Sources: [Mary Rose Cook]() Topics: [Development](), [Code](), [test](), [developer tooling]() Tags: [code](), [development](), [devtools](), [test](), [tests]() ### AI overview The author describes using encapsulated development to code on a phone. Each prompt leaves the repository in a known, stable, verified, and stateless condition, supported by refactoring and automated end-to-end testing. ### Source excerpt I'm lucky enough to have a wife, two young children and a job as an AI Engineer at Notion. I'm also lucky enough to have a side project. Some weeks, I'll get half an hour on my laptop to work on this side project. Most weeks, I won't. Yet, I've averaged two commits to the project per day for the last three months. How? By building on my phone. But, really, by making it possible to build on my phone. The broad approach: encapsulated development. Each prompt leaves the repo in a known, stable, verified, stateless condition that permits the next change. Known My mental model of the project is functional enough that I can make future changes. This doesn't mean I understand everything. I may not know the architecture of some parts of the system. I may not know how some implementations work. But I can understand the behavior of those parts of the system as black boxes. For example, I don't know exactly how the particle system stores particles. But I do know that, when it spawns particles, it doesn't allocate new objects. Stable The quality of the software must be high enough for the next change to be successful. This means well factored, working code. Sometimes, the project will start to crumble with the accumulation of low quality code. I do a string of refactors to get things back on track, then start building features again. Verified Every change must be correct. I don't have time to manually test changes. The kettle has just finished boiling. Incorrect changes build into a wobbly tower. Each prompt must include how it will be verified as correct. This usually means end-to-end tests. For a web app, this might mean having Chrome DevTools actually click through the UI to check it works. Or spinning up the API and checking that inputs produce the expected outputs. Or going full ~StrongDM~ and implementing the external services the product interacts with. In my case, I'm working on a tool for making video games. So I built a headless version of my engine. Test code can ini ## How Fountain keeps code generation on track for browser-based mobile games DevFeed: [How Fountain keeps code generation on track for browser-based mobile games]() Original publisher: [Read original article]() Published: 2026-03-27T07:00:00Z Content type: article Language: en Sources: [Mary Rose Cook]() Topics: [AI-assisted coding](), [Code](), [Mobile](), [WebGL](), [ui](), [Canvas](), [browser]() Tags: [agent](), [browser](), [bugs](), [canvas](), [code](), [code-generation](), [computer](), [developer](), [graphics](), [interface](), [language](), [model](), [render](), [tool](), [user-interface](), [vector](), [webgl]() ### AI overview The author describes Fountain, a game-making tool that uses a predefined framework, built-in systems, manipulable user interfaces, and a constrained target domain to keep generated code aligned while creating simple mobile arcade games. ### Source excerpt About nine months ago, my son said he wanted to make a video game. He said it was called Exploding Kitties. We made it together on my computer. He described the gameplay and drew the graphics. I vibed the code. The game basically worked. But we had to build it in small pieces. And, periodically, I had to spend time in the guts of the code, getting it back on the rails. Unifying two ways of doing the same thing. Fixing gnarlier bugs. Disentangling the game code from the engine. Today, I know that we'd be able to one-shot Exploding Kitties. The first reason: models and agent harnesses produce much higher intelligence. But, the second reason, the one I want to talk about, is the supporting techniques and environment. I've built a new game-making tool called Fountain. You can one-shot any simple mobile arcade game. Or, you can iterate your way to a more complex game and the code stays on the rails over many turns. Here's why it works - A framework that supplies decisions and built-ins Every game is given a game framework upfront. This framework encodes many decisions. That game entities have a certain data shape. That behavior abstraction is done with prototypal inheritance. That the coordinates of an entity represent its top left. This keeps the code generation aligned. And this framework includes generally useful built-ins. An update/event/draw loop. A WebGL canvas render surface. A collision detection and resolution system. A particle system. A system to detect input. This reduces the amount of code that must be generated. A manipulable artifact Prompting can be tiresome. Language is ambiguous. The model can interpret a prompt in a way the game designer didn't intend, and make the wrong change. Language is clumsy. It's hard to precisely indicate any point in a continuum. A color. A point. An amount. But there's a solution. Do it the old way. Give the game developer a user interface through which to express their intent. A color picker to choose the color of the water ## When Parallelizing LLM Work Helps--and When It Does Not DevFeed: [When Parallelizing LLM Work Helps--and When It Does Not]() Original publisher: [Read original article]() Published: 2025-11-01T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Large Language Model](), [context](), [Code](), [Tool]() Tags: [agent](), [cognitive-load](), [context](), [llms](), [parallel](), [tool]() ### AI overview The author argues that switching to other tasks while LLMs generate code is usually counterproductive because context drains away, high cognitive load limits coherent task-switching, and generation is only part of the work. Parallel generation can help for long-running or self-verifying tasks, related research, and low-cost experiments. ### Source excerpt LLMs take time to generate code. I've set things up so I can switch to another task while I wait. But, surprisingly, I've found this is usually the wrong idea. First, if I switch, the context I had on the first task drains away. When I return, I'll need to load that context back. Second, if the first task has a high cognitive load, I won't be able to think coherently about anything else. Third, if the first task is my main task, I'm mostly doing other things besides generation. Drawing diagrams, thinking, reading code, composing prompts. So switching would parallelize just a fraction of my time. However, there are some cases where parallel generation is worthwhile. First, a generation that will take a long time. For example, implementing a spec.md I've created. Or a task where I have an end-to-end process where the agent can self-verify to a correct solution. Or my colleague, Simon, pasting in a to-do list of items and then going to lunch. Second, a generation for the same task I'm already working on. For example, sending an agent off to research a question about the code base. Third, fire and forget ideas with a low cost of failure. For example, giving an agent a link to a bug report it might be able to fix autonomously. Or sending the agent off to try implementing an idea I had for a new tool. Parallelizing these things works well, and is manageable. But the hectic mode of keeping several plates spinning isn't worth it. ## Using AI Coding Tools to Accelerate Test Coverage DevFeed: [Using AI Coding Tools to Accelerate Test Coverage]() Original publisher: [Read original article]() Published: 2025-11-01T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Testing](), [Test coverage](), [codex](), [Claude Code](), [Claude]() Tags: [claude-code](), [codex](), [prompt](), [review](), [test-coverage](), [testing]() ### AI overview A Notion engineer reflects on using Claude Code guidance and Codex to speed up test writing during a time-limited test-coverage sprint. The author describes prompting Codex to prioritize important or complex functions and to carry a task from a function name through creating a pull request. ### Source excerpt At Notion, we've been doing a quality sprint to increase our test coverage. Friday was the last day, and I wanted to get some more tests written. Time was short, which forced me to break my usual workflow. Not that I really have a usual workflow, these days. New AI-augmented programming tools and techniques come out every day. Everything is changing so fast that you can frequently become 10% more productive, forever, with a few minutes or a few hours invested. So, I push myself to try new things. But, inevitably, workflows are sticky. It's hard to change a habit. Extra cognitive load to monitor and refine the technique. Extra willpower to overcome the inertia of the familiar. Extra gumption to risk wasted time on something that isn't helpful. So I have my mega list of stuff to try and every few days I'll pluck something off it to try. But Friday was eye-opening. With time short, I wanted to get as much done as possible. And failure would mean only a few hours lost. We already had a bunch in place to speed things up. A Claude Code skill that my colleague, Jimmy, wrote. It laid out a careful, thorough process for writing tests. It included looking at our testing guide, tips on what to mock and an entreaty to look at surrounding test coverage. I pointed Codex at the Notion doc listing functions that needed coverage. I told it to find functions that are core parts of the system, or that have complex logic. This way, we could prioritize our time towards testing code that was important or gnarly. And, on Friday, here's the new stuff I tried - I'm rushing. Jimmy's skill is written for Claude, but I use Codex. What if I just point Codex at the skill directory in Claude's config? I'm rushing, so I have to get out of the loop. I need a process that can autonomously go from function name to PR. So I wrote a prompt with these steps: read the guidance on writing tests, write tests, create a branch, commit, review the code, refine the code, put up a PR. I'm rushing, so it's going ## Carl Sagan's Cosmos and the changing boundaries of the unknown DevFeed: [Carl Sagan's Cosmos and the changing boundaries of the unknown]() Original publisher: [Read original article]() Published: 2025-10-14T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Cosmos](), [Learning]() Tags: [cosmos](), [learning](), [space]() ### AI overview The article reflects on how Carl Sagan's Cosmos moves from the vastness of space to Earth and Alexandria, tracing humanity's transition from geographic ignorance to a world that is largely known. It then returns to space as the remaining vast unknown. ### Source excerpt Cosmos, the book by Carl Sagan, does something remarkable. It starts in a distant part of the universe. It does a slow zoom, through desolate space, through groups of galaxies, through the Milky Way, through a remote arm of the Milky Way, through the solar system, past the most distant plants, finally into Earth. It shows us as a tiny note of dust in an obscure part of the universe. Then, it moves to one of the early civilizations, in Alexandria. To Alexander's ideals of learning, his great library. It shows how, at that time, Earth was vast, unknown, many parts a mental blank. And it traces the change from that blankness to continents being connected within a human life span. Civilizations becoming known to one other. Until, finally, there are no unknown parts of Earth. No unknown continents or peoples. The rest of Earth was once other, but now it's us. The book returns to the question of space. Vast, unknown. Just like Earth once was. ## The cinch DevFeed: [The cinch]() Original publisher: [Read original article]() Published: 2025-10-14T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Large Language Model](), [Figma](), [Code](), [ui](), [Notion]() Tags: [code](), [context](), [figma](), [implement](), [llm](), [model](), [ui](), [writing-code]() ### AI overview An account of using an LLM to implement UI refinements by combining Figma mocks, existing UI code, and a concise list of relevant revisions. The added context helped focus the model on current changes despite noise in the mocks and saved substantial coding time. ### Source excerpt When generating code with an LLM, sometimes a task is so laborious to specify that you may as well do it manually. But, sometimes, you can find just the right information to cinch together to enable the model to do the work. Here's an example. At Notion, I had built some UI for a new feature. Ken, my designer colleague, reviewed the working software and updated his Figma mocks with some refinements he wanted. I needed to implement those refinements. The Figma mocks provided all the necessary information about how the UI should look and work. And the existing code represented the current state. But I couldn't just point the LLM at the mocks and tell it to implement the differences. The comparison between code and mocks was too noisy. The mocks included things we were planning for the farther future, things that were out of date, things that another engineer was implementing. But, it wasn't worth the effort of directing the LLM to do each change, one by one. Which brings me to the cinch: I realized I could combine the mocks and the current UI code with just a little bit of extra context: a terse bullet point list of the revisions. The mocks provided the full context of each change, but the bullets directed the model's attention to the relevant information. This cinch took me maybe fifteen minutes to compile, but saved hours of writing code. Seeing how to draw together the crucial information to let an LLM understand what to do. The cinch. ## Making a game with my son DevFeed: [Making a game with my son]() Original publisher: [Read original article]() Published: 2025-07-06T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [cursor](), [Claude Code](), [Code](), [Mobile](), [App](), [Programming](), [web applications](), [OpenAI]() Tags: [app](), [claude-code](), [code](), [cursor](), [mobile](), [openai](), [programming](), [web](), [web-app]() ### AI overview A parent describes making a mobile web game with her seven-year-old son using Cursor and Claude Code. Code generation shortened the feedback loop, while a prompt interface, pixel editor, and audio transcription let them modify the game together on a phone. ### Source excerpt One morning, my son woke up and came downstairs, deep in thought. He looked up at me and said, "Can we make a game, Mummy?" He's seven and he's called Jacob. He told me his game was called Exploding Kitties. He described the mechanics. Bad guys patrol up and down. If they see the player - a kitty - they laser them with their eyes and the kitty explodes. If the kitty can sneak behind a bad guy, it can scratch and kill him. I had a little game making kit already. A mobile web app. An update and render loop, game objects. I showed Jacob how to add game objects to the level. He added some red squares for the baddies and a blue square for the kitty. I can't tell you how magic it was to see him use something I made. I said, shall we make the kitty move? He said yes. I prompted Cursor, "Make it so when the player taps the screen the blue square gradually moves to where they tapped." Cursor generated the code and applied it. The mobile app, served on localhost and made available over WiFi, refreshed on my phone. Jacob tried tapping the screen and the kitty moved to where he'd tapped. In the past when we'd made games together, the programming had been too slow for Jacob to stay engaged. Now, with code gen, the feedback loop was fast enough to keep his attention. I told Cursor to add a prompt input box to the game itself. I wired up a little backend route that could receive the prompt and pipe it through for Claude Code to implement. The UI for modifying the game was now built into the game itself. Jacob and I could both work on the phone. A shared headspace through a shared device. Jacob said he wanted to draw proper pictures for the kitty and the bad guys. I typed into the phone, "Create a pixel editor on the game object properties screen. Store the pixel art on the game objects." Two minutes later, Jacob was poring over the throne, drawing the kitty in the pixel editor, enthralled. It reminded me of when my Dad and I would make icons in ResEdit on the Macintosh. After Jaco ## A Flow-Based Technique for AI-Augmented Programming DevFeed: [A Flow-Based Technique for AI-Augmented Programming]() Original publisher: [Read original article]() Published: 2025-05-23T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [AI-assisted coding](), [Programming](), [Artificial Intelligence](), [Code]() Tags: [agent](), [ai](), [code-generation](), [developer](), [programming](), [techniques]() ### AI overview The author describes a flow-based technique for AI-augmented programming: describe a feature, provide relevant code context, review generated code, let the agent fix lint and type errors, and test the feature. The author says this approach has made feature development about three times more productive and offers one-on-one coaching for professional engineers. ### Source excerpt tl;dr: I'm offering coaching sessions where I teach professional engineers a smooth, stay-in-flow technique for AI-augmented programming. All the nitty gritty tips and setup were very helpful. -- Andrew J. Email me to sign up!. Let the computer make you more productive My first job after university was working at a software company on their huge Java desktop application. The architecture, complex and winding, made the code very hard to follow. Layer upon layer of indirection meant that trying to follow the flow of execution led to cognitive overload. Fortunately, the company, though almost unflaggingly tight-fisted (bring your own cake on your birthday), bought IntelliJ for every developer. It had a feature, go to definition, where you could click on a method call and jump to the implementation. This made it possible to understand the byzantine code. Which brings me to AI. As programmers, we feel comfortable using tools to make us more productive. Generating code with AI is a natural next step in letting the computer help us. Three times more productive With code generation, building features goes much faster. I can be declarative ("add a button..."). I can get an implementation of a stock algorithm ("implement A* with this contract...") I can zoom in when I need to ("wait, don't duplicate that state..."). Programming is a craft. Getting better is the slow process of accreting little techniques and intuition. But there are some core techniques you use all the time. For example, moving in small steps to keep the code compiling. AI-augmented programming is also a craft. And there are also some core techniques. But they're different. That one I described above isn't even really a thing for AI-augmented programming. It's too low level. One core technique for AI-augmented programming, maybe the core technique - describe a feature, attach relevant code context, skim the code as it's generated, let the agent fix lints and type errors, try out your new feature. This isn't a cobble ## Using AI to build a tactical shooter DevFeed: [Using AI to build a tactical shooter]() Original publisher: [Read original article]() Published: 2025-05-05T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Artificial Intelligence](), [Programming](), [cursor](), [Large Language Model](), [Code]() Tags: [agent](), [ai](), [code](), [cursor](), [llm](), [programming](), [voice](), [workflow]() ### AI overview The author describes using AI-augmented programming to build a 2D tactical shooter with enemy behavior based on Goal Oriented Action Planning. The article also outlines a workflow involving AI-assisted planning, milestone-based implementation, voice-to-text prompting, and Cursor Agent mode. ### Source excerpt Enemy AI My latest side project is a 2D shooter where the enemies plan their attacks. I'm using a technique called Goal Oriented Action Planning. This approach was used in an old game from the 2000s called F.E.A.R. It was a sort of spooky tactical shooter. Think Rainbow Six but with that creepy girl from The Ring hanging about the place. In FEAR, the enemies could flank the player and provide suppressing fire. They could stay in cover and coordinate with each other. More side projects with AI-augmented programming Why am I making this? It seemed like it would be fun to try a structurally simple 2D game with tricky enemy AI. In the age of programming with AI, it's much easier to follow this kind of whimsy. I'm more productive and I can get to the interesting stuff more quickly. Productivity hack You know that film with Bradley Cooper*, where he takes a drug that makes him super focused and productive, but he ends up ruining his life? Well, I've found something similar. Livestreaming. If you want to trade some of your lifespan and peace of mind for some productivity, just record yourself working. It's quite stressful. You're worried about making blunders in front of other people. You can't take breaks. You definitely can't start scrolling X. But you will get a lot done. Game tape Everyone's eternally wanking on about Camp 4†. I wasn't there, but I think X might have it bested. It's awash in scenius. The field or tradecraft of AI-augmented programming is proceeding so unbelievably fast. And the best place to learn about it is in ephemera and asides crammed into tiny boxes dispensed by a misfiring slot machine. So, here is a contribution to the effluvial stream. A video of me working on the 2D shooter. You can see me plan out the project and generate the code that lays out the level, implements player movement, and implements collision detection. Pretty good for an hour and fifteen minutes. Though extemporaneous, the video outlines a powerful AI-augmented workflow for w ## Learning New Software Development Workflows with AI DevFeed: [Learning New Software Development Workflows with AI]() Original publisher: [Read original article]() Published: 2025-03-12T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Artificial Intelligence](), [Programming](), [Learning](), [cursor](), [Large Language Model](), [ChatGPT]() Tags: [ai](), [chatgpt](), [code](), [cursor](), [programming]() ### AI overview The author reflects on how AI tools such as ChatGPT and Cursor have changed software development learning and productivity. They argue that adopting AI-assisted workflows requires replacing established programming habits, which creates cognitive strain and demands active supervision. ### Source excerpt A few months ago, I started sleeping badly. I had been excited about AI since ChatGPT came out. I'd loved using Cursor to help me program since Jay had told me about it over the phone as I walked from Eureka Heights back home to Noe Valley. But, in January, something changed. The proximate cause was a flood of new AI releases. o3-mini, Deep Research, Lightpage. Every week, more intelligence dropping from heaven into my lap. But the bigger change was that I was getting more productive, faster. Type in a few sentences, get a hundred lines of code. A feeling of vertigo. More than that, I could learn a new technique in an hour and become significantly more productive. This was in stark contrast to the previous twenty years I'd spent learning to program. That was a slow, accretive grind. A new technique for encapsulation. A more refined understanding of what it means to "repeat yourself". Learning that you could step-debug a production web app. My friend, Sam, has this model of learning as building a graph. Each node is a piece of information or a skill or a behavior. They're interconnected. Acquiring a new node of knowledge isn't too hard. It's a bit harder to elaborate it. Which is to say, to connect it to the existing nodes in your graph. But the real fucker is when you have to unmake a part of your graph. You get cognitive dissonance because some of the nodes contradict each other or need to be pried apart or replaced. It's very painful to disassemble the graph and remake it. Learning to program was a lot of that. Learning to build software with AI feels completely different. It's much closer to learning a new discipline. Certainly, the old way of programming is relevant. But all the power comes from the new techniques in this new field that doesn't even really have a name. Further, a lot of the new techniques involve a new workflow. Copy code from your editor into GPT, make a request, get code back, paste it into your editor. No, don't do that any more. Instead, sta