"Add a small dashboard for the ops team, shouldn't take you long."
You scope it: one table, two or three charts, a few filters. Half a day. You build it that evening and demo it the next morning.
Your manager looks at it for two minutes: "Filters should switch by week, defaulting to the current one. Move the funnel up top — conversion first, details after. Oh, and regular ops users shouldn't see revenue numbers."
Three changes: one reshuffles the layout, one changes the query logic, one touches field-level permissions. The "small dashboard" turns into three days of rework.
Almost every developer has lived through this loop. The problem was never that the requirement was complex. The problem is that until something visible exists, the conversation has no object to point at.
A one-line requirement is a goal, not a plan
The manager describes outcomes — "let ops see the data." The developer handles paths: where users enter, who sees what, what the default state is, what happens when data is empty.
Those live in different worlds, and the translation material — actual pages, fields, buttons — doesn't exist in a verbal exchange.
Often the requester only has a direction. Requirements aren't fully formed before the meeting; most of them take shape after someone sees a version. That's why the verbal follow-up loop is so inefficient:
"Should the filter have a default?"
"Probably."
"Does the detail view support editing?"
"Just add it, we'll see."
Nobody is being careless. One brain holds business scenarios, the other holds data structures, and there's nothing concrete in between to point at. Discussing requirements by imagination gets vaguer the longer it runs.
Same words, different pictures
Another kind of rework comes from matching words and mismatched pictures:
- They say "add a filter." You picture a dropdown. They picture a combined filter by business stage that remembers the last selection.
- They say "the flow is similar to before." You plan to reuse the old pages. They mean the path is similar — fields, permissions, and states all follow the new business instead.
These mismatches never surface verbally, because both sides feel they were clear and assume the other understood. The reveal only comes when the page exists: "That's not what I meant."
Hidden couplings in the system
Plenty of requirements sound clear until the work starts.
"Add an export button" — then you check: exports need audit logging, the permission group isn't configured, and legacy data has inconsistent field formats.
Business systems have few truly isolated "small features." One button is tied to permissions, one status to a workflow, one field to legacy data. Those risks only surface when a developer goes back to the code and the schema — they stay invisible in a verbal review.
"Done" means different things
The last rework arrives at acceptance: everything is built, and the first reaction is "this status label is wrong" and "this page shouldn't show amounts."
What counts as right, what must never happen, who sees what — acceptance criteria that were never expanded up front, so the two sides never agreed on what "complete" means.
The fix: make version one a commentable demo
All four rework patterns share one property: they only surface after something visible exists. So create that thing early.
AI has pushed the cost of "a viewable version" very low:
- Have a short initial conversation: goal, users, core flow
- Let AI generate an interactive HTML demo — fake data, no backend, complex logic stubbed. This version's job is to say "this is what I understood," not to be production code
- Publish the demo as a link with comments on, and send it: "Here's my understanding of the interaction. Mark anything wrong directly on the page."
For publishing, ShareOne has a skill (search ShareOne on skillhub / clawhub, no signup needed). In your AI assistant:
You: publish the html we just generated to shareone, with comments on
AI: Published. Link: https://shareone.app/s/xxxx (comments enabled)
The web app works too: sign up, upload an HTML / TXT / Markdown file, publish.
Feedback must carry a position
The link opens for anyone — viewing needs no login. To comment, a reviewer selects the exact sentence and writes next to it; commenting requires a login so the system can tell reviewers apart, and every comment is attributable.
Wrong copy gets selected and flagged. Wrong flow gets marked on the step itself. Feedback stops being descriptions scattered across chats and screenshots, and becomes opinions pinned to positions on the page.
The same comment at demo stage is requirement clarification. After real development, it's rework — with APIs, data, and permissions in the blast radius.
Close the loop: let AI read the comments and revise
You: pull the comments from my shareone link
AI: 2 comments:
- On "Filters support a date range":
"Switch by week, default to the current week."
- On "Conversion funnel":
"Move the funnel to the top — conversion first, details after."
Status: open
You: apply both changes and republish
AI: Updated. The link stays the same.
The reviewer refreshes and sees the new version; the next round of comments lands on the same URL. AI now participates in the full loop — generate demo, collect feedback, revise, re-confirm — while you make the calls.
One extra step, days less rework
What slows a project down is never the demo step. It's rework: once pages are wired to APIs, states live in the database, and permissions span systems, "we misunderstood the flow" costs multiples to fix.
AI lowered the cost of building things. It hasn't removed the question of whether the right thing is being built — when the understanding is wrong, AI helps you build the wrong thing faster.
That moves a developer's value one step earlier: translating a fuzzy business idea into an object that can be confirmed, commented on, and revised. From firefighting before release to the first move before coding.
ShareOne — https://shareone.app/en (free; web signup required, skill path needs no signup)
Top comments (0)