The stuff nobody tells you about using Copilot in real projects

The AIE Core Technology Group hosted a 2-hour live Copilot working session with the engineering team focused on:

Here’s what no “10x your productivity with AI” post will tell you:

Most early Copilot sessions will waste tokens.

Significant time was spent having Copilot explore a microservices-based project codebase that was unfamiliar. A lot of what happened was essentially token usage for exploration and understanding.

But here’s the non-obvious part:

The developers who already owned that codebase should have approached it differently.

They already knew:

For them, the right move was to bring that knowledge directly and use Copilot only for the parts where it genuinely saves time:

The lesson isn’t: “Use Copilot for everything.”

It’s: Know when human context is faster, and use Copilot for the rest. The most impactful Copilot artifact wasn’t code. It was a markdown file. A CLAUDE.md file was created in the repository root.

It told Copilot:

Then — and this is the part most teams miss — after the session ended, Copilot was asked to update that file with everything learned during the session:

That file compounds over time. Every session makes the next session better. Every teammate who opens the repo starts with richer context. It’s not just documentation for humans anymore. It’s documentation for an AI coworker — and possibly one of the highest-leverage investments a software team can make today.

Copilot found a dependency the developer missed

During the planning phase, Copilot identified that a change in the integration adapter library required a corresponding change in the promotion engine microservice. This wasn't in the Jira ticket. The developer who owned the task hadn't called it out

Copilot caught it because /plan mode reads the entire codebase, including dependency trees, before generating its implementation plan

This flips the usual narrative. We talk about AI hallucinating or getting things wrong. But in cross-service architectures, Copilot's ability to trace dependency chains across repositories is genuinely superhuman. Not because it's smarter - because it's willing to read every file before forming an opinion. Most of us aren't

"It's easier to edit than to create" is the real unlock

The team framed it as follows: ask Copilot for a first draft of anything - a charter, a story breakdown, a test plan - and you get something "free." It won't be perfect. But starting from a 70% draft you can edit is dramatically faster than starting from a blank page

This applies even to project charters and OKRs (Objectives and Key Results). They were feeding Copilot prompts like:

"give me a candidate charter for migrating this set of services to a new integration pattern"

The output included structured documents covering rollback strategies, backward compatibility concerns, and definition-of-done criteria that had not yet been considered.

They weren't. Copilot was

The role-shifting trick nobody talks about

They can ask Copilot to adopt a role before answering

This isn't just prompt engineering. It genuinely changes the lens Copilot applies. The gap analysis it produces as an "architect" emphasizes system boundaries and integration points. The same codebase reviewed as a "QA engineer" surfaces edge cases and error handling gaps

A single developer, armed with these role prompts, can simulate the perspectives that used to require scheduling a meeting with three different people

The team that saves prompts wins

The architect saved his successful plan as a .prompt.md file and committed it to the repo. Next time anyone works on a similar task, they don't start from zero - they start from a proven prompt

Over months, a repository accumulates a library of prompts that encode how your team thinks, what your architecture looks like, and how your services interact. It's tribal knowledge made reusable - not just for humans, but for AI

Nobody talks about prompt libraries as a team asset. They should!

The honest part: setup is still painful

The first 20 minutes of the session were pure troubleshooting

This is the real adoption barrier - not "will developers use AI" but "will developers survive the setup process." If you're rolling this out to a team, invest in a setup guide that's been tested by someone who's never done it before. The one-time pain is worth it, but don't pretend it's one-click

The bottom line:

The developers who are getting real value from Copilot aren't the ones using it most. They are the ones who know exactly when to use it and when not to

And they treat Copilot like a capable but junior coworker - fast, eager, and in need of direction

The rest is just typing