Beyond the Vibe: Building AI Workflows That Work

This is an adapted, written version of a talk I gave internally 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 whatever 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.

Here’s why: AI amplifies whatever you give it. Good process or bad process, 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.

I feel my team validated this thesis in a hackathon.

Where process beat vibing

In February, my team of four entered an AWS AI hackathon. We’d never worked together before, and we were all in different cities. 48 hours, just over 50 teams competing. Our first instinct was the same one everyone has: open the AI, write a spec, 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 faster 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, one that had a working knowledge of Kiro, the tool we’d be building 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. We agreed to run the 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. Then we 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 first, in ASCII wireframes, then in prompts for Figma, before any of it touched our actual prototype. Words before wireframes. That prototype got downloaded and folded back into the working build.

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 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.

That was February, with two agents. Here’s where it went.

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 draws on the patterns of every agent before it. That’s the flywheel. Two agents became nineteen in a matter of weeks.

The hackathon’s design phase had bothered me the whole time. 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. What it’s good for is naming icons and pitching illustration ideas I then hand to something built for actually generating images. One has final authority on accessibility, and nobody overrules it.

The coordinator itself doesn’t design anything. It facilitates: proposes a plan, waits for approval, spawns the specialists that plan calls for, then synthesizes what comes back 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 existing overview card from one of our applications, a real interface already live, 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 one addressing something the audit had flagged. The first restructured the information hierarchy. By the fourth, it had progressive disclosure, semantic grouping, and contrast that actually passed. 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 kept pointing the agents at more work, the gaps started showing.

From pipeline to facilitation

I built a research assistant next, for web research and competitive analysis. But the real lesson from that stretch wasn’t about research. It was about how the agents talked to each other.

The first version of the design pod was a pipeline: one specialist handed off to the next automatically, 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 mention had become the entire design. Nobody decided that. It just accreted. And with no traceability, I couldn’t even see the step 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. The first thing it does is place you within an eight-phase design process it already knows: stakeholder alignment, research, problem definition, concept ideation, IA 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 it is the whole point: propose, approve, execute, synthesize, decide, document, next step. A person is in that loop every cycle. 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 personas, but not the abstract kind. The pod built them from real usage data: access levels, role patterns, actual behavior, not guesses. Every claim in each persona got tagged as validated, meaning it was backed by real data, or inferred, meaning it still needed a human to check it. Those tags mattered later, when the personas got handed to a research team to verify against how people actually use the tool.

From there, the strategy specialist wrote a proper design brief: the overview, the real constraints, what success would look like. That brief became the spec every other agent worked from. Three specialists then analyzed the interface in parallel, and the coordinator synthesized what came back into 26 issues, sorted by how much they mattered.

The recommendations that came out of it were concrete, not directional. One example: three transfer buttons that all looked identical, no matter how different the consequences of clicking them actually were. The fix borrowed directly from Kite, the design system team I ran earlier in my career — 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. Contrast ratios included, before and after shown side by side. Internal shorthand got translated into language a person could actually act on. 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

As I felt confident in the agents, I needed to prepare them for distribution to the team.

By this point there were nineteen agents in the system, and I was treating each one like an actual piece of software, not a clever prompt. Every agent is semantically versioned, so I know exactly what someone’s running when they use one. Every agent has tests: static tests to confirm the files it depends on actually resolve, smoke tests to confirm it does what it should, and conflict tests to confirm it doesn’t do what it shouldn’t, whether it stayed disciplined or just got lucky. The agents were given modes, loaded only when necessary to maintain a high signal-to-noise ratio. As an example, the experience specialist has a quick-answer mode, a collaborative explore mode, and a structured audit mode.

The part that scales

None of this is finished, and it isn’t perfect. The agents still give conflicting advice sometimes. AI still misses things a seasoned designer might catch immediately. It’s a thinking partner, not a replacement, and human judgment is still the part doing the real work, not a formality bolted on top.

AI amplifies whatever you give it. You can generate a thousand clean lines of code in minutes, or a thousand-line mess, and it won’t tell you which one it handed you. Vibing has its place. It’s genuinely good for exploring an idea or getting a rough sense of something fast, and it’s just a different activity than building for production. But the opposite of vibing isn’t going slower. It’s being intentional: plan what you want to do, use AI to help you get there, align on it, then act.

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?