If the same alphabet isn’t pronunced the same in different languages, and if the same word doesn’t mean the same in different languages (i.e. ask for some Pain in an English vs French), then it should be easy to believe that two English speakers saying the exact same thing, could mean something entirely different.

The real facade being that English is any way a common language we speak. In reality we all speak English-ish — a custom language with personal semantics, using common symbology at various layers — at the base layer the script, at the next layer the spellings, and the layer above, grammar.

I’m going to call this personal language a HyperLanguage to differentiate it from the common symbology of broad languages like English, Russian, or Urdu.

What we convey using those symbols is as different as a person named Jesus being a sole individual in the past 2000 years for an English speaker, and the guy next door for a Spaniard or Latin American.

The real tragedy of LLMs isn’t that they’re doing too much, it’s that the moment we found the 2020’s version of Eliza with decoder-only models, we stopped utilizing half the power of a complete Transformer architecture.

The problem Transformers were built to solve…

“Communication is the process of transferring an AST from one individual to another.”

Lera Boroditsky’s many talks explain the challenge of conveying meaning across languages: https://www.youtube.com/watch?v=iGuuHwbuQOg

This is well known. As a small example to set context, I come from a culture with large patriarchal joint families — dozens of people across 3+ generations living under one roof. We have nuanced words aunts, uncles and cousins that place them within 4 hops of my family tree conveying in a single word: fathers or mothers side, male or female individual, the generation upto +2 in either direction, and gender and relationship of lineage, i.e. son of brother of my mother vs daugher of sister of my father. The only English equivalents to these are: grandparent, aunt, uncle, and cousin.

So how do you translate full texts across languages? This is what the Encoder half of a Transformer does (your ChatGPT/Claude/Codex/Grok are all Decoder-only models).

In simple terms, lets represent each individual as a set of values each representing one degree of freedom: [generation-1, fathers side, male, husband-of-fathers-sister, etc.]

If we can fill these in based on context, then the phrase: “male cousin on mother’s side once-removed” becomes: “mame-bhau” in Marathi and vice-versa.

In short, this list of values is an embedding. The more dimensions (aka degrees-of-freedom) we provide an embedding, the more nuance it can hold.

If we get this far with capturing this nuance… what if we treated two English-speakers as speaking HE1 (Hyper-English-1) and HE2 (Hyper-English-2)? Have you ever had a conversation with an individual from the exact same city, town, education, cultural background, generation and yet felt like they “just weren’t getting it”? It’s been my entire lived experience. Wouldn’t it be nice if we could translate HE1 -> HE2 and convey our precise meaning?

On the other side of Computer Science is something called an Abstract Syntax Tree (AST). It is a normalized, canonical, uniform way to represent semantics accurately and precisely. When two ASTs are equal, they mean precisely the same thing.

In short: “Communication is the process of transferring an AST from one individual to another.”

We just didn’t take Transformers far enough

Imagine if we continued to build encoders (I’ll call them Projections for now) from HyperEnglish1 into the English or more general Embedding Space? Could we capture our meaning better such that a reader could decode our intent in a way they understood in their HyperEnglish2?

That is what WineTone is really about. This is why WineTone itself is open source, not really a business for me, but a playground for my intellectual exercise of HyperLinguistics.

In my opinion, even the best AI-powered therapy, counselling, depression, relationship advice, coaching, etc. apps being powered by (aka wrappers over) Decoder-only LLMs are missing the deeper power transformers give them.

Imagine an app where cultural nuances of phrasing are translated across boundaries. Relationship counselling where true intent is discovered, embedded and then translated for the recipient. In short, a world where we can accurately project our AST to others every single time. A world of HyperLinguistics!

It’s just a lot more fun to do this while drinking wine!

How WineTone works

Let’s assume that the identity of “A Wine” is closed over it’s bottle. I mean identity in a real Ship-of-Theseus kind of way. What “a wine is” in the most philosophical, moral, ethical, physical, literal, colloquial way. What I mean by closed is that what make the wine itself, is all contained — the molecules, the mixture (solution, emulsion, etc.), the proportions, the chirality, and so on.

Which is to say that “A Wine” is a very definable, finite, fixed entity. Which is to say that descriptions of said wine are subjectively objective — they are subjective to the person coming up with them, but they represent a very objective fixed entity.

Let’s place a wine on a 2-dimensional embedding space. One dimension will be sweetness, and the other dimension will be… sweetness?

Let’s project 4 wines on this graph. x-dimension is how sweet a wine is from 0 to 100. y-dimension captures the “kind of sweetness” — surely we all know that not all sweet things are the same. Aspertame, stevia, fructose and sucrose all taste different. Sweetness can be a pure smell — like that of honey. Sweetness could take up easily 100 dimensions in our embedding.

How do wine experts define it? They use eigenvectors of course, they just don’t know it. When they say a wine has hints of honeysuckle, or grapefruit, or oak — they’re collapsing thousands of dimensions into one dimension and pivoting around that dimension. Grapefruit covers all the layers of citrus, layer of bitterness, and more. Subtract the grapefruit and whatever is left is given a name. I’d be surprised if they have specific verbiage for the dozens of kinds of sweetness.

Sommaliers basically have two things that are going for them: Consensus and Ceremony. Consensus is easy — everyone uses the same basis vectors they learn through incessant practice. No different than learning to play an instrument. And Ceremony is when you create a bit of aura around a title and continually remind people of the separation between you and them.

Sure there are a few naturally gifted people — but there can only be so many Mozarts’ and Johns’ Williams.

Practically this means that there can be thousands of basis vectors to choose from that describes the same wine. And we have the perfect mechanism to convert anyone’s arbitrary description into this vector space: An Attention Encoder!

And this is exactly what WineTone does:

1. For each wine it produces a self-learned embedding space. It doesn’t matter what the space is. It’ll have a bunch of basis vectors and each wine will be some combination of those bases.
2. Every individual description provided for a wine is projected onto this embedding space, for now with a simple linear product. It proves the point. In short, I’m simply manipulating the embedding space to my basis vectors.
3. Then in my transformed space, I can label wines how I want. If my “sweetness” tends to be more aspartame, then the shift of origin + scaling of the y-axes puts all the aspartame-y wines right next to where my sweetness cluster search happens.

That’s basically it. In the future I’d love to build attention layers, but it really isn’t needed. At some point I plan to use chemical analyses to add some fixed objective dimensions to the embeddings. But they’re not strictly needed.

WineTone is a language translater between your language and everyone elses.

The point is larger than Wine

If you’re an AI researcher, product developer or especially an anthropologist, linguist or social scientist, consider the possibilities of capturing, translating and conveying accurate intent. How many relationships could be saved, how many egos could be not bruised, how many wars might be avoided?

We have the tool, and we’re obsessed with a chatbot.

Pantone solved color in 1963 by giving every shade a number, and since then no designer has ever had to say “you know, kind of a dusty mauve?” ever again. The conversation ends the moment you pull out the chip.

Wine has had 10,000 years and still can’t tell you what “grippy” means.

Ask a sommelier and they’ll say high tannin polymerization — textural drag on the gums. Ask me, having grown up in India, and “grippy” sounds astringent like water with alum (if you know, you know!) Ask someone who’s never been to France what “French oak” smells like and they’ll stare at you in confusion.

Expressing the same concept individually is one of the most basic joys of life. Yet, every wine recommender on earth, from the free apps to the “Maître Sommelier” interpret your language as if it were universal.

They embed your query into a vector space, search the corpus, and return what other people said about wines they drank. The system is listening, technically. But it’s hearing you in someone else’s accent.

WineTone is built to hear you in yours.

The Demo That Surprised Even Me

So I did a thing — I pulled publicly available data on 287,000 wine reviews, collapsed into 164,069 distinct (producer, wine, vintage) triples and embedded into 384-dimensional vectors — capturing both what wines taste like and what words humans actually reach for when they taste them.

Ran the query: “earthy and grippy with jasmine notes.”

Without any personalization, the system returns a perfectly reasonable American Riesling, a Zinfandel, a Cab Franc — the dictionary neighbors of “earthy” and “grippy,” assembled from what the corpus says those words mean.

Then I tried to calibrate the model TO ME. I labelled six wines I’ve actually drunk, in my own words.

The system now returns four Italian Nebbiolos from Piedmont — including three Barolos it had never been told to favor. From one label on one wine, it inferred that my “grippy” lives in Nebbiolo territory, that my “jasmine” bends toward Barolo’s floral signature, and that the sommalier’s “grippy” and mine are the same word in a different language, with different semantics.

This Is Not a Wine Problem

The wine domain is just particularly delicious for demonstrating the point, but the underlying failure is everywhere. Someone searching “big cuddly bears” on a pet site probably means Bernese Mountain Dogs, but the system may warn against adopting grizzlies. Someone asking for “cat videos” on a platform that knows they’ve watched five David Attenborough specials is almost certainly looking for snow leopards, not their neighbor’s tabby. Someone asking for “a birthday wine” might want a crowd-pleaser for a dinner party or something rare and weird for a solo celebration — and the right answer depends entirely on who is asking, not on the semantic average of everyone who’s ever typed those three words.

The recommender systems that win the next decade won’t be the ones with the most training data. They’ll be the ones that calibrate the user, not just the corpus.

Why It’s Fast, Cheap, and Hallucination-Proof (And Why That’s Rare)

Most AI recommendation architectures make a quietly expensive mistake: they ask the language model to generate answers instead of letting the database select them. The result is slow, token-hungry, and occasionally confident about wines that don’t exist.

WineTone uses a 33-million-parameter embedding model for exactly one job — turning text into a vector — and then lets CedarDB (a fast, Postgres-wire-compatible analytical database with pgvector built in) handle everything else. Similarity search across 164,069 wines runs in under 50ms. Per-query cost is microcents, not dollars. And because the LLM never produces wine names — every result traces back to a canonical database row with full provenance — there is no hallucination surface. Nothing is being invented. Everything is being found.

The per-user projection that powers personalization is a 384×384 linear matrix, fit via ridge regression in milliseconds and stored in about 250KB. It starts as the identity matrix (meaning a new user gets the generic baseline), and every label they add bends it incrementally toward their personal idiom. The math is closed-form. The cold-start problem effectively doesn’t exist. And the calibration history is versioned, so you can watch each user’s “accent” crystallize over time — which turns out to be a genuinely beautiful thing to look at.

Where It Goes From Here

The current prototype covers 20,000 of 164,069 wines with dense embeddings (full-corpus encoding on CPU takes 2.7 hours, and I get bored easily). It speaks only English, which is a shame given how much I lecture on distinct languages. And it doesn’t yet incorporate actual chemistry — the full vision in PLAN.md pairs the language embeddings with GC-MS chemical fingerprints, which is about $7K–15K of analytical work away from being real.

That last piece is the moat. Language models can learn that people describe Barolo as “tar and roses,” but they can’t smell the rotundone molecule that causes the tar note or the geraniol that causes the rose. A system that fuses natural-language calibration with actual chemical fingerprints isn’t just a better recommender — it’s an objective, versioned, scientific archive of what wine actually is, at a molecular level, mapped to what humans actually say about it, at a personal level. Pantone for wine, in the most literal possible sense.

The corpus itself becomes more valuable over time as user labels fold back into the training data, meaning tomorrow’s encoder has heard more accents than today’s. That’s a data flywheel with a genuinely interesting shape.

Memorializing Wines and Reviewers

The wine-industry potential here is two fold and can be extended to other spaces with a subjective-but-internally-consistent grouping. Subjective to individuals, but within the individual, consistent.

First of all, we can memorialize historic wines who have their last 10 bottles on the planet left. Or even rarer. By producing a high-dimensional embedding, if we ever reproduced that wine again, we’d know how far we were from the original. We can also use this to measure vector distances across any arbitrary wines.

Secondly we would memorialize various reviewers. If I have a favorite person whose palette I tend to like more than others, then I can pull up their projection matrix.

The Thesis

Recommendation systems are very, very good at understanding the text. The next leap is understanding the person. Not in aggregate — demographic models already do that, and they are, frankly, boring. Individually. One projection matrix per person. One accent at a time.

Your “grippy” and my “grippy” are not the same word. WineTone is a small experiment in what becomes possible when a system stops pretending they are.

It’s also, incidentally, a pretty great way to find a Greek Nykteri, Hungarian Furmint or Romanian Dealu Mare — all of which are volcanic, mineraly, floral, but each described differently in wine literature.

Code, architecture plan, and a reproducible demo at github.com/archisgore/WineTone. Apache-2.0. Built by Archis Gore. Wine-adjacent academics, chemistry labs, and anyone who has ever been handed a Riesling when they asked for something “earthy” — my inbox is open.

Imagine walking into a Windows shop with a Mac app on a USB stick. You would expect nothing to happen, and nothing would. The app doesn’t run, and we treat this as the natural order of things.

Now imagine walking into a Linux datacenter with a Linux binary on a USB stick. Different company, different country, different threat model. None of it matters. The binary runs, and that should disturb you more than it does.

The monoculture is the bug

Every Linux server you have ever touched — your bank’s, your government’s, your hyperscaler’s, your adversary’s — runs roughly the same Linux as every other Linux server on the planet. Same syscall numbers, same calling convention, same error codes, same /proc layout, same ELF format down to the byte. When an attacker writes a working exploit for a Linux machine, they have a working exploit for every Linux machine, because the economics of an exploit are one-to-many: one bug, ten million reachable targets, frictionless arbitrage.

This is not an accident. POSIX promised it, the GNU project delivered it, distros standardized it, and the cloud immortalized it. Write once, run everywhere is a beautiful slogan when you are shipping software and a catastrophe when you are defending it.

Where Polymorphic Linux stopped

I spent eight years at Polyverse building Polymorphic Linux — drop-in scrambled binaries for the major distros, so the ROP gadgets in your libc were not the gadgets in mine. Memory-corruption exploits broke, and we shipped to hospitals, telecoms, and governments. The math was right, but the boundary was wrong.

Polyverse scrambled the contents of binaries without touching the contract between them. Two Polymorphic Linux machines still spoke the same Linux: same syscall numbers, same ABI, same everything an attacker needs to construct the next exploit. We diversified the gadgets while leaving the grammar intact.

encrypted-linux finishes the job.

A Linux with a private dialect

It is a Linux distribution in which the grammar itself is per-build. The kernel, the C library, the compiler, and every binary produced by that toolchain agree on a private dialect derived from a single seed, such that a different seed yields a different dialect in its entirety.

Pick a seed and build your Linux. Your write() is no longer syscall number 1 but a 64-bit value nobody else holds. Your function calls do not pass arguments in %rdi but wherever your seed dictates. Your ENOENT is not 2. Your /proc/[pid]/status carries no field named VmRSS. Your binaries carry an EI_OSABI byte meaning this build, this seed, and anything stamped differently — a stock Ubuntu binary, a leaked attacker dropper, an off-the-shelf rootkit — receives ENOEXEC from the kernel before it executes a single instruction.

This is not obfuscation, not a sandbox, not a watermark. It is a language barrier. Your Linux and mine are now as different as Mac and Windows, not because we ran them through different obfuscators, but because they speak different machine-level languages at every layer of the contract. The same exploit cannot work on both. The same shell-script payload, the same gadget chain, the same kernel rootkit — none of it ports. Attackers who once wrote once and owned everywhere must now write against each target independently, per build, per country, per company, per rack.

Execution deterrence

I call this execution deterrence, and the promise it makes is narrower and more honest than the one most security products offer. It is not “you cannot break in,” which is a promise nobody can keep. It is this:

If you do break in, the code you brought with you doesn’t run.

The cost of an exploit collapses from one-to-many to one-to-one. We reintroduce friction into a market the attackers had perfectly arbitraged away, converting a free attack into a paid one and a one-to-billions broadcast into billions of separate one-to-ones.

Whose Linux?

This is, at its foundation, a digital sovereignty story.

Sovereignty is not only about where your data lives. It is about whether the executable layer of your civilization belongs to you. At present, the answer is no. The executable layer is a shared global commons, and every nation, every bank, every embassy, every hyperscaler is downstream of the same Linux ABI that has been frozen since the 1990s. When CVE-2026-whatever drops, your sovereign-cloud nameplate offers no protection, because the same exploit works against your air-gapped agency, your enemy’s grid, and your neighbor’s bank with equal indifference.

Consider what changes if that were no longer true.

A country builds its sovereign Linux, so that its weather agency, its tax service, and its strategic command all speak the same dialect, built nowhere else. Other countries’ attack toolkits do not compile against it, and CVE-class exploits stop crossing borders.

A bank builds its Linux per business unit and rotates quarterly. Trading runs one dialect, retail another, and the SWIFT gateway a third. An exploit that lands in one segment is a paperweight in the others, because lateral movement has become a translation problem rather than a path-finding problem.

A hyperscaler builds a fresh Linux per tenant, making two customers on the same physical hardware as foreign to each other as Mac and Windows. Cross-tenant escape stops being an exercise in finding the right syscall hole and becomes an exercise in guessing 64 bits of calling convention, error codes, and procfs schema simultaneously.

An embassy carries its own Linux on its own drive. The host country’s surveillance toolkit, built against everyone’s Linux, finds itself fluent in the wrong language, and the classic bag-search attack stops working.

None of this is slideware. The kernel patches, the compiler patches, the libc patches, and the build orchestrator are all in the repo. The reference image boots in QEMU. The hello binary runs. The stock-Ubuntu hello does not. The CI badge stays green.

“But isn’t the seed recoverable?”

This is the crypto-nitpicker’s question, and while it is the right question, it is being applied to the wrong problem.

The seed is public in precisely the same sense that your house key is public — you carry it in your pocket every day, and in principle anyone could obtain it. The security does not rest on the impossibility of that acquisition. It rests on the fact that acquisition costs something, that the cost is per-target, and that the next target carries the same cost all over again. Strong cryptography raises the per-target cost, which is desirable, but the deterrent does not require unbreakable crypto. It requires any friction at all, applied uniformly to every contract in the stack, scaled by however many independent dialects you choose to maintain. That number is your deterrence dial, and you set it wherever your threat model demands.

You cannot patch your way to security

Roger Schell, the father of trusted computing, wrote in 1979 that you cannot patch your way to security. He was describing the bolt-on industry that would consume the next forty-five years of the discipline, and we have, right on schedule, vindicated his pessimism. We have audited, scanned, EDR’d, ML’d, and Zero-Trusted ourselves into a position where the same exploit still ports across continents without modification.

The question worth asking is whether the cure is more detection at all, or whether it is a thinner shared surface. Encrypted-linux is one answer to that question. The Encrypted Execution paper, whose patent I pledged to the public domain, makes the broader case: per-build cryptographic diversification at every layer where a contract exists, making the contract private and the language yours.

The one thing to take away

You need not believe the cryptography is unbreakable, nor that the seed is invisible, nor that encrypted-linux is the final shape of the idea. You need only accept a single premise:

If your Linux is the same as your adversary’s Linux, you are sharing the executable layer with your adversary. And if you are sharing the executable layer with your adversary, you are not sovereign.

Solving that problem requires no additional firewalls, no additional SOC analysts, no additional AI. It requires a build process that produces a Linux belonging to you alone. The code is on GitHub, Apache-2.0, patent pledged. Make a Linux nobody else has, one that runs nobody else’s code — make a Linux that is yours.

GitHub - archisgore/BFY_Bottom_Timer: A Dive computer based on Arduino + off-the-shelf components in a day.

Last week my Petrel died after a decade of excellent service. An opportunity to disassemble it.

This basically confirms what a dive computer really is.

It’s really a microcontroller (Cortex-M chip in this case), an ISM module, a pressure gauge and a screen.

Intuitively I knew this is all it really could be, but always happy to confirm.

I bet most of the cost really comes from the need for reliability, testing, and especially the deco algorithm. Last thing you want is a computer failing mid way through a dive.

As I work with people who were born after I started working in tech, my turn to tell you one thing we had “back in my day” culturally that I think is our industry is missing. Perhaps it was so subtle, pervasive or simple that it doesn’t make into articles about the future of Engineering.

Today’s rant is about why AI isn’t the reason we don’t have a healthy Junior Dev pipeline, the same way NodeJS didn’t stop a pipeline of engineers learning C/C++/Rust/Assembly/CUDA. The reason is far simpler to fix and uncomfortable to admit.

Want to know what we had 20 years ago that this generation doesn’t get?

We had a lot of “eff around time”

My career started towards the end of the software cambrian explosion when every week we had new operating systems, new processor architectures, new motherboards, RPC frameworks, REST vs RPC debates and so much.

But the absolute key point is — I spent my first five years of my career shipping absolutely nothing useful. I worked on SOAP, REST, distributed filesystems, Desktop-in-the-Browser, goofy OSes, and so much more. And a lot of that diverse exposure helps me out today.

There’s a myth we believe despite all of human history stating otherwise: That humans don’t learn or innovate unless we force them to. Which is directly contradicted by everything from the first smallpox vaccine before germ theory, to Mendel’s invention of statistics and discovery of genes, to Joseph Fourier’s then-controversial infinite-sum-of-waves during WW2, all point to people who will simply not be satisfied or contained with the status quo. What’s more telling is these were the people who survived, which means there probably were 100 times as many who tried and failed.

All the Senior/Principal engineers we know of partly grew because they moved up the junior ladder, but what they really grew from was just an incessant amount of effing around and making mistakes.

Everyone I know who understands how a MOSFET works or how to produce build an npn transistor, or build a logic gate, doesn’t know it because there was a junior engineer task assigned to them. They know it because it was fun to know. What being a junior used to mean is that we’d tolerate a significant amount of people building logic gates for a few months even when there wasn’t anything innovative in doing so, and no direct billable benefit to it. Because we knew that having someone on the bench who could build logic gates and an entire processor through one PDF bug can break iMessage with zero-clicks: https://cybersecuritynews.com/imessage-0-click-exploit-iphone-users/

I understand the appeal of “Frameworks”. Wall street and the industry just loves frameworks and systems and branding because simplification doesn’t sell.

What bothers me further with the Frameworks for developing Junior Developers is it indexes so much on Code Smells and Lines of Code Coverage or building an intuition for Async protocols and deadlocks. Mentorship is at best 2nd-hand learning — you’re going to get a cult that parrots dogma, not problem solvers grounded in first-principles.

What bothers me even more is it misses the biggest aspect of seniority — the ability to collaborate, to move conversations forward, to take difficult feedback, to miss deadlines — a LOT, to miss goals — a LOT, to deal with a difficult coworker, a difficult boss, a hostile company, and so much more. Almost anyone who’s credibly valued in the industry has caused a cataclysmic event in their company — I’ve brought down at least: live.com, amazon.com, bits of facebook.com and for healthy measure I’m pretty sure I’ve hurt instagram and threads a LOT. The key growth skill is being able to show up the next day, face your coworkers, own up to your accountability and do better. That’s what AI might really take away.

What we really truly need to develop this generation of Junior Devs is to give them lots and lots of eff-around time, exposure, opportunity and feedback. I promise, AI or otherwise, everyone wants to build compilers, filesystems, MOSFETs, logic gates. We have to give them the room to do it, and fail a lot, and learn how to handle that failure.

Kids aren’t going to stop learning because of AI. They’re going to stop learning because we’ve disincentivized them from learning.

If you were around in the 70s or 80s, you probably witnessed a cambrian explosion of programming languages — Fortran, Lisp, Prolog, Smalltalk, structured programming, OOP, Lambda Calculus, and more.

Each of these solved a credible need, which is why modern languages are so often multi-paradigm.

AI is going to eliminate “coding”, or so LinkedIn tells me when I bother to login. I’ll bet at least half the people even believe it.

I’m here to assure you, not only are your jobs safe, but they’re about to get a hell of a lot worse (translation: massive job security).

We’ve heard a lot of takes on why programming isn’t really coding, or the artistry of it and what not. It’s all true, I guess, but there’s a far more pragmatic reason we’re missing.

AI is not Super-Turing

(Super-Turing or Hypercomputation: https://en.wikipedia.org/wiki/Hypercomputation)

That pesky Church-Turing thesis comes to haunt us, because no AI can do “more computer” than the computer that flew on the Apollo missions. Actually it really can’t do “more computer” than Charles Babbage’s Analytical Engine from the year when Victoria became Queen, which we now know to be Turing-Complete, thanks to Ada Lovelace having invented loops 80 years before Alan Turing.

This isn’t to dunk on the amazing utility it provides, but to point out all the problems it cannot solve, because a Turing Machine can’t solve them!

Basically — AI cannot verify other AI because at best, every AI is only Turing Complete. And that means we cannot look at it, it’s prompt, generated code, and even determine that it will even halt, much less determine that it won’t do anything worse.

The Prediction: We’re going to reinvent Lisp, but in AI!

I’m going to build up my argument, but if you already buy this premise, then here’s the punchline:

In the next year we will see:

1. Sklisp — Greenspun’s 10th rule will apply — there will be a Great Debate around the granularity of Claude Skills. Should we start with a skill for elementary counting principles, and build number theory on top, to solving prime factorization?
2. Chat++ — Holy War over whether Agents may inherit from other skills, or call them. Should the agent for “Book Airline Tickets” and “Book Taylor Swift ticket” call into a “Book Tickets” agent, or inherit from it and append to it’s prompt?
3. Claurlang — Skills are really agents that we run in a global context, and context pollution is a functional and security risk. We should created thousands of small contexts per skill that provided clean inputs and read outputs. Each skill should be a complete agent spun up on demand and killed when done.
4. LVM — Inevitably, LLM builders are going to build moats. And we’ll have a Virtual LLM that abstracts over all the moats.

Why I think this

I spent a decade in cybersecurity. While the most popular solutions are antiviruses and what not, the real problem that we all face, is that at best we want to Figuring out Intent, and at worst, we want to know the Impact.

What is Context Pollution, if not Shared Mutable Globals?

What is the difference between these two?

int p = 5
int q = 5
adjustValue(p)
p = p + q
modifyValue(q)
q = p + 3
modifyValue(p)
p = p - 2
// Why is p 52 when it should clearly be 25?

vs

"When I say machine the first time, it should be my web machine. 
But if the agent 'do-database-cleanup' was called, then use 
the first machine referenced before that agent was called. Keep track of all
machines referenced throughout."

What is malware signature detection, if not prompt detection?

Instead of hashes of binaries, we’ll be sending hashes of text strings. A popup warning you that “The agent you’re about to call has, in it’s prompt, an instruction to delete all files” doesn’t seem far fetched.

Armies of people will be developing malicious prompts and larger armies will develop dictionaries for them.

It’s going to take one Agent or Skill to pollute someone’s context before a cottage industry of cybersecurity industries pops up to protect you.

What is Privacy if not Heap Isolation?

Say you have the greatest agent in the world, but you don’t want having it the full context of what you’re doing — both to avoid pollution and maybe because you don’t trust it/the authors. So now we’re passing developing public, private and protected members?

Which is to say — hang in there. There will be may jobs eliminated until the first black swan event, and then there’ll be even more demand for vetting prompts, isolating AIs, isolating contexts — we’re about to rediscover isolated heaps, protected class members, not using globals everywhere, and all of the past 50 years of programming learning all over again.

We’re going to need ADB (AI Debugger) with breakpoints at various steps. We’re going to need stack traces when an agent fails. Strap in because the next 20 years of work is about to be created, and everything you know is going to be useful.

A graph of Contexts that can be created, inherited, forked, merged, granted and revoked access to

A few weeks ago, I prompted a model with a ton of situational context — let’s say I had 200 bananas of 3 different species, arriving on different container ships from 3 different routes, each with different deliver risks. By providing this information, I was able to get my model to create the perfect smoothie plan, which I wanted to share with a colleage. I couldn’t.

In human terms, I wanted to tell my Model, “Can you speak to Mr. Hypokalemia and answer whatever they want based on all this information I’ve given you?”

From there, I wanted the model to answer questions about the perfect smoothie plan, what their potassium consumption would be over time, what they could do to offset risks, and so on.

Even the typically AI-frenzied LinkedIn had few satisfying answers.

This rant was written at midnight so it’s unstructured, but I definitely think this should exist. In my head I’m calling it “Confidant.ai” (My personal AI confidant) and I’m calling this method of computing, “Confidant.AI.l computing.”

Confidant.ai: An AI Network

I’m going to describe a world that someone else should build (because I have sufficient side-hobbies for me to prototype this.) Please skip the “links to context sessions”, or “digital twins” and all that. I know. If those things do what I’m asking, I’m sold on your solution tomorrow — tell me where to sign up.

One of the problems with all models today is they lack global and contextual memories.

Use Cases for Confidant.AI-al Information sharing

For example, if I want to share a procedure, a runbook or a cooking recipe, I still have to write/blog/post about it, which other’s models have to scrape to provide them a version for them.

What I cannot do, is go to Claude/ChatGPT/Gemini and TELL it what my recipe is, and then have someone else ask it for “Archis’s recipe” which it can answer for.

This applies to a lot of information — I still enter my calendar information in my calendar tool. I store notes in notes. I store wikis in wikis. Sure AI is an interface to the information, but it could be the Confidant for my information, vending it out to anyone who’d ask, by checking with me.

Imagine someone able to ask Confidant.ai, “I’m thinking of asking Archis to dinner next week. Does he have any preferences or restrictions?”

Depending on who is asking, Confidant.ai would ping me to check if it can share this information with them. Depending on whether or not I grant the permission (through a prompt), it is able to share preferences or decline to share.

Now extend that to calendar tooling — it could remember my preferences for routine activities and answer on my behalf, only checking with me for confirmation.

Use Cases for Shared Contexts

Imagine telling Confidant.ai, “I’m thinking of a camping trip with Steve and Tim. Can you reach out to them and figure out the best location for the three of us? For my part, I prefer glamping, with cellphone coverage and a dry place.”

It remembers the shared context, where all 3 of us can seamlessly add to it, and behind the scenes, the AI is constraint solving. But it is only asking questions to each of us where it needs a conflict-resolution or a compromise. This is different than “sharing a link”. If all of us have a valid identity on confidant.ai, we are able to reference each other clearly.

Furthermore, it’s bringing each of our individual personal contexts to weigh in on decisions, while keeping private information discrete. For example, it doesn’t have to tell everyone I’m dairy-free, if there is a viable restaurant that has dairy free options that fits within others’ preferences.

Group Shared Contexts

Consider a team, org, company using Slack, Teams, etc. At various grouping levels are ongoing conversations and open questions. My tangential work chat is full of a dozen open questions I know the answers to. These answers are approved-shared (i.e. at least for the group I’m answering them in, the information is public.)

Having the AI “remember” these contexts would immensely help on three fronts:

1. Preemptive Answers: Suppose someone asks, “Does anyone remember how to disable ramdisk on a host?” and confidant.ai says, “If this helps, Archis answered this already in various chats. You ssh into the host, and run <foobar>.”
2. Proactive Tracking of open questions: I could ask it every morning, “What are some of the questions in all my groups that have been unanswered for more than 3 days?”
   Furthermore, instead of answering it in the chat, I could tell Confidant.AI, “Ah, so the way to disable ramdisks is…” and it could go respond with that information in any number of places it is relevant. Basically I no longer write Wikis as an out-of-band exercise, but rather I inform my AI, and it adds it to a selectively-shared context.

A Context Graph — The Missing Link

I think the key link here is some sort of Context Graph — think Git-for-contexts, or (I cannot believe I’m saying this) a Blockchain for Contexts?A storage system where contexts can be created, inherited, forked, merged, granted, revoked and more.

All these are accessed through a multimodel conversation interface. Rather than think of Passwords, Certificates and ACLs, you think in terms of, “Hey confidant.ai, can you tell me the things about me that are shared with people? And whom are you sharing it with?”

And it could respond with, “Your family knows your blood type, anyone you agree to a meal with can access your dietary preferences, and anyone in the Confidant.AI.l Network can get your answers to the scuba diving sites in the PNW.”

We’re Almost There — With Extra Steps

Depending on the reader, this is either solved through something you’re working on — agent personnas, or what not. Or people will never go for this. But people already are!

We’re already in a world where AI’s are talking to AI’s — whereas what we really want is a shared context. Think about:

1. Group Chats — Apple, Google, Meta — all users are using “Rewrite with AI” to write what they want to say. And all readers read AI Summaries. Why the ceremony? I argue that what people really want is to say what they mean, and hear in an actionable format.
   Maybe I just want to tell Confidant.AI, “Hey I simply don’t want to hang out with so-and-so.” and the person hears the polite version that works well for them. (A tangential rant on how-we-really-speak-different-languages down below.)
2. Resumes and Recruiting — Would be nice for me to tell Confidant.AI my Shor’s algoritm repos, GCC/LLVM modification, and other project repos on Github, my patents on USPTO.gov, and so on. It could remember this context that I could share with places I might be applying to. I already have to use AI to write my resume in a way that the hiring company’s AI can understand it. Why the ceremony where information gets lost anyway?
   Recruiting companies can simply ask confidant.ai, “Can you find me candidates who can sufficienty solve the discrete log problem on quantum circuits, as demonstrated by code they’ve written that’s distinctly different from typical samples?”
3. Finally News Consumption — twitter, reddit, etc. Why? If you have a thought, why not tell your confidant.ai stuff throughout the day?
   “You know what I think about Starbucks burnt coffee? I don’t appreciate charcoal-water in the morning!”
   “I visited Vienna last week. Here’s some photos for you to remember. It’s okay to share these with my friends.”
   And others could ask, “What are some of the interesting updates from my friends?” or “What are people’s opinions on Starbucks coffee?”

Basically if we’re using AI to produce content and then AI to consume it… what we’re actually doing is: Speaking Different Languages!

Hear me out!

An Era of HyperLinguistics

None of us speaks the same language!

My academic passion for cross-language semantic fidelity is established beyond a doubt given that I just spend 8 years developing compilers and interpretors that maintained semantic-meaning across languages.

Here’s the key insight I think we’re all missing, and why decoder-only models might want to consider encoder-decoder architectures: None of us speaks the same language!

I know this sounds controversial. Lets construct what Language actually means — it is a symbolic representation of semantic intent. Yet literally every person’s semantic interpretation of the same symbols is dramatically different.

Consider that most of the North American-European world uses the Roman Alphabet. Just because we use the same alphabet doesn’t mean that the letters have the same pronunciation across languages (v, w, j, etc.). Just because the same word is used across multiple languages, doesn’t mean it means the same thing.

So why would two self-proclaimed English speakers mean the same thing, when they use the same symbols? We frequently don’t. Can you recall a time when you had to throw a disclaimer such as, “and I’m using the dictionary definition of this word”, before saying something? Can you recall a time when one person’s ‘request’ meant another person’s ‘command’?

I’m not even touching political discourse with a ten foot pole!

I would argue that the biggest benefit of AI which we’re already using it for, is to say what we mean, and hear what is meant. For some reason we’re all cowardly to eliminate the middle step and build an AI Confidant.

Most of you know that I spent a small fortune reacquiring my patent that was owned by my former employer.

Today I’m pledging that patent into the public domain i.e. I will not prosecute any infringements, and to make it more concrete, for a nominal fee to my contracting lawyers, will grant anyone who asks, a perpetual unlimited unrestricted license to use it.

I also hastily wrote a whitepaper hosted on encrypted-execution.com that explains what the patent is about, and what I want to do with it.

I’m going to put up development bounties for developers who can build some of the stuff that I don’t have time for and legally shouldn’t. Your contributions will all be open source and free for all to use as they see fit.

More updates once I get some time off to play with compilers.

You can skip this if you’re a proficient cook — you intrinsically do this, but don’t consciously recognize that you do.

I spent most of this past year teaching baking to donors to my favorite art gallery in Seattle. I write this in retrospect knowing that:

• Very few, if any, cookbooks, blogs or videos really teach what daily cooking is like (at home or even in a commercial kitchen.)
• If they do, they’re not known enough that it continues to intimidate people.

So let’s get to it.

Is a recipe, really a recipe?

I’ll demonstrate my point with the Simplest Cake Recipe Ever: White Cake

Go check out the recipe linked, take a moment to visualize how you’d really move around the kitchen making it. Imagine this in YOUR kitchen being done by YOU — your utensils, your counters, your mixing bowls, your oven and your cleanup.

Do you see it? Are you really going to do your Mise En Place like the photo?

This is probably how you’ve seen all baking — in cookbooks, on TV, and so on. Do you keep a healthy stash of variously-sized glass or ceramic bowls? Do you look forwarding to cleaning them all?

If you measure ingredients out as you go, do you continually flip back to the proportions? Do you need to clean your measuring cups and spoons when the ingredients are incompatible, i.e. measuring out flour after the milk? It sounds exhausting, and it’s insane that the Big Chef industry promotes it.

The problem is…

Recipes don’t teach execution

Unless you’re a trained Chef, wherein “running a commercial kitchen” is part of the training, even cooking classes don’t do much to help.

Let’s rewrite that recipe just a bit differently:

1. Start with two 2 mixing bowls and a cheap kitchen scale. We’ll call them Bowl 1 and Bowl 2. If you have a stand mixer, Bowl 1 should be its bowl.
2. Turn oven onto 350F.
3. Place bowl 2 on the scale. Pour in 1 1/2 cup (or 188 g or 6.5 oz) of flour. Pour in 1 3/4th teaspoons (8 to 10 g) of baking powder. Mix gently.
4. Place Bowl 1 on weighing scale. Add 1/2 cup (1 stick in US or 227 g or 250ml) of butter. Pour in 1 cup (200g or 7oz) sugar.
5. Mix contents of bowl 1. If using stand mixing, start it off to do it’s thing. Once it’s slightly homogenized, add an egg. Once that egg is mixed in, add a second egg. Add vanilla. Once mixed thoroughly, using a spoon begin adding contents of Bowl 2 gradually as they homogenize.
6. Place bowl 2 back on weighting scale. Measure out 1/2 cups (or 120 g) of Milk.
7. Pour milk into Bowl 1. Mix.
8. Dump everything in a baking pan, and stick in the oven for 30–40 minutes.

Three things to observe here:

1. I’ve got all my measurements and conversions inline. I’m not looking at “Step 20: Add the butter” and going back 3 pages to figure out how much butter. Nor am I prepping in one of my infinite bowls before I begin.
2. When possible I don’t even waste a measuring cup or spoon. I pour flour, sugar, milk, and such straight out of their respective bags or cartons and using my measuring scale.
3. Even if you insist on using measuring cups — you’re measuring out the dry ingredients (sugar and flour) first, and then using the same cup for the milk. That’s it. One cup to clean up. And 2 bowls to clean up. If you’re using weights, just pour stuff in the bowls until you hit the target. Invest in a transparent measuring cup with lines on it, so you’re not using 3 separate ones for 1/4, 1/3, 1/2 or 1 cup.
4. I order instructions, so I only go forward. If I need separated egg whites and yolks, I add that as an instruction. If I’m going to need the whites the next day for an eggwash over my pastry, I write that as an instruction (and upfront mention I need a tupperware container.) I write down how long to wait for something to rest, or if I should be interleaving some other step in between (cleaning up, whipping cream or egg whites, soaking raisings in brandy, etc.)

Sorry if this is really basic, and yet I noticed repeatedly that participants came out surprised that all they had to clean were 2 spatulas, a couple of bowls, a stand mixer attachment, a whisk and a measuring cup.

Once you begin to rewrite recipes in an execution focussed manner, your cleanup grows logarithmic to your number of steps and ingredients. Simply put if you make a recipe that has ten times as many steps and ten times as many ingredients, you only clean up twice the number of utensils. If your recipe is a hundred times as much, you only clean up three times as much.

So now you know the secret to my constant baking. I can go 1000x more complex than a simple white cake, and I only have to clean up four times as much. That almost incentivizes me to go complex because I’m getting a 100x better product for only twice the effort.

Every cake, no matter how complex, has some dry stuff (sugar, flour), some wet stuff (water, fat)and in the most elaborate cases, a 3rd bowl for whipped egg whites. That’s it. Whether it’s a Genoise sponge, or a Red Velvet or a Chiffon or even the simplest pound cake — measure 1lb of everything, mix and boil (apparently the only method of cooking known to the british).

All your cooking friends implicitly do this

If you’ve been intimidated by that one excellent cook you know — I promise they’re intrinsically reordering steps to optimize execution and nobody is doing it the way a TV chef does.

Other random tips

1. Start with highest-temperature stuff towards lowest. If you want to toast peanuts or spices, do it on a dry pan — you need heat to get all those aromatics out. Then add oil and fry stuff that needs evenly-distributed high heat — browning your meats, getting char and flavor on vegetables, sauteeing onions. Finally you add anything with water — tomatoes, celery, bok choy. Once the temperature drops, your spices stop toasting and your peanuts get soggy. There’s a place for boiled peanuts in food, so be sure to know what you’re going for.
2. Try to avoid sudden temperature drops — buy a cheap electric kettle. If you need to add water to soups, stews, etc. Boil it before dumping it in. The cooking process abruptly stops when you drop temperature like that.
3. Baking is NOT precise. This random comment pisses me off everything I hear it and I suspect the Big Chef lobby has something to do with it. Your baking probably sucks because you’re measuring too precisely. The worst way to make french macarons, for instance, is to measure everything precisely and not think further. Not all almond flour has the same moister every day. Not all eggs are uniformly sized. Instead, you have to know what consistency you are looking for. Same for breads, cakes and what not. Your outcomes will be consistent if you know what intermediate consistencies should look like. The good recipes will describe them. This doesn’t make cooking more technical or complex. In fact, makes it easier.
4. This also applies to 90% of recipes you’ll come across, if they weren’t specifically designed for home proportions. Most recipes are scaled down from commercial kitchens where things sit around for a while — soups get reduced over a day, egg whites get dry if you’ve separated them in the morning, dough rests a lot. Instead focus on what consistency you’re trying to achieve and adjust it.

Why?

How I got interested in blockchain and crypto is a longer story, better told in person.

What we did discover, after speaking to lots and lots of people is there are a whole lot of legitimate use-cases for using a distributed immutable ledger, that have nothing to do with currency.

None of these are revolutionary, but each of them could benefit from evolution. A few that we are convinced of:

1. Consider data used for published academic research. If a publisher reaches a particular conclusion based on the data, a published “smart contract” can validate the repeatability (though not the reproducibility) allowing anyone in the future to easily validate the conclusions drawn.
2. Consider training an AI model to be non-racist and non-misogynist. Publishing the training set on a distributed system and publishing the training methodology to be cross-verified may provide better visibility for consumers into many of the systems we use, and provide a reduction in liability for those publishing those systems (think self-driving cars, facial recognition, etc.)
3. P2P games where you directly connect to each other, and the “game play” is directly coded as smart contracts. You spin up “a chain” between 5 players, and play the game. The chain overall validates all moves are valid.

Aside from these, there are a number of opportunities to improve on the current state of the art:

1. You may want locked-down audited, verified, signed, certified blockchains smart contracts in a safe language.
2. You may want to access GPUs, inference/neural engines, lots of storage or memory, and more, in smart contracts.
3. Smart Contracts should be writable in a whole host of easily-pluggable scripting languages.

How?

Let me introduce you to Landslide, a Timestamp VM implementation for Avalanche, 100% in Rust. I expect it to become the basis for many other VMs that can do incredible things.

I also expect this to open up a number of other applications such as auditable and immutable smart contracts, smart contracts that can use native system resources, VMs that can plug in a host of other scripted and unscripted languages, entire game engines coded as a VM, and so much more.