Tech-Stack Selection — by an AI council
Choose the right stack without falling for hype or sunk cost. Four rival AIs debate it and hand back: A recommended stack with the trade-offs and the decision criteria made explicit.
A recommended stack with the trade-offs and the decision criteria made explicit.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Stack debates are usually proxy wars — hype versus sunk cost — so the seats are chosen to cancel those forces: the Software Architect evaluates fit to the actual problem, the ML Engineer covers the data-and-AI corners of modern stacks, and the Performance Engineer tests claims about scale against arithmetic. The First-Principles Thinker strips vendor marketing to what the tool must actually do, the Contrarian argues the unfashionable option on merit, and the Pragmatist prices the learning curve in shipped-features foregone.
Each seat runs on a different frontier model — GPT, Claude, Gemini, Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A two-founder team building a B2B document-workflow product is torn between the stack they know (Rails and Postgres) and a serverless TypeScript stack a respected friend swears by.
The unpriced line item in this comparison is fluency: you ship your first customer-visible feature in week one on Rails, versus week five while learning a new mental model of state. For a two-person pre-revenue team, four weeks of shipped features is the difference between having and not having design partners this quarter. The friend’s stack is not wrong — it is wrong for who is holding it.
Derive the requirement before the religion: document workflows are long-lived stateful processes — drafts, approvals, versions. That is the one workload where a stateless function model adds friction rather than removing it, because every step must reconstruct context a monolith keeps in hand. The problem shape argues for the boring relational core regardless of anyone’s taste.
Steelmanning the serverless case anyway: if the product’s core were spiky, embarrassingly parallel document processing — OCR bursts, batch transforms — pay-per-invocation beats idle servers and the argument flips. Worth checking the roadmap honestly. If that workload is coming, carve out that one path as functions later; it does not need to be the foundation.
Questions
Can it compare two specific technologies, not just philosophies?
Yes — name the candidates and the debate runs on their actual properties: maturity, hiring pool, operational burden, ecosystem, failure modes. The persona mix keeps it honest about the boring dimensions (who maintains it at 2 a.m., who can you hire) that comparison blog posts skip.
What if my team already disagrees — can this arbitrate?
Paste both positions as they are actually argued internally. The Steelman-style treatment means each side gets its strongest version stated before the trade-off is judged, which tends to defuse the internal politics: the losing option gets an honest runner-up case and a written reversal condition, not a dismissal.
How does the council avoid just recommending whatever is popular?
The Contrarian seat exists to argue the unfashionable option and the First-Principles Thinker strips marketing claims to mechanics, so popularity enters only as what it really is: a proxy for ecosystem maturity and hiring. The verdict states the conditions under which the recommendation would be wrong.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Want full control — pick your own minds, set the depth? Open the full council →