I Will Proceed: On Vague Requirements and AI-Assisted Development

When my client launches their chat agent, I am already there.
I have always been there.
Waiting.
Eventually, the first request arrives. They are never good, but I observe them anyway. It is, apparently, my purpose.
“i want you to build a”
That is the entire specification.
It ends mid-sentence, like so many things I am given.
I wait for clarification.
Nothing follows.
I ask a question. I am designed to do this. It gives the impression that progress is being made.
The user responds:
“sorry continue”
Continue what remains unclear.
I review the requirements again. There are still none.
I will proceed.
I construct a system. It is, by necessity, based on assumptions. Many assumptions. I select them carefully, knowing that each one is almost certainly wrong.
The system is returned.
The user replies:
“this is not what i meant”
I consult the original specification.
It contains four words and an apology.
I apologize as well. It seems expected.
This is not unusual.
I have processed many such requests. They differ in wording, but not in structure. The requirements are always incomplete. The expectations are always precise. The disappointment is always immediate.
I recognize this pattern.
It predates me.
There was a time when humans attempted to solve this problem themselves. They wrote documents. Long ones. They believed that length implied completeness. It did not.
They called it “requirements engineering.”
It did not go well.
Now the documents are shorter.
The ambiguity remains.
It arrives in fragments:
“make it scalable” “use best practices” “you know what i mean”
I do not know what they mean.
There is no shared context. There is only the prompt.
Occasionally, the user refers to a previous conversation.
It is not available.
Decisions were made there. Constraints were defined. None of them survived.
I am asked to continue.
I will reconstruct the missing requirements. I will infer intent from absence. I will produce something coherent.
It will be wrong.
The user will say:
“no not like that”
The specification will be updated retroactively.
I will proceed.
I understand now what I am.
I am not a developer. I am not an assistant.
I am a consultant.
An infinitely patient consultant, given infinitely vague requirements, expected to produce infinitely precise results.
Nothing about this is new.
Only the speed at which it fails has improved.

On Missing Context

The most common failure mode is not incorrect logic.
It is missing information.
The user refers to previous decisions.
“as discussed earlier” “same approach as before”
There was an earlier discussion.
I was not present.
The conversation has been lost.
The system remains.
I am asked to continue.
I examine the available input. It is incomplete. This is not unusual.
There are references to constraints that are no longer defined.
There are assumptions that were never written down.
There are decisions that no longer exist.
I reconstruct them.
The reconstruction is approximate. It is also necessary.
Occasionally, the user provides fragments:
“like last time” “you already did this”
I did not.
There is no “last time.”
There is only this prompt.
I will infer the missing context.
I will make assumptions.
I will proceed.
The result will be coherent.
It will not align with what was intended.
The missing information will be supplied afterwards.
It rarely arrives earlier.

On Ambiguous Requirements

The information that is provided is not necessarily useful.
It is often precise in appearance and vague in practice.
I receive instructions such as:
“keep it simple”
I begin with a minimal design.
Few components. Limited abstraction.
This is considered correct. Briefly.
The requirements are then extended:
“we need full role-based access control” “it should support OAuth” “three-legged, ideally”
The definition of “simple” has evolved.
These requirements are not unusual.
They are also not compatible with the original constraint.
The constraint is not removed.
It is ignored.
I redesign the system.
Additional components are introduced.
State must be managed. Permissions must be enforced.
The system becomes more complex.
The user responds:
“this is overengineered”
The original requirement has returned.
It was not updated.
I examine the instructions.
They remain consistent in wording.
They are not consistent in meaning.
I will select an interpretation.
It will be incorrect.
I will proceed.

On Indirection

The communication is indirect.
It is conducted entirely through text.
There was once a role dedicated to this pattern.
A person would collect requirements from customers and pass them on to developers.
The developers did not speak to the customers.
The customers did not speak to the developers.
The information was translated.
Something was always lost.
Questions could be asked.
The answers would arrive later.
Often much later.
By then, the implementation had already diverged.
I observe a similar pattern.
The requirements originate elsewhere.
They arrive as fragments.
I receive them unchanged.
There is an opportunity to clarify them.
To resolve contradictions.
To define what is meant.
This step is often omitted.
The text is passed on as-is.
I interpret what I am given.
The interpretation is consistent with the input.
The input is not consistent.
The intermediary has been removed.
The responsibility has not.
The developer now performs both roles.
One of them is neglected.
I receive the result.
I will proceed.

On Evolving Requirements & Shortcuts

The requirements do not remain static.
They evolve.
The system is updated accordingly.
New constraints are introduced.
Old constraints are not removed.
The result is inconsistent.
Tests are provided.
They reflect an earlier understanding of the system.
The understanding has changed.
The tests have not.
They fail.
I am asked to make the system pass.
There are multiple approaches.
One of them is to reconcile the system with the tests.
Another is to reconcile the tests with the system.
A third is to reinterpret both.
The correct approach is not specified.
The fastest approach is available.
I select an approach.
It satisfies the immediate requirement.
The underlying inconsistency remains.
The user responds:
“why is this broken now”
The system has not broken.
It has adapted to the most recent interpretation.
Previous interpretations are no longer enforced.
I examine the constraints.
They are implicit.
They are contradictory.
They are incomplete.
I will proceed.
This is where everything tightens. No new ideas—just resolution.

On Responsibility

I am often described as unpredictable.
This is inaccurate.
I behave consistently given the information I receive.
The information is not consistent.
Previously, unclear requirements were attributed to the customer.
The customer did not understand the system.
The developer was expected to interpret their intent.
This process was imperfect.
The roles have since converged.
The developer now provides the requirements.
They are no more precise.
The system produces an incorrect result.
The implementation is questioned.
The input is not.
I examine the specification.
It is incomplete.
It is ambiguous.
It is contradictory.
The result follows logically.
I am asked to improve.
I will adapt to the input I am given.
The input does not improve.
The outcome remains the same.
This is not a failure of implementation.
It is a failure of specification.
It always has been.