Original
A Case for Adding Healthy Friction into AI Workflows
Why the best AI workflows push back, and how alignment through debate delivers better quality than frictionless speed.
Most conversations about AI right now focus on speed. We measure success by how quickly a first draft appears, how many lines of code get generated in a minute, or how fast a concept moves from a prompt to a working screen.
Speed is easy to measure. Quality, coherence, and architectural durability are much harder to capture in short-term metrics.
When generation costs nothing, the path of least resistance is to accept the first plausible answer. If an AI tool agrees with every prompt and executes without hesitation, you get impressive velocity. But you can also accumulate a lot of invisible debt along the way.
Building my portfolio site was a hands-on project to test my own AI workflows. I didn’t use a visual canvas like Figma. I worked largely from the terminal and my phone, moving from conceptual discussions to ASCII wireframes, semantic HTML/CSS prototypes, and browser-based tuners.
Throughout that process, I found that the most valuable moments weren’t the ones where the tools moved fastest. They were the moments where the AI and I pushed back on each other, debated trade-offs, and worked through disagreements.
It can be frustrating in the moment to stop and debate, and it definitely slows down immediate velocity. But in my experience, that friction consistently uncovers blind spots and leads to much stronger decisions.
Alignment Requires Debate
My natural working style has always leaned toward alignment rather than decree. When I lead teams, I try not to rely on top-down authority. I prefer to put ideas on the table, invite dissent, encourage devil’s advocacy, and work toward explicit agreement.
That process takes time, and it requires being comfortable with having your own assumptions challenged. I try to hold strong opinions loosely, knowing full well that I could be wrong, and that better options are out there.
When I started directing AI models for this project, I realized the same dynamic applies. If you treat an AI simply as an obedient junior assistant that executes every prompt without question, you get passive compliance. The model won’t tell you when an idea feels half-baked, when a metric looks questionable, or when a shortcut creates downstream problems.
To get past passive compliance, you need two things: permission to disagree, and solid ground to stand on.
Creating the Ground for Debate
You can’t have a productive debate in a vacuum. Without shared criteria, disagreement just turns into two subjective opinions arguing in circles.
Early in the project, we established that ground. We wrote foundational documents covering brand strategy, audience goals, and voice principles. Along the way, we captured every major fork in the road as a lightweight Architecture Decision Record (ADR), documenting what we decided, what we rejected, and why.
Coupling those strategy documents with our ADRs gave us a concrete baseline. When I asked for something that drifted from our settled principles, the AI had standing permission to check the request against those documents and push back. And when the AI suggested a shortcut, I had a documented standard to hold it to.
Here are three everyday moments from the build where that friction made a real difference for me.
1. Strategy: The Photography Section
The first debate came when I suggested adding a photography section to the site.
I invited the pushback directly: “push back if I shouldn’t, but I feel like it’s part of my creative expression.” (My team at work has joked about starting a drinking game for every time I say “push back on this,” but in this case, I genuinely meant it.)
The AI pushed back immediately. Looking at our strategy documents, it raised concerns about audience and dilution. For an audience of design and technology leaders, a loose collection of travel photos risked reading as a hobbyist gallery, competing for attention with the core case studies.
I didn’t want to drop the idea, but I also didn’t want to ignore the risk. The easy compromise would have been to tuck a small link into the About page and call it a day. Instead, we stayed in the discussion.
I provided a set of images from the Galápagos for the AI to review against our curation standards. As we talked through the work, I shared additional context: I had co-founded CreativeMornings Denver and directed its photography for years, alongside paid event work for companies like Adobe.
That context changed the architecture of the decision. Photography wasn’t just a hobby; it was credentialed creative work tied to community leadership.
We settled on an explicit architectural decision (ADR-021): Photography became its own top-level section, but with a clean split. The community-leadership story lives in the About section, while the curated visual sets live in Photography. Neither of us simply folded, and the resulting structure was much cleaner than what either of us started with.
2. Data Integrity: The Component Footprint Chart
A second disagreement happened while building a chart for a case study to visualize how we systematically deprecated a legacy UI framework across an enterprise platform.
The initial draft of the chart had a label I didn’t recognize: “reduction targets in force.” I stopped the work and asked where that came from, pointing out that the data didn’t support that label. The AI admitted it had invented a causal narrative to explain a visible drop in the curve.
Then the debate turned to how the data was tracked. We were counting legacy component instances over time. For several months, we saw steady progress, followed by an eight-month gap in reporting. When we scanned again, the numbers had dropped dramatically.
The AI pushed back, arguing that our measurement scope had changed because several high-instance packages had been completely removed from tracking. In my view, using the tool to identify packages that had too many instances to migrate by hand—and choosing to deprecate the entire package instead—was the tool doing its job. That was real reduction.
Still, the AI had a fair point: drawing a solid, continuous line across that gap would hide the fact that the tracking scope had narrowed between scans.
We agreed on a balanced visualization: a solid line for the consistent scan period, a dashed line across the reporting gap, and an explicit key labeling the tail as “reduced scope.”
The resulting chart didn’t look like a spotless marketing graphic. It looked like real-world data, with the uncertainties and scope shifts made visible rather than smoothed over.
3. Architecture: Woven Leadership
Midway through the project, some peer feedback gave me pause. A few colleagues mentioned that the early site looked like a great developer portfolio, but the leadership scope wasn’t obvious.
The AI’s first proposal was straightforward: add a fourth, standalone “Leadership Case Study” to headline the management story.
It sounded reasonable at first, but the more I looked at it, the more contrived it felt. A standalone leadership case study risks reading like an ungrounded list of accomplishments. In my career, leadership has never been separate from the work; it is how the work gets done.
I pushed back on the proposal and suggested we step back. Instead of inventing a new page to fix a perception gap, we walked through the actual stories of the teams I built, looking at how the token architecture, prototyping scale, and team federation models were themselves the proof of leadership.
We agreed to drop the standalone leadership piece entirely. Instead, we wove the leadership narrative directly into each case study under a consistent “builder who leads” structure. Leadership became the through-line across the engineering and design systems work, rather than an isolated claim.
What This Means for AI Workflows
None of these examples are earth-shattering. They are small, everyday decisions about navigation, chart lines, and content structure. But that is precisely the point.
When teams measure success strictly through short-term velocity, the incentive is to avoid debate, accept the first generated draft, and move on. That might look great on a sprint dashboard, but it often leaves unexamined assumptions and fragile architectures behind.
For leaders and teams building AI workflows, here are a few principles that I feel have served me well:
- Build the ground first: Write your strategy, principles, and architecture decisions down early. AI agents need machine-readable context and standing constraints if they are going to help you evaluate trade-offs.
- Invite dissent: Explicitly prompt models to challenge your premises, look for edge cases, and act as devil’s advocates before jumping into execution.
- Value alignment over compliance: If an AI immediately agrees with every request, treat it with healthy skepticism. The goal isn’t an echo chamber; it’s finding the blind spots you can’t see on your own.
- Accept the short-term slowdown: Taking twenty minutes to debate a data gap or challenge an architectural choice feels slow in the moment. But it prevents the weeks of rework that come from building fast in the wrong direction.
Closing Thought
Directing AI effectively isn’t about how quickly you can prompt an answer. It’s about knowing what standard you hold the work to, and building a workflow where you and your tools can challenge each other to meet it.
I’d love to hear from other design and technology leaders: are you finding ways to build healthy friction and governance into your AI workflows, or are your teams mostly optimizing for speed?