Reflections on being a technology co-founder in an AI-native engineering team.
It’s surprisingly easy to make software appear fast now.
You describe an idea, an AI assistant turns it into components and code, and soon there’s something running in a browser. For a founder building with a small team, that changes the economics of experimentation. Things that once needed weeks of back-and-forth can begin as a working conversation.
But building something quickly and building something you can trust are very different achievements.
My background is in performance engineering. I spent years looking at systems through a less glamorous lens: what happens when they slow down, when dependencies fail, when data doesn’t behave as expected, or when the real world refuses to follow the happy path.
That background shapes how I approach building YORO Health today.
We are building a product where software connects to real care delivered by real people. A screen can look finished while the workflow behind it is still fragile. A feature can pass a demonstration and fail the first time a booking changes, a reminder is duplicated, or a family needs a human response.
This is where I think AI-native engineering gets misunderstood.
AI-native doesn’t mean prompt-and-ship
We use AI throughout the building process, not only to write code but to challenge ideas, explore workflows, surface edge cases, evaluate design choices, and review what has been implemented.
The useful question is not, “How much code did AI generate?”
It’s, “Did we understand the problem better, consider the consequences, and produce something more dependable?”
For me, a feature starts with people. Who is using this? What are they trying to accomplish? Where might the experience become confusing? What happens when it doesn’t work?
Only then does it make sense to talk about the software. The proposed solution has to fit into an existing product, not behave as if it were the first feature anyone had built. Data, permissions, performance, reliability, and the experience of the people operating the service all matter.
AI is very good at giving us possible answers. It is not a substitute for deciding which answers are appropriate.
A working demo is the beginning of the review
One of the traps of AI-assisted development is how convincing the first result can be. Polished screens create a sense of completeness. Clear explanations can create a sense of correctness.
Neither is evidence on its own.
We try to challenge what has been built: Does it match the original need? What else could it affect? Can people recover from mistakes? Is the experience clear on a small screen? Are we introducing complexity we’ll have to carry for years?
In healthcare, the cost of a confusing workflow isn’t just a poor conversion rate. Sometimes it’s an anxious family or a care team missing important context. That’s reason enough to keep people accountable for consequential decisions.
The engineering role is changing, not disappearing
I don’t think the interesting future is one where developers become experts at asking a model to generate more files.
It’s one where a small team can develop stronger judgment because it has better tools to explore choices, test assumptions, and catch gaps earlier.
That requires a change in what we value. Less emphasis on the volume of code written. More emphasis on clarity of requirements, quality of decisions, observability, maintainability, and whether a feature actually improves the product.
I’m learning this in real time, while building a company. We haven’t solved every part of it, and I wouldn’t pretend otherwise. But the direction feels clear.
AI should increase the reach of an engineer’s judgment, not become an excuse to stop exercising it.
That’s the kind of AI-native engineering culture I’m trying to build.