The “what” and the “how” in software engineering occasionally change at the same time. Often, one triggers the other. The introduction of mainframes ushered in batch practices that capitalized on the scarcity of computing power. As the Internet took off, developers needed to quickly update their apps and Agile took hold. Mobile computing and cloud computing happened, and DevOps emerged shortly thereafter. Our current moment seems different as the new “what” and “how” are happening simultaneously, but independently. The “what” that’s hot right now is AI-driven apps. Today’s fast-developing “how” is AI-native software engineering. I’m seeing all sorts of teams adopt AI to change how they work. What are they doing that you’re not?
AI natives always start (or end) with AI. The team at Pulley says “the typical workflow involves giving the task to an AI model first (via Cursor or a CLI program) to see how it performs, with the understanding that plenty of tasks are still hit or miss.” Studying a domain or competitor? Start with Gemini Deep Research or another AI research service. Find yourself stuck in an endless debate over some aspect of design? While you argued, the AI natives built three prototypes with AI to prove out the idea. Googlers are using it to build slides, debug production incidents, and much more. You might say “but I used an LLM before and it hallucinated while generating code with errors in it.” Stop it, so do you. Update your toolchain! Anybody seriously coding with AI today is using agents. Hallucinations are mostly a solved problem with proper context engineering and agentic loops. This doesn’t mean we become intellectually lazy. Learn to code, be an expert, and stay in charge. But it’s about regularly bringing AI in at the right time to make an impact.
I use the Gemini CLI to:
– debug production incidents, – activate and actuate changes on my CI/CD, – do risk analysis of changes and postmortems, – write slides and docs, – run capacity planning estimates.
— Ramón Medrano Llamas (@rmedranollamas) June 26, 2025
AI natives switched to spec-driven development. It’s not about code-first. Heck, we’re practically hiding the code! Modern software engineers are creating (or asking AI) for implementation plans first. My GM at Google Keith Ballinger says he starts projects by “ask[ing] the tool to create a technical design (and save to a file like arch.md) and an implementation plan (saved to tasks.md).” Former Googler Brian Grant wrote a piece where he explained creating 8000 character instructions that steered the agent towards the goal. Those folks at Pulley say that they find themselves “thinking less about writing code and more about writing specifications – translating the ideas in my head into clear, repeatable instructions for the AI.” These design specs have massive follow-on value. Maybe it’s used to generate the requirements doc. Or the first round of product documentation. It might produce the deployment manifest, marketing message, and training deck for the sales field. Today’s best engineers are great at documenting intent that in-turn, spawns the technical solution.
I have been testing and using Gemini CLI in the last weeks. Here's what my setup looks like:
– For complex tasks, I *never* ask for code first. My initial prompt is to create a plan "Create a detailed implementation plan for [FEATURE, BUG]". – Create multiple hierarchical GEMINI… pic.twitter.com/4brvJqv8nt
AI natives have different engineer and team responsibilities. With AI agents, you orchestrate. You remain responsible for every commit into main, but focus more on defining and “assigning” the work to get there. Legitimate work is directed to background agents like Jules. Or give the Gemini CLI the task of chewing through an analysis or starting a code migration project. Either way, build lots of the right tools and empower your agents with them. Every engineer is a manager now. And the engineer needs to intentionally shape the codebase so that it’s easier for the AI to work with. That means rule files (e.g. GEMINI.md), good READMEs, and such. This puts the engineer into the role of supervisor, mentor, and validator. AI-first teams are smaller, able to accomplish more, capable of compressing steps of the SDLC and delivering better quality, faster. AI-native teams have “almost eliminated engineering effort as the current bottleneck to shopping product.”
AI Agents turn everyone into a manager. We thought the future of software was AI reviewing and editing our work. But in fact the opposite is true. The future of software is to kick off tasks to AI Agents and review, edit, and orchestrate their work. https://t.co/dAlgt3IlRD
There are many implications for all this. Quality is still paramount. Don’t create slop. but to achieve the throughput, breadth, and quality your customers demand requires a leap forward in your approach. AI is overhyped and under-hyped at the same time, and it’s foolish to see AI as the solution to everything. But it’s a objectively valuable to a new approach. Many teams have already made the shift and have learned to continuously evaluate and incorporate new AI-first approaches. It’s awesome! If you’re ignoring AI entirely, you’re not some heroic code artisan; you’re just being unnecessarily stubborn and falling behind. Get uncomfortable, reassess how you work, and follow the lead of some AI-native pioneers blazing the trail.
Spent a small bit of time this weekend playing with using agents to build agents. How meta! Today, many of our engineering leads answered Gemini CLI questions in this Reddit AMA. What a wild time for builders.
[blog] How to Fix Your Context. Building on the previous items, how should you think smartly about creating and maintaining context used by an agent? Great post.
[blog] Go 1.25 interactive tour. These are always terrific posts. Anton publishes these assessments of Go releases by letting you test out the features right within the blog post. See his related (and interactive) look at the new JSON handling capabilities.
[blog] APIs Versioning. No new ground, but it’s a good topic to refresh yourself on from time to time. And a reminder for those who keep breaking APIs.
[blog] This Week in Open Source for June 27, 2025. I’m liking where this weekly update is going. It provides a broad look at the open source landscape and what’s happening.
[article] Why Software Migrations Fail: It’s Not the Code. I imagine that AI is going to “fix” parts of this, but still a reminder that code update aren’t the only thing you need to worry about when doing a migration project.
Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:
It’s the end of a busy week. I’m looking forward to a hopefully-quiet weekend with the family and a few good books. Take a breather too!
[article] How much does AI impact development speed? Good look at some new research into how much AI impacts developers and their pace. Interesting that seniority and prior usage didn’t change the outcome.
[blog] Veo 3: A Detailed Prompting Guide. This is absolutely fantastic. Get all the right phrases and jargon to use when prompting a text-to-video model like Veo 3. Gold!
[blog] Coding agents have turned a corner. It’s fine when goofballs like me use these AI tools and offer guidance, but I really value the advice from capital-E Engineers like Brian. Here, he offers his direction on how to work with coding agents.
[blog] The rise of “context engineering.” The idea here is making sure the LLM has the right information and tools it needs to accomplish its task. It’s a system approach, versus thinking in prompts alone.
Another wild day. I’m doing some research into what other people think modern, AI-driven coding looks like. May turn my findings into a blog post. Either way, a new work style is forming.
[blog] Choosing the Right Deployment Path for Your Google ADK Agents. Fantastic post from Ayo that explores three agent hosts with different value propositions. You’ll likely debate their three types of platforms, regardless of which cloud you use.
[blog] 6 ways to become a database pro with the Gemini CLI. It’s a mistake to lump these agentic CLIs into a “coding tools” bucket. You can do a lot more than code apps. Karl shows some great data-focused examples here.
[blog] What Diff Authoring Time (DAT) reveals about developer experience. What’s going on from that moment a developer makes their first edit, until a pull request gets created? How do we measure that and improve the experience? Here’s analysis of some recent research.
[article] How To Prepare Your API for AI Agents. If you actually have an API strategy, you’re already ahead of others. This article has some advice for what to focus on.
[blog] I don’t care if my manager writes code. Should engineering managers be committing code alongside their reports? No, that doesn’t seem very wise or sustainable. But I do want my management to deeply know the tech the team is using.
Yesterday morning, we took the wraps off one of the most interesting Google releases of 2025. The Gemini CLI is here, giving you nearly unlimited access to Gemini from directly within the terminal. This is a new space, but there are other great solutions already out there. Why is this different? Yes, it’s good at multi-step reasoning, code generation, and creative tasks. Build apps, fix code, parse images, build slides, analyze content, or whatever. But what’s truly unique is that It’s fully open source, no cost to use, usable anywhere, and super extensible. Use Gemini 2.5 Pro’s massive context window (1m tokens), multimodality, and strong reasoning ability to do some amazing stuff.
Requirements? Have Node installed, and a Google account. That’s it. You get lots of free queries against our best models. You get more by being a cloud customer if you need it. Let’s have a quick look around, and then I’ll show you four prompts that demonstrate what it can really do.
The slash command shows me what’s available here. I can see and resume previous chats, configure the editor environment, leverage memory via context files like GEMINI.md, change the theme, and use tools. Choosing that option shows us the available tools such as reading files and folders, finding files and folders, performing Google searches, running Shell commands, and more.
I’m only scratching the surface here, so don’t forget to check out the official repo, docs, and blog post announcement. But now, let’s walk through four prompts that you can repeat to experience the power of the Gemini CLI, and why each is a big deal.
Prompt #1 – Do some research.
Software engineering is more than coding. You spend time researching, planning, and thinking. I want to build a new app, but I’m not sure which frontend framework I should use. And I don’t want stale answers from an LLM that was trained a year ago.
I’ve got a new research report on JavaScript frameworks, and also want to factor in web results. My prompt:
What JavaScript framework should I use to build my frontend app? I want something simple, standards-friendly, and popular. Use @report.pdf for some context, but also do a web search. Summarize the results in a way that will help me decide.
The Gemini CLI figured out some tools to use, successfully considered the file into the prompt, started off on its work searching the web, and preparing results.
The results were solid. I got tradeoff and analysis on three viable options. The summary was helpful and I could have continued going back and forth on clarifying questions. For architects, team leaders, and engineers, having a research partner in the terminal is powerful.
Why was this a big deal? This prompt showed the use of live Google Search, local (binary) file processing, and in-context learning for devs. These tools are changing how I do quick research.
Prompt #2 – Build an app.
These tools will absolutely change how folks build, fix, change, and modernize software. Let’s build something new.
I fed in this prompt, based on my new understanding of relevant JavaScript frameworks.
Let’s build a calendar app for my family to plan a vacation together. It should let us vote on weeks that work best, and then nominate activities for each day. Use Vue.js for the JavaScript framework.
Now to be sure, we didn’t build this to be excellent at one-shot results. Instead, it’s purposely built for an interactive back-and-forth with the software developer. You can start it with –yolo mode to have it automatically proceed without asking permission to do things, and even with –b to run it headless assuming no interactivity. But I want to stay in control here. So I’m not in YOLO mode.
I quickly got back a plan, and was asked if I wanted to proceed.
Gemini CLI also asks me about running Shell commands. I can allow it once, allow it always, or cancel. I like these options. It’s fun watching Gemini make decisions and narrate what it’s working on. Once it’s done building directories, writing code, and evaluating its results, the CLI even starts up a server so that I can test the application. The first draft was functional, but not attractive, so I asked for a cleanup.
The next result was solid, and I could have continued iterating on new features along with look and feel.
Why was this a big deal? This prompt showed iterative code development, important security (request permission) features, and more. We’ll also frequently offer to pop you into the IDE for further coding. This will change how I understand or bootstrap most of the code I work with.
Prompt #3 – Do a quick deploy to the cloud.
I’m terrible at remembering the syntax and flags for various CLI tools. The right git command or Google Cloud CLI request? Just hopeless. The Gemini CLI is my solution. I can ask for what I want, and the Gemini CLI figures out the right type of request to make.
We added MCP as a first-class citizen, so I added the Cloud Run MCP server, as mentioned above. I also made this work without it, as the Gemini CLI figured out the right way to directly call the Google Cloud CLI (gcloud) to deploy my app. But, MCP servers provide more structure and ensure consistent implementation. Here’s the prompt I tried to get this app deployed. Vibe deployment, FTW.
Ship this code to Cloud Run in us-west1 using my seroter-project-base project. Don’t create a Dockerfile or container, but just deploy the source files.
The Gemini CLI immediately recognizes that a known MCP tool can help, and shows me the tool it chose.
It got going, and shipped my code successfully to Cloud Run using the MCP server. But the app didn’t start correctly. The Gemini CLI noticed that by reading the service logs, and diagnosed the issue. We didn’t provide a reference for which port to listen on. No problem.
It came up with a fix, made the code changes, and redeployed.
Why was this a big deal? We saw the extensibility of MCP servers, and the ability to “forget” some details of exactly how other tools and CLIs work. Plus we observed that the Gemini CLI did some smart reasoning and resolved issues on its own. This is going to change how I deploy, and how much time I spend (waste?) deploying.
Prompt #4 – Do responsible CI/CD to the cloud.
The third prompt was cool and showed how you can quickly deploy to a cloud target, even without knowing the exact syntax to make it happen. I got it working with Kubernetes too. But can the Gemini CLI help me do proper CI/CD, even if I don’t know exactly how to do it? In this case I do know how to set up Google Cloud Build and Cloud Deploy, but let’s pretend I don’t. Here’s the prompt.
Create a Cloud Build file that would build a container out of this app code and store it in Artifact Registry. Then create the necessary Cloud Deploy files that defines a dev and production environment in Cloud Run. Create the Cloud Deploy pipeline, and then reference it in the Cloud Build file so that the deploy happens when a build succeeds. And then go ahead trigger the Cloud Build. Pay very careful attention for how to create the correct files and syntax needed for targeting Cloud Run from Cloud Deploy.
The Gemini CLI started by asking me for some info from my Google Cloud account (project name, target region) and then created YAML files for Cloud Build and Cloud Deploy. It also put together a CLI command to instantiate a Docker repo in Artifact Registry. Now, I know that the setup for Cloud Deploy working with Cloud Run has some specific syntax and formatting. Even with my above command, I can see that I didn’t get syntactically correct YAML in the skaffold file.
I rejected the request of the Gemini CLI to do a deployment, since I knew it would fail. Then I gave it the docs URL for setting up Cloud Run with Cloud Deploy and asked it to make a correction.
That Skaffold file doesn’t look correct. Take a look at the docs (https://cloud.google.com/deploy/docs/deploy-app-run), and follow its guidance for setting up the service YAML files, and referencing the right Skaffold version at the top. Show me the result before pushing a change to the Cloud Deploy pipeline.
Fortunately, the Gemini CLI can do a web fetch and process the latest product documentation. I did a couple of turns and got what I wanted. Then I asked it to go ahead and update the pipeline and trigger Cloud Build.
It failed at first because I didn’t have a Dockerfile, but after realizing that, automatically created one and started the build again.
It took a few iterations of failed builds for the Gemini CLI to land on the right syntax. But it kept dutifully trying, making changes, and redeploy until it got it right. Just like I would have if I were doing it myself!
After that back and forth a few times, I had all the right files, syntax, container artifacts, and pipelines going.
Some of my experiments went faster than others, but that’s the nature of these tools, and I still did this faster overall than I would have manually.
Why was this a big deal? This showcased some sophisticated file creation, iterative improvements, and Gemini CLI’s direct usage of the Google Cloud CLI to package, deploy, and observe running systems in a production-like way. It’ll change how confident I am doing more complex operations.
Background agents, orchestrated agents, conversational AI. All of these will play a part in how we design, build, deploy, and operate software. What does that mean to your team, your systems, and your expectations? We’re about to find out.
We’ve been building up to today’s launch of the Gemini CLI. There were some inevitable hiccups on launch day, but it’s fun to be part of teams that make things people like using. Give it a try!
[blog] Gemini CLI: your open-source AI agent. This is a huge deal. Open source, free to use, lightweight, and super extensible. This is another reason I think software engineering is changing forever. Press coverage here, here, here, and here.
[blog] Getting Started with Gemini CLI. Here’s a spot-on guide for installing and flexing some of the most important parts of our powerful new tool.
A fun and frantic day. My kids are on Summer break, but there’s no slowdown for us working folks. That’s fine by me, as long as the work is interesting and impact is possible.
[blog] Using AI Right Now: A Quick Guide. Give this a read. Ethan does another great job explain not only which AI he uses when, but how to act like a power user.
[blog] This Week in Open Source – Inaugural Post. To me, it seems like it’s been a while since an industry-shaking open source project came out from a big tech vendor. A2A is great, but still early. But there’s actually still a ton of OSS going on at Google, and I liked this recap.
[article] The AI Revolution Won’t Happen Overnight. It will not. I think the optimists (of which I am one) have predicted the right impact, but the timeline is off.
[blog] Our favorite moments from 20 years of Google Earth. Do you just take for granted that you can immediately call up nearly any place on the planet and see it in detail? I do. And that’s ridiculous. 20 years later, this is still a magic service.
Happy Monday. Summer is in full swing here in San Diego and we’ve somehow skipped the annual June Gloom. I’ve jinxed it, haven’t I.
[paper] What Makes a Good Natural Language Prompt? The difference between a good prompt and bad prompt is stark. Very different results! This paper looks at 21 prompting categories that determine the quality of output.
[blog] Google Cloud donates A2A to Linux Foundation. Excellent news! The major hyperscalers plus others are the founding members of this new project to advance agent-to-agent communication.
[blog] In Praise of “Normal” Engineers. Build great teams, don’t chase 10x engineers. If you have one, great, but your throughput is dependent on the overall software team’s performance.
[article] My 2025 system prompt. John put together a legit system prompt for use in LLM chat experiences when he wants direct, focused responses.
[blog] Colab Terminal Is Now Free For All Users. Long live the terminal! Now more you can do, for free, from the Colab Terminal. Add packages, do git commands, and more.
Yesterday was a US holiday. It’s weird having a Thursday off and then going right back to work on Friday. But, I think we all survived. Got some work done, did a Twitter thread on coding assistance, and got hands-on with some upcoming tech. Not too shabby.
[blog] How We Use AI At Pulley. Excellent look at what it means to build with AI. From tools to updated practices, there’s a lot to learn from here.
[article] MCP Needs a Security Reality Check. MCP didn’t start with a lot of mature security considerations, but they’re quickly coming around.
[blog] Single vs Multi-Agent System? Great piece by Philipp. There’s competing advice out there, and he spends time sharing the pros/cons of each approach.
[blog] Every service should have a killswitch. Every code path doesn’t require this, but there’s definitely merit in having a way to turn off a hot operation.
I feel l’m seeing the future of software of engineering take shape. Maybe it’s where I work, but I think it’s more about what is happening around me. It’s exciting to see what we build and how we build both evolving so quickly.
[blog] We Are Better Than This. It’s absurd that Bob even needs to write this. But yes, the world has been noticeably absent from solidarity and support for our Jewish friends and neighbors.
[blog] Writing documentation for AI: best practices. Do you need to do anything different from regular SEO in your docs to ensure that LLMs properly digest and process your data?
Richard Seroter's Architecture Musings 