How do you scale language model search? Can a language model be guided towards solving new problems that it usually cannot solve purely through guided resampling without training the model whatsoever? Turns out the answer is sorta yes. This has important implications for post-training and safety research.

First, it might be tempting to use MCTS. After all it worked for AlphaGo so well. On that topic I don't believe it's an accident that AlphaGo & AlphaZero are arguably the only examples of ASI that we have so far. But MCTS works well for domains with small discrete action spaces and zero sum games. But language models are different.

In transformer based models we sequentially generate tokens based on training to mimic internet data. But anyone who has played with base models has seen we lose a tremendous amount of diversity in post training. This is widely believed to be due to mode collapse.

Well if not MCTS what else? Thanks to a technique called Twisted Sequential Monte Carlo, we can actually learn twist functions that learn to score and resample promising completions that might not have reward early on or might be the first reward getting completions we get early on.

One way to think about this is that we can always score a partial sequence by taking the probability weighted average of ALL possible future completions, but this is combinatorially impractical.

Twisted SMC learns to sample by scoring partial sequences with a twist function that computes sampling weights via a telescopic product of partition functions ending in a final one that could be computed by your reward function.

As an aside this has interesting connections with the path integral from physics where we sum over all spacetime trajectories weighted by a potential. Physicists use similar technique to do calculations where the path integral has no analytical solution like in quantum chromodynamics (QCD) which generally has no perturbative solutions.

In any case I was able to get Qwen1.5 B to sample more reward yielding sequences for GSM8K problems more effectively without training it. These were rewards developed in a now famous gist for GRPO.

What’s the catch ? It's very computationally intense but I like to think this makes this "bitter-lesson-pilled". In order to use this to train a base model you'd have to alternate between training the twist and then using the twisted SMC samples to train the model, which I was surprised just now to see a paper that does this (linked below).

Regarding the implications for safety research, more work would need to be done but twisted SMC shows we can potentially generate completions that are disfavored by the base model including potentially ones post trained out of the model so long as the model is capable of generating those completions at all.

I've implemented it as a HuggingFace Trainer although this probably wont work as is for other datasets besides GSM8K. I have not used their contrastive loss and have used an approximation for the twist proposal based sampling.

• https://github.com/smahsramo/twisty

• https://arxiv.org/abs/2507.02315

• https://arxiv.org/abs/2507.02315

• https://arxiv.org/abs/hep-lat/0702020 Discrete Feynman path integral image is from Colin Morningstar's review paper, who I worked with on this stuff as an undergrad years ago!

Special thanks to John Schulman for the fun convo that led to some weekend & evening hackery and research on my part.

The following is an attempt to give a geometric point of view on correlations that might change how you think about them. I hope you enjoy.

First, some needed background.

Correlations, Covariance, and All that

Let's now define the correlation between two random variables X and Y as:

Where

and,

Enter the Matrix

Now imagine instead of only two variables we had several of them. Let X = (X₁, X₂, ..., Xₙ) be a random vector, where Xᵢ for any i is a random variable.

We can define a covariance matrix as follows:

In matrix notation this becomes:

Note: Cov(X,Y) is something else called the cross-variance matrix.

What's important for us is that they have two special properties:

1. They're positive definite e.g. aᵀCₓₓa ≥ 0

2. And Cₓₓ is symmetric, i.e. Cₓₓᵀ = Cₓₓ

The first property (positive definiteness) can be understood as the variance of a linear recombination of the components of X. Variance is always non-negative. The second property shouldn't be surprising as the correlation of i with j should be equal to the correlation of j and i.

We can define the correlation matrix of n random variables X₁,...,Xₙ is the n × n matrix C whose (i,j) entry is

In matrix notation this can be written as:

Where X̃ = (X₁/σ(X₁), X₂/σ(X₂), ..., Xₙ/σ(Xₙ))

The correlation matrix is manifestly invariant with respect to affine transformations (any scale and shift) of the vector X as the mean is explicitly subtracted out of each element and the denominator of each element is explicitly divided.

So in other words:

Where X̂ is a unit vector with zero mean. Henceforth we will drop the ^ and element-wise this is.

Consider that as Xᵢ is actually a random variable to compute this we either need to gather a data sample to approximate it or without data we must consider Xᵢ(ω) as a function of elements ω in the probability space Ω in other words:

This is actually an infinite dimensional dot product (over a Hilbert "space" if that's your thing). This kind of leaves us in a bind and far from our goal of representing this as a vector dot product, but it turns out we can simulate this to arbitrary precision as the dot product of two vectors that will give us the same result.

There are two ways to do this:

1. To grab m data points sampled from the distribution

2. Skip that and actually decompose a concrete correlation matrix via the Cholesky decomposition

Introducing Cholesky Decompositions

It turns out every symmetric and positive definite matrix (like correlation matrices) can be decomposed into the product of a lower triangular matrix and its transpose.

So C = LLᵀ

Here, L is a real lower triangular matrix with positive diagonal entries.

If we have a vector ε with each element sampled independently from the standard normal distribution, by definition the covariance matrix will be the unit matrix on average.

However, if we multiply by L, Lε will have correlation C.

Since we're interested in these triangle inequalities, let's work with three random variables.

Consider three random variables X, Y, Z. We can write down their correlation matrix:

And break them down according to Cholesky.

Note that:

This is manifestly symmetric and with some work can be shown to be positive definite.

Applying L to our noise vector yields:

Because the different εᵢ are orthogonal in expectation we can express X, Y, Z as vectors.

Taking the various dot products we can confirm:

We can also confirm that they are indeed unit norms because we can just read off C as a function of the ℓs:

And that therefore they are cosines and not just dot products!

Now for the other side of the proof, we can compute the correlation matrix.

Since ε₁,ε₂,ε₃ are independent standard normals, we have:

E[εᵢ]=0, E[εᵢ²]=1, and E[εᵢεⱼ]=0 for i≠j

Let's compute Cov(X,Y)=E[(X-E[X])(Y-E[Y])]. Since E[X]=E[Y]=0:

Cov(X,Y)=E[XY]

Substitute X and Y:

Distribute:

Because ε₁ and ε₂ are independent and have zero mean:

E[ε₁ε₂]=0 and E[ε₁²]=1

Thus:

Similarly, we can compute:

By the same logic:

And for Corr(Y,Z):

Expanding and using the independence and zero-mean conditions:

To summarize, we proved that correlations can be viewed as dot products on a unit sphere, which naturally introduces an angle related to each and every correlation.

So from now one when you think of correlations you hopefully are imagining unit vectors on a sphere.

Now for bonus points, now that we know these correlations are secretly dot products of unit vectors on the sphere lets us use the usual triangle inequalities on metrics to construct closely related inequalities on the correlations themselves.

Triangle inequality demystified

We can now define a distance between two variables X, Y based on their correlation c_{xy}

which obeys the metric properties

1. θ(X,Y) ≥ 0

2. θ(X,Y) = θ(Y,X)

3. θ(X,X) = 0

4. θ(X,Y) ≠ 0 if X ≠ Y

Given that it's a metric we get the triangle inequality for free:

So in other words: θ(X,Z) ≤ θ(X,Y) + θ(Y,Z)

We can also see that θₘᵢₙ(X,Z) = |θ(X,Y) - θ(Y,Z)| and of course θₘₐₓ(X,Z) = θ(X,Y) + θ(Y,Z)

Given that, we can infer the min correlation max(c_{xz}) = cos(|θ(X,Y) - θ(Y,Z)|) and min(c_{xz}) = cos(θ(X,Y) + θ(Y,Z))

Writing this as a function of the original correlations (with some trig-jujitsu which I'll spare you):

It might seem simple to plug in your codebase into a state-of-the-art LLM, but LLMs have two limitations that make human-level assistance with code difficult:

1. They currently have context windows that are too small to accommodate most codebases, let alone your entire organization's codebases.

2. They need to reason immediately to answer any questions without thinking through the answer "step-by-step."

We built a chat sometime a year ago based on keyword retrieval and vector embeddings. No matter how hard we tried, including training our own dedicated embedding model, we could not get the chat to get us good performance.

Below is a typical example asked of the llama.cpp repo:

As you can see, the answers were oddly specific and seemed to pull in the wrong context consistently, especially from tests. We could, of course, take countermeasures, but it felt like a losing battle.

So we went back to step 1, let’s understand the code, let’s do our homework, and for us, that meant actually putting an understanding of the codebase down in a document — a Wikipedia-style article — called Auto Wiki. The wiki features diagrams and citations to your codebase.

This wiki is useful in and of itself for onboarding and understanding the business logic of a codebase, but one of the hopes for constructing such a document was that we’d be able to circumvent traditional keyword and vector-based RAG approaches.

It turns out using a wiki to find context for an LLM overcomes many of the weaknesses of our previous approach, while still scaling to arbitrarily large codebases:

1. Instead of context retrieval through vectors or keywords, the context is retrieved by looking at the sources that the wiki cites.

2. The answers are based both on the section(s) of the wiki that are relevant AND the content of the actual code that we put into memory — this functions as a “language map” of the codebase.

See it in action below for the same query as our old codebase chat:

The quality of the answer is dramatically improved - it is more accurate, relevant, and comprehensive.

It turns out language models love being given language and not a bunch of text snippets that are nearby in vector space or that have certain keywords! We find strong performance consistently across codebases of all sizes. The results from the chat are so good they even surprised us a little bit - you should check it out on a codebase of your own, at https://wiki.mutable.ai

We are introducing evals demonstrating how much better our chat is with this approach, more on this soon!

It has also been argued that corporations are already a form of AGI, doing more than any one person can do.

AI safety has been a much debated topic, which probably requires a Wittgenstein level of genius to suss out without more empirical evidence1. It’s very clear that even assuming we can create aligned AGI there will always be misuse risk. Even a completely obedient aligned AGI can be used for bad causes if wielded by a bad actor.

But wait a minute, don’t we have almost 500 years of history aligning corporations semi-successfully ?

The grand vision of Mutable.ai is simple:

To create “AI twins” of corporations (eg by wikifying them like our product auto wiki) as an on ramp to automating them, creating AI Organizations, and ultimately AGI; aligning them the same way we align corporations.

More on this soon.

BTW, Mutable.ai is coming out with a major upgrade to our product including a codebase chat that uses retrieval techniques that far exceed the effectiveness of vector embedding techniques and has infinite effective context length.

Auto Wiki is now free for open source partners, some conditions apply (you must be the owner of the repo), you can apply now by emailing info@mutable.ai with your repo name and Github user name

Open source projects often languish because it's too hard to understand the codebase and make contributions!

Gain an unfair advantage by making it easy for devs to understand your work.

Getting started is easy: simply visit wiki.mutable.ai, pick the repo you are interested in, and let our AI take care of the rest. Our new basic tier costs just $2/repo/month, and for a limited time you can use the coupon code XDOTCOM to generate them for $1/mo.

We made a number of improvements with your feedback in mind, including:

• Code diagrams, generated in Mermaid

• Filter and search for your wiki

• AI revision with instruction

• Manual edits to revise wikis

• Better underlying model

• Private repo support that follows the permissions of the repo

• Wiki is updated automatically every month and with each commit with our upcoming PR bot.

Please note you will only be able to edit a wiki if you’re a contributor or sponsor of repo.

Thank you!

PS Here are some more example v2 wikis:

https://wiki.mutable.ai/princeton-nlp/SWE-agent

https://wiki.mutable.ai/bitcoin/bitcoin

https://wiki.mutable.ai/karpathy/llm.c

https://wiki.mutable.ai/openai/transformer-debugger

https://wiki.mutable.ai/tensorflow/tensorflow

https://wiki.mutable.ai/Significant-Gravitas/AutoGPT

Full release video:

Jumping directly into the code without AutoWiki (the “old fashioned” way of understanding a repo) is slow going. There are hundreds of files in the repository. There is a readme and even a few videos to help me understand what is going on, but they only scratch the surface of the complexity here. Understanding this “raw” would be difficult even though this isn't a particularly large repository.

At this point, it's much easier to simply generate an auto wiki and use that to get my bearings.

At first glance, it appears that there is a backend that retrieves activations, explanations, and inference data, which is then visualized on a frontend. Sweet!

From here, we have a few options: diving into the backend or the frontend. I know OpenAI has mentioned that we can use it to ablate individual neurons and see what changes. Let's see how that might come about.

I used our filter to quickly find a section on the Visualization of Model Inferences and Node Metrics.

It seems like `AblateNodeSpecs` would be pretty important, so I'm jumping to that.

Jumping into the code, it seems like they have side-by-side panes with differing parameters corresponding to the ablation. Interesting...

Salmon is looking good btw, olive oil on low burn, this is way.

This piqued my interest in how they're displaying this info, so I'm going to check out this code and maybe later look at some actual demos they've put together (most codebases don't have demos going along with them!)

It appears there is a:

• Logits display

• Token effect display with color-coded tokens

• Node display

I can already sort of picture this without even seeing the demo.

Okay, my curiosity got the better of me. I looked up the demo and indeed, these are the three central components of the display.

I noticed in the first pass of the wiki that there is a section on "Natural Language Explanations" https://wiki.mutable.ai/openai/transformer-debugger#natural-language-explanations, so I am going to look into that a bit.

It seems to be doing this by:

• Generating explanations

• Simulating neural activations based on those explanations (using few shot prompting with examples of other explanations/activations)

• Scoring and calibrating the explanations based on how closely the predicted activations match the actual activations

Finally, there is some example data. Nice!

I read a brief description of each section. Scoring and calibration seem very straightforward to me, so I'm going to skip reading more on this for now and dive into the others.

Focusing on explanation generation, I'm going to look at the TokenActivationPairExplainer.

It seems like abstract builder classes, but upon scrolling down, I noticed that AttentionHeadExplainer has some more substantial content... interesting!

That prompt is very interesting and makes me want to see some of the input data.

Thankfully, we have a subsection on this here.

Going to explore ORIGINAL_EXAMPLES in few_shot_examples.py.

I now see how this data can create pairs that hydrate the prompt to generate the demo.

This would have taken me much longer otherwise, and the salmon looks ready now... time to eat!

We recently released Auto Wiki V2, which includes:

• Filter and search for your wiki

• AI revision with instruction

• Manual edits to revise wikis

Learn more about Auto Wiki v2 here. We have more updates coming very soon, including auto updating wikis that stay up to date as the code changes. Thanks for reading!

(Housekeeping note: Sorry for the long delay. If you haven't noticed, we launched a fantastic product called Auto Wiki. Auto Wiki converts your code into Wikipedia-style articles with citations, cutting time to fluency in a codebase by 50% and documentation time by 90%. You can see an example here: https://wiki.mutable.ai/unslothai/unsloth. I also promise to write “The AI Organization, part II”. My thinking has evolved significantly since that essay. I have learned so much since then from all the wonderful readers who reached out to me.)


1) In the ZIRP heyday of tech, people built software in a very ritualized way, copied from Google: we had OKRs, sprints, code review, PMs, managers, and of course, the almighty SWE.

Note: These things are not inherently bad and they helped create monsters like Airbnb.

There was some innovation, but many, like Tyler Cowen, rightly characterized this era as “The Great Stagnation”.

2) Then, after the COVID era, a meteor appeared: the OpenAI GPT series passed some utility threshold and a boom of products like GitHub Copilot and ChatGPT transformed how we work for the better. The future never seemed brighter.

3) But after the euphoria wore off, and especially with demos like Devin, people started to realize we will NEVER go back to the ZIRP era. Software as a field will transform fundamentally. Most software will be written by machines but will be managed by humans and there will be so much software to manage and understand. Very soon, companies will have millions of lines of code appearing every day that they do not really understand.

At Mutable.ai, we call this THE LEGIBILITY CRISIS. This lack of legibility is fragilizing. This is how the Romans lost their formula for concrete and why we haven't had manned moon missions in over fifty years. Complex technology is extremely fragile without a way to preserve it.

4) What's the solution? Something like AI jiu-jitsu, use AI to understand AI, like a snake eating itself. mutable.ai Auto Wiki converts code into Wikipedia-style articles with citations and graphs. This gives people a bird's eye view of their code and allows them to deeply and meditatively understand technology in a familiar format that preceded the AI boom. If AI chat is like asking a person a question, AI-generated docs are a restoration of the written word to its rightful place, the very thing that made civilization and indeed language models possible in the first place.

Our v2, which is coming early April, will allow you to easily view, filter, and alter the wikis with just a few easy commands.

The future is like the past, only better. We will build software in ways that would have shocked us even two years ago, but we will remain firmly in control, and the legibility crisis will have been averted.

I want to thank all our customers for supporting us, I want to thank all our early users, I want to thank the founding team for believing in our mission before it was clear we were on the right track, I want to thank our investors, in particular, I want to thank Nicolas Dessaigne and Anthony Goldbloom, I want to thank our friends and everyone who rooted for us. I love you all.

The future has never been brighter at mutable.ai. We have some very special announcements upcoming, and we're hiring! And we're also still onboarding customers on v2 of our wikis before they reach GA! Please feel free to contact me directly.

Thank you!
Omar, Founder/CEO

If your job involves coding or writing, change is coming: Large Language Models (LLMs) will change the way you work, and it may happen very quickly.

The consensus opinion now is that LLMs are going to be as important as the printing press1 or perhaps even the Industrial Revolution. Some are even saying it’s the end of the world as we know it.

Most of the discussion of AI today focuses on 1:1 interactions like ChatGPT, but we aren’t talking as much about how AI is going to change organizations. AI will dramatically enhance our collective communication abilities, and this will lead us to completely overhaul the structure of the corporation.

Throughout human history our technological development and scale of cooperation have been dictated by information and communication technologies2. LLMs erode many of the assumptions about information flow and coordination costs in the modern corporation. It's a bit like dropping cell phones into a classic movie like Home Alone... Morning Alone — it doesn't have quite the same ring to it. We predict an equally transformative evolution into what we call the AI organization. We humbly propose the following definition:

“

An AI organization is an entity that primarily uses AI to manage information flow within the organization and decide on team composition and function.

”

But before diving into how AI impacts organizations, we’ll first need to understand what corporations or firms are and how our pre-LLM communications technology grounds modern ones.

Why Companies?

Look around you — almost everything you see was created by a corporation. Why? One answer is legal: governments make it possible to create legal entities that trade and sell goods & services as one unit. This creates a convenient unit for human action, especially when dealing with taxes and regulatory requirements. But the legal explanation does not tell the full story of why the market has adopted this vehicle and not another.

What prevents us from operating solely as independent contractors, or conversely, working for a single all-encompassing entity such as a giant company or the government?

The economist Ronald Coase3 believed that transaction costs were the primary factor controlling the size of firms. For Coase, firms grow to the size where the cost of organizing an internal transaction in the firm (e.g. adding one extra person working to achieve a task) is higher than the same transaction on the open market (e.g. by hiring a contractor).

To understand this, Coase devotes a lot of time to understanding the following puzzle: Outside of a firm, market signals (i.e. price) seem to primarily guide decisions, while inside, human judgement (”management”) is the primary guiding force. Coase quotes economist Dennis Robertson’s description of firms in the sea that is the market: they are

“islands of conscious power in this ocean of unconscious co-operation like lumps of butter coagulating in a pail of buttermilk”

Organizations incur many transaction costs when they get help from entities outside the organization: it requires time to find the right outside organization or contractor, a well-defined spec of the work required, and, of course, time to negotiate contractual details. This is simply too much to do for every task, especially in the face of rapidly changing business needs.

Within a firm, these transaction costs disappear. There is a devoted talent pool with deep organizational knowledge, capable of doing iterative work with a flexible project scope and time horizon.

Of course, the catch is that when we make decisions inside a firm all the market signals are gone and we must rely solely on our judgement. Inside a firm, especially for the largest and most complex companies, it becomes very difficult for even the founders & owners to understand their own organization, and we are plagued by high coordination costs.

The modern corporation

In the past, limited communication and distribution networks constrained corporation size. If we asked a 18th century reader to look around them, it’s much more likely their possessions and services were NOT produced by a corporation.

Prior to the invention of the telegraph, information could only travel as fast as the fastest ship or horse, constraining the scale and degree of coordination a corporation could operate at. The British East India Company, while being the largest company of its time, was structured more as a collection of regional operations. Each operated with a significant degree of autonomy due to the difficulty of communication between different divisions. Transmitting information between London and Calcutta, for example, could take several months. It’s hard to imagine a product like the iPhone being created in these conditions - communicating the centralized vision of Apple's executive team with an international manufacturing operation would prove immensely challenging.

The telegraph made instant communication possible within a firm, and railroads ensured a distributed market to offer their services. The companies providing services like railways were among the first to rise to this unprecedented scale. The New York and Erie Railway was one of the largest railroad companies in the 1850s. However, its general superintendent, Daniel McCallum, noticed that they were much more inefficient than smaller railways. The telegraph had led to an over-reliance on centralized control. Could these companies maintain their economies of scale while also preserving some of the efficiencies of smaller railways?

To address this challenge McCallum invented the modern org chart, which organized staff in a hierarchy with fungible role types like ‘Superintendent of Road’ and ‘Brakemen’. McCallum gave more responsibility to divisional superintendents, which allowed them to focus on their divisions and effectively operate as if they were smaller and more efficient rail lines. McCallum’s invention flourished and created the modern corporation that provides so many of the goods and services we rely on today.

Scaling the modern organization

With the innovation of the org chart McCallum eased the tradeoff between scale and efficiency that many organizations face as they grow. This new ‘operating system’ for firms operates even more effectively in modern times by leveraging the internet, but the tradeoff between scale and efficiency has not gone away. Structures and processes that work very well at small scales are difficult to maintain at larger scales. Firms today are still plagued by problems arising from scale4.

This tradeoff is not unique to organizations and is also found in natural settings. Natural beehives are much more efficient than industrial ones, but they are impossible to manage at scale. Small farms are also more efficient per unit of land because they can grow various crops side by side - unfortunately, it is infeasible to scale them into industrial operations5.

Many readers will recognize how this dynamic plays out in organizations. Small organizations have the advantage that everyone knows each other. Every member can share context with every other member of the organization. Processes and projects can be very specifically tailored to the makeup of the team and the current situation the organization faces. It’s also easier to keep a small group aligned & motivated to take on an ambitious mission - hello, startups!

A large org on the other hand has more staff (this can scale pretty far, Amazon has over 1M employees, for reference ancient Athens had around 150k people) but suffers from high coordination costs6. Executives deal with scaling pains by creating a reporting hierarchy via an org chart. This system allows information to be encapsulated and sub-organizations to focus on their own objectives without the friction of needing to interact with every other part of the org. This parallels programming practices, where we routinely divide codebases into modules, selectively concealing information through encapsulation. Notably, at Amazon, the mandate for teams to interact exclusively via APIs is believed to have catalyzed the creation of AWS7.

In today's organizations, management decides team composition and function. Unfortunately, we often see unnecessary duplication and a lack of sharing of hard-earned knowledge between teams. And sometimes how we originally organize teams can quickly become sub optimal and not reflect an organization’s changing needs. This is where the power of AI comes into play.

History repeats itself?

Stepping back, we see:

1. Firms reach an efficiency limit and practical maximum scale (e.g. VOC or British East India Company)

2. A new communication technology emerges boosting firm productivity — the telegraph (and later the internet)

3. Firms struggle to integrate that technology into the old corporate structure (traditional pyramid structure)

4. The firm is refactored into new structure that allows it to fully utilize the new technology — what we have today: the org chart, OKRs, stand-ups, and so on up to a new scaling limit (e.g. Amazon today)

We predict a similar evolution today

1. Firms at a practical efficiency and scaling limit with our present technology

2. New communication technology emerges: Large Language Models, boosting firm productivity — You are (probably) here

3. The new technology (LLMs) is running on an old corporate operating system and not fully benefiting the organization — this is the Copilot model we see today — You (might be) here

4. Refactoring the firm with a new structure, the AI organization — We will help you get here

Making companies go brrrr: Why LLMs dissolve the assumptions behind the modern firm and the emergence of AI organizations

Here are some familiar characteristics of the modern firm:

• Formal org charts with well-defined roles and levels (e.g. PM, level 6)

• Cooperation between teams, especially those in different divisions, incurs high coordination costs. Two teams working on similar problems in different divisions, as a rule, don't talk and may only be vaguely aware of each other's work. It's interesting that at Google, the internal intranet search on its mono repo and document base functioned as a sort of mixer for the company because that was often the only way two teams working on similar topics could find out about each other.

• Technical personnel are often trapped in knowledge bubbles within their own divisions, unable to share their expertise with other teams facing similar problems.

• Use of OKRs to plan objectives and for teams to sync typically on a quarterly basis.

• Sprints and stand-ups within teams, going over basic facts about what they did and how close they are to achieving their objective.

As we’ll see, LLMs route around and reduce the need for every one of these.

> Formal org charts with well-defined roles and levels (e.g. PM, level 6)

> Cooperation between teams, especially in different divisions, has high coordination costs. Two teams working on similar problems in different divisions, as a rule, don't talk and may only be vaguely aware of each other's work.

Right now we’re hand-designing information flows and team structure. Instead, let’s use LLMs to share information between teams and help route important work to the right people.

• LLMs can summarize what work everyone does in an organization by parsing over their code, messages, and documents.

• LLMs in conjunction with other AI techniques can also identify common problems in an organization and rank them by severity.

• These models can then group the work of each team member by reviewing their code, messages, and documents, providing a comprehensive summary of their roles.

• We can then route important information to the right people in the organization who have the relevant expertise.

This way of organizing information effectively forms dynamic 'flash' teams that cut across traditional organizational boundaries.

>Technical personnel are often trapped in knowledge bubbles within their own divisions, unable to share their expertise with other teams facing similar problems.

By training LLMs on company code/docs and/or embedding company code/docs in a vector space we can capture institutional knowledge ('tribal knowledge') and spread it around the organization and safeguard it against loss due to personnel changes8.

> Use OKRs to plan objectives and for teams to sync typically on a quarterly basis

> Sprints and stand-ups within teams, going over basic facts about what they did and how close they are to achieving their objective

LLMs can breakdown objectives into tasks from all levels — executives, managers, engineers, or PMs — providing technical scope. This can occur continuously to ensure alignment. The need to ask "who should I approach for..." is eliminated and information that would otherwise be in an outdated wiki is continuously updated and readily accessible. As for executives, they receive a dynamic dashboard they can chat with offering insights into their organization. Meetings and stand-ups become less prevalent in part because you can interact with simulated versions of any team-member9.

So the AI organization will feature

• Universal dissemination of organizational know-how and context

• More fluid and less defined team boundaries.10

• Accelerated development and execution

What’s the catch ? AI organizations will likely give up on some degree of legibility such as having a well defined org chart, but already the biggest and most important organizations are difficult for their founders/owners to grasp. The shift towards the AI organization is the natural next stage in the evolution of organizations.

To facilitate this transformative shift, we've created Mutable.ai.

Introducing Mutable.ai: Empowering AI Organizations

To accelerate the emergence of AI organizations, we are building the foundation to support them, unifying how organizations communicate, build, and store knowledge on a single platform.

At Mutable.ai our mission is to build foundational AI tools that will accelerate the emergence of AI organizations. Our aim is to unify how organizations communicate, build and store knowledge on a single platform, all powered by the revolutionary capabilities of LLMs.

Given the central role of software creation in the global economy11, Mutable.ai is starting by helping software dev teams by building a multiplayer universal programming platform. Superficially, this will look like a unification of Slack, VS Code, and GitHub, but we aim to avoid vendor lock in and support integrations with your current tech (like GitHub) and also to include non engineers (especially PMs!) on day one.

Transcending Copilot

While the Copilot model is a valuable starting point, it doesn’t meet the prerequisites for supporting AI organizations: unified AI driven information flow linking all stakeholders. To paraphrase Henry Ford, Copilot built a faster horse and we're building a Ferrari.

We believe simply bolting on AI functionality to existing tools doesn't create the seamless work flow we’d expect in an AI organization. Working in a true AI organization will feel almost effortless - imagine ops firmly out of the way, programming overhead eliminated, instant access to information you need from across the entire organization, and support from the colleagues best positioned to make you more effective.

Mutable.ai, an AI native platform for AI organizations

So, instead of an AI copiloting the analog of an Airbus from the 70s, think of Mutable.ai as a Jaeger for your company, piloted by your team. This means shipping more features to your customers in less time, understanding what your team is building in real time, and fearlessly leveraging unfamiliar technologies without compromising the integrity of your systems.

To aid information flow within your organization, we're offering:

• A codebase chat to ask questions about your codebase as well as pull requests or commits, TL;DR — too long, didn’t review and soon we will expand to include your docs + messaging + your issues/ticketing system

• An auto wiki feature that serves as a living documentation of your codebase (and soon Notion/G-docs and Slack)

• An auto bug identification feature that identifies potential issues in your codebase and incorporates notes, issues, and active tickets and even suggests good people to investigate these issues — forming a sort of virtual flash team to solve your most pressing issues

• An auto stand up feature that serves as a snapshot and history of work across teams, utilizing all commits across company repos

We're also breaking down technical barriers and piercing knowledge bubbles:

• Embedding the entire company corpus (code + other information) and in some cases fine tuning on the company corpus

• Multi-file editing with natural language that is aware of your codebase

• Automated test generation, that is aware of your testing style12

These features come with privacy controls that give you complete control over how information is shared depending on role, team, and seniority. For example, execs will have a birds-eye view of their entire organization that will allow them understand what is happening at any desired level of granularity. The more information you put in, the better it will work, but you are in control of who sees what information.

Coda

It’s clear we’ve hit an inflection point in the history of the firm. LLMs and AI more generally will transform the modern organization as we know it. The AI organization, the next stage in the evolution of the company, holds tremendous promise to lower coordination costs and to increase firm velocity without compromising safety.

Just as one structure is being torn down, we now see the scaffolds of a grander future one. While we hope we’ve made it clear that this structure must exist, it’s not entirely clear yet how exactly it will look. In the coming months, we will do what we do best: talk to you, ship features, and provide more examples and case studies (perhaps featuring you!) about the structure of this new organization.

If you want to be the first organization to have its own AI-powered mecha custom-fit to your team, please reach out to info@mutable.ai. We’d love to partner with you. We’re a small but mighty team whose members were formerly part of organizations like DeepMind, Google, Stanford, and AWS.

Our new codebase app is out today, check out app.mutable.ai for sneak peak of this future.13

Best,

Omar Shams, Founder CEO

2

Although it is a long topic that probably deserves its own essay, it is worth pointing out that LLMs represent a fascinating "full circle" moment for language and communication technology. Any communication technology must pick a balance of expressivity and precision.

The highly precise and abstract languages of math and computer code have come to dominate technology — "Software is eating the world"ᵃ. However, with this specificity we have given up a good deal of transparency - code and variables are less intuitive than words.

Recently we have seen programming languages trending towards increased expressiveness at the expense of precision. This trend can be seen in the shift from assembly to C to Python. The advent of LLMs will supercharge this shift, allowing us to program with plain English.

Humanity has climbed a ladderᵇ starting from orally transmitted language towards increasingly abstract and capable languages. We have now come full circle, with LLMs that are able to operate natively in the languages we use to converse with each other.

[2a] With the notable exception of physical tasks, at least until robotics can learn in a more self-supervised way ("learn-to-plumb" is the new "learn-to-code")

[2b] Wittgenstein's ladder

6

Most organizations today are inspired by the corp system Napoleon invented that was crucial to the success of La Grande Armée. The most important feature of the corp system was that they were self sufficient armies that could achieve military objectives without support from another corp. Breaking down his army in this way was probably why Napoleon was able to move so fast relative to his adversaries. Speed is everything for startups.

The Prussians after getting their butt kicked by Napoleon developed mission type tactics, Auftragstaktik, that we’re so familiar today - you’re given a mission and some guidance, but you are expected to achieve the mission rather than follow an exact process at all times. Which is actually close to the analogy between asking an LLM to write a function versus writing it out yourself—won’t always get what you expect, but sometimes you’re pleasantly surprised.

Also, to state the obvious troops in Napoleonic Europe needed to be colocated to work together so even if an artillery officer from corp II, would be suited to help corp III with something, it wasn’t physically possible for them to work together if they were 50 miles apart. Physical constraints like this are much rarer today.

10

The breakdown in hand designed corporate org charts mirrors the shift in AI research away from symbolic AI and towards the dominant deep learning paradigm today. In "The Bitter Lesson," Rich Sutton argues that over the long run techniques which can utilize more compute to learn tend to outperform those with built-in specialized knowledge. This has been shown decisively by today's LLMs: deep learning's capability to be scaled up on massive amounts of compute and data ultimately led to vastly more intelligent models than symbolic AI ever produced. These models are typically less interpretable as they have less of our specialized knowledge built in.

We predict the same shift is coming for organizations. Replacing the role of human intuition and tradition in shaping organizations with data and compute may seem counterintuitive. It may lead to less interpretable organizations, with corporate structure derived from data rather than a clearly defined hierarchy. But the bitter lesson tells us that the gains in efficiency from the AI driven organization will be worth it.