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.
Most of my “building” nowadays is for fun, for blogs, or for customer demos. But today I had to take a spreadsheet of data and enter records one-at-a-time into a web app. No thanks. Broke out the Google Antigravity CLI and took a few minutes to build a Playwright script that looped through the rows and filled out the web form. Achievement unlocked.
[blog] Learn Anything With My /teach Skill. Neat skill from Matt. He talks about it for Claude Code, but there’s nothing specific to that harness. Run this in your favorite environment to get a personalized teacher.
[blog] Writing Loops, Not Prompts, Explained. Skip the “write loops not prompts” hysteria. There’s a place for automating recurring work. But prompts are still part of the equation.
[blog] Hidden Technical Debt of AI Systems: Agent Harness. What an insightful read. I hadn’t thought about production versus training harnesses. The idea of the harness melting into the model is something we’ve had as well.
[blog] How to apply professional design principles in AI app development. Really good. It’s easy (and I’m speaking to myself) to just accept the stylized UI that comes back from the AI tool. But this post points out the eight areas where you can push back to get a stand-out result.
[blog] Make AI Boring Again. Smart take, as always. Learn these tools, figure out the best use, and make it boring.
[blog] The Coming Divide: AI-Native or Left Behind. I get it. This one is a choice. You can choose to use AI or not. Just like you can choose to read books or not. But then own the outcome.
[article] The Two-Organizations Problem. There’s the presented view of the org (via dashboards, townhalls, etc) and the lived org (how we experience it day to day). Those are not always the same.
How well my favorite sports team plays should have no bearing on my happiness. Alas, that’s not the case. But, my Padres won three in a row, which partially explains my good mood this week.
[blog] Why Are Agents Buying the Same Answer Twice? That’s a darn good question. Devin wonders why we’re computing stable answers over and over again, versus storing and recalling them.
[blog] Who Wrote That Query? You need the right visibility if you’re going to troubleshoot effectively. I like that our MCP Toolbox for Databases now makes it possible to trace a SQL query back to the agent prompt.
[site] ThoughtWorks Radar – April 2026. I don’t know how I missed this back in April. But scan through what technologies are ready for adoption and trial.
[article] Stop Getting Good at Protocols. Get Good at Agent Experience. Be good at both? Even after reading this, I’m not sure you can be great at AX without understanding the ways to make it happen. But I get the point to not obsess over fast-changing implementations.
We’re in process of doing our quarterly “check-ins” towards our personal goals. It’s a great moment for me to reflect and appreciate what my team has accomplished already!
[blog] How To Measure Development Productivity? Should you measure activity? Or output? Those are flawed categories, although they can have value at the team level. This post reminds us to consider desired outcomes and measure that.
[blog] Introducing computer use in Gemini 3.5 Flash. When you need/want agents that can “see” and reason across browsers and desktop, this sort of capability will be intensely valuable. Great to see it natively integrated into the Gemini Flash model.
[article] The Mom-and-Pop SaaS era has arrived. How many great ideas never got built because the cost of realizing them with software was too high? Not anymore.
[article] Lost confidence. When you can’t honestly quantify your confidence about the outcome, how do we proceed? Some really useful techniques called out here.
I’ve had a new blog post bouncing around in my head for a couple of weeks, and I built out some of the necessary proof-of-concept last night. Now, to block time to write the thing. That’s really the most important part of blogging, the writing.
[blog] Old Software Was Fast Because It Had No Choice. Is modern infrastructure too forgiving? Do we allocate extra headroom because we can? Instead of throwing capacity at every problem, maybe we can design smarter.
[article] Help Employees Get Better—Not Just Faster—with AI. This may change how I talk about this topic. Don’t make AI adoption just about creating AI fluency; it’s a change in how you express experience and judgement.
[blog] How Netflix Simplified Batch Compute with Kueue. Today’s got a lot of Kubernetes content. I’m not sure why. But, it’s a great reminder of how important your underlying infrastructure really is.
[article] AI isn’t solving cybersecurity workforce woes. Let’s see. A majority of cybersecurity people feel like calling it quits, AND we don’t have enough people to even fill the open roles right now. This is fine. Everything’s fine.
Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:
Just got home after a weekend in San Francisco with the family, and then a customer presentation at the Google office today. Our reading list has a lot about the modern SDLC and the role of agent loops.
[article] Why we’re bullish on loops. Agents are capable of running longer, and doing more complex work. So kicking off agents that can prompt agents is a viable approach in some cases.
[article] The Case Against Building Your Own Agent Platform. Right now? You’ll likely build something incomplete or incorrect for what agents need. That’s ok, it’s a fluid market. Don’t prematurely over-platform your stack.
[article] Autonomous Long-Running Coding Agents. Go from prompts, to goals. This makes your verifiers or evaluators even more important. I really liked this overview of the new workflow.
[blog] The New Software Lifecycle. More here on the new developer workflow. It also has a useful image showing the rapid transition from autocomplete to autonomous agents.
[article] The reason AI coding isn’t working on your team. I’m probably giving you whiplash if you’re reading today’s list from top to bottom. Don’t write off an LLM because your one-shot example didn’t work. Setup and embrace the harness.
[article] The Architecture of Focus. I liked this. Can’t seem to find time for deep work and focus? Redesign your environment. Anyone can do it.
Many of today’s pieces touched on accountability and ownership when AI plays a part in generation. Super important topic as we move past just the “create stuff” phase of agentic AI.
[article] When Purpose Backfires. Don’t lead with purpose if your team is hampered by thwarted impact. When (unnecessary) bureaucracy gets in the way, your burn out those powered by purpose.
[blog] The Open Source Maturity Spectrum. Thoughtful analysis by Steve. Corporate open source is rarely altruistic, and I’m saying that as the person who leads Google’s open source programs office! For many of us, it’s a strategic lever.
[blog] Using Agents, Keeping Agency. Good one from Devin on the decision layer, and keeping agency in a world of agents. You still own the result, regardless of how the work was created.
[blog] How to Track AI Agent Lineage and Manage State in Code Repositories. I like how Jason’s been thinking about this. Are git commits enough to understand what happened over time? Or are we missing other metadata about the session that generated the code, along with other lineage information?
I do this daily list for three reasons: personal discipline, self-learning, and sharing with others. In that order. If I just did it for learning and sharing knowledge with others, I could talk myself into skipping a day or two. But making it a “required” part of my day actually takes one decision off my plate. Do you have things you do just to build discipline?
[blog] More Than Syntax. Are developers still wrapping their identities in languages and frameworks? If so, nowadays is it less about being syntax experts and more about the community and using certain tools as a preferred way of solving problems?
[article] AI Is Rewriting the Economics of Outsourcing. Can someone do standardized work faster than you? Maybe that’s not true anymore. This article has some useful framing for how to think about it now.
[blog] A fool’s folly with local AI models. With some craziness around US models, everyone’s hot on open/local models again. Regarding local, there are caveats (especially around resources) that you need to factor in.
[youtube-video] I am done with Golang. While I (really) enjoy reading and watching things that complement our products, I also seek out critical feedback. Prime is unhappy with our consideration of generics, and anything that spoils this straightforward language.
Richard Seroter's Architecture Musings 