Building with AI is easy. Building & shipping as a team with AI is not

Conway's Law isn't a suggestion. It's a warning.

Any organization that designs a system will produce a design that mirrors its own communication structure.

— Melvin Conway, 1968

For most of software history, this was a slow-moving problem. Organization structures and culture calcify over years. You had time to notice, even if you rarely acted.

Then AI entered the picture — and the compounding went from slow to overnight.

The pattern has always been visible in how organizations historically built software. Apple's centralized structure — hardware and software under unified leadership — produced tightly integrated products and a closed ecosystem that reflects that hierarchy to this day. Oracle's large legal and compliance apparatus produced software that prioritizes enterprise contracts and risk management over user experience. These aren't design failures. They're organizational features, faithfully rendered in code over decades.

The difference now is speed. AI doesn't change the underlying dynamic — it just removes the lag that used to hide it.

We came up to this challenge when working with a client adopting vibe coding as part of their discovery and product development process.

Imagine you’re looking at a prototype somebody else whipped up yesterday. You’re reviewing a tool they say would be a game changer for the job and maybe the whole industry. But then you see a number on a dashboard chart. It looks wrong. Or maybe it's right. It looks like a complex analysis, but is it accurate, or even relevant? That's the problem — and it's not only a data problem. It's a team problem.

Toboggan Labs came in to help a client design a financial analyst AI agent as part of a next generation business intelligence platform. The founder, had both the domain expertise and the vision: small under leveraged finance teams, drowning in Excel, making decisions weeks too late because the right number required chasing data across too many places. We had leveraged Lovable for rapid prototyping, real customer data, and a capable engineering team.

The early demos were genuinely impressive — the kind of thing that makes you think you're further along than you are.

What we missed was something I now think about with almost every AI project: these tools don't just accelerate what's working. They amplify everything — including what isn't working.

The dysfunction wasn't obvious at first. The team had split into two worlds — a vibe-coded prototype environment and a production codebase quietly diverging from it. Every time something needed to move between them, it required a translation that was slow, lossy, and dependent on domain knowledge that nobody on the engineering side had.

In most business intelligence solutions whether a metric is calculated correctly depends on how you define it, which benchmark cohort you're comparing against, nuances that live in the heads of practitioners who've spent years in the industry.

We'd built infrastructure, multi-tenancy, metric calculation layers all before we'd established, with the client in the room, what "correct" or "good enough" even looked like. We were building for scale before we'd finished building for learning. And because we were moving so fast, that gap compounded quietly for months.

AI didn't create any of those problems. But it made them faster and louder. On the surface a vibe-coded dashboard looks production-ready in days. That speed disguised how much we hadn't figured out yet. The result: a month to turn one prototype into something the client could actually validate. Not because the engineering was hard — because every step required a kind of judgment that wasn't in the loop.

When the project paused and the team reset — the most important thing that changed wasn't the tooling. It was that the domain expert was finally at the center of the process rather than downstream of it. The founder could have a conversation with an investor or customer Monday and we could test something by Wednesday. Checkpoints replaced sprint planning: not "what did we ship" but "what did we learn by this date." The deadline for an investor demo didn't tell us how long things would take — it told us what to prioritize first and what to cut.

My own role as a Product Designer shifted in ways I'm still processing. Less time designing features, more time designing how the team worked, and how to better enable this rapid learning loop. Building out Lovable project templates with engineering best practices already baked in, so prototypes didn't require a full rebuild to become real. Creating more accessible data annotation tools so domain experts could see and judge what the AI was actually doing with their data. Iterating on how we can make the LLM reasoning more legible to the team so we could validate it. Ultimately, it came down to bringing back product management fundamentals —translating domain knowledge into buildable prompts and reducing what got lost every time an idea moved from the founder's head into something actionable.

When you move this fast, a misaligned team doesn't stay misaligned quietly. It ships its misalignment.

Looking back, every one of those things was about the same thing: tightening the feedback loop, and getting the person who actually knows if something is right closer to the work, earlier. That's not a design or an AI specific insight. It's actually an organizational one. AI just makes it more urgent — because when you move this fast, a misaligned team doesn't stay misaligned quietly. It ships its misalignment.

The harder, less-discussed version of this problem is that working with AI solo is mostly figured out. Working as a team with AI is not. Shared context fractures when everyone is in their own session. Now that AI can generate ten versions of something, the team still has to decide which one is right — and by what standard, and whose judgment counts. When the domain expertise lives in one person's head, the whole system is only as fast as that person can stay in the loop.

We are discovering some of these answers with teams on the frontier of these new ways of working. What's exciting is exploring how organizational design and agentic design can inform each other, revealing new patterns as we build in this emerging space. While most teams building this way right now are in the same place — I believe the real work lies in learning more from the friction than from the frameworks.

If that's the kind of problem you want to work on, talk to us about joining Toboggan Labs.