How long my automation projects actually take
People ask me some version of this question a lot: "how long would it take to automate X?" They usually want a number. A week. A weekend. An afternoon. I get why. But after running automation in production for a while now, across content pipelines, local rendering, and agents wired into real tools, I've learned that the honest answer is almost never the number people expect, and the reason has very little to do with the AI part.
The three-day myth
There's a persistent idea that automation projects are fast because the AI does the hard part. You describe the task, the model figures it out, done. In practice the model call is the fastest and least risky piece of the whole thing. Getting a large language model to summarize a document, classify a ticket, or draft a script takes seconds. Nobody argues about that part.
What takes time is everything around that call: getting the right data into the model, getting a usable result out of it, handling the cases where it's wrong, and making the whole thing run again tomorrow without you sitting there watching it. That's the part that doesn't compress just because the AI step is quick.
What actually eats the time
When I break down a project after the fact, the hours land in a fairly consistent pattern:
Wiring, not thinking. Connecting a script to an API, a file system, a database, or a browser is where most of the debugging happens. Auth tokens expire. Rate limits kick in at the worst moment. A tool's documented behavior doesn't match its actual behavior. None of this involves the AI at all, and none of it shows up when you're estimating "how hard is this task."
Edge cases you didn't think of on day one. The first version of any pipeline works on the happy path within an hour or two. Then you run it on real input and discover the input isn't clean. A filename has a space in it. A webpage changes its layout. A file is twice the size you assumed. Each of these is small, but they arrive one at a time over days, not all at once, so the project feels like it keeps "almost" being done.
Making it survive without you. A script that works when you run it by hand is a different project from a script that runs unattended on a schedule and recovers from its own failures. Logging, retries, and a way to notice when something silently stopped working are usually more code than the automation itself. This is the step most people skip when they estimate, because it's invisible until the thing breaks at 3am and nobody knows for two days.
The human checkpoint. A lot of real automation isn't fully autonomous by design. If a step produces something that goes out publicly, like a video, an email, or a published article, there's usually a point where a person should look at it before it ships. Building that checkpoint in, and deciding what triggers it, adds time that has nothing to do with the model's capability and everything to do with how much you trust the output.
A pipeline that touches multiple steps
The projects that take the longest are the ones with several stages chained together, where each stage's output feeds the next. Think: pull source material, generate a script, turn that into audio, render video, then publish. Each individual stage might be something you could build in an afternoon on its own. Chaining them together is where the real time goes, because a small formatting mismatch between stage two and stage three doesn't show up until you run the full chain, and by then you have to trace it back through everything upstream.
This is also where partial failures get expensive. If stage four fails silently and still produces a file, the pipeline looks successful. Nothing errors out. But the output is broken, and you don't find out until someone downstream notices. Building in the checks that catch that kind of silent failure is not glamorous work, and it's not something you can shortcut by picking a better model. It's ordinary engineering discipline applied to a system that happens to have an AI step in the middle of it.
Agents wired into real tools
Projects that involve an agent calling tools directly, rather than just generating text for a human to act on, add another layer. The agent has to decide which tool to call, with what arguments, and then interpret whatever comes back before deciding what to do next. Most of the setup time here isn't about the agent's reasoning. It's about giving it tools with clear, narrow scopes and results it can actually parse, and then testing what happens when a tool call fails or returns something unexpected.
The instinct is to give an agent broad access and let it figure things out. That almost always costs more time later, because a wide surface area means more ways for something to go sideways, and debugging "why did the agent do that" is slower than debugging a plain script, since you're reasoning about a decision process instead of a fixed set of steps. Narrowing scope up front is one of the few things that reliably shortens a project instead of lengthening it.
Why estimates blow up
If I had to name the single biggest reason my estimates are wrong, it's that I underweight the parts of the project that aren't the AI. When someone asks how long it'll take to automate a task, the mental model is "how hard is the task for the AI," and that's a reasonable question, but it's answering the smallest part of the actual work. The bigger questions are: how often does the input change shape, how bad is it if this fails quietly, and how much do I need to trust the output before it goes somewhere real.
Those three questions predict project length far better than the complexity of the AI task itself. A "simple" AI task with high-stakes output and messy input takes longer than a "complex" AI task with low stakes and clean, predictable input.
How I estimate now
I've stopped trying to size projects around what the model can do and started sizing them around three things instead. First, how variable is the input, because variability is what generates edge cases. Second, what happens if this fails without anyone noticing, because that determines how much monitoring and alerting I need to build in, and monitoring is often as much work as the automation. Third, does anything need a human checkpoint before it goes out, because that changes the shape of the whole system from fire-and-forget to a queue someone reviews.
Once I answer those, I get a rough sense of whether something is a few hours, a few days, or something I'll be tuning for weeks after the first version "works." The AI step itself rarely moves that estimate much either way.
None of this means automation isn't worth doing. It means the value shows up after the unglamorous work is done, not instead of it. If someone tells you an automation project will take an afternoon, ask them what happens when the input looks different than expected, and how they'll know if it silently breaks. Those two questions usually tell you more about the real timeline than anything about the AI itself.
If you want to see how these pipelines actually run day to day, including the parts that don't make it into a demo, you can find more of this on the [home page](/).
Get new guides and videos first — join the Telegram channel.