← All writing

Lessons From Teaching My Team AI

I tried to bring the way I work with AI tools to my team and packed in everything at once. It was too much. What I learned about meeting people where they are, protecting existing workflows, and building an AI-first mindset instead of forcing a framework.

I tried to bring the way I work with AI tools to my team, and I went a little crazy.

I'm a software engineer at Keysight on the EDA AI team, building AI components that get integrated across our EDA products. I've spent the last two years living inside these tools, and at some point that stopped feeling like an advantage and started feeling like something I could just hand over. So I tried to hand over all of it at once.

I tried to give them my whole setup at once

I built agent harnesses for a couple of our codebases and packed in everything I use: an AGENTS.md, a pile of skills for each repo, hooks that auto-updated our skills repository and the harness itself, and multi-agent support so the same setup would work across Cursor, Claude, and Copilot. The centerpiece was a continuous-learning hook that fired at the end of every turn and prompted the agent to update our skills based on whatever it had just learned.

I was proud of it. On my own machine, a version of this is genuinely how I work. But dropped on a team all at once, it was way too much to absorb.

The feedback that reframed it

The note I got back was simple: focus on the things that are universally applicable and undeniably beneficial. Not the clever thing. The obvious win everyone can use on day one.

That landed, because my drafts were guilty of the opposite. They imposed too much change on people's existing workflows, and some of what I was asking them to adopt wasn't even proven. The continuous-learning hook is a good example. I hadn't fully tested that exact implementation myself. I was trying to recreate an idea from my own system in a more digestible form, and even the digestible form was a step too far.

What I was taking for granted

Here's what I missed. After two years in these tools, I take for granted the mindset that "we need this" or "this will be a major productivity win." To me those things feel self-evident. To someone who hasn't lived in the tools, they're just claims attached to a bunch of new files to maintain.

My team uses the coding prompt editor to support their work. That's the right place for them to be right now. They don't live in the prompts or the agent chat the way I do, and expecting them to jump straight to my setup skips the part where that mindset actually gets built. I need to meet them where they are, not where I ended up.

The shift I forgot I'd made

When I think about my own path, it makes more sense why this is hard. It's a big step to go from reading the code directly and telling the agent every small action to take, to letting the agent do the writing while you do the verification. That's a real shift in how you work and how much you trust the loop. It took me time to make it. I can't expect the team to skip that step just because I already took it.

What I'm taking forward

A few lessons I'm building into the next version of this:

  1. Tailor the harness to protect existing workflows, not replace them. The goal is to make the way people already work better, not to hand them a new way of working and hope they adjust.
  2. Think about scale. Before adding anything, ask how the concept applies across the team, the org, and the company. If it only makes sense for one person's setup, it isn't a standard yet.
  3. Share the wins. A lot of the hesitation is that people aren't bought into the upside yet. Right now it can look like I'm adding markdown files that need maintaining, with no clear vision for why that maintenance pays off. That's on me to show, not assume.

The real goal isn't the harness

The harness was never the point. The point is instilling an AI-first mindset. When someone learns something hard, or works with the agent to solve a genuinely tricky problem, the habit becomes: take that learning and encode it into the harness so the whole team benefits the next time it comes up.

That's the difference I keep coming back to. These are standards I'm building with the team, not a framework I'm forcing on them. One of those gets adopted. The other gets tolerated until someone quietly turns it off.

Let’s find the delivery margin you’re leaving on the table.

Book your free intro call. Thirty minutes to walk me through your ops and find out where the margin is leaking.