AI Makes Building Easier — Deciding What to Build Is the Hard Part

Artificial intelligence tools have grown so powerful that the 'solo founder' strategy is becoming increasingly feasible, letting even innovators with no technical background build fully functional products. The trend isn't confined to startups — it's also taking hold at large organizations where AI adoption is on the rise. AI has democratized the entire execution stage of the innovation cycle: product managers are building working prototypes without writing a single line of code, while developers are using it to speed up software development, testing, documentation, and data processing.

This raises an important question: does collaboration still retain its role and value? If the basic unit of work is shifting from the 'team' to the 'individual armed with AI,' that implies a major shift in how we think about organizing, hiring, and what makes an employee valuable. The question extends well beyond conversations about productivity.

We explored this question recently during a buildathon — a one-day hands-on design competition — with NYU Stern students. Mixed teams with a range of skill sets were given access to common AI tools and asked to solve complex, real-world problems within a single day. Our goal was to observe how teams diverge when generating ideas and then converge when making decisions, and to see at which stages of the innovation cycle collaboration still pays off.

Eight Teams, Real Problems, One Day

We gave 33 students six hours to design solutions to some of New York City's toughest challenges — food affordability, transportation equity, bike lane safety, and access to childcare. These were complex, multifaceted issues where even defining success was difficult. Participants were randomly assigned to teams of four or five, and everyone had access to the same set of tools. They began with AI-powered research and ideation tools to understand the problem and identify the user, then moved on to prototyping tools to design actual solutions. Finally, they turned to agentic coding platforms like Lovable and Vercel to build working demos. All of this took place on a shared digital whiteboard called Miro, where everyone could see in real time what everyone else was doing.

Importantly, most students had little to no engineering background (and the teams weren't deliberately structured to balance skill sets), didn't know each other well beforehand, and had never used these tools. There was also a competitive element: prizes that could boost the winners' careers were on the line, and the judging criteria prioritized problem framing and solution design over technical execution. This wasn't about who could deliver fastest — it was about who could build the right thing.

If AI really is turning innovation into a solo sport, this was the ideal setting to prove it: smart, capable people equipped with powerful tools under tight time pressure. Every incentive pointed toward splitting up tasks, working in parallel, and offloading the heavy lifting to AI independently. But what we observed and heard from the teams told an entirely different story.

Framing the Problem and Designing the Solution

As we observed and talked with participants, two clear patterns emerged across nearly every team. At the start of the competition, each team began by discussing which problem area to focus on, working to understand and define the core of the problem, and identifying the target user. At this stage, team members used AI to gather and analyze research data (some collaboratively, some individually), then combined their findings and discussed them to reach a shared understanding of the problem space. This looked almost exactly like a classic MBA brainstorming session — a group of students in lively conversation around a table.

After that, most teams split up execution tasks: some focused on designing and building the prototype, others on crafting the presentation and narrative. At this stage, team members used AI individually to complete their assigned tasks, but they kept regrouping to discuss and test the solution's design.

Tasks that AI could handle or even take over entirely — synthesizing research findings, generating design options, building interfaces — genuinely moved faster when people split them up and worked in parallel, independently. But framing the problem remained, without exception, the area every team spent the most time on: they spent more time discussing findings, challenging each other's assumptions, and jointly deciding what to solve and how. One participant put it this way: 'Framing the problem is the most important part.' Another noted: 'Narrowing down to one clear problem is hard, even with AI's help.'

The second area was solution design. Since the cost of building a prototype has dropped to nearly zero, prototypes have taken on a new purpose. As one student explained: 'Prototyping isn't the final product — it serves as a starting point for discussion. I especially like that about the AI era.'

The prototypes teams built, and their subsequent iterations, surfaced important questions: Who is the actual user? How would people discover this? What happens if the data isn't available? The prototype didn't answer these questions, but it made them impossible to ignore.

The winning teams offered a clear demonstration of how insight-driven, collaborative decisions about problem framing led to innovative solutions — with AI serving as the execution engine that let them build a working prototype within a single day.

The overall winning team created the NYC Grocery Price Index. They collected pricing data from stores across the city, rated each one on value for money, and built both a consumer-facing app and a concept for an in-store display based on it. The working app they built in six hours was impressive. But what set them apart was how they framed the problem: presenting food affordability as a transparency issue that could be solved by making price comparison easier.

The winners of the High Impact Prize proposed turning New York's existing 13,000 grocery stores into community wholesale hubs. Rather than building new infrastructure, they solved the access-to-goods problem by connecting neighborhoods to wholesale prices through stores that already existed. The team recognized that the solution was already there — it just needed better coordination.

The winners of the Prototype Prize turned a public complaints database into a crowdsourced map showing where bike lanes had broken down. Using data the city already had but hadn't made public, they gave residents a tool to advocate for repairs.

Teams Benefit from a Shared Space

Most buildathon participants had no engineering background and no prior experience with the tools they used. Even so, every team produced a working, well-grounded prototype within six hours. As one participant put it: 'Turns out you don't need to be a developer to build a great prototype!'

But teams that tended to work in parallel using separate AI chats often ran into trouble. One participant explained: 'It was difficult because everyone was using different chats, which led to information overload and wasted time.'

Other teams got around this limitation by working in a single shared chat. Another participant said: 'I used to think AI worked best one-on-one, with a single person entering the prompts. But once the whole team was together with the AI, I realized we had a much better chance of using it collaboratively.'

Several participants noted that AI feels different in a shared workspace. 'Using AI often feels like a solo, isolated task,' one said. 'What I like about [working in a shared space] is being able to collaborate fully at every stage of the process. It's so easy to see what others are working on, and to help out or give feedback.'

When people use AI on their own, they're limited to their own perspective. We already have evidence that teams using AI outperform both individuals and AI-free teams in output quality. What we observed at the buildathon shows that when teams use AI in a shared space where every member can see the results and react to them in real time, AI becomes a tool for testing and critiquing ideas faster — and for applying the team's collective judgment.

Collaboration — and Competitive Advantage — Move Upstream

One participant saw the bigger picture: 'AI makes individuals more powerful at building or developing a product. Team collaboration is shifting its focus away from executing specific tasks and toward designing the process itself.' That's a fundamental shift.

For decades, for instance, collaboration in product development was about coordinating execution: who builds which feature, how the pieces fit together, making sure everyone's work lines up. That kind of coordination is still necessary, but it's no longer the bottleneck. The bottleneck has moved upstream: Are we building the right thing? Do we understand the user well enough? Have we framed the problem in a way that leads to a meaningful solution?

These questions can't be resolved in parallel. They require the friction that comes from clashing perspectives. They require teams to slow down and argue before speeding up to build. Several participants noted that AI is 'good at execution, but not at coming up with ideas,' and 'useful, but still dependent on human judgment.' Another said simply: 'You still need human involvement.'

As AI takes on more of the 'how,' people become more responsible for the 'what' and the 'why' — questions that are, by their nature, collaborative.

This doesn't mean AI makes execution easy, or that collaboration is only useful for framing problems. Building something still requires skill, taste, and judgment. Teams still need to coordinate execution. AI isn't making collaboration obsolete — on the contrary, it's making the messy, uncomfortable, but necessary work of jointly shaping problems more important than ever.

Three Things Managers Need to Do Differently

Here is what the buildathon teaches us about setting up teams — whether in product development or other workflows — for success in the AI era.

First, prioritize framing the problem. In an era when anyone can build a working prototype in a few hours, competitive advantage doesn't come from building faster. It comes from building something no one else thought of — because you framed the problem better. This is uncomfortable, because while AI tools make execution ever more efficient, framing the problem feels slower and messier by comparison. There's no clear metric of progress here; you often feel like you're going in circles. The temptation to jump straight into building something — if only to feel productive — is strong. But as one participant put it: 'Rushing to a solution without understanding the problem forces you to start everything over again.'

Managers need to actively protect time for this work. That means: starting projects with problem framing rather than solution brainstorming; rewarding teams for thinking deeply about the problem rather than simply executing fast; being prepared for debates that seem to go in circles — that's often exactly what a good problem framing looks like from the inside; and recognizing that the team member who stops everyone to ask 'what problem are we actually solving?' is adding more value than the one rushing to build.

Second, use prototypes to clarify the problem. Building has become so easy that it has fundamentally changed what a prototype is for. Prototypes used to come at the end of the process, once you'd figured out what you wanted, because they were expensive. Now, because they're cheap and fast, they can be built early — not to show off an answer or jump straight to execution, but to sharpen the debate about direction. That's the new job of a prototype: making disagreements visible while they're still cheap to resolve.

This requires managers to: push teams to build rough, fast prototypes early rather than polished ones; judge a prototype not by how refined it looks but by what questions it surfaces; expect the first prototype to be wrong — that's exactly how it should be; create space for the team to discuss what the prototype revealed; and make sure teams don't fall in love with their first prototype, but instead use it as a foundation for discussion.

The old workflow was: understand first, then build. The new workflow is: define the problem well enough to build something rough, then use that prototype to define the problem more clearly.

Third, organize around perspectives, not skill sets. But prototypes only become a useful learning tool when the right perspectives are in the room to interpret what they reveal. If AI really does turn everyone into a builder regardless of technical skill — and we saw this proven consistently in a single day — then what's the point of organizing teams around who can code, who can design, and who can do research?

These differences still matter, but not as much as they used to. The best-performing teams weren't the most technical ones. They brought different perspectives to understanding the problem: someone who understood the policy landscape, someone who had personally experienced the problem, someone who could think deeply about business models.

This suggests a different way of building teams: optimize for coverage of perspectives rather than coverage of technical skills (in product development, that used to mean one engineer, one designer, one product manager). Who needs to be in the room for the problem to be fully understood? Who can spot the blind spots in the team's thinking?

One student observed: 'Team boundaries are becoming increasingly blurred, because AI tools let individuals act like an entire company.' That's true, but the flip side is that standing out 'requires addressing users' problems more deeply and directly, precisely because the tools have become so accessible.' If everyone has access to similar AI tools, your team's edge doesn't lie in technical capability — it lies in how deeply you understand the problem. And that depth comes from bringing together people who see the problem differently.

The students who built solutions to New York's problems in six hours confirmed something many of us who study collaboration and innovation had already suspected. The question isn't whether AI will replace teams — it's how teams will adapt to do the work AI cannot: the deeply human work of deciding which problems are worth solving, and for whom.

The teams that grasp this first won't simply build faster. They'll build what matters.