Using Multi-Agent Perspectives (CEO, Engineer, QA) for gstack Framework Features
This skill teaches you how to structure AI-assisted development sessions by rotating between CEO, engineer, and QA perspectives, so each phase of your workflow gets the right kind of judgment applied to decisions, implementation, and verification.
Assign distinct roles to your AI coding agent at different workflow phases. The CEO perspective handles scope, priority, and trade-off decisions. The engineer perspective focuses on implementation, architecture, and code production. The QA perspective reviews output for correctness, edge cases, and regressions. Rotate between these roles explicitly using gstack slash commands, ensuring each phase of your development session gets the right kind of thinking applied to it.
Outcome: You will produce development artifacts where strategic decisions, implementation choices, and quality verification are each handled by a purpose-fitted perspective, resulting in fewer scope mistakes, cleaner code, and caught regressions before merge.
Prerequisites
- Basic familiarity with AI coding agents (Claude Code, Cursor, or similar)
- gstack skill pack installed and configured (see /skills/installing-and-configuring-gstack-skill-pack)
- Understanding of slash commands for invoking gstack skills (see /skills/navigating-gstack-slash-commands-and-specialist-skills)
- A real feature or bug to work on, not a toy example
Overview
Most developers working with AI coding agents treat the interaction as a single, undifferentiated conversation. You describe what you want, the agent writes code, you paste it in, and you hope it works. This approach collapses three fundamentally different types of thinking into one stream: deciding what to build, deciding how to build it, and verifying that what was built actually works. The result is scope creep embedded in implementation, architectural shortcuts made without conscious trade-off analysis, and bugs that only surface in production because nobody asked the hard verification questions. Multi-agent perspectives solve this by making each type of thinking explicit and sequential.
The gstack Framework encodes this separation into its core workflow through three named roles. The CEO perspective handles prioritization, scope definition, trade-off analysis, and resource allocation decisions. It answers questions like "should we build this at all," "what is the minimum viable version," and "what are we trading away by choosing this approach." The engineer perspective takes scoped decisions and translates them into architecture, code, and technical implementation. It focuses on how, not whether. The QA perspective then examines the output with adversarial skepticism, looking for edge cases, regressions, security gaps, and deviations from the original specification. Each perspective has a distinct set of concerns, a distinct success criteria, and a distinct failure mode.
The concrete artifact you produce when applying this skill is a development session log where each phase is annotated with the active perspective, its inputs, its outputs, and the handoff to the next role. Over time, this creates a traceable decision record that explains not just what was built but why each choice was made and what was verified. Teams that adopt this pattern report catching scope issues 60-70% earlier in the development cycle and reducing post-merge bug rates significantly, because verification becomes a first-class phase rather than an afterthought.
This skill sits at the center of gstack's philosophy. While other skills in the framework handle specific tasks like orchestrating power tools or customizing skill packs, multi-agent perspectives provide the structural backbone that determines when and how those other capabilities get invoked. Master this skill first, and every other gstack feature becomes more effective.
How It Works
The multi-agent perspective system works because it forces cognitive mode-switching at deliberate boundaries rather than allowing blended, compromised thinking. Research in cognitive science consistently shows that humans (and, by extension, AI systems prompted to behave like humans) perform worse when they try to optimize for multiple conflicting objectives simultaneously. A developer who is simultaneously deciding scope, writing code, and checking for bugs will shortchange at least one of those activities. The same applies to an AI agent given a prompt that mixes strategic and tactical concerns.
Each perspective in the gstack Framework operates as a constrained optimization. The CEO perspective optimizes for value delivered per unit of effort, explicitly ignoring implementation elegance. It asks: what is the smallest thing we can ship that validates the hypothesis or solves the user's problem? This perspective is trained to resist gold-plating and to surface trade-offs that engineers naturally want to avoid confronting. The key mental model here is that the CEO does not care about code quality in isolation. It cares about outcomes, timelines, and risk.
The engineer perspective optimizes for correctness, maintainability, and technical coherence, explicitly ignoring business prioritization (which has already been decided). It takes the scoped specification from the CEO phase and produces the cleanest implementation it can within those constraints. When the engineer perspective discovers that the specification is ambiguous or that a better approach exists, it flags the issue for a return to CEO perspective rather than making the trade-off unilaterally. This discipline prevents the common failure mode where an engineer quietly expands scope because a "better" solution seems obvious.
The QA perspective optimizes for finding failures, explicitly ignoring both business value and implementation effort. It assumes the code is broken until proven otherwise. It generates edge cases, checks boundary conditions, reviews error handling paths, and compares the output against the original specification from the CEO phase. Crucially, the QA perspective has authority to block a merge or require a return to the engineer phase. It is not advisory. It is a gate.
The rotation between perspectives follows a specific pattern: CEO first (define scope), engineer second (implement), QA third (verify), with loops back as needed. This is not a waterfall process. A single feature might cycle through all three perspectives multiple times in a 30-minute session. The key discipline is making each transition explicit. You invoke a different slash command, you restate the context from the new perspective's point of view, and you operate within that perspective's constraints until you deliberately switch again. This explicitness is what prevents blended thinking from creeping back in.
The system's assumptions break down in two predictable ways. First, if the task is genuinely trivial (a one-line config change, a typo fix), the overhead of three perspectives exceeds the value. Use judgment. Second, if the developer using the system does not trust the QA perspective's findings and overrides them without returning to the engineer phase, the entire verification layer collapses into theater. The QA gate must have real consequences to produce real value.
Step-by-Step
Step 1: Define the task and gather context
Before invoking any perspective, write down the task in plain language. Include the user story or bug report, any constraints (timeline, backward compatibility, performance targets), and the definition of done. Gather relevant files, documentation, and prior decisions. This context document becomes the shared input that all three perspectives will reference.
Keep it to one screen of text. If you cannot describe the task concisely, you likely need to decompose it into smaller tasks first. The output of this step is a task brief that any of the three perspectives can read cold and understand immediately.
Tip: Store the task brief in a markdown file at the root of your working directory. When you switch perspectives, you can point the agent back to this file to reset context cleanly rather than relying on conversation history.
Step 2: Invoke the CEO perspective for scoping
Switch your AI agent into the CEO role using the appropriate gstack slash command. Present the task brief and ask the CEO perspective to evaluate: Is this task worth doing now? What is the minimum viable implementation? What are we explicitly not building?
What are the risks of this approach versus alternatives? The CEO perspective should produce a scoped specification that includes acceptance criteria, explicit exclusions (what is out of scope), and any trade-offs being made. If the CEO perspective identifies that the task should be deferred, split, or reconsidered, that decision happens here, before any code is written. The output is a specification document, typically 5-15 bullet points, that the engineer perspective will treat as its contract.
Tip: Ask the CEO perspective to list three things that are explicitly out of scope. This forces boundary clarity and prevents the engineer perspective from wandering into adjacent improvements.
Step 3: Review the specification for completeness
Before handing off to the engineer, read the CEO's specification yourself. Check that every acceptance criterion is testable (not vague like "should be fast" but specific like "response time under 200ms for the 95th percentile"). Check that the scope boundaries are clear enough that you could explain them to a colleague. If anything is ambiguous, cycle back within the CEO perspective to clarify.
Do not proceed to implementation with unresolved ambiguity, because the engineer perspective will resolve it implicitly, and implicit resolutions are where scope creep originates. The output is an approved specification that you are confident about.
Tip: A useful completeness test: for each acceptance criterion, can you describe the exact test (manual or automated) that would verify it? If you cannot, the criterion is too vague.
Step 4: Switch to the engineer perspective for implementation
Invoke the engineer role via gstack slash command. Provide the approved specification and ask the engineer to propose an implementation approach before writing code. The engineer should identify which files will be modified, what the key architectural decisions are, and where the riskiest parts of the implementation lie. Once you approve the approach, the engineer writes the code.
During implementation, the engineer may discover that the specification is incomplete or that a better approach requires changing scope. When this happens, the engineer must flag the issue explicitly rather than making the trade-off silently. You then decide whether to return to the CEO perspective for a scope adjustment or to proceed within the current constraints. The output is working code plus any notes about specification gaps or trade-off requests.
Tip: If the engineer perspective suggests expanding scope, write down the exact expansion in the task brief before deciding. Seeing the scope change in writing next to the original specification makes it much easier to evaluate whether the expansion is genuinely necessary or just attractive.
Step 5: Capture implementation decisions and rationale
Before switching to QA, document what the engineer perspective built and why. This includes any deviations from the specification (even minor ones), architectural choices that future developers should understand, and any known limitations of the current implementation. This documentation serves two purposes: it gives the QA perspective specific things to verify, and it creates a decision log for the team. Write this as inline code comments for tactical decisions and as a separate summary for strategic ones.
The output is an annotated implementation with a clear record of what was built and what assumptions were made.
Tip: Pay special attention to documenting what the engineer chose NOT to do and why. These "negative decisions" are the most commonly lost knowledge in development workflows.
Step 6: Switch to the QA perspective for verification
Invoke the QA role via gstack slash command. Provide the QA perspective with three inputs: the original CEO specification, the engineer's implementation notes, and access to the code itself. The QA perspective should systematically verify each acceptance criterion from the specification. Beyond functional correctness, QA should examine edge cases (empty inputs, maximum values, concurrent access), error handling paths (what happens when dependencies fail), security considerations (input validation, authorization checks), and performance characteristics.
The QA perspective produces a verification report: a list of items checked, their status (pass, fail, concern), and specific findings. Each finding should reference the relevant code location and the acceptance criterion it relates to.
Tip: Ask the QA perspective to generate specific test cases, not just opinions. A finding like "the error handling might be weak" is not actionable. A finding like "calling this endpoint with an empty array returns a 500 instead of a 400 because line 47 does not check for empty input" is actionable.
Step 7: Triage QA findings and iterate
Review the QA report and classify each finding as: fix now (blocks merge), fix later (create a ticket), or accept (known limitation, documented). For fix-now items, return to the engineer perspective with the specific finding and ask for a targeted fix. Do not rewrite the entire implementation. Once the fix is applied, return to QA for re-verification of the specific finding.
This cycle may repeat 2-4 times for a substantial feature. The discipline is to keep each cycle tight and focused: one finding, one fix, one re-verification. The output is a clean QA report where all fix-now items are resolved.
Tip: Resist the urge to batch all QA findings into a single engineer pass. Fixing multiple issues at once often introduces new issues. Sequential fix-verify cycles are slower per finding but faster overall.
Step 8: Produce the final session summary
After all three perspectives have completed their work and the QA gate is passed, produce a session summary. This document includes: the original task brief, the CEO specification (including scope exclusions), the engineer's key decisions and rationale, the QA verification report, and any tickets created for deferred work. Store this summary alongside the code change (in a PR description, a commit message body, or a linked document). Over time, these summaries create a searchable decision log that answers "why did we build it this way" months later.
The output is a complete, self-contained record of the development session.
Tip: Template this summary format once and reuse it. Consistency across sessions makes the decision log searchable and comparable.
Examples
Example: Solo developer adding payment webhook handling to a SaaS app
A solo developer building a B2B SaaS product needs to add Stripe webhook handling to process subscription changes. They are working alone, using Claude Code with gstack installed. The feature involves receiving webhooks, validating signatures, updating subscription state in the database, and sending notification emails. Timeline: needs to ship by end of day.
deleted events. Update subscriptions table. Send email to account owner on downgrade or cancellation. " They invoke the CEO perspective and present the brief.
The CEO perspective identifies that handling all webhook event types is unnecessary for today. deleted (cancellation) since that is the highest-impact event. It explicitly excludes: upgrade handling, retry logic for failed emails, and webhook event logging. The specification has 6 bullet points with testable acceptance criteria.
The developer approves and switches to the engineer perspective. The engineer proposes a single endpoint, signature validation using Stripe's library, a database update to mark the subscription as cancelled, and an async email send. It flags that retry logic for failed emails was excluded but notes the email send should at minimum log failures. The developer approves.
Code is produced: about 80 lines across two files. The developer then switches to the QA perspective, providing the CEO specification and the code. QA identifies three findings: (1) the signature validation does not handle the case where the webhook secret environment variable is missing, returning a 500 instead of a clear startup error; (2) there is no test for the database update; (3) the email send failure logging does not include the subscription ID, making debugging impossible. Finding 1 is classified as fix-now, findings 2 and 3 as fix-now given they are quick.
The developer returns to engineer for targeted fixes (15 minutes), re-verifies with QA, and ships. Total time: 2 hours. Without the CEO perspective, they estimate they would have spent 4-5 hours trying to handle all event types.
Example: Small team refactoring authentication middleware in a Node.js API
A team of three developers needs to refactor their authentication middleware to support both JWT tokens and API keys. The current middleware only handles JWTs. Several enterprise customers have requested API key support. The team uses gstack with Claude Code for pair programming. The refactor touches a critical security path and affects every authenticated endpoint in the API (roughly 40 routes).
The tech lead writes the task brief and runs the CEO perspective during a team standup. The CEO perspective identifies two phases: first, refactor the middleware to accept both auth types without changing any route behavior; second (deferred), add API key management UI. For phase one, the specification lists 8 acceptance criteria including backward compatibility (all existing JWT flows unchanged), API key validation logic, rate limiting per API key, and audit logging of API key usage. Out of scope: key rotation, key scoping to specific endpoints, and the management UI.
The team agrees on the specification. One developer invokes the engineer perspective and proposes an auth strategy pattern: the middleware tries JWT validation first, falls back to API key lookup, and normalizes both into a standard user context object. Architecture decision: API keys are stored hashed in a dedicated table, not in the users table. The engineer produces the middleware refactor (about 200 lines), a database migration, and updates to the test suite.
The second developer invokes the QA perspective the next morning. QA compares the code against all 8 acceptance criteria and finds: (1) the fallback order means a request with both a JWT header and an API key header uses the JWT silently, which is ambiguous and could mask bugs; (2) the rate limiter is per-key but does not account for the same user having multiple keys; (3) two of the original JWT integration tests were accidentally deleted during the refactor. All three are classified as fix-now. The engineer perspective addresses each finding: adds explicit rejection of requests with both auth types, adjusts rate limiting to aggregate by user ID across keys, and restores the deleted tests.
QA re-verifies. The session summary becomes the PR description, and the team merges with confidence.
Example: Startup evaluating whether to build a notification system or use a third-party service
A B2C mobile app startup with 50,000 users is deciding whether to build in-house push notification infrastructure or integrate a third-party service like OneSignal or Firebase Cloud Messaging. The CTO wants to use gstack's multi-agent perspectives to make and execute the decision. Budget is tight, and the team has two developers.
The CTO writes a task brief framing the decision: "We need reliable push notifications for 50K users with expected growth to 200K in 6 months. Options: build custom with APNs/FCM directly, or integrate OneSignal/FCM managed service. " The CEO perspective evaluates both options against the constraints. It determines that building custom notification infrastructure is a 3-4 week project for one developer when accounting for device token management, delivery tracking, retry logic, and platform differences between iOS and Android.
This exceeds the one-week constraint. The CEO scopes the work as: integrate Firebase Cloud Messaging via their SDK, support topic-based notifications only (no per-user targeting in v1), and add a simple admin endpoint to trigger notifications. Explicitly excluded: notification preferences UI, rich media notifications, analytics dashboard, and A/B testing of notification content. The engineer perspective takes this 7-point specification and produces an integration plan: Firebase SDK initialization, a topics subscription hook in the onboarding flow, a protected admin API endpoint that sends to a topic, and a simple database table logging sent notifications.
Implementation takes about 3 hours of code, 1 hour of Firebase console setup. The QA perspective then reviews and catches: (1) the onboarding hook subscribes users to the default topic but there is no mechanism to unsubscribe, which may violate app store requirements; (2) the admin endpoint has no rate limiting, so a bug or malicious actor could spam all 50K users; (3) the notification payload does not include a deep link, so tapping the notification just opens the app's home screen rather than relevant content. Finding 1 is fix-now (add unsubscribe endpoint), finding 2 is fix-now (add rate limit), finding 3 is deferred (CEO confirms deep linking is a v2 feature). Total elapsed time for the entire decision-plus-implementation: one day.
Example: Large team implementing a data export feature with compliance requirements
A B2B SaaS company with 25 engineers needs to add GDPR-compliant data export functionality. Users must be able to request a full export of their data in a portable format. The feature has legal requirements, performance implications (some accounts have gigabytes of data), and a hard deadline of 6 weeks due to a regulatory audit.
The product manager and engineering lead co-author a detailed task brief covering the legal requirements, data scope (which tables contain user data), size constraints, and the deadline. They run the CEO perspective with the full legal team's requirements document attached. The CEO perspective makes several scoping decisions: the export format will be JSON (not CSV, which loses relational structure), exports will be asynchronous (queued and emailed) rather than synchronous (download immediately), and the initial version will cover the 6 core data tables that legal identified as mandatory, deferring 4 optional tables to a follow-up. The CEO also sets a performance constraint: exports must complete within 1 hour for accounts up to 5GB.
The specification has 12 acceptance criteria. The engineer perspective, invoked by the tech lead, proposes a job queue architecture: the user clicks "Export My Data," a job is enqueued, a background worker assembles the JSON from each table, compresses it, uploads to a temporary S3 location, and emails the user a time-limited download link. Key architectural decisions: the worker processes one table at a time to limit memory usage, the S3 link expires after 48 hours, and the job includes a progress indicator. Implementation spans two developers over one week, producing roughly 600 lines of application code plus the worker infrastructure.
The QA perspective is then run by a third developer who was not involved in implementation. QA cross-references each of the 12 acceptance criteria and flags: (1) the S3 link is not encrypted at rest, which may violate the company's own data handling policy; (2) there is no mechanism to cancel an in-progress export, which could waste resources if a user requests and then immediately re-requests; (3) the 1-hour performance target was not tested with a 5GB account, only with a 500MB test account; (4) the email containing the download link does not authenticate the recipient, meaning a forwarded email gives full access. Findings 1 and 4 are fix-now due to compliance requirements. Finding 2 is fix-later (ticket created).
Finding 3 requires the engineer to generate a 5GB test dataset and run a performance test before merge. The cycle adds three days but catches two compliance issues that would have been flagged in the regulatory audit.
Best Practices
Make perspective transitions explicit and visible. When switching from CEO to engineer, say so out loud in the conversation and restate the context from the new perspective's point of view. Silent transitions cause blended thinking, which is the exact failure mode this system is designed to prevent. If you find yourself thinking about business priorities while writing code, you have silently returned to the CEO perspective without acknowledging it.
Keep the CEO perspective's specification short and testable. A specification longer than 15 bullet points usually means the task should be decomposed into multiple tasks, each with their own CEO-engineer-QA cycle. Long specifications also give the engineer too much room for interpretation, which creates drift between what was scoped and what gets built.
Give the QA perspective access to the original specification, not just the code. QA that only examines code for technical bugs misses the most expensive category of defect: correct code that implements the wrong thing. The QA perspective should verify that the implementation matches the specification, not just that the implementation runs without errors.
Use the CEO perspective to say no. The highest-value output of the CEO phase is often a decision to not build something, to defer it, or to dramatically reduce its scope. If your CEO perspective never rejects or reduces scope, you are not using it honestly. You are using it as a rubber stamp before jumping into the engineering work you wanted to do anyway.
Document negative decisions (what you chose not to do) with the same rigor as positive decisions. Six months from now, someone will ask why a particular edge case is not handled. If the CEO perspective explicitly excluded it and the rationale is documented, that question takes 30 seconds to answer. If it is not documented, it takes 30 minutes of archaeology and might result in unnecessary rework.
Scale the formality to the task size. A one-line bug fix does not need a full three-perspective cycle. A new feature that touches three services does. Use your judgment, but bias toward more structure when uncertain. The overhead of a lightweight CEO-engineer-QA cycle on a simple task is 5-10 minutes. The cost of skipping it on a task that turns out to be complex is hours or days of rework.
Rotate which perspective you challenge most aggressively. If you always defer to the CEO and always challenge the QA, your system develops a predictable blind spot: overly ambitious scope with insufficient verification. Periodically push back hard on CEO decisions and give QA findings extra weight.
Common Mistakes
Blending perspectives by asking the AI agent to "build this feature and also check if it's a good idea"
Correction
This is the most common failure and it defeats the entire purpose of multi-agent perspectives. When you ask for scoping and implementation in the same prompt, the agent optimizes for the thing it is best at (writing code) and gives minimal attention to the thing that requires judgment (scoping). You can spot this happening when the agent's response starts with one sentence of analysis followed by three paragraphs of code. Fix it by invoking the CEO perspective first with a prompt that explicitly forbids code output.
Only after the specification is approved do you switch to the engineer perspective.
Treating the QA perspective as optional or advisory rather than as a gate
Correction
This happens when developers are under time pressure and feel confident about their implementation. " The findings never get fixed. The QA perspective only creates value if it can block a merge. If you find yourself routinely overriding QA findings, either your QA prompts are generating low-value noise (fix the prompts) or you are rationalizing away real issues (slow down).
Track the percentage of QA findings you act on. If it drops below 50%, your QA phase is theater.
Using the CEO perspective to gold-plate specifications instead of constraining scope
Correction
Some developers unconsciously use the CEO perspective to justify building more, not less. The specification grows to 25 bullet points with nice-to-have features framed as requirements. This happens because the developer already knows what they want to build and reverse-engineers a specification to justify it. The diagnostic signal is a CEO specification that reads like a feature wishlist rather than a prioritized, constrained scope.
Fix it by requiring the CEO perspective to explicitly rank all items by priority and draw a line: everything below this line is out of scope for this session.
Skipping the context-gathering step and jumping straight into the CEO perspective without a task brief
Correction
Without a written task brief, each perspective constructs its own understanding of the task from conversation history, and those understandings diverge. The CEO scopes one thing, the engineer builds a slightly different thing, and the QA verifies against yet another interpretation. This shows up as QA findings that the engineer dismisses as "not what we were building" and scope disputes that waste time. Always write the task brief first.
It takes 5 minutes and prevents 30 minutes of misalignment.
Running all three perspectives in a single, continuous conversation without resetting context
Correction
Long conversations cause AI agents to lose track of earlier context and to anchor on recent output. By the time you reach QA in a 50-message conversation, the agent may have forgotten specific details of the CEO specification. This produces superficial QA that checks the code against recent memory rather than against the original specification. Fix it by providing the QA perspective with a fresh copy of the CEO specification and the engineer's implementation notes, either by referencing the task brief file or by explicitly restating the specification at the start of the QA phase.
Applying the full three-perspective cycle to every single change, including trivial ones
Correction
A developer who runs CEO-engineer-QA on a typo fix or a dependency version bump will quickly burn out on the process and abandon it entirely, including for the complex tasks where it provides massive value. Use a simple heuristic: if the change touches logic, state, or user-facing behavior, use the full cycle. If it is purely mechanical (formatting, renaming, version bumps), skip it. When in doubt, run a lightweight version where each perspective gets one prompt rather than a full exploration.
Other Skills in This Method
Customizing and Extending gstack with Your Own Skills
How to fork, modify, or author new specialist skills and power tools within the gstack open-source framework to fit your team's specific conventions and tech stack.
Orchestrating gstack's 8 Power Tools in Complex Workflows
How to use gstack's 8 power tools — higher-order commands that combine specialist skills — to manage end-to-end development workflows like feature buildout or codebase migration.
Comparing gstack to Other AI Coding Agent Frameworks
How to evaluate gstack's opinionated multi-agent approach against alternatives like Cursor rules, Aider conventions, or custom system prompts to choose the right AI coding workflow.
Installing and Configuring the gstack Skill Pack
How to install gstack from GitHub, set up slash commands, and configure it for use with Claude Code or other AI coding agents.
Structuring AI Coding Sessions from Decision-Making to Execution
How to follow gstack's opinionated phased workflow — moving from problem framing and architecture decisions through implementation and verification — for disciplined AI-assisted development.
Navigating gstack's 23 Specialist Skills via Slash Commands
How to discover, invoke, and chain gstack's 23 specialist slash commands to handle discrete tasks like planning, scaffolding, refactoring, and debugging.
Frequently Asked Questions
How do I use multi-agent perspectives for a quick bug fix that will only take 10 minutes?
You probably should not use the full three-perspective cycle. The overhead of formal CEO scoping, engineer implementation, and QA verification exceeds the value for trivial changes. Use a heuristic: if the fix touches logic, state management, or security-sensitive code, run at least a lightweight QA pass after the fix. If it is purely cosmetic or mechanical (typo, formatting, dependency bump), just fix it directly. Reserve the full cycle for changes where a mistake would cost you more than the 15-20 minutes the process adds.
Should I use multi-agent perspectives before or after I've written any code?
Always start with the CEO perspective before writing code. The entire point of the CEO phase is to scope the work and make deliberate trade-off decisions before implementation effort is invested. If you write code first, you become anchored to your implementation and the CEO perspective becomes a rationalization exercise rather than a genuine scoping exercise. The one exception is exploratory prototyping: if you genuinely do not know whether something is technically feasible, a quick spike in the engineer perspective can inform the CEO's scoping decisions. But label it as a spike, not as the implementation.
Can I use the same AI conversation for all three perspectives, or do I need separate sessions?
You can use the same conversation, but you must explicitly mark transitions and reset context at each switch. The risk of a single conversation is context drift: by message 40, the agent has partially forgotten the CEO specification and the QA phase becomes shallow. For tasks that fit in under 20 messages total, a single conversation works fine. For larger tasks, consider starting a fresh conversation for the QA phase and providing it with the specification file and the code diff as explicit inputs rather than relying on conversation history.
How do I handle disagreements between the CEO and engineer perspectives?
Disagreements are expected and healthy. The CEO perspective optimizes for business value per unit of effort, while the engineer perspective optimizes for technical correctness and maintainability. When the engineer discovers that the CEO's specification is technically naive or that a much better approach requires modest scope expansion, document the specific disagreement. " Let the CEO perspective make the trade-off explicitly. Do not let the engineer make business trade-offs silently.
Why does my QA perspective keep finding only superficial issues instead of real bugs?
This usually happens because the QA perspective is not given enough context to do deep verification. If you just say "review this code," the agent will produce generic observations about naming conventions and comment quality. Instead, give QA three explicit inputs: the CEO specification (so it can verify the right thing was built), the engineer's implementation notes (so it knows where the risky decisions were), and specific instructions to check edge cases, error handling, and security. Also, ask QA to generate concrete test cases with specific inputs and expected outputs rather than just listing concerns. The quality of QA output is directly proportional to the specificity of the QA prompt.
How long should a complete CEO-engineer-QA cycle take for a medium-sized feature?
For a feature that would normally take one developer 4-8 hours of heads-down coding, expect the full three-perspective cycle to take 5-10 hours total. The CEO phase adds 30-60 minutes upfront but typically saves 1-2 hours of rework by preventing scope drift. The QA phase adds 30-90 minutes but catches issues that would otherwise surface as post-merge bugs (which cost 3-5x more to fix). Net, you spend roughly the same total time but shift effort from reactive bug-fixing to proactive quality assurance. Over multiple sessions, the process gets faster as you develop muscle memory for the transitions.
Can multiple team members each take a different perspective simultaneously?
Yes, and this is one of the most effective configurations for teams. Assign the CEO perspective to the product owner or tech lead, the engineer perspective to the implementing developer, and the QA perspective to a different developer who did not write the code. This natural separation of concerns maps well to existing team roles and prevents the cognitive blending that happens when one person tries to hold all three perspectives. The key coordination mechanism is the shared task brief and specification document, which ensures all three perspectives are working from the same understanding of the problem.