# 500 people vibe-coded for 30 days. I was one of them. - Sanja Grbic, Automattic AI Engineer · 2026-07-07 In Automattic's Radical Speed Month, a 30-day experiment where over 500 employees paused roadmap work to ship real projects, product designer Sanja Grbic built three distinct products—a board game session manager, a design system status tracker, and an iOS chat for WooCommerce merchants—demonstrating how AI tools like Claude Code and ContextAIC can transform roles and unlock speed. The first project showed that engineers become enablers when they set up non-engineers for coding success. The second project, completed in two and a half weeks, moved Grbic from designer to design engineer by owning the full build, from proof of concept to deployment. The third project, built in just six days with a fellow designer, proved that shared understanding of AI workflows collapses iteration time. Grbic argues that large organizations can replicate this by providing tool access, finding enablers, creating space for experimentation, and granting agency—shifting human behavior to break out of established habits and release the velocity AI offers. ## Questions this episode answers ### What was Automattic's Radical Speed Month experiment? Automattic's Radical Speed Month was a 30-day experiment where around 500 employees paused their roadmap work, paired up, and were given full autonomy to "ship something real," optionally using AI. About 794 projects were started. Sanja Grbic, a product designer, participated and built three projects, revealing new collaboration dynamics between designers and engineers. [4:22](https://aie.addtry.com/a7f42db2-536a-4aa0-a278-945a23b47c1d?t=262000) ### According to Sanja Grbic, how did Radical Speed Month change the role of engineers? During her first project, a board game session manager built in two hours, Sanja observed that the engineer's greatest impact came from enabling others rather than doing more engineering himself. He set up the project, taught Git basics, and helped the team contribute code. She believes that with AI allowing non-engineers to code, engineers will need to become enablers and teachers, elevating their role from builders to facilitators. [8:47](https://aie.addtry.com/a7f42db2-536a-4aa0-a278-945a23b47c1d?t=527000) ### How did Sanja Grbic's own role evolve during Radical Speed Month? Sanja shifted from a product designer to a design engineer. For her second project, a design system status tracker, she independently handled the entire process—from ideation to deploying on internal and external platforms—using AI tools like Claude Code. She described this as a defining moment: owning the whole workflow without negotiations or handovers, enabled by the experiment's freedom and the company's AI infrastructure. [12:37](https://aie.addtry.com/a7f42db2-536a-4aa0-a278-945a23b47c1d?t=757000) ## Key moments - **[0:00] Welcome** - [0:22] Automattic's Radical Speed Month gave two-person teams full autonomy to build and ship projects for 30 days. - **[0:37] About Automattic** - **[3:08] AI Enablement** - **[4:22] The Experiment** - [4:37] 500 Automattic employees initiated 794 projects during the 30-day Radical Speed Month. - **[5:59] Board Game App** - [5:59] Sanja Grbic's team of four built a board game session manager app in two hours using Claude Code and Nano Banana. - [8:47] An engineer's impact enabling others to code is greater than doing more engineering themselves, says Sanja Grbic. - [9:22] Engineers will need to become enablers and teachers as AI allows non-engineers to contribute code. - **[9:42] Design System** - [10:53] Sanja Grbic built a design system status tracker as a proof of concept in 2.5 weeks, becoming a design engineer. - **[13:23] Merchant Chat** - [13:23] Two designers built an iOS chat for WooCommerce merchants with an AI agent in only six days. - [15:36] Sanja Grbic's design process shifted from starting in Figma to building live prototypes first during Radical Speed Month. - **[16:09] Key Takeaways** - [17:15] Large organizations can unlock AI speed by providing tools, enablers, and giving agency to experiment. ## Speakers - **Sanja Grbic** (guest) ## Topics Vibe Coding ## Mentioned Automattic (company), Claude Code (product), ContextAIC (product), Figma (product), GitHub (product), Jetpack (product), Nano Banana (product), Storybook (product), WooCommerce (product), WordPress.com (product) ## Transcript ### Welcome **Sanja Grbic** [0:02] 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. ### About Automattic **Sanja Grbic** [0:37] 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. ### AI Enablement **Sanja Grbic** [3:21] 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. ### The Experiment **Sanja Grbic** [4:37] 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. ### Board Game App **Sanja Grbic** [5:59] 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. ### Design System **Sanja Grbic** [9:42] 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. ### Merchant Chat **Sanja Grbic** [13:23] 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. ### Key Takeaways **Sanja Grbic** [16:25] 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. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.