135 posts tagged with “tools”

I’ve intentionally covered loops a lot this week. It’s been the talk of the virtual town of late, so it’s an important concept to understand as AI-assisted software design and development continues to mature.

MC Dean pulls it all together practically for designers in this piece. She reminds us that designers need to stay in the conversation; be in the room where it happens:

The conversation about AI and design tends to run in one direction: here are tools you can use to do your job faster. That framing keeps designers in the task loop. Tools help you execute. The loop stack shows you where the real work is.

The real work is authoring the system loop. Writing the specifications that constrain how AI behaves. Encoding the quality standards that define what good output looks like. Making the judgment calls that no loop below the oversight layer can make on its own.

Taking a “loop stack” built by engineers, she adapts it for designers:

At the base: the execution loop. The model fires, tool calls happen, tokens generate. This is genuinely not your concern. You don’t need to understand transformer architecture to design well with AI, any more than you need to understand TCP/IP to design a good website.

One layer up: the task loop. The agent works on a specific thing until a condition is met, then stops. Who defines that condition? You do. “The task is complete when the output meets the brief” is a design decision. What counts as meeting the brief is yours to specify.

Then the product loop. This is the experience layer, the thing a person actually encounters. Does the flow hold together? Does the output feel like it belongs to a coherent system? Does it match the quality bar? Every heuristic you’ve ever learned, every design principle you’ve internalized, lives here.

Then the system loop. This is where the AI gets better, or doesn’t. The patterns it learns, the constraints it operates within, the values it embodies. Design systems, behavioral specifications, brand guidelines, content principles, tone of voice. Everything you’ve encoded about what good looks like. This is the layer that trains the loops below it.

At the top: the oversight loop. This is where human judgment lives permanently. Not as a checkpoint at the end. Not as a review gate before launch. As a continuous presence that can redirect anything in the stack at any time.

This is what we call “craft”.

In the full post, she shares a prompt for you to try that illustrates how the loop actually works. Go try it.

The interesting part of agent loops isn’t how to keep an agent running. It’s knowing when the work is understood well enough to let it run.

Peter Yang, interviewing Claude Code’s Thariq Shihipar on Behind the Craft, asks about Claude Code’s new loop, goal, and workflow features. Shihipar describes /goal less as an autonomy switch than as a signal that the uncertain work has already been done:

/goal is great when you have a complicated task and need to make sure it is done at the end. It’s the user indicating, “I’ve done enough specification and exploration. I understand the problem space. Just go execute on it, and if you run into something, fill it in.”

That puts a useful boundary around loop engineering: don’t ask the agent to power through ambiguity you haven’t investigated. Shihipar treats planning as the work of reducing that ambiguity:

We often talk about plans as one shot: you plan, then you do something, and that’s it. But planning is an iterative process of exploring, investigating, and finding out what you don’t know and what you want.

A few minutes later, he gives that process a better name:

I like to call it getting rid of your unknowns. With almost any task, there’s a lot you don’t know—either how things work or what you want. It’s very iterative. You don’t write it all down once and then implement it. There are many steps and different passes.

Implementation doesn’t end that process. Shihipar asks the agent to keep notes about what it discovers while building, then feeds those discoveries back into the specification:

The model can find things that it—or you—didn’t anticipate during implementation. I ask it to keep implementation notes as it goes: what did we not expect about this implementation? Once we have that, we can respec if needed. It’s much less one handoff from specification to implementation and more a back-and-forth process.

That’s the more useful loop: explore until “done” is concrete, build the smallest version that can expose what the plan missed, then revise the plan from what the build teaches you. Longer-running agents are the consequence, not the point.

Quotes lightly edited for clarity.

Jihoon Jeong asks the question: if the model starts fresh each cycle, what actually compounds? He uses software developer Geoffrey Huntley’s Ralph Wiggum loop to illustrate:

If the loop’s power came from looping — from persistence of effort, from the agent grinding away at the problem — then the longer you could keep one agent going, the better it should get. The opposite is true, and every practitioner knows it. A long agentic session curdles as its window fills with dead ends and stale state; the agent gets worse with continuity, not better. The winning configuration, rediscovered by everyone who runs loops at any scale, is maximum discontinuity: kill the agent every iteration, resurrect it blank, and let it inherit nothing except what the last iteration wrote to disk. Huntley’s design wasn’t naive. It was surgical. Discard the mind, keep the files.

Fresh context is only useful if the loop can tell progress from activity. Jeong puts that burden on the verifier:

Second, one of the five decisions is load-bearing in a way the others aren’t. The verifier is the wall the whole structure hangs on. A loop repeats whatever its verifier accepts; if the verifier is strong — tests, compilers, benchmarks, anything with teeth — the loop compounds progress, and if the verifier is weak, the loop compounds output. Every experienced loop practitioner converges on the same rule: the loop is exactly as good as its stopping test. A loop with a weak verifier isn’t an autonomous engineer. It’s an expensive random walk with excellent posture.

Jeong’s answer is that the model starts each cycle from scratch, while plans, tests, commits, and code preserve progress for the next one:

The loop works, and the skeptics are right about why its working is strange. It adds no intelligence. It makes no model smarter. It rents the same brilliance every cycle at full price, extracts what it can, and throws the brilliant thing away — keeping only the residue on disk, because the residue is the only part that compounds. It works better than it has any right to, exactly as I said last time. And its characteristic failure mode is now visible at scale too, and it is not a crash. It’s a flatline. The loop keeps turning, the tokens keep burning, and the density of correct answers stays wherever the verifier pinned it — because nothing inside the system learns from one cycle to the next. The agent that finishes iteration forty is precisely as capable as the one that started iteration one. Only the pile of files has grown.

We’ve heard about prompt engineering and then context engineering, and now it’s loop engineering. Googler Addy Osmani offers a clear introduction to it, beginning with a simple definition:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete.

What changes is who keeps the work moving:

For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.

Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model - the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.

And the loop itself has a recognizable anatomy:

A loop needs five things and then one place to remember stuff. Let me list it first and then map it.

1. Automations that go off on a schedule and do discovery and triage by themselves.
2. Worktrees so two agents working in paralell dont step on each other.
3. Skills to write down the project knowledge the agent would otherwise just guess.
4. Plugins and connectors to plug the agent into the tools you already use.
5. Sub-agents so one of them has the idea and a different one checks it.

Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.

Claire Vo, who built a bug-triage harness for her company ChatPRD, offers a usefully plain definition of an AI harness. The important part is that the intelligence does not live only in the model. Some of it lives in the surrounding code that prepares the work, limits what the agent can do, and decides what it must leave behind.

A harness is some code around an AI agent. Yes, you heard it here first. A harness is just code around an AI agent that makes it more effective. Can that code have AI in it? Sure. Does that code have to have AI in it? Not necessarily. What is the goal of a harness? To make the AI better. It is so simple, and I feel like the way that people have been talking about this has made it such a mystery that I wanted to make it very clear to you all. It is just writing more code around your AI to make it more useful for a specific use case.

Vo’s threshold for building one is equally practical: look for work where the setup and expected result recur.

So what are the parts of a harness? Well, a harness is going to have specific context. It’s going to be able to take specific actions, and it’s going to have a goal of specific outcomes. It’s just as simple as that. And I want to talk about when it makes sense to build a harness and when it doesn’t. I think you’ll want to build a harness when the same workflow needs the same setup and the same outcomes. It’s really when there is a combination of deterministic and non-deterministic workflow, step-by-step process, tools, and use cases you want your AI to follow to do a specific job.

That turns harness-building into a design problem. The work is choosing the job, shaping the workflow, narrowing the tools, specifying the artifacts, and creating an interface through which a person can direct and inspect the system.

I identified a specific workflow. I determined what the run against the task would look like. I made very opinionated calls to tools or data sources. I didn’t just say, “Use an MCP,” although that could be part of your harness. What I did is make adapters that made the calls to these external APIs and tools very specific. I thought about what the structured artifacts out of that workflow might be. I decided what rules and permissions I wanted to give this harness and which ones I didn’t. I decided whether I wanted to use Claude Code or Codex or a model router to actually run these things. And then I built a surface to interact with this agent. It could be a TUI. It could be a CLI. It could be a web app. But I built some way to interact with this.

The model supplies capability. The harness makes a repeatable workflow legible and enforceable.

Christine Vallaure, a UI designer who teaches Figma and AI workflows, offers designers a map of the hidden infrastructure between a convincing Figma-to-code demo and a production workflow:

The demos show you one clean layer working under perfect conditions. Your actual work needs three or four layers stacked together, and nobody shows you the stack, because the stack is where it gets messy and half-solved. The confusion comes from not knowing they are separate things at different stages that need different skills.

A useful distinction is between context and connection. Figma’s Model Context Protocol (MCP) connection can expose the file, markdown can preserve working rules, and skills can make repeated tasks more consistent. None of those guarantees that a generated button is the button already maintained in the product. That takes an explicit mapping to the codebase, plus someone responsible for keeping it current.

Look at the whole stack. Each layer covers the hole under it. The pipe lets Claude see your design. The note carries your rules. The recipe keeps your repeated jobs consistent. And the mapping, the top layer, is the only one that truly welds design and code together so they never drift.

But that top layer needs a codebase, developers, and constant upkeep. Most people do not have that, and should not pretend to. So for almost everyone, the design and the code will drift the moment either side changes, and that is not a sign you set it up wrong. It is simply what these tools are without the expensive wire: they take a snapshot and build from it. When things drift, you regenerate. You do not try to hand-repair a connection that was never really there.

That makes the stack an ownership map as much as a technology map. Each added layer creates another artifact that can become stale. The right setup is the most infrastructure a team can actually maintain, rather than the most complete diagram it can assemble.

And the flip side holds: if you are not this team, do not build like this team, or you will spend your life maintaining a machine you never needed and cannot keep up with.

Sen Lin, writing in UX Collective, has a useful reference for designers who want Claude Code to fit their workflow instead of acting like a generic engineering agent:

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer: Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

A technical stack is the set of technologies you decide on before writing a line of application code. A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The useful move is treating Claude Code setup as a design operation, not a prompt-writing trick. Give it a project brief, a design-system guide, and the right tools before it starts touching the work.

If CLAUDE.md is the brief, DESIGN.md is your design system translated into something an agent can read and obey. It’s a format specification that describes your visual identity to a coding agent: the exact values, and the reasoning behind them.

The file works on two layers, and both matter.

The first is machine-readable design tokens, written as YAML front matter — the exact values, so the agent never has to guess what gray-500 resolves to or which surface color a modal should use: […] The second is human-readable design rationale, written as prose — the part that explains why a value exists and how to apply it. Tokens tell the agent what primary is. The prose tells it there should never be more than one primary button per view, that a primary action is always paired with a neutral or subtle one for cancel, that button width is set by the parent and never hardcoded.

The tool/instruction split is the part worth saving:

MCP gives the agent access to tools.

Skills give it the knowledge to use those tools well.

Where MCP is access, a Skill is a markdown-based guide that teaches Claude how to perform a specific task in a specific way. It’s a set of instructions, scripts, and resources — a training manual that keeps the agent from wandering down expensive detours and burning tokens on the wrong approach.

Good checklist. The designer’s job is not just to ask Claude Code for UI. It is to onboard the agent into the product, the design system, and the working style before generation begins.

Michael Riddering’s Dive Club interview with Loredana Crisan, Figma’s chief design officer, is about how Figma wants a bigger, faster, more explicit design loop.

Riddering asks Crisan whether taste gets less defensible when everyone can make more things faster:

I actually think that what happens when everyone has the power to build is actually it elevates the need to stand out. You could buy those pretty funny or soulful congratulatory cards, birthday cards, whatever cards, and they have the message written inside. And it’s a great message. Do you just give somebody that card? You could, but that’s not what you do if you’re a good friend. That’s not how you show up. And so I think that the more software is getting created, the more articles are being written. Basically, we’re in a place where everything is getting produced at such high, high rate. And we already had trouble consuming what was already there. And so what we’re going to try to do is look for even more authenticity. […] So this is why I think it’s not taste. It’s just your point of view, your human intuition, what you want for that experience needs to come through. And then the tools that they build are very much important to help you drive that.

I think Crisan is right about the greeting card metaphor. When production gets cheap, the work that still feels made for someone will matter more, not less.

That matters for designers because AI abundance changes the filter. The scarce thing is knowing why this draft, this interaction, this bit of motion belongs in this product.

Riddering then pushes on control, which is where Crisan gets concrete about Figma’s tool bet:

The premise is that AI could get you to 70%. And this is true with motion. You could prompt your frame and then you will get the first animation set up. But then from there, you need to make it yours. So it’s almost like AI sets up the workspace. It gives you the parameters, but then you are the one that makes that thing. […] If there is a color that I want to put in my design, a color wheel will never be replaced by a prompt. So there are moments where you just want to take control yourself. […] And it’s an interesting way of working because increasingly as designers, I believe we’re creating systems, not just screens. […] Design is never done alone. Design is evolved through critique. It’s a place where one of the tools of design is other people. And so it’s really fun to be able to have AI, have agents, have the direct manipulation and direct control and your team in one space.

This is the version of AI design tooling that makes sense to me: the tool accelerates the setup, the first draft, but the product still gives designers enough control to make taste visible in the final result.

When working with AI design tools, we tend to think we need to one-shot a prompt to get everything. That, of course, is far from true. We iterate—a lot—by describing the changes we want, then waiting, and inevitably, iterating again. Crisan is describing a tool that still leaves room for the hand: sliders, variables, shared artifacts, and other people.

And she points to evals as part of the designer’s new job:

Increasingly, we’re working with non-deterministic systems, right? So a lot of what the experience is, is produced by an LLM. Previously, it could be produced by an algorithm. I worked at Meta and can tell you, we’ve had a lot of conversations about the buttons that would exist on a feed story. Those buttons are important, but when you think about what people really experience when they open one of those products, it’s the content. And so all of the conversations that we had about buttons as designers were far, far less important than the conversations that we should have had about the algorithm itself, right? And when it comes to these non-deterministic systems, how do you ensure that they meet your quality bar? There’s this thing called the evals is, on the one hand, the least sexy thing in the world, because you are now in a place where you’re trying to specify what good looks like and how systems that could either recognize that themselves or be augmented with humans that could do that. And it’s fascinating to try to do this on an unverifiable domain like design, because design is not, there’s not a correct answer to design, but there are many incorrect answers.

Figma’s own Config 2026 recap makes its strategy clear: it shipped code layers that bring editable, inspectable code onto the canvas; Figma Motion with timelines, keyframes, exports, Dev Mode inspection, and MCP compatibility; shader fills and effects generated by the Figma agent; generative plugins that let teams create canvas-native tools by describing them; Weave tools for reusable generative workflows; and a broader Figma agent with skills, connectors, attachments, and shared chats. The through-line is not one more AI feature. It is Figma trying to make the canvas the place where code, motion, generative media, team-specific tools, and agent context all live together.

The old design-tool space was mostly canvas versus canvas: Sketch, Figma, XD, Framer, whichever product made design teams move faster. Darren Yeo, writing in UX Collective, is looking at a different fight: Figma against the possibility that the canvas becomes optional.

Figma’s enterprise strength has always depended on breadth. Designers used it first, then product managers, engineers, marketers, writers, and executives followed. The more people needed to review, comment, inspect, or reference design work, the more seats Figma could sell. The same applies for the product bench, with the rapid expansion of Slides, Buzz, Sites, and now Motion and Weave.

AI complicates that logic. If an engineer can generate or inspect UI directly inside a coding environment, or if a product team can translate structured design intent into working software without opening a shared canvas or applications, the need for passive, underutilised seats weakens. Config 2026 actually confirms this tension by bringing code layers and agent workflows closer to the main product, Figma Design. In other words, Figma is acknowledging that an increasing number of people want to participate in product and code creation without relying on traditional file-based design behaviour.

That does not kill Figma’s seat model overnight, but it does chip away at the assumption that every stakeholder must enter Figma to participate or experience design. Thus, the deeper issue goes beyond whether the team has seats at the table (canvas). The table of collaboration resides in a code-native environment and workflow, where the moment of truth shifts closer to implementation, and that reduces the number of times a team needs to return to a design file as the source of record.

The handoff-is-dead argument usually shows up as a claim about what designers can do now: move closer to implementation, write production-minded specs, and stay in the work longer. Yeo adds the business-model version of that argument. If collaboration moves into code-native environments, Figma is not just losing a handoff step. It is losing the shared room that made every reviewer, PM, engineer, and executive need a paid license.

Figma is not standing still. Even before Config 2026, the company pushed beyond static collaboration and into AI-connected workflows. Features like MCP, Code Connect, and Figma Make on local code point toward a future where design data can move more fluidly into development environments and AI tools.

That is a smarter response than pretending the canvas can win by becoming a slightly better canvas. Figma’s best path is to become the system that preserves design intent, component logic, and implementation alignment across tools. In that model, Figma is becoming an operating layer.

This is also why the company’s product strategy feels more important than its individual features. A single new AI button will not change the story. What matters is whether Figma can make design data more portable, more structured, and more useful outside the file itself. Config 2026 suggests that Figma understands this, but it also shows how hard the transition is: the company still has to make the canvas relevant in a world where many teams want to begin and finish elsewhere.

Yeo’s warning is blunt: “if teams can skip past the canvas by accelerating from intent to implementation with less translation, the value of designing to handoff vanishes.” The answer he points toward is less about file ownership and more about whether design intent can survive the trip across tools. For designers, that shifts the work from drawing the artifact to making the intent durable enough for other tools to read.

The future of design is likely to be built around reusable tokens, readable structures, and tool-agnostic metadata rather than locked files that only live well inside one platform. The winning systems will be the ones that can travel between editors, browsers, codebases, and AI agents without losing meaning.

Claire Vo on her How I AI podcast gives a plain-language walkthrough of agent loops in Claude Code and Codex. The episode is technical, but the useful translation for designers is familiar: define the job, give it tools, decide what good output looks like, and make the system prove it. Once an agent can run without you, the interface problem moves into instructions, permissions, and checkpoints.

And then a couple other foundational things that I think are helpful when you’re running loops. And why are these things helpful before we get into what they are? They just keep the work clean.

If you are going to be yolo-ing loops all over the place, you’re going to want some consistency in execution, you’re going to want clean workspaces, you’re going to want conflicts resolved and avoided. And so, all these things are really to make those loops effective.

And so, what are the things? They are work trees. I feel like this entire podcast could be Git 101. But work trees are just basically a way to isolate the work, especially the coding work of an agent away from other agents’ work in a sandbox. There are skills, repeated ways to do common tasks. We have a full episode on what skills are from earlier last year when they came out. Plugins and connectors, these are just the tools that your agent has access to. […] Sub agents, both Codex and Claude Code allow you to kick off sub agents. This is just a way to federate out work from the main thread, so that sub agents can do specific tasks, especially validation. And then there’s some way to track state. And essentially just think of this is like a to-do list.

The practical translation for agent orchestration: write the operating conditions around the work before asking for the artifact.

Calling it a loop makes it sound like automation plumbing. The design work is the brief: what the agent can touch, what tools it can use, and how it knows it is finished.

The employee comparison makes the loop feel less exotic:

Now, people are going to ask, “What should I use a loop for?” And when you’re designing loops or designing agents, I say this is the time for the manager. You are designing a job. And so, just imagine that you’re onboarding an employee. That employee could be an executive assistant. That employee could be a customer service agent. That employee could be a software engineer.

Every Friday, EA, I would like you to review my calendar, see who canceled on me, where I could have used my time more effectively, if there are any follow-ups, and send me a Slack to get this done. Um and I want you to do that every Friday. Guess what? You’ve just designed a loop for your executive assistant. […]

So, I really like to think about loops as designing workflows and designing jobs to be done for people. It just happens to be that you can put this intelligent agent against the loop, and then it’s ready to go.

For designers, that last sentence is the translation layer. A designer already knows this move from creative direction: clear constraints produce better work than a blank request. The only difference is that the worker now happens to be software.

A loop without success criteria is just a faster way to make someone review the same ambiguity at a higher token cost.

We all want our agents to work for us on a schedule whenever we want, doing work that we don’t want to do. It’s great. What are some of the problems? One, loops can get expensive. So, I just kicked off an automation that happens on a regular basis. It does wide-ranging work. It decides when to spin off sub agents.

And it does loop-based validation, which means it’s burning tokens until it hits a threshold that it decides is successful. If you do not write that loop well, or your validation criteria is too thin, guess what? Your agent is going to burn tokens. I think we’ve seen this with open claw in particular or some of these agent harnesses is they’re really good at loops. They’re very diligent. They get interesting work done, but man, do they love to burn tokens.

[…] Loop-based prompting is just its own thing. Goal-based prompting in specific is just its own thing because you have to be very precise about evaluation and success criteria. If you are not, you will be very disappointed and use a lot of tokens for not a lot of output.

Murphy Trueman isn’t worried that AI makes bad design. She’s worried that it can make passable designs, enabling designers to bypass contact with the material that teaches them how systems actually behave:

UI is starting to feel disposable in a way that unsettles me. Not as a complaint about quality. Structurally.

The pace of generation means nobody dwells in a screen long enough to notice whether it’s actually considered or just plausible, and plausible is increasingly good enough because the bar for “does this look designed” keeps dropping when the tools do the designing. The decisions are still there, technically, but the attention that turns decisions into craft has somewhere else to be.

You can produce a lot of considered-looking work without any of it being considered.

This is the craft problem hiding inside the productivity story. The danger isn’t only that teams will ship screens faster. It’s that they may lose the habit of noticing the small decisions that make an interface hold together after the first glance.

Trueman gets more specific about what Figma gave her:

But the specific thing that made Figma matter to me wasn’t efficiency. It gave me a way to hold abstract structural ideas in my hands — the relationship between a component and a style, between a token and a decision, between a change made in one place and every instance that inherits from it, made visible, made editable, made something you could touch and understand by touching it. That’s how I learned to think about the work.

That’s the part I don’t want AI tools to flatten. The best design tools don’t just make results; they make relationships inspectable. You learn by manipulating the system, getting it wrong, and seeing which decision moved. Difficult to do in code and see it cascade in the product.

Everyone records videos with their smartphones, whether it’s concerts, kids, or stuff you think you’ll upload to TikTok. Truth is though, you might go back and watch those moments in your camera roll, but you’ll probably never edit them and make them into something shareable. Video editing takes a long time. Interesting things are happening with AI computer vision these days.

Ilias Haddad created an app that will index and semantically describe your videos. He made it to solve a specific problem he had:

I had 2,207 GoPro videos, and I need to rewatch them to find interesting moments from my cycling journey. I built a project to index them locally on my M1 Max using open-source ML models, search for those moments, and send the best clips straight to my DaVinci Resolve timeline.

NJ Singh built something similar:

Every AI video editor on the market assumes your footage is already labeled. Mine is IMG_*.mov and DJI_*.mp4 across folders with names like Mara june 2024 backup final FINAL. Eddie [an AI video editor,] can search by transcript, but none of these tools can find “the elephant on the hill at golden hour” against an unlabeled archive.

The AI editor is solving the wrong problem. Or more precisely, it’s solving the second problem; the first problem is the index.

In designer and investor Soleio’s South Park Commons interview, Rasmus Andersson, creator of Inter and an early Figma designer, draws a useful distinction between software and type. Regular software decays fast; Andersson says that if he hasn’t touched something in two weeks, he usually trashes it and starts over. But a typeface can keep gaining value years later.

Andersson starts with how complex modern software is:

Today there’s just this towering complexity of making software, and for a very good reason, right? For like 15, maybe 20 years by now, our industry as a whole has been hyper-focused on scale because it’s just been an economic evolution that’s been out of this world. So it makes sense that we’ve been trading off and trading away things like shareware, concepts like that, and things like simplicity and ease for the ability to scale and for the ability to things at scale to actually work and break apart. But in the wake of all of that, which is great in so many ways, we’ve given up these things that are listed, and I feel like at least me and many people like me and who sort of are trained to build this thing, enjoy making software at a smaller scale.

That’s like a metaphor that I think can be helpful is imagine your room, apartment, house, whatever, your dwelling place. It’s probably different from the person next to you. And it’s not so that we go out and we buy the Apple apartment and all the furniture is there and everything is perfect and we can change the carpet, and that’s about it. That’s ridiculous, no one would do that. Yet that’s what people do with software.

Manufacturing software was professionalized and gentrified. The stack got so optimized for global products that it left less room for the small, personal, weird things people used to make for themselves.

Andersson’s Figma story keeps that from becoming nostalgia:

First off, something that was just amazing about working at Figma at the time was that there was just this culture of doing things differently. That was amazing. And every single individual who I worked with were just like, if that person went to start a company now and they put me with it, I’ll come. Every person was like that. Every person had an opinion about something that was really exciting.

Another thing that I think was so fascinating about how things were done at the time at Figma was this deep intention around everything and moving slow. But moving slow with many things in parallel, like staggered, right? So from the outside, Figma would ship something every month, maybe even more often than that. But internally, a person would work on one thing for one year. And sometimes at the end of that one year, it would just go into the bin and never ship. So that I think was really cool to see from the inside and then having a very different effect on the outside.

That distinction matters in an AI tooling moment where output is getting cheap. Figma looked fast from the outside because slow, deliberate work was happening underneath. Speed at the surface depends on judgment below it.

On Inter:

One thing for sure is finding the right ratio between impact and effort. I think Inter is one of those things. Sure, I’ve spent like 10 years on it, and who knows how much of my time on it, right? So there’s a lot of effort behind it. But I think it’s one of those types of efforts that has a very disproportionate impact from the effort.

[…]

I gotta say though, something that is amazing about working at Typeface is, it’s something like, it’s almost like in the field of design, you might think about cars as a unique type of thing to design because it’s both like, and architecture’s a little bit like that too. It’s not strictly the sign as in signage for roads, right? It’s very technical and it’s not the sign as in expressing myself through art, like graphic design, like a poster, it’s somewhere magically in between.

And another aspect of it that’s kind of cool is that you can put in 10 minutes here and 10 hours there and they add up over time which I don’t think is true without a software because the rate of decay of any type of regular software is very high. Two weeks is my cutoff. If I have not worked on something for two weeks I have trashed it and start over but with a typeface like that decay is extremely extremely low, in some cases zero.

Amber Bouabdallah, writing in UX Collective, gets at the learning problem lots of designers are facing in this AI transition: the tools don’t produce one shared path toward competence.

Bouabdallah draws the line between deterministic software training and relational AI practice here:

Traditional software training works because the tools are deterministic. You learn where the buttons are, what the shortcuts do, how the system behaves when you click the thing. Mastery, in that world, converges — everyone arrives at roughly the same competence, following roughly the same path, and you can write a training deck for it. Mastery means knowing the tool’s correct use.

AI tools break that definition. Maggie Appleton — designer and anthropologist, now at GitHub Next — gave a talk in 2023 called “Squish Meets Structure” about designing products with language models, and the line from it that I love is her description of the magic-input box: it has “no affordances,” “no knobs or door handles.” The interface, she writes, “offloads a ton of cognitive labour to the user.” There is no correct use to learn. The tool meets you where you are. Which means what you bring to it — your instincts, your mental models, your accumulated taste, your willingness to iterate, your custom claude.md files — is the tool, as much as the model is.

So mastery hasn’t disappeared. It has shifted. With deterministic software, mastering the tool meant converging on its logic. With AI tools, mastering one means the opposite: learning to bend it toward your logic. Tailoring it to how you already want to work. Mastering an AI tool is the craft of making it amplify the specific strengths and experience you bring — so the work that comes out is sharper, and unmistakably yours. That kind of mastery is real, and hard-won, and worth teaching toward. It is just personal rather than universal. Divergent rather than convergent. Everyone’s version of it should look different, because everyone’s version is built out of a different person.

Her Salesforce examples keep that from becoming an abstract tool-training claim:

Six months in, Ningdan and I had designed for tool adoption and accidentally created conditions for something more intimate. Seeing each other work. Seeing the specific choices someone makes when the tool doesn’t behave, the workarounds they’ve invented, the mental models they’ve constructed to make sense of something genuinely new. A window into someone’s thinking — and into how each person was mastering these tools in a shape no one else’s would match.

And once you can see the thinking, you can see the worry too. Amanda Harris, a User Experience Architect on our team, named a tension directly in the post-mortem: “I worry that we’ll lose the exploratory aspects of finding what’s wrong with an idea by jumping so quickly into hi-fi prototyping.” That’s not resistance to new tools. That’s a designer protecting something she knows matters. Hearing it voiced — in a room where everyone is nominally learning the same things — is only possible in a setting small enough and safe enough for honest uncertainty.

The anxiety designers are feeling is a signal, not a weakness.

And Bouabdallah closes by naming the training layer her team actually designed:

The tools will keep changing. They will keep arriving faster than any module can be written, any best practice can be documented, any official curriculum can ratify. It is tempting to treat the peer layer as a bridge — something to lean on until the real training arrives. But the real training is not coming, because there is no fixed competence to train people toward. As long as the tools keep moving, the peer layer isn’t the bridge. It’s the ground.

We did design how designers master AI. We just found that mastery wasn’t what we thought it would be. Not a competence everyone arrives at, but a practice each person builds — bending a generic tool toward their own strengths, their own experience, their own way of working, until the work it helps them make is sharper and theirs.

Apple’s developer conference WWDC kicked off on Monday with a keynote. They announced various OS improvements, including refinements to Liquid Glass, and most importantly, a revamped AI strategy.

In the days leading up to the keynote, longtime Mac journalist Jason Snell wrote about building his first Mac app with Claude Code in just a couple of hours. We’ve heard this story before. We’ve been talking about it here for months. And yet, here’s a veteran technologist who’s just now discovering Claude Code’s power and building an app.

It’s easy to get caught up in the Silicon Valley AI hype bubble and think the whole world has changed and is using AI for everything. But no, that’s not actually the case.

Snell on what the experience actually required:

The process of building the app reinforced something I’ve been thinking about for quite a while: coding is a specific skill, but it’s only one part of a much larger process. Great developers aren’t necessarily great coders, though they can be. Apps must be envisioned, their specifications defined. The act of trying to describe an app to an AI coding engine is a clarifying one. The more you describe the app, the harder your brain has to work, because it’s always more complicated than you think it’s going to be. The decisions you make determine what the app comes to be. […]

Yup, tell me about it. Tell us product builders about it! The code was never the hard part.

Where I’d push back is on the optimism around it:

We now live in an era where, if you can dream an app, you can probably build it. Especially Mac utilities. And who cares more about native Mac software than Mac users? Certainly not those companies that gave up on Mac development and focused all their energies on giant cross-platform code bases to attract venture investment and big payouts.

Snell himself calls his app “ugly and incomplete” a paragraph earlier, so “if you can dream it, you can build it” is a bit of a stretch. The gap between a thing that runs and a thing you’d ship is where the real work lives: envisioning, deciding, refining.

And it’s a reminder of where the next barrier sits. Snell ends on the tooling:

Which brings me to a final point: Apple’s development tools, most notably Xcode, are nightmarish. My developer friends are used to them, but as someone who has never really used Xcode before, I was shocked at just how deeply unintuitive it is. As in, Claude would tell me to click on things, and I would have to reply, “I have no idea what that is or where it’s supposed to be.” And I’ve been a Mac user for a long time! I’ve gotten very good at intuiting where stuff is in a Mac interface.

[…]

While AI tools have made it more possible to build apps on Apple’s platforms, the developer tools themselves are still a formidable barrier. As the definition of “developer” changes, so, too, must the definition of developer tools.

I wholeheartedly agree with Snell that Xcode is a mess. For those like me who only open it on occasion, it’s baffling that Apple developers live with such a nutty application. Take a look at the best of Apple’s first-party apps like Keynote, Final Cut, or even Numbers, and Xcode is just…bizarre.

Apple did announce something at WWDC 2026 that was interesting—that nods to where they could go if they wanted to—users can ask Siri AI to vibecode Shortcuts and Safari extensions. Will have to see if that’s the seed for something.

Arpan Patel wrote a nice consolidated Claude Code reference: the directory layout, CLAUDE.md the way Anthropic’s Boris Cherny writes it, skills, subagents, MCPs, the underused commands. The whole guide turns on one shift:

Claude Code clicked for me once I quit treating it like ChatGPT in a terminal. The mental model flipped from “I need to write this code” to “I need to set Claude up to write this code well.” Setup is the work. Execution is verification.

If you use Claude Code daily, bookmark it.

Emma Webster, writing for Figma, argues that AI tools are pulling prototyping earlier in the product process: teams can validate with more fidelity, then carry design context forward instead of recreating it at handoff.

Product teams are rapidly adapting to the new way of working in the AI era. They’re prototyping before writing specs, testing in code before designing, exploring at unprecedented scale, and shipping with design system context that used to get lost in the handoff. We talked to product builders at FloQast, Merkle, Affirm, and Accor about how that’s playing out in practice.

The shift is about when the hard questions show up. Specs used to be the artifact that let teams pretend they had alignment. The team behind Claude Design skipped the PRD entirely and prototyped its way to the answer instead. With AI tools, a prototype can become the first serious question: does this flow hold up when the data, logic, motion, and system constraints are present?

Webster describes the code-to-canvas loop this way:

Testing an idea against intricate constraints—things like multi-step flows where one action triggers the next, or interfaces that behave differently depending on the data behind them—used to require significant developer investment. Today, AI coding tools have made it possible for more people on a product team to quickly build and test these kinds of interactions before committing to a direction. That’s opened up a new workflow. A product builder can create a working prototype in code, then move it onto the Figma canvas using Codex to Figma to see the full picture and refine it together. From there, if more work needs to happen in code, they can move back via MCP with the design context intact.

This is the version of AI-assisted design I care about. Not “prompt a shiny UI from a blank page.” A working model becomes the place where designers, PMs, and engineers can see the same problem at once. Figma is still the canvas for style exploration and visualizing complex flows, but the decision surface is becoming more product-shaped.

That matters because prototype fidelity changes what a team is allowed to learn. A flat mockup can test preference and comprehension. A working prototype can test sequencing, edge cases, permissions, motion, and whether the idea survives contact with real constraints. Bringing that earlier into the process should make design less speculative, not less thoughtful.

The Accor example shows why this matters before anyone commits to a build:

Justine opened Figma Make and prototyped something she wouldn’t have had time to build by hand—a webpage that reorganizes itself based on what the user types. Search for “golf” and the page reshapes around properties with golf courses, curated outings, and relevant experiences. Make handled the micro-interactions and transitions, and the Figma MCP server kept everything connected to the brand’s design system. Within days, she had a working prototype ambitious enough to show leadership what was possible—and concrete enough to start a real conversation about what to build next.

Webster’s Affirm example carries the same logic all the way into production:

A PM prototyped the badge variations in Figma Make—going from idea to working prototype in two days instead of the usual six weeks. Designers refined the winning direction on the canvas, and when the team was ready to move that design into production, they loaded the design artifacts into the Figma MCP server and connected it to Cursor. MCP passed the components, tokens, and layout structure directly into the coding environment, where an AI agent generated the front-end implementation. Developers used that as their starting point, building production code that already reflected the designs instead of reinterpreting them from scratch.

Preserving components, tokens, and layout structure turns the prototype into a rehearsal for the real build. It has enough fidelity to expose bad directions early and enough context to keep the winning direction from being rebuilt from memory.

The line running through Tobias Van Schneider’s interview is simple: designers complain about tools all the time, but the better move is to build the environment you wish you had.

Nikolas Wrobel interviews designer Tobias Van Schneider, founder of Semplice and mymind, and the profile traces that pattern directly: Semplice for portfolios that didn’t fit the platform/template world, then mymind for thinking without the performative noise of social media.

Van Schneider:

How do you protect yourself against consuming, draining effects from Social Media, or disenchanting tech-mechanisms?

This question almost too perfectly leads into what I do everyday. In part, I protect myself by using mymind.com (which I created) — there are no ads, no vanity metrics, no social media features, nothing but myself. Only me and the things I care about. Over the years, mymind has become so valuable to me, it’s the first place I go to look for inspiration. In fact, while I am answering this interview, I find myself going back and forth between old notes and musings inside mymind.

Social media still drains me, just like everyone else, but it’s nice to at least have one place just for myself. And thats mymind.

Aside from that, I just get offline and out into the world. Or I create something.

Van Schneider isn’t pitching another social layer; he’s describing a private room for memory, taste, and reference.

He later explains where that product idea started:

As with many things, it was a total coincidence. When we initially worked on the mymind product and brand, we didn’t even have the name “mymind” yet. The whole thing was called AWMT, which stands for “As We May Think” and is a reference to an old essay by Vannevar Bush from 1945 in which he wrote about a machine called “The Memex” which was some sort of machine that collects and connects your personal knowledge.

Coming off of that inspiring essay, we came up with a slogan called “Think for yourself” which is sort of the antithesis to the cloud/hive mind of what we call social media today. Especially since we position mymind as a private sanctuary, it just made sense to us.

All of this eventually got me into the rabbit whole to search for ideas for our logo. The classic “Thinker” statue immediately came to mind. I always loved that one, a man deep inside his own thoughts, unfazed by the world around him. But the statue was a bit too literal to me, too well known, too sharp and serious. We needed something more abstract, more playful. Eventually I found out about Cycladic art, originating from the Aegean islands during the Early Bronze Age. Very famous for their minimal and stylized marble figurines. Now, the rest is history. I immediately fell in love with the simplicity of it and it felt like a great canvas to build our visual universe on it. The rest is history (:

Wrobel asks Van Schneider about the conditions he works best under:

The creative me enjoys being alone. Completely isolated, nobody even in the other room. It gives me freedom and clarity to think for myself and be myself. My real creative being thrives in these moments, untouched by the opinions and desires of others.

My ultimate solitude tends to arrive at midnight. It almost transforms me. The dark brings focus. Silence brings new ideas. No voices interrupt, no chance of emails, just me and my thoughts. It’s this time I feel most creatively alive.

Now, add a soundtrack to it and I’m in creative heaven (:

I don’t think every designer needs midnight solitude. But design work does need stretches where taste can form before it becomes consensus. In a work culture that treats collaboration as a default good, that distinction matters.

This is also why the tools question matters. A portfolio system, a private reference space, even a type foundry site are not neutral containers. They either protect the conditions where taste can develop, or they pull the work back toward the defaults of the platform. Van Schneider’s career makes that feel less like a manifesto and more like a working habit: when the available environment makes the work smaller, build a different environment, then keep using it until it changes the work.

Van Schneider’s favorite advice turns complaint into output:

“The best way to complain is to create something” by James Murphy, founder of LCD Soundsystem. It has become one of my guiding principles. It turns useless, negative energy into productive, positive energy.

Fulya Lisa Neubert, writing for the Slack Design blog, starts with a familiar design handoff problem:

For most of my design career, Figma was where the real work happened. I’d design screens, build prototypes, then hand off the designs for someone else to build. If something felt slightly wrong in production, we’d go back and forth trying to articulate what “it should feel like” in words. This process worked well enough, but there was always a gap between what I could show in a static design tool and what someone would actually experience in the product.

The piece gets concrete when Neubert moves from screens to Slack search. She points to a kind of interaction where static prototypes can suggest the flow, but can’t prove whether the experience works under someone’s hands:

The search experience in Slack is a deeply keyboard-driven feature: typing states, focus management, the way content scrolls and reflows as you interact. These are things you can sketch in Figma and even prototype to a degree, but a Figma prototype can’t tell you whether the focus ring moves correctly between elements when you press tab, or whether a scrolling gradient feels right as content overflows. You need to actually use it.

I don’t read this as an argument that designers need to become frontend engineers. Neubert came in with the basics and figured it out:

I came into this with basic HTML and CSS — enough to roughly understand what I was looking at, but not enough to write it myself. That turned out to matter less than I expected. The first time I described a focus interaction in plain language and had a prototype working in minutes, I stopped thinking of code as someone else’s territory. […]

My setup is fairly straightforward. Cursor is my main environment. I use Figma’s MCP integration to pull in components I’ve already designed and Slack’s design tokens, so I don’t have to rebuild spacing, color, and type from scratch every time. I tried working directly in Slack’s codebase — years of accumulated complexity that made every small change feel like a bigger undertaking than it needed to be. […]

The Figma integration matters because the prototype isn’t starting from a blank toy environment. It pulls real components and tokens into a lighter workspace, which makes the thing shareable without pretending to be production. For Slack search, that means the team can review behavior instead of debating screenshots.

Neubert is also clear about the tax:

AI also doesn’t always preserve what you’ve already built. You prompt it to change one thing, and it quietly breaks something else. If you’re not testing after every turn, you won’t notice until you’re sharing the prototype with someone — or worse, presenting it — and that’s when you realize something’s broken.

That is the right caution. AI changes the distance between intent and working behavior, but it doesn’t remove verification. If anything, it makes the habit of testing after every small change part of the design process itself.

Felipe A. Carriço, a UX designer and AI product builder, turns accessibility guidance into context AI coding agents have to follow with A11Y.md:

A11Y.md is not a guideline. It is an accessibility validation protocol and a persistent context architecture for developing accessible software with AI. It is designed to integrate with AI agent systems and human review workflows to ensure certifiable compliance.

By adopting the mental model of Anthropic’s CLAUDE.md—which acts as a system prompt memory for code generation—A11Y.md translates this architecture into a universal, portable governance layer. Instead of generic coding rules, it forces any coding agent (Claude, Cursor, Copilot) to strictly adhere to WCAG 2.2 AA and ADA standards from the very first line of generated UI code.

I appreciate how operational this is. It pairs well with Joost de Valk’s Website Specification, which treats machine-readable standards as part of what a good site does. A11Y.md brings the same idea into the build process: the generator has to carry the accessibility context while it makes the UI. That matters because accessibility failures in generated code are rarely abstract. They show up as broken keyboard paths, silent error states, and interface logic that only works for the person who can see and click everything.

Carriço is blunt about the difference between reading and changing the workflow:

Reading about accessibility is the first step, injecting it into your code is the real goal. Do this right now in your project:

1. Download the Rules: Copy the A11Y.md file from docs/en/ to the root of your application’s repository.
2. Inject into the Prompt: If you use Cursor, GitHub Copilot, or Claude, add this to your global rules file (.cursorrules or Context system):

“Strictly follow the development rules defined in the A11Y.md file.”

3. Use as a Quality Gate: Before merging important PRs, use the checklist in docs/en/templates/REPORT.md.

If you do not perform the steps above, you are not changing your workflow — you are just reading about the subject.

That is the product here: wiring accessibility into the build process so it changes what gets generated.

Joost de Valk, creator of the Yoast SEO plugin for WordPress, has turned the “what should a good website do?” question into The Website Specification: a platform-agnostic checklist that puts HTML basics, SEO, accessibility, security, performance, privacy, internationalization, and agent readiness in one place.

The useful shift is that the AI-facing work is treated as normal website hygiene. Not a separate “AI strategy” project. Not a prompt-engineering side quest. Just another part of making the site understandable to the systems that now read, rank, quote, and retrieve it.

A platform-agnostic specification of the technical features every decent website should have — from <title> to /.well-known/security.txt, from WCAG contrast to llms.txt. Written for humans and agents.

Ten areas, mapped to widely-accepted standards.

Each topic links back to the source standard — WHATWG, W3C, IETF RFCs, WCAG, MDN, and the organisations defining the modern web.

Whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML, the spec is the spec. Implementation hints follow it, not the other way round.

I like that standards-first posture. A lot of AI advice still treats the web like a pile of pages to be scraped, summarized, and maybe attributed later. De Valk pulls it back toward contracts: stable URLs, explicit policies, structured data, clean source material, and machine-readable ways to discover what matters.

From the Agent Readiness section:

Agent readiness is a loose umbrella term for the choices that make a website legible to AI agents — chat assistants, autonomous browsers, retrieval pipelines, and any other non-human client that reads the web at scale. None of it is a single formal standard. It is a collection of existing web fundamentals plus a few emerging conventions.

Agents read the same HTML as browsers, but they read it differently. They:

• Fetch a page, often without executing JavaScript.
• Strip away navigation, ads, and chrome to extract the main content.
• Follow links, structured data, and well-known endpoints to discover more.
• Cache and quote your content in answers, with or without a link back.

If your content is locked behind client-side rendering, your URLs change every release, or your robots.txt blocks the assistants your customers use, you are invisible in that surface. The pages that win in agent answers are the ones that are easy to fetch, easy to parse, and easy to trust.

That’s the part designers should pay attention to. We tend to think of the interface as the thing on the screen. But if agents are part of the audience now, the interface also includes off-screen surfaces: metadata that explains the page, feeds and sitemaps that expose what exists, crawler policies that say what can be read, and curated indexes like llms.txt that tell software what matters.

De Valk again:

There is no single switch. The items in this category each cover one part:

• Stable URLs so cached answers stay valid.
• Structured data (JSON-LD) so agents can extract entities without guessing.
• Clean semantic HTML so content extraction does not pull in navigation.
• A robots.txt that names AI crawlers explicitly so your policy is unambiguous.
• /llms.txt as a curated index of your most important content (emerging).
• Machine-readable endpoints — sitemaps, RSS, JSON feeds — where they fit.
• MCP server endpoints for sites that expose tools or actions (emerging).

Most of these also benefit traditional search engines and accessibility. Agent readiness rarely conflicts with the rest of the spec; it just raises the priority of things that have always been good practice.

De Valk’s point is simpler: agent readiness mostly means doing the old web discipline well enough that agents can actually read and trust the site.

Dan Carey leads product at Anthropic Labs, the team behind Claude Code and Claude Design. In a talk on how a three-person team shipped Claude Design in ten weeks, he describes what happened to everyone else after their engineers got fast:

And so once Claude Code took off, the bottleneck moved. The bottleneck moved from building the feature to figuring out the right things to be building for your users, in a lot of cases. So the option was either skip those early steps, just try and decide on the fly, and potentially build the wrong thing really fast, or try to find ways for the rest of us to speed up. So our designers, our PMs, were having trouble keeping up. We needed our own accelerator tool.

Carey just relocated the bottleneck onto the exact work designers and PMs own: figuring out what’s worth building. That’s product discovery becoming the real constraint. When building gets cheap, what’s left to get right is the decision about what to build at all.

How does the team make that call? Not by writing it down:

So we like to use prototypes because documents are imprecise. It’s so easy for two people to look at the same doc and have two different products in mind about what the experience should be. […] Prototypes are more concrete, more visceral. They let you get hands on with the thing and really feel the experience yourself.

They skipped the PRD and the vision docs entirely. A working prototype immediately aligns people, and it doubles as the discovery tool: you build the rough thing to find out what the right thing is.

And it helped that the team was small enough to skip coordination entirely. Here’s Carey:

Everyone on the team does everything. The engineers talk to users, PMs write code, designers do data analysis. All of these things are enabled in part with Claude. And the lines between the roles on this team, they have essentially dissolved at this point. You do have your specialization, you do have the unique perspective and diversity that you bring to a team, but at any moment, any one of these people on this team can talk to 10 users, you can realize what the underlying problem is, you can design a solution to it, you can ship it to users, you can listen for feedback, you can keep iterating solo if you need to.

On Carey’s team, the designer who spots the problem also builds the solution and ships it. That’s the kind of role a lot of designers are now being asked to grow into, and it looks less like a handoff between specialists than one person carrying an idea from problem to finished screen.

Speed doesn’t guarantee you build the right thing, though, and Carey is candid about the team’s misses. They built a set of advanced, fine-grained controls for power users. A few vocal testers loved them—I know I would have. But the usage showed everyone else hated them, and the team pulled the controls in a week. Two lessons came out of it:

So this taught us a couple of things. One, this taught us that we should be a tool that lifts the level of craft for everybody, not just the ceiling on power users. It also taught us that we want to be as open as possible, because there will be users that we never meet the full needs of. There’s going to be some power user out there who wants to do something very specific that we’re not going to support. And that’s what convinced us that we wanted this to be a very open tool. That’s why if you export from it, you get HTML, CSS, JavaScript.

David Pierce, writing for The Verge, dates the inflection precisely: late 2025, when an update to Claude Code crossed the line from “surprising when it worked” to “surprising when it didn’t.” That’s the moment vibe coding stopped being a demo and started being a tool ordinary people could actually use.

In late 2025, an update to Anthropic’s Claude model turned its Claude Code tool from a code generator that was surprising if it worked to one that was surprising when it didn’t. Suddenly, all you needed was $20 a month and a half-formed idea, and an AI model could build you functional software. If you could explain what wasn’t working, Claude Code could probably fix it. Andrej Karpathy, an educator and researcher who was on OpenAI’s founding team, had called this new behavior “vibe coding.” Suddenly the vibes were off the charts.

The reliability threshold matters more than the headline number. Twenty dollars a month was already true. What changed is that the output stopped breaking when you asked it to do something real. That’s what made the personal software lineage—from HyperCard in 1987 through Lee Robinson’s essay, the home-cooked-app idea, micro-apps, and fleeting apps—turn from a niche aesthetic into something a normal person could actually do over a weekend.

Pierce documents his own version of that weekend: building Timetable, abandoning it, building Spring and forgetting what it did, getting stuck on Twilio bills. The realization that pulls him out of the loop is the one that’s worth dwelling on:

What saved my efforts was the realization that personal software doesn’t have to be built from scratch. Knowledgeable developers might be newly capable home cooks, but the rest of us are more like customers at Chipotle. We don’t make the food, we don’t even really assemble it, but we get to decide what goes where and how it’s served to us. For most of us, the future of software is not building our own Excel from scratch, it’s using the models to build spreadsheets wildly more capable than we could create ourselves. It’s building the Chrome extension for your favorite app that is really only missing a Chrome extension. It’s tweaking the way things look to suit your exact taste and needs.

Most coverage of vibe coding implies the future is everyone becoming a one-person engineering team. Pierce’s actual claim is narrower and more useful: like ordering a Chipotle burrito, you’re picking ingredients and toppings, not running the kitchen. The point is not to replace Notion or Obsidian or Todoist. It’s to bend them an inch closer to how you actually work.

My whole publishing workflow for this blog switched from Payload CMS to a custom admin UI and now a custom Obsidian plugin.

Which brings the conversation to where Pierce lands it: taste.

In this new world, the most important thing you’ll need is taste. Not objectively good taste, necessarily, so much as a keen sense of your own. You need to be like Rick Rubin, the famous music producer, who once told 60 Minutes that what made him successful was not any particular technical ability, but “the confidence I have in my taste, and my ability to express what I feel.” Rubin practices that art with A-list celebrities; you need to be able to do it with AI. Otherwise, you’ll land in what Lovin calls “doom loops,” telling your chatbot only what you don’t like and counting on the model to be the creative one. That way lies madness — and bad software.

Yan Liu’s working definition of taste cites the same Rubin formula—sensitivity times standards—and that’s the part of Pierce’s argument that designers should sit with. The $20 vibe-coder has the tool. What they often don’t have is the trained eye to know when Claude’s purple gradient is wrong, or why the icon looks like a butthole instead of a planner. Pierce learned this the hard way and concluded, sensibly, that he didn’t have opinions about databases but did have opinions about typefaces. That’s the right diagnosis. It also undersells what designers actually do—Raj Nandan Sharma’s warning about taste-as-end-of-pipeline selection is the other half of this. If designers don’t show up as authors here—shaping what gets generated, not just thumbs-upping it after the fact—the personal software era will produce a lot of bespoke purple gradients and not much else.

Michael Riddering brings Tommy Geoco on Dive Club fresh off field visits to Vercel, Perplexity, Metalab, Ramp, and Snowflake. Geoco and his team are making a documentary after roughly 200 conversations with designers and design leaders this year. The survey finding he leads with is the one I would have least expected: designers who have moved more of their work into AI-assisted prototyping are also more satisfied with their workflows. The hierarchy of who is actually doing that work is the part worth sitting with:

The number one thing that stood out to me was that designers who are currently vibe coding are more satisfied with their workflows. […] And I did not expect that. […] People seem to dig it in this survey. […] It’s the people who are currently doing the majority of their workflow on vibe coding activities. It’s design engineers. That makes sense. Lead principals. [After that] it’s non-designer roles, which might be students and researchers. Then it’s managers. And then it’s your general junior mid-level IC. And that part was fascinating that managers are doing more than junior and mid-level ICs. Either things are trickling down and people are experimenting and then they’re going to pass learnings down, which is kind of what we’ve seen on location. But it also might mean that like some managers or teams haven’t yet made room for the rest of the team.

Design engineers and leads at the top is unsurprising. Managers above juniors and mid-levels is the inversion, and remains basically unchanged from two years ago when Geoco’s 2024 survey found the same thing.

Leadership-IC Divide. Leaders adopt AI at a higher rate (29.0%) than ICs (19.9%)

So what’s the read? Geoco gives it the generous read first—learnings cascading down—and then concedes the other possibility: some teams haven’t made room for the rest of the team. Riddering puts it more bluntly: “I’m looking at a bunch of junior and mid designers that are getting cut out of the process.”

The other finding is that 59% of designers have built their own tool for their workflow. The example Geoco brings back from Vercel makes the builder-mode shift concrete:

When I went over to Vercel, they had this brand designer, who had never coded before. And now was vibe coding a tool. Their marketing team would put out blog posts. And they were like, “Why does the design team need to create the OG blog post cards for every page? That’s not a good use of [their time].” So he built a tool that just allowed them to insert any sort of images. And it just already had all of the branding and the sizing baked in. And they just roll these [tools] out quickly. And I’m like, that just became a tool, an internal tool. That’s cool. And so because it was really interesting that they started referring to him as a brand engineer… And I’m like, okay, that kind of qualifies it actually.

A designer who had never coded solves an actual marketing-team problem, ships the tool, and the role title arrives after the work. That is how the next batch of “blank engineer” titles is going to land. Riddering then describes how the orchestrator pattern works in his own day-to-day, offering a concrete account of the workflow I have been writing about as orchestration from a working designer:

Part of me is almost slightly self-conscious about it. But I do the vast, vast majority of my messy explorations with AI now. I feel like I have made the jump to the quote unquote creative director where I’m just working with AI to show me a certain thing 50 different ways. And then I’m pulling the pieces that I like and then combining them again. And finally I get to somewhere where I’m like, yep, that’s good. And then I take that from paper, run it through cloud code, and now it exists on localhost. And then I will sweat the details and actually do the precision designing in code, which is, that’s crazy, man. That’s a very, very different workflow than I’ve done at any point in my career.

The orchestrator gap is opening where I thought it would. What I did not account for is who is getting invited into that work first. The data Geoco surfaces points to leads, managers, and design engineers getting more chances to build with AI than junior and mid-level ICs.

Here’s a hypothesis I’ll put out there: leads are more used to directing. I’m personally comfortable with orchestrating, being the editor because I’ve been a creative director and leader for so long. The loop is right there: frame, review, direct.

After watching six agents design an app together in Pencil and spending a little time in Paper, I’ve been waiting for Figma to answer. Rodrigo Davies and Tammy Taabassum, writing on the Figma blog, finally announce it: a native design agent on the canvas, not bolted on through a separate app or a third-party MCP client.

Davies and Taabassum open with the pitch:

Designers need purpose-built tools that serve the essentials: exploration, experimentation, collaboration, and precision. Figma was built as a multiplayer canvas to make all of that possible. As teams adopt agentic tools to build products more quickly, false choices are emerging: Speed or precision? AI generation or direct manipulation? You shouldn’t have to choose.

Earlier this year Figma opened the canvas to third-party agents through its MCP server, letting Claude Code, Codex, and other agents push designs into a Figma file. That move covered the integration story. This one covers the in-app story:

That’s why we built the Figma agent. Our goal was to create an agent fluent in Figma and native to the way teams work. That meant making Figma itself legible to a model in ways that aren’t possible with third-party tools—with deep context on your components, tokens, standards, and best practices.

A third-party agent reaching in through MCP has to translate every request through a protocol; a native agent already speaks the file format. It knows your components, your tokens, your variables. That’s the gap between an agent that can edit a Figma file and an agent that lives in one.

The use cases Davies and Taabassum walk through—going wide on style explorations, bulk-updating variables across a design system, distilling comment threads into actionable plans—are the work designers were already paying the tax on. On exploration specifically:

The best designs rarely come from the first idea—or the first prompt. Exploring directions, comparing approaches, and iterating is already core to how designers work. Our agent will help you cover more ground in less time.

Renaming variables across a file, repeating padding changes through an entire flow, swapping one component for another across a dozen screens: that’s the busywork the agent is perfect for. The taste call on which direction to ship stays with the designer.

Davies and Taabassum close with:

Figma’s agent is embedded where the work already happens. There’s no toggle tax, no context switching, no learning curve. You stay in Figma and your team stays in the loop. We built this with one goal: to help you work faster without compromising on quality and craft.

That’s the competitive answer to Paper and Pencil. Agent-native canvases get a head start by not carrying any legacy assumptions; Figma carries millions of files and the design systems inside them. The bet is that the install base plus a fluent-in-Figma agent beats a greenfield canvas plus a generic one. We’ll see who’s right once the beta opens up.