Human-first AI: build for leverage, not replacement
For most of my career, the core question in software engineering has been some version of this: how do we make it reliable, simple, and useful? AI has not changed that question. It has changed how much is possible when we answer it well, and how much damage we can do when we answer it badly.
The approach I believe in is human-first AI. Not AI for the sake of AI, but AI that gives people more power.
The lever, not the replacement
There is an old idea that with a long enough lever and a place to stand, one person could move the world. What I like about it is who is still in the picture: the person. The lever does not move anything on its own. It turns one person's effort into something much bigger.
That is the mental model I use for AI. The best AI systems move the fulcrum. They let a person apply judgment, experience, and intent to problems that used to be out of reach. The worst ones try to take the person off the lever entirely, and usually end up as systems nobody fully trusts and nobody can easily correct.
AI should augment human capability, not take away human agency.
Three questions I ask about any AI feature
- Does the person stay in charge of the decision? AI can draft, suggest, summarize, and check. The person should still be able to see why, disagree, and change course.
- Does it fit how people already work? If people have to reshape their day around the tool, adoption stalls and workarounds multiply. Good AI shows up where the work already happens.
- Does it make people better over time? Leverage compounds when a tool helps people learn, not only when it saves them a step.
Why high-stakes software sets the bar
I work in healthcare technology. In a domain like that, "the model was confident" is not an acceptable explanation. Reliability, traceability, and a clear human in the loop are not nice extras. They are the product.
I think every domain will eventually hold AI to that standard. People will trust systems that respect their judgment, and they will route around systems that do not.
Engineering principles, evolved
None of this means throwing away what we know about building software. Clear boundaries, well-defined interfaces, testing, observability, and simplicity matter even more when part of your system is probabilistic. What changes is where we apply them: to context and prompts, to the boundaries of what an agent may do, to how we evaluate behavior, and to memory that persists across interactions.
That last one, persistent context, is where I am spending a lot of my time. An assistant that forgets everything between conversations can only ever be a clever tool. One that carries the right context, with the person in control of it, starts to feel like real leverage.
Where I am going with this
I am exploring, experimenting, and building in this space, and I will keep writing about what I learn: what works, what does not, and which old engineering lessons turn out to matter most.
If you are thinking about the same questions, as a builder, a leader, or an investor, I would like to hear from you.
Have a reaction, a counterpoint, or a question? Reply by email. I read every note.