This is a story about the waiting disappearing from software projects.
Hi, I’m Shogo Harada, CEO of Linnoedge, writing from Ho Chi Minh City.
If you’ve ever commissioned software, you know the rhythm. You explain what you want in a meeting. The team says “we’ll take this back and design it.” A week passes.
At the next scheduled meeting you see a screen, and it’s… not quite what you meant. So they take it back again. Another week.
Weeks go by before anyone touches working software. It’s draining for the client — and honestly, for us builders too.
I first published this article back when “co-creation” was still half a slogan for me. Our workflow has changed so much since then that I’ve rewritten it from scratch, based on what actually happens in our projects now. (Fully revised, July 2026.)
The day I noticed it was faster to talk to the AI than to open Figma
It started on a parenting-support app we’re building for a client.
After a requirements interview, my usual move was to open Figma and start drawing screens. This time, I talked to the AI first instead. Who is this for? What is it trying to achieve? What does success look like? Not sketches — words.
And here’s the thing I noticed.
A screen is never just a screen — you can’t settle it from the picture alone.
When the background — the user, the goal — is written out in words, the AI doesn’t just produce an interface. It produces a consistent shape for the whole thing, including how the data behaves behind the screen. Start from pictures and you get “looks nice, backend TBD.” Start from words and the front and the back come up together.
To be clear: Figma didn’t become useless. Our designers still use it to polish the final product, and for visual precision it’s often still the better tool.
What changed is the order. Pictures first, or words first.
People call this way of working “vibe coding.” For me, the biggest deal isn’t that the AI writes code fast. It’s this reversal of order.
Requirements: from weeks to about one
Change the order, and the timeline changes shape.
The old rhythm: interview, then a week of design work, then the next scheduled meeting to show it. If the answer is “not quite,” repeat. Weeks pass before the client touches anything that works.
Now: a single screen mock can come out during the meeting itself. A working mock — something you can actually click through — lands within the same week. From interview to working prototype, what used to take weeks now takes about one. And this isn’t a lucky project; it’s what happens when you change the order, so it repeats.
The moment they see it working, clients change
This is the part I most wanted to write about.
For years I believed that when requirements wouldn’t converge, it was an interviewing-skill problem. Ask better questions, and you’d extract everything in the client’s head.
I was wrong. Nobody’s mental image survives being put into words — not the client’s, and not mine either. However long we talk, the picture in your head and the picture in mine are slightly different things.
Put something clickable on the table, though, and the meeting changes.
“What happens if I tap this?”
“This.”
“Huh. …Could we put a button here that does X?”
That “could we…?” is my favorite moment in any project. Ideas show up on the spot, or you get a clear no. Both are progress. The vague “let us take it back and consider” disappears.
What’s actually happening, I think, is that the line between the person commissioning and the people building stops mattering. The moment everyone is standing around a working mock, the client isn’t receiving a status report anymore — they’re making decisions with their hands on the thing. The meeting stops being a report and becomes a workbench. When I used to say “co-creation,” this is the substance I was missing: co-creation is the client stepping inside the build loop.
One thing, though: AI lies
So far this sounds like a free lunch, so let me tell you where it bites.
We’ve lost a full day of work — once closer to three — to an AI that said “done” about something that didn’t work. It says it with a straight face. We call these “AI lies,” and if you don’t catch them, they quietly burn your schedule.
My first instinct was that careful human review would prevent this. But at the volume and speed AI produces, catching every lie with human eyeballs alone stopped being realistic some time ago.
So we flipped the approach. The systems that stop AI’s lies are themselves built with AI. One AI builds; another checks it; a third checks from a different angle. One layer of checking never holds. Two or three layers, and it starts to work.
It’s unglamorous work, and it takes effort. But the speed I described above is only safe to use once this braking system exists. Whenever I talk about the speed, I talk about this in the same breath.
“What did we even do before?”
Lately I catch myself wondering: before AI, what were we doing with all that time?
That’s how much our workflow has changed. Designers and engineers do different work than they did a year ago — but the biggest change is the client’s seat at the table. From waiting for reports, to deciding around a working mock.
Some things haven’t changed. Deciding what’s worth building, and calling the shot to go — that’s still humans. AI doesn’t take that over. Which is why I don’t see AI as something to fear; it’s closer to a partner that sharpens your thinking. If you’re curious how we run AI inside our own studio, it’s on our AI consulting page.
If the waiting in your current development project is wearing you down, here’s the one thing I’d want you to take away.
Software is shifting from “commission it and wait” to “watch it together and decide.”
You don’t need to describe your idea perfectly in words. Turning it into something that runs — that’s our job.
Key takeaways
- Words before pictures — write out the user and the goal, and the AI shapes the front and the back of the product together.
- Weeks become about one — a clickable mock lands the same week as the interview, so reactions come on the spot: ideas, or a clear no.
- Catch AI’s lies with AI — one layer of checking never holds; two or three layers make the speed safe to use.
FAQ
What is vibe coding?
Vibe coding means describing what you want in plain language and letting AI generate the code or prototype, instead of writing full specifications first. In my experience the real value isn’t faster code — it’s that putting the background and goals into words is itself an act of design. How we use it in client work is on our AI consulting page.
Does the AI-built prototype become the production system?
No — and I’d rather be direct about that. The prototype is a working mock for aligning expectations. Production needs separate work on performance, security, and maintainability, and as I wrote above, AI lies — so everything passes through layered checks before it ships. How we run production builds is on our system development page.
What do I need to prepare before talking to you?
Nothing. Bring the idea as it exists in your head — “I wish we could do X” is enough. Putting it into words is the part we do together, and documents are optional either way. Book a slot below and just talk.
If you’d like to see your idea as something that runs, start here.
Talk it through with me first
I’m happy to be your sounding board — starting from the idea in your head, down to how fast a working mock could exist for your case.
Book 30 minutes → See our AI consulting
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.