Everyone is Building the Same Tool

This past summer I went to an internal tools demo night, and every company there had built the exact same thing. A prototype playground. Branching, sharing, some kind of collaboration layer, a way to pull in the design system. I'm not saying people are unoriginal, or that anyone copied an idea—it was actually very cool to see so many people converging on the same paradigms in real time, within such a fast-moving, unsolved space.

Now, maybe we're all geniuses and these paradigms are objectively the correct solutions, or maybe we're all just carrying around our respective years of design habits and just mapping them to this new world. But what is true is the problems we're all running into, and they're the same ones.

This is my attempt—full of human-crafted em-dashes—at sorting out which of these problems and workflows need a new tool created, and which ones just need a team that's willing to work a bit differently.

Rewind a bit

I joined Unify in late 2025. The design team was three people and the process was weirdly waterfally. Engineers expected finished designs and detailed specs. Designers handed them over with something uncomfortably close to redlines.

I came in as a big AI curmudgeon. I'd been at GitHub when we launched Copilot, which at the time was a cute gimmick that couldn't code nearly as well as you. Then, throughout my time at Heap the models steadily improved but hallucinated half the time and often ended up creating more work I had to deal with. After Heap I took two blissful tech-free years off, and every company that pitched me during those two years was "AI for X," which always ended up being a shallow prompt layer on top of a model. It was boring and depressing, and I started telling headhunters to miss me with their AI opportunities.

Then I joined Unify right after Opus 4.5 came out, and I finally had a reason to use it. It took about a week to get completely AI-pilled. I might have set a record. In time, my string of prototypes got the rest of the team there too. The team's work rapidly shifted from perfect design-system-compliant screens to getting clarity on an idea as fast as possible. We didn't arrive at the perfect mature tooling I was striving towards before I left, but we threw a lot of stuff against the wall, and we ran into most of the same walls everyone else is running into. Not the one we threw stuff at. A different wall. Walls.

As far as I can tell, everyone is dealing with—and working on—some version of the same five things:

1. Getting fidelity on an idea really quickly
2. Working with your real product on a canvas
3. Getting designers to ship to production
4. Getting agents to ship good design
5. Seeing and reviewing all the work

I'll go through what we did for each, and whether I think it's worth building a product and business around. But first, the question that sits underneath all of them.

Build it or buy it

As I'll mention a hundred times in this post, one of the biggest things that's shifted is the correct answer to "should we just build this?" At Unify we had unlimited Codex and Claude tokens, and anyone could pick up pretty much any tool. Our post-sales team built a ton of internal tools for themselves, as did our sales and support teams. With models improving, ambitious ideas are getting closer and closer to one-shot territory.

The thing many people miss when talking about this stuff, is that when you build something, you're also building yourself a new job. The questions I ended up asking were roughly:

1. Is buying it prohibitively expensive? Is it feature gated in a way that makes sense for our needs? The bar here is getting higher considering you're pitting this against maintenance burden, not another source of (direct) monthly run rate.
2. Does it need to fit exactly how my team works, enough that I'd rather own the maintenance?
3. Does it just run once it's built, or does it need constant care? If it just runs, there's no question.

I built my own Granola, because it felt worth it. But Granola has an engineering team working on the fundamentally hard parts, the denoising and diarization they've already trained, and they keep shipping. Building it myself means signing up to keep up with that. And while it felt worth it for a time, by now they've shipped all the things I originally built it for.

Anyway, let's get to these juicy design problems.

1. Playing in the sandbox

I built my own prototyping sandbox. Then every designer on my team built their own prototyping sandbox. Everyone in the industry has built their own prototyping sandbox.

But Joel, you might say, wouldn't it be better if you all worked on a single amazing prototyping sandbox? And to that I say nah. This category of tool is about trying many things out rapidly, letting your curiosity and weirdness lead the way, refusing to be constrained by a system of rules designed to keep you down your product consistent. The goal is not to arrive at the solution, but rather the direction (be it system design, flows, a novel UI pattern, whatever).

So consistency in tooling across the company isn't nearly as important as building the tool that will help you specifically progress as fast as possible. AI makes you so fast, but you find yourself asking for the same stuff over and over. What are those things for you? This is all duplicative and a little wasteful, but it's faster. Your sandbox is a cluttered drawer, and if someone tidies it for you, you have to relearn where everything is. There's some upfront cost, and then it gets faster, because you know your mess.

Mine had sliders for direct manipulation instead of prompting back and forth, hot-swappable components for quickly testing a bunch of versions of a thing, and settings for flipping between states. It ballooned into a monolith. But the patterns were straightforward, so after I forgot my laptop at my gate at SFO, in my shame, I rebuilt the bones of it in about an hour. The issue obviously wasn't making the thing, it was arriving at these patterns I found super valuable through a process of trial and error.

A month later, Josh Puckett released DialKit. It was and is such a great piece of tooling, but its biggest impact was cementing—in public—the best practice of direct interaction rather than the inefficient back-and-forth natural language that had become so prevalent. I'm sure we'll soon see the same with hot-swappable component and state engine tooling become popular. Recently, Maayan Albert, one of the demoers at that internal tools night, released Proto—a new design tool that has this concept built in. This quick aside is just me being excited at all the best practices I haven't heard of yet!

Anyway back to the problem at hand. Sandboxes! Another characteristic of prototypes built here is that they are almost certainly throwaway. An engineer wouldn't let it within a mile of the codebase (though an AI reviewer might). But this is a feature, not a bug. Production quality is a constraint and constraints keep you down. So instead: no quality. No quality, no pressure, and we make cool shit.

My sandbox became the fertile soil upon which Unify's future was built. Literally the prototype that pivoted the company. Was this the version that made it into the product? No, of course not. It couldn't be, didn't need to be, and thank god it wasn't. If it had to be closer to our actual product during exploration, it never would have materialized. When something isn't baked yet, the dogma of your existing design only holds it back. In that sense, these sandboxes are much closer to sketching or paper prototyping than even Figma is. Everything is possible, all you need is your imagination. And tokens. Free tokens, ideally.

For going wide, I used Pencil (now Pen) and Paper (now Parchment or something idk) for a while. These can deliver on an adjacent job to the sandbox: "Here's the problem, here's more or less the system I have in mind. Make 60 versions of this while I go for lunch." It was the first time I saw agent swarming, a bunch of tiny cursors building at once—which, let me tell you, if you haven't been AI pilled yet this might very well do the job. Now, these little cursors are not amazing designers, but they also fuck up in really interesting ways. Things I would never have done, because they take a truly deep level of misunderstanding, can result in real gems.

Does this need a product? I don't think so. The playground is the tool everyone builds at demo night, and it's better when it's yours. Swarming on a canvas is great, but to me, it's more a feature than a product. At the time I was doing the same thing in Figma via the Console MCP. Now it's even easier, and in a couple months I imagine there'll be a single open source package that gives you 90% of what you want with a single prompt. The thing people are missing are the patterns that will lead you to success.

What matters here is the loop. Make something not quite right in five minutes, react, iterate. That's what I love about designing with AI, and it's the first thing the next category gives up.

2. Your real product, on a canvas

This is the one everyone dreams about. Open my actual app, drag things around. It maintains logic and Just Works™. Duplicate a screen to try a different direction, and under the hood that's a new branch.

Before I left I piloted one of the tools going after this. You connect your codebase, it ingests it for about a day, and then you prompt changes and see them side by side on a canvas. I enjoyed seeing things side by side. A couple of designers on my team were more impressed than I was.

To me, the result landed in an uncanny valley. It's still early in the era of these tools, so this was not yet production-ready code. The two-way street you'd want with your codebase wasn't feasible. The designs it outputted felt like slop forced into our own system's language. And it was slow. Instead of something not quite right in five minutes, I was waiting 20 minutes for a design that might not be right. The more time something takes, the higher your expectations, and what I got wasn't miles better. This was just one approach among many (think DESIGN.md files, design system MCPs, Pen and Paper, tools to pull real customer data in for edge cases, and so on and so forth). I piloted many other approaches around the same time and this was the current leading edge.

That said, the problem this category of tools are attempting to solve is hugely critical to the future of product development. Applying a real-life source of truth to your designs leapfrogs the high-friction slog of building the various screens you want to create or edit (either from scratch, existing screens, or a library of Figma components you need to string together).

More mature solutions in this space may finally solve the challenge of keeping your design tokens and components in sync with production, something that's never happened in the wild, not even once. It's the holy grail. The thing that will finally eliminate the sisyphic work and maintenance that's always been part and parcel with digital design. It means when you need to work on something, you just do.

I see this as fitting neatly into a process of sandbox for direction and canvas for execution. The next category will discuss what comes after this.

Does this need a product? With this one I'm not sure for a different reason. A reliable tool in this space would be huge, but the main benefit of being able to extract the source of truth with high enough fidelity and certainty is something that frontier models are most likely to accomplish. A product can build the canvas and tooling around this ability, but its stickiness will require enough functionality that it's no longer worth just building and maintaining yourself—and the easier it becomes to one-shot, the higher the bar for these tools.

3. Designers shipping to production

One of the hurdles of product design has always been bridging the gap between your imagination and reality. Research adds friction. Rigor adds time. And companies—more so these days—expect a lot in very little time. So what happens is you design flows with hypothetical users and states in mind, and these inevitably miss many things.

Designing and working directly in your codebase can help you interact with the constraints of the system and work through flows in context at the exact moment you need those answers to improve your designs. Though this is arguably part of the previous category, if and when it gets good enough.

The bigger unlock here is the boost in velocity when engineers review real PRs instead of mocks and prototypes. The interpretation layer disappears, and the work of figuring out what is and isn't feasible, how to implement a design concept, which implicit states to account for, or what needs to change to match the system shrinks considerably. Much of that work will have been done throughout the design (and development) process.

Engineers will be freed up to focus on more impactful work. I imagine many front-end specialists will shift to design systems and front-end architecture rather than implementation, where they will be much more highly leveraged.

The main issues here are:

1. The translation layer between code, design tools, and back.
2. AI code quality is still far from enabling non-technical people to ship solid production code, though this is improving rapidly with every release.
3. The cultural issues that come with messing around with someone else's domain. Though, again, I think this will naturally shift as everyone becomes more empowered to play in arenas they haven't specialized in.
4. All the other DX tooling that needs to be put in place for this to work, such as cloud dev environments or staging environments with easy deployments.

When these are resolved, for better or worse, we'll start seeing way more one-person teams shipping at a fast clip.

Does this need a product? 100%. I think this is the safest bet of all of these to pursue. The stakes are higher with product code so rolling your own tool is riskier. Designers need to be able to spin up an ephemeral instance of their codebase, alter it, engage with it, iterate on it, and push it—all while using real data and services, and ideally without the complexity of the underlying systems. It's a less glamorous space than a shiny canvas, but there are so many things to get right that it feels like a real moat, even with models improving. It's also exactly what the current trajectory of product development needs.

I care about this one a lot because it's where quality comes from. I can't spin up a prototype to fix a tiny interaction on a page that already exists. And I likely won't ask a friendly engineer to fix all the things that bug me. These details are always P3s, but they're also where a lot of the end-to-end quality wins come from, and on the flip side, where the cumulative this-product-feels-bad vibes come from.

No, I just want to open a quick PR and fix it myself, in production. Better yet, I want to just tell an agent to do it.

4. Agents shipping good design

The obvious next step to this is freeing yourself up for higher level tasks by letting agents figure out the small stuff. This, again, is where a lot of experimental methods like DESIGN.md files, design system MCPs, various configurations of skills and heuristics, and design-specific harnesses come in. Some of these attempt to output designs that follow your design system, a la the first category. Almost all so far have had to do with hard skills—visual design (or explicitly avoiding slop patterns), animation, interaction, front-end implementation. I'm curious what the more cerebral parts of this might look like. Either way—nothing, so far, has figured any of this out.

The end game is to have an agent that can autonomously produce designs, both detailed and high-level, that can match the quality of output from the most senior and talented designers. Design is an extremely fuzzy and broad field. It includes an area of attention that ranges from the position of a single pixel, to the arrangement of components on a page, to the friction in a set of steps in a flow, to the words used to describe and delineate the core concepts of a system, to the user needs being solved for, to the business goal all of this is supposed to accomplish. This is a lot for any model to account for, and they can't do it yet. So what we do is develop a series of crutches and bandaids.

Let's start with the most basic of these modalities. At Unify, I spent a bunch of time editing our AGENTS.md for design tasks: telling our agents which components to use in which cases, and what visual balance even looks like. Engineers were doing the same thing on their side, defining what kind of PR they'd be comfortable with.

What I learned is that there's a real tension between using a design system and looking good. If you teach a model how to make things look good, it does that, and its main tool is slop. It fills every area to create balance, and rarely with anything useful or relevant. If you tell it to use your design system, it stops thinking about layout entirely. It drops a component in, large and empty and haunting, and calls it a day.

So I added steps. Measure the empty space, and if there's too much, fix it. Now the agent has to build the thing, look at the thing, and rebuild the thing, which is super slow. The version that started getting somewhere looked more like a design process. Spec it out first and assume a size, so you're guessing at the layout before building anything. Critique the spec. Do another one. Show me, I critique it. Then build it with the real components.

That costs a ton of tokens, requires human intervention, and takes the time you hoped AI would save you. So far that hasn't mattered much, because we've been in tokenmaxxing paradise. That's already started to change.

Does this need a product? This is a real issue with a ton of leverage, and a hard problem to solve. I can imagine a lot of point solutions focusing on various parts of the design process. There has already been plenty of progress here. Multiple designers releasing their expertise, distilled into skills, with evals to prove their efficacy. Most of these have been open source (Anthropic's aggressively mid frontend-design, Impeccable, AI for UI, Stageshow, Califa's Better User Research). Some have been paid (ui.sh, Interface Craft, Shift Nudge), often alongside educational material, which makes sense I guess, considering teaching and skill building require a similar process of articulation.

While there's at least a bit of a moat around specific expertise and process, we all know that the labs just loooove stealing—can't get enough of it—and if you have access to a skill, so do they. Before long a lot (more) of our discrete processes and ways of thinking will be table stakes for frontier models. So I wouldn't build a business around the knowledge itself.

The thing that might be able to create some gravity is an interface or harness that gets a lot of the behavior and the human-agent feedback loop right, but even that feels short-sighted as we near a future where we implicitly trust agents to just do the work. In building this website, I shifted from manual design work, to working in an agent, to easily rolling my own tool to comment directly on the site and have the agent deliver implemented designs to me—not great designs, of course, but that's a matter of time.

Joel Califa

@notdetails

I built a critique flow on my new website for friends helping QA it, and it’s so ergonomic that I now use it instead of talking to Claude directly. Comments 👉 Linear tickets 👉 Triaged by Claude, which takes a stab at it. I come back to a bunch of previews to test and approve.

10:32 AM · Nov 6, 2026

17 likes1 replyView on X

I doubt this category will even have an interface down the line. Bottom line: in the interim I love to see tools in this space and find a lot of value in them, but I think there's an expiration date on all of them.

5. Seeing the work

Even before AI made a messy world even messier, organizations had trouble keeping track of all the work happening within it. That's why every designer who ever left Facebook has attempted to recreate Pixelcloud, its design feed. It's why product channels are spun up on Slack, why activity feeds exist on Linear, and why there've long been lurkers all over Figma. It's simply impossible to keep up with all the work.

Guess what—there's more work now. A lot more. An exponential amount flowing like there's no tomorrow. And you can't count on your entire team being in Figma anymore. Not even in its drafts. No, today they're spinning up their fancy sandboxes, sometimes locally. Their design assets are Claude artifacts or Replit prototypes or Vercel staging links or PRs you'll never see before they go out. Things are moving so quickly now, because what's happening in design is happening in every field. Velocity is skyrocketing, and with it the pressure to move quickly. Custom tooling is skyrocketing, and with it the fragmentation of work product.

So where does critique happen, and how do you maintain quality as the train barrels forward? Our approach was relatively low-tech. A Vercel deployment behind our login and a three-minute Loom of someone clicking through the idea and explaining it, posted in a public design channel the moment it was ready. We commented on the Loom instead of the prototype, which honestly got better feedback. It worked fine.

The "everyone posts their work in one place" tool Facebook people are always trying to make has never worked for me. I've never seen one be sticky enough for a whole company to buy in. At Unify we tried Threads for async critique because we were remote and our async culture needed work, but it was really hard getting people to open it on top of Slack. Today, it's pretty straightforward to develop your own internal version of this, but it'll suffer from the same issues. Manual work to remember to post. Maintenance. Change management to get people to use it. And the larger issue: a linear feed is not a good fit for the future pace of product development.

At Unify, I made myself a bunch of dashboards and cron jobs. I had a daily brief based on the Figma activity log that told me which Figma files were being engaged with the most, and who was engaging with them (Designers meant they were in flight, PMs or leadership meant they were being reviewed or specced, Engineers meant they were being developed). It picked up which design tickets were being completed in Linear. It picked up when Vercel links were posted in public channels, and when design decisions were being discussed. It gave me an extremely valuable and condensed download every morning of everything that was happening on my team. I was pretty proud of this, but quickly humbled at a design event where Meaghan Choi ran us through her set up that funnels every PR with a design or front-end change to a central review log. Other folks have set up automated video walkthroughs of every meaningful change.

These things are moving quickly, and they're going to be key in a world of one-person teams shipping hundreds of things a day, no longer constrained by the systems meant to keep us down our systems in check. The failsafes we put in place to ensure standards are met are only going to be so effective, and I think there's real room for products that help us oversee all this work at scale.

Does this need a product? Counterintuitively, I'm going to say yes! Historically, I've rarely seen real budget go to design quality control. But with volume rising this quickly, and with execs closer to the product than ever, I think the winds might shift. In a sense, the foundation of this would be something that already exists in spades: a personal agent with enough connectors to be useful. This is the thing that can finally avoid the death knell of every activity feed I've ever used—the need for people to manually maintain it. Applying inference to the ambient activity across your various tools and spaces can provide you with a real picture of what's going on. People can personalize the summaries to their needs. It's a trend we've seen a lot and will see a lot more of.

But the second part of this, the feedback loop—see work, comment on work, get updated on work—is a bit harder to pull off, and requires an opinionated approach to get right. It's not as simple to roll yourself because it often requires interfacing with multiple systems and multiple people. There are many more universal workflows that will likely need to be built and integrated, making it the kind of product and interface that almost isn't worth maintaining yourself. I think a truly good solution for this could become a tool with some longevity rather than being sucked up into a lab or an IDE, though there will be a lot of players going after it.

The parts that aren't tools

Some of the hardest stuff wasn't tooling at all.

Engineers wanted something boxed in and defined. Even really product-minded engineers got uncomfortable being handed a prototype and told to go feel it, understand it, and then build it. Designers had the opposite problem. You can suddenly do everything, so under a tight deadline someone would drift into "oh, but isn't this cool though?" Yes. We have stuff to ship.

There were two philosophies about what to do with all the speed. One was a really tight spec you can hand straight to an agent. That's a legit direction. Mine was that we can build stuff really quickly now, so stop chasing the perfect spec. Do quick throwaway forks, feature-flag some people in, see if it works, adapt. I've never been interested in a perfect handoff anyway. It's always felt like an anti-pattern to me.

None of this is new, by the way. It's just Lean UX. Embed designers with the product team, produce fewer artifacts, build together. It just became the only workable option. Implementation got this fast, so design has to move this fast too, and if you try to think of everything in advance, design becomes the bottleneck immediately.

So what's worth building?

Things are changing fast, and these are real problems. But squint at the five of them and a pattern shows up. The parts that feel the most like design—the sandbox, going wide, teaching an agent some taste—are the parts you can build yourself, and probably should. They're personal, they're cheap to make, and the models are eating them anyway. The parts that actually need a product are the unglamorous ones: getting a designer into production without a crash course in git, and keeping track of everything once everyone (and their agents) is shipping into it. Plumbing and oversight. Nobody demos plumbing at demo night. I mean, now they are.

This is probably why we all built the same playground. It's the fun part. It's where you feel the loop, and the loop is what got me AI-pilled in the first place. I don't think anyone was wrong to build it. I just think the tools worth paying for are the ones that come after it—the ones that turn a pile of throwaway sandboxes into a product that ships, and still feels good when it does.

Near the end at Unify I was testing every tool I could find, hoping one of them would mean I didn't have to build this stuff myself. I left before I found one, and I'm less bothered by that than I expected. Most of what actually moved us wasn't a tool. It was engineers getting comfortable building from a prototype instead of redlines. It was a Loom in a public channel the moment an idea existed. It was a team that stopped chasing the perfect handoff. The tools mostly just got out of the way.

So I still don't know whether demo night was a room full of geniuses or a room full of old habits, and I'm not sure it matters. Build the playground for yourself. Buy the plumbing once someone makes it good enough. Spend everything else on getting your team to work differently, because that's the part nobody can sell you.