A few weeks ago a Business Manager handed me a 50-page AI-generated technical spec. The document was impressive. The perspective behind it was the problem.
I had talked to him a few days earlier about a new internal tool the company needed. We discussed the use case and the requirements in depth. Later on, I discussed those same requirements with my IT team and assigned them the job of making the technical specification.
But before my team finished, the Business Manager handed me his own spec. A spec ready to be executed. The document was generated with AI assistance and it was impressive — fifty pages long, detailed feature breakdown, implementation timeline, cost projections. Everything looked professional. The AI had done exactly what it was asked to do.
I read the whole document and noticed a problem. Not with the quality of the document but with the perspective that shaped it.
The spec called for a manual Excel-based workflow with several manual steps and validations in-between. All seemed clean and manageable, matching the Business Manager's mental model of how that business workflow should work.
When I checked the spec my team was working on using the same AI assistance tools, I noticed they had produced something completely different: automated data ingestion, real-time dashboards, API integrations with existing systems.
Both specs addressed the same business need. Both were technically sound. Both could be built in roughly the same timeframe. But they were fundamentally different architectures, shaped by fundamentally different perspectives on how work should happen.
The Business Manager's version was optimized for control and visibility — he could see every step, every piece of information and approve everything manually at any stage. The technical lead's version optimized for efficiency and scale — minimal manual intervention, automated error handling, designed to handle 10x the current volume without breaking.
Neither person was wrong. But the AI amplified their existing perspectives without challenging them. The Business Manager got back a business-shaped solution. The technical lead got back a technical-lead-shaped solution. The AI didn't think for either of them. It thought like them.
The Perspective Filter
This dynamic shows up everywhere once you start looking for it. A marketing director using AI to design a customer onboarding flow produces something heavy on touchpoints and engagement metrics. An operations manager designing the same flow produces something optimized for throughput and error reduction. A customer success lead produces something focused on retention signals and satisfaction measurement.
The underlying business requirement is identical in all three cases: get new customers productive as quickly as possible. But the AI output varies dramatically based on who wrote the prompt, because the AI inherits the prompter's definition of what "productive" means and what "quickly" optimizes for.
The dangerous part isn't that these perspectives exist (they always have). The dangerous part is that the AI output feels objective. When someone shows you a fifty-page specification that an AI helped generate, the instinct is to evaluate it as a neutral technical document. But it's not neutral. It's a reflection of whoever wrote the prompts, processed through a layer that makes their bias harder to see.
I've seen this pattern derail projects. A business stakeholder uses AI to spec out a technical solution, presents it to the engineering team as "the requirements," and expects implementation to be straightforward. The engineering team looks at the spec and immediately sees the architectural problems — missing error handling, no consideration for scale, integration points that don't exist in the current system. But because the spec was "AI-generated," there's an assumption that it must be technically sound. The AI becomes a shield against technical pushback.
The Authority Transfer Problem
The most insidious version of this is when AI output gets treated as authoritative simply because it came from AI. "The AI said this is the best approach" becomes a conversation-ender, as if the AI has some independent perspective on what "best" means.
But AI doesn't have opinions. It has training data and pattern matching. When it recommends an approach, it's recommending based on the patterns it learned and the way the prompt was framed. If you prompt it from a cost-optimization angle, you get cost-optimized recommendations. If you prompt it from a user-experience angle, you get UX-optimized recommendations. If you prompt it from a compliance angle, you get compliance-heavy recommendations.
The choice of angle isn't made by the AI. It's made by whoever writes the prompt. And that choice shapes everything that follows.
I saw this also play out in a project where the initial AI-generated architecture called for a microservices approach. The recommendation looked sophisticated, included proper service boundaries, even had a reasonable deployment strategy. But when I dug into the prompts that generated it, the framing was entirely around scalability and modularity. No one had prompted the AI to consider the team's actual experience with microservices, the operational overhead, or the debugging complexity for a team that had been running monoliths for five years.
The AI gave exactly what it was asked for: a scalable, modular architecture. But it wasn't asked to consider whether that architecture matched the team's ability to operate it. The prompter's bias toward modern architectural patterns shaped an output that would have been expensive to maintain and difficult to debug for that specific team.
Multiple Perspectives, Better Decisions
The solution isn't to stop using AI for architectural decisions. The solution is to recognize that a single perspective using AI produces a single-perspective architecture, no matter how sophisticated the output looks.
The same prompt from different organizational roles produces different answers. Neither is necessarily right, but the combination produces something better than either alone.
When working on AI projects now, I run it through multiple perspectives — typically business, technical and security. Each prompt is framed for that particular role's priorities and constraints. Then I look at where the outputs diverge.
The AI output from each perspective is always different. Not slightly different — fundamentally different. The business stakeholder gets a solution that fits the budget and timeline. The technical lead gets a solution that won't create technical debt. The security team gets a solution that won't create compliance problems.
None of these perspectives alone produces a complete architecture. But taken together, they surface the trade-offs that a single-perspective approach would miss. Without that contrast, you don't have an architecture decision. You have a single-perspective recommendation that looks complete.
The conversation shifts from "this is what we should build" to "here are the different ways we could build it, and here are the trade-offs between them."
The Bias Is in the Prompter
The fundamental insight is that AI suggestions are not opinions of the AI. They are reflections of the prompter back to themselves, processed through a layer that gives them a veneer of objectivity. The output looks neutral but the input never was.
This matters for how technical leaders should handle business-side AI-generated specs. Treat them as input, not directive. The spec represents one perspective on the problem, shaped by one set of priorities. It's valuable input. But it's not complete requirements.
And it matters for how business leaders should think about AI-assisted decision-making. "The AI said so" doesn't close the architectural conversation. It opens it. The question isn't whether the AI's recommendation is correct. The question is whether the perspective that shaped the prompt captured all the constraints that matter.
The leverage comes from using AI to rapidly explore multiple perspectives on the same problem, not from using AI to validate a single perspective more convincingly. The bias isn't in the AI. The bias is in the prompter. The AI just makes it harder to see.
So when someone comes to you with an AI-generated solution, the first question shouldn't be "is this technically sound?" The first question should be "what perspective shaped this output, and what perspectives are missing?"
Originally published at unlockedconsulting.ai.
