90% of your agents design process is Dead

AAI LABS
Computing/SoftwareSmall Business/StartupsManagementInternet Technology

Transcript

00:00:00There's a layer in the old build process that doesn't exist anymore.
00:00:03And most teams haven't figured out what to replace it with, so they're still running
00:00:06the old one on muscle memory.
00:00:08This week, Jenny Wen published an interview on Lenny's podcast.
00:00:11She's the head of design for Claude at Anthropic, and before that, she was director of design
00:00:16at Figma.
00:00:17In the episode, she talked about how the design process is dead and what is actually replacing
00:00:21it.
00:00:22So we're going to break down what changed, why, and then walk through the exact process
00:00:26that replaced it.
00:00:27To understand what replaced it, you have to understand why it existed.
00:00:31With the old process, you'd define requirements first, then a designer would take those into
00:00:35Figma and make a mock-up of how the app is supposed to look.
00:00:38That Figma file was the hand-off document between what someone wanted and what got built.
00:00:43A front-end engineer would then convert that file into code.
00:00:46Meanwhile, the back-end engineer was building in parallel, because an API spec was defined
00:00:51up front, so both sides could move at the same time and everything connected at the end.
00:00:55Jenny describes this as a process designers treated as ritual.
00:00:58This was the standard across the industry.
00:01:00Most people explaining why it's changing missed the reason it existed in the first place.
00:01:05Simon Willison, a developer who writes one of the most widely read technical blogs in
00:01:09the space, wrote up Jenny's Berlin Talk in January and added the insight her talk implies
00:01:14but doesn't say directly.
00:01:16Building with AI significantly reduces the cost of building the wrong thing.
00:01:19Before AI, a flawed direction meant months of wasted engineering time.
00:01:23A small mistake in the front-end meant 10 times the work during implementation.
00:01:27So teams justified every step.
00:01:28The research, the personas, the user journeys, the wireframes, the spec doc.
00:01:33All of it was protection against building the wrong thing at scale.
00:01:36So what actually changed in the process?
00:01:38Engineering speed changed first.
00:01:40And it changed faster than most people processed.
00:01:42Jenny said a few years ago, 60 to 70% of her time as a designer was spent mocking and prototyping.
00:01:48Now it's 30 to 40%.
00:01:49She didn't decide to work differently.
00:01:51The engineers around her started spinning off multiple agents in parallel and suddenly the
00:01:55bottleneck wasn't engineering anymore.
00:01:58Engineering changed first and design was forced to follow.
00:02:00Vision timelines changed too.
00:02:02Design used to produce 2 to 5 year visions.
00:02:04Now the technology is moving fast enough that 3 to 6 months out is the realistic scope.
00:02:09And it's not necessarily a deck anymore.
00:02:11It's a prototype that points people in a direction.
00:02:13The same thing happened to the translation step.
00:02:15When an agent can take a requirements document and build a working interface, there's no
00:02:19translation layer.
00:02:20The agent writes the code.
00:02:22There's no Figma file to translate because there's never a Figma file.
00:02:25Also if you are enjoying our content, consider pressing the hype button because it helps us
00:02:29create more content like this and reach out to more people.
00:02:33When we get client work, this is the exact shift we've had to make.
00:02:36Now the design process changed but the part that didn't change is requirements.
00:02:40Bad requirements waste the whole build.
00:02:42And most teams skip straight to the spec.
00:02:44That's the wrong order.
00:02:45When you're building a prototype, you don't need a tech stack or an API spec.
00:02:48You need to know enough to build something that looks and feels like the real product
00:02:52so you can put it in front of someone and get a yes or a no.
00:02:56So before you touch the prototype, start with actors.
00:02:58An actor is a person who interacts with the system.
00:03:01A specific person with a specific goal.
00:03:03But who uses it determines what it needs to do.
00:03:06If you have someone who submits content and someone who approves it, those are two different
00:03:10interfaces with two different first screens.
00:03:12Then look at where the views split.
00:03:13At some point in most products, two different actors hit the same URL and see completely
00:03:18different things.
00:03:19An admin sees a management panel.
00:03:21A regular user sees their dashboard.
00:03:22Last thing is constraints.
00:03:24Don't tell the agent what tools to use.
00:03:26Tell it what it can't do and what it can't cost.
00:03:28This would also make the technical decisions much easier later on.
00:03:32Now we implemented all of those specific rules into this create PRD prompt, which basically
00:03:37just interviews you, acts as your PRD interviewer, and interviews you according to the rules,
00:03:42asking you a bunch of different questions.
00:03:44And at the end, you end up with a PRD markdown file, which is going to be used in the later
00:03:48stages of the process.
00:03:49That PRD file is what everything else builds on.
00:03:52So the next step is turning it into structure for the front end.
00:03:55For this, we use this layer prompt, which essentially tells the agent to look at the PRD, which again
00:04:00is not a full PRD with all the technical requirements produced two things.
00:04:04It asks it to produce the pages and the modals that are going to go with your prototype and
00:04:08then the user flows.
00:04:09Now, obviously pages and modals are important for structure so that everything the agent
00:04:14needs to implement in the front end is planned beforehand.
00:04:17We've continued to talk about planning before taking action and why it's so important for
00:04:21the agent and the context window, so we don't need to dive deep into that.
00:04:24But with user flows, it's important to define the actions of each actor.
00:04:28Since we are already focusing on the actors themselves and not the features, it's also
00:04:32important to define the user flows so that the agent can implement the proper interaction
00:04:36states and the proper navigation for the full UI prototype.
00:04:40So we end up with two files where the architecture.md has the pages, the modals, and the user flows
00:04:45that we discussed.
00:04:46After that, we asked it to install a Next.js app because that's the tech stack that we
00:04:50normally use, Next.js with a super base.
00:04:53And this is what it actually came up with.
00:04:55Overall, the design looks really great, but there's a specific reason for that.
00:04:58Also, it wasn't mentioned earlier, but the build was a community platform with channels,
00:05:03products and courses.
00:05:04There are two actors, basically the member and the creator as well, where the creator
00:05:08has all the administrative functionalities such as creating a channel, adding a product
00:05:12or uploading a course, as well as looking at different statistics.
00:05:15In our opinion, for the first prototype that's been made, the design looks really great.
00:05:19But the UX is not that great because normally we don't want a dashboard like this.
00:05:23And this is actually the whole point.
00:05:24That kind of fix used to cost days, here it costs minutes.
00:05:27Because AI can do these modifications really really quickly.
00:05:30And since there's no back end here, it also doesn't have to deal with all that extra stuff,
00:05:34it's just the front end prototype.
00:05:36Now normally AI doesn't really make these good looking websites and interfaces.
00:05:40And the reason this actually looks good is because we use this general purpose front end
00:05:44skill which Anthropic offered in one of their blogs.
00:05:46We highly recommend using this before having your UI implemented.
00:05:50Just save it as a slash command or a skill so that your agent can actually use it.
00:05:53Now if you're working for a client, all you have to do is show them this prototype, which
00:05:57is fully working in terms of functionality with mock data, because it's not going to do
00:06:01a database right now.
00:06:02You can show this to your client, get their approval and if not, make the changes and then
00:06:06proceed with the rest of the build.
00:06:08These task lists are one of the reasons we can now really ask these agents to make fully
00:06:12functioning prototypes.
00:06:14It's because of these task lists, because of task persistence and because everything
00:06:17is structured.
00:06:18This is why making that architecture.md file was really important because it allows the
00:06:23agent to build a perfectly optimized task list so that it doesn't hallucinate.
00:06:28After that we move to the back end implementation.
00:06:30Now normally there are two things you could do.
00:06:32You could keep Next.js, keep the front end separate in Next.js and then implement the
00:06:36back end as a separate Python service.
00:06:39But that depends on the type of application that you're working with.
00:06:42For most of the projects that you guys would probably build, Next.js is going to be fine.
00:06:46You specifically need a separate Python back end when you need these extensive libraries
00:06:50that aren't available in Next.js or if you need some serious background job orchestration
00:06:55to optimize your site or its functions.
00:06:57In that case, you might need to have a separate back end.
00:06:59Otherwise the Next.js back end is pretty much all you're going to need.
00:07:03Before we touch the back end, we need to know what the front end actually needs from it.
00:07:07So we had the agent look at the front end code, the PRD and the architecture file and write
00:07:11an API spec.
00:07:12After that, we asked it to use the three documents to create the full super base schema because
00:07:17we're using a super base plus Next.js as the front end.
00:07:20It basically needs to create the schemas that are going to house the data for the app.
00:07:25Normally if you ask your agent, it's going to tell you to go ahead, get your API keys
00:07:28from the database and manually paste SQL queries to create the tables.
00:07:33But instead of that, you should be using the super base MCP.
00:07:36Always try to use an MCP for whatever service you're working with because it automates a
00:07:40lot of the stuff.
00:07:41For example, we didn't even have to look at the projects here.
00:07:43It automatically created the project, ran the queries for the schema and automatically ran
00:07:48the migrations.
00:07:49So we basically had to do nothing.
00:07:51After your database has been set up, you're going to connect the front end to the database.
00:07:55Now again, there is a clear distinction here.
00:07:57You don't have to connect the back end to the database because it's already integrated in
00:08:00the front end.
00:08:01The front end directly talks with the database, making the integration and the overall complexity
00:08:06much easier.
00:08:07Now we are actually partnered with warp for this video and they recently released OZ, which
00:08:11is an orchestration platform for different cloud agents.
00:08:14These cloud agents are handy for tasks that you just want to delegate and you know that
00:08:19the agent would be able to complete on its own.
00:08:21So up till now, the agent had connected the front end to the database and the app was basically
00:08:26working according to that.
00:08:27But to add stuff like payment processing, new notifications, rate limiting, or analytics
00:08:32on the site, we actually need a dedicated backend API layer so that we can integrate all of that.
00:08:37For that, we created an environment using OZ and ran a cloud agent, which asked it to build
00:08:41that dedicated backend layer.
00:08:43And after about 15 minutes, it was done with the task and the whole thing was ready.
00:08:47To actually make this functional and start accepting users, all that was left now was
00:08:51just Google authentication, Stripe integration, and a few small details we needed to fix.
00:08:56Now you've seen the full process and the prompts have been right there on screen.
00:09:00But if you want all of these prompts as a step-by-step workflow that you can just follow for your
00:09:04own projects, we're putting that in AI Labs Pro.
00:09:06For those who don't know, it's our community where you get ready to use templates you can
00:09:10plug directly into your projects for this video and all previous ones.
00:09:14If you've found value in what we do and want to support the channel, this is the best way
00:09:18to do it.
00:09:19The link's in the description.
00:09:20That brings us to the end of this video.
00:09:22If you'd like to support the channel and help us keep making videos like this, you can do
00:09:26so by using the super thanks button below.
00:09:28As always, thank you for watching and I'll see you in the next one.

Key Takeaway

AI has inverted the product development lifecycle by making engineering faster than design, shifting the designer's role from creating static mocks to orchestrating functional prototypes and defining user-centric constraints.

Highlights

The traditional design-to-engineering handoff process is becoming obsolete due to the speed of AI-assisted development.

Building with AI significantly reduces the 'cost of building the wrong thing,' allowing teams to skip heavy upfront documentation like wireframes and personas.

The focus of design has shifted from creating static Figma mocks to developing functional, high-fidelity prototypes in minutes.

Modern product requirements should prioritize 'Actors' (specific users with goals) and 'Constraints' over rigid technical specs.

Tools like Next.js, Superbase, and Model Context Protocol (MCP) allow agents to automate database setup and backend integration seamlessly.

A dedicated backend API layer is still necessary for complex tasks like payment processing, rate limiting, and advanced analytics.

Timeline

The Death of the Traditional Design Ritual

The speaker introduces an interview with Jenny Wen, Head of Design at Anthropic, who argues that the classic industry design process is effectively dead. In the past, designers followed a 'ritual' of creating extensive Figma mock-ups that served as a handoff document for engineers to translate into code. This slow process was a defense mechanism against the high cost of engineering mistakes, which could waste months of work if the direction was flawed. However, AI has fundamentally changed this math by drastically reducing the time and cost required to pivot or fix errors. Consequently, the heavy reliance on personas, wireframes, and detailed spec docs is no longer justifiable in a high-speed AI environment.

How Engineering Speed Forced Design to Evolve

Engineering velocity has increased so rapidly that design has been forced to follow suit to avoid becoming a bottleneck. Jenny Wen notes that her time spent on mocking and prototyping has dropped from 70% to roughly 30% because AI agents can now build interfaces directly from requirements. Long-term vision timelines have also shrunk from five-year plans to realistic three-to-six-month scopes due to the pace of technological change. The traditional translation layer—the Figma file—is disappearing because agents can generate working code without needing a static visual intermediary. This shift means the prototype itself is becoming the primary tool for direction rather than a slide deck or a design file.

Redefining Requirements: Actors and Constraints

While the build process has changed, the importance of solid requirements remains constant, though the method of defining them has evolved. Instead of jumping straight to technical specs, the speaker recommends starting with 'Actors'—specific people with specific goals who interact with the system. Defining these roles helps determine how many different interfaces are needed, such as a creator dashboard versus a member view. Constraints should also be clearly defined, telling the AI agent what it cannot do or what it cannot cost rather than dictating specific tools. This section concludes with the introduction of a PRD (Product Requirements Document) prompt that interviews the user to generate a structured markdown file.

From Architecture to Functional UI Prototypes

The workflow moves from the PRD to creating an architecture file that outlines pages, modals, and user flows to provide context for the AI agent. By planning these elements beforehand, the agent can implement proper interaction states and navigation without 'hallucinating' or losing focus. The speaker demonstrates this by building a community platform prototype using Next.js and a specialized front-end 'skill' to ensure high-quality visual design. This prototype is functional enough to show to clients for immediate feedback, allowing for changes that used to take days to be completed in minutes. The use of structured task lists and persistent context is highlighted as the key to making these automated builds successful.

Backend Automation and Cloud Agent Integration

The final phase of the process covers backend implementation and the use of Model Context Protocol (MCP) to automate database management. While Next.js handles most needs, a separate Python backend is suggested for heavy orchestration or specific libraries not available in JavaScript. The speaker shows how the Superbase MCP can automatically create projects and run migrations without manual SQL entry, further reducing friction. To add professional features like Stripe payments and Google authentication, they utilize cloud agents via the OZ orchestration platform. The video ends by emphasizing that these tools allow a single person to build fully functional, production-ready applications at unprecedented speeds.

Community Posts

View all posts