Build Faster, Test Smarter with AI: Dan Wahlin

AI agents can now take an idea to a working deployment faster than ever. That raises a question every engineering leader is asking: if an agent can write the code, does engineering discipline matter less, or more?

In this episode of the Code To Cloud podcast, I sat down with Dan Wahlin, who works in developer relations at Microsoft across Azure and GitHub, from Kubernetes, Container Apps and Functions to GitHub Copilot. We talked about what changes when agents write the code, deploy it and open the pull requests, and why the answer keeps coming back to security, testing, evidence and human judgement.

More Code, Faster, Means More to Check

We started with GitHub, which has grown from a place to store code into what Dan calls "a whole software development life cycle system." With agents now submitting pull requests, security moves to the top of the list. As Dan put it, "you can't just take something an agent did and just assume, oh, it's probably fine."

Secrets are the classic example. A password slipped into an .env file is "surprisingly hard to catch every scenario of," Dan said, because some keys are throwaway test values and others are production credentials nobody wants to rotate. GitHub's answer is layers: CodeQL, AI-assisted detection, and the newer security features announced at GitHub Universe. His point was that the protection exists, but you have to know about it, and some of it needs an admin to switch on.

The practical takeaway for any team rolling out coding agents:

• Turn on secret scanning and push protection, so a credential is stopped before it reaches the repository.
• Treat agent-written code like any other contribution: review, tests and security scans before it merges.
• Write your standards down for the agent. Our guide to GitHub Copilot custom instructions shows how.

Agents Can Build the Deployment. Ask Them for the Edge Cases

Dan is a software developer and architect by background, not an infrastructure specialist. Infrastructure as code was something he'd hand to someone else. Now, he said, he can produce "not only the YAML to drive all my services and pods" on Azure Kubernetes Service, "but the full deployment of it with an agent."

The feature he values most isn't the speed. It's being able to ask the agent to "find the edge cases." His example: managed identities versus keys. "Somebody new to this might not even know that's an option," he said, but an agent will tell you, if you ask what the most secure option is.

That matches how I work. My agent steering files say things like "use managed identities," because keys are no longer the way forward and access should tie back to Entra ID. And deployments go through a CI/CD pipeline, not straight from a laptop into the cluster. That pipeline is stage one, and it's mostly YAML, which agents have made far less painful. These days, most of my coding work is the test files, so nothing slips through the cracks.

When the pipeline is slow or fragile, agents expose it quickly. We wrote about that in Agentic DevOps: Speed Needs a Delivery System. Building that path to production, with paved roads, golden pipelines and identity done properly, is what our platform engineering work is for.

From Vibe Coding to Ten Golden Gate Bridges at Once

Dan drew the line clearly. You can "vibe code this up in a day or two." Getting that same idea into a whole software lifecycle, with CI/CD, security and the right Azure services, is a whole other ball game. Two years ago he'd have handed that part to a DevOps specialist.

The speed creates its own problem. What would have taken months to deploy is now in production in hours, and the teams that support it are catching up. My analogy on the episode was the Golden Gate Bridge: it took years to build, and it still needs maintenance and people on it every day. "Well, guess what? Now we're building 10 Golden Gate bridges at once." Onboarding new services, operating them and supporting them all have to keep pace with how fast they're now built.

For more on where this is heading, our conversation with Gene Kim on the future of coding with AI is a good companion piece.

Stacked Pull Requests, and Steering the Agent to Option B

Dan's example of a newer GitHub feature was stacked pull requests. In the old days, teams built one massive pull request because the pieces depended on each other and merging them in the wrong order broke things. The result put huge pressure on the reviewer: "Dan threw 10,000 lines of code at me." Stacked PRs let you split the work into small, ordered pieces a person can actually review.

That led to the point Dan kept returning to. "We're all now capable of building pretty much anything. However, unless you're steering the agent down the right road, that doesn't mean it's going to turn out that well." He's often surprised by solutions that work but were plainly never questioned: if the team had asked the agent for alternatives, "they probably would have chosen option B."

Experience is what makes the steering possible. Dan trusts today's models a lot, but not to stay on the best-practice road: "once they get going down a rabbit hole, they might stick in that rabbit hole." He still plans, and thinks through edge cases and security, before he lets an agent run. When he mentioned people who say they don't plan anymore, my answer was short: "Those people haven't caused outages."

Evidence and Guardrails: Tests That Run in the Pipeline

"I always want evidence," Dan said. "Evidence, evidence, evidence." His two big things are evidence and guardrails.

I shared a story from a rapid prototype with two early-career engineers. At the end of the day, they said the main thing they'd learned was not to trust the agent 100%, and to keep asking it why it had done something. We had spent more time building validation and verification than features. That's deliberate: skip it now, and you may have to rebuild the whole thing later, or expose something you shouldn't have.

Dan's version is end-to-end testing. When he hand-coded everything, unit tests were normal but end-to-end tests often weren't, because there wasn't time. Now he uses Playwright heavily, and he argues there's "no excuse not to have really solid end-to-end tests" that run locally and in the CI/CD pipeline, so a change is checked the way a user would see it, through the UI, not just the code.

Deterministic Automation: Stop Paying Tokens for Scripts

Running all those checks has a cost. I described my own loop: ten stacked PRs ready, a 20-minute wait while the pipeline tests each one, then a finding to fix, and token and compute time burning the whole while. I push as much as I can to GitHub Actions, and the next step is speeding that up without sacrificing quality.

Dan's answer was one of the most useful ideas in the episode. "We've become so accustomed to just go through the agent," even to rename a file. Many of those jobs are deterministic. So spend the time once: tell the agent "here's what I seem to be doing on a recurring basis, now build me a script," and run the script from then on, even if the agent is the one calling it. "You can run the end-to-end test without any AI, generally."

That's the architect's question applied to AI: what's the right tool for the job? If you're planning agents in production, our free Agent Platform Production Checklist covers the gates, identity and cost controls to put in place first.

Hands-On: Omarchy, Agent Buddy and Hacking Everyday Devices

The second half got hands-on. Omarchy, the Arch-based Linux setup that's built for development, has a learning curve, and Dan built Learn Omarchy to teach it, with a guide that flies around and talks you through it, plus games for learning the hotkeys. (Dan had read my own Omarchy hotkeys post, which is my most-read post.)

Then there's Agent Buddy, Dan's free, open-source desk companion: an animated character on a small Waveshare ESP32 screen that reacts when your coding agents start work, need approval or finish. It runs on C++ firmware, and Dan admits he didn't come from a hardware background. He's now trying a watch-sized screen, and found that a different pin layout means the same firmware won't run on it. "Do you know how long it would have taken me to figure that out" two years ago? I built my own, Hey Nova, by pointing an agent at Dan's repos and asking for a plan. Flashing the firmware felt like hacking again.

We also talked about repurposing everyday devices, from a reverse-engineered smart display to cheap Android screens turned into family calendars. My advice, with a legal disclaimer: if you've got something lying around that isn't critical, plug it in over USB, fire up the agent and ask, "Can you interface with this device?" And ask it to explain its steps. I often have it draw a mind map, and Dan uses the image generation in the GitHub Copilot app to turn a topic into a comic-book explanation.

Dan's Challenge: Act on Your Ideas and See Them Through

Dan closed with advice for two groups. If you've been ignoring AI, now is a good time to get up to speed and push past what you thought you could do. And if you're an idea person who sees things through, you've never been more empowered. "I cannot think of a time in my career where you have more power to actually deliver."

His challenge: think of every meeting where someone raised a great idea, everyone agreed, and it went into the backlog because nobody had time. "Right now, there's kind of no excuse for that." Bring the idea up, execute on it, and see it through.

Listen to the Full Conversation with Dan Wahlin

This post covers the main themes, but the full 45-minute conversation has more, from war stories about production outages to retro gaming. Catch it wherever you listen:

• Listen on Spotify
• Listen on Apple Podcasts
• Listen on Podbean
• Watch on YouTube

Find Dan on GitHub, LinkedIn and X.

Where to Start If Your Team Is Adopting Agents

The message from this episode is simple: agents make it faster to build, and that makes the delivery system around them matter more. If your team is at the start of that journey, three places to begin:

• Check where you stand. The free Agentic AI Readiness Scorecard takes a few minutes and shows the gaps to close first.
• Get the production checklist. The Agent Platform Production Checklist covers identity, guardrails, testing and cost controls.
• Build the delivery system. Our Agentic DevOps work puts GitHub Copilot and coding agents into your pipelines on Azure, with the tests, identity and approvals that let you move fast safely.

Have a question after listening? Book a discovery call or join our Discord community. Catch every episode on the Code To Cloud podcast page.

Frequently Asked Questions

Do AI coding agents make testing less important?

No. Agents produce more code, faster, so there is more to check. In the episode, Dan Wahlin argues that end-to-end tests are now so much easier to write that there is no reason to skip them, and they should run in the CI/CD pipeline as well as locally.

How should AI agents deploy to Azure safely?

Through a CI/CD pipeline rather than straight from a laptop, using managed identities instead of keys, with tests and approvals as gates. Ask the agent for the edge cases and the more secure alternative, because someone new to Azure may not know managed identities are an option.

What is the difference between vibe coding and agentic software development?

Vibe coding gets an idea working in a day or two. Taking it through the full software lifecycle, with CI/CD, security and the right Azure services, is a different job. Agentic development keeps people steering: small stacked pull requests, review, tests and evidence before anything ships.

How can teams reduce AI token costs?

Stop sending deterministic work through the agent. If you do something on a recurring basis, have the agent write a script once and run that instead. End-to-end tests and many pipeline steps run without any AI, so they cost no tokens.

What is Agent Buddy?

Agent Buddy is Dan Wahlin's open-source desk companion: an animated character on a small Waveshare ESP32 screen that shows when AI coding agents such as GitHub Copilot or Claude Code start work, need approval or finish. It runs locally, with no cloud account.