Powerful AI can't fix vague requirements

AI can write code fast. It still cannot fix vague software requirements for us.

Software development has never been just about writing code. Code is the visible result at the end of a more important process: understanding the problem, the people using the product, the business rules, the limits of the system, and the effect each change can have on everything around it.

AI tools and large language models have not changed that. They have made it harder to ignore.

Today's AI can quickly generate classes, API endpoints, database migrations, tests, user interface components, and even whole modules. But the quality of that code depends on the context we give the model. AI can speed up implementation. It cannot reliably make up for a weak understanding of the product.

AI can build the wrong thing very quickly.

That is not productivity. It is technical debt arriving sooner.

A ticket sentence is not a software requirement

Take a request like this:

"A user should be able to cancel an order."

It sounds simple at first. Add a few checks, call an API, change a status, and show a button in the user interface.

The real requirement starts when we ask what "cancel" means:

• How long can the user cancel the order?
• What happens if the payment has already gone through?
• Should the system start a refund automatically?
• What if part of the order has already shipped?
• Does reserved stock return to inventory?
• Who tells the warehouse?
• Can the seller reject the cancellation?
• How do we record the change in the audit log?
• Does a used coupon become available again?
• Which statuses do other systems expect?

One short user need quickly turns into a set of business rules, states, integrations, and agreements between different parts of the system.

Without those answers, AI will probably generate code that looks correct. The structure may be clean. Method names may be good. It may even include a few tests. But it can still ignore payments, stock levels, existing integrations, or behavior that other parts of the product depend on.

Correct syntax does not mean we built the right product.

Documentation gives AI the context it needs

Teams often treat documentation as something to write after the implementation. In practice, the most useful documentation starts before the code because writing it forces us to think through the change.

It does not need to be long or formal. Its job is to reduce the number of ways people can read the same requirement. A useful document should answer questions such as:

• What problem are we solving?
• Who has this problem?
• Which business rules apply?
• What can the system do, and what must it reject?
• Which existing processes will change?
• Which systems, modules, and teams will feel the change?
• Which decisions did we make, and why?
• Which edge cases and errors do we expect?

Once that context exists, it also becomes good input for an AI model.

An LLM does not understand our product just because we gave it part of the repository. It does not know why someone added a status two years ago. It cannot see which external system depends on one field or why a temporary workaround now supports a critical business process.

The model only knows what we put in its context. If that context is incomplete, old, or contradictory, the result will have the same problems. AI does not remove the confusion. It turns the confusion into code.

UML diagrams should explain the risky parts

UML and other visual models have a bad reputation in some teams because people once used them for too much formal documentation. The problem was not the diagram. The problem was drawing one that nobody needed.

A useful diagram is a compact explanation of how a system works:

• A sequence diagram shows who starts an operation, the order in which services talk, where errors can happen, and who handles recovery.
• A state diagram shows the allowed changes between states. For example, can an order move from SHIPPED to CANCELLED, or does it need a separate return process?
• A component diagram shows system boundaries and dependencies between modules.
• An activity diagram explains a business process that is hard to follow across several tickets.
• A domain model gives the team a shared meaning for important terms. "User," "customer," "account owner," "subscriber," and "payer" may sound similar, but they can be very different roles in a real product.

These models help AI because plain text often leaves room for guessing. A diagram can make interactions, ownership, and allowed flows explicit.

We do not need a diagram for every class. We need diagrams where a wrong assumption could cause an expensive mistake.

Ask what else will change

Before choosing an implementation, ask a wider question:

What else will change if we build this?

A real product is a network of connected behavior. A new feature rarely stays inside one screen or one service. It may affect existing user flows, authorization, billing, reporting, analytics, notifications, audit records, performance, security, and integrations.

That is why impact analysis matters. A new requirement has to work with old rules and existing features, including combinations that are easy to miss when we only test the ideal path.

For example, adding a family subscription is not just a new plan type. The team also needs to think about:

• the relationship between the subscription owner and other members
• access rights and role management
• plan changes and cancellation
• removing a member who still owns data or content
• billing rules
• member limits
• privacy between members
• migration of existing individual accounts
• promotional codes
• analytics and financial reporting

AI can suggest scenarios, create a test matrix, and implement rules once they are clear. Someone still has to understand the product well enough to notice which questions are missing.

That responsibility still belongs to the engineer.

Communication contracts carry business meaning

Modules and services in a distributed system share more than data. They share expectations.

An API specification, event schema, message format, versioning rules, idempotency, timeouts, retry behavior, and error responses form a contract between components.

A service can change the meaning of a field without changing its name. The technical shape still matches, but the business contract is already broken.

Imagine that an OrderCancelled event originally means the whole order was cancelled. Later, one service starts sending it for partial cancellations too. Every existing consumer can now make the wrong decision even though the event still passes schema validation.

Documenting the shape of a message is not enough. A good contract should explain:

• when communication starts
• who owns the data
• what each field means
• which delivery guarantees apply
• whether the operation is idempotent
• which errors the receiver should expect
• how the contract can change without breaking current consumers
• what happens when one side is unavailable

Clear contracts let AI generate more reliable clients, validation, adapters, compatibility tests, and service code. When the contract is vague, the model fills the gaps with assumptions. Those assumptions can look perfectly reasonable until they reach production.

AI speeds up the process you already have

If a team understands its domain, writes clear requirements, keeps documentation current, and knows its system boundaries, AI can save a lot of time. It can handle repetitive work and leave engineers with more time for decisions that need judgment.

If the same team has vague requirements, conflicting rules, and a weak picture of the current system, AI will produce the wrong code faster and make those problems harder to remove later.

A more powerful model does not fix poor context by itself. It may write more convincing code, suggest a cleaner architecture, and explain its answer with more confidence. The answer can still rest on a bad assumption.

Good prompting for software work depends on the work that happens before the prompt:

• understanding the user and the business problem
• writing precise requirements
• modeling the domain
• recording rules and decisions
• checking the effect of a change across the system
• defining ownership boundaries
• writing explicit communication contracts
• giving examples of expected and rejected behavior

A prompt cannot replace software design. If the prompt is good, that is usually because the design work happened first.

Engineers are moving closer to product decisions

As AI handles more implementation work, an engineer's value will depend less on the amount of code written by hand. The harder and more useful skills will be:

• understanding the user's real problem
• finding hidden assumptions
• connecting business needs with technical limits
• predicting the side effects of a change
• defining clear system boundaries
• designing stable contracts
• checking whether the implementation fits the product
• thinking a few steps ahead

Technical knowledge becomes more important here, not less. We need enough depth to review generated code, spot weak abstractions, find security and performance problems, and understand side effects before users find them for us.

We may spend less time translating a finished decision into code. We will spend more time making sure it is a good decision.

Clear thinking still comes first

The power of the AI model matters less than how well we understand what we are building.

We need to understand the request and the reason behind it. We need to know how a feature affects the rest of the product, how it works with old rules, which interactions it adds, and which contracts it must respect.

This was the work of good software engineering before LLMs, and it will remain the work after they become normal tools. AI can reduce the time we spend on repetitive implementation. That gives us more time to understand the problem, shape the product, make architecture choices, and think about the long-term effects of our decisions.

AI will not remove the need to think. It may finally give us enough time to do more of it.

Maybe "Software Product Engineer" is a better name for the job after all.