I'm Building the World My Kids Will Inherit. That Changes Things.
Most people building AI tools are building for the market. I'm building for my kids. That's a different constraint — and it shows up in every decision I make.
The future isn't abstract when it's sleeping down the hall.
Here's the thing I haven't said out loud yet because it sounds dramatic: every system I build, every agentic workflow I ship, every automation I put into the world — I'm building the world my kids will grow up in.
Not metaphorically. Concretely. My kids watch me work late and ask what I'm doing. They're going to inherit whatever we make. That's not a think-piece talking point. That's my actual life. And once that lands, it changes how you think about what you're building and why.
Why this matters
Most of the discourse around AI and the future of work is framed around productivity, disruption, efficiency, and who gets replaced.
Almost none of it is framed around: what kind of world are we building for the people who haven't gotten here yet?
The kids in classrooms right now are going to enter a labor market we're actively reshaping. They'll use tools we're normalizing. They'll have values about AI that we're setting — because kids absorb what adults do, not what adults say.
And most of us building these tools aren't thinking about that. We're thinking about the next release. Which I get. I do it too. But we're the generation setting the norms, and that's worth naming.
What fatherhood does to your time horizon
Before kids, my time horizon was about three to five years. Ship something, build a company, hit a goal. That was the loop.
After kids, your time horizon extends to twenty years without you trying. You start doing math you didn't ask to do. How old will they be when AI is fully integrated into hiring? What does the labor market look like in 2040? What skills will still matter when they're looking for work?
That's not paranoia. That's just parenting. You can't help but run the numbers.
And when you run those numbers, certain things look different. Automation that feels neutral from a market perspective starts to feel personal. Productivity gains that seem like just efficiency become questions about what work will look like for real people you love.
It's not that the calculation changes. It's that the stakes stop being abstract.
From my own bench
My day job is training healthcare workers on clinical systems. Real people, real stakes, real frustration about tools that weren't built with them in mind. I've spent years watching what happens when technology moves faster than the people who have to use it.
Then I go home and build AI systems at night.
That tension is useful. Because it reminds me that every system I build has a person at the end of it. And that person is not me. They're someone trying to do their job and go home to their family. They're someone's parent, someone's kid.
My kids will be those people someday. So will yours.
That doesn't mean slow down. It means build with that person visible in your mind — a real person, not a user persona in a slide deck.
What I actually want
I want to build tools that compound toward something good. Useful systems, honest in what they can and can't do, that actually help people accomplish things that matter to them.
I'm not naive enough to think every tool I build is automatically that. But I hold the question. What does this do to the person on the other end? Not just in the demo — in deployment. Six months in. When they're tired and the system doesn't work the way they expected.
Fatherhood made me a better builder because it made "the user" someone I care about. It removed the abstraction.
Try it today
| Step | What you do | Why it pays off |
|---|---|---|
| 1. Name one real person | Pick a specific individual — not a persona, an actual person — who will use what you're building | Keeps the work from becoming an abstraction exercise |
| 2. Run the dignity check | Ask: if someone I love used this at a hard moment, would it treat them well? | A gut-check most product reviews never ask |
| 3. Explain it to a kid | Describe what you're building to someone who has no reason to be impressed | Forces honest plain language — and surfaces what you actually believe about it |
Where people get burned
- Optimizing for the demo without thinking about deployment. A system that looks clean in a controlled setting can be brutal when a real person with a real problem and real time pressure sits down with it. Fix: test with the most stressed, most time-constrained version of your user, not the most cooperative one.
- Making "the user" a statistical abstraction. Aggregate personas are useful for scale. They're useless for dignity. Fix: anchor every major product decision in at least one real, named person.
- Building for the market you have instead of the world you're making. The market validates your current assumption. It doesn't tell you what you're normalizing. Fix: hold the long-term question separate from the short-term metrics.
Tools, and a question worth sitting with
- A thing to try: Before your next product review, answer this in one sentence: "What does this make easier for a real person, and what does it make harder?" If you can't answer the second half, you haven't thought about it enough.
- A read: Ruha Benjamin's Race After Technology and Safiya Umoja Noble's Algorithms of Oppression aren't AI hype books. They're documentation of what happens when builders don't hold the end user visible. Worth it even if you disagree with them.
- A question to actually sit with: If the next generation inherits the AI systems you're building today — what do you want them to have?
The bottom line
I don't know if I'm building the right things. I think I'm trying. I hold the question more than I used to.
The future is going to be inhabited by people I love. That's the constraint that changes everything for me.
— Dru Edwards