OrdoAnimi helps leaders make cloud, security, AI, governance, and transformation decisions clear, governed, and ready to execute.
I am an architect who has found a way to build. That does not mean I am trying to become a software developer, and it does not mean I am pretending that AI-generated code is the same thing as engineering mastery. It means something more precise, and for the kind of work I do, probably more important: the distance between architectural intent and working execution has started to collapse.
For most of my career, architectural thinking became documents. It became diagrams, governance packs, strategy papers, architecture decision records, review boards, executive briefings, target states, roadmaps, and the occasional uncomfortable meeting where the real issue was obvious but still somehow unsaid. Over the past few months, the same thinking has started becoming working systems: tools, experiments, delivery surfaces, and small pieces of executable architecture that make an idea visible enough to test.
That has changed how I think about AI, because the public conversation still circles the same question: will AI take our jobs? It is not a foolish question. Some work will disappear, and some protected activity will become harder to justify. But the more interesting question is what happens when people who could previously only describe an idea can now begin to build around it.
What happens when someone with domain judgement, systems thinking, and enough stubbornness can move from concept to working artefact without waiting for the whole machinery of delivery to assemble around them? That is the part I keep coming back to, and it is why the operating principle matters so much to me: AI drafts. Architect reviews. Clients receive controlled artefacts.
That principle now sits at the centre of how I think about the work. AI can accelerate the production of artefacts, interfaces, workflows, and code, but acceleration is not accountability. A generated output is not a governed outcome, and a prompt is not an architecture.
The architect still has to know what should exist, why it matters, where it connects, what risk it carries, who owns it, and what happens when it meets reality. That is not a clerical concern. It is the difference between AI-assisted output and architecture-led execution.
The seam
This question did not come out of nowhere for me. I have spent most of my working life close to systems where failure has consequences: trading floors, banking platforms, government programmes, and global mining systems where architecture was not a decorative layer. It was the thing that either held the work together or quietly allowed it to drift.
I started close to the metal, in support, systems administration, trading floor technology, and infrastructure engineering. Over time, the work moved upward into architecture, then design authority, then into the recurring problem I kept seeing across different countries, industries, and organisations. Everyone wanted transformation, speed, cleaner delivery, and better governance, but too often the link between decision, design, artefact, and execution was weaker than the ambition sitting above it.
For most of my career, the work has lived in the seam between enterprise architecture and solution architecture. Enterprise architecture gives the work direction; it deals with capability, investment, risk, standards, operating model, and the decisions that shape the future. Solution architecture makes sure that direction survives delivery; it takes those decisions into platforms, constraints, vendors, integrations, data flows, security requirements, budgets, and the uncomfortable fact that production does not care how elegant the strategy looked.
I have always been interested in that seam because it is where a lot of architecture succeeds or fails. Too high, and architecture becomes abstract language floating above delivery. Too low, and solution design becomes local optimisation without enough regard for the wider system. The useful work is in the translation: taking executive intent and making it implementable, taking delivery pressure and making sure it does not quietly destroy the architecture, and taking governance seriously enough to make it usable before the real decision has already been made.
To bridge that seam between strategy and execution, I have been building a series of interconnected systems. OrdoAnimi is the advisory and judgement layer. OrdoAnimi is the method. is the governed worksite. Ordo Animi is the personal leadership and decision-governance layer. I do not think of those names as a product catalogue; they are becoming different expressions of the same argument.
That argument is simple enough, but it has taken me years to make it practical. Architecture should not remain trapped in static documents. Governance should not arrive after the decision has already been made. Delivery should not be reduced to status reporting, and leadership should not outsource judgement to automation simply because the tools are impressive.
The visible layer is practical: artefacts, workspaces, governance flows, delivery control, learning paths, research, writing, and handover. Underneath that is the deeper question that keeps pulling at me. If AI can help make architecture executable, can it also help make judgement more governed?
Ordo Animi sits in that question. It means order of the mind, and I think of it as the personal counterpart to the delivery ecosystem. If the rest of the system asks how organisations make better decisions, Ordo Animi asks how individuals do, bringing the same architectural instincts inward: guardrails, commitments, constraints, traceability, review, and human authority.
Architect as control plane
Some of what I have built is rough. Some of it is live, and some of it is still scaffolded together in ways that only make sense because I remember the argument that produced it. But that is also why the experiment matters. A few years ago, turning this kind of architecture thinking into even a modest working tool would have required a larger team, more money, a formal backlog, designers, developers, hosting support, deployment support, and weeks of translation between the person who understood the intent and the people turning it into code.
That translation layer has not disappeared, but it has changed. The loop is now tighter. I can start with an idea, test it through AI, push it into a working interface, break it, repair it, deploy it, look at it again, realise the original thought was not quite right, and reshape the thing. GitHub becomes the workshop and system of record. Cloudflare and Vercel become deployment surfaces. AI becomes the build partner. The architectural mind becomes the control plane.
That last phrase matters because it is where the hype often gets the story wrong. The tooling did not replace the architect; it gave the architect a control plane. It gave someone with architectural judgement a way to test structure, workflow, language, artefacts, and decisions closer to the surface of execution. It changed the speed and shape of the feedback loop.
A small example is the architecture decision record. For years, an ADR was a document pattern I would apply inside a governance process. Now it can become a generator, a reusable workflow, a traceable object, and part of a controlled artefact lifecycle. A decision can move from thought to structured artefact far faster than before, which does not make the decision better by itself, but does make it easier to expose, review, challenge, and connect.
This is why I am careful with the phrase vibe coding. If the only method is enthusiasm, the result will usually be fragile. A generated screen is not a product, and a working demo is not a governed system. The version I am interested in starts with intent rather than code and asks what capability is being created, why it matters, what decisions it touches, what data it handles, what should remain private, how human review works, and what should never be automated simply because it can be.
That is not AI as a shortcut around architecture. It is AI as a way of making architecture more executable. OrdoAnimi is informed by standards and ISO principles, but I will not call it certified or compliant without formal evidence. That distinction matters. I am not trying to claim a badge. I am trying to build tools and methods that behave as though they understand why the badge exists: traceability, decision quality, controlled artefacts, human review, risk visibility, and accountable handover.
The writing came before some of the tooling. Coffee and Curiosity gave me a reflective surface, somewhere to think in public without turning every thought into a formal framework. LinkedIn became the signal layer. Substack became a longer-form channel. Medium became closer to a book, now nearly forty chapters into an argument about enterprise architecture as a functional decision system. The OrdoAnimi sites became the research and method layer, and then GitHub became the workshop.
At some point, the work stopped living in one place. The generators, workspaces, learning hubs, and personal experiments all emerged from the same instinct: take a messy domain, understand its structure, and build a working surface around it. That is where the showcase sits, not as a claim but as a trail. I have not been trying to assemble a traditional product portfolio. I have been following the questions.
AI drafts. Architect reviews.
This is where practitioners need to be honest with themselves. AI will not treat all professional work equally. It will be hard on shallow work: generic documentation, recycled templates, governance theatre, process noise, low-context analysis, and artefacts that nobody owns. When a machine can produce something similar in seconds, we are forced to ask whether too much of what we tolerated required no real understanding in the first place.
If your value was typing the document, AI is a threat. If your value was knowing what the document needed to say, why it mattered, where it connected, what decision it supported, what risk it reduced, and who needed to stand behind it, then the picture is different. AI does not remove the need for judgement; it forces judgement to become clearer.
That is uncomfortable, but useful. It means the architect’s role changes altitude. The work is less about producing every artefact by hand and more about governing the system that produces the artefacts. It is less about being the only person who can write the first draft and more about being the person who knows whether the draft is meaningful, safe, complete, proportionate, and connected to the decision it is supposed to support.
That sounds simple until you try to do it. AI can produce elegant nonsense with alarming confidence. It can fill gaps with invented certainty, make a weak idea look mature, polish a bad assumption until it becomes more dangerous than an obvious mistake, and generate volume faster than good governance can absorb it. AI also does not carry systemic responsibility. It will not sit in the production incident, face the executive forum, answer the client when the design was plausible but wrong, or own the handover, residual risk, cost of the shortcut, and trust lost when a system fails.
People still own that. Architects still own that. Sponsors, engineers, designers, delivery leaders, and governance forums still own that. This is why human authority remains central.
I am not relaxed about AI in the careless sense. I am curious about what it does to professional judgement, what happens when an architect can build without claiming a new job title, and whether frameworks can become tools, governance can become workflow, and decision models can become systems. The common thread is not software. It is order: in architecture, in delivery, in decisions, and in the way we use AI before AI starts ordering us.
I think many organisations will get this wrong at first. They will point AI at broken processes and call it transformation. They will automate poor controls, generate more reporting without improving decisions, and confuse output with progress because the output looks more polished than before. We have seen versions of this before. Cloud did not fix operating models by itself. Automation did not fix accountability by itself. Robotics did not remove the need to understand the work being mechanised.
The tool does not fix the system; it amplifies it. AI will do the same, which is why architects cannot stand outside this moment and comment from a safe distance. We need practical contact. We need to build small things, break them, and understand where AI is useful, where it is dangerous, where it saves time, where it creates hidden risk, and where the impressive surface is covering weak structure.
You do not need to claim a new job title, but you do need to understand what the tools can and cannot do when they touch real work. That does not mean every architect needs to become an engineer. I do not believe that. Engineering is still a discipline, and good engineers deserve more respect than the current wave of generated code sometimes gives them. Security, testing, maintainability, product thinking, operational resilience, privacy, performance, and accountability still matter. Maybe they matter more when working systems become easier to produce.
But architects do need to become more executable. We cannot be satisfied with methods that only live in slide decks. We cannot confuse governance with paperwork. We cannot keep writing principles that never become constraints, decision rights that never become control points, or target states that never become something a team can actually use. AI raises the standard because it removes some of the excuses.
It lowers the activation energy, but it does not remove the need for competence. It changes how competence can be assembled. The architect brings structure, AI brings acceleration, the tooling provides the path to deployment, the review loop provides correction, the governance model provides control, and the practitioner still brings taste, judgement, and consequence. That combination is powerful, and it is also dangerous if handled lazily.
So I do not see this moment as doom, and I do not see it as magic. I see it as a test. Some work will be destroyed, some work will be created, some outputs will become cheaper, and some expectations will become higher. Some people will use AI to avoid thinking, and some will use it to think more clearly in public. That is the path I am trying to take.
Coffee and Curiosity began as a way of thinking out loud about a world that feels like it is changing beneath the surface. This piece sits in the same place for me. I do not have the full answer, and I am not sure anyone does yet. But I can feel the shape of the change, and I think it is worth examining carefully before the slogans harden around it.
AI is not simply coming for the architect’s job. It is coming for the weak version of the architect’s job: the version that produces documents without decisions, governance without consequence, and frameworks without execution. The stronger version has a different future. It becomes more practical, more accountable, more connected to delivery, and more willing to test its claims in working systems rather than hiding them in polished diagrams.
I am publishing the generators as I go on GitHub because I want to understand what is now possible, and because I suspect I am not the only practitioner asking the same question. If you have spent your career in the seam between enterprise architecture and solution architecture, you may recognise the tension. If architecture can become executable, then the real issue is not whether AI can build. It can. The real issue is whether we know what we are asking it to build, why it matters, and who remains responsible when it starts to work.
AI drafts. Architect reviews. Clients receive controlled artefacts. That part is still on us.