Design Engineering with Maggie Appleton

What makes for a great designer or a great design engineer and what can software engineers learn from them? Maggie Appleton is one of the most awful design engineers I know. She's worked as an illustrator, as a designer at an AI startup, and is currently prototyping a GitHub next. Today we talk about what is a design engineer and why there's often attention between engineering and design. The tools she's used before and now and why Penn and pencil is not going away even with agents. Do you still need a designer when AI can join me 20 high-fidelity

prototypes and is AI design obvious to Spot and many more? If you're an engineer and wanting to know where design is important and how to get better at designing yourself, this episode is for you. This episode was presented by a tool buffer, vector and full-text search built on object storage. It's fast, cheap and extremely scalable. Today's episode will be about design and design engineering and so I wanted to share something visually interesting about our season sponsor, Antisysys.

We already know that Antisys verifies your system correctness by running your whole system in host assimilation and finding bugs. Here's a UI for casualty analysis. You could open a report for a bug and see the probability of a bug occurring throughout the timeline of the simulation. In this case, we can see that virtual time 25 something happened that makes this bug close to 100% to occur. So we can jump to this point of virtual time simulation to read the logs. This kind of

bug probably visualization is one that I've never seen before. There's also this neat log explorer. You can filter on error messages and then visualize how common or uncommon the error is over time. For example, here's looking for failing linearization failures, the purple line. And you can understand how rare or common a specific failure was. Again, I've yet to see

this kind of error visualization and I really like the innovation on the UI side. And finally, the simplified multiverse debugger. You can go back in time and replay a debug timeline and you can inject bash commands at any time without affecting the playback of the bug. How cool is that? For example, we're listing 1,000 of current directory but as you can imagine, you can go debug the whole environment so much easier. I love how the team and the citizens are pushing what's possible with

both debugging and verifying software. Head to Antisthesis.com to learn more. Maggie, welcome to the podcast. Thanks. I'm thrilled to be here.

I've had so many guests on the podcast. No one had quite the introductory story and detect like you. How did you get into tech? And you came from a very different background, right? Yeah. I mean, I came in because it was where the money was, I guess. I mean, not really. But in the

sense that like, in university, I studied cultural anthropology, which is like one of my one true love, like I adore cultural anthropology. I totally fell in love with it in university. What is anthropology? Yeah. It's okay. It's a study of human beings, which sounds impossibly broad

and like, how could that be a discipline? But it does it in a particular way where you go and you live with people intensely in this thing called participant observation. Usually it was done kind of when the field was born of different cultures, of course. It was like anthropologists from the West primarily go into places like Papua New Guinea or Australia and living among traditional peoples and then realizing how different their cultures were, not just like, oh, they eat different food, you know, they have different houses, but they have completely different understandings of like what color is they don't have completely different understandings of time. It was kind of alongside the birth of psychology, like understanding how flexible is the human mind about constructing understandings of the world's. And the party is really one of these eye-opening

subjects when you get into it because you can kind of get into like medical anthropology or the anthropology of sex and gender and you just find out how extremely adaptable and fluid human beings are. And I loved it because I grew up as an ex-pack kid overseas. So I think I was exposed early to lots of different cultures. And so it felt very natural to me to realize like, oh, the way things, you know, people do things at home, you know, quote, quote, home would be London for me by left at age six is completely different to the way they do it elsewhere. And there's no fixed way for humans to kind of construct a society or live life and the bounds of what we think is possible as much wider than we originally assume, which is what I loved about it. So I studied it, but of

course, come senior year, kind of go, right, what jobs are there available in cultural anthropology? I guess I love living with natives isn't to borrow that money. It's not very lucrative. So the options were like, go get PhD and become a professor. Well, the military hires lots of anthropologists to come up with torture techniques for people in different countries. So when presented with these options by our professors, we were like, okay,

okay, we'll think about that. And I always love design growing up. So I had been doing, like, I was a kid of the 90s. I grew up on Neo-Pertz with HTML and CSS in my space, and I learned HTML and CSS probably around 12 or 13 and knew how to do it. But in the way, we're like, there wasn't that much complexity to it in whatever this was in 1999.

Did you have my space? I did. Oh, yeah. Customize it with all the crazy animations and like the little sparkle trailer in the old cursor. And like, I think mine was quite golf at the time.

Like, but I learned a lot. But of course, at the time, the web was so new. It wasn't like people thought this was a career or didn't think of it that way. But I came out of university with this degree that wasn't necessarily employable. And I just started doing freelance web design work because that was how I knew how to make money. Like throughout school, I was doing IT tech

work for the university and just naturally went into this because it was like, well, I need to pay rent somehow. And I gravitated towards illustration originally because I love drawing. So I was originally an illustrator for the first couple of years. And the way that I went more into the tech side, because you've kind of been an illustrator that's like editorial or you go to branding or like all kinds of types. But I started working for a startup. I guess I

wouldn't call it a start. It was more like a design Dev shop in Prague that was making UI UX apps for like SF startups at the time. They were doing work for like Tinder and Uber like in the early days, like in their beginnings. So it was there, I got exposed to UI UX design. And I was making the illustrations for these apps doing logos and branding. But I like that was my first exposure to like,

oh, there are people who design buttons and sidebars. And that's kind of interesting. I didn't end up going into that for a while. But that was my first introduction to like, what is product design in tech as a field? And eventually I joined this company called Egghead, which does develop education. So they

taught JavaScript. Sure. You've seen them around. And I was there illustrator for four years. And then I became an art director and like, art director, other people's illustrations for them. And that

was really where I learned JavaScript react. Like that was, I think my real front end engineering education was like doing illustrations for them. But in doing the illustrations, I had to understand the material I was illustrating, which turned out to be like react components and use effect and like JavaScript functions. And in a weird way, I just ended up moving more into front end engineering and visual design because it just felt like a natural move. You worked at Elisid as well, right?

Yeah. Was that before Egghead? After. That was after. Yeah. So so you were at Egghead as their

learn design there. And then Elisid was an AI startup, right? Yeah, early, pretty early. Well, okay. I mean, it was like the founders there were really kind of incredible people and one of them had been studying language models for 10 years. He had like seen the writing on the wall way before

anyone else. But like kind of MIT like PhD kind of like, you know, machine learning stuff and kind of had this realization of like language models are going to revolutionize science. He was really big on like, how could this be the scientific process? So Elisid originally was, and it still is actually, I mean, they've expanded, but at its core, it's using language models to speed up the scientific literature of your process, which is very manual, slow thing of all these academics reading thousands of papers and extracting data about them into spreadsheets, perfect for models like a perfect use case. So I joined them, I think it was late 2021, early 2022. And you were the only designers

in all product, actually, were the founding designer. Yeah. Yeah. Six of us in the beginning, when I joined maybe seven, I might have been the seventh, I forget the vice-mole team. And it stayed small, most of the time I was there. And yeah, I was the only designer the whole time. And then we

had a PM at some point who left and then we didn't get another one. So it's no PM quite a while. And it was a really wonderful experience because it was a classic early startup. Like it was like we were family, we would like stay together for weeks at a time during retreats like the founders had really strong conviction and they're really small people. I trusted them so much. So it was sort of like

get on board with the vision kind of deal. And it was there. I really learned product design end to end, I'd say in the terms of we had lots of users because we had a free prototype that was like very, very popular. So you had all this data you could collect about what people were searching for and clicking on and what worked and what didn't and ABI tests and we just went really fast. We shipped a feature every week for a year. So it was like design, build, like ship it,

measure, design, build, ship it, measure on repeat over and over for like the solid, I think I was there a little over two years and I'd learned a ton in that time just about the core mechanics of product design and the sense of like really going from one of the user needs, what's their domain through to doing all the front end engineering and like tying it all together. So it's a really wonderful experience. I learned a lot. It was an intense by the end of it. I was like, step back from the start of the format. So you got into design, I guess kind of work like self-taught,

like figuring out there's a need for this. You worked at EKED where you learned to design or explain developer concept, educational concept for developers. You worked at AI Star Up as a designer. What does a designer do? It's a different role than I get a sense of course, like there's going to be the depends but at startups that you work with that you know how would you describe and of course many of us developers have worked with designers, so have notch at all. I mean, I kind of describe

it. It's not that different to engineering. It's problem solving. But the materials are different. It's the way I would describe it. It's like you go through the same process of like you have,

defining what your problem is. Like, are you sure this is the correct problem? Have you defined it well and scope it well? You know, researching possible solutions, doing wide exploration, what were all the ways we could solve this, what are the trade-offs of them, you know, prototyping solutions, validating those at the right solutions. Do they work for users? Do they make sense? I don't think

it's that different to engineering in the sense that I do some of both in my job, but it's just the materials different instead of working with code, although nowadays with developers you're working in high level kind of architecture data flow. You're not necessarily writing the syntax, but at the time, what syntax are you going to use to write this problem? And with design, the materials are like space, size, weight, color, you know, things you'd see in an interface in terms of the visuals. Motion, you know, prominence is this big enough. Are these the right words for the user to understand what this button is going to do? Like everything from copywriting to visual

graphic design. But with product design, you're also dealing with what we would call nouns and verbs of a product. So it's easy when your product is like a sneaker store. It's like the nouns are like a sneaker, cart, money. If you're designing AWS, the nouns get extremely difficult. And I primarily

worked in, well, I'd call it power user tools like scientists, developers, where the nouns are extremely hard because they get very abstract. It's like, what's the right container for a set of data? What's the right container? Or noun to point you to like, Oh, this is your whatever set of data, or like this set of data connects to that set of data. Or like here's a function that transforms data into another set, you need a noun and verbs to give to users so they can understand how to manipulate whatever you're trying to get them to do. It's a really difficult in depth or sometimes because

there's so much malleability in a way, there isn't what's done. What's malleability? Like ability, like it could take many different forms and shapes versus if you're designing things for the real world, like I have friends who work for like government design, there's restrictions there, where it's like you're trying to get someone to fill out a form. It's an act, it can be a hard design challenge, but it's not complex in the same way versus like at the moment, right? I'm of course trying to design like a genteq tools and it's like what are the nouns of agents? Like,

we don't know. There's like chat sessions, we have these things called plans, there's something called an MCP, there's skills, like could we make new primitives that like connect a bunch of sessions all the way to a PR that becomes a new noun that contains it? Like, there's all kinds of boundaries you could draw that would make the user think about your experience differently and then you have to define what verbs can they take on which nouns, right? Can you short edit rename delete? This is like classic crud stuff you have to figure out, but I don't know. Can you like fork an agent session? What

are the implications of that? Like, I think the hard bit of product design is designing a coherent system that takes all the complexity that could exist, especially in something like DevTools and reducing it to the simplest possible form you can, which is very easy to say, extremely hard to do every time. To like a really canonical set of nouns that the user can go, okay, I can point at that, I understand what that's going to do. I can like a button, I don't get surprised at the outcome. This takes time to do this kind of like hard reduce it to its best, most elegant form.

This is so interesting because what you've described of like, you know, we have a new product that has not not existed before like a dev tool in a digital space which lives in our head or inside of the computer with things that we just invented, made up in MCP or an agentic scale, and then thinking of how we find the right words so people can use it and it makes sense. I just see that you're kind of drawing the map in your head, which is not all that different to when you're building a new system as an software engineer. And I remember talking with Ken Beck who talked about how with the Wart Cunningham, they came up with some of the basics of that might have been domain driven design or it might have been some related concepts, but they had a Tzaurus in front of them trying to they search for the right words on how to, oh, it was a design patterns. Design patterns later came out of it, but they were trying to put a name on these constructs and these things and how, which feels like a very similar thing to what you're describing.

Yeah, yeah, that's design. This is where I kind of get into sure this types of design, like you could be like this interior design as brand design, this product design, but product design, when we talk about it in tech is actually software design and software design is engineering. It's actually the same skill. Like you might be working with slightly different materials in the sense of one of you cares more about the colors and the size and the shadows and like the shape of things and the motion design, but that person also has to understand like what's the shape of the database, like what are these APIs? Like what is the data in the right place? Are we passing data through

this component in the right way? Like they have to also understand this. Interesting because designers I worked with years back at places like Uber and at Skype, they had their design tools, which was sketch later, Figma. They typically work with the product folks. They did explorations or UX prototypes. They often sat into user testing, but in the end,

they had a design, they had visuals, they had animations. That was their thing. And they handed this over to us engineers together with the PRD or the product. Here's the product, here's how it's going to look. And then we built it and we will build the UI that's in mobile and we will then go maybe sit with them or show them. And they will say, this motion doesn't feel good.

But my view of the designer is like, well, it was very visual. And for example, those designers maybe they didn't need to, but they didn't need to get involved in like how the base works and how they were very aware of the flows of the user journey. So like, is that type of design, how would you characterize as being different? Or is it just that their domain is a little bit different? It's more of the business level, the more these are like mobile and web and some of those.

Yeah. I think it gets into kind of like how we label different parts of design. The kind of design I'm talking about is obviously biased by my experience, which is much more design engineering stuff because it is like, when I hear design engineering, that's kind of a catchphrase now. What does that mean? But I think of it as a designer who really engages in the engineering and understands how the product works and it's required. It's not required in all domains again. If you're doing

government, they don't think you need to understand the database. But if you're designing for developers or you're designing in a brand new field like AI, where so much of how the product works is determined by what is possible on the backend and the shape of the data, then you do need to engage with it a lot. But if you're working on an app where actually a designer is probably better served by advocating for the user and that's a kind of more traditional philosophy of product design is like, you represent the user and you represent trying to get the best experience possible for the user. And that means user interviews, caring about flows, like, does this button feel big enough? Does it have the right words? And then they can spend much

money there if they don't have to care about the technical backend. Like maybe it's actually irrelevant when really what you need to care about is like, does this flow make sense to people? So that's not necessarily a different kind of designer, but it's kind of think of the whole the stack right, but expand it all the way out, not just back in the front end, but the interface and users and then the product in the context of a business and the product in the context of an economy. Like there are people who mean way more on this side, and I'm a bit more the straddling of the product design and the engineering, but you can have valid designers all along this and some people again, you know, just visuals or just animation, like there's lots of niches. I just like a bit more of the half engineering, half design slice of it. To help understand a bit more of what you do.

Can you talk about the tools that you use? Like, you know, as engineers, we're kind of used to be the ID and the code editor and some of the hardcore people like them and some of those things. And these days, of course, it's changing a bit more. Those are the tools. What are your tools?

It changes all the time. I mean, to some degree, like something stay constant, like you're using similar tasks, but of course, at the moment, I'm trying to try everything because part of my job is like trying to figure out what GitHub should do next. That's what our team does. That's just a name. Right. Good. Next day. It's like, it was well named. So a lot of the time, like,

we are just, of course, I'm trying out codex and Claude and like dog-fooding stuff internally at GitHub. I've tried Conductor. I mean, name any agent, like open code, Pi, I try them all. I do love codex at the moment. Like, I do think like opening eyes onto some really good stuff, at least in there, their design of their like, desktop app is beautiful. They really thought it through.

So I think they're doing some really good stuff. I still use paper and pen for like initial brainstorming. Yeah, you have your notebooks here. Yeah, I brought some along because no books aren't dead. I don't think they're going to be dead forever. And I still use Figma because I know how to use it. And I can

do some brainstorming in it before I pass it off to an agent. But to be honest, there's a point where once you figure out what you need to build, which is actually all the work, once you hand it off to an agent, it's not that implementation is solved. But we've reached a point where implementation is like good enough that if I spec it out really well and I list out how the agent should verify for me that it actually did the work, I can hand it to an agent and just like, right, let me know when you've got a PR up. You know, I don't really look at code that much anymore. I do look at PR code when I'm reviewing it, but skim skim skim, you know, okay, that looks sensible, merge. So most of the work I

find is everything leading up to telling the agent to implement something. And then the PR review is kind of a separate piece of work. But like the bulk of my tools deal in this first section now versus we used to have the IDE, you know, once it was like, okay, you've decided this is the right thing to design now, you actually start the work of like implementing it. It's kind of beautiful that's no no longer part of it as much. Open BS code sometimes, but not really.

Yeah, but before hand you would post I write like you do the post I was. Yeah, yeah, as part of the like what should we build I include in this lots of prototyping. And I kind of have the privilege of being on a team where we don't have to build like production quality software, we are mostly trying to prototype and validate ideas. So we have a lower quality bar than someone shipping to propagate hub. So it's very high quality.

Yeah, which makes sense. I mean, that's kind of you get the kind of the directional things right. And then once it's great, you might build it or you might decide to build it. Yeah, but I definitely I mean, we can hopefully show these later. I do I do a lot of stuff sketching.

I mean, even just in a face design, a lot of what you're doing is just drawing boxes and then being like, there's this slide over from the front from the bottom. Like if I click this button. So this is like you kind of drawing up a you have an interface you think could look like so. Yeah, I see a mix of yeah, mix of you eyes and we'll put these on on the screen, but you eyes description of what they do what like can you just talk to one of these or like one that that's interesting, memorable. Yeah, yeah, so this is a new I should explain the context.

I'm prototyping at the moment something where my theory is like one of the bottlenecks with agents is planning is a really bad experience at the moment. Like at the moment, you have a long chat with an agent you sometimes even in a CLI, which is a pretty primitive interface. And then the agent grills you by asking you a set of like choice A, B or C questions. And it does this like 100 times over using that percuss scale. He was just on the podcast. Yeah. Yeah. And by question 20, you're like quite

tired and your brain starts down. No, my friend, I went through and I got 36 questions and I was kind of they're good, but I was trying to get annoyed around like yeah, like 20 or 25. I'm like, and also I know you when it was stopped. Right. It's endless. And like the human brain,

you get tired, you can't make the same decisions in this short of time. And also you don't have enough information about most of those decisions because it's given you a question and three options it's told you number eight is recommended that you just are being like, yeah, a enter a I agree with you. So this is not an ideal experience. It's gets into like agents love to output reams and reams of text. And that's an ideal output for agents, but it is not an ideal input for humans.

So we have a mismatch with like what do humans need to be able to digest large amounts of information and truly understand it and be able to make informed decisions. That is not the interface for this. So I'm trying to explore how would we make an interface that got us to do better planning and better decision making, but in a way that was easier for us to comprehend. So this is what I'm prototyping at the moment. And part of this is like, okay, it's going to be multiplayer because of course everything should be with your team planning together. So you got several people can

do it together. Exactly. But also just like, how do you make it so that you have more space for each decision? So I'm trying to prototype like, okay, so first of all, this has to definitely happen in a GUI, not in a CLI. So these are just like a rough idea of how you have a more space or exactly. So I'm thinking of it as like, each decision maybe has its own little mini document

or card. And depending on the decision, some of them, maybe you can just have three multiple choices. That's fine. It's maybe a simple decision, right? Maybe I'll see. But sometimes it'll ask

me things like, do you think the borders should be like gray 10%, 12% or 15%? And I'm like, well, show me this is a visual question. Or sometimes it's like, how do you want the architecture to be structured? And I'm like, well, show me an architecture diagram, show me a data flow diagram, show me a state machine, like, I'm trying to prototype like decisions that have come with diagrams and prototypes and HTML embedded in them so that depending on what question is being asked, it shows me the correct interface to make that decision. So I'm prototyping here is like, okay, you got a plan, that's a big document, you maybe got these little decision docs embedded within them that can you can expand to see more of? And then looking at like, I think each decision should

have a human assigned to it who made that decision so that you have an audit trail later, not necessarily to hunt people down, but to be like, okay, why do we make this decision about the backend? Well, let's go see, okay, Luke made that decision like six months ago, let's go open up his decision card and be like, what information do you have available in order to make this decision? Hopefully this becomes useful later. But here I'm just sketching what are the possible shapes this take is like a stack of cards that expands on the screen is this like, well, one big linear thing will be like swiping through stuff like it's Tinder, like what what interfaces are going to be useful for this? This is a lot of sketching is just trying to figure out like possible possible shapes of things, all kinds of these characters because I was trying to make an ESP character. Well, this is like, you know, this is like my kids scripting all of my work.

This is like, you know, ESP32s, you know, Steve Ruiz has like sold everyone and buying an ESP32. It's like this little device with a screen and a very small microchip that has Wi-Fi Bluetooth. And so I was designing a little character who like tells me the weather and like, I'm trying to hook it up to my agent. So it could be like, you have this much capacity left before you set limit happens. So like, this is just all kind of thing. It's a mix of like, like, some serious stuff and

some fun stuff. Yeah. Yeah. And I can show like, um, the whole thing with notebooks and thinking on paper, I think all designers do this, but coming from illustration, the reason I do this is because I started in a world where you have to draw everything to like figure out what you're going to do. So when I was an illustrator, I had tons of these notebooks where you're figuring out like, what's the composition? What's the physical shape of things? Like, how are you working out,

like the shape of the grass in a scene? And so I think I started problem solving on paper, like very early on in my career, like figuring out compositions and layouts. Was this was a was this in college? When was this? I think I was going for egg head when I was doing this.

And then you drew all of these? Yeah. Yeah. I was trained with, um, I was in LA for a while, which is a terrible place to live. But with, I trained with like people who are concept artists on films and they have a really beautiful way of working that's, that's very technical. It's very

like constructing things from 3D shapes and like drawing and space that. Because these are really 3D. Yeah. Yeah. Um, and then, and then kind of just teach you how to do like landscapes and layouts.

I loved their way of teaching. And it's very, again, it's very technical. It's very like engineering. You have to understand like with robotics, like different types of joints you could like put together a robot in so that you could actually draw a robot that was believable. There was a lot of like understanding reality in order to believably draw a reality. So I think doing this set me up to when I

moved into like UI design to do a lot of this kind of sketching because, you know, just comes naturally. I mean, these are a little bit easier to sketch as well in terms of the user. Yeah. But then I think it's like that helps you think on paper that all of this is just sort of like you have an idea in your head. And sure, I could like go into Claude Code and be like, Hey, Claude, here's an idea. I have a stack of cards and it's an accordion. But it's much faster to just get a

piece of pen like, like, pen or pencil on the desk next to me and draw that with my hands. It's like way fewer effort. So I feel like people online keep being like, Oh, like, everyone's just gonna prompt everything to create. But, but you need something that is like quick feedback and very loose in the early stages to figure out the shape of something before you can put into words what you want an agent to do. And also it's visual. It's not text. And there's another bit more satisfying

doing it for you. Yeah. And then you can look at it. It doesn't go away on your screen and sit on your desk and you can like the next day be like, Oh, yes, I remember I was trying to like figure out what shape this feature should be or like you can draw like data diagrams, whatever you want. It doesn't have to be visual, but it's just a way of externalizing thoughts before they're then they're not linguistic. I think this is the key thing is like, again, agents only accept text as

inputs. Okay, they can read images. Like I do take photos and put them in. But they're not as good at images. They're very bad at special spatial reasoning. They're very bad at visual design. I mean,

trying to get them to do design, they just make mistakes where like they just don't put spacing around things and things of the wrong size and they make text over that they can't see, right? Like trying to explain a visual idea and text to an agent is really challenging and doesn't work very well. So I find I still end up doing a lot of my design without agents upfront because all it is is thinking through the visual, the visual pieces of it. And then when I'm like, okay, I know this is the shape of the thing I want, then I can tell an agent to do it. But I find it hard to like involve it earlier in a way that I think some people are claiming they do, but I'm skeptical.

But it's interesting because even in software design, the architecture design, some of the like most productive sessions I've observed have been in person around the whiteboard where people, again, we're talking about like components, databases, networking connections, retrylogics, whatever, you know, like these things you could describe or you could put it on a computer. But when you put it on a board, when someone puts it on there, and then someone else takes, and you know, they kind of, it's their force to take their ideas into 2D space, because we don't do 3D. I know you can draw like cool 3, but we can also just box scenarios. Someone does that and the other people understand and they go in and they add their own thing or they circle or they add new components. And even in digital space, I think my role is a good example. They became so popular

because they figured out a way to do collaborative whiteboarding, you know, like you don't have to be in the same room, but they give you somewhat similar tools. So I wonder if this whole thing of getting your ideas either to a physical medium, which I think for us engineers is the whiteboard for you as the notebook. Maybe it just helps, maybe rethink or solidify or also it does have a forcing function about the verbs, the shapes that you. Yeah, yeah, yeah. And this gets into kind of like the interfaces we have to agents right now are so primitive. I think we know this right, we're

all like a couple of years into this, I think just wilds, maybe five years, I forget when GPT4 came out, was it three or four years ago? And the three point five came out in the three years, four or four years, November 20. Yeah, yeah, yeah. So now I was at Alyssa and then because we were debating doing a chat interface and then they did it and we're like, oh, they like stroller, it's not that was, it's necessary competing with them. But that is no time at all.

And it's kind of wild. We've made it as far as we have, but it's also like, I always say software design is extremely young field, like what we 60 years into it at most. So even that, we haven't figured out a lot of things about how to design the best interfaces for people and machines to like communicate with each other and agents barely at all. I feel like there's this like, there's this world that agents live in, there's like weights and models and scales and then you have your human side that is like physicality and texture and light materials and all these things, agents don't understand and trying to find like artifacts that allow us to meet in the middle and create stuff together is like a really hard challenge because you've got two totally different types of beings, not that agents are conscious beings. I'm not in that camp, but there are type of intelligence that like wants to think and act in a certain way that it's not the way humans want to think and act and it's hard to translate between the two. I just find myself frustrated that

they can't sort of be looking over my shoulder, looking at my notebook and be understanding what I'm drawing and like helping me move my ideas along. This is like the eventual dream is they understand space and light and shape and lines and you know, but I think we're quite always away from that. So one thing we've talked about your notebooks and the jolt's was one thing that you've posted about recently is woodworking. You said that I'm at the stage of software design during, well, no, I'm at that stage of software design where you start taking woodworking for a second. Can you tell me a little bit about that experience?

Well, the joke is like, at some point every engineer you have a choice of things you can get into because you feel like you're like disembodied from the world working in software. So you have to pick ceramics, bread baking, you can maybe pick like motorcycle or repair or something, but woodworking is a pretty popular one because it's like engineering, you need a lot of measurement and being precise. So yeah, I'm learning woodworking because I bought a house here and all the houses in London are very old. So you buy a house that needs a lot of work that is always what happens. Maybe the same in Amsterdam. I think all kinds of stuff.

So then you suddenly become like, oh, I need to learn like DIY skills, which I was like, you know, Claude Chatebout, very helpful coaches in this regard along with YouTube and Instagram, like, you know, I'm not like, oh, there's so many things I need solutions to that I need to figure out how to make I need to like make shelves here. I need to like fix this badness. So I was like, well, I have no DIY skills, no woodworking, but just signed up for course being like, well, I'll then I'm pretty sure I can like I'm not too old. I can acquire new skills and I'm sure I find lots of parallels to software but in a more satisfying way where you actually like touch the thing you make. One thing that you've talked about, you've been talking about is the concept of design engineers. For a few years ago, you posted, I'll quote you, I'm having a strong

shyness become a full-blown design engineer day. I'm not even sure what it means, but I just want to touch lots of code and solve tangible problems on screens and make beautiful animated stuff. Yeah. And then you went over and you tried to collect names of people who knew who you felt were kind of doing this design engineer. Now that was a few years ago. Yeah. What have you figured out about

design engineers, if they exist, what they do, where, what places they work in? Yeah, I think they do exist. I think Twitter might have a different definition or like, I think there's a lot of people where not that I should call X, sorry, X. Twitter, X, all the same. Yeah. On X, I feel like a lot of people

who get cool design engineers or who present themselves as design engineers actually are like very good micro interaction designers, like little like, here's a cool hover effect on a button and like, here's a cool loading transition stick. Those things are definitely cool. I don't consider that design engineering because you could achieve most of those things by just telling an agent to do those without looking at a single piece of code. To me, that's just like very advanced, sophisticated like motion design and visual design. And that's cool. But I don't consider that design engineering

because I don't think that's like a full job for you to do that as a career. But design engineering, the people who I think of as good design engineers do the kind of thing I was talking about before, you step much more into the engineering side of work. So you're still a designer, you're still caring about like, product, nouns and verbs, and like the visual design. But then you really work with engineers closely and or are like directly involved in implementing and writing code yourself. And you fully understand, or you don't have to be a full full stat, but like you have a deep understanding of the technical, the technical architecture of the product you're building. You

really are like, okay, given the shape of the backend data, what is possible in the interface, like that sort of design work, you know, given what models are capable of and what kind of skills we're building into this product, like how do I explain to users what the capabilities of this product are like truly digging into the technicals and not living in the world of like just user interviews in the market and like what color is the sidebar, but caring much more and working much more closely with the engineers and almost always I feel like implementing a lot of it yourself. Like I've always done my own front end work just because it's easier. And then the engineers I work with are usually thrilled because they hate CSS. And then they get to go work on like the more interesting difficult stuff I'd say it's like the sinking or like the like back of the front end work, you know, like the more logic stuff they really get to engage in that and they don't have to worry about like, is this the right border radius on something like I don't think they very rarely care and I do care. So it's always worked out well. You kind of do that.

So I just defined as someone who's like deeply into the engineering side of the design. What's in your past positions, current positions, through friends who are also designers, what have you seen great engineering and design collaboration look like made up with designers or design engineers? I mean, I do find being a design engineer, I've always had amazing collaborations with engineers because again, you do the bit they didn't ever want to do. And you take away what I assume is most of the tension between designers and engineers that I've never experienced because I've always been a front end person. But I've heard of people, you know, they're being the tension where you have someone's made some perfect big file and the engineer hasn't implemented it exactly to spec.

And obviously there's a tension there because because someone made something immediate. There's a nice gradient and it's mobile and doing gradients would absolutely wreck the swirl performance. And again, these are like, we're talking about years back when this was a thing. And now you're going back like, can I change a single color or you try to explain like what you can do with your either performance limitations or think about low in devices, Android or iOS or Android where the designer might be more into the iOS world. And again, a good designer would not but there's oftentimes the engineer would come like, all right, we have constraints here for whatever reason.

Yeah, I think this gets into like, I don't want to blame the designers because I think it's a failure of tools because the design tools that everyone used to use sketch and figment, these like pixel mockups, they have no relationship to the constraints of the medium, which is like whatever you're building for iOS or desktop or the web, like you have to understand like the materials you're building within any design role, like a table designer would not like be oblivious to like how oak performs in certain contexts, right, or like how pine dents in a certain way. And in the same way, I think if you're designing for the web and you don't understand like performance or like how is your app like fetching data and what's the loading time and what if there's race conditions? I think if you're oblivious to that you'll end up with bad design solutions and then with really bad. Yeah, so I'm hoping agents actually help solve this, right? Because really then designers using agents can step more into the engineering side and also use agents as a coach and like a learning tool and say, okay, the engineers come back and told me that we have this like error state, I've never heard of in my life, like explain to me why that error state would occur, you know, and help me build a state machine, right? Like there's like all these new tools available,

but those old frictions I have to assume were just like tool based things and I would say designers that are maybe stuck in the past who don't want to let go of like, oh, I make pixel mockups, I don't know if anyone's there anymore, but if they still are, I mean, you're just, yeah, I can't imagine that relationship going on in the future. And then you mentioned Figma Figma was such a popular tool for a while, that was the interface between engineers and designers. How do you use Figma today or how have you used it in the past? I think I've always used it like not to get the hyper-deli mockups at all. I think to get like the rough shape of things past a notebook, so a notebook you can be like, okay, the shape of it is like this, but it's such a rough sketch and Figma is useful, I find for being like, okay, exactly what color is like the right amount of contrast, like your attention to this element on the page, like exactly what size does this text need to be to like flow well. But then you I would

never take it too hyper-deli because of course everything always looks different. I mean, I primarily design for the web, everything looks different in the browser, right, depends on the font rendering, and it was kind of a responsive nurse and I went exactly your break points. So I would always take into browsers pretty early on, you get like medium fidelity in Figma, like the shape of it, and then you take it into a prototype and then you can really tweak and refine. And of course with agents now it's just like my point and agent, my Figma mockup, and I'm like, just get all of that in there and then and then make, you know, what's called a jig, which is where you get like little sliders and variables attached to like a little jig. It comes from woodworking, or you make like a little device that helps you do one specific job. So with design, when you're working on a live prototype, you say,

okay, here are the variables I'm not sure about. I'm not sure about like my headline size, give me sliders and color pickers and like all these things, like the animation curve, I'm not sure about giving me and then I'll tweak it live. And then when I have the values just right in the live version, then we'll commit those to be the actual values much faster. It's like build your own Figma as needed. And inside of GitHub, how do designers work? How do yourself and other designers

work as a big organization? You're building a tool for developers with a bunch of different parts? I mean, I don't spend that much time with like the GitHub design all proper. I know some people in there, but your next. So the GitHub next team is a little bit isolated, like we still have good relationships with the rest of the world, but a little bit by design, we're supposed to be kind of like the R&D team out on the side kind of doing weird stuff and then trying to convince the rest of the org like that we're right and they should like pay attention and do our thing, which is a whole different politics thing. So I like kind of see the designers, but I think they

have a very different job to me and that they have to like poll quality standards and they're working on like a big design system and like an old Ruby on Rails app, but they've got very different constraints to me. Yeah, they have like millions or even more like tens of millions of customers who like that's now a different thing that they've been used to certain things or finding certain things or certain patterns. Exactly. Changing anything on dot com is like a whole political thing because because customers expect them to come and they have critical work for you can't move their button. But the team I work on does me and one other guy who are both design engineers. So we both like do engineering work, but we are more the design people and everyone

else is much more engineer like and they're really senior. So it's fun to work with them because like they've seen everything. They like know how to architect and have, but we don't work that differently to engineers. I find I mean, we're putting in PRs the same as them. We're like working on the same tools and materials. It's much more that thing of like what bits of the app we care

about. I have course care about the interface part and then like my engineer partner is what we'll scare about like the backend and the data flow and everything. So same tools, but different like considerations, I guess. I wanted to take some time to mention our presenting sponsor, TurboBuffer. TurboBuffer couldn't be a better sponsor for this episode as they have what I think is one of the most refreshing brands in tech right now. TurboBuffer's co-founder Simon describes

your brand as hardcore and whimsical and their design perfectly reflects this. TurboBuffer, the database is extremely hardcore AI infrastructure. It supports critical search workloads for entropic, notion, bridge water, cognition and many more of the largest and fastest growing AI companies in the world. They take reliability, performance and scalability very seriously. But TurboBuffer, the team refuses to be another sterile, boring enterprise company. Just look at their website.

It's exactly what you would want the website for a database to look like. It's simple, modest and transparent. They even put the limits on the homepage. But it also isn't boring. It's nice to look at. It's very well thought out. And their little AskI diagrams perfectly blend hardcore engineering

with whimsical design. Plus, if you've ever tried to generate a good AskI diagram with AI, you'll quickly realize that they create all of these by hand, not with AI. TurboBuffer's brand is the perfect reflection of who they are. And that's why it works so well. The brand is hardcore and whimsical and so is the team. I highly recommend TurboBuffer not only as the extremely scalable search engine for AI,

but also as a group of people that will go to exceptional links to deliver for their customers. You can check them out at turbopuffer.com slash pragmatic. I also want to mention our season sponsor entire. Maggie mentioned that as a design engineer, she's still putting in PR the same as everyone else. And every one of those PRs is pushed to get hosting. But there is a problem with get agents.

Get is increasingly becoming a bottleneck for modern agent-heavy software development. Devs are creating more code with agents. These agents are pushing more code. And many devs are running parallel agents that are pushing even more code. GitHub is clearly struggling to keep up and has frequent outages. So what is the solution? Entire was founded by GitHub's last CEO, Thomas Dumpka,

and he rebuilt get hosting for the agent to care from scratch. Entire was built to be very fast and have your repos region only close to you to reduce latency, allowing for fleets of agents to push in parallel. Entire's performance is next level. Their repo can handle 418 pushes per second. And that's up to 89 times faster than every other competitor on the market. When GitHub is down, you can still keep

working and you don't need to migrate away from GitHub. You just sign up to entire and the platform mirrors your repo. Oh, and one more thing. Have you ever wondered what prompt resulted in this code being generated? I find that the prompt and conversation with the agents carries more information than the PR itself. Entire captures all the prompt history with your agent right in the repo, easy to

check back. And it's got a pretty innovative UI to show all of this. If you're looking for get hosting that works, even when GitHub is down, head to entire.io slash pragmatic, install the CLI, and mirror your repo with a click. I've already done it. Well, and did I mention that it works with any agent and is open source? And then with LM, since they came out, how is your design process

change? You've already mentioned how it's not a lot easier. You can, like, for example, if you either have an interface with them, you can you can ask a lot or a code extra or an editor agent to implement it. But what has changed, like between the notebook between your mock-ups between the prototype that gets there was part easier and maybe what parts are trickier? It's definitely all faster and it definitely all feels a bit easier. I will say, I definitely remember not suffering through,

like making elaborate prototypes in Figma because that was going to be faster than like building more complex things in the web. And then trying to show them to use this with these like Figma clicks through prototypes that obviously like everything is faked. I remember that on the other user thing. And then sometimes you have to like have this weird things to click here and then. Yeah. So you're like in these user interviews and like the user's trying to click something

that you haven't hooked up to like a fake new screen. And the whole thing just feels a bit insincere. And then even when you did make prototypes, you couldn't spend any time making them look nice. So then sometimes the user would get like a bit distracted or confused by the fact it looked terrible. But yeah, but we only had a few days and then we got to move on to the next prototype. And

now I wouldn't have that problem at all. Right? Like now I can build something that really looks quite sophisticated and not with the agents doing it on there or a lot of direction I find to make something that I would think was an acceptable interface. But it's so much faster. Sometimes I have even mopped up quite high for deli stuff and Figma and then just been like, Hey agent, here's the Figma file, you know, goal mode, you play right, take screenshots, if it doesn't look like the Figma, keep going, keep looping until it looks exactly like the Figma and it'll get there.

And so that was just like, I can run that overnight. I don't have to do anything in the morning. The interface is pretty much there as I expected out. Like, and then to you guys, this was going to work, right? Totally. It's totally because you're like, this isn't complex. This is like, okay,

again, we're building another sidebar. All right, let's get the React components and like, and you don't really care about the quality or tech.run. You have like, it's gonna be throw away anyway, right? If it works because of that, because then you'll build it and if it doesn't work, like, great. It doesn't matter. Yeah, so prototyping is a whole different game now. I feel like you can

prototype much more ambitious things. And then I do love the whole Jig thing. It feels like this malleable software thing where like you can make the software whatever you want it to be where I'm not constrained by Figma's available tools. I can be like, okay, I'm trying to make this animated constellation map for something I recently did. Like, what speed are the stars moving at? Like,

what zoom level are we at? Like, you did that? Yeah. And like, how, what degree is the gradient at on the screen? And you just put these all little sliders and you just tweak it and then you think, oh, I really want like a slight like green like grain over this television, you know, it's like, it honestly feels like magical a lot of days. Do you have that? Yeah, let's see. So this is

something I built for the new GitHub next, like website, we have a kind of basic one up, but I want to something a bit fancy. We want to make it a little bit easier to like publish research frequently. So I was playing around with some like, you know, some jazzy, some jazzy home pages. And this whole thing is like an animated, like spinning constellation and these like some projects that the teams worked on over the years. Amazing. And like, this kind of thing to prototype this,

right? Of course, I started with the sketch notebook, but then made a bunch of jigs where I was, okay, what colors the background and like, how fast is this map spinning? And then there's a bunch of like, cool physics on the stars that I didn't have to do any physics. You know, I didn't have to know anything about that. You know, how, how big are these when you hover over them? And then I

did this like cool scroll effect down into the proper page. And all of that, right? I didn't write any code. I made a bunch of different jigs and tweeted just exactly. And then so these were like, just imagine these were like things on the screen, for example, the color you go from like blue, green, red, and then you figure out, right, you like this, the most sizes, all of those, right?

Exactly. I can be like, make me a slider for controlling the animation variables on the constellation experiment. So that work. But that's the kind of, it's like really simple. If you tell it, like, make me controls or make me a slider for whatever it is you're trying to do, just think about like, okay, what are the ways I need to like tweak this to make it work? It's pretty good

about just making them. I mean, I have a skill, so it like knows how to like make them so that they look decent, right? And based on your preferences, you know, what you figured out works? Yeah, yeah. But then it's great. Just hooks it up and then you can just kind of like play with it. And it's

a whole different way to design. It's very, you know, Brite Victor, like the live programming stuff. Brite Victor was, he's an engineer also a designer. I mean, he's often doing some crazy stuff now. He did about set of talks between, I don't know, it's like 2010, 2013, one of them's like, stop drawing dead fish. And it's about how like programming is not a very live medium, like, you

know, you code in the editor, you do your whole build, and then you look at it in the browser or wherever it is. And these two things feel very disconnected. It's very hard to like, you're tweaking variables in code, and then you have to go see the effect and it's not a direct connection. And so his whole thing was like, you need to have instant direct feedback at all times to be able to like look at the artifact you're making and directly tweak it. And it's like, this kind of stuff come to life. Like, now we finally can do it. But before you couldn't do that, there was like no programming

system in existence that could give you like a life preview of every possible variable or thing. Like, the closest we have is like dev tools in the browser. Well, another topic which is very related to this one, while we're waiting for one thing that with AI, of course, you're saying it's easier to build stuff, but if the AI is also easier to design, when I was asking people like how they work with designers and engineer replied to something, which I hear a lot more, which is I'll quote this person, I'm here as an engineer, I ask club design to generate 20 high-fuddly alternatives and I keep it ready to land with perfect design. It's very enjoyable and feels much faster than interacting with the design team. So it is a thing saying, Oh, I have these tools. I don't necessarily need a designer like I can just ask for all these,

like, and in this case, it was just giving me 20 alternatives. I'll choose a perfect one and boom, I'm done. As someone who is a designer, what's your take on on this? And by the way, this is not the first time I think there's always the thing like, do we need designers, do we need as engineers, do we need product managers? And of course, you know, product manager also has to be an engineer as well. But what do you think? Where could this be valid? What could people be

missing? I think in cases where you don't have a designer to hand and you're trying to like validate a product or like prove a hypothesis meeting in a face, right? It's great to just use a model to be like, sure, make me 20 high-fuddly designs. I'm sure I might look at those designs and be like, well, like, it all depends on taste too. I might look at them and think, okay, well, these look obviously generated by AI to me. And I don't know that they're going to do the job that

they need to do it. Again, it depends on the context of it. Something simple needs a button, a sidebar, fine. But if it's like, you know, we have some new primitive, we're trying to make figure out the shape of that when you really need a designer to come in and like, really, it's just someone who's assigned to like, think through the problem properly, like put in the brain work and be like, okay, do the experiments, like, show them to use this, like figure out what people actually understand and don't. And that's really like the labor I designed to come in and do. But

I think it's completely fine for developers without access to one to like, use models as much as they can. But when models do designs for me, I, of course, just look at them and think that is terrible quality. That is awful. Even to the extent of like, I think they've been prompted with some what we would call universal design principles, but they sort of don't understand nuance and context. And then I think they like, stick to them too strictly. So like, I find the agents want to put a label on

everything in the interface, label meaning like a small bit of text, like there might be like a little button that's like to close the sidebar. And we would usually use an icon button for that, because most people are trained that this little button, the other sidebar means it'll close it. And they'll experiment with it and they'll click it and they'll figure out that as correctly what it does. But the agent will write close sidebar or close modal in the top right hand of the modal. And you're now a lot of text on this page. And they'll just like put like four lines of instructional

text over a button and just things where you're like, I understand in the models mind, it's thinking, oh, this is how we like make the interface explainable to the human. But actually, it's really bad to say. Now, talking about the UX and UI for AI, what do you think UX and good UX and UI looks like? And I know this is a bigger question, but so far, what have you learned about what works and what doesn't? I think when it comes to this, like, what is the ideal UI of AI, which is like a big question, I don't know that we'll figure out the answer to for a while, but it's something like, something's haven't changed. Like, in terms of what is good interface design for software,

it's there's still a lot of principles here. Like, what formats do we have to show users like data? You know, it's like dashboards and sidebars and documents. Like, there's a lot of things that haven't changed. We actually had a good story from this about this from a list where the app was like helping scientists extract data from papers. And they were very used to doing this in

Excel spreadsheet. So yeah, big Excel spreadsheet, put the papers in one on each row and then they'd extract each piece of data into the cells, right? Pretty standard process. But of course, in the beginning of a list, we were like, oh, that's so old school. There must be some like much better interface for like, you know, seeing the data extracted from papers. So we tried all this crazy

stuff. There was like infinite campuses with like cards spread everywhere. There was one that's like a bunch of cards that are like, linearly stacked. We were like, maybe it's more like notion of these like composable documents with which interfaces like we tried all this stuff. And every user in a view I did, users were just like, this is very confusing. Can I just have a table? Like every time.

And so after a couple months of this, like, Oh, what's the new UI of AI? We were like, Oh, it's a table. Well, at least in our use case, it turned out the interface people were using was the best because it was the most familiar to them. And it caused the least amount of like cognitive load for them to use the tool. So we were like, right, back to tables, that's fine. Like, it was good to go

on that journey. But sometimes we have this notion of like the UI of AI will be so wildly different from our current imaginings. And sometimes it's really not at all. It's like, you can do more powerful things. I think there's lots of leverage, but I expect it to all be built with documents and sidebars and tables and like all the, all the classic things we've worked out do work and people know how to use. Yeah, interesting. There's a cognitive load in learning any new U.S.

UI paradigm, it can be confusing if you're existing tools don't work like that, because again, people will still use operating systems and Google sheets or Excel or office documents, etc. And even if like a small subset of people are like, I don't know if familiar with this new UI, new UI. So if you remember like, probably like parents or grandparents teaching them how to use the phones, the interfaces and ones they learned to, they're good. But then you really want to do that again? Yeah, no. Yeah. So what's the similar? Yeah. It's kind of like how we started with chat

bots, right? It's like chat bots were not the final form. Like as if we could look at codecs, like, there's a lot going on here. There's short, there's a chat window here. But there's all kinds of things going on with it, work trees over here. And then we've got this whole interface and like, I can do

like annotations and debug in this. Like, there's a lot of extra stuff where you take the familiar primitive and you expand outwards from it. And we did similar things unless it like, there was still a table, but then we baked a lot of stuff into the table and around it. But you start with familiar primitives. So here, I can like change. So we have our jig ready. Yeah, let's expand this. So here's

a jig. This is using dial kit. This is built with this, like a change to the speed of the animation to see like, oh, is that too fast? Like, is that too slow? The intensity is like the how much gravity is being applied to the stars here? How much variation is there in the stars?

It's a sizing and scroll. So this is like when I scroll down to have this zoom out, like what's the resting height? I think this is of the, when this is here, like the resting height of this, resting logo size, let's see what this is like, I have some glass effects on the surface that it's like, oh, it's on the top. Like that is that glass effect. Like, see, that's too bright. Then you

can't read the words all the way down here. You can barely tell it's glass. There's some sort of like happy middle ground you want to figure out like how much contrast between the background. So this is where you weren't kidding that this is like your own almost personal Figma, if you will, or like something to it. Yeah. And then it's really difficult to mock up static versions of this

and figma, which I have done. Yeah, like I was for a minute, we were thinking maybe like a gray background, trying to figure out how much like grain and stuff, maybe like a wavy one. Yeah. And then I'm trying to figure out here like, okay, is it like halfway off the screen? Maybe there's like a slice out of it here. So you can play around with like layouts and ideas, but you can't get a sense

until it's live in the browser of how this is going to feel and like how much scroll you need to do here. Like, and then like the themes and the colors and textures and everything. So I work with this a lot now when everyone designing something visual. It's so much easier to have live variables, which again, would not have been possible before you could have built this by hand, I guess, in the olden days, just would have been practical. Just coding the thing itself was slow enough. One interesting

thing we talked about is capability gas lighting. What is capability gas lighting? I think this is similar to like even Molik has this phrase, the jagged frontier. It's pretty much that but I came up with capabilities gas lighting before I read his work. But so that people are familiar with the concept.

It's that models are really, really good at some things and really bad at others. And it's really hard to predict when you give a certain task, which of those it's going to fall into. And then capabilities gas lighting was the feeling I got early on from using them where like they convince you they're so capable because they'll really impress you on one task and then you try them on something else and like they fail and you kind of feel like you're kind of gas like me, like imagining that you're this extremely intelligent agent or model. And then you like fall in your face. And then sometimes I feel like they fail, but I haven't totally noticed how badly they failed because I still have this belief that like, oh, but you're a frontier model like, oh, this could never really get this wrong. It totally does all the time. So it's such an inconsistent experience.

It's so different to working with a human. Like if you find a human who you feel is like really an expert in a topic and you work with them, it's very unusual for them to be inconsistent in their performance, right? Like it's very rare for them to suddenly forget all of their expert knowledge on a topic. And if they did, you would be very like, are you having a mental breakdown? Like, this is very weird behavior. But this is how models like behave every day. Like one day they

will actually perform really well on a task and they could fail at that same task the next day because you prompted differently or they had different contexts available or like random whatever it is like stochastic outputs. They just didn't do as well. So I think it's hard to work with them because you never quite know what you're going to get. Yeah, but I guess we just need to keep us in mind, and this is ongoing. Like, of course, we always say and we have seen that the models improve, but you want to be skeptical. Yeah, yeah. Of course, there's some baseline with frontier models that

they're not going to perform below a certain bit. But you know, of course, the models are changing all the time and people complain about this that you operate to a new model and it changes what it's good at or it changes like it doesn't perform to you expectations of certain things. It's like, it's hard to predict. You did a talk titled One Developer, two dozen agents, zero alignment. Why we need collaborative engineering. Can you talk about just this observation, like one developer,

two, seven, two dozen agents, zero alignment? Yeah. So this is like a problem that the GitHub next team has been focused on trying to find various ways to solve. I think for well over a year now is this is this acknowledgement that we are now working with these agents locally on machines and it speeds up each individual person like us alone with the agent. We can go really fast.

The stuff I always built on a team, right? You're always trying to align with like the product managers and the designers and the other engineers, like what decisions you're all making. And we don't actually have good tools in place to do that. It's sort of like we have Slack. People might have something like linear or get have issues where they're like doing issues, but there's tons of pre-planning work before you write an issue because usually when you write an issue, you're like ready to hand it off from an agent. But before that point, you have to have agreed upon your approach and like,

should we build this feature? Is this feature the right shape? Does it have the right interface? Like do we have some sort of database migration? We have to do this all this like up front work and not many good tools do that work in is how we felt, especially not ones with agents involved in them.

So the biggest gap seems to be like we have a denting tool, but none of them are real-time multiplayer or your sessions are private and shared to you often locally on your machine. So you couldn't possibly share it with someone. This is starting to change now. Like I have seen some products come out that are trying to do live multiplayer agent work like buzz from Jack Dorsey and ace the prototype that we made at GitHub next was in this direction was like shared compute shared sandboxes in a Slack like interface. So you're like coding and talking at the same time.

So people are beginning to realize this is like the next big thing we need to push on to improve and like our agent coding tools, but it's totally unsolved. Like even once you have a Slack interface and as an agent in there, you still need tools to agree on things. This is where I'm kind of pushing on like maybe decisions need to become sort of first-class primitive. Like when an agent presents a decision to a human, you first need to have the decision be like large enough on screen to give you the information about it. But then also you probably need someone else on your team to come like help you make that decision or at least give input on it. And then someone has to be responsible

for having had made that decision. You need like a record of like here's the things we decided. Like here's the context we're going to feed to the agent. You know, there's some moment where we've written like a clear set of issues or specs that we're going to hand off to be implemented. And then some verification check on the other side. But you all need to be so aligned up to the

point of implementation because in the old world implementation took so long you could like adjust along the way. But now because there's a sort of hard handover point to an agent, you need to all be aligned up front in a way that we're not at the moment. Like even our team, we feel this all the time. It's like we're all individually running on our machines and it's hard to stay aligned on what we're doing. And you mentioned GitHub next time in deproziving that you're doing.

Can you talk a little bit about the types of projects you've built that you're experimented, some learnings that you've had? Maybe give us a direction of like things you're now excited about exploring. Yeah. So I joined the team like a little less than a year ago, but most of the time we were working on this prototype, which is like Slack, plus cloud compute, like Sandbox, it's a micro VMs and a bunch of other stuff in there. Like you can like open PRs and review your code and that kind of stuff. So it was all in one multiplayer workspace. And it was a really like

useful prototype, but it turned out to be extremely ambitious for us and we had like three or four people working on at a time. And we wanted it some point to take it to like a real product, but it just turned out that was like not feasible with the number of people we had. But we're trying to take bits of it and ship it to the rest of GitHub. Like Sandbox has now gone out to be part of the GitHub desktop app. That's been used in other ways. And I think it's also made leadership take the

multiplayer like thing more seriously and try and find other ways to make ship that to the product. And that this is a really promising direction. I mean, we already have a deep dive out by the time this podcast is out about ramp who have built just this inside and they made it collaborative. It's forced collaborative. You cannot make anything private. Oh, yeah, we do have multiple interfaces.

They have the running is called inspect and it runs in Slack. There's a Chrome plugin as well. There's a web interface and they did find that in the Slack channels with product manager designers. They can talk the agent is like gets all this input. And then all the sessions, anyone can join a session and anyone can prompt and change the direction, which actually was a really concerning point. They weren't sure if they want this because people, but they were like,

well, it's just some of the nice things. So it turned out to not be an issue. But because of this, it spreads better. And it has all this feedback, which is the reason it works really well for them is it's integrated this agent to all of their internal systems. And their cloud machines are like a full-blown developer machine, which is a lot of work with cloud development environment, which is all this to say, like doing this or one company specifically for them, it's possible doing it as a generic solution, probably more difficult. I'm sure it will come or I'm sure there will be attempts.

But this is the difference we seem like scratching your own itch and doing something that works for for so many people. I mean, Slack, they launched their whole developer experience ID thing, which they might be able to make this experience happen. Buzz from Jack Dorsey is going in this direction, too. There's clearly lots of people realizing this is a problem. And you're also experimenting in this direction, clearly. Yes. So one of the things, when we tried to build this whole thing,

it was too ambitious to do it with all the micro VMs, but now scaling back and thinking, okay, what bits of this could be prototyping ways that would help GitHub leadership have a bit more direction of where they should run next. One of our functions of our team is just to run out of product and say, okay, you guys know what the things you should probably do in the next six months to one year is we are much more like, what is a big crazy swing GitHub could make or what's more risky or what's like the far future. And so that's why we're trying to prototype. Okay, people now on this multiplayer, like sessions thing, what comes after that? So now we're interested in like, how do you make proactive agents that aren't annoying? It's one of the

things we're trying to explore. Because proactive agents, you think we have this dream of like, okay, assume, assume intelligence is like free or so cheap that like it doesn't matter, right? That's a fun assumption to make. If you could have 100 background agents running, what would be the least overwhelming least annoying way to consume any of their outputs is like an open research question. We're trying to figure out how would you have agents working in a document with humans where it's not, again, overwhelming or annoying for them to be making changes or doing helpful background work in a way that doesn't feel like invasive or interruptive.

So we try and take these kind of design questions and figure out prototypes that could solve them in the hopes that like, you know, if one day you have wanted to build something in this direction, we can then be like, hey, here's all the research we did. A question I wanted to ask you is coming from a developer angle. It's what happens when in your experience observations when we start to give more and more decisions to the agent. And I'm going to quote a developer Jorge Monruvia who wrote an article called Omicraft. He wrote the neat interview on the small stuff is decaying quickly as models improve. And when models are capable,

enough to handle those details themselves, spending too much time on these details starts to feel like a poor use of human attention. And he writes about how he's not opening it. He really opens his code editor anymore. He has been months he wrote a single line itself. But the thing is he used to live inside and see all the details. And there is a sense that craft has to do with being

there with the details. And of course, you're coming from a design perspective, but what have you observed of your own craft changing, decaying, or what you're saying? Do you think this is a danger as there's this temptation as we talked about, like, just good, good, good, make this decision? We just did this with the slider, which didn't matter. Yeah, but it can matter.

But it can matter. It doesn't matter. I mean, it's hard because I'm not like, I would say like a true engineer in the sense of like, I don't necessarily care about clean code that much. But you care about great design. But I do care about design. But the thing is,

they can't, they definitely can't do design to my standards. Yeah, I have to still be really involved to get the design to look and feel the way I would make it. So I'm annoyed almost that I'm always in there being like, no, that is a terrible transition. Here's how we should do it. You know, like this. So you're into details. You're not letting go of those details.

Yeah, because I wish I could. I wish, I mean, I've written design. Well, I don't know. I want to put you on this. Yeah, I keep thinking this. Like if tomorrow I keep

trying to write design skills that tell the agents exactly my design preferences, which will be universal, like I have preferences about how much padding I like between a border and an element, right? And that's not everyone's preference. It's not right for every product. But for me, I'm like, there are set rules. It's this much padding. It's this kind of border, border shadow, like it's pretty standard.

And I've tried to write these rules, but then they don't universally apply them properly and it doesn't work. And so I always end up in there changing specific values that you would think by this point in time would have been automated away the way that we all talk about that agents are like taking over stuff that you would think this would be so trivial to like for them to implement like a certain kind of whatever it's opacity level on a border. So I kind of think if I woke up tomorrow and they just still just worked or like the agents just had enough context and they just designed exactly to my specs, I wonder if I would be like, Oh, all the fun bit is gone. Like, is it satisfying to have like a gorgeous interface up here in front of me? But I didn't, I didn't do anything to make it.

I'm not sure. I almost I also think about this with like interior design stuff. Have you been on Pinterest anytime in the last like two years? I'm familiar with it. And my wife is in one when we're decorating a new house, like I remember collecting these things. We work with an interior designer

and my collective a lot of things. But I also was there and you have these kind of like, we're kind of thinking like this, but not quite but like when you mix this trying to explain, you know, like we wouldn't have the tools beyond like you just take screenshots. So yes, from there in the print, just I guess. You know, you know, yes, it's a lot of it is AI now if you get on there. Oh, really? There's gorgeous rooms if you search for certain things, but you look and

you can kind of start to see like, Oh, that's for sure AI. That's for sure. Yeah, which is definitely problematic when their images of a physical space because then you go like, Well, the light might not be accurate or this is all just fake. And they look beautiful, but you kind of think like, well, someone didn't make that room and that's not a real room that exists. So it's almost irrelevant to me. Like, well, look gorgeous. Cause it's been trained. It's like very much like everything that was on

the web that we've, you know, clicked thumbs up on. But with interfaces, if they all become extremely slick, like, think you take, you know, what's popular right now, the linear and their aesthetic, right? Like very minimalist, very clean, very white, very little bit of rounded corners. If all the agents can implement that, no problem. Just like dead on. People will start to design in

different ways because that will become a tell that you just use an agent to do the design. And if you want to look like you're going to stand out, you need to have some human do something new and different. I think it gets into like design, although it has universal basics, like is the tech space enough to read? Do you have enough space around things? A lot of it's fashion. Like it's in fashion

right now to look a little bit like linear. It's not in fashion to look a bit like my space, but it was a while ago and they'll be in 10 years in the future. If you look like linear, you're very out of date. You look like some old, crappy piece of software and there'll be some new aesthetic that comes up. So it's like, the models can't necessarily understand that design is like within a cultural context and that cultural context is always changing. And it signals different things to

people. And if people read it as like, oh, they didn't care about this, like, because it's just like the bland basic code, like Claude has a specific design language. It's very like, like, noticeable, right? Cream background, like slightly red text, like this eyebrow text on things like, you look at it, like, yeah, yeah, yeah, yeah, though generated that. No human was involved in this. Like, I don't know if

style you pick communicates to the person viewing the product or page and things that clearly were made by agents. I think we might start to reject out of hand. Maybe I have this thing where when it's text, when it's written text, I can immediately tell if it's AI written. I can never tell if it's because I write a lot, I also read a lot. I read a lot of fiction. And so it just feels off immediately.

And it's not just Claude, it's just the repetitiveness, the objectives. But I can never tell for sure, like, am I the one who notices because you said like, Oh, you see it's Claude. And I'm not sure if I looked at a web page that I see that as Claude because you're, you're so into this the same way I'm so into words or or nonfiction writing. Yeah. So I do wonder if if maybe we're talking to as an expert, you can always tell, but the experts are always a small percentage of population. We don't know. But I

do agree with you that it is predictable in ways that humans are luckily not, I guess. Yeah, like, I definitely noticed the writing one too, because in the same I'm a writer. I love writing. And the minute I hit any sentence that is like remotely like, yeah, it's like close to everybody. And then even like going back and reading, you know, nonfiction books that like were really like not written a long time ago, you're back a read book written 50 years ago. And just the opening is so refreshing.

You're like, Oh, these are such novel words. Like there's none of this, like, if this then that, or it's not X, it's Y, there's not a single bit of it to be seen you just like breathe in like original human writing. And it's so refreshing that you go, yeah, I can't stand to read anything that's taken and tried. Speaking of original writing and human writing, you've talked about the digital garden. What is a digital garden? It's a blog, but with some extra rules attached. So it's a blog

where every piece you put up does not have to be finished, as long as you clearly signal to the audience, it's not. So it's a blog that you grow over time. So you can put a piece up that's half done, and then update it later, you have like an update of that date. And I usually will, I communicate it with three different stages my post go through. So I have seedlings budding and evergreen, like, in the gardening metaphor. So I can put up something that is like a half finished thought and market

as a seedling, and then like come back to it later and finish it up or fix it. Writing in this way has made me allow me to publish much more than I ever would have otherwise. Like I have perfectionist tendencies. This was very much a counter to that, where of course I want some of my stuff to be my best work, my most polished, but it's completely unrealistic. I would never put anything up if that was the case. So working in this way really freed me. I mean, I started my garden in like 2020,

I think. So it's not been that long, but I've written a fair amount more than most people have blog posts on their website, because some of them are frankly like three paragraphs long. Or they have some of them, I have big long essays. They've taken me a long time to write, but halfway through the SLU will hit something that says draft in progress and everything below that point is pretty rough. One of these I started three years ago, every time I have like some free time, I go back to it, like finish one more paragraph, I like move the little draft notification down. It like allows me

to work in public, which I also think helps like people kind of get to see behind the garage door a little bit, because often the notes below the draft point are like bullet points or like, oh, I should say something about X and here. I'll just kind of put it on the website as long as it's marked appropriately. I think it's fine. It's like this like contract between you and the reader, as long as you're communicating to them that these are like rough notes, I haven't finished that. Okay, as long as you're not saying like this is my best finished work that I feel like people read it in the right spirit. Someone's related to this. Again, just going away from from from AI.

You also talked about barefoot developers and home cook software. Yeah. What are there? Who are there? So this was, I'm not sure I remember what year this is. It might be 2024, which feels like an

eternity ago was not that long ago. This was at the local first conference in Berlin in 2024. I did this talk here. Home cook software barefoot offers home cook software is a phrase that comes from Robin Sloan, which is software that you make for you and your family and the way you make a home cook meal. So it's about this app that he builds for his family where they send each other video notes and it's like, it's not anyone else's server. He doesn't have to pay for it.

It's not managed by some big company. And this is the way more software should be. There's lots of little pieces of software we can build for ourselves that benefit our lives and our families, and it doesn't have to be like 299 on the app store or sell my data in exchange for this software. And I made this case at this conference that I expect to see an explosion of this with language models. Okay, the writing was already on the wall. I don't think it was that crazy of a prediction,

but we were still more in the early days. We didn't have agents yet. But now, of course, it's like totally happened. There's like personal software everywhere. Everyone's building their own recipe manager and their own household app and their own gym app. And like there's all these

great use cases that people can just make the software to be what they want without having to download a bog standard version of it. But I extended this concept by saying, okay, home cook software is for you and your family. But there's another concept that I called barefoot developers that comes from in Maoist China. They had this thing called barefoot doctors where they took peasants from rural villages and trained them up with basic medical training, like giving vaccinations, you know, administering antibiotics and then distributed them out to the villages so that you would improve healthcare for everyone. And it was a wildly successful program across the board and improved health as you would expect people who can't get to hospital. And I think we

need the same concept for developers because so far developers are extremely expensive as a profession and like extremely skilled. But there's lots of people with lots of needs who would maybe need little software built for like their allotment garden or they're like street. But they have some problem they need solved. And like Google sheets doesn't really cut it. Like they can't really just do like a Google doc. They want something like maybe managing a

schedule or like managing inventory. And like either they would have to all like raise money together and like fund it and pay some piece of software that doesn't quite fit their needs, but does an okay job or maybe trades their data for this. Or if they had someone who was let's say at this barefoot developer type who's like kind of a power user, someone who might use a notion on an air table in an old world, now can just use an agent or language model and building the stuff where they need for like not many tokens, like pretty cheap. They don't have to read the code as long as it works. Like as long as they verify it's fine.

I mean, what reminds me a little bit of the webmasters. Yeah. So back it was a long time ago, but in the 90s, maybe mid 90s, late 90s, the webmasters were just power user administrators who would administer, for example, schools, yeah, windows installations and they were not the highest paid. I'm not sure how they got trained, but at some point every school had a webmaster, sometimes they were volunteer, sometimes they were paid, companies had their webmasters and they would often operate the web pages, which was again more involved, way more involved than later. Of course, that's why there was a role and then like patch things and it was all kind of, you know, they were they might forget to patch stuff or they might not know and they're like forums, webmaster forums where they helped each other and it was kind of like, because what you talked about, the China example that was of course a government program with the goal, but this was just a grassroots movement. Yeah. Yeah. And I think that needs to happen again.

Like we definitely have these people to some degree, like there's like a techie person in each community who kind of people go to for help, but I think these people need more like support and tools and I mean that in a sense of building like libraries or frameworks for them, because I think there's a whole bunch of people now coming in as vibe coders or whatever, right? Like building apps that looking at code, but you know they're hitting terrible security, like foundations and like they're probably like handling the data wrong, like they lose their database at some point, like they don't have good foundations to build on because they're just telling the agent like, hey, make me an iOS app that does X, but they don't really understand engineering. You know, I would advocate for something like something that is, I think it should be local first because this philosophy it matches up with the need. It's like data should be local, you could just think it between machines, you don't really need a database in the cloud, there's no point to that, like a little bit of data sovereignty, they own the data, no one else can buy it or trade it or get access to it. I just feel that should be much stronger like local first frameworks that give you these good, good solid principles of place, good security, good data persistence, make it easy for these barefoot developers to build, like maybe some good interface primitives on top, it's maybe something like the next version of air table would be this is what I would hope.

What advice would you have for engineers to learn from designers when they have access to working with a designer, learn from also collaborate better with? Yeah, I think it's in the same way that I'm advocating that designers shouldn't be afraid to get involved in engineering now vice versa, right? Like in the same way that a designer can sit down with codecs or core or co-pilot and be like, hey, explain the backend to me, like just not the details, the shape of it. I think in the same way developers can sit down with an agent and be like, okay, I need to design a sidebar, like what are the principles of good sidebars? Okay, I have my blog, like teach me about typography, like you now have like a very patient tutor who's just gonna sit there and be like, okay, this is where when you would vary line height, here's exactly how many characters you fit on a line, like they can just teach you and you know, as long as you're willing to learn and you want to expand into the design skills, I think before it was very hard to learn these things, you had to be on a design team, especially part of design stuff, like how do you interview users, how do you do like a usability test, like not generally available information really except for some books. But now you sit down with an agent,

you're like, hey, here's the data I got, give me some ideas for possible interfaces that would represent it. Well, they're decent at that conceptual stuff, even if they don't always get the interface, right? Going back to your anthropology roots, what are things that us engineers, people building software could take inspiration or learn from anthropology, like methods approaches, things that have really served you well. Yeah, because I feel like I look at everything a little bit through the lens about the polyure, I try to, it's like a peg glasses you can kind of put on in the same way you can be like, I'm gonna look at this like an engineer, but if I look at things like an anthropologist, you think about like, what are the unspoken cultural rules going on in this interaction or this context with this problem, and especially in the context of software, like sure, maybe you're building a database that you're building it for users in a cultural context, right? Like, they have assumptions about how they decide something is trustworthy, they have assumptions about how they decide that something is worth their time or like how a flow should go and this is all culturally contained, like, it depends also on like the international, how international your audience is like what you're designing for, but there are cultures where like time flows from from right to left, right, or from up to down, but we assume in the west, you know, time for

those flows left, right? But that's not universal everywhere. I think just like reading a little bit of cultural anthropology and understanding how varied people's world use can be, like some culture see, not see different colors, but categorize colors differently in a way that makes them see them differently, like they might see blue and green as actually one unified color, and if you're designing an interface like, not that necessarily directly applies, but I think it's understanding there's a broader range of ways humans can interpret something and, you know, if you're building tools for humans, there might be some where you could like teach them to see the world differently through the thing you're building as well, like change their perspective on like how they how they interpret reality. And then in anthropology, you said that, you know, anthropologists would one thing that would do they would the traditional anthropologists would live with natives and be embedded in them.

Is that something that maybe now that AI is, you know, like, it's making code a bit easier as engineers, I think it's pretty clear that an injury becomes more valuable the more they take on the other parts of the business, the more empathy, the understanding, could it be just an idea when you have the opportunity to just embed yourself with customers, become a customer yourself. I mean, this used to be the thing, right? Like Amazon had their customer obsession, which also starts with understanding customer, but I guess this might be very natural as someone who's an anthropologist, which is like, you know, go and try to be one of them, whatever you're building with. There's a good point that like, engineers are about to have more free time in a certain way. I know there's an infinite number of engineering problems to solve, and then it's like, maybe solve them better, you know, by having with that extra time. But a big part of this is, yeah,

you could expand into more of the design side. And past the interface is really like the user research side. And that is like, go fully understand the domain you're designing or building for and like, what real world contexts are people using it in? Like, when are they pulling out your app, like, in a factory, are they on a, in a tube, like, I don't know, a little bit of like, understanding context of use is a big thing that user researchers do. And then understanding the moment when someone reaches for your product versus like, reaching for a different product, like, one of the decide you're the right solution. That definitely gets into the user research side, but that's a

great thing for engineers to expand into if that like appeals. And it's closing. What books would you recommend one that you enjoyed reading and why? One of my favorites that I give to most people is called addiction by design. So it's about people addicted to gambling machines in Las Vegas, but it's an anthropologist doing it. And she talks about both like living among these people and

their experiences, but also the machine designers, like, how do you design a machine that is so addictive that someone sits set up a 12 hours straight? It's like a really fascinating thing. And how are like gambling casinos designed to have no windows, there's like no time around you as you like, it's machine is by Natasha Dauchil. And I read it in university and I love it. It's it's a total mix of like cultural anthropology, participant observation, and also machine design and engineering and like, how do you design addictive systems? Which of course, you read it and then

you think about phones and Instagram and you reflect a little bit on like, what are these systems we're building for people Maggie, thanks so much. This was very interesting. Yeah, thanks for having me. Really fun. This was a very visual episode. So I hope you were able to watch your video,

especially the parts where Maggie showed her sketches in the notebook. And this was one of the most interesting parts of this episode for me. Even as Maggie spends her days prototyping the future of agentic tools, she starts her design process with pen and paper. Her reasoning is that agents cannot see but us humans can. And I have to wonder, is it only true for visual stuff? I mean,

when I think back to my most productive brainstorming sessions with engineers, it was usually in front of a whiteboard drawing stuff where we drew out our ideas about the system and the components. Another extremely cool trick from Maggie is how she uses AI to generate prototypes with sliders to change parameters and change the design. She calls it a build your own Figma and we did a live demo with a constellation animation that you played around with. This was so darn cool. You get Figma like tools dynamically built for you. It's also pretty incredible that we can do this

with agents in a matter of minutes. Just wow. Finally, I appreciated how Maggie was honest about how she feels about the design craft. It's cool that agents make her work faster, but she said she's not sure she'd love if an agent just spit out a perfect design. And yet, agents are getting better at design. It feels to me that this is kind of how I feel about code. It's great that the agent can

generate good code, but it was something I liked being good at and I wasn't good at it. Now, I don't write the code, but it does feel more transactional. I feel a bit less connected to the code and the creation of the code itself. For design agents are not there yet, but I didn't sense that Maggie wants to let go of that designer in her. I wonder if one thing to learn from her for us devs is that we should also have a notebook to make sketches of ideas, not just UIs, but architectures and systems.

I don't know, but I might give it a go. At least it will make me feel less that I'm dependent on agents and I'll have some AI-free space, if you will. Thanks for listening and let me know how you like this less conventional episode. Thanks and I'll see you in the next one.