More of the project requests I get now arrive pre-built. Not the software. The spec.
A client sends me page after page describing how to build the thing, generated by an AI, and somewhere in the middle is a sentence or two about what they actually need. The proportions are backwards. The business challenge is a footnote. The technical scope, written by a chatbot that’s never seen their systems, is the main event.
What these look like
The structure is always similar. A list of technologies. A proposed architecture. A database design. A plugin stack to “scope around.” It reads like a scope of work because it’s doing an impression of one.
Here’s an invented but representative version. A startup wants to sell access to a content library to corporate customers, with per-seat limits. Reasonable goal. The request that lands in my inbox says: use this billing provider as the source of truth, build custom database tables for entitlements, run provisioning through this specific job-queue library, maximize plugin use, but also build a custom licensing engine, but don’t treat the e-commerce plugin as authoritative, but do scope around that same e-commerce plugin plus four add-ons.
Read that again. It contradicts itself three times. That’s the tell.
Why it contradicts itself
A language model hedges across every option at once because it has no constraints to narrow the field. It doesn’t know the budget. It doesn’t know the team. It doesn’t know which part of this is actually hard, or which part actually matters to the business.
So it lists everything, recommends everything, and hedges everything. Then it formats the result to look decisive.
The confidence is real. The basis for it isn’t.
Writing the scope is the job
This is the reverse of how the work actually goes.
A client comes to me with a business challenge. I ask questions, figure out what’s really going on, and write the scope. That’s not a warm-up before the real work. For a lot of projects, it is the real work.
When the scope shows up pre-written by an AI, it skips all of that. And it skips it badly. The AI never had the information that makes a scope worth anything.
The result isn’t a head start. It’s something I have to walk back before I can begin.
Ideas are fine. A spec is not.
There’s a difference between sharing an idea and handing over a technical scope.
If you tell me you were picturing a customer dashboard, or you think an integration with your existing CRM might be the answer, that’s useful. That’s you telling me how you imagine it working, which helps me understand what you want.
A 2,000-word technical specification generated by a model that’s never touched your systems is a different thing. One tells me what you’re after. The other tells me what a chatbot predicted an RFP should sound like.
What to send instead
If you’re putting a request together, here’s what’s worth your time:
- The challenge. What’s broken, slow, manual, or costing you money. Be specific.
- What success looks like. How you’ll know it worked.
- The constraints. Budget range, deadline, the systems you already run, who’s on your team.
- Your ideas, clearly labeled as ideas. “We were thinking maybe X” is welcome.
That’s it. Skip the generated technical scope.
And if you want to point an AI at the request, point it at the first item, not the last one. It’s much better at helping you describe a challenge clearly than at deciding how to solve it.
The part the model can’t do
I use AI tools every day. They’re good at a lot of things, and I’m not nostalgic for doing everything by hand.
Writing your scope for you isn’t one of those things, because the scope depends on everything the model doesn’t know. The budget, the constraints, the real reason you’re calling. Bring me that part. Writing the rest is my job.
