I gave a talk called Leveraging AI in Development Workflows to 47 engineers at BMO. The subject was guardrail setup and enterprise code quality standards, and it closed with open Q&A. Presenting AI coding tools inside a regulated bank takes more than capability demos. It takes acknowledging the fears people will not say out loud, headcount, craftsmanship, accuracy, and showing the guardrails that make the tool compatible with the environment.
I am writing this from memory and from my own notes, not from a recording, so read the structure below as the shape of the session rather than a transcript. The parts I can be precise about are the reasoning: why I picked that subject, which demonstrations are worth the time, which objections deserve a real answer, and what I would change if I ran it again.
Why I Became the One to Drive This
I was not assigned this. I proposed it because I had been using AI tools every day in my own Angular work for years, had configured my team's assistant, GitHub Copilot Business, with guardrails, and had walked the developers on my team through working with it. The productivity difference was large enough that keeping it inside a team of five felt wrong. People I respected were spending afternoons on work the tool handles in seconds.
The other motivation was more pragmatic. AI adoption in large organizations tends to happen in one of two ways: top-down mandates that create compliance without genuine adoption, or bottom-up organic spread that is slow and uncoordinated. A structured showcase that acknowledged the real concerns while demonstrating real value seemed like a faster path to the outcome I wanted. Teams using these tools effectively and safely.
Choosing the Subject
Most of the preparation went into three things: working out what the audience was actually worried about, choosing demonstrations that would be credible to experienced developers, and anticipating objections well enough to answer them honestly. The capability half was the easy half. Anyone can make an AI assistant look impressive for ten minutes.
I did not run a survey and I would not read much into one if I had. I went in with the concerns I had heard in general conversation about these tools and the ones I had had myself: security and compliance risk, code quality and correctness, and a more personal one I decided to handle separately. The suspicion that an interest in AI tooling is really an interest in doing the same work with fewer people.
Addressing the Headcount Fear First
I put the headcount question in the opening rather than letting it sit under the Q&A waiting to be asked. The framing I used: I cannot speak for anyone's long-term plans, but my own position is that these tools are about the quality and impact of the work, not about replacing the people doing it. Judgment, domain knowledge and system understanding do not automate. The work that automates is the work nobody enjoys.
I would keep that order. A concern that size colors everything said after it, and a room that suspects a hidden agenda does not ask real questions when you open the floor. Say it out loud before the first demo, or spend the rest of the session talking past it.
How I Would Structure the Session
The structure worth keeping is short framing, most of the time on live demonstrations, a walkthrough of the guardrails, and then open Q&A with no fixed end. Keep the slide count low. Engineers do not need a deck. They need to watch working code appear and then watch you check it.
- Framing: what the session covers, what it does not, and the headcount question addressed up front
- Test generation: hand the assistant a function with awkward edge cases and build the suite live
- A mechanical refactor: a pattern migration everyone in the room has done by hand
- A debugging walkthrough: describe a concurrency bug to the assistant and work through its analysis out loud
- Guardrails: the Copilot Business setup, repository custom instructions, and the pipeline that rejects bad code regardless of who wrote it
- Open Q&A, with no fixed end time
The Demonstrations That Land
Test generation is the one that lands. Take a function with a messy set of edge cases, describe it, ask for a suite, and the file comes back in under a minute with boundary cases a developer under deadline pressure would skip. It is the least glamorous capability on the list and the most convincing one, because everyone in the room has postponed writing exactly that file.
Use code the audience recognizes the shape of. Not code from the repository sitting in front of them, which raises its own questions in a bank and is a conversation you do not want in the middle of a demo, but the same framework, the same conventions, the same kind of function they touched last week. A toy example lifted from a tutorial reads as a sales pitch and gets treated as one.
The debugging demonstration is the second strongest. A race condition is a good candidate: two concurrent requests where the result has to reflect the last one initiated, not the last one resolved. Show the bug, describe it in plain language, and walk through the analysis out loud. It reaches switchMap quickly. What is on display is not the answer, it is how fast you get to a hypothesis worth testing.
The Demonstration That Falls Flat
Generating a component from scratch is the weak demo. The output is correct and experienced developers are unmoved, because they can write that component in five minutes anyway. I had misjudged the value proposition. Scaffolding speed matters when you are generating many components at once, or when the scaffolding is genuinely intricate. For one straightforward component it is a rounding error.
I would replace it with AI-assisted code review. Run Copilot code review on a pull request, then compare what it flagged against what the human reviewers flagged. That is the use case that surprises experienced developers, because it surfaces the issues they would catch on a second read and miss on a first read under time pressure.
The Objections Worth Preparing For
The Q&A is where the real work happens. I had prepared for security and compliance questions and those came, and I had good answers. The two objections I had underprepared for were not about security at all.
The first is the craftsmanship objection: generating code rather than writing it produces developers who understand their systems less deeply over time. That one is not wrong, and it deserves a real answer rather than a brush-off. The same argument was made about IDEs, about frameworks, about copying from StackOverflow, and in each case the answer was not to refuse the tool but to be deliberate about when to use it and when to write from scratch to build or keep the understanding. Say plainly that it is a genuine risk, because it is.
The second is the accuracy objection. It gets things wrong. Yes, it does. AI output requires review, always. The gain is generating a first draft in thirty seconds that a senior developer then reviews and adjusts, instead of typing that draft yourself. Ship AI output unreviewed and you will have a bad time, and that is a workflow problem, not a tool problem.
What Actually Moves a Skeptic
If the objection is security, the guardrails walkthrough is the part that matters. Seeing the rules written down as concrete Copilot instructions, and seeing the CI gate that rejects the code regardless of who or what wrote it, moves the frame from this tool is a liability to this tool can be configured and fenced.
If the objection is quality, show the tool getting something wrong. Ask a follow-up that leads it down a bad diagnostic path, catch the error in its reasoning out loud, and correct it. A demo where everything works is a sales pitch. A demo where you catch the mistake makes the actual point: the review skill is still yours, and AI speed plus senior review beats either one alone.
What Changed Afterward
I did not run a formal adoption measurement, and that is the gap I would close first. I had follow-up conversations, not a dashboard. So I cannot tell you what one session changed across 47 people, and anyone who hands you a clean adoption number from a single talk is guessing.
- On my team, nothing had to change: the assistant was already configured with guardrails and the developers were trained. The talk mostly gave that workflow more legitimacy
- That team finished development of an AML compliance project about 35% ahead of schedule
- Beyond my team, I shared the custom instructions file with anyone who asked. Several attendees came back with questions about adapting it to their own repositories, which was the signal I cared about
- What I do not have is a number for organization-wide adoption. I had conversations, not a dashboard, and I would agree on a lightweight measure before the session next time
Lessons for Anyone Driving AI Adoption in Engineering
The process taught me more about change management than about AI. Technically sophisticated people do not need to be sold on capability. They need their concerns addressed honestly. The pathway to adoption is acknowledging the legitimate risks, demonstrating that those risks can be managed, and showing the value with code they recognize from their own work.
- Use code that looks like the audience's own work. A tutorial example reads as a sales pitch
- Address the headcount concern explicitly and early. It colors everything else if left unaddressed
- Show AI getting something wrong and the recovery. It builds more confidence than a flawless output
- Bring the guardrails configuration and the CI gate, not just the capability. In a regulated environment the safety layer is the interesting half
- Let Q&A run long. The real questions, the real objections and the real interest surface after the prepared content ends
- Seed the follow-up by finding two or three engaged attendees and giving them something specific to try that week
- Decide before the session how you will know it worked. I relied on conversations afterward, and even a three-question follow-up would have made the case for the next session easier
The goal of a showcase is not to generate enthusiasm. It is to lower the activation energy for people who are already curious but have not acted. You do not need to convince everyone in the room. You need to give the interested ones the tools and confidence to try.
If you are a senior engineer or tech lead considering a similar initiative in your organization, my strongest advice is to start with the people who are already curious. Find three engineers who have expressed interest in AI tools, work with them for two weeks, document what they learn, and then bring that combined experience to a larger group. Peer evidence is more persuasive than a showcase by a single advocate. That is the one thing I would do differently. I would have had co-presenters from other teams rather than presenting alone.
References
- GitHub Copilot repository custom instructions. https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
- GitHub Copilot. https://github.com/features/copilot