Ben Feely
AI for business, for engineering teams, for product and design, for planning, for writing, for creating. Whatever the work, it always comes back to AI for you. That is what Empowering You means.
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.
01
A few things I've built and shared. I'd rather show the work than describe it.
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 showsBringing AI into real engineering work, inside the tools where the work happens, not as a chatbot off to the side.
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 showsThat 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.
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 showsShipping real tools other engineers depend on, and open-sourcing the parts worth sharing.
02
I'm building a body of work on what it actually takes to bring AI into an engineering organization. The short version:
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.
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.
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.
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.
03
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.
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.
04
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.
05
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 is the curated menu: what this is, who I am, and where to go. /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.
06
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 meLinkedIn (opens in a new tab)GitHub (opens in a new tab)