You Should Have an Autonomous AI Workflow (Even If You Don't Always Use It)
Better to have it and not need it than to need it and not have it.
TL;DR
Having an autonomous AI workflow isn’t about using it for everything—it’s about having the option to delegate, which changes how you evaluate and prioritize work even when you don’t use it.
The real value is reclaiming your time for the parts that matter—planning, designing, deciding—while the agent handles solved problems you’d otherwise re-solve by hand.
The discomfort of letting go isn’t about the agent’s capability; it’s about not yet having confidence in your process—detailed plans, review agents, and quality gates make it safe.
Start with low-stakes work where failure is free, then gradually expand; once you’ve seen an agent build something correctly while you weren’t even there, you won’t go back.
These are the worst models you’ll ever use—building the muscle now means you compound leverage with every improvement, while people who wait will start from scratch.
It was a Wednesday evening, the last working day before the Eid Al Fitr long weekend in Dubai. I had an idea for an internal tool—a test harness I’d been thinking about for a while. The kind of thing that would take a few days of focused work to build properly.
I spent a few hours that evening planning—breaking it down in Plan Mode, and running adversarial sub-agents to poke holes in the approach. By the time I stopped, the plan was almost there, but not quite finalized. I didn’t get time to review the feedback.
Thursday morning—a holiday—I looked at the adversarial feedback, ran my technical-planning skill, and had seven milestones. So I started the agent and left for breakfast with my family.
The first couple of milestones were done by the time we got back. That evening, I clarified a few design decisions and started the next batch. By early noon the next day, everything was ready. All seven milestones complete. Built to spec. 80% test coverage. Quality checks passed.
I haven’t used the tool yet—it’s still the weekend. It’ll probably need a few fixes. But the code is there, and I’m confident it’s close. I got the weekend with my family. I didn’t have to choose.
The planning was deliberate—without it, none of this would have worked. But the stakes were low. If the agent didn’t deliver, I’d build it next week. I lose nothing. That’s how I’ve approached a lot of this. Try it on something where failure is free.
But what actually surprised me wasn’t that the agent could do the work—I had confidence in the process by then. It was how long it sustained without me being at my desk. Every other time, I’d been sitting there or nearby. Available. This time, I was at breakfast, at the mall, putting my son to sleep. And the work kept moving. That intrigued me more than anything.
It’s about having the option
That story isn’t about AI being impressive. It’s about having a choice that didn’t exist before. A year ago, the trade-off was simple: work through the weekend, or the tool waits. Now there’s a third option.
What I didn’t expect was how much the option changes your thinking, even when you’re not using it. Once you know you can hand something off, you evaluate work differently.
In the past few weeks, POCs that would have taken me multiple days have been finished in a few hours. Not because I’m working faster—but because I have the third choice. Plan it, hand it off, and come back to something working.
Spend time on what actually matters.
I love writing code. But I’ve wired models to controllers a thousand times. I’ve rebuilt the same utility functions across dozens of projects. The novelty is gone. These are solved problems I keep re-solving by hand.
When Copilot launched, it handled this kind of work well—Autocomplete for the boring parts. But the boundary kept moving. First it was single lines, then functions, then files. Now it’s moved far enough that I don’t have to write code at all for these tasks.
The principle is simple: don’t re-solve solved problems. Spend time on what isn’t solved yet—the planning, designing, architecting, and deciding exactly how I want something to work. The thinking. That’s where I add value. The AI takes what I’ve decided and makes sure it gets built.
The discomfort of letting go
Letting go of control is uncomfortable. Having an agent work autonomously—not knowing exactly what it’s doing or how it’s making decisions—can feel wrong. Especially if you care about quality. I get that.
But here’s what I’ve found: the discomfort isn’t really about the agent. It’s about not having confidence in the process.
A detailed planning session gives you confidence in direction—you know what will be built. And the process you design around execution gives you confidence in how it gets built. Review agents, validation criteria, quality checks—these aren’t optional extras. They’re what make letting go feel safe. I covered my current workflow in my previous post here.
I didn’t get here overnight. Everyone figuring this out right now is in the same position—it’s a new field, and what works for you might not be what works for someone else.
But you do have to keep pushing the boundary. Every time I hit something I didn’t want to do, or didn’t have the capacity, I’d try pushing the AI to do it for me. Sometimes it worked, sometimes it didn’t, and it’s fine if it didn’t.
Start small, you won’t go back
It started with a small refactor. A utility nobody depended on. The agent got it right. So I handed over something slightly bigger. Then something bigger.
Each time, I watched—how was the code quality? Did it follow the patterns I expected? Were the tests meaningful or just coverage padding? Over months, the answer kept being "good enough to
The scaffolding I built early on—review processes, quality gates, validation criteria—compensated for what the models lacked at the time. But as models and platforms improved, the scaffolding simplified. What used to be a directory structure with state machines tracking tasks is now a few lines in a config file. Same outcomes, less machinery.
And there’s a gateway effect. Once you’ve seen an agent build something correctly—start to finish, while you weren’t even there—you can’t go back to doing everything by hand. Not because you’ve gotten lazy. Because you know what’s possible, and choosing to spend hours on something you could delegate in minutes starts to feel like a misuse of your time.
Build the muscle now
These are the worst models you’re ever going to use. That’s not a complaint—it’s the point.
Models are getting better. Platforms are maturing. The tools themselves have already absorbed the scaffolding I needed six months ago to make autonomous workflows reliable.
You don’t stop building websites because dial-up is slow. You build them because when broadband arrives, you already have a presence, you already have distribution. The people who waited have to start from scratch.
The same applies here. The more you leverage AI now—the more you hand over, the more you build quality into your process—the more leverage you get when the next model drops. You’re not just building a workflow. You’re building the judgment for when to use it and the trust that lets you step away.
What changes
The question used to be: Can I build this? Do I have the time, the energy, the uninterrupted hours?
Now the question is: what do I want to build? And do I want to be the one writing the code, or the one deciding what gets built?
You don’t need a complicated setup. You don’t need to hand over everything. You need a workflow you can use—an option is right there, waiting for you.
Don’t wait for perfect. Start now. Iterate. Start with something where failure is free.
And then go have breakfast with your family.
If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts — what topics around AI and developer productivity are you most curious about?