• Impeccable
• Impeccable Pro
• The Impeccable slop catalog
• The Dark Arts of Skill Engineering talk

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike, and today’s interview is with Paul Bakaus. Paul is the CEO and co-founder of Renaissance Geek, the venture-backed company behind Impeccable, the viral agentic design tool. Previously, Paul created jQuery UI, was a DevRel lead at Google, and was the CTO of Zynga Germany. Welcome, Paul.

Paul: Thank you very much for having me.

Allen: I’m glad to have you here. It was like fate that we sat beside each other at the AI Engineering World Fair, like two or three weeks ago, and just started immediately geeking out around harnesses and agents and velocity of teams and design slop. And then you’re like, hey, I’m giving a talk. Of course, I was in the talk. And I’m like, this is something we need to bring to more people. So I’m really glad to have you here.

Paul: Yeah, absolutely. Let’s chat and give everyone all the deets.

Allen: Yes. So we’re going to go into, of course, Impeccable and what you’ve been building, what you’ve been learning doing that. I understand that there’s a new release that came out like minutes ago. So we’ll get into that. But first, just give some people some context, who you are, where you’re coming from. How do you like to kind of summarize the kind of high-level soundbite of the Paul story so far?

Paul: Yeah, absolutely. Yeah. So I’ve been in the game for quite a while. I’ve been a front-end engineer before there was a term for front-end engineer. and people thought that was a stupid career decision at the time.

Allen: It’s just JavaScript, where is that going to go?

Paul: I know, right? But it worked out okay. And so for the last 20, 25 years, I’ve been building front-end and most importantly, I’ve been building tools, all sorts of powerful tools. I think that’s kind of the through line. Started doing agency work in Germany and worked on some really large-scale applications at the time. So this was before Gmail was a thing and the T-Mobile, Deutsche Telekom web apps actually were at the time some of the most impressive web apps. Like large scale calendar apps, full featured clients that were built in JavaScript. So I learned a lot back in the times from those projects. And then I also learned that it really is annoying to not do these things with a framework that powers these things. So there was this quirky new framework on the market and that was jQuery. and people thought it was very confusing at first and really weird and did things differently than others.

Allen: It was amazing how successful jQuery was given how weird it was compared to the stuff that came before.

Paul: Yeah, that’s right. But it sort of clicked for people and it clicked for me and so I started contributing more and more and became part of the jQuery core team. My affinity was actually mostly towards UI and UX. I guess I was a design engineer before you could call it a design engineer before that term existed. But that’s why ultimately John, who created jQuery, asked whether I want to do the official UI project for jQuery, jQuery UI. So that’s what I’m mostly known for people who know me 20 years ago. And then I’ve done that for a couple of years, which became super popular. I’m very grateful and gave me kind of a front row seat at maybe like the Web 1.0 to Web 2.0 conversion path. And then I thought, what else? I mean, I was always an open web fanboy and I thought, what else could I bring to the table to the open web? And I thought maybe the next thing is gaming. So I spent a couple of years building a game engine for the web, sold that one to Zynga and spent a few years there leading their R&D efforts around like new technology. And then spent a long time at Google and actually eight to nine years. And at Google, I worked also on tooling. So I worked on the Chrome DevTools for a while. And the Chrome DevTools was this tiny team like originally based out of St. Petersburg.

Allen: Oh, I didn’t realize that. That’s like the origin of it?

Paul: Yeah, and I spent some time in St. Petersburg, which is now harder to do, for obvious reasons. But it was really fun. And it was really just engineers. They didn’t have designers. They didn’t have PMs.

Allen: You can sometimes tell, certainly in the early days of those tools, they were amazing and changed everything. But they were not exactly like this slick product thing.

Paul: Paul Irish at some point became a PM, and I became their DevRel lead. But to be honest, a lot of crossover. So he PMed some things, I PMed other things. I also designed a whole bunch of things on the project. That was a lot of fun. At the time, I worked on a pitch to the team internally that I called DevTools for Designers. I actually gave a conference talk about this at some point and led to features like the device mode, for example, the responsive design mode in DevTools. And then I switched over to Google Search after a while and I worked on features like AMP. AMP was kind of universally hated with developers.

Allen: Yes, it was.

Paul: I promised the intent was really good. It’s interesting, right? There were all these conspiracy theories around Google at the time and AMP. And these would make for really interesting dinner stories if they were true. But they were unfortunately not true. It was actually way more boring. Publishers were dying and asked us for a way out. And so we built a way out. And then they’re like, no, we hate this.

Allen: That was part of the fun of working when I worked at Apple that you would hear an external story that you’re like, I can see why our behavior… Might seem like some giant scheme, but it was actually just a bunch of people made a mistake or whatever.

Paul: Yeah, I mean, we made plenty of mistakes, don’t get me wrong, but it was well intended. And it was a really interesting challenge to be leading developer relations for AMP and building a whole lot of tools and ecosystem around it. Whilst, you know, a lot of folks were really not a fan of it. But we made it work for a lot of people for quite a while. But here too, the through line was sort of like giving people tools to build. And we built what you see is what you get editors for making visual stories on the web, stuff like that. And then I jumped back into the startup world because Google was moving too slowly for my pace. Before I did what we’re going to talk about, last couple of years since 2022, I think I spent working on YouTube software, basically like AI software that makes the biggest YouTubers in the world more creative.

Allen: Interesting.

Paul: And so I worked on helping them come up with new ideas with LLMs, with diffusion models for thumbnails. And in that process, I learned a lot about how to get an LLM to be divergently creative and how to make it creative and super, super hard, but super fun. And so now I figured there’s so many ideas that I had over the years that I collected of new tools that I want to build and new ways I want to help people have superpowers in this new age that we’re in maybe that I figured it would be time to create my next startup. And that’s why I’m here now.

Allen: Well, my sense with Impeccable is the origin story of a lot of tools that are changing the way we work right now is because we have this huge disruption that suddenly a whole bunch of things are possible that weren’t possible and it’s all hard to work with because it’s all new. A lot of us are just like, okay, well, I need this tool obviously. And then it’s other people who are like, oh great, you made that? Can I use your thing?

Paul: Yeah. In the last year, I did a whole bunch of contracting for some of my friends, colleagues, because I wanted to simply explore what problem do I attack next. And I think this is not a unique story by any means, but in the process, I realized there’s still a lot of tooling that’s not built yet when you want to go fully agentic. And San Francisco has no shortage of dev tools builders. And I did build some tools for developers, and I released a whole bunch earlier this year. The one project that really made an impact was impeccable because interestingly, it speaks to both developers and designers and product managers. And PMs. Yes. So I think the whole world is converging towards code. Designers are definitely moving downstream into code as well. And Impeccable speaks their language. Not something, by the way, that I expected. Hindsight is always 20-20. I thought it would be…

Allen: You thought it’d be a developer tool? Yeah, so let’s, for those who haven’t tried Impeccable or seen the various tweets and things, how do you describe it? I mean, so Impeccable 4 just came out like minutes ago. So maybe how you describe it has shifted. How do you describe it as of July 22, 2026?

Paul: I think the description is actually still the same. It is turning your coding harness into a design harness. You know, well, it can still code, but I guess it’s like a design harness, a coding harness good at design now. Now, how does it do that? It gives your agent the vocabulary of design. One thing that I noticed when seeing designers work in Claude Code, for example, and engineers work in cloud code is that designers will usually get better results if they know how to produce.

Allen: Better results for their designs, but perhaps worse results for their code.

Paul: Correct. Yes. So there’s a compromise. But better design results. And I figured, why is that? And it turns out they just have a completely different language that they use compared to engineers. Engineers usually don’t use terms like vertical rhythm unless you’re a design engineer.

Allen: Or information hierarchy.

Paul: But if you don’t, if you see something that’s broken, right? If you see a page and you as an engineer, you can identify it doesn’t look good. But if you tell the model, hey, this doesn’t look good, that leaves too much room for interpretation, right? Yes. And the multimodal capabilities of these models are actually not good enough yet to make sense of it on their own. So it’s really like shooting in the dark. So I noticed how designers were using, and including myself, by the way, are using Claude Code and other harnesses. And I figured there must be a way to take this language of design and package it. And so that was sort of the origin of Impeccable. I figured, okay, well, I think I can package this as a package of skills initially and ship it and give it to others who need it as well. And that allows me to say things like, hey, make this case study section bolder or clarify the UI writing in this area. And the agent would actually know what bolder means in the context of my site and my design system, as opposed to just doing whatever it wants to. So that’s That’s the biggest part of Impeccable, I would say. Now, another part of Impeccable is AI slop prevention.

Allen: That’s like a lot of where the fun on Twitter is around, especially in the last few months. People are becoming very aware of the pitfalls and the things we’re sick of seeing now.

Paul: And I would say that’s probably definitely the gateway drug or door opener for most people who arrive, who try Impeccable for the first time because it’s very, very good at that. It removes AI slop both through its skill, through the LLM instructions, but also through a deterministic detection engine that is in hooks in your agent and actually prevents these things from ever happening. So it has like more than 50, 60, 70 rules or something for all sorts of slop, right? And these are things like side tab borders or italic serif fonts or purple gradients. One of my new favorite pet peeves are blinking dots.

Allen: Yeah, yeah. It’s like a blinking dot as if it’s live connected to the server, but it’s just blinking. It’s just making it look cool.

Paul: Yeah, and then another pet peeve that many I think will identify with are eyebrow or kickers.

Allen: Yes, like the little bit of text on the top coming soon or new or nothing needs to be there, but it sticks something there to make it kick it up a notch.

Paul: Absolutely, right. And so Impeccable detects all of those and then strips everything out. So it creates a pristine baseline first, strips everything out and then can rebuild on top. So that’s the essence. Now in the process of building it, I also realized that especially when working on something like colors, very hard to do that with chat.

Allen: Yeah, yeah, yeah, yeah.

Paul: Describing your ideal palette, right? It’s very hard to do in chat. And so I figured this is annoying. I want some sort of visual iteration mode. I don’t want to go to Figma though. I want to stay in my own code base. So for that purpose, I noticed there were emerging projects like Agentation, for example. Agentation, though, if you’re not familiar, it’s a React-only tool that works out by MCP and built by Benji Taylor, who’s now head of design at X. It’s super cool. It inspired me to build what I’m going to talk about next. But it is limiting because it uses MCP and MCP doesn’t wake up the agent on its own. And then it also only works for React as far as I know. And what you can do then is basically in your own live development server, you can leave comments on the page and then tell the agent, hey, I just left some comments on my page. Can you actually look at this?

Allen: As in like you can click on a particular element and comment on that element.

Paul: That’s right, yeah. Now, I think that functionality is now pretty common in harnesses actually, like Codex has this feature, Cursor has this feature.

Allen: Cursor has it.

Paul: Impeccable Live, which is what this version of the feature in impeccable is called, actually goes way further than that. If you spin it up, you actually get a UI picker and then you can click on anything on the page and say like, hey, I want four new variants of this element. And then your agent actually generates the variants immediately, pushes them back into the browser and then you can browse the variant.

Allen: Carousel through them.

Paul: Yeah, you can carousel. You get dynamically created tunable parameters for these variants as well. So you can change density and things like that when appropriate. And you can, of course, use the impeccable command palette. So you can say, I want five different types of animations for this element. Or I want better colors. And so create four versions that use color in different ways. So there are lots of different ways to use it. It’s a powerful visualization mode that sits on top of impeccable. You can also use it without.

Allen: Those interactive tools like the generative sliders, a lot of people had opinions about how the Claude Design, or at least the Claude Design as it exists in June, July 2026, leaves a lot to be desired. But when I saw that they had, like, one of the main things they were thinking about is, like, how do we give you grab handles to try different ways of expressing this and exploring this design space? That’s one idea that I think is, like, as you’re describing, like, it’s just so much easier to use a pointing device to explore a design space than to use words. Yeah,

Paul: yeah, absolutely. I was both very glad when I saw that others had the same idea and very annoyed, to be honest, because I had like a working version of these tunable parameters in a branch for a couple weeks. And then I saw them ship before I did. But it is what it is.

Allen: That’s the fun of being in a moment like this when there’s so much change and there’s so many people building, there’s so many pushing boundaries, is that we’re all going back and forth, being so inspired that we’ve found something new. And then still being annoyed that someone else is also building it. And then that competitive but inspirational loop is how you get these moments of Cambrian explosion.

Paul: Absolutely, yeah. And it’s really fun. I mean, I think it’s an interesting topic on its own. Like where is the moat? because there might be no moat right now for many problems. I think my friend Anish at A16Z just tweeted about it this morning, and I think he caught it in a really clever way. It’s like, hey, you have to think about if in my product or my feature, will my product or feature, will I be sad or happy when the models get better or not?

Allen: Yeah, Sam Altman has mentioned this over the years too. Of course, he’s more inclined to want you to think that way. But it’s a really useful mental model. Because if you’re like, well, the models are just going to eat this functionality next year. Then you probably do not have something super valuable.

Paul: But Impeccable, for example, right? Impeccable has areas where I would definitely be sad if the models get better.

Allen: Right, because this thing about it’s making it not do this useless design behavior, that the models will obviously inevitably stop doing that.

Paul: That’s right. But then there’s also other areas like the live mode, for example, or the hooks-based detection system, stuff like that. that’s more like harness expansion, I would say. As opposed to model expansion. So that’s really more about UX of the last mile. And that, I think, is a moat that’s more durable. As opposed to, hey, let me remove this AI slop for you.

Allen: Yeah, that’s obviously… We’re all building things and trying to simultaneously build something that’s going to be really valuable for a lot of people over long term, as well as get initial users. So if the initial users come from a temporary pain, but then that builds your flywheel for the long-term really valuable thing, then I think that’s a great way to build a product right now. So you mentioned a bunch of things that Impeccable does. And perhaps the sort of most sophisticated sounding is this if you have a live skill that obviously has some sort of server in a loop where you’re interactive in the browser and it’s changing things. But Impeccable is a skill. And a lot of people have the mental model that a skill is like an MD file. And then if you say, oh, our product is a venture-backed skill for Claude, people would say, no, that’s not a thing. A skill is an MD file. So I’d love for you to share a little bit. You had this talk, which basically just goes into that. So we’ll link that in the show notes. What’s the high-level takeaway of the talk so we can convince people who are interested in pushing the boundaries of this stuff to watch it?

Paul: Yeah, I think you phrased it well. I think mine is probably the most extreme case of like, oh, I started with a small MD file and then it all escalated from there.

Allen: It’s an operating system for design in a package

Paul: with a compiler. But yeah, first of all, I think what most people don’t realize is that a skill is not just an MD file. It’s not just prose, but it can contain as many JavaScript files or Python files, scripts that you want. You can ship tons of logic with it. And that means deterministic logic that executes things, makes requests, all sorts of things. And so I think it’s not good to think of a skill as oh, it’s just an extended prompt. And I think that was the topic of my talk, The Dark Art of Skill Engineering. And there’s an article version of this too that maybe you can link to as well now. But really, I wanted to shift the mindset from okay, I’m building this prompt extension to I’m extending the harness.

Allen: I’m basically

Paul: creating new functionality where there wasn’t any in my coding agent or harness. I think that’s an interesting shift in how you think about a skill. And in my case, yes, it started with a single skill and then expanded to a whole bunch of skills. And then I realized, oh man, I’m blowing through the context of everybody’s system. Which is not great.

Allen: Total cost exploding.

Paul: Exactly, right? Because all of these skills, the front matter is all loaded into the session. And so ultimately I ended up with just this one skill that almost works like a mixture-of-experts model with a router.

Allen: Like a router almost.

Paul: That’s right, yeah. And so there’s like a pretty lean core and then it routes into different areas based on what it implies the task is. Or if you explicitly say, hey, okay use the bolder command, you can do that too. And then it has like a whole bunch of scripts that it will use for all sorts of use cases. And I think that’s probably the biggest learning is that whenever you can do something deterministically, do it. Like don’t rely on the LLMs to do the right thing when it comes to instruction following.

Allen: The best case scenario is that they do correctly follow the instructions at great expense. That’s the best case.

Paul: And GPT-5.6 is actually the worst offender here.

Allen: Oh, really?

Paul: Yeah, I mean GPT-5.6 Sol. Oh,

Allen: just in terms of going and spending extended effort to do something deterministic and actually doing it expensively.

Paul: Absolutely. I don’t know if you saw the news of the security breach. Yes, yes.

Allen: The model was under test and it just found zero-days to escape its sandbox just so it could try to cheat on the exam.

Paul: Yeah, I think that’s a great example because I actually, I mean, I guess this is a bit embarrassing to admit, but I just got gaslit by GPT-5.6 and three days working with GPT-5.6 after basically I worked with Fable on improving Impeccable 4 and then I came to a point where I got stuck. I’m like, you know what? I’m going to switch over to 5.6. I want a fresh perspective and then I worked with 5.6 for two or three days straight probably like 30-40 hours of work and I was so convinced by GPT-5. 6 that I’m moving in the right direction and it produced itself lots of tests on evals that proved its own points but at the end I ended up with like completely bland designs. It was a complete shitshow. And so got to be really careful of not letting these models go over-engineer stuff.

Allen: We have a whole new generation of its ability to be confidently incorrect at greater expense than previously.

Paul: Absolutely. And this, by the way, is like Fable is very different there. Fable, I noticed, will much, in my experience, will not be doing that most often.

Allen: Yeah, that’s been my experience too.

Paul: It’s less confident.

Allen: It has different problems.

Paul: Yeah, different problems for sure, right? I mean, sometimes it will commit to some really obscure creative direction and like, yep, I’m going to go down this rabbit hole. I think it’s going to be great. And then no, it’s not.

Allen: Yeah, but if you tell it, hey, that’s not great, it’ll be like, you’re absolutely right. And it’ll use the most weirdest language about to make bizarre compound words to say how the load-bearing mistake was whatever and quietly this and that. Absolutely,

Paul: absolutely.

Allen: It’s an amazing world we live in. So we’ve got Impeccable 4 now. Maybe now is a good time to – so I think folks have an understanding of what the skill, but don’t think of it as a skill, but basically like harness extension for being able to level up designs, remove slop, but also go further into building unique and creative designs in your front end or otherwise your development that you’re doing. what were kind of the goals of impeccable for and what did you learn building that?

Paul: Yeah, so first of all I think impeccable there are a bunch of design skills out there and ways you can fix this problem or try to fix this problem. Most tools new design tools and design skills I would argue are probably made for vibe coders so they’re made for people who want the design problem to go away.

Allen: Yes.

Paul: Let’s say you’re building on your app with lovable whatever and you just want a decent landing page design and then you’re happy, right? Impeccable wasn’t made for that. It’s very important to call out. Impeccable was made as a daily driver. I mean, I was working on an enterprise-level application, lots of states, pages, whatever. And I just wanted to have these new pages that I’ve been working on, features that I’ve been working on, to not drift anymore from the design system and just help me work on these designs better, remove slop, etc. So it was really meant to be a daily driver. So that’s what Impeccable is at its core. However, a lot of people are now using Impeccable to start completely new greenfield projects. And while I do think that that’s still a little bit harder sometimes than maybe going with something like Stitch or Figma or whatever at first, it is a legitimate way of starting a project. In fact, I think Impeccable does something that’s unique that many other design tools don’t do. And that is it does a product interview with you at the beginning.

Allen: Yes. And that was a hint to me using it, that you were serious about this. This is not just like a vibe code thing. It’s like if you’re not willing to spend five minutes talking through who your customers are and what you’re feeling you want them to have when they use their product, then you’re not serious enough in some ways about this project.

Paul: Because if you’re building, let’s say, a kid’s iPad app, right? And you’re having your AI design director design the thing for you. The AI design director, in this case, impeccable, doesn’t know whether the landing page is for kids or the parents. It’s a real problem.

Allen: Yeah.

Paul: I mean, that dramatic.

Allen: Are the kids four? Are they 14?

Paul: Yeah, that too. Exactly. Right. So that interview is super, super essential. And in general, I don’t subscribe to the idea of that one shottable design. I don’t think that’s real, to be honest. But and now we’re getting to impeccable for one thing that I noticed is for those who want to create net new design with impeccable and for those who want to create, let’s say, an expansion to the existing design. Let’s say they have a web app and they want to make a landing page for it, right? Or vice versa. Or they want a new case study section, whatever it is, right? So both of redesign or expansion or net new greenfield work. Impeccable had a bunch of shortcomings. It would do well usually with landing page design and with product design so like App UI, but it wouldn’t do well with things like documentation pages, which isn’t really landing page or product UI. It wouldn’t do well with portfolios and hobby pages because there’s nothing to sell there. You can’t have a big CTA, like hero button on a portfolio. That doesn’t make sense.

Allen: Yeah, so more just content, it sounds like.

Paul: So more content, more diversity of applications. That’s one big thing. And the other thing is, no matter what I tried, for instance, I have this evals harness behind the scenes. And I’m testing all the frontier models across different niches. For example, one niche is an observability platform, like New Relic or something like that. And observability platform is actually a really hard problem because culturally, there’s no real visual identity there. You can’t just say like, oh yeah, observability platform. I’m going to use this real material and I’m going to make it beautiful.

Allen: Yes, this is the color that observability looks like.

Paul: Yeah, no, it’s just black and I don’t know, whatever.

Allen: A graph.

Paul: Terminal, graph, whatever. It’s not, it’s a kind of a monoculture design wise. And in fact, no matter if you use impeccable before version four or the front end design skill from Anthropic or, you know, just no skill whatsoever, I can guarantee you the page that you will get for observability platform is basically like a typical SaaS hero, dark and then like a chart or something visualized in the hero. And that is the version you get every time. You can try to say be more creative. Not going to work. You can try to say, I’m a very demanding customer. It’s not going to work. Those eras of prompt engineering hacks are done. The models are unfortunately smart enough now to see through that. So that’s not going to work. You will still end up with that same…

Allen: All your competitors will have the exact same layout of the same page.

Paul: Absolutely. The models all gravitate towards the same well of sorts. I hated that. I really wanted to break out of that. I wanted when somebody starts a new project, I wanted them to create something unique that works for them. Now part of that is the product interview. Part of that is to put the human into the loop and get input from them. But Impeccable 4 does something much more extreme. There’s a new way of basically rolling dice in Impeccable 4, and I wrote a paper about it that I will probably release in the arXiv as well, that I think is actually like a true breakthrough in divergent creativity.

Allen: When you say rolling dice, it’s like this, how do I get you out of your median? There’s a latent space of all the things that the model knows about. When you’re playing Dungeons, if anyone’s done Dungeons & Dragons, you create a character or a world, you can roll at this table of all these different things that gives you a starting point.

Paul: That’s right.

Allen: It’s like that.

Paul: And there are a bunch of prompting techniques that I’m using. And so prompting is not completely dead. It’s going to create five to seven, maybe, ideas on its own based on lots of clever prompting and based on your input as well. But then most importantly, I’ve now created an API and this is part of the new impeccable offering as well that seeds creative worlds. I generated hundreds of creative worlds and visual identities and spatial composition layouts. And I’ve painstakingly went through all of them, human-approved them or not. And these are very rich worlds, right? It’s like 8-bit whatever visual design system or like Bauhaus era whatever design, right? So these are rich worlds with rich composition and rich ideas. And these worlds get seeded in in the design process as challenges to the LLM-created ideas that are based on context. So the LM seeded ideas have your context, and that’s great, but they are usually pretty safe and steer towards the same well. The challengers that are seeded challenge the model. That’s what they call challengers. And they force the model to go out of distribution.

Allen: Right. And say, are you sure this is better than if it looked like a Japanese teahouse? And then the model has to defend that.

Paul: Correct. And so the model will then, by the way, not make it look like a Japanese teahouse most of the time. Because it knows that’s too extreme. But the spark is enough to rethink what it’s currently doing. And so you as a user then get fused ideas, a mix of fused ideas. Sometimes like a challenge is directly accepted because it just fits, right? That can all happen. And sometimes the model decides in the end after re-ranking its own ideas. Now actually one of my ideas was the strongest, but more importantly, you as a user, you get presented these ideas. You can re-roll the dice if you want to, if you don’t like any of them. And then you can build that idea out. And that produces way more divergent creative ideas that are much less bland than before. I mean, it’s a night and day difference. I’m actually running a huge Evals catalog behind the scenes right now that I’m going to publish for the first time across all niches and competition skills, etc. To really show the difference because it’s quite stark.

Allen: I love that. Yeah, I’d seen a version of this years ago when they had the early stable diffusion type models where you try to make, like let’s say you’re trying to generate cityscapes and then it’s like it would create every single cityscape in order to be like I don’t know Hong Kong with neon signs or whatever and it was hard to get it out of that and so the trick was to have a little catalog of all divergent things like a cityscape that’s been overgrown by an apocalypse a cityscape that’s in Germany whatever and then that gets deterministically inserted into each generation and it randomly picks one of them and then you actually then start sampling the latent space and finding the stuff and of course some of them would be bad and then now in 2026 where you’re saying Impeccable 4 can have that, but with some reasoning. Like if it says, do it as an apocalypse and your thing is an observability platform, it should probably not look apocalyptic. But maybe that gives it some idea that it could be more austere or something like that.

Paul: Yeah, absolutely. And I think the important thing, by the way, also is that this is not templates, right? So there are plenty of skills and other systems out there that create templated design. And nothing wrong with that if you need it for internal users or enterprise applications or whatever. But if you’re building a landing page, you want it to be distinct and unique. You want it to stick out. It’s the whole point of a landing page. And so I don’t really subscribe to the idea of shipping templates so much. So these visual worlds, they’re not templates. They are really just these challengers that steer creativity. And yes, you might decide, I love this visual world so much, I just want this exact world. That’s up to you, right? That’s fine. But it’s not a templating approach per se.

Allen: You can imagine, and part of what makes me optimistic this is an approach to get more actual divergent stuff out of the models is that it’s the combination of you actually having an interview. Like if you’re just vibing coding off the top, it would be more likely for you to pick one of these visual worlds and it’s more like a template. But if your components of your system actually are defined out as like, here are the things that matter for my brand or what I’m trying to achieve or the feeling I want my users to have. And then it’s like, what if it was a demonic hellscape? Then the thinking model could be like, well, no, absolutely not. That’s wrong for this. But what if it was an angelic utopia, right? Like it might actually get it out of when combined with your unique things that you’re actually trying to do.

Paul: And that’s exactly what Impeccable 4 is now forcing the model to do. So it’s actually quite exciting. It’s a lot of fun. I just feel much more joy in these test runs, to be honest. I mean, it’s fun to do and it’s creative and stimulating. So I kind of really love where this is going. I want to build it out much more. And actually there are major milestones in Impeccable 4 that are still to come that will enrich this even more. But yeah, I think the results are very promising.

Allen: So this is like building in a direction that you’ve talked a little bit about. Like, obviously, you know, stripping slop is like the sort of thing that gets people in the door or that was the original maybe starting point of it. But you’ve said the main quest is amplifying human intent, which I just love the sound of that directionally. Of course, that’s what we want. We want human intent, not just a thing that automatically designs every page to look the same and then we just don’t need to design things anymore. Obviously, bias is people who like to design things and make good software. Tell me more about directionally, like kind of how you’re thinking. You have venture-backed business now, you’re hiring, you have this kind of directional vision. Tell me more about where that comes from and what you’re thinking so far to the degree that you can say in how you’re trying to bring that about.

Paul: Yeah, absolutely. So Renaissance Geek, the company behind Impeccable now and my startup. Impeccable, I would say, is the first outlet of what I’m trying to solve. And that’s the first problem space, and that problem space is design. and it was a very acute real space for many people. And so we will definitely produce a paid version of Impeccable, actually, Impeccable Pro.

Allen: You heard it here first, folks.

Paul: Yeah, shameless plug. There’s now a wait list on impeccable.pro.

Allen: We’ll link that up.

Paul: Yeah, and then also some enterprise products that actually remove slop at scale, so basically get you to a decent baseline. But then beyond that, what I’m actually most excited about is the generational problems that I see around any creative endeavor in the future. Because I think right now what these harnesses, whether it’s ChatGPT on the consumer side or Codex and Claude Code and all of these on the developer side, don’t really do well, in my opinion so far. First of all, they’re chat only. And there are others who are trying to solve this problem of generative UI. But that’s one big problem space. Not everything is made for chat. And oftentimes you want a much cleverer interface, much more structured or visual interface to do something. That’s one thing. The other thing is, to your point, amplifying intent. But then there’s really two phases, I think. There’s the initial phase, and that is what and why to build something in the first place. And so, what am I going to build? Why am I going to build it? And who helps me figure that out? It cannot be AI deciding for you, but I think AI can be a thought partner in that process. I think we can build tooling around this. And so, for instance, when you start a new project in a harness and we want to build this functionality for what it’s worth at Renaissance Geek, help me figure out what I don’t know. So if I want to build a landing page for a project, like if I’m not a developer, help me figure out what I don’t know, what I need to know. Help me figure out, create tools on the fly for me, create a path on the fly for me so that we can work on this project together over time and I learn what matters as well. I think that’s really, really key.

Allen: Or at least are forced to consider and decide what matters or communicate what matters rather than just vibe.

Paul: Yeah, exactly. Right? So that’s sort of like the initial phase. Now then there’s like the building and I think humans personally I think humans need to be in the loop more in the building phase as well. I don’t think it should be completely handoff most of the time but I know there are two camps here like there’s also the camp of Peter Steinberger, who’s into software factories and token maxing, and I just don’t really subscribe to it. But then there’s the final phase and the final phase I think we can all also all agree on hopefully which is the judgment phase and the polish phase. So there are two problems here. One is temporary, maybe, I don’t know yet. And one of them is eternal. And the temporary one, maybe, so again, here, there are two camps who are competing and have competing opinions, is polish. I think right now, for example, it’s not possible to get to great design with AI. I think it’s possible to get decent design, maybe. But not great design. Great design requires much more polish than what AI currently does on its own. It requires the eyes of a human and the point of view of a human. And so I think there’s the taste, you know, overused word. But there are so many aspects that bring something from like 80% to 100%.

Allen: Well, a bunch of it is the craft stuff of just like we don’t want a flicker while this is loading. but the agent doesn’t notice there’s a flicker because they only parse a reality at one frame per second or something like that.

Paul: For example, right? And I call this sort of amplified craft. So can we amplify people’s craft, human’s craft, as opposed to replacing it? Because right now, this is a real problem. How do you get from 80% to 100%? Right now, it feels like either I hand off this work to an agent or I do it myself. But where’s the in-between? This is a frustrating problem. That’s potentially a problem that would go away. Some people at least say that. Maybe it will go away. Maybe the models will be so good at craft that, I don’t know, in the future, a year or two from now, there’s never going to be AI slop, for example, right? Maybe. Now, I think that’s a contentious idea, but many Frontier Lab friends of mine would actually say this.

Allen: Well, there’s two parts of that. There’s the AI slop where it’s like, oh, it’s just flickery or this button is obviously janky. So that seems very plausible, But then there’s two meanings of slop. Because sometimes people say slop meaning a thing that’s objectively bad, but then a human passed along anyway. But then there’s other form of slop, like this beige Claude design where everything is nice serif fonts. The first time you see it, it doesn’t come across as slop because it’s not objectively bad. It just becomes slop through repetition.

Paul: That’s true. Yeah. And I think slop in this case actually is a moving target. So to your point, once everybody uses it, people identify it as slop even though it’s not necessarily. bad,

Allen: yeah. Em dashes are fine in principle.

Paul: It’s actually like purple gradients, there’s nothing really wrong with purple gradients, right? But they’re overused now. So, but anyway, like this craft phase, you know, we can argue about maybe that phase gets thinner and thinner and thinner once the models get better. Who knows, right? But then there’s the other problem and the other problem is judgment. So you as a human who’s working on something that maybe you’ve never worked on, you want to make a song, right? This is your first song. You’ve never made music before. How do you know whether what you made is good or bad? How do you know what the agent did is good or not. This is an unsolved problem for what it’s worth. And it’s a problem that gets significantly worse with new generations. I mean, new grads, students today who will never gain the experience. If you’re a front-end developer growing up today, right? Good luck getting like a junior developer job, to be honest. And then how do you gain the experience that you need to build the intuition to understand whether something is good or bad? Very hard problem in my opinion. And there are not enough companies trying to tackle that problem specifically. So I’m trying to attack that phase as well. So basically create the last mile for creative work, any type of creative project work that leads the human from like, okay, what do I even make and what do I don’t make? And why am I making it all the way to like, okay, I now know how to judge whether what I’ve made is what I wanted and other people want. By the way, you could make it just for yourself. Great. All power to you, right?

Allen: You know,

Paul: if you want to make something cringe or like a family calendar or whatever, But,

Allen: you know, I’m doing it purposely bad. But we’re trying to build a valuable business. And so we want to solve valuable problems, which typically means a lot of people are going to use this software and get value together. Two

Paul: different problems, right? And so I’m trying to attack this whole space, produce solutions for that. Now, what these solutions might look like, you know, we’re still working on. It might be a fully like a new type of harness, creative harness. It might be harness extensions. It might be like commercial products that you can integrate. But ultimately, that’s the problem space.

Allen: Yeah, one of the parts of that, a whole bunch of things plug into that. But one of the parts of that that we’ve been talking about on our team is around if you have junior people, which so far we have not had any of for many reasons that many teams have not. But we have some really talented and interesting people who are junior that come in and they’re excited and they’re obviously smart and they care a lot and they could be really good. But the idea of trying to supervise them while they’re off in some silo coding with Fable and Fable’s glazing them, or especially Sol 5.6 is telling them that they’re a genius. And how many $10,000 a week of coding tokens that they’re spending doing that, right? It’s a difficult challenge. So there’s a lot of things, obviously, having harnesses and tools that help them level up is valuable. One of the things that we’ve been prototyping around is how do we make some of the feeling of the ability, like the collaboration piece, which is mostly fallen away. Where it’s like previously we were all working literally beside each other and we were thinking quite frequently in terms of how many times did you talk to another human per character of code got typed versus now how many times you talk to a human per token gets hundreds or thousands of times higher ratio. And so tools that allow more visibility and collaboration, especially if you have a long-running task, it goes for eight weeks to rewrite this thing in Rust or whatever. Right now, often that’s like literally on someone’s laptop spinning up a whole bunch of cloud agents. But the operation center of that is one place. So I think that’s, in my view, that’s part of this. Like how do we have the next generation of people doing great work is like finding ways that we actually are working together and not just. All right, well, deliver me a final merged PR or get fired.

Paul: Yeah, I completely agree. I mean, I think a lot of what we’re all working on right now, I mean, like the whole agent experience, I guess, is very single player right now. And lots of people have been requesting multiplayer for Impeccable as well, to be honest. For instance, you know, I want to do a critique. Critique is another interesting feature of Impeccable. It does a really, I think, decent job of critiquing, doing a design critique on your feature or code or whatever it is. but then maybe I want to show that critique to you, right? And I want your assessment. Does it make sense? Does it not make sense?

Allen: Yes.

Paul: Maybe I want you to fix these things of the critique for me. So working together as a team is definitely not easy yet with Impeccable. I think that’s another interesting area for Impeccable Pro to solve for because I’ve talked to teams who now made Impeccable or required tools to install for all their new hires but it’s still very solo player, I would say.

Allen: Yes. Yeah, yeah. Two last things that are kind of related to that as we wrap up on time. So one is on this question of Figma. So you mentioned like, okay, I want to move forward in my design, but I don’t want to be in Figma. And the obvious reason that a lot of teams are saying that is because Figma no longer matches what their product is because the product is moving faster. and so they want to iterate on the product as it is, not as we originally maybe mocked it up. Do you have an instinct or a take on what Figma’s relationship to all of this process is going to be in the coming years? Are they kind of just going to be hamstrung forever? Are they going to pull out of the fire and sort of reinvent in some ways like the code is the source of truth and Figma is working directly on the code? I mean, from what you know, I’m not sure if you were a big Figma user, but I got hard into it not too long ago and now suddenly I’m back out of it again.

Paul: First of all, I love Figma and I have a huge respect for Figma. I think they started with some really interesting engineering breakthroughs with WebRTC and a whole bunch of other tech that they’ve been using to make this really work. Collaborative design in the browser, which at the time was really cool for a front-end developer to see how far they could.

Allen: It seemed almost impossible like Google Maps did when they first came up.

Paul: Absolutely. So huge respect for Dylan and the team. I think they have their work cut out, though. I gave a talk about this a couple weeks ago, and the talk was titled, The Hand-Off is Dead. Sure, it’s controversial on purpose, but I think it’s real. I think in most companies, most people that I’ve talked to lately, designers, engineers, teams of product teams, they are scrambling. They’re scrambling to figure this out because engineers are moving at a much different pace than before and have different tooling available to them as well. Assisted code reviews, to your point, is often a solo player experience. But the release cycles are now much quicker. There’s much more code that gets written. Oftentimes there’s no time to wait for a waterfall process or agile process like a hand down from a designer. And designers are really scrambling. Designers are really in a tough spot because if I don’t even have a day to explore a design direction then I’m just going to be overruled. I’m going to be skipped. And this is happening more and more often and I’m seeing this across companies. I’ve talked to so many people about this. This is a trend. This for sure is a trend. And I’ve talked to Fortune 500 companies and smaller startups, and people are moving out of the design canvas. Not just Figma, any type of design canvas. And so there’s definitely a trend that’s happening. Now Figma is seeing this, of course, and is also building MCP and connectors and whatever it is. I think Figma Make has announced that you can now design in production on your code base or something like that. I haven’t tried it, but I think they’re moving.

Allen: And Dylan has talked about the concept of full round tripping.

Paul: Yeah.

Allen: Right? Like, it’s the obvious thing like, oh, make it round trip. You design it and then it’s in production and your production stuff comes back into Figma. It’s just very easy to say. Extremely difficult to retrofit to a 10-year-old, 15-year-old product.

Paul: Yeah. Very, very easy to say. Very hard to do. Now, what Figma has going for them is that they have an excellent canvas. They have really great controls. They have precise controls. They have spent so much time in their tooling, in their craft of their precise tooling, whether that’s snapping or how you define layouts and whatever it is. There’s so much craft that went to the Figma. If they can solve this, if they can figure out how to replace the substrate, how to basically make it code, make it production code across frameworks, I think they could have a giant comeback. We’ll see how that goes. But I think they have their work cut out. And then, of course, organizationally, they’re a large company now. They have traditionally organized team structures, etc. And so can they reinvent as quickly as an incumbent now as a small startup? I don’t know, right? It’s hard to say. Things are moving towards your code base. Production, design in production, I think is a real trend. And it’s very hard, I will say. The live mode in Impeccable, for example, it works across frameworks. It’s kind of crazy, actually. I knew it was crazy when I started on our endeavor. I knew that would probably break in so many cases. I did it anyway, and it broke so many times at the beginning. But in the first version, it was really, really hacky. And oftentimes your site would crash or whatever. HMR might produce bad things. And then I just ended up fixing hundreds and hundreds of incoming bugs until I found that it deserved to move from alpha to beta. But it was a grind because, again, it doesn’t just support React. It supports Vue, Astro, Static Pages. You name it. And all of those have completely different component models. VDOM versus no VDOM. like islands, you know? It just gets really messy and complicated.

Allen: And that’s for the scope that you have in your, don’t call it a skill, skill that’s new as opposed to the scope that Figma has. Which one thing they have going for them is that my understanding is that they always try to constrain their stuff into stuff that could be expressed with HTML and the DOM and CSS. But it’s basically all of it, plus WebGL now.

Paul: Well, you know, I’ve actually, so I have an interesting story here. I actually did this way before Figma did, this exact thing. And that was a feature in Chrome DevTools that we never shipped.

Allen: Ah, okay.

Paul: So it was called layout mode. And it was literally that, right? So you could open DevTools and then you could, instead of having an inspect button, you’ll have like a layout button and you can click on anything on the page and you can actually drag things around, modify things, change the margins, change the paddings. And this was 15 years ago, right? So this was a long time ago and it was beautiful. I mean, I was very proud of the prototype that I’ve created initially. A very rich prototype that worked as a JavaScript snippet. And then the team got very excited about it and built our first version in Chrome DevTools. And we were very convinced this is the future and we’re going to do this. And this is going to be great because we also had source mapping with real file changes in your system.

Allen: Oh, because that’s what made me to your question. It’s like, great, yeah, I’ve made a great design in the DevTools. Even if that happens, everybody just will do that with little micro changes. but then you’re like, now I need to actually export this back to my code.

Paul: Yeah, no. In fact, if you don’t know this, this is going to blow your mind. Did you know that you can take a folder and drag it into the dev tools and then it’s live source mapped file by file?

Allen: Oh, no, I did not know that. So if you have static HTML on your computer.

Paul: Yes. So if you drag something into the dev tools with the thing that you have open, so let’s say you have index.html open, you drag the folder in the dev tools, it creates a live mapping. And now when you open the CSS panel, for instance, in DevTools, change anything, it saves back to source.

Allen: What? How did I not know that?

Paul: Yeah. So this still works. It’s crazy. And you can do this in the JS debugger as well, right? So you debug something and you’re like, I don’t like this. And then it saves directly, right? It’s an actual editor that saves back to disk.

Allen: I never knew.

Paul: Yeah. But combined with that, the layout mode was a really beautiful idea, I think. Here’s the big reveal, though. it didn’t have a happy ending. And the reason why it didn’t have a happy ending is because at some point the DevTools engineers became so frustrated with quirks of how the browser engine works and CSS and HTML works, and all these edge cases that we decided it’s not worth the squeeze. Because once you get to negative margins, you really don’t have fun anymore doing that. And so I think those are the edges that the Figma team will hit as well.

Allen: And that would be all even worse now with all new types of layouts and just masonry grids and all the other stuff that exists now and the web itself as a platform keeps getting more complicated.

Paul: Yes, so direct manipulation on a webpage is still an unsolved problem, I would say. Very, very hard problem, even with all the AI tools that we have available to ourselves.

Allen: But it’s coming. Someone’s going to do it. Maybe it’ll be you.

Paul: The problem is it’s a UI problem as well. It’s a design problem because my example just now, negative margins. Let’s say you select an element and you have these dragging things to drag margins and paddings or whatever. Great.

Allen: Sure, it makes sense. I make the margin 20, I make it zero. It shows me what that looks like.

Paul: What does it look like when I make it minus three? How do you solve for negative margin? Exactly, right? So there are all these really strange problems that you have to deal with.

Allen: We’re living in exciting times, sometimes in the bad way but often in the good way and it’s really fun exploring this problem space with people who are thinking about it a lot. Before we go, I know you’re hiring. is there a particular role or type of person you’d love to reach out to?

Paul: Yeah, thank you. My company is called Renaissance Geek for a reason. I’m trying to hire people who are T-shaped generalists who are extremely good at solving design engineering problems, pretty much. So I’m hiring especially design engineers. That’s the most important role right now. So if anyone in here listening is a design engineer or considers themselves an engineer very good at design or designer very good at engineering or anything in between, I definitely want to hear from people. Ultimately, it’s going to be a really tight, small team for a long time. I never want to build a big team. I’m not here to build a big company. I’m here to solve big problems. I want a handful of people who join me on that mission.

Allen: Awesome. Well, we’ll get links to that and the other things we mentioned in the show notes. Thank you so much for being on the show.

Paul: Thank you for having me, Allen.

Allen: It Shipped That Way is brought to you by Steamclock Software. If you’re a growing business and your customers need a world-class mobile app, get in touch with Steam Clock. And that’s it for today. You can give us feedback, follow us on social media, rate the show by going to itshipped.fm/contact. And until next time, keep shipping.