I Automated a 40-Hour Week. The Hard Part Wasn’t Technical.
If your business depended upon you making the most of your time, what are the 4 hours you would fight hardest to keep?
7/24/20264 min read
The founder I was working with had one word for what he wanted: fast.
He’d earned the urgency. Early-stage company, short runway, a market that wasn’t going to wait for us to get organized. And the product operation around him was anything but fast. Feature requests arrived through email, Slack, customer calls, and shared Notion pages — no consistent format, no dedupe, no single source of the truth. The roadmap in Notion and the backlog in Linear drifted apart within days of every manual sync. Release notes came together by hand. In my first week I counted the cost: roughly forty hours, every week, of pure information-movement. None of it made the product better.
So I gave him fast.
The first thing I built wasn’t automation, though. It was a decision. Before a single workflow ran, I mapped the authoritative source of truth for every stakeholder — feature requests and product decisions lived in Notion, engineering work lived in Linear, what-shipped lived in the release notes — and defined the contract between tools, so nothing existed in two places without a rule for which one wins. It wasn't pretty. It’s also the reason the automation held. Before you automate, you have to decide. And deciding is a human job.
With that settled, I spent the next month building an AI system to do the busywork, which included six connected workflows that captured and deduped requests from every source, classified and prioritized them, wrote the user stories, kept Notion and Linear in sync, generated the release notes, and surfaced what was actually in the sprint. Forty hours of weekly overhead dropped to minutes. Tickets per cycle went from eight or ten to more than fifty. We stopped losing issues entirely.
Building that took a month. The harder question took longer: which four hours still needed a human, and why.
When I first read the founder’s feature list, I didn’t believe a fraction of it. A younger version of me would have opened a roadmap debate in week one, armed with reasoning, ready to be right. Instead, I built his list. All of it. When shipping becomes nearly free, you don’t have to win arguments with words. You can be generous, prove what the team is capable of, and let results make the case.
And the results made a case, but not just the one I expected. Once we could build anything quickly, it became obvious that speed was no longer the constraint. The system could produce whatever we asked. It could not tell us what was worth asking for.
That’s what the four hours were. It wasn't the tasks the AI couldn’t handle, but all of the decisions only a human should own. I kept the priority calls. I kept the weekly review where the system proposed rule changes based on what it had gotten wrong, and I approved or rejected each one.
And I kept every customer conversation. Our voice-of-customer program wasn’t a survey tool; it was me, on calls and email threads with early customers, listening the way you can only listen when busywork isn’t waiting for you afterward. Those hours produced our first sale. Those relationships were ones I could return to, and did, several times before the engagement ended, because the first conversation had been a real one.
“Trust, but verify” has become the standard advice for working with AI. I’d add that you also have to be qualified to verify. Verification is only as good as the verifier.
I wasn’t the human in the loop because I was uncomfortable handing work to a machine. I was in the loop because fifteen years of watching customers work is what made my review worth anything. When the system flagged something as a top priority, I could tell whether it was right and not by instinct alone, but by pattern recognition earned the slow way. That judgment is precisely the thing you can’t automate, because it’s the thing doing the verifying.
I’m not the only one who figured this out. Andrej Karpathy describes AI autonomy as a slider: push it up only as far as your ability to verify allows. The generation is cheap. The qualified verification is the bottleneck.
And if you believe you’d catch the errors anyway, the research is humbling. A randomized trial by METR found that experienced developers using AI completed real tasks 19% slower, and walked away believing they’d been 20% faster. A thirty-nine-point gap between feeling fast and being fast, among elite engineers. There weren’t a lot of engineers who got caught, but the number wasn’t zero. I don’t take that as an argument against AI. It’s an argument for measuring, and for staying humble about your own speedometer.
A nail gun doesn’t make you a carpenter. It makes a carpenter faster, and it makes an amateur dangerous at exactly the same speed. The tool amplifies whatever judgment is holding it.
The founder got his fast, more of it than he asked for. But the moment that stayed with me was smaller. An early customer, on our second email, opened with the confession that they had been keeping a list of things that they thought would be helpful. The sharing of that list is what got to me. That’s what the four hours bought: trust, not throughput.
If I were your coach, I’d ask you one question: of the forty hours your team will spend this week, which four would you insist stay human? Not because AI can’t do them, but because those four are where you’re the most qualified verifier your company has.
