Designing for the Agent Experience: When UX and DX Collide in the Age of AI

Dana Lawson at UXDX USA. Video: https://youtu.be/De3Sh8LrHrc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Agent experience is really about humans

[00:00:08] Good morning, y'all. You know how fast AI moves? I was working on this talk six months ago and it's already out of date, so I totally changed it. Well, not so much, but I had an epiphany when I was doing this. This was originally "Designing the agent experience," and guess what, it still is. But as I started actually doing the implementation, I realized it wasn't about agents at all. It's really just about humans.

[00:00:42] Welcome, everyone. I'm Dana Lawson, CTO at Netlify, and here's my thesis up front. When I was redesigning the Netlify platform for these agents, it did not just help the machines. I was approaching it like a true DevOps engineer, and it forced me to make everything better for humans. We call the discipline agent experience, or AX. The surprise was that AX turned out to be the best thing that we ever did for the people behind the keyboards. Not just developers, not just engineers, honestly everybody, because now that everybody can build, they are building. So this talk is about what the journey looked like, how I got there, what broke, what I rebuilt, and why the builder persona is no longer just an engineer with GitHub.

[00:01:29] Before we get into the architecture: I know you're going to hear this over the next two days, but our jobs have changed, and some people may have different opinions. Tomorrow I get to have a fun debate about how it's taken your jobs. News flash, it is. Sorry, I'm going to say it. But don't freak out, because we have more purpose than just doing some stuff that AI can do. The people that build on our platforms are no longer just developers. This conference, UXDX, is really now just about agent experience. But the most important thing is that AX is just about the people behind the keyboard and making their experience easier.

[00:02:07] IDC predicts that more than 5 million new applications will be built by 2028, and at Netlify I can attest that there are more than that, because I see them every second of every day. It is incredible to see the world building. That is more than 40 years' combined worth of software in less than three years. And that's not because the number of engineers is exploding. In fact, are we engineers? Who are we? Who am I? I've been asking myself that my whole life, and now I'm really confused about who I am. It's because agents have turned intent into a programming language.

[00:02:52] The new strongest programming language out there isn't Python. It isn't the new hot JavaScript framework. It's English. It's English. We're having to retrain ourselves as engineers, developers and technical professionals to actually speak to each other again, because guess what agents learn in, and guess what they do? They do English. Claude Code, Cursor, v0, Bolt, Lovable: these tools let anybody build, and they are great at working through software ideas. Therapists, teachers, small business owners are becoming software creators. Anybody with a good idea can now get it out to the world, and I am here for it.

[00:03:29] I've always had a mission, in my own personal background, to lower the barrier and the gatekeeping of this technology, so that we can all just unlock humanity, because we're building for each other, not just for bots. Because of that, we had to rethink how we're doing this. At Netlify we're building for all these builders, not just developers, not just product designers, not just product people. The agents are here to serve the new builders, and it has to just work. What we discovered was that when we were making it better for the agents, it got better for the engineers as well. This wasn't just for the builder, but for everybody in the development life cycle.

Tori and the retreat website

[00:04:11] Let me tell you how I got here. Let me introduce you to my home girl. She is my best friend. I live in Portland, Oregon. I don't tell anybody I'm an AI overlord, because they probably won't be my friends in Portland, but y'all can share the little secret with me. She's a licensed massage therapist, she is a vibrant drummer, and a delightful, authentic woo-woo hippie. She makes me rub crystals and do seances. I love this woman. She came to me and she's like, "Girl, I got the best idea ever. I'm going to create an all-inclusive retreat in Barbados." We were having this conversation in Barbados, mind you, on the beach. And I was like, "Do it. You are amazing. I'll be the first person to sign up."

[00:04:52] She didn't just want to go to WordPress, and no shade on all those old systems. She wanted to really unleash this experience and this idea, and really enjoy building a community in her favorite place in the world. Tori doesn't write code. I don't even think she knows what code is. She writes intentions, and she decided she was going to build a website. So naturally she went to ChatGPT: build me this website. It wasn't just a simple static website. She had a vision of community, of everything just working out of the box. She's like, "I ain't taking payments, but I need money." And I was like, "We got you." As you think about these people unlocking their ideas, this is really what agent experience is about.

[00:05:36] She went into ChatGPT and started prompting for a website, but every assumption we baked into tooling turned out to be a human assumption. First, it was all about Git. Git this, commit that. She was like, "Girl, you worked at GitHub. You know what that is? Come tell me what it is. I don't even know what you guys do." And I was like, you don't need to know. I'm not teaching you GitHub. We used to have stickies at GitHub to teach us GitHub, and I worked at GitHub. That's a true story. So I was like, okay, all right, she is my perfect guinea pig. This girl can't Git nothing, pun intended.

[00:06:12] The reality is that for millions of new builders right now, agents speak fluent developer. They're spitting out SQL, foreign keys and all the other stuff that nobody knows what it is. But the humans they're serving, guess what? They don't. Some of y'all in this room are closer to the code than ever in your technically adjacent roles. You're having to go through and see all of what we talk about in our dev speak, sometimes leet speak. These tools assume a level of technical literacy that most of the world just doesn't have.

[00:06:42] The surprise for me was that fixing this for Tori, so that she could just get it done, fixed it for my entire team. We made the agents' error messages clearer. We structured the build output for machines. We removed unnecessary friction. The engineers benefited from it as well. It wasn't just the user experience, it was the developer experience, because at the end of the day we just wanted to make it work. Every human assumption we removed made the platform better for everyone, and this is the gap that agent experience closes.

Guardrails are vanishing

[00:07:16] I was blown away. I'm just telling her, after all these years, you do not need to worry about code revisioning, rollbacks, et cetera. Just roll it forward, get it done, prompt away. And I was like, these guardrails are just vanishing. That doesn't mean they're vanishing just for her. It means they're vanishing across the entire development life cycle, and we have to implement new ones. Why are they vanishing? Because the interfaces changed. The agent handles Git. The agent handles deploy. The agent handles DNS. The builder focuses on the vision.

[00:07:51] At Netlify, this is what it looks like in practice. Agents have full access to platform primitives, deploying, configuring, iterating, so the human never has to touch anything, which is scary but awesome. Again, we have to continue to think about the architecture, and the trust and safety that we built around it. AX is here to capture the humanity in the story. It removes that technical friction, so again, people like Tori and me can just build.

[00:08:18] Here's the key insight: we didn't build two separate experiences. I think every designer in here would slap me if I put a toggle on that screen. I heard that's bad design practice: don't ever toggle a screen. Somebody come talk to me. I was like, just put a toggle for power users, and they're like, "Do not toggle." This is why they don't let me touch design. We built a better platform, period. We didn't dumb it down. The same structured signals that helped an agent deploy Tori's site also helped a senior engineer break-fix stuff in the back end and debug a failed build, and designed a better experience for all of us.

UX and DX are collapsing into one discipline

[00:08:53] This brings us to the core thesis again: UX and DX are collapsing into a single discipline, and here's why. The builder now includes agents acting on behalf of humans like Tori, like me, and designing for agents is designing for this new builder. So remember, the human is who you're actually doing this for. As you think about your developer experience, you really have to take off those blinders about who touches the keyboard and who's going to do what. I believe that in every business everyone's being asked to do more, and it could be you, it could be your teammate. I think eventually we'll all be members of the technical staff, and that's crazy to think of as your new role.

[00:09:35] Agent experience isn't about making the machines happy, but recognizing that when we remove that friction, we're making it better for humans to work alongside them. Structured errors that agents can parse? Great. Now we can have dashboards and we can have continuous loops. Deploy previews can give agents clear pass-fail signals. Humans want that same clarity. They want to know what's broken. This is where the practice gets to designing the system seamlessly. We're not just making APIs agent-friendly. It's really about rethinking your entire stack, unfortunately. The big gap right now is some of the architectural practices, which I'll go into, that you can implement right now to continue to refine that experience, so that for the people behind the keyboards it feels like magic.

The landscape of AI-native tools

[00:10:22] Let's look at the landscape. Y'all have all been here. In two years we've seen an explosion of these tools. Claude from Anthropic, a CLI that tests, writes and commits. Cursor and Windsurf, AI-native IDEs. You have v0, Netlify, Bolt, StackBlitz, Replit, B 64 [?], Railway. I could go on forever naming all these companies that are now pair programming with you. GitHub Copilot now has an agent mode that just fixes your PRs. All of these have a common pattern behind them: intent as input and working software as output.

[00:11:00] But here's the thing: they all need infrastructure that understands the pattern. That's what developer experience has been about, creating that tool set so you can go from idea to production with clarity, scalability, safety and governance. All of the infrastructure has to understand where it's going and what it's doing. The deployment targets, the CI pipelines, the edge networks have to be designed for agents. That's what I've been doing.

From specifications to intent

[00:11:26] So what's actually changing in the software life cycle? Well, we're moving from specifications to intent. Again, this is where we have to rethink how we write specifications. I'm not saying death to specs. In fact, if you have a company like mine that has been around for a minute, this isn't all greenfield technology. You have to work with what you have, but you have to think about that human experience every step of the way, internally and externally, if you're building a development platform like me.

[00:11:53] Traditionally, y'all know how it goes. Development begins with PRDs, GitHub issues, Jira tickets, docs, all written for people to review, to hand off and to decide. AI-native workflows start with prompts and problem descriptions, sketches and references. The input is intent: I want a wellness retreat website with booking, not a 50-page requirements document. That's true for entrepreneurs and new builders, but why is that not true for us? Why don't we build faster? At Netlify we've been dogfooding this experience with what we've released, called Agent Runners. An agent takes the intent, it generates the code, and the output moves into real engineering workflows. It gives you deploy previews, automated tests, production pipelines. What used to take months now takes minutes.

From sequential handoffs to collaboration

[00:12:41] The second shift we see is in the sequential handoff, and everybody's at a different part of their journey here, depending on your systems and how your companies are transforming right now while you're sitting here. Historically it was a relay race. You go to PM, we hand it to design, design makes mock-ups, then engineering, and engineering goes to QA. Maybe it's just a test suite, but it's going through that sequential handoff, then finally to our DevOps homies who are going to deploy. It's weeks, and every step of the way we're losing context every time we pass it.

[00:13:14] Now, with agents, it's become collaborative. We have product teams that are working on prototypes with agents. Designers refine the experience directly in code. They've been doing this for a long time, but now they're doing it all on their own, with nothing but a prompt in front of them. Engineers are validating the guardrails and the architectures, but we have agents in between handling testing and deployment, and everyone participates earlier. It just keeps compressing. But there's a bitter truth here. Where do you start building? What do you build for now, because it's going to get better tomorrow? This is where we have to continuously grow and use our expertise. So maybe AI's taking your job, but we still need you.

From passive CI to autonomous loops

[00:13:52] Third, we moved from passive CI pipelines to autonomous development loops. It wasn't just about creating agents that could talk to each other. It was about the SRE Google handbook dream of 2013: self-healing machines. Guess what? It's actually here, mostly. Agents don't just write the code. They're participating in the entire life cycle. I know some of y'all have been playing with Wiggum loops, and maybe your claw bots are sitting there doing all your work. That is the future. These software factories, and albeit some dark software factories, are the new ways to approach some of these handoffs.

[00:14:28] They generate tests. They detect failing previews, analyze build logs, propose fixes, open PRs. CI/CD becomes a continuous feedback loop. You're going to set it and forget it on some of these. Again, a lot of these tasks happen in the background, and these new builders will never know any of this is happening, so to them and to you, it has to just work. At Netlify we've been using the deploy previews already in our build infrastructure to provide the observability and signals they need. When a build fails, an agent can just pick it up and redo it, and you're not sitting there watching build failures, merge failures, conflict failures. It just works, because this is what is expected. This isn't the future; this is happening right now.

Agent Runners and machine-readable build logs

[00:15:09] I mentioned Agent Runners. What are these Agent Runners, and why did we build them in a certain way? We know that people are utilizing LLMs and models to create and deploy code, and you've got to do it safely and securely. We give agents sandbox environments with full platform access, so they can deploy, configure and iterate, again without the human in the loop on the things they don't need to know. When you're programming now, it's all about intent and not about the chores in between. Humans are here to review the output and guide the process.

[00:15:40] Here's a specific example of a redesigned surface. Our build logs used to be a human-readable narrative. You had an engineer that cared what the log said on the other end. Most of the time you didn't care; you just had an alert that would go off and tell you. But now we need to make them machine readable. They're terrible for machines without a change. So we restructured them to emit structured, machine-readable error codes alongside the human text. We didn't just rip out the human text. We know that everybody's on this journey at a different clip, so we wanted to make sure that our logs would be machine readable and also human readable. Again, DX and UX are now the new AX, and vice versa. They're all the same. An agent can now parse a build failure, identify it as a missing dependency and fix it, all from those build logs.

[00:16:28] But here's the thing: it made it clearer all along the way. Maybe you never want to look at a dashboard again. In fact, I don't. I want it to just magically tell me and fix it. I do still want to be that control freak, because that's what I'm here to do, to ensure that everything runs seamlessly, so I'm not going to set it and forget it. But the error categorization and failure reasons, the AX, at the end of the day improved my experience as well.

Fragmented systems and tribal knowledge

[00:16:56] But here's the problem that most of us face. This is going to be a huge lift, implementing an agent experience in a pretty sophisticated environment. Not many of us here have the opportunity of going greenfield, so we're faced with fragmented systems. I've gotten to work at some of the biggest Ruby shops on the planet, and let me tell you, I have stories, okay? Nobody has good systems. If any of you come and say, "My system's awesome, my architecture is perfect," you're full of it. Come find me. I don't believe you. I will fight you on that. We all have fragmented systems. In fact, unleashing the agents, you might even have more fragmented systems.

[00:17:37] We are introducing these agents to a collection of APIs, microservices and CI pipelines that were built for humans. Stuff is going to break along the way, and sometimes you're going to fall back on that old mentality of, I'll just do an SRE agent. You have to think about this as an orchestrated system where everything observes, learns and knows. Agents struggle with this. They can't see across service boundaries. Every API speaks a different dialect. Critical workflows live in tribal knowledge. I know that some of the stuff in our handoffs is stuck in somebody's head, a Slack thread from 2022, an undocumented Terraform module. Agents can't observe the system, so they can't act intelligently, and all that tribal knowledge doesn't work in an agent environment. That's the fundamental challenge: we can't just bolt agents onto legacy architectures. The architectures must evolve.

From APIs to capabilities

[00:18:34] Some of the first architectural shifts: from APIs to capabilities. Traditionally you would have REST endpoints: POST to a URL, PUT this, GET that. An agent looking at a 200-endpoint API surface has to figure out the right sequence, the right parameters, the right order. Agent-native systems expose intent-level operations: create a site, deploy a repository, provision the edge. Again, this is all in what? Human-readable language, because guess what, that's what your agents are programmed in. That's what LLMs output. So we have to rethink how we configure these API endpoints. At Netlify we're evolving these APIs to support both models: REST for existing integrations, and capability interfaces for agent interactions.

From request-response to events

[00:19:17] The second shift, and this is the big one, is rethinking request-response as event-driven architecture. Traditional APIs are pull based. You send a request, you get a response. Agents have to poll. They should be alive. They guess, they retry, they slurp up that data. I don't care if you use Kafka, Rabbit, Cassandra, pick your poison, but you're going to have to invest in events, and you're going to have to bring events and streaming into your systems, because this is what agents really utilize to learn, create and distribute. AI-native systems expose these events: deploy started, build failed, PR created. When a build fails, the agent doesn't wait, because it's now event based and continuously polling. It just fixes it, it just goes. We're creating those autonomous loops, and this is how we built our build system to just work, because if it doesn't work for any builder, it's not going to work for an engineer or a developer.

Making your architecture legible

[00:20:15] The third step, and I spoke about this a little bit, is making your architecture legible. When you have a fragmented system that isn't greenfield, and we all have one, I've established that distributed systems run on tribal knowledge. One engineer knows service A, another team knows service B, the SRE knows the database, the architect understands the whole system. You have to go talk to them and say, am I going to break something? That does not work. Agents need to have the knowledge.

[00:20:40] At Netlify, what I did is create blueprints: a shared technical knowledge base with descriptions of the core services, cross-service contracts, deployment dependencies and the architectural decisions. These are basically the architectural decision records: why it was all designed that way. So AI coding agents understand the system before they go pounding on it. This is where you spend that time on your specs and really ensure that you have system discoverability. You can do this many ways, but I'm going to tell you: use a markdown file. That's what they're for. Put the context in the right place.

[00:21:13] The goal isn't better documentation. It's ensuring that the agents know where, what and how to change. We've all heard the horror stories of an agent escaping and deleting your database, an agent escaping and giving all your secrets away, an agent escaping and doing what? This is why you have to rethink your architectural boundaries, because you want an agent to go YOLO, but you want it to go YOLO in the right container.

The continuous human-agent loop

[00:21:38] Let's put it all together. We have moved away from static tool chains to agent-orchestrated systems. The software development life cycle becomes a continuous human-agent loop. A PM describes the work in natural language. An agent generates the prototype. Another agent runs the tests. A deployment agent provisions a preview, and observability agents monitor the performance optimization, and then it just works as it suggests improvements. PRs are created, and if they have the right signal, they just go. If they're more spicy, maybe that's where you get an alert. The human stays in the loop, providing judgment, taste and direction, but the loop moves at machine speed. Again, this isn't replacing engineers. It's amplifying everybody's ability to build and advance human progress from their good ideas.

Trust is the foundation

[00:22:32] But all this power comes with serious responsibility, because I'm not going to be in the news. Please don't let me be in the news for agents stealing your damn secrets or breaking something. Every day I wake up and I'm like, is Mythos going to come get me? Security people, come find me. When agents can deploy, you have to ensure that trust isn't optional. It's the foundation. So, three principles at Netlify.

[00:22:59] First, sandboxed execution. Agents run in isolated environments. They are allowed to do only what they are allowed to do. They can't escape. They can't access resources they're not granted. So yes, you have to continue to worry about role-based access, but maybe it's agent-based access. Somebody get your startup pitches out. Second, human in the loop by default. We ensure that the last mile that Rory's talking about is still taken care of. For some of our consumers on the Netlify platform, they may not care about that, but that's why I care about it, and ensure there's an agent experience that includes the human in that thought process, because who doesn't want to share their websites and like them? Everybody wants to show what they build. The agent builds, the human approves.

[00:23:42] Third, audit and rollbacks. Every agent action is logged. This is again where we think about events. Everything that is happening is being logged, and it is learning from it. Every deploy being able to be rolled back instantly is a must, because you are experimenting at the speed of light, so you have to be able to roll back and push code just as easily. Trust is built on that transparency.

The whole company gets to build

[00:24:02] When you do this, agents lower the barrier to building, and the entire company now gets to participate. I told you about Tori, but at Netlify everybody's building: security, IT, finance. In fact, I have to tell them, "No, you can't put that in production. No, you can't use that tool." That's my new job, though. I feel like I'm the AOL hotline for all my technically adjacent friends, who make a website instead of a spreadsheet, and I'm like, maybe it should be a spreadsheet. All of us are dealing with this, and this is why I am trying to really ensure that the right guardrails are in place. To do that, the agent experience has to be seamless, because the people that aren't professionals in this space aren't going to know where they should care about stuff. That's again why we think the developer experience is now the agent experience, so that we as humans can participate.

Summary: taste becomes the scarce resource

[00:24:48] All right, I'm going fast here, so let me summarize. Accept it: the builder persona has changed. Now everybody in this room is empowered and able to create the best experiences for us all globally, to enhance humanity. It is our responsibility to make these systems secure, safe, trusted and guarded. We must evolve legacy systems, and we must do it with trust and safety being foundational. And fourth, this is what you can start shipping tomorrow: start putting in structured errors, event-driven signals and legible architecture. Start taking it from programming and developer speak into intent and human speak, so that you can build the foundation for people to continuously have a great experience, because that is truly what makes the agent experience the only experience.

[00:25:39] Why does this matter? As my CEO at Netlify, Matt Biilmann, who coined agent experience, said: now that anyone can generate code, it's no longer the scarce resource. We have code abundance. You heard in the earlier talks, it's just flowing. The scarce resource becomes taste: knowing what's worth building. Judgment: knowing when to ship and when to hold. Architecture and design systems at scale that are trustworthy, so that humans and agents can collaborate safely.

[00:26:07] This is where it comes full circle. AX didn't just help agents on our platform. It forced us to clarify the architecture and our signals, which made the human engineer more effective too, as we also made the human at the other end able to just share and build. This brings us back to Tori. After hitting the wall of Git, she finally got it. I was like, "Girl, just drag and drop that on Netlify. You've got a website up, and we'll go from there." Because of the agent experience that we put behind the scenes, for somebody that didn't know how to build, didn't know how to configure, didn't know how to test, didn't know how to deploy, but had a vision, we made it possible.

[00:26:47] She called me up and she said, "Girl, I am a developer." And you know what? She is. I'm not going to go crush her. I was like, go on LinkedIn, put massage, put developer, I will endorse you, my friend. It'll make her day. She did it, and here is her vision for the world to see: Luscious Blues Caribbean Massage Retreat, where she is building a community. This is AX in action. This is why we're doing it. We designed for agents, and in doing so we made building possible for massage therapists, CTOs, product developers, designers and anybody else who has a dream, because actually, agent experience is just the human experience.

[00:27:25] When I thought I was doing this for agents, I was really doing it for you. If we take those principles and practices now, we can unlock and unleash the world to continue to create and share our expertise. If you want to learn more, come to axeti.com [?] and share your best practices on how we can make better software for the world. Thanks.

Q&A

[00:27:53] Host: Okay, so we're going to do some questions. But first, just a quick scheduling piece here for anyone who is planning to go to the 11:00 executive session on moving fast in the wrong direction: that is going to be starting in about five minutes, so just be mindful of time on that one. Okay, great stuff. Questions? Oh, we have a lot of them up here. Agents can't be embarrassed, fired or learn from mistakes. How do your humans take on the accountability for agent activities, and do teams work together to own agents' activity, or individuals?

[00:28:24] Dana: I love it. I've always said the practice of DevOps was removing humans from being the gatekeepers, and the whole premise was not to blame the engineer. It's really to blame the robots. So yes, agents can't be embarrassed or fired, but this is about the guardrails. As you're thinking about developing these, you have to realize how much pressure and probably additional responsibility you're putting on your team members, and ensure that you have well-documented practices for what they're responsible for or not. We try to ensure that no big change goes out without a human, but mistakes happen. So again, I think it's about ensuring that you have the right context, the right guardrails, the right permissions to allow people with different skill sets to participate. There's not one type. I come from a blameless culture. At the end of the day, people working with good intent is all that matters, because we're going to make mistakes.

[00:29:19] Host: Sure. You seem to think AI is coming for our jobs.

[00:29:24] Dana: I do.

[00:29:25] Host: And we're going to talk about that tomorrow.

[00:29:27] Dana: Oh, we are.

[00:29:27] Host: Okay. Which role specifically, and why?

[00:29:32] Dana: This is a tough one, and I don't want to get into tomorrow's debate, but I think it's just like what you started off doing. Probably as long ago as I go, I used to just change backup tapes. That was my first tech job, and I thought, well, that's all I get to do. Cool. But look at me now, CTO. It's collapsing. I think that if your job was very narrow, like changing backup tapes, or your job's just doing this one thing, it absolutely isn't anymore. You have to be curious. You have to build. You have to think about the entirety of the process. You're going to be expected to go faster. So when I say it's taking your jobs, it's taking the jobs as defined today, because the expansion of our personas is unwieldy. I don't know about you, but we're all being asked to basically be a software development life cycle of one. So if you have a specialty in a particular role, I definitely think it's migrating and shifting into something new.

[00:30:28] Host: Yeah, and a little plug: we're going to drill into this more tomorrow in a debate, "Is AI taking your job or changing your job?" Everyone now knows what side you're on.

[00:30:37] Dana: That's right.

[00:30:38] Host: Okay. Reviewing autonomous agent outputs sounds boring. Are we all going to become QA?

[00:30:43] Dana: Oh my God. This is what my product managers tell me now. They're like, everybody's just shipping prototypes and it's all over the place, and what do I do? Just sit and look at a million prototypes? I think QA has been dead for a hot minute. I don't think there's been a lot of "hey, all I do is QA testing." It's QA++, and if not, that's interesting. I don't know. Again, come talk to me. I want to hear how you're implementing QA. I think it would be boring. Stuff like this, again, where I was talking about agent experience, this is the boring stuff that you should have an agent do.

[00:31:12] It's funny when everybody's like, wait a minute, you're going to let a coding agent just do your PR checks? I was like, you just submitted a 500-line pull request. There's no way you checked that pull request in five minutes, but I saw you hit submit. Okay, at danazulgithub.com [?]. I know you didn't read that, and I saw that it was from your mobile phone. I'm sorry, I kind of trust the agents more than I trust some of y'all. So automate the crap jobs.

[00:31:41] Host: All right. How are you thinking about fatigue in human-in-the-loop reviews, and preventing people from rubber-stamping outputs?

[00:31:50] Dana: Okay, here's my hot take. Weren't agents and automation supposed to give us our lives back? I thought that was the purpose of developing this technology, so you could go do what you wanted to do. So I'm from the school of thought of: you get all your stuff done, then I'm not going to sit and ask you for more. Somebody asked me, they're like, I got all my stuff done in three days. And I'm like, cool, don't tell anybody what you're doing for the other two days if you're hiking. No, go tell everybody, because I care about commitments.

[00:32:22] I do think change fatigue is real, and I think most of us love what we do and have such a passion for technology that I actually have to go in there and be like, stop, you should stop. But there's this fear of jobs being replaced. There's this fear of, I'm not producing enough. There's this fear of, I'm going to be found out that I'm a fraud and I shouldn't even be here. There's fear everywhere. It's not a race. It's about the quality. So personally, if you are a whip-smart person and you've got your claw bot doing all your bidding, hopefully not in your production systems but in a safe way, and you're out riding your bike, I say go for it. But I don't know, that's the Portland, Oregon in me. I just like to remember that agents are here to serve us, not the other way around.

[00:33:11] Host: I guess that's a nice segue into the next question, about risk. As guardrails are collapsing to make things easier for new builders, how do you think about making sure destructive behaviors, for example deleting a production database, are still guarded?

[00:33:26] Dana: It's interesting, because at Netlify we started with this idea of, cool, we're going to put a harness around agents so people can build. But then we were like, wow, shouldn't we move away from just front-end sites? So we implemented Netlify Database. I recently did this, and it kept me up at night, okay? Being able to just go and prompt a full-stack application with a fully functioning production database. My team were like, "Can you tell our customers not to put production software on there yet?" I was like, "No. If y'all aren't ready, then I'm not ready. Y'all are starting to freak me out."

[00:34:02] But what I've learned is that this is what we've been taught as engineers: protect production. So we slowed it down. In fact, I held the release up so that we could build more confidence in there, to ensure that bad things like that can't happen, and made clear snapshots and recovery paths. You have to continuously think about your disaster recovery, but now you need to do it more amplified. Those principles of the past just have to be applied more, and things that you might have been okay doing because a developer or an SRE was behind the keyboard, you really have to put more pressure on the guardrails, especially when it comes to data being consumed. To me it's not necessarily about the data being up, but because now anybody can build, and y'all have seen the news reels, it's like, what's going in there? I don't want somebody to inadvertently expose something they shouldn't.