# Enabling AI, Empowering You. I'm an engineering leader who brings AI into how teams actually build, with rigor instead of hype. The point was never the AI. It's the people it makes more capable. Twenty-five years building software, the last decade at Microsoft, now leading a group of teams learning to deliver with AI. ## The work A few things I've built and shared. I'd rather show the work than describe it. ### AI that draws while you talk A working setup that turns a live design conversation into an evolving system diagram, using GitHub Copilot inside VS Code. The discussion becomes a durable artifact instead of a whiteboard photo nobody finds again. What it shows: Bringing AI into real engineering work, inside the tools where the work happens, not as a chatbot off to the side. Link: https://github.com/benfeely/diagram-workspace ### A second agent that catches the first one cutting corners A reviewer agent that rides alongside the primary coding agent and checks its work as it goes. It hooks into the agent's lifecycle, keeps a running record of what the primary agent is thinking and changing, and runs an independent evaluation on every turn, often with a cheaper, faster model, so the check is a real second opinion and not an echo of the thing it's reviewing. Next to that it runs deterministic checks, like scanning for secrets, before and after the model responds. When something breaks a rule, it blocks, flags it, and logs why. I designed and built it as independent work, and I'm bringing it into how my teams build. What it shows: That excitement about AI and rigor about its output aren't in tension. The useful move isn't to keep checking by hand. It's to build the thing that checks, and keep it honest. ### angular-react An open-source library that lets React components run inside Angular applications, from my platform days. Still public, still referenced by teams who need the bridge. What it shows: Shipping real tools other engineers depend on, and open-sourcing the parts worth sharing. Link: https://github.com/benfeely/angular-react More on GitHub: https://github.com/benfeely ## What I think about I'm building a body of work on what it actually takes to bring AI into an engineering organization. The short version: ### AI enablement is human enablement. The interesting question was never how to enable the AI. It's how the AI makes the people more capable. I design for the human first. ### Discipline over hype. The most useful thing I built this year is a guardrail pattern: a second, cheaper agent whose only job is to catch the first one cutting corners. Excitement about AI and rigor about its output are not in tension. You need both. ### Work in loops, not handoffs. Agents change how work flows. People set intent and judge the result; agents do the drafting and ask when they're unsure. It isn't more work. It's the messy, informal work we always did, finally made visible and structured. ### Keep the source. A prompt that produced an output is source code. Throw it away and you've shipped the jar and deleted the project. I preserve the thinking, not just the result. ## What I'm writing I'm writing a series about what actually changes when agents do the work and you don't. The through-line is simple: the model is the constant, and you're the variable. Each piece takes one place I got it wrong and works out what it means for the rest of us. ### The Thing That Made Me a Good Engineer Was the Thing I Had to Unlearn I caught an agent about to make a mistake and felt good about it, and I was wrong to feel good about it. What I was best at just got cheap, and the job that's left is the one I didn't see coming. Read: /writing/the-thing-i-had-to-unlearn/ Read the series: /writing/ ## Who I am I've spent 25 years building software, the last decade at Microsoft, where I grew from senior engineer to Principal Group Engineering Manager. What I care about, and what I'm good at, is building product close to the people it serves and leading the cross-functional teams that ship it. For the past year I've gone deep and hands-on into AI for engineering: multi-agent orchestration, guardrails that catch an agent cutting corners, and the unglamorous plumbing that lets agents do real work safely. I'm the practitioner who's genuinely excited about what AI can do, and also the one asking whether the output is actually correct. This site is where I work in the open. Less talking about AI, more showing the work. ## See what your agent sees Most of what gets said about building AI-native is about traffic and tooling. The part I care about is quieter. An agent experiences your software the same as a person does. It just comes in through a different door. So you can design for that experience, and it turns out designing for the agent and designing for the human are not opposite jobs. On this page they are the same markdown. This is my small proof of that. The mechanism is small. Ask any page for `Accept: text/markdown` and you get back clean markdown instead of the full HTML. Those are the exact bytes an agent receives, and they are the exact bytes behind the "agent view" toggle at the top of the page. No separate mock, no scraped approximation. One artifact, two readers. Two files sit at the root for an agent that wants the whole site. [`/llms.txt`](/llms.txt) is the curated menu: what this is, who I am, and where to go. [`/llms-full.txt`](/llms-full.txt) is everything, concatenated, for the ones that would rather read it all in a single fetch. I do not expect much agent traffic, and that was never the point. The point is that I would rather show you I think this way than tell you I do. ## Reach out I'm always glad to talk with people working on AI in engineering. If you're wrestling with a hard adoption problem, or just want to compare notes, get in touch. - Email: ben@empoweringyou.ai - LinkedIn: https://linkedin.com/in/benfeely - GitHub: https://github.com/benfeely --- # What I'm writing > The model is the constant, and you're the variable. I'm writing a series about what actually changes when agents do the work and you don't. The through-line is simple: the model is the constant, and you're the variable. Each piece takes one place I got it wrong and works out what it means for the rest of us. ## Read now ### The Thing That Made Me a Good Engineer Was the Thing I Had to Unlearn I caught an agent about to make a mistake and felt good about it, and I was wrong to feel good about it. What I was best at just got cheap, and the job that's left is the one I didn't see coming. July 2, 2026 ยท /writing/the-thing-i-had-to-unlearn/ ## Season 1 A hub-and-spokes series. One is live; the rest are on the way. 1. The hub: the model is the constant, you're the variable. [Coming] The whole argument in one place. AI didn't hit a ceiling. It hit us. 2. I was the bottleneck. [Coming] For years I was the thing every change had to pass through, and I mistook that for being essential. 3. AI's ceiling predates AI. [Coming] The limit everyone blames on the model was already there in how we work. The agent just made it visible. 4. Stop being the gate. [Live] Caught an agent about to slip, felt proud, was wrong to feel proud. The thing I was best at just got cheap. /writing/the-thing-i-had-to-unlearn/ 5. The more I specified, the worse it got. [Coming] My instinct was to pre-chew every step. The agent did better when I said plainly what I wanted and got out of the way. 6. Experience didn't get cheaper. It got repriced. [Coming] The part of my experience that was really just diligence is worth less now. The judgment is worth more. 7. Everyone is a leader now. [Coming] Directing an agent hands you the judgment call that used to be the back half of a career. Ready or not, it starts on day one. --- # The Thing That Made Me a Good Engineer Was the Thing I Had to Unlearn _I caught an agent about to make a mistake and felt good about it, and I was wrong to feel good about it. What I was best at just got cheap, and the job that's left is the one I didn't see coming._ July 2, 2026 A few weeks ago I caught an agent about to make a mistake, felt good about it, and was wrong to feel good about it. I was working through a plan with it. About two-thirds down the list I saw the gap: it was going to mishandle a boundary case on an input, the kind of thing that would blow up the first time the code ran against a real example. I stopped it. "You missed this one. That input will break it." It agreed, folded in the fix, and moved on. And I felt the small, specific hit of satisfaction. I caught that. If I had not been paying attention, that would have gone in wrong. Some version of that feeling has been with me for twenty-five years, long before any agent existed. Anticipating the blind corner is the thing I was good at. I could read a design and feel where it would fail, name the case nobody else had thought through, write the spec so complete that the failure never got a chance to happen. It made me a good engineer, and later it made me a good leader, because I could look at a plan and tell you where the bodies were going to turn up. Every time I caught one, the belief hardened: without me, it stays broken. Here is what took me a long time to admit. I was lying to myself, thinking I was saving work by catching that mistake early. That is not how these agents work. They do not one-shot it. They get it roughly right, then closer, each pass using what the last one revealed. The plan I was reading already had the agent writing tests and running that path against real inputs, and the first time it did, the boundary case I "saved" it from is exactly the kind that trips on the next run. Not every bug surfaces that way, but this kind does. I was treating an iterative experimentalist as a one-shot oracle, reacting to its first draft as if it were the final answer. So when I jumped in by hand, I was not saving the run. I was interrupting a process built to correct itself, and feeling proud of the interruption. The thing I was good at, catching the blind corner, just got cheap. Everything that follows is one argument about that. It did not get cheap because the machine got better than me. It got cheap for a narrower reason. The edge cases that come from a checklist, the ones I was thorough about, an agent now enumerates at least as well as I do, and it never tires of it, never skips the boring ones. The edge cases that come from knowing this system's particular scars, the history nobody wrote down, it cannot see at all. What got cheap was the thoroughness. What got expensive was the judgment. So the honest frame is not that experience is being devalued. It is repriced. The part of my experience that was really just diligence is worth less now. So if I am not the catcher anymore, what is the job? Build the gate. The discipline does not disappear, it moves. "Let the agent iterate and stop checking its work" is exactly the kind of advice that ships a bug. The fix is not to keep checking by hand forever. Stop being the gate. Build the gate, so you do not have to be it. The rigor I used to spend nitpicking a plan in real time goes up front now. I say once, clearly, what "valid" means in this domain, so the agent inherits it on every task, and I build the validation that runs whether or not I am watching. Where you put the gate matters as much as building it. The inner loop is only free when failing is cheap and you can tell, fast, whether it failed. Reversible is not the same as verifiable. A financial calculation can be trivial to rerun and still take a domain expert a day to confirm is right. A concurrency bug can be cheap to undo and effectively invisible to the inner loop until it hits production load. So let the experiment run free in the reversible, verifiable inner loop, and put the gate at the boundary that is expensive or irreversible to cross. Inside, let it run. At the boundary, hold the line. The cross-team dependency that breaks something three teams away is not a thing you catch by hovering over the plan. That is exactly what the gate is for. The gate is not something you build once and walk away from. It encodes my current understanding of what "good" means, so it can be wrong, and it can quietly rot as the system moves. The check that mattered last quarter can keep passing long after the thing it was protecting has changed shape underneath it. And an agent will happily learn to satisfy it without satisfying me, hitting the letter of the rule while the thing I actually cared about slips through. It is something you own and keep honest on purpose. The single point of failure does not disappear when you stop inspecting every change by hand. It moves to the gate, the one thing now running unwatched unless you decide to watch it. When I look back at that moment with the boundary case, what I see is two old habits dressed up as diligence. Fear of the rework drove me to over-specify before the agent ever started, when the truth is the agent does better with a clear statement of what I actually want than with my best attempt to pre-chew every step. Pride drove me to jump in the second it wobbled. And under that pride was the thing I like least to admit. I was trying to stay relevant, and I reached for it in the one place the machine had already taken: the thoroughness, not the judgment. Both were trying to make me the gate, and being the gate, standing in the path of every change to inspect it by hand, is exactly the job that does not scale and exactly the job I should not want. The work that is left when I stop being the gate is leadership work, and what caught me off guard is where it lives now: in the hands-on building itself, not just in running a team. It is deciding what "good" means here, building the validation that lets a team move fast without flying blind, and knowing which boundaries are the expensive ones so you guard those instead of everything. And this is not only my story. An agent is a tireless junior engineer that iterates until the thing works but cannot tell you whether it built the right thing. Someone has to supply that, and supplying it used to be the back half of a career, the part you grew into after years of watching systems break in ways no checklist predicted. The demand for it has not gotten any smaller. It has just moved to the front. Ready or not, every engineer directing agents is being handed the judgment call before they have earned it. The gap between the judgment the job needs and the judgment you have is real, and it does not close on its own. It is the new thing to grow into, and it starts on day one. I spent a long time proud of being the person who caught the mistake. The job now is to build the thing that catches it and keep it honest, spending the scarce judgment where no gate can reach.