I even got some time to work on an app I’ve wanted to build for years, a kayak safety app. I was able to use Stitch to lay out the frontend and get advice on color palettes. I then used AI Studio to hook the design up to several US government APIs that provide data on marine weather, tides, and currents. I finished a prototype of my app and have been gathering feedback from friends who also kayak the waters of the Salish Sea. Overall, I left the event on a high, smiling, and very grateful for the opportunity to help folks build their ideas and to spend a few minutes on one of my own.

Definitions

When I told my friends I was going to Chicago for a builder event, they asked me “What’s a builder? Is that like a dev?” I gave them the answer I’ve been using internally for the last few months:

“A builder is someone who relies on AI to create an app, agent, or service.”

I like this definition because it makes it clear that AI is empowering folks to do things they couldn’t do before. This definition also helps differentiate builders from developers, without making them into two completely separate groups. In reality, some people can be both depending on context.

Developers vs Builders

Sometimes I get asked “Are developers builders?” And my answer is the completely unsatisfying “it depends.” These days most developers use AI for some of the toil of building software. And for a lot of developers, there are contexts where we are reliant on AI.

For example, I’m not a great frontend developer. I’ve tried to learn, but it isn’t one of my strengths. AI enables me to do the basics of creating UIs. So when it comes to frontend, I’m a builder. Several of our build day attendees were also traditional developers who were empowered to do things outside their normal skill set by AI.

Emerging Segment of Non-Coder Builders

Personally, I’m excited by the non-coder builders. I love seeing how experts in their field can make their ideas come alive with AI. I want to see the kinds of apps that marketers, authors, lawyers, dentists, real estate agents, and teachers build. I want to see how they can combine their expertise with AI tools to build something that helps them out every day.

That was the magic of our build day for me. Folks with no coding experience but expertise and an idea were able to spend a day with us and build apps that taught me interesting things about economics and body mechanics. Attendees were able to get advice from others and deploy something that they found valuable and interesting. They were surprised at what they could do with Google’s builder stack. And I was happy to teach them some basics of software to help them on their journey.

The Builder Revolution

I believe that the builder revolution, where anyone with deep domain knowledge, passion, and some tenacity can prototype an app, is already well underway. But I’m curious what others think. Do you have a definition of builder that you like? Do you have any good builder stories you want to share? Or are you waiting for a specific feature or a better model before you recommend your non-coder friends go build their first app? Let me know in the comments.

“Stop prompting directly, write prompts or code that writes your prompts, and then loop over that code!”

This sounds like either programming or meta-programming to me, but sure, let’s take loop engineering for a test drive with ping-pong pairing.

Ping-pong pairing is a technique I learned years ago to motivate myself to get through programming tasks I found undesirable or technically daunting. It is a programming technique, but it is easiest if you think of it as a game.

The rules are simple: Player One and Player Two agree on the larger task. Player One writes a minimal failing test and commits. Player Two makes the test pass, writes another failing test, and commits. Then it is Player One’s turn again. They make the failing test pass, do any necessary refactoring, and then write a failing test. You repeat those steps until both players agree the task is done.

Sounds like a loop, so let’s do some loop engineering.

Ping Pong Pairing Agent Skill

Step one was to set up the loop. I implemented my loop as an agent skill so I could use it across multiple projects. I built the agent skill with Antigravity, telling it directly that I wanted to write a new skill. Because the “game” of ping-pong pairing involves two separate people, I chose to recreate that dynamic using independent subagents. I prompted Antigravity to create the skill, directing it to use a subagent for each of the two players. I also clearly explained the “rules” of the “game” in my initial prompt.

While I often use one-shot prompts during demos, in reality, my typical workflow involves several back-and-forth steps refining the application I’m building. Writing this skill was no exception. The initial version of the skill planned out what each subagent would do on each turn ahead of time, which isn’t the spirit of the exercise. So I clarified that it shouldn’t plan everything in advance.

You can see the skill created here: GitHub. Note, this was a fun exercise and is not necessarily a recommended way to use an AI coding tool.

Testing the skill

Once I had the skill written I wanted to test it. My go-to app for learning new languages and frameworks is the game Mastermind. And a turn-based game seemed like the perfect way to test a turn-based approach to coding. I sent Antigravity off to the races with this prompt:

Use the ping-pong pairing skill to build the game mastermind. The implementation plan should contain the rules of the game, information on the tech stack, but not specific tasks for each subagent. Let each subagent determine the right thing to do next at the start of each turn based on the rules of the game and the tech stack.

I approved a few initial steps and then walked away. 10 minutes later, I came back to a working Mastermind game and this commit history:

ONE RED: Add failing test for initializing Mastermind game instance with a secret code
TWO GREEN: Implement Mastermind game initialization and getSecretCode
TWO RED: Add test for validating secret code length
ONE GREEN: Implement validation for secret code length
ONE RED: Add failing test for validating that secret code only contains valid colors
TWO GREEN: Implement validation for secret code colors
TWO RED: Failing test for game guess exact match feedback
ONE GREEN: Implement guess method for exact match feedback
ONE RED: Add test for guessing with correct colors in incorrect positions (white pegs)
TWO GREEN: Implement white pegs feedback scoring logic
TWO RED: Add failing test for remaining turns tracking
ONE GREEN: Implement turn tracking and remaining turns decrementation
ONE RED: Add failing test for guess length validation and turn tracking behavior
TWO GREEN: Implement guess length validation
TWO RED: Add failing test for guess validation with invalid colors
ONE GREEN: Implement validation for guess colors
ONE RED: Add failing test checking that the game is over and won when a guess matches the secret code exactly
TWO GREEN: Implement game over and win status tracking
TWO RED: Add failing test for guessing after game is over
ONE GREEN: Prevent guesses when game is over
ONE RED: Add failing test for guess history recording
TWO GREEN: Implement guess history tracking
TWO RED: Failing test for 10 incorrect guesses resulting in game over
ONE GREEN: Implement turn limit check for game over
Refactor: Remove unused @ts-expect-error annotations from tests
Add interactive Command Line Interface entrypoint in src/index.ts
ONE RED: Add test for secret code color normalization
TWO GREEN: Implement secret code case normalization
TWO RED: Add test for guess color normalization
ONE GREEN: Implement guess color normalization
ONE GREEN: Add duplicate matching edge case tests

The game wasn’t beautiful, and there were some clunky aspects to the UX, but that’s to be expected of a one-shot approach with such a short prompt. Especially when that one-shot prompt explicitly told the AI to ignore aspects of its default workflow, such as a planning stage, that are designed to improve the final application.

So what was the point?

The point of doing this wasn’t to build a just ok Mastermind game. The point also wasn’t to use ping-pong pairing in my regular AI-Assisted Coding workflow.

The point was to experiment with an AI-driven dev loop that required multiple subagents to act independently while passing information (e.g., failing tests) between them at key points in the cycle.

It was also a fast and amusing way for me to get more comfortable with setting up loops and subagents inside Antigravity. The next agent team I set up will definitely be more sophisticated. I want to experiment not just with multiple code-generation agents, but also with test and eval agents, security review agents, and more. There’s a lot of potential here, but sometimes the easiest way to get started is to take something familiar and do a new thing with it.

Those practices shaped how I approach software engineering. They shaped how I approach management. I still default to TDD with small commits 20 years later if I get a choice. But most interesting to me is that all those XP practices have made me a successful user of AI in software development as well.

Always Be Pairing

One of my dev jobs was on a team that was 100% pair programming. We started the day with a standup where we split into pairs, picked a story card from the board, and then spent our day working at one computer with two keyboards and two mice. At first, it was hard. It felt awkward and slow. I found being shoulder to shoulder with another person all day exhausting. But with practice, I learned. I learned to communicate with precision, not phrases like “you know” and “stuff”. I learned to be a useful navigator, pointing out our errors and planning our next step when I wasn’t the one typing. I learned to enjoy pairing as a default practice, rather than as a tool to use only when you have a tricky bug.

When I started using AI for coding, I quickly fell back into my old pairing patterns. I’ve customized my AI tools to use pair-programming principles. We discuss changes bit by bit before writing any code. I discuss design decisions with the AI. I ask it for feedback and ask it to point out errors not only in my code but also in my design. I find that working with AI as a pair-programming partner, rather than fully delegating tasks to it, improves the quality of the results. It also ensures that I understand the code’s design and the decisions that went into choosing that design.

Small Stories, Small PRs

A habit my early mentors taught me was to work in very small chunks. The first time I submitted a 1,500-line pull request that I’d spent 2 weeks on, I was politely but forcefully instructed never to do that again. I was taught to break down tasks into chunks that could be completed and merged in 1-2 days. If I objected and said something couldn’t be broken down into pieces that small, I was told, less politely, that I was incorrect. And when I combined feature work and a refactor into a single PR, I was told that no one would code-review it until I separated them. All this feedback turned me into someone who is uncomfortable keeping a branch alive for more than a few hours.

When I started writing code with AI, it was natural to work in small stories and small PRs. I break features into pieces I can finish in a few hours to a day. Each task is a new conversation and a new branch. I have some customizations in my setup that direct the AI to work only on the current feature. If it identifies additional work along the way, I’ve told it to put those ideas into a to-do list. Once the feature we’re focused on is working, I submit the PR. I also sometimes start a new conversation to critique the code and identify issues, such as incorrect comments, before I do a human review.

Test Driven Development

One of the most important things I took from my time in the Ruby community was the culture of test-driven development and testing as a critical component of software development. I was taught a particularly strict form of TDD that only tested behavior, forgoing mocks and assertions on what methods were called. I still do a tiny involuntary shudder when I see tests that assert new was called.

When I work with an AI, I find I’m most successful when I use a modified TDD approach. The biggest difference is that instead of starting each step with a unit test describing the end state, I start each step with a prompt describing the end state. The prompts are usually closer to functional tests than unit tests, but they aren’t at the level of an entire spec. And just like the tests I write, my prompts don’t describe implementation details; instead, they describe the user-facing behavior.

Self Documenting Code

One of the things I found hardest to adopt in XP was the approach of self documenting code. When my mentors said self-documenting code,, they didn’t mean header blocks on methods picked up by a documentation generation tool. They meant code that was written so clearly that those blocks were largely unnecessary. It took me years to habitually use plural variable names for collections and the singular version of that name for individuals in that collection. And I remember some debates during code review about the order of clauses in conditionals. Do you start with the positive condition or the more common condition? Are postfix conditionals too confusing?

Now that I’m writing with AI, I’m grateful I developed early habits of constantly reviewing code with an eye for readability. Readable code is easier for the AI to understand, and it’s easier for me to review the diffs for the AI-generated code. I have made one adjustment to better document my code for AI. I have a generated file in each directory labeled something like context.md that my AI assistant can use for context.

Conclusion

If you were an XPer back in the early 2000s, what practices have you found most helpful as we adopt AI as part of our coding toolbox?

The simple truth is that I don’t know what the future of DevRel is. I have some ideas, but we’re all on an AI journey together, and sometimes it seems like the tech changes every day. In that world I’m a bit suspicious of anyone who claims to know the future, unless they have a time machine. But I am comfortable talking about trends that I’m seeing in how I personally work and what I’m hearing from the folks I talk to. But upfront caveat, I can guarantee my sample is biased. I’d love to know where others have experiences that differ.

The Tale of the Reluctant Gopher

One thing I’m noticing in my own work is that AI-assisted development makes it much easier to try new things and experiment with new tools, languages, and frameworks. I’m seeing this in my own workflows. I put off learning Go (Golang) for years. While I value all the strengths of the language, I didn’t have any problems where I absolutely, 100% needed the power of Go, so I hadn’t been able to justify to myself dedicating the time to learn the language and become a Gopher.

Now, writing Go is as easy as writing any other language, so I’m preferentially picking Go for new projects. Why not? I can get high performance, native concurrency, and high readability with no additional friction for me. Additionally, because I find Go very readable I’m still comfortable doing code reviews on the code I generate for side projects. Are my code reviews as detailed as someone who knows the language well? Probably not. But also, the code that’s being generated isn’t a mystery to me.

Goals Not Syntax

Another thing I’m noticing in myself and in a lot of demos I’m seeing from my colleagues, is that the way we’re working with AI is changing. When I started using AI for development assistance I was asking questions about the argument order of specific methods in LangChain and what values an enum could have in a library I was trying to integrate into a demo.

This week I asked Gemini how to fix the images on social media links to my blog. I didn’t ask about X/Twitter cards or Open Graph or SEO. I just asked how to make the links to my blog look better. It was able to identify the issue and fix it. A lot of folks refer to this change in prompting style as “Spec-Driven Development”, but I’m still not sure how I feel about that term. I did end up having to nudge Gemini to use the Jekyll SEO Tag plugin rather than just adding the necessary fields itself. But that’s my design preference to use a maintained library rather than building integrations from scratch. The generated code worked in both cases.

No Really, Solve My Problem

One more trend I’m seeing is that folks want learning personalized to them. Either they want explanations that relate to their existing knowledge and strengths, or they want knowledge presented in the context of their existing project. So instead of getting a generic explanation of how concurrency works in Go, a web dev may want that explanation given in contrast to JavaScript. Or someone may want an LLM’s answer to take into account the libraries they’ve already imported into a project, rather than pulling in a completely new library.

I regularly ask Gemini to explain things to me, or more accurately I’ll say “tell me more…”. And at this point I pretty much expect that its explanation will take any additional context into account. Usually that’s my codebase, but sometimes that’s additional information I’ve shared about me and my previous knowledge. When it was teaching me Agent Development Kit (ADK) I asked it to use Go and told it I knew JavaScript. It explained critical Go concepts to me based on how they compared, or didn’t, to similar things in JavaScript. For me at least, it seems natural that answers would be customized to me and the things I’m currently working on.

What Does This Mean for DevRel

So what does this mean for DevRel? While I do think some things will change pretty significantly, I think a lot of what we already do is still relevant. Since it is easier for folks to try new languages and frameworks, we need to ensure the communities we belong to are welcoming to newcomers, especially newcomers who may not have followed a traditional path to this particular technology. I think my team is probably tired of me saying it, but everyone is welcome at my developer (and builder) party.

I also think we need to focus a larger percentage of our content around higher level tasks. Some DevRel teams do this really well already. I’ve always appreciated that the Firebase docs have great walk-throughs for common multi-product tasks. If folks are asking higher level questions we need to make sure that the tutorials and documentation exist to help achieve those higher level goals, especially when the solution is multi-product.

Finally, every day I feel more and more urgency to have great evaluation tools. If folks are expecting personalized answers, I want confidence that those answers are correct. I was a huge proponent of Test-Driven Development (Red, Green, Refactor for life). I liked TDD because it gave me confidence my code was right, or at least right within the context of the tests that I wrote. Evaluation seems to be the unit and integration testing of the AI age. And I want really great evaluation tools so I can be confident that personalized answers are correct.

Conclusion

I’m curious, what trends you are seeing in your communities? Are folks embracing personalized learning or do they prefer traditional documentation and tutorials? Are your colleagues trying new tools more readily now that the time needed to experiment is lower, or are folks sticking with what they know well? Please let me know in the comments.

It wasn’t that I disliked learning or got bad grades. I just never understood the way most schools work. Why should everyone who is the same age have to learn the exact same material at roughly the same rate? We were taught to embrace our strengths and weaknesses, and yet our school treated us like we were all the same when it came to learning.

To arrogant, teenage me, it was obvious that the solution was self-paced learning of some kind, likely driven by computers since most of my classes had over 30 students per teacher. So I tried to code a self-paced learning system. Sadly my programming skills weren’t up to the task back in the mid-90s. I did build a couple of very simple flashcard-style apps that my friends used to improve their grades on tests, and seeing how my work could help others was what got me hooked on tech. And so I got a degree in Computer Science.

Announcing Ursa Weaver

A few weeks ago, at a workshop, I got thinking about the personalized learning problem again and wondered if I could create something to address it using AI. I fired up Google Antigravity, picked something I wanted to learn, Agent Development Kit (ADK) for Go, and got to work. I’ve released what I created in open source as Ursa Weaver (https://github.com/GoogleCloudPlatform/ursa-weaver).

Ursa Weaver was entirely vibe coded in Antigravity. It took me about 60 minutes to build an initial proof of concept and a few hours over the following weeks to refine the idea based on feedback and do some initial testing. The initial release has no traditional code, just an AI Agent Skill and some data files. And yet, it can provide personalized guidance to someone who wants to learn ADK for Go.

Design Considerations

Before I started actually writing the code, I worked on refining the requirements. In the end there were three things that were high priorities for the initial version. First, the tutor needed to run in the environment where people actually worked. I don’t understand why folks should learn skills in one set of tools and then have to transfer that knowledge to their primary IDE.

Second, I wanted the curriculum to be both personalized and curated by an expert. There are plenty of examples of AI explaining concepts; what is usually missing from these demonstrations is how bits of skill and knowledge build on each other. For example, AI can teach you addition, but it may not know you need to understand quantity and numbers before you learn addition. Or that you could learn subtraction before you learn addition.

Finally, it was important to me that there was some verification that students had actually learned the material. I know that often just reading material isn’t enoug. You need to actually do something with the information to retain it.

High Level Implementation

Ursa Weaver is implemented as an AI Agent Skill, allowing it to run on AI integrated IDEs. This means that the tutorial happens in the context of your existing configuration and preferences and in the context of a tool you already know. In context learning means you can focus on the material being presented and not on learning a new interface or tool. It also means that Ursa Weaver has access to any additional skills, CLIs, or MCP servers you have installed.

To allow the AI to personalize the learning journey I broke down the topic I wanted to learn, ADK for Go, into a series of skills that could be learned in 5-10 minutes. I used Gemini to help me do this, but I verified its work. Once I had the core list of skills I then worked with Gemini to add any pre-requisite skills, especially implicit or implied skills. Things like having Go installed or understanding how asynchronous versus synchronous function calls worked.

Once I had the entire list of possible skills, I used Gemini to organize them in a JSON file that listed each skill and the dependencies it had on previous skills. This creates a skill graph, but you can think of it as a course catalog explicitly listing that you can’t take Advanced Algorithms until you complete the Introduction to Algorithms course.

To tackle the verification requirement, I added explicit details about how to verify each skill was completed or learned. I gave Gemini a list of potential ways to do verification including short answer questions, multiple-choice questions, reviewing or executing code the user wrote, and verifying a configuration with MCP or command-line commands. This verification ensures that if a user completes the “Go Setup Skill” later skills can assume that the user has Go and the GOPATH is set correctly.

Finally, to support personalization I made two changes. First, I added support for fast tracking through skills if the user can complete the verification or an equivalent assessment without needing additional guidance or explanation. I also added a user profile that has basic information about the user including their background, interests, and what skills they’ve already completed. This allows the AI to customize the learning to a learner’s existing knowledge base and allows you to work through the curriculum across sessions.

Future Work

I have a long to-do list for the project. I’ve tested it in Antigravity and Gemini CLI but I need to test it with more tools. I want to add full support for multiple languages so students can be taught in their preferred language. I’ve only committed one curriculum file to the GitHub project, but I have others I’ve tested myself. I want to both provide some additional example curriculum files and the prompts (and code) to create your own from documentation and other sources.

I want to build evaluation tools for curriculum files that simulate common user personas and common scenarios including longer sessions which in my testing have shown the highest tendency to drift from the established curriculum. Once I’m confident in evaluation, I want to create larger curricula with potentially hundreds or thousands of skill nodes. I’ve created a curriculum with 100 nodes in my testing, but without good testing and evaluation it is hard to have confidence it will provide a good learner experience consistently.

Finally, most learning apps have some sort of gamification, or at least recognition of the work learners finish. I’m not sure what to do here but potentially I could use one of Google’s image models to create merit badges or certificates of accomplishment at key points in someone’s learning journey.

Share Your Feedback

If you get a chance to try Ursa Weaver, let me know what you think, both good and bad. It is still a proof of concept. For me, the biggest surprise was how fast it came together without any traditional coding. In just a few hours using Antigravity I was able to build something that teenage me could imagine but didn’t have the ability to build. I know I would have been a happier student if I could have wound my own way through the curriculum rather than having to work on chapter 3 just because it was the first Thursday in November.