500 people vibe-coded for 30 days. I was one of them. - Sanja Grbic, Automattic

Hi there, welcome to my talk. My name is Sanja, and today I'm going to share with you an experiment we did at our company that's somewhat unusual and very exciting. It was a one-month initiative called Radical Speed Month, where two-person teams were given full autonomy to build and ship projects.

I built three projects during this time. I will walk you through them, and we'll talk about the outcomes and learnings for myself as a designer, as well as the system-wide impact this experiment had.

I'll tell you a little bit about Automattic first. We're the company behind several products in the WordPress ecosystem, such as WordPress.com, Jetpack, WooCommerce, as well as many other brands like Tumblr, Beeper, and many more. We are around 1,400 people, and we're fully distributed, which is pretty interesting for also what I'm about to show you.

We're fully distributed and asynchronous, which means that most of our work, our thoughts, our concepts from the past couple of decades are very well documented. I'm a product designer, and I've spent over a decade building software and watching how teams build software.

I've worked for—I've been at Automattic for five years now, on the Jetpack design team. And in the past, I've worked for several companies of different sizes, different types of products, and different team organization configurations. So after all these years, I've not only accumulated experience in designing products, I also have a lot of insight into team dynamics and organizational structures within product teams.

Over the years, the designer role has morphed and evolved a lot. We had—we still have—all of these different types of roles, like web designers, or UX designers, or interaction, or product designers. We've also used many different tools, from the Adobe Suite to Sketch to Figma, and many, many others in addition to those.

And AI is a new tool. It is definitely not built just for designers. It's versatile, so it can be used by many other, many different roles. But the expectation is the same for everyone: it's that it will bring us speed.

And of course, this is why companies are rushing to put it to use. But no matter what role uses AI, this velocity is going to look very different in small teams, like 1 to 3 people that are building new products, let's say a 0 to 1 product, versus large organizations that might have built entire product ecosystems that have software that's anywhere between 5 and 20 years old, and that have more than 1,000 or even thousands of people.

Before I dive into the experiment, I will tell you a little bit about what preceded it in terms of how we use AI at Automattic. We were encouraged to use it, to learn it, and to experiment with AI from the very beginning.

At first, we had access to tools and courses. Then the AI enablement project was initiated, where every single employee goes through a two-week course designed specifically for their role. This is completely immersive, with lectures and focused hands-on time, very, very helpful.

And over time, as AI coding tools got better, everyone was encouraged to get comfortable with contributing in code. And we can thank our systems and operations team for setting up fantastic security and processes, as well as documentation that's good enough that a non-engineer, such as myself, can spin up a working development environment.

And last but not least, an incredibly helpful tool that I use every day for research and planning is ContextAIC. It's an MCP server that gives AI tools access to all of the knowledge and data that we have documented over the years that I previously mentioned.

So back to the experiment. About two months ago, we kicked off this project. The instructions were to pause the roadmap work for 30 days, pair with a partner, and ship something real. We were welcome to use AI, though it wasn't a requirement.

And of course, we couldn't all do this at once. We had to do this in stages, and we had about a third of the company participating in the first round. That's around 500 people that started around 794 projects in these 30 days.

One lucky circumstance for me was that during this month, I was also participating in this two-week in-person AI enablement course. So AI tools played a huge role in what I was able to deliver, and that's why I was building not one, but three different projects.

And when Radical Speed Month started,

I had some knowledge of GitHub. I would review PRs. I had played around with Claude Code. But I have never, until then, actually built and shipped something in code. And I mean at work. Like, I've done a small hobby project here and there, but that's completely—that was a completely different experience.

I'm going to share my personal journey of how my skills and process and collaboration style shifted over the course of the 30 days. And this will also give us insights into how this change can be promoted and implemented at the organizational level for large companies.

So this is the story of the first project I worked on and my first contributions in code. As I mentioned, at the time Radical Speed Month was starting, I was at the in-person AI enablement training. And over there, we did an—as part of the program, we did an exercise where, as a group of four, we had two hours to build something together.

We were two designers that aren't super comfortable in code, an engineer, and a product lead. And we decided to build this board game session manager. We had a board game evening planned that night, so we wanted to create an app that's used to create, view, and join, and manage board game event sessions.

You can see what that looked like. This is what we built in two hours. We built an app

where people can start and stop a session, see what games and spots are available, and even chat with each other. And on top of that, we chose this 16-bit style illustration of our actual office that people found especially appealing.

The most interesting thing about this project isn't what we built. It was how we worked together and leveled up together. At the very beginning, we agreed that we all want to contribute, and we were very lucky that the engineer that was in our group was really, really great at setting us up for success.

He set up the project in GitHub, helped us grasp some basic commands, and helped us understand how Git works. I worked with versioning in the past for, you know, in different situations, but—and I thought I understood Git, but actually I didn't.

I really needed someone to tell me how it works and what are the best ways to set up a project. We were sitting together, we were testing out the app, and we were building it together and dividing the work among us.

So we were all committing code to this project. And since this wasn't this app that we were building, it's not related to any of our existing products, so there were no risks involved, and our focus was on learning, which was really, really, really great.

We only used Claude Code for this purpose. And outside of that, I think the only visual tool used was Nano Banana to create the office illustration.

And the biggest insight, I think, for me from this project was that if you're an engineer, the impact that you have when you enable others may be far greater than the impact of doing more engineering yourself. And for any—this is a great learning for any role.

It can be the same for engineering, or design, or product. Keep in mind that when you're working on a team with mixed abilities, and if you're stronger in a specific skill, make sure that you're helping and enabling each other up.

Because now, with AI, we can all do a little bit of the work that's outside of our domain. And this was the biggest learning for me: that engineers will need to become enablers and teachers. Moving on to the second project I worked on.

This was my main focus for the Radical Speed Month. I paired with an engineer and a design operations person, and our goal, our main goal—we worked on some design system projects together in the past, and here our main goal was to surface relevant and up-to-date design system information to humans and AI tools.

And this problem space is huge. Our design system that we use for our WordPress ecosystem products is open source. It serves many products internally and externally and is always in flux. So the problem space was big, and we saw a lot of opportunities.

So we decided to divide, and each person took on a problem to tackle. And what I proposed, this design system status tracker,

the solution that I proposed raised questions with the engineer around performance, around maintenance, and if we would be able to build it in the first place. But I was kind of empowered by the previous exercise. I was allowed to experiment, so I decided to build the full idea as a proof of concept on my own.

So the discovery portion was three people, but the design and build was just myself. And it took around two and a half weeks to build this. And as I worked on it piece by piece, especially when I reached the point where I had actual live component previews working, I was really mind-blown at what I was able to achieve.

I moved through the project without any

restrictions in mind. I was just trying to push the limits. And the tracker was picking up links from the GitHub repo, from Storybook, from Figma, sorting them according to status, tagging them with the correct library names. Search worked perfectly.

And I was really excited about this product, and I shared it with fellow designers. I iterated a little bit based on the feedback, but everyone was pretty excited. I built the prototype initially as a start, and then I used Figma only later in the process for some visual fine-tuning, some things that I just couldn't explain to Claude Code.

I wanted to deliver an image, and that worked. But the live project was what I was iterating on directly. And the prototype was built within a week, and then it took another week and a half to rebuild it, for some fixes, to set up hosting and deploy it in our internal platform as an internal tool, as well as on an external public-facing site that had a little bit of curated data and information.

And delivering this product was a defining moment for me, where I moved from a designer to a design engineer. This is, of course, enabled by AI, but most of all, it was enabled by the fact that I could own the entire process.

We were within the Radical Speed Month. I was allowed to experiment. I had the agency and made all of the necessary decisions. In large organizations, this is very hard to do. But here, I could just build whatever I thought

was needed, and I didn't have to spend a lot of time in negotiations and handover.

And then that was two and a half weeks, so I kind of had one week left of Radical Speed Month. So I paired with a fellow designer. And here, you'll be able to see the incredible shift in speed and process that happened.

In only six days, we went from zero to, through the entire process, to building an iOS chat for WooCommerce merchants that allows them to answer shoppers in real time, reply from their phone, or even set up AI to answer the questions for them.

And this is a fully working proof of concept that includes authentication through WordPress.com, includes a Jetpack connection. If you use WordPress, you might know what that is. We also built a widget that inherits the site theming, where the site visitors can actually ask the questions, as well as the fully capable AI agent that scans the site for information and answers visitors' questions in real time, and also discerns whether it can answer a question or not.

What was important here was that the alignment and the ideation part was fairly easy. It was fairly easy for us two designers to align and shape the features, because we always have the users in mind. And on the process side, what was interesting is that we started the exploration as a Claude Code project folder, where all of the chats and ideas were recorded into a file system.

And I noticed that that significantly sped up collaboration, as well as build later. And we've continued—I've continued this practice in my daily work. The main artifact we worked on here as well was the prototype. And that's the biggest shift for our process, because normally we would start in Figma and we would work in Figma until we reach very high fidelity.

But here, we had a very good plan, then we

built the

prototype or the product, and then we went back into Figma to just come back to it in a visual sense, to build a mood board and for some UI fine-tuning. And in only 30 days, my process that has been similar for years has completely shifted, and that was true for many other people.

The first project showed me how the engineer's role can be elevated from a builder to an enabler, and this is a skill that I believe will be crucial as more and more people in other roles start working in code.

The second one moved me from a designer to a design engineer. And here, I'm talking about being able to push code to production in a well-established, large system that requires serious onboarding and security practices. All of the company initiatives that I described together gave me the space I needed to experiment and find my own process that works within what we already have established in the company.

And the third project that I shared was just proof that we've unlocked speed, because I already had adjusted my process a little bit, but then we both leveled up together and had a shared understanding on how we can apply the tools so we could also easily meet each other.

If you're in a large organization, try to implement this, even just at your team level. Changing processes or tools in large organizations requires shifting the human behavior behind them. So provide your people with the access to the new tools, find your enablers and champions, create space for experimentation, and give them agency so that they can break out of their habits and unlock the speed that AI tools can bring.

Thank you.