More of the project requests I get now arrive pre-built, not as software but as a 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, a 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, the team, or which part of this actually matters to the business.
So it recommends everything and hedges the rest. Then it formats the result to look decisive.
The confidence sounds solid, but nothing behind it is.
Writing the scope is the job
This is the reverse of how the work goes.
A client comes to me with a business challenge. I ask questions, figure out what’s really going on, and write the scope. For a lot of projects, that scoping work is the job, not a warm-up before it.
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 is something I have to walk back before I can begin.
The Difference Between an Idea and a Spec
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. A sketch tells me what you’re after; a generated spec 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:
- Describe 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.
- Share 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 on that list instead of the last. 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 the budget, the constraints, and the real reason you’re calling. Bring me that part, and writing the rest is my job.
