Copilot Did the Work. I Made the Calls.

I opened this repository in Visual Studio Code as a deliberate exercise. Not because I needed to write code for my day job, but because I wanted to know whether a manager, using modern tooling, could build a real engineering blog without overdesigning it first.

I'll be direct: I felt out of my comfort zone at points. I found myself asking Copilot to explain what it had just written, not to rubber-stamp it, but because I needed to understand it well enough to make decisions about it. That is a different kind of fluency than writing code from scratch, and it turned out to be enough.

I'm sharing this on the Sage Engineering blog because the approach matters beyond this specific project. If we're serious about AI-assisted development at Sage, the question isn't just which tools we use — it's how we use them. Outcome-first, judgment-led, with the right engineering review at the right moment. This is an attempt to make that model explicit.

This isn't a hypothetical design doc. This repo is the blog. The site, the content workflow, and the deploy story are all here.

Why the repo is the point

The goal wasn't a perfect architecture. It was to answer a clear question quickly: can I build a real engineering blog as a manager, use tooling to move fast rather than overdesign, and get something runnable far enough before asking for a production review? If the answer is yes, then the repository itself becomes the blog: the code, the content, the documentation, and the deployment flow all in one place.

What I used

The site runs on:

• Astro for static page rendering and site composition
• Keystatic for content editing and authoring
• AWS S3 + CloudFront for hosting
• GitHub Actions for PR checks, preview deploys, and production deploys

The repo also includes developer validation commands in package.json:

• npm run dev
• npm run cms
• npm test
• npm run lint:all
• npm run build

Those commands are the practical contract for a working engineering blog repository.

Architecture in this repo

The site is authored in VS Code, stored in GitHub, built in GitHub Actions, and deployed to AWS S3 and CloudFront.

The workflow I followed in VS Code

The workflow started inside Visual Studio Code, not in a conference room.

1. I used Copilot to help turn the idea into a concrete plan.
2. I decided what the site needed now and what could wait.
3. I began implementing the plan in the repository.
4. I kept the scope small and outcome-focused: content publishing, preview deploys, production-ready infrastructure.

At one point, Copilot wanted to take me down a Lambda path to get the site running quickly. Serverless functions to handle routing, dynamic responses, the works. I pushed back. It felt like infrastructure for the sake of infrastructure — complexity that served the tool's defaults, not the outcome I was building toward. S3 and CloudFront give you a static site that is fast, cheap, and operationally simple. That is the right answer for a blog, and it was a decision I had to make deliberately rather than accept. I redirected Copilot, made some of those calls manually, and kept the architecture where it needed to be. The tool is only as outcome-focused as you are. My judgment set the direction; Copilot filled in the work.

That sequence matters. It is not about having every detail nailed before writing any code. It is about using tooling to make the first working version real and meaningful.

What this repo already proves

This repository already contains the crucial pieces for the blog:

• src/pages/index.astro renders the site homepage and blog list
• src/content/posts/ holds published posts as Markdoc content
• src/content.config.ts defines the content schema and validation
• infra/ contains the AWS CDK infrastructure configuration
• README.md documents publishing, local development, and deployment workflows

Those are the ingredients of a real blog, not a sketch.

Where the gap still exists

The tools got me to a real repository quickly. But there is a gap between a working repo and production readiness.

That gap is the production mindset. A Principal engineer in my area reviewed the repository before it went anywhere near production. The specific risks we worked through included: IAM permissions boundaries between preview and production environments, CloudFront distribution configuration and cache invalidation behaviour, S3 bucket policy and public access controls, and whether the GitHub Actions deployment flows correctly separated preview from production at the secrets and environment level. None of those are things Copilot gets wrong exactly — but none of them are things you want to discover in production either.

I got the solution far enough that it was useful and demonstrable. Then I brought in the right person to validate the path forward.

The manager-led lesson

Modern tooling collapses the gap between having an idea and having something real. VS Code and Copilot let you plan and implement quickly, without needing a full design process before learning from a working version. Getting something demonstrable before seeking perfection is more valuable than extended design conversations.

But the final handoff to production still benefits from experienced engineering review. Not because the manager-led work is wrong, but because the production mindset is a different skill. Bringing a Principal engineer in at the right moment is not a concession; it is the correct engineering decision.

For Sage Engineering, this matters in both directions. Managers who engage directly with the technical layer, using AI tooling to get closer to the work, create better conversations with the engineers doing that work. And engineers working alongside managers who have genuine skin in the build tend to produce more outcome-aligned results. The Principal engineer who reviewed this repository didn't just validate the infrastructure; they shaped it. That collaboration is the model worth repeating.

Start with the outcome. Build the minimum useful thing. Bring in the expertise to make it safe to ship. The repo is the evidence that it works.