This project cybersyn supplies a recurring pattern: a powerful abstraction escapes its proper domain, gathers institutional confidence and begins making reality answer to the model. We’ve seen the same move in management dashboards, algorithmic hiring, enterprise architecture and now GehAI. The machinery becomes impressive enough that questioning its premise looks unsophisticated. What David gets right is the core mechanism, ignorance is often visible, but elaborate error arrives with diagrams, credentials and a steering committee. It can survive evidence because organisations have invested status, budgets and careers in keeping the framework intact. This essay occasionally makes simplicity sound safer than it is. Asking people what they need can beat weeks of modelling, but people possess incomplete information, conflicting incentives and unreliable forecasts. Complexity earns its place when it improves decisions under scrutiny. The useful test is whether the apparatus reduces uncertainty and survives contact with outcomes. But, AI raises the stakes because it industrialises persuasive elaboration, as a model can produce a polished explanation before anyone has checked whether the question, evidence or objective makes sense. The historical pattern predicts a flood of systems that optimise proxies, satisfy internal benchmarks and fail quietly in production. Their sophistication will make them harder to challenge, especially once the humans responsible for verification have allowed those skills to decay.

Feels that the metaphor is doing a lot of work here, and mostly earning it! Companies don’t suddenly become technically weak - right? They gradually lose the ability to recognise what good looks like or have taste in what is good. That’s a much more uncomfortable failure mode because everyone involved believes they’re making sensible decisions. I’ve seen versions of this happen in engineering organisations that grew quickly. New people learn from the system they’re given, interview against that system and eventually become the people defining the next generation of standards. Nobody sets out to lower the bar. The environment quietly does it for them. Ian gets that mechanism exactly right. What the essay leaves largely unexplored is that AI may accelerate both directions. Companies with weak engineering judgement can now produce software faster than ever, creating the illusion that capability has improved. Equally, organisations with strong engineering cultures can amplify their best people because routine implementation becomes cheaper. The differentiator shifts from writing code towards recognising architecture, making trade-offs and knowing when the model is confidently wrong. This feels like the real strategic risk over the next decade. Whilst every vendor is selling AI productivity, far fewer are helping companies preserve engineering judgement itself. That’s a much harder capability to rebuild once it disappears because the people deciding what “good” means are the same people whose calibration has drifted.

Microsoft’s headline promises an operating company; but the evidence currently describes an unusually large services and engineering organisation wrapped around Microsoft’s platform. The $2.5 billion commitment and 6,000 embedded specialists make this more consequential than another forward-deployed engineering announcement. Microsoft is preparing for customers to ask a practical question: “How do I get my own FDE capability?” The answer will probably bundle people, models, data services, governance and delivery methods into one Microsoft-shaped system. That’s commercially coherent. It also deserves scrutiny. The launch gets part of the outcome focus right. Enterprises have spent enough time admiring demonstrations. Useful AI work begins with the operating result and works backwards through workflows, data, controls and engineering. Yet “company IQ” remains too vague. A knowledge graph alone won’t make enterprise data ready for agents. Neither will a large model with a generous context window. Customers still need an engineering framework in which human FDEs and software agents collaborate, supported by reusable components, evaluation loops, security controls and clear ownership. Graph engineering, Fabric IQ and similar products may fit inside that framework; none supplies the operating model by itself. This is where Outcome Focused Engineering (OFE) has room to become the broader category. The reusable architecture matters more than whichever graph database, model provider or Microsoft product happens to be fashionable this quarter. A credible approach would let customers retain the method, substitute components and develop their own capability after Microsoft’s embedded team leaves.

The part that stuck with me wasn’t the canal. It was the suggestion that the Rekursiv was right four times in succession and still lost because the calendar hadn’t caught up. That’s a useful correction to the tidy stories we tell about technology. We love to imagine that good ideas win and bad ideas disappear. Reality is messier. Plenty of excellent ideas arrive before the supply chain, manufacturing economics or software ecosystem are ready to support them. Rekursiv appears to have landed squarely in that gap, and the article does a good job of explaining why its commercial failure doesn’t automatically invalidate its architecture. I’d still treat the central thesis with some caution. This is an investment firm’s essay, and there’s an understandable temptation to connect historical dots into a compelling narrative for today’s silicon startups. The evidence around independent performance validation is thin, and it’s easier to identify successful descendants after forty years than it is to predict them in advance. Hardware ages rapidly. Interfaces, instruction models and programming abstractions can survive several generations of hardware if they’re designed with portability in mind. History doesn’t just reward good architecture. It rewards architecture that can survive its first implementation.

Releasing old code is easy. Making it understandable, buildable and genuinely useful to today’s developers is where projects usually stall. This repository isn’t presented as a museum piece frozen behind glass, it includes working modernisation experiments gives future contributors somewhere concrete to begin. That’s far more valuable than dropping a tarball onto GitHub and hoping curiosity does the rest. Comic Chat was effectively making editorial decisions about conversations decades before today’s fascination with AI-generated interfaces. It inferred tone, selected expressions and changed presentation dynamically. Primitive by current standards, certainly. Yet the interaction model feels oddly contemporary. This release also says something about Microsoft’s relationship with its own history. Open sourcing legacy software has become a way to reduce custodial cost while strengthening developer goodwill. I’d still like more evidence that these preservation projects develop lasting communities rather than brief waves of attention. GitHub stars arrive quickly. Active maintainers rarely do. Anyway, Comic Chat was a thing I used for brief moments and never liked it. But that's me.. you should try it too...