# IA & Client: "Prototypers" > Why a client's Slack message about prototyping a feature in 2 hours with AI no longer scares us, and how it's reshaping our business as developers. Date: 2026-04-29 Authors: Héloïse Guillaume Tags: ia, temoignage, web, developpement --- It wasn't a tense boardroom showdown. It was just a Slack notification on a random Tuesday. We were in the middle of estimating tickets for a client (let's call him "Client A"). Some of them, like building a chat directly integrated into the app, had been flagged as "substantial work." In other words, these features required time, testing, and a sizable budget. Then, the notification popped up in the channel. Client A had been tinkering on his own version of the app as a side project. He posted an image of a fully functional chat with a typing indicator and wrote: > Out of curiosity, I tested creating a chat yesterday. Here is the result in < 2 hours. For a development team, seeing a feature estimated at several days of work appear in "less than 2 hours" can trigger a moment of panic. Are we too slow? Is our expertise becoming obsolete? Even our internal chat lit up with questions: "Wait, do we use these tools enough? Are we behind?" ![This is fine](./images/this-is-fine-meme.jpg) But Client A wasn't trying to trap us. He wasn't asking us to blindly copy-paste his AI generation. In fact, we never even saw his code, only the interface. His message was actually an invitation: he trusted our ability to build a robust, maintainable application, but he was challenging us to harness that same raw speed to accelerate the process. ## Client A isn't an anomaly. He is the new standard. Since the arrival of generative AI, we are seeing a shift in how clients interact with us. They are no longer just "specifiers"; they are "makers." 1. Some, like Client A, use AI to prototype visions they want us to industrialize. 2. Others go further, wanting to "vibe code" alongside us, producing features in real-time while expecting us to guarantee the stability of the whole. At BearStudio, we realized we couldn't just ignore this. We had to move from being "The Builders" to becoming "The Warrantors." **In this first article, I want to show how we are adapting our service model to clients who sometimes code faster than we do, and why they still need us more than ever. A second article will follow soon to explore a scenario that goes even further.** ## The "shadow" prototype: from gatekeepers to warrantors To understand why this interaction with Client A was a turning point, we have to look at how we, and the entire tech industry, operated just two years ago. ### The old way: the "discovery" game In the pre-AI era, when a client wanted a complex feature like a chat system, we played a telephone game. Like the children's game in which a message is whispered from one person to another and becomes distorted as it passes along, a client's original idea often changed or lost clarity as it moved through multiple intermediaries (Product Owner, Designer, Developer). Each step involved interpretation, which could lead to misunderstandings or deviations from the client's initial vision. It was a process designed to minimize risk, but it was slow. If a client arrived with their own code, we were the "Gatekeepers." We would usually look at their amateur attempts, politely smile, throw it in the trash, and rewrite everything from scratch. We charged for the "what" (the feature) and the "how" (the code). ### The shift: the Client A incident Then came Client A's Slack message. He hadn't just described the chat; he had built it. When he offered to show us his "admin platform" and the chat he built in under 2 hours, he was actually nervous. He jokingly said he felt a "big pressure" because he knew his code wasn't professional grade. This was the moment that changed our perspective. Internally, the reaction was raw: > If a client can generate the interface in a lunch break, what are we billing for? But during the meeting, the dynamic flipped. Client A didn't say, "I did your job." He said, "I can show you the rest, and you can tell me how badly the AI probably did it." He didn't want us to build the chat anymore. He had already "built" the vision. **He wanted us to professionalize it.** ### The future: the prototype IS the specification This experience forced us to accept a new reality: The "Shadow Prototype" is not a competitor; it is the ultimate specification. Instead of spending days on abstract user stories ("As a user, I want to see a typing indicator"), we simply looked at his screen. The ambiguity was gone. - **Before**: We estimated 10 days to figure out what he wanted and build it. - **Now**: We estimate 5 days, but 0% of that time is spent guessing, and 100% is spent on architecture, security, and integration, the whole propulsed by the use of AI in the codebase. The code generated by AI worked for a prototype, but did not always cover the requirements of a production environment (robustness, security, scalability) nor all of our best practices. And that’s expected: it wasn’t its role. Its real value was elsewhere: enabling us to skip the “discovery” phase and move straight to “engineering.” ![Galaxy brain](./images/galaxy-brain.jpeg) ## How this prepares us This is the future of our service. Clients will come to us with more than just ideas; they will come with working (but broken) prototypes. Our value proposition is shifting. We are no longer the ones who reveal the magic of code (AI does that now). We are the ones who provide the certainty of engineering. **We are moving from being "The Builders" to being "The Warrantors": the experts who take a client's dangerous, exciting 2-hour experiment and turn it into a boring, stable, money-making product.** But Client A's case was relatively safe. He built in his sandbox, and we built in ours. The two codebases never touched. What happens when the client doesn't just want to show you the path, but wants to drive the car with you? This brings us to a second, more disruptive scenario. We are seeing the rise of tech-savvy teams who aren't just using AI to prototype ideas; they are using it to ship features. They have tight budgets, aggressive deadlines, and a philosophy that terrifies traditional CTOs: "vibe coding." They don't want us to rebuild everything. They want to code alongside us. **In the next article, we dive into this new co-construction model, its risks, and the guardrails we put in place to prevent speed from turning into chaos.** ## Keep reading Curious about how we use AI on the technical side? Check out our dedicated article: - [Discovering MCP: a new approach for your AI agents](/fr/blog/articles/decouvrir-le-mcp-une-nouvelle-approche-pour-vos-agents-ia) (French only) More interested in how we collaborate with our clients? Take a look at these case studies: - [UX Case Study: Cuisinez pour bébé](/en/blog/posts/ux-case-study-cuisinez-pour-bebe) - [Lea English Case Study](/en/blog/posts/lea-english-case-study)