Beyond the Vibe: Building AI Workflows That Work

This is an adapted, written version of a talk I gave in April 2026, as a lunch and learn on AI workflows.

I see a lot of people vibing with AI. Throw a prompt at it, take what comes back, hope for the best. That’s fine for small things. It’s great for exploration, for getting a gist of an idea. But it doesn’t scale.

AI amplifies whatever you give it. Good process or bad, structure or chaos, it doesn’t care. It just makes more of it, faster. What scales isn’t a better prompt. It’s a structured workflow, where AI supplies volume and speed and people supply judgment and direction.

My team validated this thesis in an AWS hackathon.

Where process beat vibing

In February, I joined a team in an AWS AI hackathon. We’d never met, and were in different cities. The hackathon was 48 hours with just over 50 competing teams. Our team’s first instinct was the same one everyone has: open AI, write a spec, and start running. I pulled us back. We weren’t even aligned on what we were building yet. AI makes you fast, but fast in the wrong direction is just a quick way to waste two days. Sometimes it does more harm than good.

To prepare for the hackathon, I had built my first two agents: one that helped with prompting strategy and one that had a working knowledge of Kiro, the tool we’d be working with.

We used AI at every step, but planning is where it mattered most. We described our goal and constraints to the prompting advisor, and it proposed a structured brainstorming playbook, which involved each of us asynchronously running a role-based tree-of-thought prompt — laying out options, pruning, and iterating to a solid idea. We then moved to lightning demos and dot voting. AI helped us synthesize the votes and move into alignment. Nobody moved until the plan was clear and everyone explicitly agreed that it was something we all wanted to build.

Design worked the same way. I talked through the interface with the AI, then moved to token-friendly ASCII wireframes, then to prompts for Figma Make, before any of it touched our actual prototype. That prototype got downloaded and folded back into the working build. The work went fast.

We finished top 5 out of about 50 teams and won “Best AI Workflow.” It didn’t happen because we moved fast. It happened because every phase had a process, and the AI amplified the process, not just the output.

It wasn’t all clean, though. We hadn’t set up real contracts between what each of us was building, so the second day went to integration, stitching everyone’s AI-produced pieces into something that actually worked together. We got there. But that gap, only a thinly defined shape for how the pieces would connect, turned out to be the same problem I’d run into again, at a much bigger scale, a few months later.

Building the toolkit

After the hackathon, I pointed those same two agents at a new problem: building more agents. They improved each other, then helped me build an agent-builder, something that could build other agents from a five-step process of its own: define the goal, shape the structure, implement it, document it, test it. Every new agent drew on the patterns of the ones before it. Two agents became nineteen in a matter of weeks. At the time, spinning up a new specialist for every task felt like the right move—even if managing that roster would eventually force another rethink.

The hackathon’s design phase bothered me. It was too much vibe design, not enough context. I wanted something closer to a real design process, with words before wireframes as a rule, not a lucky exception. So I built a design pod: a coordinator plus a set of specialists, each with real, narrow expertise. One handles strategy and feasibility. One handles user experience and cognitive load. One handles visual design. One handles visual assets and illustration, though it’s honestly terrible at drawing anything itself. It’s better for naming icons and pitching illustration ideas I then hand to something built for generating images. One has final authority on accessibility that nobody can overrule.

The coordinator itself doesn’t design. It facilitates by proposing a plan and spawning the specialists that the plan calls for, then synthesizes the result and documents all of it.

Explore before you commit

As I built the design pod, I wanted to test it against real use cases to see how it performed. I gave it an overview card from one of our applications, and handed it to the experience specialist for an audit. It came back with specifics like, “this violates Miller’s Law, sixteen elements crammed into a flat list when seven, plus or minus two, is the limit.” Each finding cited an actual UX law or accessibility standard.

From there I iterated, one version at a time, each sketch addressing something from the audit. The first restructured the information hierarchy. By the fourth, it had progressive disclosure, semantic grouping, numeric badges, and passing contrast. None of it touched a design file until the end. It was rapid exploration, conversation before creation, cheaper and faster than pushing out prototype after prototype, with the constraints baked in from the first exchange instead of bolted on at review.

As I pointed the agents at more work, gaps started showing.

From pipeline to facilitation

The first version of the design pod was a pipeline: one specialist handed off to the next, straight down the line. It didn’t work. There were no real contracts between them, so outputs were inconsistent. A bad assumption made early rode the whole chain downstream and got amplified at every handoff. On one project, an early agent doing competitive analysis mentioned it had come across an idea for a bento-box layout. By the third agent in the chain, that offhand remark had become the entire design. It was never decided, it just manifested. And with no traceability, I couldn’t even see where it happened, which meant it also burned a lot of time and tokens heading in the wrong direction before anyone noticed.

So I restructured it. The coordinator stopped being an orchestrator and became a facilitator. It starts by identifying where you are in an eight-phase design process it already knows: stakeholder alignment, research, problem definition, concept ideation, information architecture and wireframing, prototyping, usability testing, handoff. You can enter at any phase and resume across sessions, and later phases feed back into earlier ones instead of running in a straight line.

From there, the loop underneath is the whole point: propose, approve, execute, synthesize, decide, document, next step. Every decision gets documented. Every artifact gets numbered and timestamped. I can close a session and pick it back up days later without losing the thread. That’s what structure gives you that vibing never will.

What the full system produces

The clearest example of all this came when a team building a customer-support tool needed real design support, and I ran the whole system against it end to end.

It started with persona archetypes. The pod built them from usage data: access levels, role patterns, and behavior. Every claim was tagged as validated (backed by data) or inferred (still needing a human to check it). The research team could use those tags to identify what they needed to validate.

From there, the strategy specialist wrote a proper design brief: the overview, the constraints, what success would look like. That brief became the spec the other agents worked from. Three specialists then analyzed the interface in parallel, and the coordinator synthesized what came back into 26 prioritized issues.

The recommendations were concrete. As an example, three transfer buttons looked identical, regardless of the distinct consequences of clicking them. A proposed fix borrowed directly from our company’s design system. It was a destructive-action red for the irreversible option, the system’s primary blue for the safe default, an outlined secondary style for the one that just holds. This wasn’t a casual prompt and a thumbs up. It was a structured audit, prioritized, and backed by standards I could point to.

Agents as software

Once the agents were stable, I prepared them for distribution to the team.

By this point there were nineteen agents in the system, and I treated each like software. If an agent was going to earn a place in the workflow, it needed real rigor. Every agent was semantically versioned, so we knew exactly what was running. Every agent had static tests to confirm it was structurally sound, smoke tests to confirm it did what it should, and conflict tests to ensure it didn’t drift. We also gave them modes, loaded via progressive disclosure to maintain a high signal-to-noise ratio. As an example, the experience specialist had modes for a quick answer, collaborative exploration, and structured audits.

The part that scales

None of this is finished, and it isn’t static. In the months since this talk, my thinking has kept moving. Managing nineteen autonomous agents solved our handoff problems, but it introduced its own coordination tax. It forced me to realize that an agent has to earn its existence through infrastructure—sandboxing, external tool connections, or a strict gatekeeping role. Most of what I originally gave to dedicated agent personas actually belonged in focused, reusable skills.

But whether you’re coordinating a pod of agents or executing a single skill, the core principle holds: AI amplifies whatever you give it. It will generate a thousand clean lines of code or a thousand-line mess without telling you which one you’re looking at. Vibing is fine for exploring an idea or getting a rough sense of something fast. But production takes structure: define the constraints, align on the plan, and let the tooling amplify the process instead of the guesswork.

That’s the part that actually compounds. I’d love to hear how other people are drawing that same line: where does vibing stop earning its keep for you, and structure have to take over?