Habr AI explains why ChatGPT shouldn't write your AI implementation spec for you

The temptation to hand AI not only the implementation itself but also the drafting of the technical specification looks logical: it is fast, cheap and spares you long interviews. But it is exactly at this step that a business often ends up with a polished document that is poorly tied to the real task, the processes and the team's constraints.

Why the template doesn't work

When a manager or client asks ChatGPT to write a spec for an AI implementation, the model usually assembles a plausible, generic template. It is full of the right words: data analysis, model selection, security, integration, quality metrics. The problem is that such text is built on probability, not on knowledge of a specific company. It does not know how approvals work, where the data lives, who is responsible for support, or which solutions have already failed to take root inside the business.

As a result, the document can look mature while remaining empty at the level of execution. It often lacks priorities, project boundaries, acceptance criteria and a description of exceptions. It is even worse when the spec is written by someone who does not fully understand the subject area themselves, and the AI simply packages those gaps in an official style. What comes out is not an engineering document but a convincing imitation. This is dangerous right at the start of a project.

What problems surface

The article argues that AI generation is especially dangerous for AI implementation projects in particular. There are too many dependencies here: the quality of source data, legal restrictions, infrastructure costs, integrations with internal systems, and requirements for explainability of results. A generic text almost inevitably smooths over these sharp edges and creates the illusion that the task has already been formalized. That means the project's real risks surface too late, when part of the money has already been spent.

• Wording stays too general and allows dozens of interpretations
• Requirements for data and its quality are described superficially
• Success metrics are replaced by abstract KPIs with no tie to the business
• Timelines and budget look realistic only on paper
• Comparing contractors against such a spec distorts the picture, because everyone is answering a vague request

This hurts more than the contractor-selection stage. If you send a weak spec to several teams and then also ask AI to evaluate their proposals, the error scales up. The system will match responses against the same superficial template and reward those who hit the formal keywords best, not those who understood the problem more deeply. In the end, you can pick a contractor with a beautiful presentation and weak architecture.

Where AI is useful

This does not mean AI should be removed from the spec-preparation process. It has a useful role, but a supporting one. The model can be used to structure information that has already been gathered: turn a client interview into draft sections, suggest a list of clarifying questions, help check for logical gaps, and bring terminology to a single style. In other words, AI is good where you need an accelerator for editorial and analytical work, not a substitute for investigating the project.

A workable approach looks like this: first, the team manually records the business goal, the current process, constraints, available data, decision owners and the criteria for the result. Then AI helps put this into a clear form, but does not replace the expertise of domain specialists, analysts and the technical lead. The more costly an implementation error is, the more dangerous it is to trust the model with wording the initial requirements without human review. And only after that is the text handed to the model for refinement and editing.

What this means

The main takeaway is simple: AI can speed up spec preparation, but it cannot reliably determine on its own what exactly needs to be implemented and how it will work inside a specific organization. If you use the model as the author of requirements, the business risks buying not a solution but beautifully formatted uncertainty. This is especially true in projects where processes, budget and people's responsibilities will have to change later. That is exactly what makes such documents especially expensive.