My GitHub Copilot Journey - Part 4: The Infrastructure Leap

Eight weeks ago, I accidentally committed a secret to a public repository. Last week, I was designing authentication architectures with managed identities and federated credentials. Same person. Same tool. Completely different confidence level.

This post is about the most transformative phase of my journey: when I stopped using AI for code and content, and started using it for infrastructure, deployment, and DevOps. To me, this is where the productivity gains went from impressive to structural. (I won't pretend the learning curve was smooth — there were definitely some embarrassing moments along the way.)

The confidence ladder

If you've followed this series from Part 1 , you've seen how my relationship with AI evolved: ask → verify → command → collaborate. Nowhere was that progression more visible than in how I approached infrastructure.

Let me show you the actual confidence ladder through my prompts:

Rung 1: "Can you help?" (Week 1-2)

"Can you help make this possible? Ideally, come up with the infrastructure scripts." "What is the correct name for this cloud region?" "I accidentally committed a secret... can you help me rectify this?"

Notice the language: "Can you help?", "Is it possible?", "What is the correct...?" — these are the prompts of someone who doesn't trust themselves to make infrastructure decisions, let alone trust an AI to make them. (I'm not going to sugarcoat it — I was genuinely nervous about breaking things.)

And that accidental secret commit? Well, that happened. That's the kind of mistake that makes you more cautious, not less. At this point, infrastructure felt like a minefield where one wrong move could cause real damage.

Rung 2: "Set this up" (Week 3-4)

"Push this to a new GitHub repo." "Add a GitHub Actions workflow that builds and deploys on push." "The build pipeline gives this error — fix it."

The shift is subtle but important. I'm no longer asking if things are possible. I'm telling Copilot what to set up. I've moved from questions to commands — the same pattern from Part 2 , but applied to infrastructure.

Rung 3: "Automate everything" (Week 5-6)

"Make sure everything regarding deployment is automated. Others will also want to deploy this." "Can these nine separate configuration scripts be deployed automatically with infrastructure-as-code too?"

Now I'm thinking about other people using what I've built. I'm not just deploying — I'm designing for repeatability and maintainability. The ask has shifted from "deploy my thing" to "create an infrastructure system." (I knew very well that this was becoming overkill for a personal project, but pushed through anyway — it's how you learn.)

Rung 4: "You own this now" (Week 7-8)

"Going forward, you can commit and push during our sessions." "Any new feature should go into a feature branch. A pull request needs to be created proactively." "Commit every implemented phase, link to the GitHub issue, push when ready."

This is delegation. Not "help me do X" — but "here's how we work now." I'm defining a development process and trusting Copilot to execute it. Feature branches, PR workflows, issue-linked commits — the kind of practices that teams take weeks to establish. I have been working like this for a few weeks now and it honestly feels natural at this point.

The GitHub integration aha moment

The moment that made git integration click wasn't a single event — it was a cascade. (I'm not going into every detail here — just the highlights that mattered most.)

First: I asked Copilot to push code to a new repository. Simple enough.

Then: I started asking it to commit with meaningful messages. It understood the context of what had changed and wrote better commit messages than I typically would.

Then: I realized it could create GitHub Actions workflows from a description of what I wanted automated. No more copying YAML from Stack Overflow and adapting it line by line. I'd say "add a workflow that builds on push to main and deploys to Azure" and get a working pipeline 😊.

Then: I connected it to GitHub Issues and Projects. I could say "commit every implemented phase and link to issue #41" and it would create properly linked commits, update the issue, and move the project card. The planning loop — from idea to issue to implementation to PR to deploy — collapsed into a single conversation.

The debugging breakthrough: When a GitHub Actions workflow failed, I used to copy the error log, open a browser, search for the error, read through forums, and trial-and-error my way to a fix. Now I paste the workflow output into Copilot and say "fix it." It reads the error, understands the workflow context (because it wrote the workflow), and produces a targeted fix. Deployment debugging went from a 30-minute context-switch to a 2-minute conversation.

Pro Tip: When pasting a failed workflow output, include the full log — not just the error line. Copilot needs the context of which step failed and what ran before it to give you a targeted fix.

The infrastructure evolution in numbers

Here's what happened to the scope of infrastructure I was touching:

Month	Infra files created/modified	What I was building
Month 1	~13	First deployment script. First infrastructure template. First CI pipeline.
Month 2	~20	Multi-module infrastructure (database, monitoring, container hosting, role assignments, authentication, telemetry dashboards)

The file count doesn't even tell the full story. In month 1, I was creating one thing: a basic deployment. In month 2, I was creating systems: infrastructure modules that depend on each other, with security scoped correctly and monitoring built in from the start. The growth feels almost unreal when I look back at it.

The security arc: from accident to architecture

This deserves its own section because it's the starkest example of growth. (And also because I'm slightly embarrassed about the starting point, but hey — transparency is the whole point of this series.)

Week 1: Accidentally committed a secret. Panicked. Asked AI how to remove it from git history. Learned about credential rotation the hard way.

Week 4: Started discussing the difference between API keys and managed identities. Asked AI to explain when to use each.

Week 6: Proactively set up managed identity authentication. Configured scoped role assignments. Asked AI to help me audit which services still used key-based auth.

Week 8: Designed an authentication architecture using federated credentials, OIDC for CI/CD pipelines, and scoped permissions. Built feature toggles for admin-only functionality.

The transformation: from someone who accidentally leaked credentials to someone who proactively designs security architecture. In eight weeks. If you ask me, that's not just productivity — that's genuine capability growth.

And the specific tools that enabled it — Bicep for infrastructure-as-code, Managed Identity for passwordless auth, OIDC for secure CI/CD, Azure's MSAL library for user authentication — went from words I'd heard to tools I wielded, all through conversations with Copilot. I have been using managed identities exclusively for all new projects since, and honestly can't imagine going back to API keys.

The "fleet deployed" pattern

Somewhere around week 7, I invented something I started calling a "fleet deployment." It was a detailed, reusable prompt that I'd run each morning to process my inbox and communications — structured instructions that Copilot would execute consistently.

The prompt was specific: scan messages, categorize by urgency, flag items waiting on me, group follow-ups by person, skip automated notifications, and compile everything into a morning brief.

I refined it over about a week. Each day I'd notice an edge case: "Don't flag calendar invites as urgent", "If someone sent the same request twice, consolidate them."

After a few iterations, I had something that saved me 30-40 minutes every morning. Not occasionally — every morning. That's 3+ hours per week, 13+ hours per month 😊.

But the bigger insight is this: I was treating AI prompts like code. Iterating, testing, debugging, versioning. The engineering mindset applied to workflow automation. The beauty of this approach is that once the prompt works, it works consistently — unlike a manual process that depends on your energy level that morning.

From reactive to proactive

This phase changed my relationship with infrastructure from reactive to proactive.

Before: I'd deploy, wait for something to break, google the error, fix it, redeploy.

After: I'd describe the entire architecture upfront, ask AI to identify potential failure points, build monitoring and alerting from the start, and deploy with confidence.

The shift from "fix things when they break" to "design things so they don't break" is massive. And it was enabled by being able to think through infrastructure at the speed of conversation rather than at the speed of documentation-reading. (I realize this sounds like a bold claim, but it genuinely changed how I approach any new project now.)

The one-afternoon system

Here's a real example of what became possible. In a single afternoon session (over 100 exchanges), I:

1. Took a raw data source and built a web application around it
2. Added authentication and role-based access
3. Created a complete infrastructure-as-code setup (compute, database, monitoring, identity)
4. Set up a CI/CD pipeline with automated deployment
5. Added telemetry and analytics dashboards
6. Debugged and iterated through deployment issues
7. Pushed everything to a repository with proper branching

One afternoon. One conversation. A complete, deployed, monitored, authenticated system.

That's not science fiction. That's what happens when you combine trust in the tool, clear architectural thinking, and the habit of delegating to AI. (Well, and a fair amount of coffee — let's be real about that too.)

You might be in this stage if:

• You manually deploy or configure infrastructure
• Your CI/CD pipeline was set up once and never improved
• You avoid security configuration because it feels complex
• You have "automate this someday" items on your todo list from months ago
• You treat deployment as a separate phase from development

Try this week

Automate one infrastructure or deployment step you currently do manually. Pick the simplest one:

• A deployment script you run by hand
• A configuration you copy-paste between environments
• A monitoring check you do manually
• A build step that isn't in your CI pipeline yet

Describe it to AI with full context: what it does, why it's manual, what could go wrong. Let it generate the automation. Test it. Iterate.

Once you've automated one thing, you'll see two more you could automate. That's the infrastructure flywheel starting to spin.

---

In Part 5 , I'll step back and look at the full picture: what happens when all these layers — trust, depth, breadth, and infrastructure — compound together. The numbers, the honest limitations, and what I'd tell anyone starting this journey today.

This is Part 4 of the My GitHub Copilot Journey series.

Now go ask GitHub Copilot something ambitious. 🚀

Enjoy!

Tim