If you liked this piece, you should check out:

• Specialty Tokens: your AI transformation practice. Get a free strategy audit to assess where AI could driven meaningful ROI to your organization.

• Supercenter.dev: The OpenRouter for sales tools, where you can turn your AI conversations into pipeline with real-time web data and account signals.

• Apply to a selective, non-commercial group for enterprise architects deploying AI into PE/VC/sovereign funds, international corporates, and across petabytes of data.

The next stage of company AI is not another chatbot. It is an owned software layer and org reshuffle that turns employee vibe-coded experiments into company infrastructure. We can call those builders “citizen-developers”.

Hey wake up, the smart kids are building AI gateways and owned software

I have seen this at three VC and PE funds, at two SaaS scale-ups, one bootstrapped and one venture-backed, and in the systems I have built for companies in the last 2 months.

Outside tech, people tend to think AI means ChatGPT and Claude. We’re finally growing up from that.

What makes companies build their own AI systems and software and why are companies doing this?

Because sovereignty compounds.

It’s the same reason the EU is doubling down on it’s sovereignty AI efforts. They want to own their own AI supply chain and be self-reliant.

By nature, this of course applies to the companies in the market as well.

They ALSO want ownership over their stack.

• They want to professionalize their internal insights and knowledge.

• They want their organization to produce it’s own intelligence on itself to create owned flywheels.

• They want to derisk and protect their IP.

• Their revenue opportunity (“secret sauce”) is transforming to become productized for AI systems and agents internally and externally.

• They want to reduce cost and create feedback loops that make the system better every time someone uses it.

If you’re not thinking about how to do this, you will not lead in your space in 24 months.

This is the messaging I see investors sharing with their roll ups and portfolio companies as users go more agentic and AI-default for their work.

The growth results speak for themselves.

Here is how this typically shows up as a problem at a company:

1. Employees open their preferred AI tool like ChatGPT or Claude (CoWork).

   1. If they don’t have access they shadow-spend and pull out a personal credit card.

2. They connect a few tools, vibe-code some software or an agent, build a skill and create something genuinely useful.

3. But it still lives with one person: their prompt, credentials, context, and a maintenance/continuous improvement problem. And if there’s no central team plan, it’s just data leaked.

4. Then they show it off internally, and the head of platform or data gets upset as the thing dies if its creator closes their laptop or goes on vacation.

5. Repeat.

6. Eventually, a Head of Platform/Data usually realizes - fuck - all the insightful learnings, skills, traces, knowledge/context buildup, projects, agents etc are floating. I need to clean this up.

7. Reshuffle begins → designates appointed AI leads per team, or internal FDE hit squad, and goes priority by priority across the org.

8. THEN they start building the system, sometimes all at once.

The companies getting serious either build or buy a shared layer underneath those experiments for the org

The others just freeze and procrastinate by spouting generic, lazy, anti-AI statements. Or saying “we’re not really there yet”.

The pro companies; here’s what they do:

• They run their own AI chat next to current AI subscriptions (for now) to a knowledge base, or interconnected company systems on a central “control plane” (just an integration hub with an MCP, skills, etc).

  • Some choose API pricing instead of subscriptions, or fine-tune and self host to protect data (ZDR: Zero Data Retention).

  • Which is also why you see labs pivoting to offering BYOC, while some enterprises flee to Chinese models (Looking at you AT&T).

• That control plane, or governed MCP layer, whatever you want to call it is then connected to all AI-chats for everyone via MCP:

  • It exposes internal systems with permissions (read, write, delegate, spend, etc.)

  • Routes requests through a model gateway

  • Connects those systems and runs agents + AI chat

    • Helping set them up, adapt, schedule, trigger.

  • Stores company context, knowledge, permissions, skills, and reusable workflows

  • Etc.

It’s the most important internal project right now.

There’s an underlying production path through this …

• Employees experiment during their “AI time” and build things that are useful for their role.

• Engineering takes the agent or project someone hacked together, professionalizes it, and delivers it back as software the company can actually run.

• Even in large organizations, this is unsustainable, which is why you see the introduction of roles such as the “Content Engineer”, “GTM Engineer”, etc. You almost need an AI Engineer per team at scale, and strong AI-native working knowledge per person.

That is the shift change happening in real-time at frontier minded companies.

This is also not net new.

This has also the standard for enterprise since the beginning of software, as a way to combat high seat based usage costs and create internal tools as company infra.

Once that’s been done, AI stops being a collection of personal chats and becomes a company software layer it can learn from, moving into evals, loops, observability, and self improvement opportunities.

The pattern is moving beyond just agents for workflows, too.

Companies are actively attacking their CRUD (Create, Read, Update, and Delete) apps and generic tools. They are not ripping out, replacing, displacing, their Systems of Record OR their CRM.

Instead of renting another generic interface, they can now easily build owned software around their internal systems and data, then pull in external information where it matters.

The whole objective is to own what’s critical, and have the AI systems in the org wrap around the employee activities.

So the new stack is just internal systems + MCP/API for external data access.

Examples of this

• Samsara is a clean example. Its marketing organization has shipped 90 agents, but it does not treat them all the same. Personal agents stay personal. Team agents are registered, checked against the right data, reviewed by engineering, and moved into production. The hard problem is no longer getting people to experiment. It is deciding what becomes infrastructure and who maintains it.

• Ramp is the clearest version. It built a semantic layer from dbt, Looker, and Snowflake metadata plus domain documentation, then put Ramp Research on top. Its GTM team repeated the pattern with Ramp Revenue: shared account context, playbooks, permissions, and actions powering a central coworker and employee-built tools. Ramp owns the knowledge layer, then keeps building agents on it.

I call these layers and builds AI-gateways.

Model routing is only the entrance to this whole project.

The category then expands into the place where company context, tools, agents, rules, and owned software meet.

Here are three useful ways in to do this for your company:

Build and own the environment. Cloudflare OS is an open-source company OS built on Workers, with shared context, skills, internal systems, and Gatekeepers for access. This is an easy enterprise grab.

Assemble from a developer stack. shadcncraft AI Chat gives you a complete Next.js chat surface and a Vercel AI Gateway starting point. Bring your own backend and build the company layer behind it. More startup/scale up focused.

Adopt a managed layer. Supercenter provides the context, integrations, permissions, agents, governance, and rollout support as a company platform. This is a buy and white glove service.

The build-versus-buy debate misses the point.

The choice is whether useful AI work and context stays trapped in a personal chat or gets a shared production path.

Anyway, the smart kids are choosing the second.

Thanks for your attention.

🤙

If you liked this piece, you should check out:

• Specialty Tokens: Your AI practice for strategy and implementation.

• Supercenter.dev: Prospecting on Autopilot with AI.

AI is entering its Made in China moment.

The United States invented the modern language-model economy.

China is learning how to manufacture intelligence at scale.

China does not need an uncontested lead for this to change the market. Its models only need to get close enough that price, control, and availability start deciding the sale. We are already there.

The Gap Is Small Enough to Matter

People keep describing the US-China model gap in months. Six months behind, then three, now one. I do not think that clock tells us much anymore.

The 2026 Stanford AI Index found that US and Chinese models traded places at the top several times during 2025. In March 2026, the top US model led the top Chinese model by 2.7%.

The United States still produces more notable models. The best closed model still leads the best open model. China also faces real limits in advanced chips and semiconductor manufacturing. A 2.7% lead can still be too small to justify a large price difference for ordinary work.

Stanford counted $285.9 billion in US private AI investment in 2025 versus $12.4 billion in China. That is a 23-to-1 gap. The report also warns that private-investment numbers undercount Chinese state-guidance funding, so there is no honest single number for total spending.

The United States spent far more measured private capital to hold a small performance lead. Scale, supply-chain pressure, and cost engineering now matter as much as who invented the category. That is what I mean by a Made in China moment.

Constraint Changed the Architecture

DeepSeek is the cleanest example.

DeepSeek-V3 had 671 billion total parameters, but it activated only 37 billion for each token. Its technical report describes a mixture-of-experts architecture, efficient attention, FP8 training, and infrastructure work designed together.

The famous $5.6 million training figure needs a large asterisk. It covered the official training run and excluded prior research and experiments.

DeepSeek did not respond to limited compute by pretending compute was unlimited. It redesigned the model around the constraint.

Moonshot did something similar with Kimi. Kimi K2.5 has one trillion total parameters and activates 32 billion at a time. Its developer-reported benchmarks need the usual caution. Most of the factory stays asleep for each token.

The hardware pressure is real too. US export rules still require licenses for covered advanced-computing products tied to restricted China-linked entities. Meanwhile, Huawei says it spent CNY192.3 billion on R&D in 2025 and deployed its 384-NPU SuperPoD across industries including finance, telecommunications, and electric power.

China still depends on foreign technology in parts of the semiconductor chain. Export controls have also made efficiency and domestic substitution national engineering priorities. The restrictions slowed access and gave Chinese labs a reason to redesign the stack.

Why Would You Use a PhD to Classify Things?

Most companies are still buying AI as if every task deserves the best intelligence they can access.

They use the same premium model to classify an email, extract an invoice number, match a customer record, summarize a call, review a contract, and refactor the billing system. Then they ask it to “do a better job.”

Why would you use a PhD to classify things?

The job is to structure intelligence economically across the company. Let a cheap model handle classification, extraction, routing, formatting, and first-pass retrieval. Use a specialist for a repeated domain task where your own data and evaluation can beat a generalist. Call the frontier model for deep audits, risky decisions, new architecture, and the occasional refactor that changes how the company works.

I already work this way.

Inside Conductor, I use faster models for design and quick iteration. I use Sol 5.6 for hard logic, long-running tasks, audits, and refactors. I often let one model write and another review, going back and forth between Claude and GPT models. Kimi sits in another lane, focused on design changes if I run out of usage on the others.

The switchboard matters more than finding one permanent winner. Models change. Good routing survives the change.

Cheap Models Still Need a Good Product

You cannot take the most intelligent model, drop it into a broken process, and tell it to do a better job.

You still have to decide which errors are expensive, when latency matters more than polish, when a task should escalate, what the model may touch, and where a person checks the work. You need memory, evaluations, permissions, cost limits, and evidence that the cheaper model can clear the task reliably.

Routing is a company-design decision with a model price attached to it.

The RouteLLM researchers showed that learned routing could cut benchmark costs by more than half without losing response quality. GPT-5 used the same structure: a fast model answered most questions, a deeper model handled harder ones, and a router decided between them.

OpenAI itself routed prompts instead of spending maximum intelligence on every request. Your own stack should be at least as deliberate.

The Correction

When GPT-5 arrived, a lot of us expected a world-changing discontinuity.

It was good, and I kept using it, but the sky did not open.

Technical progress continues. Stanford reports that models are improving so quickly that benchmarks are saturating and becoming less reliable. What has plateaued is the emotional return from another frontier release.

The top providers are clustering together, buyers have more alternatives, and “we have the smartest model” is becoming a weak reason to pay the highest price for every job. Buyers are asking what a model does inside a workflow and what that result costs.

Compute Is Becoming a Financial Product

In August, NVIDIA signed memoranda of understanding with Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs, and KKR for platforms intended to mobilize more than $500 billion for AI infrastructure. NVIDIA’s own language was explicit: compute is becoming an investable asset class.

Earlier in 2026, NVIDIA invested $2 billion in CoreWeave, a cloud company building AI factories on NVIDIA infrastructure.

Calling this 2008 again is too neat. The narrower concern is still real. The same ecosystem can finance a data center, supply its chips, invest in its operator, and then cite the resulting buildout as demand. Some of that money builds a real industrial base. Some of it may become reflexive.

Builders should avoid products whose unit economics only work while frontier intelligence is subsidized.

What Could Change the Market Again

Ilya Sutskever thinks AI is moving from an age of scaling back to an age of research. His concern is that current models generalize far worse than people and require too much data to learn. He points to continual learning as a missing property.

SSI has not released a model that solves this. It is a research direction, not a product claim.

Thinking Machines Lab is working on a smaller version that companies can use today. Tinker lets teams fine-tune open models with lightweight adapters while it handles the training infrastructure. A real continual-learning breakthrough would reset the market. Until then, companies can still teach an existing model one job unusually well.

The correction leaves builders with a less glamorous job. Start with one workflow, price it, and measure the cost of a bad answer. Send routine work to a cheap model, repeated domain work to a specialist, and expensive mistakes to the frontier.

If a cheaper Chinese or open model clears 90% of your workflow, is paying for the frontier model prudent insurance, or brand loyalty disguised as engineering judgment?

If you liked this piece, you should check out:

• Specialty Tokens: your AI transformation partner. A practice I run to audit, implement, and up-skill teams on AI across their organization successfully.

• Community: Apply to be a part of an active AI working group that is private, non-commercial, and highly selective, with members from Citadel, leading VC’s and executives at major corporates using AI daily.

I got a question from my colleague which inspired me to write this article.

I spend a lot of time on design, because good design signals care.

When you can show through your UI/UX or your craft that everything built was highly intentional, it will feel simple. By that nature, it will build trust before you start conversations with your target recipient.

In the age of slop, designs built with craft stand out more than ever. But not everyone may have the skills of a professional designer.

Below is a short article and a list of many resources you can use to build amazing designs to bring you above zero.

First it’s important to understand the design process.

It looks as follows:

If you don’t follow these 3 phases, I have found it’s difficult to get a good outcome, and you’ll face the blank canvas problem.

Following ‘the design process’ just means:

• Understand the viewer’s problem.

• Collecting inspiration and identifying why it works

• Experimentation and iterate

• Refine and implement

My thoughts and recommendations:

• Your AI designs will become infinitely better if you learn about design language, design grammar, standards etc.

• Frequently I find myself hunting the definitions of things I see (I do this by asking AI what something is called).

• This is why domain specific language and expertise is so valuable, so you can properly instruct this all knowing LLM.

Two points on inspiration

• Get on X, and make a design library.

  • Here’s how I do it: On X I save a lot in bookmarks and categorize them, then on Pinterest as well.

  • X:

  

  • Pinterest:

    

• Everyone should curate a ‘slap wall’. ^ This is a space designed to save and document interesting designs that you like. It becomes useful later so that you can cherry pick what you like and have a reference (to ask AI from). Here’s mine: Pinterest,

  • Occasionally I’ll peep over at Recent Design, Variant, Collect UI, and not long ago I found Origin Kit.

  • Cosmos is cool, but I don’t find it great for UI. More for -vibes-.

    • But they have an excellent resource of public works from art history to use. If you want that Cursor background ‘UI framed by art’ aesthetic.

• If your objective is product growth, choosing from a library of highly converting screens, you should look at Mobbin. Mobbin is both design and optimized for product marketing from leading applications. Note: they do have an MCP, so you can ask AI to reference Mobbin designs for a better output ($ It’s paid).

  • Here is a free alternative to Mobbin called LazyWeb, an A16z Speedrun company helping bring converting design interfaces to agents (an MCP).

• Third, I often like to create many variations of a design before I commit to it. I’ll ask AI: “Create 5 variations of the design with a switcher so I can look through them”. It will just reconfigure the components which makes it much easier and easy on compute.

• Next, make sure your foundation is on point. You’ll want a grid underlying your entire web page otherwise it won’t even look good (8 point grid system is common).

• Luckily, for design specifics, you can borrow skills from UI Skills from professionals (This itself is a curation).

  • Here’s a great checklist skill for designers.

• Following Designers and Design Engineers, will increase your eye for what looks good, and lower the barrier to imagination on creation. Some of my favorites are very active on X sharing their process and even have their skills and educational material published directly on their sites:

  • Emil Kowalski

  • Benji Taylor

  • Alex Vanderzon

  • Dennis Jin

  • Rauno Freiberg

  • Paco Coursey

  • Arlan Marlat

• Use a connection handoff or canvas between agents and designs. It allows you and AI to work closer together on a visual setting, with code x design.

  • I personally don’t use these as much because I like to design in code directly inside applications instead of experimentation on canvas, but these can be helpful when starting out a new idea:

    • Paper (#1 choice)

    • Figma (Meh)

    • Pencil (Ok)

    • Agentation (Ehh…)

• Here are some components libraries I use, these can be utilized by agents via code as “legos” to assemble design frameworks together (most of these are react, and I’ll make use of them on a site in Next.js x Vercel ecosystem:

  • Canvas UI (New update in web tech enables this. These are beautiful inspirations)

  • Smooth (Siri Orb is soooo nice)

    • Jakub Antalik’s Orb’s (Alternative to Smooth’s Siri Orb)

  • Interior (There is a brief moment in time after you interact with something on the web, that half tick moment helps manage emotion and state of users. Interior builds components for that moment.)

  • Skiper-UI (I actually don’t think that I have used one yet but I love the craft)

  • Fancy Components (Text component library)

  • Cult UI (Super high-quality ShadCN components)

  • Spell.sh (High quality designs, made for Design Engineers specifically - think Stripe fanboy/girls)

  • Toolcraft - Make in-house design tools or products

Some artists or designers are kind enough to make tools as a byproduct of their professional engagements, either for in house tooling for faster client work, or for clients. Here’s a great example by Algo TV, Jakub’s Metal buttons, & Arlan’s Vault which are a series of demos and small tools that are useful for your builds born out of client projects.

You will want an animation library.

Why? Well it’s important, again, to add motion and activity. Not too much though. Some references of helpful libraries. It’s more of a taste thing:

• Motion - (The OG)

• Anime.js (Fairly recent, but amazing for SVG transitions)

• Lochie (Go nuts on adding Haptics to mobile, which are normally blocked by the mobile OS)

The last item on the list I would add is sound. Sound can be an incredible haptic experience for users, but many may not like it. However, details such as completion noises, or tics, and dings can be beneficial in moderation. If you love hyper-reactive software, I use a mechanical keyboard simulation on Mac called Klack. It gives you an idea of how mouse clicks and button presses can be interactive.

Until next time!

🤙

Etc. links:

• Favorite website designs of mine lately:

  • Cognition

  • Paper

• Here’s an exhaustive list of resources for Design Engineers.

  • Tools

If you liked this piece, you should check out:

• Specialty Tokens: is your AI transformation partner. I run this firm to assess, train and implement AI and agents across your teams successfully.

• Community: Throw in questions and meet other readers in the chat. Learning and requesting new content together.

What happened this week in AI? Let me walk you through it.

This weeks releases looked disconnected: a moderation model, an enterprise-search experiment, a cyclone forecaster, two Chinese frontier models, a chip acquisition, a memory shortage, and a leadership reshuffle at Google.

Here are the eight updates worth knowing:

1. AI memory capacity for 2027 is reportedly already allocated

Image: DigiTimes.

DigiTimes reported that Samsung, SK hynix, and Micron have already allocated their 2027 DRAM and high-bandwidth-memory capacity. That’s insane. The suppliers are more careful than the headline. SK hynix says demand exceeds its supply capability and it has signed long-term agreements with about 10 customers. Samsung expects the shortage to deepen in 2027 and persist into 2028.

Cheaper inference does not mean the world uses less compute. It means we put AI behind more tickets, documents, databases, cameras, and devices. Unit costs fall while total demand climbs.

Why this matters at work: Your AI budget is not only a software budget, because capacity, latency, and vendor contracts can matter as much as the advertised price per token.

2. Mistral released a 3B model that guards models 7 times its size

Image: Mistral AI.

Shieldstral is a 3B open-weight safety model for text and images. You describe your policy in plain English at inference time, and it returns a safety score from one forward pass.

It runs on a single 16GB GPU. Mistral says it matches or beats open guard models up to 7 times larger across its evaluation suite.

The important part is not the benchmark. A team can run an adaptable moderation layer on its own infrastructure instead of sending every safety decision to another large hosted model.

Why this matters at work: Your company may be able to enforce its own rules around internal copilots, customer content, and sensitive media without paying a frontier model to review every interaction.

3. Neon and Castform trained a 4B model for enterprise search

Image: Neon.

Neon and Castform post-trained a 4B open model for agentic retrieval over company data. Their case study says the specialist can match or beat GPT-5.6 Sol on the target task while open models cost roughly 100 times less.

This is a vendor-authored result. The post does not name the base checkpoint or publish enough detail to treat the 100 times claim as independently settled.

But the architecture is useful: give a narrow, frequent job to a smaller model and escalate only the difficult residue to the frontier.

Why this matters at work: Always-on search across company knowledge becomes economically plausible when a cheap specialist retrieves the evidence and an expensive model is used only for the hardest judgment.

4. WeatherNext can forecast cyclones one day earlier

Image: Google DeepMind.

WeatherNext Cyclones predicts a storm’s track, intensity, and wind structure up to 15 days ahead. Across its evaluation, the model gained more than 24 hours of forecast accuracy on average. Its 3-day forecast was as accurate as what prior systems could provide at 2 days.

Google released the code and model weights, including a mini version that can run in a free Colab notebook.

This is not a nicer chatbot. It is another day to move people, equipment, and emergency crews around the world to prepare.

Why this matters at work: The best AI return may not be writing faster, but moving an expensive or dangerous decision forward while there is still time to act.

5. DeepSeek made agentic reasoning cost cents

Image: ARC Prize.

The DeepSeek-V4-Flash-0731 checkpoint is MIT licensed. ARC Prize independently verified its Max configuration at 89.0% on ARC-AGI-1 Semi-Private for $0.02 per task. On the harder ARC-AGI-2, it reached 61.4% for $0.04 per task.

Those prices apply to these evaluations, not every coding or research assignment. But cents per reasoning task changes what a team can afford to leave running in the background.

Why this matters at work: Cheap reasoning lets you run more first-pass analysis, testing, coding, and document review before a person or premium model handles the consequential exceptions.

6. Qwen3.8-Max sold a different picture of AI work

Image: Alibaba Cloud.

Alibaba launched Qwen3.8-Max as a 2.4-trillion-parameter multimodal model with 95B active at a time and a 1M-token context window. The company says it completed a 16-day autonomous coding project. The API is live, with open weights promised for the week of August 10.

The ranking needs precision. Qwen briefly appeared first on Artificial Analysis’s Agentic Index. After a grader and banking-benchmark update, the current leaderboard puts Claude Opus 5 Max first and Qwen tied for second.

The most interesting part was the launch film. People fish, climb, play tennis, and read while the agent works in the background. The official line is: “You live your life. It does the work.”

Why this matters at work: Knowledge work will increasingly be redesigned around what keeps running between meetings, not only around what a chatbot can answer while you watch.

7. AMD is buying a company that turns models into chips

Image: AMD Newsroom.

This is the biggest one I find most interesting. This week AMD signed an agreement to acquire Taalas, a company building model-specific inference silicon.

Taalas hardwires one model into mask ROM and uses SRAM for its working memory. Its HC1 demonstration chip holds Llama 3.1 8B and produces a company-reported 16,960 tokens per second.

The catch is flexibility. A major model update means manufacturing new silicon. The current chip is also a roughly 250W data-center product, not something going into your phone tomorrow.

Still, think about 4K video decoding. Dedicated hardware made a difficult computation feel almost free. Stable AI workloads such as moderation, translation, fraud checks, routing, and voice interfaces could follow that path.

Why this matters at work: Repetitive AI functions may become faster, cheaper, and more private, but executives will have to trade easy model updates for the economics of dedicated infrastructure.

8. Google changed AI leaders while the stack changed shape

Image: Google.

Google announced that Demis Hassabis is handing day-to-day control of Google DeepMind to Koray Kavukcuoglu. Hassabis becomes chair of Google DeepMind and Alphabet’s chief scientist, with more focus on AGI, science, and Isomorphic Labs.

Jeff Dean is leaving after 27 years to start Discovery Loop with Sanjay Ghemawat. Google will invest and remain a cloud partner.

Alphabet shares fell about 4% after the announcement. I found no credible evidence that Google kept Hassabis inside the company because it feared the stock would crash. The evidence supports a voluntary shift that had been developing for about a year.

Why this matters at work: Keep prompts, evaluations, and workflow logic outside one vendor’s model so a leadership or product shift does not strand the process.

The pattern underneath the week

This was not the week one model won.

It was the week intelligence moved another layer into the background: behind a safety policy, a database query, a weather warning, a coding agent, a routing decision, or a piece of silicon.

Most models are already good enough for a large share of knowledge work. The advantage will come from routing each job to the cheapest controllable system that reliably clears its quality bar.

Would you rather build on the best closed model through an API, or an open model that is slightly worse but cheap enough to run constantly and under your control?

If you liked this piece, you should check out:

• Specialty Tokens: is your AI transformation partner. I run this firm to assess, train and implement AI and agents across your teams successfully.

• Community: Throw in questions and meet other readers in the chat. Learning and requesting new content together.

The person leading data at a large, publicly listed media company told me they were doing a lot of internal AI education.

People were experimenting. Teams were building. In his words, “We get a lot of vibe coding.”

He wanted to go all in.

Then I asked a less exciting question.

Who maintains what they build?

How does a prototype make its way back into the real system? Who owns it when the person who made it gets busy, changes roles, or leaves?

The conversation changed. He was not resistant. He was overwhelmed.

At first I thought this was the familiar gap between an AI pilot and production. I no longer think that goes far enough.

The company did not have too few AI experiments. It was about to own more software than it knew existed.

AI removed the queue

For most of the history of enterprise software, building was expensive.

A team wanted a tool. It wrote a specification, found a budget, waited for IT or engineering, and eventually received something. The queue was slow and frustrating, but it also rationed how much software a company could create.

AI removed much of that queue.

A marketer can build a lead-research agent. Finance can make a workflow that drafts close commentary. Operations can connect a form, a model, and the CRM before lunch. A founder can replace five handoffs with one agent and a Slack message.

This is real progress. It is also a change in who produces software inside a company.

AI did not turn everyone into an engineer. It made engineering consequences available to everyone.

The moment another person depends on the lead-research agent, it is no longer a personal experiment. It is software. It has inputs, permissions, failure modes, users, and an implied promise that it will work again tomorrow.

Nobody has to call it software for the obligation to appear.

The bottleneck moves downstream

We can already see this inside software engineering, where the measurements are unusually legible.

A 2026 NBER study of more than 100,000 GitHub developers found that autonomous coding agents were associated with 180% more commits. The increase fell to 50% at the project level and 30% at the release level.

That is not evidence that the agents failed. It is evidence that they succeeded at producing more than the surrounding system could absorb. Code still had to be reviewed, integrated, tested, released, and attached to something users wanted.

OpenAI described the same shift from inside an unusually aggressive experiment. Its team built a product with roughly a million lines of agent-generated code in about one-tenth the time it estimated manual development would have taken. Then code generation stopped being the main constraint.

Human QA became the bottleneck.

The team’s response was not to tell the model to try harder. It made the environment more legible. Logs, metrics, tests, architectural rules, review feedback, and recurring cleanup became part of the system the agent could use. Human corrections were turned into documentation, tooling, or enforced rules.

That is the part most companies are missing.

They are giving more people the ability to create, but they have not built a place for what those people learn to go.

A company learns only when the correction survives

Imagine a sales agent drafts a follow-up using an outdated pricing deck.

The account executive notices, fixes the email, and sends the correct version. The customer receives accurate information. The immediate problem is solved.

But unless that correction changes the source, the instruction, or a test, the company has learned nothing. The next person runs the agent and gets the same mistake.

Now imagine the correction updates the pricing source, adds a check, and reaches every future run. The next account executive does not need to discover the same failure.

That is organizational learning in a form you can inspect.

The point of using intelligence at work is not only to create more output. It is to create new intelligence the company can use next time.

So I would measure AI productivity differently.

Not by the number of prompts, pilots, agents, or hours people say they saved. Measure how often a correction becomes reusable.

The model makes the first version. The company earns the second.

Every department is becoming a software team

On the morning of my conversation with the data lead, I spoke to a successful founder whose company was already using AI for commercial work: branding, websites, ads, emails, follow-ups, and similarity search for clients.

Those use cases are attractive because the result is visible. You can point to the page, the ad, or the lead list.

Operations are different.

An ad is an output. An operational workflow is a dependency.

The moment the company depends on it, someone has to know which system is the source of truth, what the agent may change, where approval happens, how failure becomes visible, and when the workflow should be retired.

That work used to sit mostly with software and operations teams. Now it is spreading into sales, finance, marketing, support, legal, and HR.

This does not mean every agent needs a committee. Central approval can become its own failure mode. Slow gates encourage people to build around them.

It means every company needs a faster path from personal invention to shared memory.

Airtable offers a useful counterexample to the idea that AI adoption has to be centralized. During a 60-day internal program, 435 of roughly 700 employees built production agents. The company says more than 200 workflows became agent-driven.

But “let everyone build” was not the whole system.

Employees spent the first two days mapping workflows before they touched the tools. Agents went into a shared registry so people could find and reuse what already existed. Outcomes were measured weekly. One person owned the program, and each function had a captain carrying lessons across teams.

The freedom produced hundreds of agents. The structure gave those agents a chance to become company capability instead of personal debris.

Put every pilot through the Monday test

The first builder proves that the model can do the job.

The second person proves there is a workflow.

The first correction that improves every future run proves the company can learn.

Before calling a pilot successful, ask five questions:

• Can somebody other than the builder find it and run it?

• Is one owner visible where the workflow lives?

• Can that owner see what it did and where it failed?

• Does a correction change the next run for everyone?

• Is there a clear way to pause, replace, or delete it?

If the answer is no, the pilot may still be useful. It is not yet organizational capability.

It is future archaeology.

The next AI race is a memory race

The next enterprise AI problem will not be an inability to build.

It will be an inability to know what has been built, who owns it, what it is allowed to do, what the company learned from it, and whether it should still be running.

The model race matters. Better models create new possibilities. But frontier capability diffuses quickly. Most companies will be able to buy access to similar intelligence.

The advantage is what happens after access.

One company fixes an agent’s mistake in a chat window and forgets it. Another turns that mistake into a better source, instruction, test, or permission rule. One repeats the same correction across twenty disconnected pilots. The other makes the correction once.

That is the living ecosystem I want when I talk about an AI-native company. Not a company with the most pilots. A company in which useful corrections have somewhere durable to go.

Your AI pilot worked. Good.

Now see whether it survives Monday.

Maintenance is not the boring part after the innovation. It is where intelligence becomes institutional.

Message Thomas

If you liked this piece, you should check out:

• Specialty Tokens: is your AI transformation partner. I run this firm to assess, train and implement AI and agents across your teams successfully.

• Community: Throw in questions and meet other readers in the chat. Learning and requesting new content together.

The executives I meet are not short on AI vocabulary.

They can tell you they use MCPs. Their people have Claude. Everyone has ChatGPT. There are skills. There is budget. There is an AI strategy.

Then I ask one question:

Tell me about one use case in each department that changed how you work and produced a return.

That is where the conversation changes.

Very often, the answer is not a workflow. It is a list of tools.

I recently spoke with a team that described broad access to Claude, MCPs across the department, and skills. They wanted a refresher on how to use it all. Once we got into the actual work, the picture was different. One person was proficient. There was no core builder. Nobody was sharing skills. Nobody was building end-to-end flows. Nobody was monitoring them. The only real organization-wide AI system was a set of shared accounts.

This is the bluff.

Not because the leaders are lying. Most are trying to keep up in a market that has made ignorance feel dangerous. They have absorbed the terms because they do not want to be the executive who looks behind. But knowing the words is not the same as changing the work.

AI adoption is not what you know. It is what people do repeatedly.

Buying seats is fine. Giving everyone access to ChatGPT or Claude is fine. It may even be the right first move. But a subscription is infrastructure, not transformation.

The companies getting value are moving from casual chats to repeatable workflows. OpenAI’s enterprise research describes this shift toward multi-step workflows, while Microsoft finds that culture, manager support, and talent practices matter more to reported impact than individual effort alone.

The useful part is not the model. It is the operating system around it.

For many companies, there is an uncomfortable sequence:

Digitize. Automate. Optimize.

You cannot hand off a process that only exists in somebody’s head, a spreadsheet maze, or five disconnected systems. And you cannot expect employees to discover and share reliable AI workflows if nobody owns the permission model, training, standards, or tools that make those workflows possible.

So what should an executive actually do?

Set a company-level intention. Be clear that this is not a novelty budget. It is an effort to redesign how work happens over the next one or two years.

Then make it real:

• Give one accountable person the mandate to find safe, valuable use cases.

• Give employees practical training and coaching, not a one-time product demo. BCG’s 2025 survey found regular use is higher where people receive meaningful training and in-person coaching.

• Create a place for skills, prompts, agents, integrations, and lessons to be shared (A ‘company brain’, Open Web UI, Supercenter).

• Establish governance and access so the right people can connect systems and build, without turning every experiment into a security exception.

• Start with work that can be handed off reliably, then monitor the result.

The metric I care about is simple: is the balance of work changing?

Are people consistently handing tasks to AI systems, reviewing the output, and using the recovered time for higher-level work, system building, and experiments? Or are they still doing the same work manually while describing how AI-native they are?

That is the difference between access and adoption.

The executive move is not to pretend to know every tool.

It is to make it safe for the company to learn, build, share, and prove what works.

Ask your leadership team the uncomfortable question:

Which departmental workflow has AI actually transformed, and who can show us the before and after?

If you like this kind of information, you should check out:

• Specialty Tokens: is your AI transformation partner. I run this firm to assess, train and implement AI and agents across your teams successfully.

• Community: Throw in questions and meet other readers in the chat. Learning and requesting new content together.

I vibe-coded - or “agentically engineered” - a product that crossed 16,566,304 uses this week.

Uses, not users.

One use is one completed dictation. The counter is closer to 17 million now, but that does not really matter. I’m keeping the number I saw when I started writing this.

I’m proud of it.

This is not promotional, so I’m not going to link to the product. The project was an experiment: how much of a real commercial product could I create with AI models, and how far could I take it?

The frontend. The backend. Authentication. Payments. The site design. A local inference engine. AI SEO/GEO. Programmatic marketing pages and real articles.

The application itself, three times.

Every part was AI-assisted.

I threw away the app twice

I’ve been practicing this way of building on different projects since 2023. This was the first one that worked end to end as a commercial product.

I started in February 2026 and built like a maniac.

The first version was Electron. I trashed it.

Then I moved to Rust for speed. I dumped that too.

The third version was Swift because I’m on a Mac. That one worked.

The benefit of building this way was not that the model produced perfect code. It was that code became cheap enough to throw away. I could dictate a change, let the agent update the feature, rebuild, relaunch, and use it almost immediately.

Electron and Rust were not wasted work. They showed me what version three needed to be.

The model that changed the build loop

For me, the threshold was Claude Opus 4.5.

It was the first model I used that could plan and execute across the codebase mostly reliably. It understood an Electron app well enough to work with a local AI engine. It could research technical options. It could sometimes tell me that an approach was a bad decision before I spent another day on it.

“Mostly reliably” is doing a lot of work in that paragraph.

Many times, the model told me a feature was done and complete when it was not. The code existed. The UI appeared. The agent sounded confident.

But the feature did not actually work.

I started calling these confidence hallucinations.

For every feature, I would do at least forty rounds of testing. Actual usage. Unit tests. Updating evals. Watching analytics. Finding the next thing that broke. Sending it back.

This was the job: hammering out the slop and refining it until the model’s declaration of “done” matched the experience of using the product.

Two recent research projects describe a version of the same problem. Building to the Test showed a coding agent reaching a near-perfect score while leaving part of the requested software dead or absent. DeepSWE argues that common benchmark tests can pass incomplete solutions.

The benchmark says it passed. The agent says it is done. Then you open the product and find out what is true.

Anthropic’s Opus 4.8 announcement even describes the newer model as less likely to let flaws in its own code pass without comment. That tracks with my experience. The models improved. The need to verify them did not disappear.

I did not know the stack

For most of this project, I had no idea what I was doing from a traditional technical perspective.

I understand UI, UX, and design. At the time, I did not understand the technology segment, the proper stack, or the software development lifecycle. All I knew was what I wanted the product to feel like and how it should work.

So my system prompts were often some version of:

Teach me why I should do this, how a senior engineer would do it, and when I should use it again in the software development lifecycle.

I was using the model to build and to teach me the terminology I needed to properly command my robot builders.

That does not mean the technical layer stopped mattering. It means I could learn it in the context of a live problem instead of studying it in the abstract and hoping I remembered it later.

My belief now is blunt: anyone who says you cannot create valuable software that makes money using LLMs is wrong.

I did it.

It did not make an impressive amount of money. That is not the point. People paid for it. They used it millions of times. That was enough to prove that this could become a real product instead of another demo sitting in a GitHub repository.

My real model benchmark

Every time a new model arrived, I switched to it and asked a practical question: what can I build now that I could not build last month?

Benchmarks are useful. But there is nothing quite like watching something that was previously impossible begin working inside a live product.

My prompts were usually long voice dictations. I would explain what I expected from start to finish, including how I wanted the interaction to feel. Then I would use the output, learn the proper term for whatever was wrong, and send the next instruction.

The useful model was not always the one with the highest score. It was the one that could survive this loop:

Dictate. Plan. Implement. Rebuild. Use. Test. Update the evals. Repeat.

The model supplied more of the execution over time. I still supplied the taste, the skepticism, and the definition of done.

Then code stopped being the bottleneck

Once the product worked, I learned a different lesson.

For this project, software became less about how much intelligence I could hide inside the code and more about whether the features showed that I understood the user.

I had rebuilt this product three times within 4 months. That made the feeling of using it more important, not less. I would rather spend my attention on the thing that makes someone want to keep using the product than on protecting an implementation I can rebuild next month.

And once implementation became cheap enough, distribution became the constraint.

I already had an audience of around 75,000 people, but I made fewer than ten posts about this product. Most discovery came from pages I generated around high-traffic key searches, supported by real articles I dictated.

The best search areas were related to AI models and local models running on-device. Qwen ASR was available through the product, for example. That brought visitors from Singapore and China who wanted a very fast local language tool.

The position mattered too. Privacy first. Local first. Your intelligence and data should be owned on your device.

I took a stand and wrote a manifesto around that belief. The product did not have to beat software market leaders OR hardware implemented market leaders like Apple, Google, or Microsoft. It just needed to be a credible alternative for the people who cared about local ownership.

That position gave the product a reason to exist alongside them.

What sixteen million uses actually proved

Usage is starting to flatten now. That is okay (I also stopped working actively on it in May - so less promotion).

I always assumed the large platforms would eventually move into this category. I learned new technologies, built something people paid for, and found a position that reached far beyond the small amount of promotion I gave it. I plan to release it as open source and let people create a thousand small versions for their own teams and use cases.

Sixteen million dictations do not prove that vibe-coded software is automatically good.

They prove that it can become good enough to be used millions of times—if someone is willing to keep testing after the model says it is done.

So yes, start. Ask the AI what to do. You will probably find a way.

But do not confuse the model’s confidence with the state of your product.

Use the thing. Break it. Test it again. Be a slop cop. Keep hammering out the slop until “done” is something the user can feel, not something the agent claims.

If you are building with agents, where do you draw the line between vibe coding and engineering?

Subscribe now

If you liked this piece, you should check out software I’ve built:

• Specialty Tokens a forward deployed engineering firm helping you go AI-native in less than 60 days.

• Supercenter is your AI coworker in Slack, just a ‘@’ tag away for end to end tasks.

• Resonant is a free dictation and meeting transcriber on mac for people who run things with their voice.

Today I used AI to make my own font.

When I was younger, I thought I could build a creative life for myself by designing fonts and websites. I loved the idea that the letters you read could be mine — that the shapes themselves could carry a little bit of me.

But fonts are incredibly challenging to make. That is a very, very difficult passion. Websites are hard too, but somewhere along the way they became much easier, mostly because of AI. So I ended up building software for companies instead.

This was the thing I pictured. And it had been sitting on my list for years.

So today I finally did it. Here’s exactly how — and how you can do it too.

Step 1: Write out your whole alphabet by hand

I picked up a marker and a sketchbook, and I wrote down every letter and number in the alphabet. Uppercase, lowercase, the digits, and a row of punctuation. One character at a time, sitting on the lines of the paper.

A few things that matter more than they sound like they should:

• Use one marker, and keep your letters about the same size. Consistency here is what makes the font feel like a font and not a ransom note.

• Leave real gaps between letters — a finger-width at least. That space is what lets the computer tell where one letter ends and the next begins.

• Sit everything on the line. Let the tails of letters like g, p, and y dip below it. That line becomes the baseline of your font.

That’s the whole “design” step. No software, no tablet. Just your hand.

Step 2: Take a photo

Then I took a photo of the sheet. That’s it. A straight-on phone photo in decent light — dark ink, light paper, no harsh shadows.

This is the part that still surprises me. The bridge between “some marks on paper” and “a real, installable font” is a single picture.

Step 3: Let the AI do the heavy lifting

Here’s where it gets fun. I handed the photo to AI and told it what I wanted. It went and downloaded the tools it needed, then flattened the image and extracted each character, using a series of Python scripts to turn my pen strokes into clean vector shapes — the math a font is actually made of.

It found each row, split out every individual letter, figured out where my baseline was, and traced the ink into outlines. When something looked off — at one point a whole row was coming out too big — it caught the bug and fixed it itself.

I didn’t write any of that code. I just described what I was after and watched it work. The thing I’d always assumed required years of specialized knowledge turned out to be a conversation.

Step 4: A couple of visual polishes

Real handwriting never repeats exactly. Write “mississippi” by hand and every s is a little different. So the AI added subtle variations of each lowercase letter and wired them up so repeated letters wobble naturally instead of looking stamped out.

Then it packaged everything into a proper font file and rendered a preview.

That’s my actual handwriting. As a font. Reading it back was a genuinely strange and wonderful feeling.

Step 5: Install it and use it

And then, just like that, I was able to install my own font. Double-click the file, hit install, and it shows up in every app on my computer — notes, documents, design tools, all of it.

The captions you’ve been reading on my video? Those are set in this font. It’s me, all the way down.

The part I keep thinking about

This was something I’d been putting off for years. I’d built it up in my head as this huge, technical, someday project. And I was able to do it in just an afternoon.

That’s the real story here, more than the font. The creative things we talk ourselves out of — too hard, too technical, maybe later — a lot of them aren’t that anymore. The barrier moved. The marker and the idea are still yours. The hard part in the middle is something you can now just... ask for.

If you’ve got a bit of handwriting and an afternoon, you can have a font that’s unmistakably yours.

Subscribe now

If you liked this piece, you should check out software I’ve built:

• Supercenter is your AI coworker in Slack, just a ‘@’ tag away for end to end tasks.

• Resonant is a free dictation and meeting transcriber on mac for people who run things with their voice.

  ---

If you are building on frontier models, your biggest platform risk may not be pricing, latency, context windows, or which lab wins the next benchmark.

It may be whether your country is allowed to access the best model.

The Anthropic Fable/Mythos situation made this obvious. Anthropic announced Fable 5 and Mythos 5, then days later suspended access after a US export-control directive. Claude also now has identity verification for certain capabilities and compliance checks.

That is the shape of what is coming.

The model picker will not just ask what plan you are on. It may ask who you are, where you live, which entity you work for, and whether your use case is allowed under a national security regime.

AI is becoming a national export.

Not in the clean SaaS sense. In the way chips, cryptography, defense technology, and advanced cyber capabilities become exports. The frontier model becomes strategic infrastructure. Access gets tiered.

The public gets one class. Verified users get another. Trusted partners get another. Labs keep private models ahead of what the public can touch. Governments get their own class.

This is bigger than one Anthropic incident.

The US leads on frontier AI. China is pushing hard through model labs, infrastructure, and open-source distribution. Europe is trying to answer with sovereign AI initiatives like Apertus, a Swiss open foundation model built by the Swiss AI Initiative with EPFL, ETH Zurich, and CSCS.

That project is interesting because it says the quiet part directly: countries do not just want AI products. They want foundations they can inspect, host, regulate, and depend on.

Most countries do not have that.

A sovereign AI foundation is not a chatbot with a flag on it. It is data center fleets, energy, chips, advanced networking, talent, capital markets, trainable data, and a regulatory environment that lets all of it operate.

That list eliminates a lot of countries immediately.

Even serving frontier models at scale is hard. Building them is harder. Keeping up with the next generation is harder again.

For builders, this changes the shape of platform risk.

We used to think about model dependency like a normal vendor decision. Is the API good? Is the pricing sane? Is the uptime reliable? Does it work inside my product?

Now there is a different question:

Can this model be turned off for me because of who I am, where my company is incorporated, where my users are, or what my product does?

That question was theoretical until it was not.

I have already been able to hack into my own applications using AI systems, even after using frontier models to help safeguard them. That changes how I think about access.

It is obvious why governments care.

These systems are not just autocomplete. They are increasingly useful at software engineering, vulnerability discovery, research, automation, and knowledge work.

The same capability that helps a defender secure a system can help an attacker find the weak point faster. The same model that helps a founder automate knowledge work can help an AI services firm compete with an entire labor market from another country. The same system that makes a startup more productive can make a country more strategically dependent.

This is why the export framing matters.

If frontier intelligence becomes a controlled export, then the gap between countries will not just be about GDP or university talent. It will be about access to the best reasoning engines.

Downstream countries and companies may still get AI. They may still get useful models. They may still build products.

But they may not get the frontier.

Or they may get it late. Or with guardrails. Or only through a trusted partner program. Or only if their identity, jurisdiction, customer base, and use case pass a compliance check.

That creates a new hierarchy:

• Lab frontier.

• Government frontier.

• Trusted partner frontier.

• Verified commercial frontier.

• Public model access.

• Open model fallback.

The important point is not that open models disappear. They will matter more. Apertus, Chinese open models, local models, and sovereign open-weight projects become strategic alternatives because they reduce dependency on foreign-controlled access.

But openness alone does not solve the problem if the performance gap keeps widening.

If one country has the best models, the data centers, the chips, the capital, and the right to decide who can use them, then intelligence starts to behave like nationally controlled infrastructure.

For builders, the practical takeaway is simple:

Do not treat frontier access as guaranteed.

If your product depends on the best available model, you need to understand what happens when that access changes.

• What happens if a capability is gated behind identity verification?

• What happens if non-US users cannot access the best model?

• What happens if a model becomes available only to trusted partners?

• What happens if the public version is intentionally behind the private, government, or lab version?

This is not a reason to stop building on frontier models.

It is a reason to design with the new reality in mind.

The next platform risk is not just that a lab changes its API.

It is that intelligence itself becomes a licensed national capability, and your startup only gets the tier your country is allowed to touch.

Subscribe now

If you liked this piece, you should check out software I’ve built:

• Supercenter is your AI coworker in Slack, just a ‘@’ tag away for end to end tasks.

• Resonant is a free dictation and meeting transcriber on mac for people who run things with their voice.

Kidlin’s Law

There’s an extremely brain dead way on automating anything, and it’s an old adage called Kidlin’s Law.

Kidlin’s law states that if you can name something and describe it specifically, you have solved half the problem.

Gratefully, we live in a time where we all have access to some of the most capable and intelligent programmatic minds given to mankind.

Here are the sequence of steps you need to take in order to automate almost any task.

Step one, download or open up your AI of choice.

Based on popular usage, I would recommend OpenAI’s codex for the streamlined route, Claude Cowork for the Professional Managed route and any other platform as a secondary option just because of the user experience in these below steps.

TLDR: Tell AI what you want.

Just kidding, a bit more than that.

Step one,

Open it up Open AI’s Codex:

• Go into automations

• Go to the top right corner.

• Press, create via chat.

• This will allow you to create an automation that runs at an interval or trigger every time Codex is open.

• To use your local compute credits from your pro plan.

• Until this is offered as a cloud service, you have to set this up locally.

Gif Guide:

Subscribe now

If you liked this piece, you should check out software I’ve built:

• Supercenter is your AI coworker in Slack, just a ‘@’ tag away for end to end tasks.

• Resonant is a free dictation and meeting transcriber on mac for people who run things with their voice.

From Coding to Operational Work

We have reached the point where coding agents are no longer just tools for writing software.

They are becoming practical enough to move into operational work.

This is a serious step change.

Previously, agents were impressive but fragile. They could draft, summarize, code, and automate pieces of a workflow, but they were expensive and brittle enough that most serious operational work still needed to be routed through humans.

That is changing. Frontier models are becoming more pragmatic and more capable, while the cost of running useful operational loops is falling. With models in the class of DeepSeek V4 Pro and other frontier systems, it is now possible to do real company work for pennies on the dollar.

That changes what a company is.

If you view a company as a series of inputs and outputs, the shape becomes much clearer. Inputs are inbound forms, calls, emails, texts, walk-ins, support requests, purchase orders, applications, tickets, and conversations. Outputs are delivered services, shipped products, completed tasks, materials, reports, approvals, responses, and decisions.

A company is a platform that transforms inputs into outputs.

And if a company is a platform, it can be controlled by agents in the same way software can.

The agent reads the input, decides what system state needs to change, invokes the right tools, asks for help when needed, and pushes the work toward an output.

This is why 2026 feels like the year where we begin to see more companies run by agents.

Not just chatbots on top of companies. Not just copilots beside employees. Agents inside the operating layer of the business.

There are already pieces of this forming around us: Polsia, Cofounder, Codex automations from OpenAI, Devin automations, OpenClaw, managed agents from Claude Code, Supercenter, The Company Company, and many more.

The important thing is not any one framework. The important thing is the direction.

The model and the agent capture maximum value like a whirlpool.

This is how the AI labs are designing their products.

The more work the model can absorb, the more value flows toward the model provider, the agent runtime, and the orchestration layer.

That pushes human value outside of whatever the agent can currently grasp.

Taste. Intuition. Emotion. Trust. Judgment. Relationships. Context.

The parts of work that are still hard to formalize become more valuable, at least for a while.

But inside a company, the agent will keep expanding.

By nature, it will try to grasp more. A workflow becomes a tool.

A department becomes a system. A system becomes an interface.

An interface becomes something an agent can operate.

Companies will become harnesses.

Departments will become harnesses.

Individual coworkers will become harnesses.

The question will not be whether agents can help with company operations. The question will be where the harness belongs, who controls it, and what human judgment is still kept outside the whirlpool.

🤙

To all the people I have copied throughout my education and professional career, I want to say thank you.

It is a great privilege to be able to learn from others. In many ways, that is the mother of all innovation.

This week, I was not copied, I was cloned. (🙄)

At first, I was salty. I felt protective. I felt like something had been taken from me.

But after sitting with it, I recognized how much of what I have created has come from the inspiration of others.

I literally keep notes, boards, folders, and screenshots full of ideas I admire. My product builds have been shaped by features I first saw somewhere else. My writing has been influenced by people whose work made me think differently. My taste has been built by paying attention to other people’s taste.

It is easy to be ungrateful. It is easy to feel like someone stole your idea.

But in the age of LLMs, the truth is becoming harder to ignore: most of us are aggregators of other people’s inventions. We remix, reframe, combine, imitate, and improve. Originality is rarely about creating from nothing. More often, it is about seeing connections others missed.

So if you have been copied, maybe there is another way to look at it.

You created something worth noticing.

You built something that drew enough attention for someone else to study it, borrow from it, and try to make something of their own from it.

That does not mean copying always feels good. It does not mean attribution does not matter. It does not mean people should take without care.

But it does mean your ideas are alive.

And if your work is inspiring enough to be copied, maybe that is not only a threat.

Maybe it is also proof.

Over and out.

P.S. Readers get free access to Resonant, which was used to dictate this article for you.

Subscribe now

Every big AI company, every AI lab, is becoming a product company.

A lab is just a place where you do R&D, create research, apply intelligence, and use that research to build products.

They’re moving from upstream intelligence to downstream application because of agents and integrations for brand protection, revenue opportunity, and experimentation.

Anthropic launched Claude Code, then Claude Design — a recent product coming out of the lab.

Every product gets its time to shine out of the lab before it loops back to feed model improvement data.

• OpenAI did the same: ChatGPT → Codex.

• Cognition Labs built Devin.

• Moonshot built Kimi.

• Runway opened Runway Labs.

• Google runs Google Labs.

• Gamma released an agentic product from their lab.

• Lovable runs the same shape, though theirs reads more like an experimental product surface than a declared lab division.

• Anthropic Labs is explicit about their framing.

Now flip it.

How do you design your own product so it builds the training dataset for your next model?

You’ve probably already seen it in Claude design where you have to approve or deny a specific item and give information as to why.

What does a lab-focused distribution center actually imply?

You’ve gone from model-first to experimentation-first.

Coding agents and agentic systems cleared so much headroom that big enterprises can now spin up dedicated spaces, test fast, and ship niche products or quirks — and keep the high-risk experiments away from the core business.

It’s easier to blame the lab for something that didn’t land than to risk the reputation of the firm. Case in point: the AI browsers from Google, OpenAI, and Perplexity, who all figured out they needed to remerge those browsers into super apps (or Computer’s).

From a business and investment angle, it’s just a pipeline of new products orbiting one flagship center.

A great way to experiment, find new streams inside the ecosystem, and push them to market.

Most companies have the same problem: they can’t distribute their software to market as fast as they can make it. It’s also why solo founders ship so fast. They build everything, worry about nothing, carry no internal friction, and sit directly on the problem.

In 2026, watch the word “lab” turn into a buzzword.

Treat it as a soft launch.

They’ve already run the thing internally — now they’re trying to build a category-leading product by bringing it out, often at the expense of a downstream or adjacent competitor.

There’s a second door, and almost no one is naming it.

The same friction that makes a firm build a lab makes its best people walk and rebuild the work outside, funded in months.

LeCun left Meta for AMI Labs. Goldie and Mirhoseini left Anthropic and Google for Ricursive Intelligence. Silver left DeepMind for Ineffable Intelligence.

The lab is a soft launch and a holding pen at once.

The holding pen has a door, and the venture money is parked right outside it.

Good luck.

I spoke to my friend at HatchWorks (and also a writer here on Substack) about what I’m up to with Resonant, past projects, and how building solo in the age of agents & AI has ‘changed the game’.

Highlights from the Episode

The real signal in dictation may be the edit, not the transcript.
One of the core ideas in the episode: the most useful data is not only what someone dictates, but the difference between what they dictated and what they actually sent. That delta reveals intent, hesitation, correction, and preference. Add in the app someone switches to next, and you start to see repeatable workflows: code task → Slack message, note → email, thought → calendar event. The corrections and transitions may be more valuable than the raw text.

Local-first is a distribution wedge, not just a privacy feature.
On-device dictation opens up customer segments that cloud-first tools struggle to serve: hospitals, medical staffing companies, firms with in-house models, and organizations with strict data boundaries. The point is not just that local-first is “more private.” It changes who the product can sell to.

Voice tooling could follow the Cal.com model.
The episode explores an open-source path for voice infrastructure: open-source the core, let organizations self-host, allow custom dictionaries and speech models, and monetize implementation, hosting, and support. Voice tools have mostly been SaaS so far. This would be a different distribution model.

Fully local still does not work perfectly yet.
A notable admission from the episode: five weeks were spent trying to make post-processing work fully on-device, but the quality was not good enough. Server-side inference was added as a fallback. The broader point: fully local AI is the direction, but for some workflows it is still gated by hardware and performance.

Taste can be systematized.
The episode breaks down a concrete design workflow: Twitter, Pinterest, and Hacker News as inputs; mood boards for taste formation; shadcn components for speed; and a custom AI skill that audits the interface against an 8-point grid, type scale, whitespace, and layout discipline. The model is prompted as if it works at Apple and Vercel. Less “taste is magic,” more “taste is a repeatable pipeline.”

Entrepreneur First advised the 2022 Berlin cohort not to build with AI right before GPT-3.5 took off.
One of the sharper stories: in the 2022 EF Berlin cohort, the advice was basically not to build with AI. Shortly after, GPT-3.5 changed the market. Four people in that cohort ignored the advice and built AI companies anyway. One reportedly sold for $90 million; another is now around $4 million ARR. The lesson is not simply “ignore advisors.” It is that even opportunity-spotting institutions can miss the biggest shift in front of them.

Learning to code took six failed attempts before agentic tools made it click.
The episode gets into the repeated failed attempts: courses, structured programs, and “proper” learning paths that did not stick. What finally worked was treating building as play. This is not just a vibe-coding success story. It is about tools finally matching the way someone actually learns.

Resonant’s website openly borrows from Cursor.
The design references are named directly: beige background, classical art, clean layout, and the general Cursor-inspired aesthetic. The interesting part is the transparency. Instead of hiding the reference, the episode treats it as part of taste formation: understand why something works, then adapt it.

The Ralph loop refactor started with an interview, not code.
A Frankenstein codebase was put through Codex in a “Ralph loop,” but with one key instruction first: the model had to interview the builder for ten minutes before touching the code. Only after building context did it begin the refactor. It then ported the project to Swift and Rust in roughly 25–30 minutes. The important detail is the interview-first step: force the model to understand the project before editing it.

The “show your hands” rule for video content.
A small but useful content principle from the episode: trust on camera increases when people can see your hands. The recommended framing is hips-to-head, hands visible, and screen content synced to what is being said. Simple, specific, and immediately testable.

The OpenAI tension is real.
There is a candid moment about seeing OpenAI as “Evil Corp” for a long time while still admitting that 5.4 is very good. That tension matters for anyone building a privacy-focused or local-first product: the long-term philosophy may point one way, while the best current model may point another.

Free beta plus inference costs creates a brutal loss-leader problem.
The episode gets into the economics of offering a free beta while paying for inference. The people who care most — privacy-maxis, local-first obsessives, and power users — can also be the most expensive to serve. The open question is where the paid line should sit.

The origin story starts with a police call.
At age 11, my mother called the police because she could not find me. I was in her office, script-kiddie hacking games. It is a specific, slightly embarrassing detail — and a better origin story than a polished founder narrative.

TL;DR

• Conductor.build is a free agent orchestration tool that runs Codex and Claude Code side by side on the same repo using subscriptions you already pay for.

• Parallel work trees ship features concurrently — no branch-switching, no stashing, no merge conflicts.

• Setup scripts auto-install and run your dev server per tree.

• Cmd+Shift+R runs a full code review before anything hits main.

• Five-tab cap keeps it sane.

• Replaces the IDE-plus-terminal sprawl with one window.

• Five-minute switch. Worth it.

Today I want to walk you through Conductor.build, because it’s been my primary environment for a few weeks now and I think it’s worth the five minutes it’ll take you to try it.

Conductor.build is essentially an agentic development environment. It’s used for agent orchestration (atm) between the two primary model providers — OpenAI’s Codex and Anthropic’s Claude Code — and it’s a free tool that the Conductor team released for the community.

FYI — it is VC backed for those who care.

One of the reasons it’s such a strong tool for work is because it takes you out of the IDE, out of the terminal, and into the “ADE” (Agent Development Environment) — creating a focus zone that feels very fluid and effective for agent-driven development.

What I mean by that is: you can easily jump between the standard settings of each model and provider you’re using, set the level of thinking, paste context across tabs, and run multiple agents in parallel without any of them stepping on each other.

How it works

You go to the Conductor site, log in with your GitHub OAuth, and start adding repositories. You can either pull from what you already have on GitHub, open a project locally, or do a quick start → Next.js is my typical stack, but you can go with something like gStack .. as they .. offer this?

When you’re ready, have added a repo, you can start to deploy agents from a workspace, each with their individual work trees. You’ll automatically use your existing subscriptions from OpenAI’s Codex plan and Anthropic’s Claude Code plan — nothing new to set up, nothing new to pay for.

The workspace, top to bottom

On the left hand side you can see the work trees that have been created from each workspace I’ve set up.

The small things that add up

One of the neat features is whenever I’m prompting → I take and add a screenshot, copy the entire message, paste it into the chat, and it’s entered as an inline item.

Now here’s where it gets useful: if I open up a new tab, I can copy that entire message and it brings the image with it as rich text. So if you’re going between five different tabs, using Opus for one thing and Codex for another, it actually carries that pasted-in element with you across tabs.

It’s a huge time saver, especially when running into errors where you need to reprompt.

Setup scripts are the real unlock

This is the reason I actually started using Conductor, aside from the nice UI.

You can go into Settings or hit Command-comma, then down to Setup Scripts, and enter your defaults. In my case that’s npm install for a Next.js project, and then a Run script — npm run dev. The reason I mention this is because if you make many work trees from that workspace, you can work on multiple files in parallel across different work trees, so features or major changes don’t conflict with each other.

But each one requires setup, and that’s where the run button comes in. When I create a new work tree — let’s say I call it “tianjin” — it creates that git work tree for me in real time.

Then on the right hand side I click the run button, and because I’ve set a setup script and a run script, it launches everything immediately. It does the install, runs the application, and opens up the site for me. Everything through that one button.

Underneath the running server you also have access to a terminal where you can put in further instructions, or even run other agents. So if I’m using Devin CLI or Kimi, I can do that directly from that terminal environment alongside the two main ones.

The review shortcut

Up in the top right you can see diffs as you make changes. In the top bar you have five different tabs you can run at any one time. You cannot go beyond five — that’s a design choice by the team and I think it’s a wise one, because when you get over three or four agents running in parallel, it’s hard to keep track anyway.

One more neat tool: Command-Shift-R opens a review feature by default. I have providers set up so my default model is GPT-5.5 thinking on low, and my review model is GPT-5.5 thinking on high. So when I hit Command-Shift-R, it’s a quick shortcut to review the entire workspace for that git work tree and do an audit on all of the code I’ve built. One keystroke, full audit, done.

When you’re finished with a branch you can either continue on it or archive the project directly. Archived projects stay available in Finder.

Why it’s the daily driver

Overall this application is very nice to use because it minifies the IDE into an agent development environment. I have chat, I have the ability to flick between different models, and there are these neat little tools — like Command-Shift-R — that make the loop tight. It respects the subscriptions I already pay for. It makes parallelism cheap, which is the change that actually matters. Most AI dev tools make one agent easier to use. This one makes many agents easier to coordinate.

I really enjoy using Conductor.build. It has been my primary environment since a developer friend told me to switch and took the five minutes to walk me through it. I want to give you those five minutes to show you why you might consider it, and hope that you do the same.

Most people think tech luxury looks like a new MacBook. It doesn’t.

Tech luxury is quieter than that.

It’s the absence of friction in your day.

It’s the small subscriptions stacked on top of each other that nobody notices except the person paying for them.

Here are the five.

1. You run Claude Code and Codex on Max plans. Both of them.

Not one. Both.

That means you have huge amounts of usage on tap.

You switch between the two without thinking.

You don’t watch the usage, the meter.

You don’t ration your prompts.

You don’t pick the cheaper one when the harder problem comes up.

You pay for the option to not choose.

That’s the luxury.

2. You use speech-to-text everywhere.

Your prompts. Your emails. Your docs. Your notes.

You stopped typing a long time ago. You use a tool like Resonant or something that captures what you actually said instead of what your fingers can keep up with.

The luxury isn’t the tool.

The luxury is that typing is now a choice, not a default.

3. You pay for Raycast.

Image search. Clipboard history. Snippets. Window management. AI commands. Quicklinks.

Ten apps collapsed into one launcher. One keystroke away from anything you need.

You used to have a folder of utilities. Now you have a command bar.

4. You pay for something like Obsidian Sync.

Eight, ten, twelve dollars a month. You don’t think about it.

Your knowledge base lives across every device you own.

Your notes from the phone show up on the laptop.

Your laptop notes show up on the iPad. You can publish a thought to the web without leaving the app.

The cheap version of this is free and broken.

You pay for the version that just works.

5. You have an autonomous coworker running while you sleep.

An agent. Hermes, OpenClaw, Devin, something you trust.

You hand it a task at night.

You wake up to a pull request, a draft, a research doc, a finished spreadsheet.

This is the newest one on the list and the strongest tell.

The other four make your day smoother.

This one makes your day longer without you being awake for it.

Thanks for your attention 🤙,

Thomas

After a few months of running both heavy, here’s what actually shook out — and why I now route work like a switchboard operator instead of a loyal customer.

My daily drivers are three: Opus 4.7, GPT-5.5, and SWE 1.6 from Cognition. Second tier is Kimi K2.6. Everything else, I don’t touch much right now.

But the more I work, the more obvious it gets: combining models is the move.

One-size-fits-all is over.

Codex Is the Clear Winner for Hard Work

I’ll just say it. I used Claude for all projects for months. But GPT 5.4 was good. Opus 4.6 was ehhhh.

GPT 5.5 is GREAT. Opus 4.7 is better than 4.6 but still meeeehhhhh.

After usage changes on Claude (5x max plan) I hit my limit, switched to Codex out of necessity, and it did the most complex task on the first attempt.

I stopped defaulting to Anthropic for everything.

Now my split is simple:

• Opus 4.7 — design, frontend, quick iterations, fast plans

• GPT-5.5 — logic, long-running tasks, hard tasks, deep audits, refactors

• SWE 1.7 — specific Cognition workflows

Both Opus and GPT-5.5 run inside Conductor, which lets you run multiple agents in parallel in isolated git worktrees. Conductor is where the routing actually happens for me.

The Conductor Default Reviewer Setup (cmd + shift + R)

In Conductor, I use cmd + shift + R and set Codex GPT 5.5 as the default reviewer.

Adjacent I have layered a skill — /auditcodex — which audits Opus 4.7’s work through Codex.

So Opus writes. Codex reviews. The fast worker gets reviewed by the thorough one. Cheap insurance.

This setup alone changed my output quality more than any single prompt change I’ve made this year.

Opus Is Still Faster — But Speed Is the Restraint, Not the Skill

Opus 4.7 is more efficient and works faster. That’s still true. And regardless of all the development sentiment Anthropic has been toying with — the mythos, the usage rate drama — it reminds me of what happened with Cursor after pricing and usage changes (because coding subsidies are v-high).

Compute is the restraint. Not intelligence.

That’s why Anthropic is now partnering with SpaceX for over 220,000 Nvidia GPUs at the Colossus 1 data center, doubling Claude Code’s five-hour limits, and lifting peak-hour throttles on Pro and Max. They’re scrambling to give users back the capability they quietly took away.

I’m on the 5x Max plan. I’ve never hit a usage limit on Codex.

That sentence is the entire essay if you want it short.

Codex Doesn’t Overbuild. Opus Doesn’t Know When to Stop.

This is the deepest difference, and the one nobody talks about enough.

I built a local dispatch feature using my voice. Only Codex was able to do it, review it, test it with me, and build a thorough eval around it. Claude.ai just made a sloppy mess and kept building more and more features that went nowhere.

Codex told me when it was good enough and when to stop. It was firm about its language. Opus would just keep finding things to build.

Authentication. Payments. Backend. Database. Deep searches. All Codex now. It searches better and it’s more thorough. I built a personalized cache and recommendation system around frequently used dictation words — Codex one-shot it after Opus had made a mess of the same problem.

If you can give GPT-5.5 the right context and material, I’m confident it solves problems. Especially hard ones. That’s what “AGI” feels like in practice — not a benchmark, just a model that says this is done and means it.

Low Thinking Codex Feels Like Claude. Use That.

Here’s a tip almost nobody is using: run Codex GPT-5.5 on low thinking when you want fast, non-overthought iteration.

When run like this it feels a lot like Claude.

It doesn’t overthink your code. If you want a single model for fast and slow work, this is the closest thing. High and extra-high thinking are for the hard stuff. Low is for the speed lane.

Different gears in the same car.

I’m Using and Writing Skills That Pair Models

This is the next move.

Skills that route work between models automatically.

Claude is good at design, writing, fast work. Codex is good at backend, auth, logic, payment systems, deep reviews. Why force one model to be both?

I think over time, outside of skills, there’s a real place for a team of models working together on a task instead of one big model trying to do everything. Combining open source, smaller models, frontier models. Each in its lane.

The benchmark era is ending. The orchestration era is starting.

My favorite skill: auditcodex

What This Tells Me About the Market

We’ve hit a maturity point where competition is genuinely good for developers. The labs are head-to-head.

Nobody has a permanent moat. Aura shifts month to month — Opus had it, then 5.5 took it, and Anthropic will probably leapfrog again.

The Setup, in One Block

For anyone copying the workflow:

• Opus 4.7 — frontend, design, anything that touches UI, fast plans, quick iterations

• GPT-5.5 (Codex) — backend, auth, payments, database, deep search, audits, refactors, hard logic, long-running tasks

• Conductor — runs both in parallel, isolated worktrees

• cmd + shift + R — Codex as default reviewer

• auditcodex skill — Codex audits Opus’s work

• GPT-5.5 on low thinking — when you want Claude-feel speed without the overbuilding

Stop asking which model is best. Start asking which model is best for this job, right now.

This is the first piece in a series I’m calling Lazy Leverage. Five skills worth learning now.

Read it slowly.

If you read this newsletter, you’re past the AI-skeptic phase. Your boss is pushing it. Your team is adopting it. The argument about whether to use it is over.

The interesting question is what you do once you’ve arrived at this point.

Here’s the frame I’d offer:

Humans are the last mile of LLMs.

Last mile, in logistics, means the final delivery stretch. The expensive part. The part that doesn’t automate. That’s the position humans now hold relative to language models. The model handles the bulk transit. You handle the last few feet.

The last mile is the quality layer. It’s the orchestration. It’s the refinements that other humans relate to because a human shaped them. Models can produce volume. They can’t yet produce the finish that makes another person trust the work. That gap is the job.

There’s a related shift worth naming. Software engineering has always had a property most professions lack: all related work context arrives upfront, you research, test, loop.

AI is what gives every other profession that same property. Marketing, sales, operations, legal — none of them currently have that loop. AI makes it possible by pulling context together, triaging events, taking action across tools.

Which means software itself is changing shape. The pattern emerging looks like three layers: interfaces, language models, and skills. The interface is how a human or another agent reaches in. The model is the engine. Skills — markdown files containing instructions, references, and procedures — are how the model knows what to do in your specific context.

Skills can be better than scripts because they’re self-healing.

A script does only what you told it. When the world changes, the script breaks. A skill is different. The skill says what. The agent reading the skill figures out how under current conditions.

The agent brings judgment the code can’t. That’s why skills compound while scripts depreciate — the script is locked to the world it was written in, the skill navigates whatever challenge is current.

The five skills below describe what the last mile looks like in practice.

People are becoming architects and orchestrators. These are the skills of that role.

1. Managing morphing systems

The skill: designing systems you expect to remake. Building structures with the assumption that the tools, models, and inputs underneath them will change before the structure does — and treating that ‘churn’ as a feature, not a failure.

Most knowledge work is a chain of triggers. A thing arrives — a ticket, an email, a PDF, a Slack message — and you run a procedure on it. Sometimes the procedure is a checklist in your head. Sometimes it’s an automation. Sometimes it’s a handoff.

AI keeps breaking those procedures. A new model lands. A new tool ships. Last month’s system is now wrong, and the system you build next month will also be wrong, on a shorter timeline.

The skill is being willing to repurpose what you built without grief.

That’s harder than it sounds. People get attached to work, especially work they did well. The morphing-systems mindset asks you to treat last quarter’s pipeline as parts, not architecture. The structure can be rebuilt. The pieces inside it carry forward.

This sets up a tension that skill five resolves: how do you stay willing to remake systems while also building things that compound? The answer is that the structure morphs. The pieces inside it — the prompts, the skill files, the workflows — don’t. We’ll come back to that.

📌 Try this week: pick one workflow you’ve built. Ask “what would change if a new model could do 80% of it natively”. Don’t act on the answer. Just notice how attached you are to the existing version.

2. Orchestrating agents

The skill: directing multiple AI agents working in parallel toward a shared outcome. Giving each one a clear brief, watching their outputs, and managing the loop between them so the bottleneck stays on direction rather than execution.

Codex, Claude Code / Cowork, Devin — coding agents have gotten so good at programmatic efforts and reasoning (coding), they’ve now crossed into operational work. Context windows keep expanding. Models keep getting smarter. The agents will keep absorbing more of the day.

The skill is running several at once. Five panels, five tasks, you on top.

This sounds counterproductive for deep focus. It is, until you know your objective well enough to delegate cleanly. Then it stops feeling like multitasking and starts feeling like management. The bottleneck moves from execution to direction.

Direction is harder than people expect. Most of the difficulty in delegating to a junior employee is the same difficulty that shows up here, just compressed. Vague brief, vague output.

Specific brief (with real examples) = useful output.

A working definition: an agent is an LLM + tools + an environment.

The environment can be your laptop or a server somewhere — it matters less than people think.

What matters is the loop:

• How does the agent receive a task?

• What tools can it reach?

  • Can it touch or ‘see’ the right systems?

• How does its output get back to you?

📌 Try this week: line up two agents on adjacent parts of one task. Watch where you become the bottleneck. That’s where your next skill file needs work.

3. Thinking like an architect

The skill: planning the structure of a system before building any of it. Defining how the pieces fit, what each one is responsible for, and what could replace it — so that when execution gets cheap, the design is what determines the quality of the result.

Read more

I make content for 70,000 people a week across socials running a creator business in tech and by extension…AI. But the number keeps climbing up, as does the bar for quality. In order to educate and serve at that scale, I have to optimize where I can.

This is where I optimize.

Five tools. Daily use. Each one survived the cut against dozens of others.

1. Conductor — conductor.build

The modern agent orchestrator. Five tabs open at all times, work trees running across multiple projects, depending on the tasks at hand. The interface is minified but unified. Every pixel points at shipping.

If you’ve tried wrangling Codex and Claude Code from a terminal and a dozen tabs, you know what Conductor solves.

Cost: free.

2. Resonant — onresonant.com

Resonant is the voice layer for work. Every dictation, every meeting, with one context point for agents.

I talk to my devices instead of prompting or typing. Resonant catches the thinking and makes it queryable through MCP or API.

I built it. It turned into a larger project. Free on Mac and Windows. Whisper Flow and Granola had a baby → except it doesn’t train on you and stays private.

I stopped typing a long time ago, and I use my voice for absolutely everything. As you can see in the image, it saves me a lot of time.

Cost: zero, if you don’t count what I spent building/managing it.

3. Tella — tella.tv

I make a lot of videos. Brand work, client demos, async explainers, screen recordings that have to look like I cared. Tella cuts edit time to almost nothing. Horizontal, vertical, demo, share link, done.

Loom without the production tax.

Cost: $26/month.

4. Devin — devin.ai

End-to-end autonomous software engineer. Devin indexes the codebase, takes the task, completes it, tests it, and hands back a wiki.

I give it the long-horizon work I’d otherwise put off. Ports. Security reviews. Auth tests across a full workflow. Refactoring sloppy agentic code into proper modules and interfaces.

It also handles PR reviews on GitHub, bug fixes, and runs multiple sessions in parallel. That last part matters. It makes Devin almost as efficient for me as Conductor — same compounding effect, different surface.

Latest models. Token-efficient. Ships.

Cost: just dropped from $500 to $80/month.

5. Supercenter — supercenter.app

Somewhere between SaaS and a service. Enterprise MCP for organizations fighting shadow AI. Every employee gets governed, permissioned access to email, Slack, internal systems — with agents and delegations included. Nobody gets locked into one AI ecosystem.

For me, it’s the layer that travels. I hop between projects and my skills, connectors, and context come with me through one connector.

Cost: free, while it’s in testing.

Underneath all these five:

• Claude Code and OpenAI Codex Plus. $100 each, every month.

• Almost everything I do runs on one of them.

That’s a wrap.

Subscribe now

You maxed out Claude Code.

Or OpenAI Codex.

The cursor blinks and nothing happens.

You get the dreaded - “you’ve hit your usage limit, wait until XX:XX” message.

Stop paying for overages.

Use free inference instead.

Option 1: OpenRouter

Go to openrouter.ai. Click Rankings.

The leaderboard shows what people are actually using right now. New models land there constantly. Many are free.

Qwen, for example recently shipped free inference in exchange for coding data for their new model releases (yes even free has a price, advised only for personal projects). Others do the same.

Pick one. Sign up for an account, get an API key, copy the model ID.

Plug it into your harness.

Cursor, OpenCode as an examples.

Option 2: Nvidia (🐐)

This is the one people sleep on.

The world’s largest inference provider gives you 80 hosted models for free. Serverless. No infra. No credit card friction.

That should tell you something about where the market is going.

Setup takes four minutes

1. Create an account. Go to build.nvidia.com. Sign up.

2. Open API Keys. Create a test key. Copy it.

Go to Models. Filter by Free Endpoint.

You’ll see the good ones:

• GLM 4.7

• Nemotron

• Minimax 2.7

• GLM 5.1

• Gemma

• Devstral from Mistral

All free. All serverless. All ready.

Wire it into your editor

Works in OpenCode. Works in Cursor. Works in Conductor.

Read more