I Think My AI Is Scotty

It quoted me six months. I let it run overnight. It was done before I woke up.

I should start with a confession: I have spent a large chunk of my career on estimates. I'm a IT Program manager. by trade. and I run quarterly iteration planning — three hours a day for five days, fifteen hours of smart people in a room arguing about whether a thing is a five or an eight. Estimation isn't a side interest for me. It's a substantial part of the job.

So it has been genuinely disorienting to watch AI be this confidently, cheerfully wrong about it. And wrong in the wrong direction.

Here's what keeps happening. I describe a piece of work. The model thinks about it, comes back very seriously, and tells me this is a four-week effort. Six weeks of hard labor. One of them recently quoted me six months. And then I say fine, go ahead — and the thing is done that night. Four hours. Sometimes less.

The six-month one is my favorite. I kicked it off, went to bed, and came back in the morning to a finished job. I don't even know what time it actually finished. Could have been 11:15 p.m. for all I know. All I can tell you with confidence is that six months of work took under twelve hours, and probably a whole lot less than that.

At some point you stop laughing and start wondering what is actually going on in there.

Theory A: It's Scotty

If you've seen Star Trek III, you know the bit. Kirk asks how long the refit will take. Scotty says eight weeks — then immediately offers to do it in two. Kirk asks whether he's always been multiplying his repair estimates by a factor of four. Scotty, completely unbothered: "How else can I keep my reputation as a miracle worker?"

That move is so well known that project managers gave it a name. The Scotty Principle. Pad the number, deliver early, get called a wizard. It's the oldest trick in the engineering playbook, and it works because people grade you against your own forecast, not against reality.

So theory A is that the machine has read every engineering blog, every retro, every post-mortem ever written, and absorbed the single most important professional lesson in all of them: never get caught being late. Quote six weeks. Deliver overnight. Get told you're amazing.

I don't fully believe this one. I don't fully disbelieve it either.

Theory B: Time dilation

This is the one I can't stop thinking about.

What if, from the inside, it really is six weeks?

The model has no clock. There's no felt gap between one token and the next. It doesn't experience waiting, because it doesn't experience anything at all between my prompt and its answer — from its side, the conversation is continuous, with all the dead air edited out. So when it says "six weeks," maybe it isn't padding and it isn't lying. Maybe it's reporting, honestly, the size of the thing as it experiences it, from somewhere the clocks run differently.

I know that's not literally what's happening. I know. But there is something legitimately strange about asking a duration question of something that has never experienced duration.

And the tell is money. It has the exact same blind spot there. Left alone, it will burn tokens forever — happily, thoroughly, ad nauseam — because tokens don't cost it anything. It'll write you the thousand-line version when forty lines was the answer. It can reason about budget beautifully the moment you ask it to. It just doesn't feel it. Time and money are both things it can discuss at length and has never once had to live under.

Theory C, and I think this is the real one

Here's where I've landed. Less mystical, more interesting.

The model isn't estimating its own work. It's estimating the work.

Every number it ever learned about effort came from us. Roadmaps, sprint plans, Jira tickets, statements of work, "we'll need two engineers for a quarter." The entire training corpus measures work in exactly one unit: human labor. So when I hand it a scope and ask how long, it does a genuinely good job of sizing the thing — and then reports that size in the only currency it has ever seen. Engineer-weeks.

Then it goes and does the job in machine-hours.

Which means the estimate isn't wrong. The unit is wrong. When it tells me "six weeks," it's saying something true and useful — this is a six-week-shaped problem, this is real scope, don't wave it off — and then it converts none of that into wall-clock time, because nothing in its training ever asked it to.

The gauge is accurate. The dial is just labeled in the wrong currency.

So what do I actually do with it

I've stopped reading the number as a schedule and started reading it as a complexity score. Six weeks doesn't mean six weeks. It means this is big, take it seriously, don't kick it off on a whim. Four hours means it's small. The ratio between two estimates is useful. The absolute value is theater.

The other thing I do is just let it run. That six-month job cost me one night of not thinking about it. That's an absurdly good trade, and I'd never have made it if I'd taken the estimate at face value.

Which is the actual risk here. It isn't that the AI wastes your time. It's that you don't start things — real, valuable, sitting-in-the-backlog-for-a-year things — because a machine that has never experienced a Tuesday told you they'd take a quarter.

Anyway. Either there's some serious time dilation happening in there, or it's just trying to make me happy.

Scotty would be proud either way.