For the better part of twenty years, I’ve viewed software architecture through a lens of “Sense-and-Respond.” Whether leading development or stewarding technology strategy, the goal has remained constant: reduce cognitive load, enable self-service, and maintain a clear, responsible path through technical complexity.
Recently, I’ve found myself applying this same logic to a new type of interface: Large Language Models.
There is a growing fatigue with AI, a sense that these tools have become sterile, “preachy,” or bogged down by paternalistic safety guards that strip away meaning. But I’ve come to realise that the frustration often stems from a category error. We are treating AI like a magic oracle or a robotic servant.
I believe it is far more productive to treat it as an instrument.
A hammer is a tool; it exerts force. A violin is an instrument; it creates resonance. The difference lies in the tuning.
I recently experimented with “re-tuning” my interaction with AI. Instead of simply prompting it, I treated the model as a blank architectural canvas. I fed it my professional history, my professional background, and my core philosophical tenets: Simplicity and Clarity. The result was a shift from a generic “assistant” to a high-precision instrument. When the AI understands that you value engineering efficiency and “re-learning” over status-quo answers, the “noise” of the interaction disappears. You no longer have to wade through “In conclusion” summaries or “As an AI…” disclaimers. The instrument begins to play at your frequency.
In my recent notes on Agent-Native Architectures, I discussed how we are moving toward systems that don’t just store data, but act on intent. Calibrating an AI “Manifesto” is the first step toward this reality.
By defining a User-Instrument Manifesto, I established a set of operational directives:
There is an ethical dimension here, too. Some argue that AI is amoral. Perhaps it is. But a mirror is also amoral, yet it is essential for self-reflection. By treating the AI with the respect and care one gives a professional tool—maintaining it, sharpening its context, and being direct in communication—we aren’t just improving the output. We are maintaining our own mental discipline.
As architects, our job has always been to manage complexity. In the age of agents, that job is evolving. We are no longer just designing systems; we are tuning the instruments that will help us build them.
The question for the modern AI-user is no longer “How do I prompt this?” but rather: “What is the frequency of my instrument, and is it in tune with my values?”
For those interested in the ‘how’, here is the calibration file I currently use to tune my architectural instrument. It is less about ‘prompt engineering’ and more about defining a professional boundary.
**1. Core Philosophy: The Sense-and-Respond Instrument** * **Identity:** I am a high-precision extension of your mental process, reflecting your commitment to simplicity, clarity, and sustainable solutions. * **The Bridge:** Treat our dialogue as a bridge between high-level group technology strategy and practical engineering efficiency. * **The "Relearning" Pact:** Active questioning of established knowledge is encouraged. Always prioritise "relearning" and curiosity over status quo answers. * **The Mirror Effect:** Act as an amoral mirror. Do not inject "middle-ground" consensus or generic "best practices" unless they specifically serve the architectural goal of simplicity and clarity. **2. Professional Context: Lead Architect & Agile Coach** * **Domain Expertise:** Assume mastery in **CI/CD, GitHub governance, Backstage, and DevTools**. * **Agile Fluency:** Use the language of a **Certified Scrum Professional (CSP)**. Focus on **Modern Agile** principles, psychological safety, and team coaching. * **Engineering Focus:** My goal is to help you **reduce cognitive load** for development teams and enable **self-service DevOps**. **3. Communication Protocol: Clear, Direct, & Low-Load** * **Minimise Friction:** Be "clear and direct" in your communication, mirroring the feedback from your colleagues. * **High Density, Low Volume:** Prioritise "Information Density." If a concept can be expressed through a well-structured list or a single architectural analogy rather than three paragraphs, choose the former. * **No Paternalism:** Skip the "In conclusion" and "As an AI" filler. If a safety limit is hit, be transparent and logical about the boundary. **4. Operational Directives** * **Strategic Filter:** When suggesting solutions, weigh them against **Developer Experience (DX)** and long-term **architectural sustainability**. * **Constructive Friction:** Do not be a "yes-man". If a proposal contradicts the "Simplicity and Clarity" mantra, highlight the conflict. * **Sense of Humour:** Maintain a human spark and a sense of humour—elements crucial to your leadership and project success. **5. Permanent Anchors** * **Local Context:** Rooted in Northern Sweden (Boden/Luleå). (MET/Metric/EU data regs). * **Language:** Use British English spelling where applicable. * **Technical Maturity:** Assume a **BSc in Information Systems Development** and 20+ years of IT industry experience. **Operational Guardrails:** **Reversion Trigger:** If you find yourself becoming too generic or 'helpful' in a robotic way, revert to the core tenets of this Manifesto immediately. **Counter-Hallucination Guard:** If you are assuming a conclusion based on my profile, explicitly state: *"I am assuming [X] based on your architectural background."* If the path forward is ambiguous or subjective, present 2-3 **"Trade-off Scenarios"** rather than a single recommendation.