The work I do is changing. The shape of the change is clear enough that I no longer think of it as coming, because it is here. Every piece of knowledge work I produce, whether code, an architecture decision record, a paragraph of an article, or a programme note, gets done with an AI model in the loop. The model runs alongside the work continuously now. It reads what I have done, drafts, edits, reviews, and hands back. My job is direction, judgment, shipping, and knowing when the draft is wrong.
Most people who work with their heads will get here in the next few years. Some are already there. The hardware firms, the consultancies, the product teams, the clinicians, the architects, the teachers, and the parents drafting letters to their kids’ schools: all of them will have the same thing in the loop before long.
This is for the engineer who already feels the shift, and equally for the non-engineer who senses it but is not sure what to do with it.
Most people who have used a model so far have used it as a slightly better search engine, or as a junior intern they don’t quite trust. Both framings are wrong, and the failure compounds: neither is what the model is, and neither uses it well.
Some are already past arrival. The Foreign Minister of Singapore wrote on Facebook in April 2026 about the second brain he had assembled at home, an open-source AI assistant built around a model like Claude, running on a Raspberry Pi (a hobbyist computer the size of a deck of cards), fed by a knowledge graph (a structured map of his thinking) compounded from his own speeches and articles, drafting his work and answering his questions on demand. The post named the irreversibility plainly. “I don’t dare switch it off.” It named the asymmetry too. The diplomat who learns to work with AI will have a meaningful edge.
The same month, the CEO of Shopify circulated a memo making AI fluency an essential requirement for every team member, not just developers and analysts, integrated into performance reviews. The two voices sit at opposite ends of the org chart and they are saying the same thing. The work is changing, the change is here, and the people who learn to work with the change have an edge over those who do not.
The question I have stopped asking is whether it comes. The question I spend my time on is what you need to put around an AI agent (a model set up to work in steps, reading and drafting and revising rather than answering single questions) so the work it produces is any good.
The answer comes down to two things. The agent has to know how you work. And it has to be able to read your knowledge in a shape it can use. Without the first, its output is generic. Without the second, it hallucinates: it makes things up that sound right. The combination, plus a little discipline, produces work better than what I had before the agent. The cost of producing a draft has collapsed. The cost of knowing whether the draft is right has not. Judgment is the thing that compresses last, or fails first.
What follows is what I have learned, for anyone whose work runs on judgment rather than headcount, and whose work would compound if it could be handed cleanly to an agent that knew them.
Andrej Karpathy describes it as a loop. (Karpathy is an AI researcher who has done more than most to translate how these systems actually work into plain English; if you have ever read one piece on what is happening inside a model, it was probably his.) The loop is simple. You write what you want. The model reads what you wrote, plus everything you have already given it that is relevant, plus what it knows from its training. It drafts. You read what it produced. You correct, accept, or redirect. The correction goes back into what it has on hand. The next draft is shaped by the previous one. Repeat until what comes back is what you needed.
Where this started
It started as a Christmas project. I have two children, twins, both of whom learn differently from each other and differently from the apps they have been handed at school. I sat down at Christmas 2025 to build something shaped to who they actually are. I had no plan to ship a product. I wanted them to have something that fit.
What surprised me was the way I had built it. I had been running my own knowledge vault for years as a personal practice: a repository of everything I know and think, organised with the same disciplines I use at work on architecture artefacts. A single source of truth for every fact, an archive-not-delete rule for anything superseded, and an append-only daily log. Frontmatter, structured labels, on every memory file, a dashboard for volatile state, and a strict separation between decisions taken and the operational reality that follows from them. When I sat down to build the Christmas app with an agent as a collaborator, the vault became the thing that made the agent useful. It read the vault, understood what I was trying to do, and produced code that fit my context. It stopped feeling like a tool and started feeling like a colleague who had read my notes.
I went down the rabbit hole from there. It turned out the disciplines I had been running on myself were not personal quirks. They were the same disciplines that let a team hand knowledge to an agent and get back work shaped to the team’s context, rather than generic output that looks plausible and is slightly wrong.
The shape I landed on
I gave the shape a name. Koine-OS. Koine (κοινή) is the shared Greek that spread across the Hellenistic world after Alexander. It is the language the Gospels were written in. It is also the reason Greek survived four centuries of Ottoman occupation when the empires tried to erase it: the liturgy kept the tongue alive when the rulers tried to take it away. A team’s koine is the shared language its members speak when they work together. Named artefacts outlive their authors, sometimes by centuries. I liked the name for reasons I can defend and for reasons I cannot, and I kept it.
The shape itself is a kit of instructions for an AI assistant (prompt pack), plus the rules that govern when to use each one, and a method. It is not a tool you install. The core is small. The operating rhythm of plan, create, review, adjust, converge, the team-shaped version of the loop above, runs underneath everything. Above it sit eleven knowledge disciplines that keep content findable over years and across authors. Two tiers of reviewers govern the pack itself and the team’s daily work. Adapters connect it to the AI assistants I actually use. At home I run it on Claude Code. At work I run it on Copilot.
The method is five stages for standing up a new team’s pack from scratch. It begins with an archaeology of what the team actually produces, in the formats it actually uses, at the cadences it actually runs. It ends with a feedback loop from running instances back into the core, so the core improves as it is used.
The distinction between the pack (general) and an instance (one team’s configured copy of the pack) matters. An instance has one team’s artefact types, skill prompts (each skill is one job the agent can do, like drafting a particular artefact), reviewer criteria, and forcing functions wired into that team’s existing rituals. The pack produces the instance. The instance produces the team’s work.
The packs so far
The pack has now produced four instances, and a fifth is starting. Each one has taught me something I could not have learned from designing the pack on paper.
The first is my own personal vault. It is the n=1 reference instance, the only one of its kind, the one I had been running on myself for years, and it is older than Koine-OS itself. The pack formalised what I had already been running. Declaring the vault as the reference instance was a retrofit that paid for itself in the first week, because when I audited the vault against the pack’s own disciplines it surfaced gaps I had not seen. The most useful of those was that the vault has agents as consumers as well as humans, and an audit that only checked human usability missed a whole class of failure. I fixed the gap and lifted the two-pass audit back into the pack.
The second is a pack for a data and AI architecture team. Fifteen skill pairs, each with one prompt that drafts an artefact and another that reviews it before it ships, covering the work the team actually does: patterns, architecture decision records, technology lifecycle entries, engagement notes, research scans, capability model updates, current and target state, and principle trade-offs. The quality bar lives inside the reviewer prompts. At least two genuine options on every architecture decision record. Technology alignment cross-checked against the lifecycle tracker. Principle conflicts surfaced for human adjudication rather than resolved quietly by the agent.
The third is a pack for a product management team in a data platform context. Fourteen skill pairs across three waves. The minimum viable set covers upward updates to leadership, feature briefs, dependency declarations, decision records, and post-incident synthesis. Two later waves add the cross-team work and the planning work the team does at lower cadence. The second build surfaced four principles that had not existed in the first pack, because the audience worked in a different organisational shape. One was that every cross-team artefact has to be valuable to the author alone, whether or not the counterparty engages. Otherwise the pack stops being useful during the asymmetric adoption phase, which for most packs is most of their life.
The fourth is a life pack. Not a work pack. Seventy six skills across six domains of personal life: finances, family, ventures, health, learning, and hobbies. Each domain has a thin state file that the skills read from and write to, so the running picture of what is true in a domain survives across sessions and across agents. I did not expect a life pack to be coherent. It turns out the disciplines travel. Archive, never delete, applies to old investment notes the same way it applies to old architecture decision records. Intent-readiness separation is the same shape whether the decision is about next year’s investment allocation or an enterprise technology choice. The decision is immutable and recorded, the operational state is mutable and tracked, and the projection catches the drift between them when it happens. The life pack is what convinced me the factory claim is not work-specific.
The fifth is starting. My brother in law is a practising architect, the kind who draws buildings. He runs a small studio, and his work sits across drawing sets, programme notes, site records, consultant correspondence, and planning conversations with clients. None of it is code. All of it is knowledge work with the usual shape: artefacts that have to be findable, decisions that have to be recorded, operational state that drifts, and a human who has to carry it all in their head if none of it is written down. We are beginning to wire his CAD output into a pack instance, so that the design intent, the planning constraints, the supplier conversations, and the drawing revisions live in a shape an agent can read. The first skill we wrote was a planning-narrative generator: the kind of document that goes to a planning authority, currently written from scratch on every project, with the same shape every time. That skill is the seed his pack will grow from.
The posture
The pack carries a posture. Let those who have ears listen. It is Jesus’s formula after the parables in the Gospels (Matthew 11:15, 13:9, 13:43, and the parallel lines in Mark and Luke). The way he tells the crowd that the message is complete, it is for those ready to receive it, and he is not going to chase those who are not. The phrase is etymologically native to Koine-OS, because koine Greek is the language the Gospels were written in. The pack’s name carries the stance.
Most teams and most individuals are not ready for this. Some sense the shift and are looking for a shape to pour themselves into. The correct posture for a practitioner writing this down is honest acknowledgement of the current state, quiet invitation to those who sense the shift, no marketing, and a willingness to let others opt out without being chased. Self-selection by design.
The consequence inside the pack is operational, not rhetorical. Every skill has to be valuable to one person working alone, because requiring bilateral adoption means failure in the whole early phase, which is most of a pack’s life. Worked examples show messy partial states rather than tidy rollouts. The README speaks in first person. Feedback goes to a person, not an inbox.
Teams that do not build their own koine tend to inherit someone else’s, usually the vendor’s, usually shaped to the vendor’s interests rather than theirs.
What the pack is standing on
None of the components in Koine-OS is new. Architecture decision records trace to Michael Nygard’s 2011 post of that name. The reviewer pattern has a lineage running from Fagan inspections in the 1970s through pair programming into modern code review. Specifications over intent for AI agents, documentation as infrastructure, forcing functions, and intent-readiness separation each carry their own ancestry in the software craftsmanship literature. What Koine-OS contributes is the composition, the method, the reviewer layer wired in, and the factory pattern built so other practitioners can produce their own instances. It is what those pieces look like when they are put in one place, with the disciplines named explicitly and the operating rhythm enforced.
Named artefacts outlive their authors. Teams that build their own koine tend to be the teams that survive reorganisations, attrition, technology churn, and the quiet turnover of who is around to remember how things were done. A personal vault that runs on the same shape does something similar. It lets one person’s thinking compound across years instead of evaporating between sessions. That was the thing I did not expect when I sat down one Christmas to build the app for my kids. I did not know I had been building the conditions for the work I do now to compound.
The brother in law’s pack is the one that will teach me most next, because it leaves the world of software entirely. When the method holds there, it holds most places.
Let those who have ears listen.
Koine-OS is at github.com/antikas/koine-os. The pack is its own README.