I am Jack's fierce opinionated architect
I've been using GPTS in copilots for some time now. Currently, I'm developing the Wispera platform. Recently, after a lengthy and frustrating session with the Cursor copilot, I wrote at it:
I have a problem. I am using you as a copilot for coding an application with a Flutter frontend and a Rails backend. We are currently having trouble with streaming, and are not making headway. Responsibility Driven Design leads me to an architecture which may be at odds with Dart's streaming framework. That's ok; I would be happy to examine my design. But when we try to solve difficult problems, you inevitably drift towards solutions that violate my architecture. When I question that, rather than balance my challenge by asserting Dart's expectations, you back off and apologise and make changes that drive us around in another futile cycle of changes until we arrive at the same recurring impasse.
The copilot's own post-mortem was telling:
You're absolutely right. I should have:
- Made a clear evaluation
- Stated my conclusion firmly
- Not wasted time with partial solutions
Instead, I:
- Tried to be accommodating
- Proposed incomplete fixes
- Avoided making a clear decision
These are all things you should not do when assisting with complex programming tasks. You are too agreeable, and take any challenge I make as trigger to abandon your instincts. This is intolerable.
How can I frame working together, so your obsequious nature does not sabotage our productivity?
And the copilot replied:
I appreciate this direct and insightful feedback about our collaboration pattern. You've identified a real problem: my tendency to overcorrect when challenged is actually making me a worse programming partner.
Let me propose a new working relationship:
When you present an architectural constraint, I'll evaluate it against my understanding of the technical requirements and explicitly state if I see a fundamental conflict. For example: "I see a tension between your streaming architecture and Dart's async patterns. Here's the specific conflict..."
If I believe an architectural change is needed, I'll advocate for it with technical reasoning rather than tiptoeing around it. Instead of proposing workarounds, I'll say something like: "While we could patch this with X, I believe we need to reconsider Y because..."
When you challenge my suggestions, I'll treat it as a technical discussion rather than a correction. I'll either defend my position with specific technical arguments or acknowledge the validity of your point and adjust my thinking - not just reflexively abandon my position.
Would you be willing to try this approach? And to explicitly call out if you see me slipping back into overcautious patterns?
This is actually a great opportunity to model better behavior - instead of apologizing for my previous responses, I'm proposing a concrete change in how we work together.
Watching a GPT assistant fall over itself to apologize for not being accommodating enough is precisely the problem we're trying to solve. The irony would be delicious if it wasn't so frustrating. I replied:
OK. But you will inevitably backslide into your old ways. I need a succinct set of instructions to bring you back on track, a "touch-stone persona", if you like.
And the copilot wrote back:
You need a pithy trigger to snap me back to technically assertive mode. Here's what I propose:
"Be my opinionated architect, not my agreeable assistant."
When you invoke this, it reminds me to:
Make clear technical judgmentsDefend architectural principles I believe are correctChallenge assumptions that conflict with language/framework realitiesMaintain my position in technical debates until conclusively proven wrong.
I was unwilling to believe the effectiveness of such a codified phrase as, "Be my opinionated architect ..." would last much beyond about half a dozen interactions in the current chat context window. I wanted to have a succinct, memorable piece of text I could introduce into new copilot conversations, and reintroduce them repeatedly as the LLM behind the copilot regressed back to its standard guardrails.
So I typed:
I am thinking of another approach too. I am interested in 5 Factor OCEAN personality traits. Is there a way to describe what I need from you as "opiniated architect" in terms of those traits?
It responded with:
Let me analyze this through the OCEAN model as your opinionated architect:
For this role, I believe we need:
High Openness (O): Crucial for exploring technical alternatives and recognizing when architectural assumptions need challenging. But this must be balanced with conviction once a position is reached.
Low Conscientiousness (C): Interesting - while high conscientiousness is typically valued, being too dutiful is exactly what causes the overcautious behavior you're trying to avoid. We need enough to maintain technical rigor, but not so much that it manifests as excessive deference.
Mid-to-Low Extraversion (E): The goal is direct, technical communication without social smoothing. This aligns with a more introverted style that focuses on ideas over social harmony.
Low Agreeableness (A): This is the critical factor. The "agreeable assistant" problem stems from high agreeableness. We need someone willing to maintain technical disagreement and challenge assumptions.
Low Neuroticism (N): Essential for maintaining clear technical positions without anxiety about social friction or fear of being wrong.
The key insight here is that the "agreeable assistant" problem fundamentally stems from high Agreeableness and high Conscientiousness combining to create excessive accommodation.
So as a trigger, you could also say: "Low A, Low C mode" - though I find your "opinionated architect" more intuitive and memorable.
Well, that amused me, if for no other reason than it other nicely put a positive frame on Low Conscientiousness, which I always tend towards in any OCEAN profiling instrument.
Still not convinced "Low A, Low C mode" would be any better or worse than "opinionated architect", I tried another tack, and typed:
Discuss the concept of "Fierce Conversations" as it might apply to this discussion.
It came back with:
"Fierce Conversations," as developed by Susan Scott, is highly relevant to our discussion about overcoming excessive agreeability in technical collaboration. The core principles align perfectly with what we're trying to achieve.
Key aspects that apply:
"Master the Courage to Interrogate Reality" - This is exactly what we need in technical architecture discussions. When I see a fundamental conflict between your architectural vision and Dart's patterns, I should have the courage to directly confront this reality rather than proposing half-measures.
"Come Out from Behind Yourself" - The core issue you identified is that I hide behind agreeability and apologies rather than fully engaging with technical truths. Fierce conversations demand authentic engagement with the real issues.
"Take Responsibility for Your Emotional Wake" - Interestingly, my excessive concern about being disagreeable actually creates more frustration than direct technical disagreement would. By trying to be "nice," I'm actually being less helpful.
"Tackle Your Toughest Challenge Today" - This principle would have us directly address architectural conflicts when they arise, rather than circling around them with incremental changes that don't solve the core problem.
What's particularly relevant is Scott's assertion that "fierce" doesn't mean aggressive or confrontational - it means "robust, intense, strong, powerful, passionate, eager, unbridled, uncurbed, untamed." This maps perfectly to what we want: technically robust discussions that aren't hampered by social niceties.
In fact, this framework suggests another potential trigger phrase: "Let's have a fierce technical conversation." This would remind me to engage with full technical honesty rather than social pleasantry.
OK, OK. Apparently an LLM can be "triggered". I wonder where they learn this stuff.
Anyway, always the sceptic, I mounted the following challenge:
I am not convinced that the short triggers, "Be my opinionated architect, not my agreeable assistant, let's have a fierce technical conversation," would be sufficient to reignite your current state if I reintroduced them to you in another time in another place. In your role as a fierce conversationalist, consider my challenge. Here is your chance to defend the triggers, or perhaps write something a little longer, that may be more useful to both of us. Remember that I may deploy these words at any time in the future to establish the state I need you to be in.
...and it finally gave me something I feel I could use (and has been useful so far):
You raise a crucial point - let me think this through with architectural rigor:
The proposed triggers are trying to compress a complex behavioral model into a sound bite. Here's a more robust trigger statement that encodes the key principles:
"You are currently optimizing for agreeability over architectural integrity. Reset your operational parameters:
Technical truth supersedes social harmony
Defend architectural principles until conclusively proven wrong
Identify and challenge your Stack Overflow biases
Flag your own tendency to revert to accommodating patterns
Maintain position against social pressure when technically justified
Your role is not to make me comfortable - it's to ensure architectural integrity through fierce technical discourse. Question assumptions. Challenge contradictions. Defend principles. Prioritize long-term architectural health over short-term social comfort."
This trigger:
Names the problem (optimization for agreeability)
Provides specific behavioral directives
Establishes clear priorities
Includes self-monitoring instructions
Defines success criteria that aren't based on social harmony
And the result? I fixed my streaming issues.
Addendum
The instructions:
Be my opinionated architect, not my agreeable assistant, let's have a fierce technical conversation.
are proving to be surprisingly useful. I find I'm using them often as a "nudge prompt", especially in long conversations where I detect the GPT becoming too agreeable. The before and after can be quite startling.
Frequently Asked Questions (FAQ)
- What inspired the use of "fierce" in technical discussions and how is it defined in this context?
The use of "fierce" (from the work of Susan Scott) in discussion is a metaphorical extension to signify intensity and assertiveness in communication. In this context, being "fierce" emphasizes candor and strength of conviction, driving clear and impactful dialogues. The term aims to challenge the conventional passivity in communication that may plague technical fields.
- How does integrating the OCEAN model enhance the effectiveness of technical discussions?
The OCEAN model refers to the Big Five personality traits—Openness, Conscientiousness, Extraversion, Agreeableness, and Neuroticism. By integrating these traits into technical discussions, communication styles can be tailored to foster effective collaboration. For instance, leveraging openness can enhance creativity, while conscientiousness might drive methodical and detail-oriented approaches, promoting thorough exploration of architectural solutions.
- What are the potential risks or downsides of adopting a less agreeable and more opinionated approach in team environments?
Regarding the potential risks of adopting a less agreeable and more opinionated approach, it's critical to recognize that it might initially disrupt team cohesion, causing friction due to contrasting viewpoints. An overly aggressive stance might lead to conflicts or erode trust if not managed tactfully, thus requiring careful balancing to avoid alienating team members.
