Vibe Coding Makes Understanding the User More Important

By Matthew Andrews · October 4, 2026

As AI takes on more of the work of writing code, I keep returning to a management question: how do developers and leaders track requirements across a large system when implementation can move faster than their understanding of what needs to be built?

My answer increasingly comes back to decomposition: breaking work into smaller pieces.

But the kind of decomposition matters. We need to become much more precise about breaking down the user’s experience, and preserve that perspective all the way into the smallest units of work.

A User Story Can Describe Almost Anything

For years, user stories have given teams a familiar structure:

“As a user, I need to do something, so that I can achieve an outcome.”

That structure is useful. It encourages us to identify a person, a need, and a reason. But it does not tell us whether the work is appropriately sized.

“As an advisor, I need to manage my clients’ investments” could describe an entire product.

“As an advisor, I need to see when a client’s account information was last updated” describes a much smaller capability.

Both fit the same template.

The sentence structure alone does not tell a team whether it understands the requirement well enough to build it, verify it, or report meaningful progress.

Where the User Gets Lost

As work moves from epics to stories to tasks, the breakdown often shifts toward implementation.

Build the database table. Create the endpoint. Add the component. Connect the service.

Those tasks can be necessary. They help developers organize their work. But they also make it possible for a team to complete a long list of technical activities without delivering a complete user experience.

A dashboard can exist while leaving the user unable to tell whether its information is current. An approval button can work while failing to explain what the user is approving. A workflow can succeed under ideal conditions and leave someone stranded when information is missing.

The technical pieces may be finished. The user’s need is still only partly met.

With AI-assisted development, I expect that gap to become easier to create. Generating more implementation does not automatically resolve ambiguity in the requirement.

Decompose the Experience Further

Consider a requirement like:

“As an advisor, I need to review a recommendation before approving it.”

Before implementation begins, I want the team to break that experience down further:

• I can tell which client and account the recommendation belongs to.
• I can understand what change is being recommended and why.
• I can see the information used to produce it and when that information was updated.
• I can recognize when missing or outdated information makes the recommendation unsuitable for review.
• I can understand what approving it will authorize.
• I can decline it or postpone my decision.
• I can tell whether my decision was recorded.
• I can return later and understand what happened.

Each statement remains grounded in something a person needs to understand or accomplish.

Some of these statements may belong in one delivery slice. Others may need further breakdown. The point is to make the experience specific enough that the team can identify what is missing and demonstrate what works.

The stopping point should be a meaningful, observable user outcome. Breaking work into smaller tickets is only useful if those tickets make the requirement clearer.

Technical Implementation Should Provide Safeguards

I believe technical implementation should provide safeguards rather than become doctrine.

Security boundaries, privacy, accessibility, data integrity, and reliability still matter. So do architectural constraints that protect the wider system. Faster code generation makes those safeguards more valuable.

But within those boundaries, teams should have room to discover a better implementation.

A requirement that says, “The user can tell that their information is outdated before making a decision,” preserves the purpose of the work. The implementation may change as the team learns more.

A requirement that prescribes a particular component or sequence of service calls can become detached from that purpose. The team may faithfully implement the prescription while missing the experience it was meant to create.

We need enough technical direction to protect the system and enough flexibility to improve it.

Emotional Intelligence Becomes an Engineering Skill

This is where I think emotional intelligence becomes one of the most important capabilities on a development team.

Breaking down a user’s needs requires more than asking what feature they want. It requires listening for uncertainty, recognizing assumptions, understanding frustration, and noticing when the team’s language no longer matches the user’s experience.

When someone says, “I need a dashboard,” what are they struggling with?

They may need to recognize a problem sooner. They may need confidence that nothing has been missed. They may need to explain a decision to someone else.

Those needs can lead to very different products.

A team that can understand the person behind the request has a better chance of decomposing it into useful, testable outcomes. That takes curiosity, empathy, and the willingness to ask questions that initially seem obvious.

It also takes humility. A detailed requirement can still be wrong. Teams need to put their interpretation in front of users and be willing to change it.

AI can help us implement an interpretation quickly. We still have to establish whether that interpretation is right.

Track Progress Through Demonstrated Outcomes

For management, this changes what useful progress reporting looks like.

Completed tasks and generated code tell us that activity has occurred. To understand whether a large system is becoming more complete, we need to connect that activity to observable user outcomes.

For each small capability, I want to know:

• Is the intended user outcome clear?
• Has it been implemented?
• Has someone demonstrated that it works in the actual workflow?
• Does it behave appropriately when information is missing, a dependency fails, or the user returns later?

That gives leadership a more meaningful picture than a percentage derived only from completed implementation tasks.

It also preserves the connection between the larger objective and the smallest pieces of work. A team should be able to explain how each piece helps a person, and show the evidence that it does.

The Work Moves Toward Understanding

I see vibe coding as part of a broader shift in how software gets built. As implementation becomes faster, unresolved questions about users, requirements, and acceptance become harder to ignore.

My view is that the teams best positioned to benefit will be exceptionally good at understanding people and translating that understanding into small, demonstrable capabilities.

The user story still has a place. We need to carry its focus on the person much further down into the work.

When a team can explain even its smallest delivery increments in language the user would recognize, it becomes easier to build the right thing, verify it, and understand how much of the system is truly complete.

Back to Blog