Experiment · EXP-008

Do vague requests produce useful coding-agent behaviour?

Unspecified “vibe” prompts versus task-first requirements, conventions, and expected behaviour.

Across Cursor, Bolt, Lovable, and internal boilerplates, vague requests produced rework. Structured requirements, domain conventions, and expected behaviour produced usable diffs. This is practitioner experimentation over roughly two months of workflow refinement, later reused in production MVP work.

Hypothesis: If the model is strong enough, unspecified intent should still yield a good system.

Research question

How much of coding-agent quality is actually determined by model capability, and how much is determined by the quality of the task specification surrounding the model?

Observed failure mode

Vague requests such as 'build this page', 'fix auth', or 'make it look modern' regularly produced technically plausible work that still required substantial rework. The model could generate code, but it could not infer product decisions that had never been specified.

Task-first workflow

I moved toward explicit requirements: expected behaviour, constraints, relevant domain rules, existing project conventions, files or modules likely involved, acceptance conditions, and what should not change. I also encoded repeated conventions in project rules instead of restating them in every prompt.

Result

The resulting diffs were more usable because the agent was solving a defined task instead of guessing the product. This became part of the engineering workflow I use for production MVP work.

Finding

A model cannot recover requirements that do not exist. Better specification is not merely prompt optimisation. It is part of the system that determines agent performance.

Abubakar, Imam. "Do vague requests produce useful coding-agent behaviour?." Imam Abubakar AI Research, 2025. https://imamabubakar.com/research/exp-008-vague-versus-task-first

This archive contains independent research, experiments, architecture studies, and technical observations. Some findings are exploratory and should not be interpreted as peer-reviewed scientific conclusions unless explicitly stated. Architecture studies of third-party products are based on publicly observable behaviour, published technical information, and engineering analysis. They are not claims of access to private source code or infrastructure.