# 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 I wrote this one up on LinkedIn: https://www.linkedin.com/pulse/what-your-design-meetings-drew-themselves-ben-feely-50ikc/ ### 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/ ### I Learned This on an Assembly Line The first thing I ever built was an assembly line, and it taught me the thing I've spent twenty-five years relearning. You don't fix the bottleneck, you fix a bottleneck, and the next one steps up. AI didn't change that, it just moved the constraint faster, toward the one part no vendor sells you. June 30, 2026 · /writing/assembly-line/ ## 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. ## Elsewhere on LinkedIn A couple of earlier pieces that live on LinkedIn, from before I started writing here. ### What if your design meetings drew themselves? The write-up behind the live-diagram setup: a design conversation that turns itself into a system diagram as you talk. Read on LinkedIn: https://www.linkedin.com/pulse/what-your-design-meetings-drew-themselves-ben-feely-50ikc/ ### Humans + Agents: The future of engineering collaboration An earlier take on how people and agents divide the work of building software. Read on LinkedIn: https://www.linkedin.com/pulse/humans-agents-future-engineering-collaboration-ben-feely-3c92c/ --- # 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. --- # I Learned This on an Assembly Line _The first thing I ever built was an assembly line, and it taught me the thing I've spent twenty-five years relearning. You don't fix the bottleneck, you fix a bottleneck, and the next one steps up. AI didn't change that, it just moved the constraint faster, toward the one part no vendor sells you._ June 30, 2026 First published on LinkedIn: https://www.linkedin.com/pulse/i-learned-assembly-line-ben-feely-7eq6f/ ![Ink-and-wash illustration of a worker at an assembly line who has just fixed his own station, wiping his hands, looking up to see the machine downstream jammed and overflowing with parts. The jammed station glows amber. Captioned "Chasing Bottlenecks."](/writing/assembly-line/cover.png) The first real thing I ever built was an assembly line. I was still in college, running a small manufacturing operation, and one station had to lay down a precise amount of a granular material on every part that came through. So I built the dispenser for it out of eBay parts and scrap: a little rig that sensed when it had let out exactly enough, snapped shut, and reset for the next one. I got that station humming and felt like a genius for about four seconds. Then I looked up and the line was already backing up somewhere else. The thing I'd just fixed wasn't the slow part anymore. Something downstream was, and it had been the whole time, hiding behind the station I'd been obsessing over. That's the day I learned the thing I've spent twenty-five years relearning: **you don't fix the bottleneck. You fix *a* bottleneck, and the next one steps up to take its place.** It never feels finished, because it isn't. The chase is the work. I'm doing the exact same thing right now, except the line is the way my teams build software, and what's speeding up the stations is AI. The part that surprised me isn't that AI is fast. **It's that it didn't change the game at all.** It just moved the bottleneck quicker, and it moved it somewhere I didn't expect. Under all the noise, here's what's actually happening. AI doesn't lift a whole process at once. It cheapens one step at a time: code first, then the planning around it, then parts that were never about code. And every time one step gets cheap, the work doesn't shrink. It slides to the next step nobody's touched yet. **Relieve the tightest point and you expose the one behind it.** That's the oldest rule in operations, and AI just made it run faster. The catch is *where* the bottleneck is sliding to. The model is rented, and it keeps getting better on someone else's schedule. The tools that drive it are rented too. What's left, the part no vendor sells you, is whether the agent can see your world and act in it: **the context only you have, and the autonomy only you can grant.** So the constraint keeps sliding toward us. That sounds like bad news. ![Ink-and-wash illustration: an engineer holds two amber keys labeled "Context" and "Autonomy" in front of a locked iron gate, while the rented model and tools sit faded and tagged "rented" behind him.](/writing/assembly-line/context-autonomy.png) > It's the best news there is, because it's the part we can actually change. That's the whole thing I care about, and it's why I think *enabling AI* and *empowering you* are the same sentence. Both are one move: **find the constraint and take it out, in the system and in the person.** And it never ends, because the constraint never stops moving. So here's what I'm going to do in my articles here... I'll take the real processes we all live in (the way software actually ships, the way an incident gets communicated, the way a quarter gets planned) and walk the bottleneck as it slides. What AI just made cheap. What that exposed. And what it takes to open the next tight point. Every piece, the same picture: a *flow*, with its constraints, turning green one step at a time. ![Ink-and-wash infographic titled "Find the Bottleneck." The software lifecycle is laid out as stations from Requirements to Production, each staffed by robot and human figures showing how much AI does the step. Integration Tests is buried in an amber overflow and marked the bottleneck. Three panels below read "One Step at a Time," "The Bottleneck Moves," and "The Chase."](/writing/assembly-line/find-the-bottleneck.png) I still remember the feeling on that assembly line: the four seconds of pride, then the next slow station lighting up. I used to think the goal was to make it stop. It wasn't. The goal was to get good at the chase, because the chase is the job. It always was. So before I break down the first flow, do the thing the assembly line taught me. Pick a process you run, and find the one step everything else waits on. That's your bottleneck. I'm genuinely curious where you're all seeing it: **what's the step everything in your world is waiting on right now - AND - can AI help with that step?**