I can’t remember a smoother long-distance travel day. Flights all on time, decent wifi, got a little sleep, and went from the airplane landing in India to my hotel in less than an hour. Personal record!
[article] Why AI Coding Agents Still Need Clear Specs. Create fully complete specs before firing up your Ai agent, or just /goal and let your agent figure it out? This talks about the importance of validating the spec (even a small one) before setting the coding agent loose.
[blog] Multi-Tenancy Isn’t About Databases. Good reminder that multi-tenancy is about isolation, and you don’t necessarily have to use separate databases per tenant.
[blog] Have you heard? Clickhouse is winning the observability wars! Sometimes those blazing the trail don’t get the glory; it’s those that follow. But Charity points out why a different approach to storage (and a different philosophy) for observability is distinctive.
[article] CEOs fear they’re underinvesting in AI. There’s a lot of FOMO out there. But don’t use AI because of that. Apply it where it can make a real difference.
I’ve been working for days (unsuccessfully) on a piece of a demo I’m doing next week in India. Fortunately our product and engineering teams jumped in, and we found some service bugs. So it wasn’t ENTIRELY my fault. But today I got it working, and it’ll be the highlight of my day.
[blog] Write code, not specs. Here’s a contrarian take. Instead of maintaining two “systems” (specs and the realization of that spec in code), this person sees the code as the source of truth for patterns, requirements, and such.
[article] On measuring engineers as individuals. When you record and measure individuals based on output metrics, a bunch of the background collaboration work disappears as a result.
[blog] Is the PRD dead? How to choose the right level of documentation. If traditional requirements docs aren’t the answer, what is? It’s worth talking about this with your team. If you’re still doing it the old way, you might not be seeing the velocity improvements you hoped for.
I enjoyed the time off, and am also happy to be back into routines. The tech world didn’t take much of a break, and I’m working through a reading backlog.
[blog] Where does Antigravity look for Agent Skills? We’ve made this confusing and I look forward to the point when agent skills can be easily discovered and stashed for later use. Mete does a good job here steering us to to the right places.
[blog] How to Count Gemini Tokens Locally. As we all become more token conscious, it’s not a bad idea to understand the ins-and-outs of counting tokens.
[blog] The State of AI in the SDLC: A Roadmap for Scaling. I buy it. As you chase your first customer, you’re just focused on the code (and use case). Then you have to think about process, and after that, organization.
[blog] Of Skills and Loops with AI Assistance. If you invest up front in encoding your knowledge into skills and crafting agent loops, you’ll see some fairly dramatic speedups.
[blog] Building Gin: Simple Over Easy. Sometimes the throwaway thing you built along the way turns into the main thing. Great story about the start of Go’s most popular web framework.
[blog] Tom’s opinionated guide to skill building 101. Excellent. Skills don’t just serve software developers. They can make other disciplines, like technical writing, significantly better.
[article] The twilight of the chatbots. Looping agents with good direction don’t require a lot of human intervention. That’s different than early mainstream AI days where we engaged with chatbot interfaces.
I had a great day off. The kids had a summer camp for the morning, so I took a joyful, meandering drive through the mountains and towards the beach. One beach-adjacent taco stand later, I wandered back. This is why I’ll never want a self-driving car.
[article] 7 reasons experienced EMs get stuck. This may be for engineering managers, but these reasons apply to nearly any manager position.
[blog] A return to two-pizza culture. Amazon’s Werner Vogels looks at the shift in when you write down your plan, and how teams work with AI.
[blog] Learning faster with Antigravity. How do you build a frontend for a backend you’re unfamiliar with? Andrew did a learning loop, and created a skill to make this process repeatable.
[blog] Guide to the OWASP MCP Top 10. Here are the security issues you need to watch out for with MCP. Some of these you can directly mitigate, and others might require some proxies or gateways to protect your users.
[blog] Why we built ADK 2.0. A big part of this was bringing deterministic execution to agents with “workflows.” Good post on when to use this new abstraction.
We’ve somehow got both tomorrow and Friday off for our Independence Day holiday. I’ll still probably do a reading list both days. I’m sure the anticipation will keep you up tonight.
[blog] Get started with the Claude apps gateway for Google Cloud. If you care about performance, you probably already point to Anthropic models hosted on Google Cloud. Now you can run their new apps gateway here too and get enterprise management.
[article] The future of engineering at Nationwide, Comcast, TD, and HPE. These are all wonderful takeaways. I’d be surprised if any large enterprise—I haven’t met one—has truly done any of this at scale, but it’s the right foundational beliefs.
[blog] Beyond Gemini Enterprise: Google’s Hidden AI Superpower. A great model is a must-have. We’ll keep making those. But it’s about more than just an LLM, and Google’s got a unique value proposition up and down the stack.
[article] Agent Memory. Excellent deep dive into the various types of agent memory and considerations for each.
[article] The AI jobs debate just got messier. Sometimes the data refuses to bend to the narrative. Or, we just assume nobody knows what’s going on right now. I’m voting for the latter.
I liked some of the manager-focused pieces today, as that’s an under-served audience right now. There’s plenty of content for how individuals use AI, but much less about the impact and role of managers.
[blog] Paging Charity! How can engineering leaders avoid becoming Bond villains? The number one job of every manager/leader is to win at business. Not build great teams, not coach the next generation. Those things matter a ton. But you won’t get the opportunity to do those things if the team doesn’t matter.
[article] CEOs, CIOs clash over AI’s value. Oooh, enterprise drama. Each side probably expect different outcomes, or at least on different timelines.
[blog] Antigravtiy CLI Plugin for Claude Code. Mix models, mix harnesses, whatever. You don’t need to use one stack for everything, and it may be prohibitive to do so!
[blog] The Problem is Prompt Debt. Less prose, more firm direction. And fewer hand-written prompts, more generated.
That was fast. We’ve moved from prompting an LLM, to providing instructions to an agent, to having agents prompting other agents in a loop. “Loop engineering” is all the rage among the AI elite who are excited to spin up an agent and let it chomp tokens until it achieves a stated goal. You might rightfully wonder where you fit into all of this.
LLMs and agents basically know everything but your context. There’s a role for you in setting up the full context—instructions, tools, examples, policies, skills, and such—your agent needs. It’s also up to the human to set a goal for the agent to loop on. And unless you completely trust the quality of the output, we have a role in reviewing (and owning) the result.
Earlier this month, I wrote a post that showed how simple it was to spin up an agent team in Google Antigravity. I played no part in the work once I kicked off the team with a prompt. But that’s not super realistic for most people and most scenarios. You may want smaller bites of work that a human is capable of reviewing (not 5,000 lines of code at a time), and the opportunity to engage with the agent team at the right times to adjust steering. To be sure, there is a class of agentic work where you want to just want to fire-and-forget, so we will talk about that too.
Let’s see what it looks like in real life. What about a prompt that kicks off an agent team that pauses at strategic times to get my insights? And what about a subsequent process that’s entirely agent looped because I don’t care to be involved at all? I’ll show both.
First, I want to build my web application. It’s the same scenario as my last post: a hotel website. I don’t want to create a prompt (or provide context) with all the details, but rather, have the agent interview me (/grill-me). Then, we should create sprints, pausing after completing each so that I can genuinely absorb all the changes. Each sprint tackles a vertical slice of the architecture, using a team of sub-agents to do backend, frontend, and test work. The frontend engineer asks clarifying questions (using the ask_user tool) to get my opinion on visual design. Here’s my complete prompt:
/grill-me "Let's build a hotel room booking app for Seroter Hotels consisting of a backend API and a web frontend."
First, act as the **Engineering Manager** to design the API and frontend. Interview me to gather my requirements, asking only one question at time.
-----------------------------------------
1. ROADMAP PROPOSAL (HALT FOR APPROVAL)
-----------------------------------------
Once our Q&A is complete, do NOT write any code or launch any subagents yet. Instead:
- Analyze our discussion and propose a Sprint Roadmap consisting of 2 to 4 vertical-slice sprints.
- Each sprint must represent a single, reviewable Pull Request (PR) containing a full stack slice: backend API, frontend UI, and associated tests.
- Present this roadmap to me and HALT. Ask for my feedback, additions, or changes.
-----------------------------------------
2. SPRINT EXECUTION (HUMAN-IN-THE-LOOP)
-----------------------------------------
Once we mutually agree on the roadmap, write the final specification and sprint plan to `architecture.md`.
Execute the agreed-upon Sprints one at a time, enforcing `architecture.md` as the living **Source of Truth**:
### SPRINT WORKFLOW:
For the active sprint:
1. Launch the **Test Manager**, **Backend Engineer**, and **Frontend Engineer** in parallel.
2. **Read Phase:** Force each subagent to read the latest `architecture.md` file before generating code, ensuring they strictly adhere to the established design, database models, and sprint scope.
3. **Frontend Interrogation:** For the Frontend Engineer, before creating any files, it must use the 'ask_user' tool to ask 2-3 visual design questions for this sprint's UI and pause for my response.
4. **Consolidation Phase:** Once the parallel subagents finish their tasks, they must pass their final API endpoints, file lists, component choices, and test plans back to you (the Engineering Manager).
5. **Update Source of Truth:** You must append these implementation details directly to the relevant sprint section in `architecture.md` (e.g., documenting the actual DB columns, final API routes, UI components, and test coverage delivered).
6. **HALT & PR Review:** Present the updated `architecture.md` and a summary of the code changes for my review. Wait for my explicit approval before moving to the next sprint.
Here’s what happens when I plug this into the Angravity 2.0 desktop app. First, I add that prompt into the textbox and choose my LLM (Gemini 3.5 Flash).
The primary agent is acting as my Engineering Manager and starts off by asking me its first requirements-gathering question.
We go through a handful of questions (“what types of rooms are available”, “what are key business rules”, etc). After a few questions, I get one about the preferred tech stack.
Great. After this, Antigravity shows me a proposed sprint plan. The first sprint builds out the search capability, second sprint works on room booking, and the final one is for looking up existing bookings. At this stage, I could split the work differently, alter each sprint plan, or proceed as is. I’ll proceed as is.
Antigravity starts up the agent team (see them on the top right of the screenshot), and the Frontend Engineer asks the “Engineering Manager” to get some visual design requirements from me.
Each of the sub agents goes about its work. The Test Manager, for example, creates a test plan that’s reviewable any time.
Once all the sub agents finish, the sprint is over and ready for review. Now I can peruse the generated code and docs. Because the sprint was a reasonable size, the review is manageable.
I proceed through sprints 2 and 3, with the Frontend Engineer stopping to get clarifying answers about look-and-feel of the booking experience. As each sprint finishes, I’m asked to do a review.
Throughout each sprint, there’s plenty of looping where the sub agent works, reviews, reacts, and repeats. I’m not involved in most of the actual build work, nor do I need to be.
After all the sprints wra up, I’ve got a working web app.
I wan to be included in the “build the app” scenarios. It’s fun work, and I don’t trust an agent to do everything I want without some involvement from me. But you can imagine that there are many tasks that can be entirely agentic without my input. Let the agent figure everything out. For instance, let’s say I want to containerize this whole web application, and test that the containers work right. I don’t care at all about being involved in this, and frankly, the agent knows more than I do in this situation.
Here, I just want to use /goal to have my agent loop until it achieves the goal.
/goal Containerize this entire hotel booking application on my local machine. Generate optimized Dockerfiles for both the frontend and backend, configure a docker-compose.yml, build the images, spin them up, and verify that the API and frontend can communicate over the network. Note that I'm accessing Docker locally using Colima. If any container build fails, analyze the logs and auto-heal the configuration until they all start successfully.
See this is great. I don’t care about writing Dockerfiles or even reviewing them. Let alone mucking around with all the container stuff like opening the right ports. Let the agent loop on that until it all works.
After Antigravity finishes its work, I see the dockerfiles, docker compose file, and notice containers running during the local test.
Craft agent teams that add you where you want to be involved. Figure out the moments that genuinely need you. But don’t be an agentic micromanager. Decide on key places where you input matters (if at all). And then use /goal to unleash the agent on tasks where you don’t need any supervision.
Richard Seroter's Architecture Musings 