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?"
Top comments (2)
The two-spec collision in your story is not the failure mode, it is the fix, and it beats the prescription you land on. Neither the business manager nor the IT team could have surfaced their own framing alone, no matter how carefully they asked what perspective is missing. The missing perspective is invisible from inside the frame that is missing it, which is the whole trap: the head asking "what did I leave out" is the same head whose frame decided what got left out. You can enumerate the perspectives you already know exist. The dangerous one is the perspective you do not know to prompt for, and introspection cannot reach it by construction.
What reached it was the delta. Two independently framed outputs collided, and the difference made each one's assumptions visible from outside, the one thing neither could do from inside. So the move that actually works is not prompt-from-multiple-perspectives, because that is still one head choosing which perspectives to add. It is get outputs from independently framed sources and read where they disagree. The disagreement is the only instrument that shows you an axis you did not already know to look along.
The part that makes this urgent is fluency. Fifty pages, well structured, technically sound, is what makes an inherited bias credible. A sloppy one-sided spec gets questioned. A polished one-sided spec gets adopted. AI does not just think like you, it raises the production value of thinking like you, so the biased answer now arrives pre-armored with the look of thoroughness, and the missing perspective has to argue against something that already looks finished. The objectivity is not only an illusion, it is a well-produced one, and production value is exactly what suppresses the question you want people to keep asking.
YES