The New AI Workflows

Hey everybody. Today I want to talk about new emerging AI workflows that LLMs are powering to let you work differently and really do more with less. But first, who am I? I'm the co-founder and CEO of Builder.io. I've also made some cool open source projects like Mitosis, the Crossframer compiler, and AI projects like GPT Crawler. You also may have seen me as Steve8708 on a bunch of different platforms like YouTube.

So here's the core thing I want to talk about. As someone who hires a lot of engineers, I can very much vouch for this. We hire engineers to solve problems and build great products, not specifically for writing code. Now that LLMs can do a lot of code writing, I prefer engineers I hire to use them as efficiently as possible. If the LLM will generate slop, then hand code. But if the LLM can generate code that does good and work faster so we can deliver to our customers faster, that is a huge benefit. And having trained people who are effective at using LLMs who understand the underlying technology is what I care about most. And when we hire, we try to assess who is most effective at these things.

So if you think your job is just writing code, you might panic and be like, oh no, AI is coming for me. The reality is the total opposite. Each engineer we hire is more capable than in the past, so they have more value to us than in the past. But I don't care who's writing the code as long as it's good code and solves our customer problems. And so that changes kind of how you think about being an engineer a bit. Now, if you've ever been an engineering manager, you know that as a manager, you don't usually write much code too. You manage developers and they write the code. That is a natural part of many people's careers. And I'm finding that accelerating because when you can have a team of AI agents writing code for you, if you can oversee that the code is good, similar to overseeing that your engineers who are your employees' code is good, you can be super effective. And while a lot of great managers write code, the best ones certainly don't write the majority of the code for their team. But the mindset applies the same. The same way you work with engineers on an engineering team is almost identical to how you work with engineers as agents, or AI agents who are writing code for you. And when hiring developers, I really care to see people who can treat the AI like an employee and work with it. The same skills apply, the same ways that you communicate, the same ways that you give guidance, clarify requirements, check in and calibrate. It all applies the same. So whether you aspire to be an engineering manager or not, you're going to need those skills. Now, there's multiple ways to handle using AI to write code.

Many people are familiar with what you could call a foreground agent or synchronous work where you're typing into cursor or copilot or cloud code what you want to build and you watch it kind of build it out or fix the bug in real-time. Now there's an emerging thing called background agents. As the AI gets more reliable at writing good quality code, testing its own work and validating that it's done it correctly, we can delegate more agentic work to be async, like assigning tickets, or kick off multiple of these in parallel. There's a lot of great benefits here, but there can be some pitfalls as well. Cover both in a demo in a second and talk about the trade-offs and how you can jump from one to the other too.

The important thing to recognize is LLMs don't only make you more productive as a developer. They make other people like the designers and product managers you work with competent at working with code. That could be as simple as when the PM asks you a question, you can actually tell them to go ask the code themselves. Or if a designer keeps sending you these designs that really don't make sense, they're complicated to, they're just complicated to implement, you can actually have your designer work on top of the code directly. That way when something's handed to you, if you're using a good agent that's informed to use the design system and coding practices correctly, you're actually getting 80% complete front-ends and you can work on the tough parts, the back-ends, the implementation and business logic.

By combining these things, you can open up whole new workflows. What I've seen in our team and other teams is some new patterns that didn't exist before. In the past, you had the big waterfall where you had to have a hundred meetings and a hundred memos and blah, blah, blah before anything gets built. Now we've seen people can produce and ship a lot faster. If engineering has an idea or sees customer feedback, you yourself as a team of one could take a first iteration at making an improvement to the product. With the right AI, UIs can be generated with the right best practices. You can make sure the implementation works great and if product or design have feedback, they can jump into the code after you and clean up the pixels, add the tracking or even just ask the questions that they have. And you can ship so much faster without blocking and waiting and waterfall. You can move more agile than ever. Similarly, if you've got parts of a product that are just kind of ugly and ignored, similarly if you've got parts of your product that are just kind of ugly and designs want it to update forever, they don't have to make designs that nobody's going to ever work on. They could just jump into the code, improve the UX and send a pull request. Engineering doesn't have to chase these red lines and all the ways behind a designer. They can just review the code, comment on an agent if they want the code modified or cleaned up and merge. And similarly, PMs don't have to send you these long memos and requirements docs. It can send you a prototype that has some of the basic pieces working and has some clear gaps where we need to finally implement. Design can work over the top and polish the UI while engineering in parallel works on the final implementation. We've seen this drastically improve the speed at which teams could execute while maintaining the same kind of quality bar and requirements around the code.

It can send you a prototype that has some of the basic pieces working and has some clear gaps where we need to finally implement. Design can work over the top and polish the UI while engineering in parallel works on the final implementation. We've seen this drastically improve the speed at which teams could execute while maintaining the same kind of quality bar and requirements around the code.

And in general, we find these teams have a lot more fun. It's just fun to ship things as approved products rather than be bogged down in bureaucracy and waterfall. The best part is you have a lot of different options of products you can use. For secret agents, async agents, agents your non-developers can use, even some that can integrate with your actual code, and agents to help with code review.

Now I'm going to demo some of these things. I'm going to use Builder.io because I know that product really well. I built the thing. But just keep in mind, you can use a wealth of other products for a lot of these different things and ultimately pick your own favorite combination of what works best for you. So that said, let's demo some of these workflows. I think it'll be fun. So here I'm over in the Builder.io dashboard and this is designed to feel like a loveable or some kind of easy AI app builder. But under the code, these are all existing real code repositories. You pull in from your GitHub or Enterprise Azure DevOps or whatever you have.

You pull in from your GitHub or Enterprise Azure DevOps or whatever you have. For any of these we can just kick off a branch and start making edits and sending pull requests. But first I want to kick off an async agent. So as you see, there's Slack and Jira icons. That means we can just tag the Builder agent in Slack or we can assign the Builder agent a Jira ticket. Whether you're a PM, designer, or developer, you probably have a lot of tickets.

One really cool thing is if you're a developer getting assigned tickets, one thing you could do is just reassign it. Let the first iteration be taken over by the Builder bot. Alternatively, you could also just tag the bot in the comments too and say, hey, do this for me. You could assign a whole set of tickets all at once, maybe a whole chunkier backlog that nobody wants to deal with anyway, and let the agent take a first pass at the implementation.

You will get a comment that the agent is working on it and these agents can be very much customized to follow all your best practices. By default, of course, they also look at the existing code and as close as possible replicate the patterns that they already see as well. So let's let this background agent run for a minute and let's do some synchronous work. So back in Builder, let's say I want to edit this Builder Academy project. I'll just click plus new branch to create a new branch, and we'll pop into the visual editing environment.

So here you've got a whole code mode where you can go in and edit the code. You can spawn all this stuff locally so it's actually directly editing your local codebase too. There's a VS Code integration, a CLI, and a cursor plugin.

Let's just focus on the AI side first. The cool thing is because this can run in the browser or in a desktop app, you can actually delegate this to your non-development teammates too. Anybody can come in here and prompt and you can hand off to other teammates as well.

I'll show you what I mean. Let's start very simple. And I notice this academy site, which is our actual like learning management system. This is where you can take courses and be certified in knowing how to use Builder. It doesn't have a Contact Us page, so I'll just go in here and just say add a Contact Us page.

Under the hood, the agent is doing what you're used to with tools like Cloud Code or Cursor. It's looking at how the code works. It knows for a Contact Us page, you probably need a form. We probably need an API. It'll figure out how we do those things, create a to-do list, and get working.

I'm currently using Cloud Haiku 4.5. It works really fast, which is really fun. It keeps you in flow better. And we are done.

Let's look at our Contact Us page. It looks like I found a runtime error. I just click the attempt to fix button. It'll resolve itself here. That's a nice thing about having a browser integrated as it can detect those errors and then just fix them. Great. Runtime error solved. We've got our Contact Us page.

Now here's the interesting thing. So far, this workflow hasn't been that different from what you'd use for Cursor. This is synchronous agents. This should be not too crazy. Now, what's cool though is when we actually have the context of the UI here, we can do some interesting things. So the cool thing about having the actual visualization here built in is even though we're editing our own code, either locally or in the cloud, I can just hop to design mode and get a full Figma-grade editor for this. So maybe I want to make this page wider.

Maybe I want to take this section and move it side by side with the form, change the layout, change the column width. I prefer these to have a white background color. I just think it looks better. Bam. And I don't need a subject field. And let's use some natural language here too. We can also say, add an FAQ accordion below this and fire it off.

Whether I prefer to use Figma-style UI editing for that kind of precision edit I want of my local code, or I want to send this link to our designer and say, Hey, I did a first pass at some of the implementation here, but mine is a little ugly. Designer, can you come in and make it look better? You get this really fast handoffs where people can pick up where each other left off and not do the traditional thing, which is like, Hey, designer, can you take a screenshot of this and then go in Figma and redesign it, then I'll look at it and have to re-implement it, but that sucks.

Let's just hand off the code, let the designer work and bring it back. So cool. I have my updated page layout. I've got my FAQ accordion. This is great. Now if you find a designer still would prefer to work in Figma, which many do, there's a solution for this as well. We can go back to design mode. We can select whatever we want, like maybe this section, and then we can export it to Figma. Your designer in Figma can then just open up the builder plugin, go to the import tab and paste. And there we go. Here's our design. Now we can start making edits. For example, maybe we want to dark modify this form. So let's choose a dark fill. Let's make the text white. Ba-bam. Ba-bam. Let's make these inputs dark as well. Maybe a little bit lighter and give them a stroke that's not quite light. Okay. Now when I'm happy, I can just go back to the plugin and I can export this.

I can jump back into builder, paste and say apply my design updates and let it run. So you can do a pretty seamless handoff to go from code to design and back or bring in that new designs as well. Importantly, a lot of this work doesn't even have to be done by you, a developer.

So now we're updating the code. Great. And cool. I've got my updated design. It looks like the inputs work as expected. The form still works as expected with validation. This is great. When we have what we like, we can just fire off this send PR.

All right. PR was created. Let's open it up. Now I've got a nice title and description outlining the changes. We can check out the files view and this is the first time we're going to actually go from foreground agent to background agent. So here, whether you send this as a developer or your designer or PM or whoever sends the pull request.

So here, whether you send this as a developer or your designer or PM or whoever sends the pull request. Now people have feedback. They could certainly ask it to you, but let's say your designers have the PR, like they're not going to know how to update code to change naming or structure or whatever. The cool part is if we want to change anything, like maybe let's take this form section, we can just go in and tag the builder IO bots and just say whatever you want to do, like move this form to a new file and let it rip. The cool part is you can collaborate with a bot like a human and leave all the feedback you want and then the bot will start taking over and doing it.

So this is the bot working in the background. It can work on many of these comments in parallel and here it's already responded. I'll get right back to work and it'll push up changes as they're ready. Now while that's running, because this is in background mode, I can go do other things. In my case, why don't we check on that ticket that we started. So here we had this weather dashboard ticket and we can see, great, a few minutes ago, the builder bot finished the work. So while I was doing all that other synchronous work, the bot was doing a bunch of work for me in the background directly from the ticket that had all the specifications, could have attached files, could link to other things, which you can use FCP servers to pull that context.

So I'll just open up this. So this was a project working on a totally different application. So what I asked for was a weather dashboard, and it's inside this application, which is using the Cloudscape design system. It's AWS's design system. So let's go over and I think in dashboards, cool, we should see a weather dashboard. Great. Let's see if it was able to one shot this. Cool. So it looks pretty good so far. Let's close this out. The ticket asked for to be able to do a type of head search. So San Francisco location. Great. This is all using Cloudscape design system. It looks good. We've got the current weather overcast. That sounds right for San Francisco. We've got all of our Cloudscape charts and graphs.

Great. This is a great first pass, but I do have some feedback. We could jump into design mode, do stuff like that or use natural language. One thing I like to do is just say, hey, make this seven day forecast a side squat. I'll say also give me an option to change between Fahrenheit and Celsius. As you can see, these typos don't matter. The LLM can generally figure this stuff out. And the important part to understand here is now we've gone from async to synchronous. We've gone background to foreground. We do all the foreground work that we want to do here.

Great. We've got our updates. Let's search San Francisco again. And all right. We've got our side scroll. We've got Fahrenheit, Celsius toggles. Now let's take a minute to recap. Here we took a couple of approaches to go from being the direct code writer to managed code writers. We delegated a ticket to the AI and then picked up where we left off and refined. We did some synchronous agentic work.

From the pull request, did some asynchronous work as well and talked about a variety of ways of collaborating with your co-workers like designers and PMs. You can mix and match these techniques as much as you want. You can explore a huge variety of products that can help solve these things. Either way, I hope you take seriously exploring new ways of working. While I know you're fully capable of writing the code by hand, you're getting more and more tools and now more and more workflows to work with to collaborate and build products faster as a team. Thanks so much for watching this.