I have a finance repo.

I have a marketing repo.

That would have sounded strange a few years ago. GitHub was where code lived. Engineering work went into repositories. Everything else lived in Google Docs, Notion, spreadsheets, Slack threads, decks, and the hazy memory of whoever happened to be closest to the work.

But that is not really how I am running Alma anymore.

Alma is a small company, so the operating system has to be lightweight. I do not want a giant process layer. I do not want every idea to become a meeting. I want the company to be able to think, ship, measure, and adjust quickly.

Increasingly, that means turning more work into artifacts that can be created, edited, reviewed, versioned, and reused by AI agents.

The marketing repo can hold campaign briefs, ad variants, landing page copy, experiment readouts, lifecycle emails, creative concepts, and positioning notes. The finance repo can hold investor updates, scenario models, pricing analysis, monthly metrics, fundraising narratives, and board materials. The product repo can hold specs, research summaries, rollout plans, and feature decisions.

Some of this still ends up in apps. A spreadsheet may become an .xlsx. A landing page may become React. A campaign may go live in Meta. But the working layer is increasingly file-shaped.

And once work becomes file-shaped, it starts to behave more like software.

It has history. It has authorship. It has diffs. It has branches. It can be reviewed. It can be reverted. It can be connected to what shipped.

That is the part I cannot stop thinking about.

GitHub as a Productivity Proxy

The GitHub contribution graph is imperfect, but it reveals something real.

If someone is deep in the weeds of building, the graph usually shows it. Not because every commit is valuable. Not because more green squares automatically means better work. But because sustained contact with the system leaves traces.

Commits show cadence. Pull requests show collaboration. Diffs show what changed. Issues show what got noticed. Deploys show what made it into the world.

In an AI coding world, this becomes even more important. If a builder is using Claude Code, Codex, Cursor, or whatever comes next, the output still has to land somewhere. The agent can write code, but the repo records what changed.

The contribution graph becomes a rough proxy for something deeper:

Are you repeatedly changing reality?

That question is not just for engineers.

The Marketing Commit

Imagine a marketer working in the same kind of loop.

Not “I made some posts.”

More like:

• drafted 20 ad hooks for a protein campaign

• launched 4 landing page variants

• rewrote the onboarding email sequence

• created a new creator outreach list

• shipped a testimonial campaign

• wrote the readout on what converted

• killed the losing angles

• doubled down on the winning one

Each of those can be an artifact. Each artifact can live in a repo. Each change can have a commit.

The point is not that GitHub is magically the right interface for marketers. Maybe the better version is Notion with real diffs. Maybe it is Linear. Maybe it is a new tool that looks more like an operating system for AI-assisted work.

The important idea is repo-like work:

1. The work is durable.

2. The work has history.

3. Changes have authors.

4. The reasoning is inspectable.

5. Artifacts connect to outcomes.

That last part matters most. AI will make artifact creation cheap. The scarce thing will be closed loops.

The future marketing graph should not measure how much content someone generated. That will be too easy. It should measure how often they moved an idea through the full cycle:

hypothesis -> artifact -> launch -> measurement -> learning -> iteration

That is the marketing equivalent of a commit that matters.

The Finance Commit

Finance has the same pattern.

A finance repo sounds odd until you realize how much finance work is versioned reasoning.

What changed in the forecast? Why did the runway assumption move? Which pricing scenario did we believe last month? What did we tell investors in March? How did the board narrative evolve? Which model drove the hiring decision?

In most companies, the answer is scattered across spreadsheet copies and Slack messages.

In a repo-shaped system, the finance work has a trail:

• models/may-runway-scenario.xlsx

• pricing/annual-plan-sensitivity.md

• investor-updates/2026-05.md

• board/series-a-narrative.md

• metrics/revenuecat-april-summary.md

The value is not that everything becomes public. The value is that the company can see how its own thinking changed.

That becomes especially important when AI is helping generate the first draft of the model, summarize metrics, write the investor update, or compare scenarios. The agent accelerates the work. The repo preserves the judgment.

The Consequences

If this pattern spreads, it changes how we understand productivity.

The old proxy for knowledge work was presence. Meetings attended. Slack responsiveness. Docs created. Decks delivered. A lot of it was hard to inspect from the outside.

The new proxy might be artifact movement.

What did you create? What changed because of it? Did it ship? Did it teach us something? Did it compound? Can someone else build on it next week?

That is a better question than “were you busy?”

It also has risks.

A contribution graph can become theater. People can optimize for visible activity instead of meaningful progress. Managers can confuse commits with impact. Teams can accidentally create surveillance systems and call them operating systems.

So the point is not to count green squares.

The point is that AI-assisted work needs a memory layer. As output volume goes up, the need for traceability goes up too. You need to know what was generated, what was selected, what was shipped, what worked, and what was abandoned.

The repo becomes less like a folder and more like a record of decisions.

A Possible Future

Maybe every serious function ends up with a repo, even if it is not literally GitHub.

Engineering already has one.

Marketing gets one.

Finance gets one.

Product gets one.

Recruiting gets one.

Design gets one.

Not because everyone needs to become an engineer, but because AI makes more work legible as versioned artifacts.

The interesting future is not that every employee has a GitHub streak. That would be a shallow version of the idea.

The interesting future is that companies get a clearer view of how work actually moves:

drafted -> reviewed -> shipped -> measured -> iterated -> archived

That graph may matter more than the org chart.

Because in an AI-assisted company, the question is not who can produce the most stuff. Everyone will be able to produce more stuff.

The question is who can turn judgment into shipped artifacts, and shipped artifacts into learning.

GitHub gave engineering a way to see that motion.

Now the commit graph may be escaping engineering.

Canada has created its first national sovereign wealth fund.

That sentence would have sounded strange a few years ago. It sounds necessary now.

The Canada Strong Fund is starting with a $25 billion federal commitment over three years. It will be an arm’s-length Crown corporation, focused on commercial returns, investing in strategic Canadian projects and companies alongside private capital. The interesting part is that it is not just a government balance sheet vehicle. Ottawa also wants a retail product so ordinary Canadians can invest in it, share in the upside, and have their initial invested capital protected.

That hybrid structure matters. It means the fund can become more than a government program. It can become a coordination layer for Canadian capital.

The first test is obvious: will the big Canadian pension funds participate?

Ontario Teachers’. OMERS. CPP Investments. PSP. La Caisse. BCI. HOOPP. AIMCo. The Maple Eight have become some of the best institutional investors in the world. They manage trillions of dollars. They buy toll roads, airports, utilities, data centres, private companies, credit portfolios and public equities all over the world. They are exactly the kind of long-duration capital Canada says it needs.

So they should be in the Canada Strong Fund.

Not as a patriotic donation. Not as political theatre. Not because anyone should raid pension assets to solve an Ottawa messaging problem.

They should participate because the Canada Strong Fund can be designed as an investable, professionally governed, commercially disciplined platform for opportunities that are currently too fragmented for them to underwrite at scale.

And the most important mandate for that platform should be startups.

The Data Is Uncomfortable

Canada is not short of capital. We are short of organized risk capital pointed at Canadian company formation.

CPP Investments reported $780.7 billion in assets at the end of 2025. Its own geographic disclosure showed $366.9 billion in the United States, or 47 percent of assets, and $98.3 billion in Canada, or 12 percent. OMERS reported that 55 percent of its assets were in the U.S. and 18 percent in Canada at December 31, 2025. PSP Investments reported 40.5 percent U.S. exposure and 20 percent Canada exposure at March 31, 2025. Ontario Teachers’ is more balanced, with 38 percent of gross investments in the U.S. and 31 percent in Canada.

These figures are not pure S&P 500 or U.S. index allocations. They are geographic exposure across public markets, private equity, credit, infrastructure, real estate and other assets. But they are still the right starting point for the national question: where is Canadian retirement capital actually compounding?

This does not mean the funds are doing something irrational. The U.S. is the deepest capital market in the world. A CPP spokesperson told CBC that major global equity benchmarks are roughly 65 percent U.S. by weight, so a 47 percent U.S. exposure is not some wild overweight.

But the national outcome is still strange.

Canadian workers, teachers, nurses, municipal employees and public servants are saving enormous pools of capital. Those pools are compounding, quite rationally, in the places with the most investable assets. Too often, that means the U.S. public market, U.S. private equity, U.S. venture-backed technology, U.S. infrastructure, U.S. credit.

Meanwhile, Canadian venture capital is tiny by comparison.

CVCA reported that Canada saw $8.0 billion invested across 571 venture deals in 2025, down from 2024. The same year, NVCA reported that U.S. venture capital reached 15,352 deals worth $320 billion. The ratio is not close. The U.S. deployed about forty times as much venture capital as Canada.

This is the real problem.

Canada has pension-scale pools of capital and founder-scale ambition, but not enough institutional plumbing between the two.

The Answer Is Not “Force Pensions to Buy Canada”

This argument can get stupid quickly.

Pension funds have a fiduciary duty. They are not industrial policy slush funds. Ontario teachers do not contribute to a pension so that a minister can pick startups. Municipal workers do not need their retirement security tied to whatever sector is fashionable in Ottawa this year.

The case for pension participation has to pass the same test any investment should pass: governance, returns, liquidity, risk, manager quality, benchmark discipline, and enough scale to justify the work.

That is exactly why the Canada Strong Fund matters.

The missing piece in Canada is not patriotism. It is product.

If you are a $300 billion pension fund, you cannot solve Canadian seed funding by writing $2 million cheques into promising pre-seed rounds. You need vehicles. You need professional managers. You need diversification. You need reporting. You need co-investment rights. You need governance. You need enough deal flow to absorb real capital without distorting the market.

Canada should build that vehicle inside the Canada Strong Fund.

Call it the Canada Strong Startup Platform.

Its job would be simple: become the anchor LP for the Canadian innovation economy.

What the Platform Should Do

The platform should not try to pick every startup directly. That would be a mistake.

It should operate primarily as a fund of funds, with a co-investment sleeve.

The rough structure:

• 70 percent into Canadian venture funds, from pre-seed to growth.

• 20 percent into direct co-investments alongside those managers, especially for Canadian companies that need $50 million to $300 million rounds without immediately moving south.

• 10 percent reserved for secondaries, follow-ons, and liquidity support so the ecosystem can recycle capital.

It should back many managers, not five famous ones.

Canada needs more funds, not just bigger funds. It needs specialist AI funds, health funds, climate funds, fintech funds, robotics funds, bio-manufacturing funds, defence technology funds, energy technology funds, developer tool funds, and boring software funds. It needs first-time and second-time managers with real edge. It needs funds in Toronto, Montreal, Vancouver, Waterloo, Calgary, Edmonton, Ottawa, Halifax and Quebec City.

The platform should write anchor commitments that make funds possible.

A $50 million commitment into a $150 million fund changes the trajectory of an emerging manager. A $150 million commitment into a $500 million growth fund changes whether Canadian scale-ups can raise locally. A standing co-investment program changes whether our best companies have to become Delaware companies with U.S. lead investors by default.

This is where pensions can participate without pretending to be seed investors.

They can commit to the Canada Strong Startup Platform on commercial terms. The federal government can seed it. The pension funds can scale it. Retail Canadians can participate through the broader Canada Strong product. The platform can recycle returns into the next generation of funds.

That is how you turn a sovereign wealth fund from a press conference into an ecosystem machine.

The Math Is Not Crazy

The Canada Strong Fund starts at $25 billion.

That is big for Ottawa. It is small compared with Canadian pension capital.

CPP alone is roughly $780 billion. Ontario Teachers’ is $279 billion. PSP is almost $300 billion. OMERS is $145 billion. La Caisse reported $517 billion in net assets for 2025. BCI manages nearly $295 billion in gross assets.

One percent of these pools is enormous.

One percent of CPP is about $7.8 billion. One percent of Ontario Teachers’ is about $2.8 billion. One percent of PSP is about $3.0 billion. One percent of OMERS is about $1.5 billion. One percent of La Caisse is about $5.2 billion.

Nobody has to bet the pension system on Canadian startups.

A 0.5 percent to 1.0 percent allocation from a few major funds, phased over five to ten years, would create one of the most important venture capital engines in Canadian history. It would still be small enough to sit inside a diversified institutional portfolio. It would be large enough to change founder behaviour.

Founders respond to capital availability.

If the only serious Series B and Series C capital is in San Francisco or New York, companies will orient themselves there. If the only deep AI infrastructure investors are American or Gulf-backed, the best Canadian AI companies will become Canadian in origin and foreign in ownership. If Canada wants headquarters, jobs, tax base, intellectual property, and decision-making authority to stay here, it needs domestic growth capital.

Not grants. Capital.

The Gulf Already Understands This

The Gulf funds are not subtle about what they are doing.

Saudi Arabia’s Public Investment Fund has Jada, a fund-of-funds company created to develop the country’s private equity and venture ecosystem. The Saudi Press Agency recently reported that Jada had allocated SAR 3.5 billion across 46 venture capital and private equity funds, while Sanabil had committed roughly SAR 1.5 billion to support 165 emerging companies. That is ecosystem construction, not passive portfolio allocation.

Abu Dhabi has been just as deliberate.

Mubadala helped back Hub71, Abu Dhabi’s global tech ecosystem. Hub71’s 2024 impact reporting said startups in the ecosystem had raised $2.17 billion and generated $1.2 billion in revenue. Mubadala also built venture exposure through Mubadala Capital and partnered with global managers. More recently, Abu Dhabi’s MGX has become a major AI and infrastructure vehicle, partnering with Microsoft, BlackRock and GIP on AI infrastructure.

The lesson is not that Canada should copy Gulf political economy. We should not.

The lesson is that sovereign capital can be used to create a market.

The Gulf funds understand that startup ecosystems are not just office space and accelerators. They are capital stacks. They are anchor LPs. They are procurement relationships. They are immigration policy. They are compute, power, customers, regulators, universities, and later-stage financing. They are the whole machine.

Canada has pieces of this machine. We have strong universities. We have AI labs. We have technical talent. We have public pension sophistication. We have stable institutions. We have energy. We have immigration. We have founders.

But we do not yet have the capital stack at national scale.

The Canada Strong Fund can become that stack.

The Mandate Should Be Narrow

If everything is strategic, nothing is strategic.

The Canada Strong Fund will be tempted to become a basket of airports, mines, ports, transmission lines, manufacturing projects, defence suppliers, telecom infrastructure, and politically important regional deals. Some of that belongs in the fund. Canada does need nation-building infrastructure.

But startups deserve a dedicated mandate because startups are how new strategic sectors are born.

A mine is important. A port is important. A transmission line is important.

But the companies that turn minerals into materials, biology into medicine, compute into software, robotics into productivity, and AI research into global products are also infrastructure. They are the productive infrastructure of the next economy.

The fund should define a clear innovation allocation and publish it.

For example:

• At least 20 percent of Canada Strong Fund capital committed to the Canada Strong Startup Platform over the first decade.

• At least half of that deployed through independent Canadian venture managers.

• No political deal selection.

• Independent investment committee.

• Commercial return targets.

• Annual disclosure of commitments, managers, vintage diversification, fees, net returns, follow-on rates, Canadian headquarters retention, patents, exports, employment and tax base.

• Co-investment rights for pension partners.

• A strict rule that government cannot direct individual company investments.

This is how you keep the fund from becoming a subsidy program.

The goal is not to make venture capital easier. The goal is to make Canadian venture capital investable at institutional scale.

What Ontario Teachers’ Should Do

Ontario Teachers’ should be first.

It already has Teachers’ Venture Growth. It already invests in global technology companies. In 2025, Teachers’ reported venture growth returns of 30.2 percent, and highlighted investments in Anthropic, Grafana Labs, Gusto, Darwinbox, Kraken and Quantexa. It also led StackAdapt’s latest funding round in Canada.

That is the muscle Canada needs.

Ontario Teachers’ should publicly commit to evaluating an anchor allocation to the Canada Strong Startup Platform, with a preference for fund commitments and co-investments that can pass its normal underwriting bar.

OMERS should follow. It serves Ontario municipal workers, school boards, transit systems, electrical utilities, emergency services and local agencies. It is already deeply connected to Ontario’s public economy. It has 55 percent of assets in the U.S. and 18 percent in Canada. It does not need to abandon global diversification to put more capital behind Canadian company formation.

CPP Investments should participate carefully. CPP has the strongest need to protect independence, because it is the national plan. But even CPP can allocate through a professionally governed, commercial platform without turning itself into a policy tool.

PSP should be natural. It already manages Canada Growth Fund independently. It understands the difference between government policy capital and pension capital. It can help design the governance firewall.

La Caisse should be a model. Quebec has long understood that institutional capital can support local economic development while still pursuing returns. Canada should learn from that without making the governance sloppy.

BCI, HOOPP and AIMCo should be at the table too.

This should not be a single cheque. It should be a standing market.

The Policy Ask

Ottawa should do five things.

First, create a dedicated startup fund-of-funds sleeve inside the Canada Strong Fund.

Second, invite the Maple Eight to become anchor LPs on commercial terms, with co-investment rights and independent governance.

Third, use a comply-or-explain model for federally and provincially sponsored public funds: each major plan should annually disclose whether it evaluated Canada Strong Fund opportunities and why it did or did not invest. Do not force bad investments. Force serious consideration.

Fourth, make BDC complementary, not duplicative. BDC can keep doing direct support, debt, seed programs and fund commitments. The Canada Strong Startup Platform should be the national institutional allocator that brings pensions, sovereign capital and private LPs into the same architecture.

Fifth, measure the right outcomes. Not announcement dollars. Not jobs promised in press releases. Measure fund performance, follow-on capital, manager formation, company scale-up retention, Canadian headquarters, exports, productivity, tax base and realized returns.

The Canada Strong Fund should not be judged by whether it sounds patriotic.

It should be judged by whether, ten years from now, a Canadian founder can build an important company in Canada without immediately depending on foreign capital to survive.

Build the Capital Stack

Canada’s startup problem is usually described as a talent problem, a culture problem, a market problem or an ambition problem.

Some of that is true.

But a lot of it is a capital stack problem.

The U.S. has a massive venture capital machine. The Gulf is using sovereign wealth to build one. Europe is trying to mobilize institutional capital for strategic sectors. Everyone has figured out that the next economy will be shaped by who finances the companies before they are obvious.

Canada finally has a sovereign wealth fund.

Now it needs to make the fund useful.

Put the pension funds in the room. Give them a professionally governed vehicle they can actually underwrite. Make startups a core mandate, not a footnote under “technology.” Back many Canadian venture funds. Reserve capital for growth rounds. Keep politics out of investment decisions. Publish the data. Compound the returns. Recycle the gains.

If Canada Strong is going to mean anything, it should mean that Canadian capital helps Canadian builders build Canadian companies at global scale.

That is the sovereign wealth fund we need.

Sources

• Government of Canada, Canada Strong Fund backgrounder, April 27, 2026.

• Government of Canada, Spring Economic Update 2026, Canada Strong Fund section.

• CPP Investments, The Fund, assets and geographic allocation as of December 31, 2025.

• CBC News via Yahoo, Amid ‘Buy Canadian’ fervour, Canada’s top pension funds still heavily invested in U.S., February 2026.

• Ontario Teachers’ Pension Plan, 2025 Annual Report.

• Ontario Teachers’ Pension Plan, Performance and track record.

• OMERS, 2025 Annual Report.

• PSP Investments, 2025 Annual Report.

• La Caisse, 2025 results press release.

• BCI, BCI achieves 10% annual return in fiscal 2025.

• CVCA, Year-End 2025 Canadian Venture Capital Market Overview.

• NVCA, 2026 Yearbook press release.

• Public Investment Fund, Jada Fund of Funds.

• Saudi Press Agency, PIF Governor reviews strategy, April 2026.

• Hub71, 2024 impact reporting via Zawya.

• Hub71, Mubadala, Antler and Hub71 National Founders Programme, September 2025.

PM Carney announced the Canada Strong Fund this week. $25 billion to start, a Crown corporation structure, and an explicit invitation for Canadians to invest alongside the government.

I think it’s a great move. Long overdue. And I think the next move is even more important.

Jensen Huang has been making a point lately that I can’t stop thinking about. Chips and data centers are the factories of the future. Not metaphorically. Literally. They take in electricity and produce intelligence, sold by the token, consumed at the rate of billions per second.

Tokens are units of cognitive labor. As models get better, more of what used to be human work moves into the factory. Translation, writing, analysis, support, design, increasingly engineering. None of it disappears. It just shifts location.

Here is what worries me. Almost none of those factories are in Canada. The dominant ones are owned by a handful of US companies running on chips fabricated in Taiwan. When a Canadian business uses AI to do the work that used to require five employees, the productivity gain is real, but the rent flows to Nvidia, OpenAI, Microsoft, Google, Anthropic. Local wages compress. Foreign profits expand. Our trade balance on intelligence will start to look like an oil importer’s balance on oil.

A sovereign wealth fund is a good start. But the most important project of national interest right now is the factory itself. Canada should be building and operating token factories at national scale. Hydro-rich provinces, cold climate, stable rule of law, abundant land. The natural advantages are obvious. The financing structure has been the missing piece.

Call it a Sovereign Intelligence Fund. A Crown corporation with a single mandate: build and operate the compute infrastructure that produces tokens for Canadian use. Canadian companies live on top of that base layer, taking the raw output and curating it into products the world wants to buy. That is the part of the value chain we are good at. We will not get to play that game for long if we do not own the factory underneath.

The early pieces are in motion. The Cohere and CoreWeave facility in Cambridge is online. The federal AI compute strategy has $2 billion committed. The instinct is right. The scale is wrong. $2 billion is a rounding error compared to what a single US hyperscaler spends on data centers in a quarter.

The next move out of Ottawa should be ambitious. Tens of billions in scale, not single-digit billions. An explicit mandate to be the wholesale supplier of Canadian-controlled tokens to Canadian businesses. And a retail product that lets ordinary Canadians own a slice of it, just like the Canada Strong Fund.

We have the chance to collectively own the factories of the next economy. We should take it.

Most iOS app founders I talk to assume that building a referral system is a six-figure problem. They look at Branch, AppsFlyer, Tapfiliate, Rewardful. They quote out something like $500 to $5,000 a month. Then they decide referrals are a “later” problem and ship without one.

Here’s the thing nobody tells you: Apple already gives you the primitives. You can generate one-time promo codes through the App Store Connect API, hand them out programmatically, and detect when each one is redeemed. With RevenueCat (or your own receipt validation) on the back end, you have everything you need to credit a referrer the moment their friend converts.

I built this at Alma in about a week. This post is the missing manual.

What Apple Actually Gives You

Inside App Store Connect, every auto-renewable subscription can have a subscription offer, and every offer can have one-time use codes. Each code is a unique string that unlocks the offer for one person. You’ve probably seen them used in beta testing: “here’s a free month, paste this in Settings.”

What’s less well known is that the App Store Connect API will generate these in batches for you. You can request 25,000 codes in a single API call. They come back as a CSV-like response with a unique string per row, and Apple tracks redemption state on their side.

So the building blocks are:

1. Generate codes programmatically through the App Store Connect API

2. Hand a code to a user via your own backend

3. Detect redemption through a RevenueCat webhook (or App Store Server Notifications if you’re going direct)

4. Map the redeemed code back to the referrer and reward them

That’s it. No third-party SDK in your binary. No second analytics pipeline. The whole loop lives between Apple, your database, and your subscription provider.

The Pool Pattern

The trick that makes this work at scale is treating offer codes like a resource pool, not a per-user generation request.

Generating codes through the App Store Connect API is not instant. It’s a background job on Apple’s side, and the codes don’t appear immediately. If the first time a user taps “Share with a friend” is also the first time you call Apple’s API, you’ve just made your share button a 30-second loading spinner.

So we keep a pool. A Postgres table with one row per code:

one_time_code_pool
  code              TEXT
  status            ENUM(available, pending, used, expired)
  assigned_to_user  UUID NULL
  expires_at        TIMESTAMP

A scheduled job watches the count of available rows. When it dips below a threshold, it calls the App Store Connect API and inserts the new batch. Codes flow through the lifecycle:

• available: minted by Apple, sitting in the pool

• pending: assigned to a referrer, waiting for someone to redeem

• used: redeemed by a friend, attribution complete

• expired: never used within Apple’s expiry window

When a user calls GET /referral/my-code, the backend grabs the next available row, marks it pending, stamps the user’s ID on it, and returns it. The user always gets an answer in under 100ms.

Authenticating to App Store Connect

The fiddly part is the JWT. The App Store Connect API uses a signed token, and the signing key format is a footgun.

Inside App Store Connect, under Users and Access > Integrations > App Store Connect API, you create a key. Apple gives you a .p8 private key file and three identifiers: a Key ID, an Issuer ID, and a Team ID. You only get to download the key once. Lose it and you start over.

The key looks like this:

-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQg...
-----END PRIVATE KEY-----

In environment variables, the newlines often get stripped, which is what makes this annoying. Your JWT signing code needs to handle both the full PEM (with headers) and the raw body (without). We normalize on read, then sign with ES256:

def generate_app_store_connect_jwt():
    headers = {"alg": "ES256", "kid": APPLE_KEY_ID, "typ": "JWT"}
    payload = {
        "iss": APPLE_ISSUER_ID,
        "iat": int(time.time()),
        "exp": int(time.time()) + 1200,  # 20 minutes max
        "aud": "appstoreconnect-v1",
    }
    return jwt.encode(payload, normalized_private_key, algorithm="ES256", headers=headers)

Tokens are valid for at most 20 minutes. We mint a new one per request rather than caching, which is fine because the cost is microseconds.

With the JWT in hand, generating a code batch is a single POST to /v1/subscriptionOfferCodes with a relationship to your subscription, the batch name, the number of codes, the expiry, and the activation date. Apple processes it asynchronously. A second poll a few minutes later returns the actual code strings.

The Redemption Path

This is where the architecture gets opinionated. Apple gives you two ways to know a code was redeemed, and you need both.

Path one: the RevenueCat webhook. When a friend pastes the code into the App Store offer redemption sheet and completes the purchase, RevenueCat fires an INITIAL_PURCHASE event to your backend. The payload includes an offer_code field. You match that string against the pending rows in one_time_code_pool, find the referrer, mark the row used, and credit the referrer.

Path two: the iOS confirm endpoint. SwiftUI ships a built-in modifier called .offerCodeRedemption(isPresented:onCompletion:). It opens Apple’s native redemption sheet. When it returns successfully, your app immediately calls POST /referral/confirm-redemption?referral_code=ABC123 so the backend can credit the referrer right away.

Why both? Because the RevenueCat webhook sometimes arrives without offer_code populated, or arrives minutes late, or arrives never (we’ve seen all three). And the iOS confirm path is unreliable too: the app might be backgrounded, the network might drop, the user might force-quit. You write idempotent code that handles either path arriving first, and you stop worrying about it.

The idempotency rule is one row in referral_completions per (referrer, referee) pair. If both paths fire, one wins, the other is a no-op.

Crediting the Referrer

This is the only part where you genuinely need a subscription provider with a “promotional” or “gifted” entitlement concept. RevenueCat calls it a promotional entitlement and exposes it through POST /subscribers/{id}/entitlements/{ent}/promotional. You hit that endpoint with a duration (we use 30 days per successful referral, stackable), and the user immediately gets premium features even though they never paid.

If you’re not using RevenueCat, the equivalent is maintaining a granted_premium_until column on your user table and checking it alongside the App Store receipt. Slightly more code, but the same shape.

The thing to internalize is: the reward doesn’t have to be subscription credit. Once you have a reliable signal that “user A successfully referred user B,” you can reward however you want. Cash via Tremendous. Account credits. Entries in a giveaway. A T-shirt. The hard part was attribution, not payout.

The Whole Loop in One Diagram

Referrer taps "Share"
  → GET /referral/my-code
  → backend pulls next available code from pool, marks it pending
  → returns "Use code XYZ123 for a free month: apps.apple.com/redeem?code=XYZ123"

Friend taps the share message
  → opens App Store offer redemption sheet (native iOS)
  → completes purchase

Two things happen, in some order:
  → RevenueCat sends INITIAL_PURCHASE webhook with offer_code=XYZ123
  → iOS app calls POST /referral/confirm-redemption?referral_code=XYZ123

Backend (idempotent):
  → marks pool row 'used'
  → inserts row in referral_completions
  → grants referrer 30 days of promo access via RevenueCat
  → optionally pays referrer cash via Tremendous, sends a push, etc.

What This Unlocks

When the cost of building a referral program drops from “evaluate three vendors and sign a $20k contract” to “two days of backend work,” the calculus changes. You stop debating whether to do referrals. You start iterating on the offer.

A few things we’ve tried since shipping this:

Tiered rewards. Refer one friend, get a month free. Refer five, get a year. The pool doesn’t care.

Influencer codes. A creator gets their own batch of 100 codes branded for their audience. Same infrastructure, different UI for distribution.

Win-back offers. A churned user gets a one-time code in an email. Same pool table, different assigned_to semantics.

Affiliate cash payouts. For a partnership with a fitness coach, every redemption of their code triggered a $15 payment to them via Tremendous. We had the attribution. Tremendous had the rails. The whole thing was a 200-line script.

None of this required a new vendor. It all came out of the same one_time_code_pool and referral_completions tables.

What Still Requires Care

Being honest about the rough edges:

Apple’s processing latency. Code batches don’t appear instantly. If your pool empties and you have to wait for Apple, your referral feature returns a 503. Keep your refill threshold generous and run the cron daily, not weekly.

Webhook authentication. RevenueCat sends a shared secret in the auth header. If you don’t validate it, anyone on the internet can forge a successful referral and grant themselves premium. We reject any webhook missing the expected header value. This sounds obvious. It is not always done.

Self-referral. You’d be amazed how many people try to redeem their own code. The check is one line (if referrer_id == referee_id: reject) but it has to be there.

Entitlement identifier drift. We had a bug for a week where the webhook path granted entitlement premium and the iOS confirm path granted entitlement alma_premium_promo. Both reported success. Only one actually unlocked the UX. Pick one identifier, use it everywhere, and write a test.

Admin endpoints. It’s tempting to expose GET /referral/admin/stats to see how the program is performing. If it’s on a public API host, add auth. We left ours unauthenticated for one afternoon and it was indexed by a crawler before sundown.

The Stack

For anyone building this:

• App Store Connect API: Code generation, JWT auth with ES256, /v1/subscriptionOfferCodes endpoint

• Postgres: one_time_code_pool and referral_completions tables, plus an Alembic migration

• FastAPI: Three endpoints (my-code, stats, confirm-redemption) plus the RevenueCat webhook handler

• RevenueCat: Webhook receiver and promotional entitlement grants via their v1 API

• SwiftUI: .offerCodeRedemption(isPresented:onCompletion:) modifier for the native redemption sheet

• Background worker: A cron job that monitors pool depth and refills via the ASC API

Total backend code is around 800 lines. Total iOS code is around 200. We use the standard subscription stack we already had, plus one new table and one new router.

The Takeaway

The real insight isn’t that Apple has a referral API. It’s that the primitives have been sitting in App Store Connect for years and almost nobody assembles them.

If you’re already using a subscription product, you’re already authenticating to Apple, validating receipts, and listening for webhook events. Adding a referral loop on top is a weekend, not a quarter. The codes are free. The infrastructure is yours. The only thing the third-party vendors are really selling is the assembly, and the assembly is a long blog post.

We shipped Alma’s referral program with this stack three months ago. Every code redeemed has been attributed. The pool refills itself. The referrer gets credit before their friend has even logged their first meal.

If you’re sitting on a subscription app and waiting for “the right time” to build referrals, this is your sign. Apple’s already done the hard part.

Curious about what we’re building? Alma is an AI nutrition coach that actually remembers you. Free to start.

I love sending surveys. I love reading the answers. Talking to users is one of the few parts of the job that has never gotten old, and a well-timed survey is the highest signal-to-effort way I know to do it at scale.

The part I do not love is the plumbing.

Typeform is a nice product, but the pricing tiers turn a weekly habit into a line item. The good features live behind the higher plans, response limits cap the fun right when things are interesting, and the data ends up trapped in a dashboard I then have to export, clean, and rejoin to my user table to ask any question worth asking. Rolling your own from scratch using a generic form builder or stitching together Notion plus Zapier plus a spreadsheet was, for most of my career, worse: expensive in hours, tedious to maintain, and always one broken integration away from a Saturday afternoon of debugging.

So the survey itch would show up. I’d weigh the plumbing. I’d ship the survey anyway, because the answers are worth it. But the friction kept the cadence irregular. I wanted a weekly habit. I was getting a quarterly burst.

So I rebuilt the whole thing. No Typeform. No Google Forms. No third-party anything. The survey page lives on our own site, the responses land in our own database, the sends go through our own email, and a skill orchestrates the whole loop. Weekly cadence. About twenty minutes of my time per round.

Here is how it works, and how you can build the same thing for your product.

What I Actually Wanted

The target was simple:

1. Survey topics should come from gaps in what we already know, not whatever I happened to be thinking about that week.

2. Writing a survey should take minutes, not hours. Designing four questions is not a craft that deserves a full afternoon.

3. Responses should land in a place I control, next to the user data they belong with, not trapped in a SaaS dashboard.

4. Sending should be one command, and the system should refuse to spam the same person twice inside a month.

5. I should never, ever open Typeform again.

Five pieces, end to end. Each one is a hundred lines of code or less.

Piece 1: The Survey Page

We have a marketing site at alma.food. It already renders a dozen static pages. Adding a dynamic survey route turned out to be a one-evening job.

The page lives at alma.food/surveys/:slug. The slug is the survey identifier. The configuration for each survey is a plain JavaScript file in src/survey-configs/:

export default {
  slug: 'logging-accuracy-2026-04',
  title: 'Is Alma getting your food right?',
  subtitle: 'Quick 3-minute check on nutrition data accuracy.',
  questions: [
    {
      id: 1,
      type: 'single_choice',
      question: 'How often does Alma feel off?',
      options: ['Almost never', 'Sometimes', 'Often', 'Most of the time'],
      required: true,
    },
    {
      id: 2,
      type: 'rating',
      question: 'How much does that affect your trust in Alma?',
      scale: 5,
      labels: ['Not at all', 'Makes me want to quit'],
      required: true,
    },
    {
      id: 3,
      type: 'open_text',
      question: 'Anything specific you want us to fix?',
      required: false,
    },
    {
      id: 4,
      type: 'email_opt_in',
      question: 'Want us to follow up?',
      required: false,
    },
  ],
}

The React page reads the slug from the URL, imports the matching config, and renders a single-page survey with a progress bar. Six question types cover everything I’ve ever needed: single_choice, multi_choice, rating, yes_no, open_text, email_opt_in. The survey pages aren’t linked from anywhere public. The path you end up on is the one you received in the email.

On submit, the page posts to a single backend endpoint. That’s it. Shipping a new survey is now writing a JS config file, adding it to a loader map, and pushing to our prod branch. Vercel deploys it automatically.

Piece 2: The Response Endpoint

The backend is a single FastAPI route:

@router.post("/surveys/{slug}/response")
@rate_limit(...)
def submit_survey_response(slug, params, session):
    session.execute(text("""
        INSERT INTO survey_responses (survey_slug, answers, respondent_email)
        VALUES (:slug, :answers, :email)
    """), {
        "slug": slug,
        "answers": json.dumps(params.answers),
        "email": params.respondent_email,
    })
    session.commit()
    return {"success": True}

(The endpoint is rate-limited and does basic input validation. Don’t ship a public write endpoint without both.)

That is the entire storage layer. Three tables cover the schema:

• surveys — slug, title, description, questions JSON, cohort SQL (for reference later)

• survey_responses — slug, answers JSON, respondent email, created_at

• survey_sends — slug, user_id, email, sent_at (enforces the cooldown)

No admin panel. No dashboard. I query it the way I query any other production data, which is exactly the point. Survey responses live next to the food logs, the chat transcripts, the subscription events. When I want to cross-reference a specific answer against a user’s logging pattern, it is one join, not a CSV export.

Piece 3: The Skill

This is the part that took the habit from “quarterly maybe” to “weekly without thinking.”

I wrote a Cursor skill at docs/skills/survey.md. Skills are markdown files that describe a workflow for an AI agent to execute. Mine has eight steps, in order:

1. Load context — the agent reads a voice guide and queries the last 15 surveys from the database so it doesn’t repeat a topic.

2. Propose topics — based on gaps in past surveys, the agent proposes five candidate topics with a one-line rationale each, and asks me to pick one or describe my own.

3. Design the survey — four to six questions, no leading phrasing, one open text near the end, one email opt-in last. The agent drafts it, I approve.

4. Create the files — config file, loader entry, surveys table insert. All generated.

5. Find target users — the agent proposes a cohort (active last 30 days is a good default), runs the SQL against our Supabase prod database via MCP, dedupes against anyone surveyed in the last 30 days, and reports the final count.

6. Draft the email — short, plain text, warm, direct. No template. No branding. The subject line is curiosity driven, not “We need your feedback.”

7. Send — one command per batch, BCC up to 49 recipients per call (AWS SES limit), record every send in survey_sends.

8. Follow up with opt-ins — respondents who leave an email in the opt-in field get a short thank-you note with a Cal.com link two days later.

Each step has clear instructions: the exact SQL to run, the exact email structure, the exact insert statement. The skill removes every small decision that used to consume my energy.

When I say “run the survey skill,” the agent reads the file and starts at Step 1. I show up for the approval checkpoints. The agent handles the plumbing.

Piece 4: The Review Loop

Sending is half the loop. The other half is reading what came back and actually doing something with it.

Every Thursday I run a second skill that pulls the week’s responses, groups them by question, summarises the open text qualitatively, and drops the whole thing into a dated markdown file at product_marketing/survey_manager/survey_results_YYYY_MM.md. The same file gets appended to every week. Over time it becomes a rolling log of what users are telling us, which is more useful than any single survey’s top-line numbers.

The key move here is that the review is deterministic. Same format, same sections, same location, every week. That consistency is what makes it possible to skim three months of results in ten minutes and actually notice a shift in sentiment, not just re-read last week’s spike.

Piece 5: The Cadence

Every Thursday. That is the whole schedule.

On Thursday morning, I run the review skill against the survey I sent the previous Thursday. Most responses are in by then. The skill summarises the answers and appends them to the running results doc. Then I run the send skill and ship a new one the same day. Review, then send, then done until next Thursday.

Twenty minutes, once a week, at the same time. The consistency is what turned this into a habit instead of a project.

The cohort query is the part I’m most protective of. Every send pulls a fresh batch of active users directly from the production database and cross-references them against the survey_sends table before anyone gets an email. If you’ve received a survey from me in the last month, you are automatically excluded from the next one, no matter what the topic is. That table is effectively a lightweight CRM: one row per send, one per-user cooldown, enforced at query time. The skill refuses to draft the email until the cohort has been deduped.

This matters more than it sounds. The fastest way to ruin a feedback loop is to burn out the people who answer. The cooldown means nobody hears from me more often than once a month, and every survey reaches a genuinely fresh slice of the user base. The BCC sends use a generic “Hi there” greeting (no personalisation is possible in BCC), which I decided was a fine trade for being able to send to a batch with one command. The signal is in the answers, not the salutation.

The Math

A weekly Typeform-style workflow has real costs:

• 30 minutes designing each survey in a builder UI

• 15 minutes exporting responses to a CSV

• 15 minutes rejoining that CSV to user data to ask any question worth asking

• A monthly SaaS bill that climbs the moment your response volume gets interesting, plus feature gates on the higher tiers for things that should be table stakes

A self-hosted loop costs me:

• 20 minutes a week, mostly spent on approval checkpoints

• Zero incremental SaaS

• Full access to the raw data for cross-referencing

• A rolling log of feedback I actually re-read

The tradeoff I thought I’d be making (polish for control) turned out to be a non-issue. Nobody has complained about the page. People answer the questions. The open text boxes fill up with thoughtful paragraphs. Response rates have gone up, not down, probably because the emails sound like they’re coming from a founder who actually cares, not a form that escaped a marketing department.

What You Need to Build This

If you’re a founder or PM reading this and thinking about stealing the pattern, here’s the minimum viable version:

1. A page on your site that reads a slug, loads a config, renders a form, and POSTs to one endpoint. 150 lines of React.

2. One backend endpoint to store the response. Rate limit it.

3. Three database tables: surveys, responses, sends.

4. A skill file that walks an AI agent through proposing, designing, sending, and recording. Start with mine. Swap out the cohort SQL for whatever matches your user model.

5. A weekly time slot on your calendar. Not for doing the work. For showing up to the approval checkpoints.

Everything else is polish. The entire system is probably 400 lines of code end to end, most of which you’re going to ask an agent to write for you anyway.

The lesson I keep learning is that tools like Typeform solve a problem that doesn’t really exist anymore, which is “I don’t know how to ship a form.” You do know how to ship a form. Or rather, the agent sitting next to you does, and all you need to give it is the structure of your own system and a little bit of taste about what the survey should ask.

Last Tuesday at 2:47 AM, a user in Sydney logged “medium fries from Macca’s.” The system matched it to a US-sourced McDonald’s record. Wrong country, wrong portion, wrong calories. Nobody was awake.

By morning, there was a markdown file in our repo explaining exactly what happened: the branded fast path matched a US-centric database record because the system has no region awareness. The file included the trace ID, the database query that confirmed the mismatch, and a recommendation to add region-aware branded food matching to the backlog. It decided not to auto-fix because the user had already corrected the values manually.

The system that wrote that report has no pulse. It’s a Python daemon running on a Macbook Pro that polls our production database every three minutes, and when it finds something wrong, it spawns an autonomous AI agent to investigate and fix it.

We call them watchers.

What a Watcher Actually Is

A watcher is a Python script that runs as a background daemon. It polls a data source on a fixed interval, checks for new problems, and when it finds one, spawns a headless Claude Code process to investigate.

Not an API call. A full coding agent with access to the filesystem, the production database, observability traces, and the source code. It can read files, write fixes, run queries, commit to git, and update production data. It does this without a human in the loop.

We run five of them.

Bug Watcher polls every three minutes. It watches two tables: user-submitted bug reports and food feedback dislikes. When someone taps the thumbs-down on a food log and writes “this is way off,” the bug watcher picks it up, pulls the user’s chat logs, queries the food item and its change history, searches our observability platform for the processing trace, reads the relevant source code, and writes an investigation report. If the fix is straightforward, a bad reference ratio or a corrupted nutrition value, it fixes it in production and commits the change.

Accuracy Watcher runs every three hours. It fetches all food item corrections from the last window: every time a user edited their calories, changed a quantity, or deleted something we got wrong. It groups the corrections by food classification, data source, and type of change. When it spots a pattern, like a cluster of 30%+ calorie corrections on estimated foods from the same source, it traces the issue through our processing pipeline, identifies the upstream bug, and fixes it in the code.

Error Watcher runs every thirty minutes. It looks for food items stuck in an error state, meaning the system tried to process them and failed. It groups them by classification, investigates the failure via traces and code, and either recovers the items or fixes the code path that broke.

Fixer Watcher polls every three minutes. We have an automated fixer agent that attempts to correct food items when it detects issues. Sometimes the fixer itself fails. The fixer watcher investigates those failures, classifying whether the root cause was a code bug, a data issue, a model hallucination, a search gap, or a timeout. This is meta-debugging: an agent investigating why another agent failed.

GCloud Watcher runs every three hours. It pulls error logs from our three Cloud Run services (API, workers, scheduler) via gcloud logging read, classifies the errors with regex patterns, filters out known benign failures (expected auth rejections, user-deleted items, network timeouts), and spawns an investigation for anything new or frequent.

What Self-Healing Actually Looks Like

The phrase “self-healing” gets thrown around loosely. Here’s what it means in practice, with two real examples from the last 48 hours.

The scoop problem. The accuracy watcher’s 6 AM run analyzed 223 corrections from 38 users. It found that protein powder logged by weight was coming back at absurd values. A user logged 30 grams of protein powder and got 30 calories instead of 140.

The investigation traced it to our fast path formula for chef recipe ingredients. When a food is stored per-scoop (140 cal per 1 scoop, with a reference ratio indicating 30g per scoop) and a user logs it in grams, the formula was squaring the weight conversion. The physics filter caught the impossible values and fell back to the LLM, which underestimated by a different amount.

The watcher identified the exact function (try_chef_ingredient_fast_path in fast_paths.py), wrote a cross-unit detection guard, committed the fix, and noted that 253 foods in the database had this broken pattern. Total time from detection to committed fix: about twelve minutes. No human involved.

The zucchini corruption. A user reported that 196g of zucchini was showing 98 calories, roughly 3x the correct value. The bug watcher investigated and found something worse than a simple estimation error.

Seven days earlier, a different user had over-corrected their zucchini entry twice in two minutes. Our user correction propagator, designed to learn from corrections and update shared food records, accepted both corrections. The master zucchini record went from 15 cal/100g (correct, per USDA data) to 50 cal/100g. For a full week, every user who logged zucchini got inflated values. About 301 food items across 165 users were affected.

The watcher traced the entire corruption timeline through five database events and three observability traces. It identified that the propagator’s safety guards only blocked large downward corrections (>80% reductions) but had no symmetric guard for upward corrections. It documented the affected user count, recommended a backfill script, and flagged the propagator design gap for human review.

This is the distinction that matters. The watcher didn’t blindly auto-fix everything. It fixed the data that was safe to fix (the master food record had already been corrected by a subsequent user). It documented what needed human judgment (the backfill affecting 165 users). And it identified the systemic weakness (asymmetric propagation guards) that caused the problem in the first place.

The Constraint Design

Giving an AI agent production database access and git commit rights sounds reckless. The interesting engineering is in how you make it not reckless.

Each watcher spawns Claude Code in headless mode with a whitelist of allowed tools. The agent can read, edit, and write files. It can run specific shell commands: uv run, gcloud, git add, git diff, git commit. It can query our production database via Supabase and search observability traces via Logfire. It cannot delete tables, cannot force-push, cannot modify CI/CD pipelines, cannot access external APIs.

The prompts are 200+ lines of markdown each. They aren’t vague instructions like “investigate bugs.” They’re structured investigation playbooks: which tables to query first, what SQL patterns to use, how to navigate the codebase, what qualifies as a safe auto-fix versus what requires human review. The prompt template is the real product. The daemon is just the delivery mechanism.

Timeouts prevent runaway investigations. Bug and fixer watchers get 15 minutes. Accuracy, error, and GCloud watchers get 30. If Claude hasn’t finished by then, the process is killed and the item is logged for the next cycle.

State tracking prevents re-investigation. Each watcher maintains a SQLite database of processed items. If the bug watcher already investigated report #4521, it won’t investigate it again on the next poll. Reset is simple: delete the SQLite file and everything from today gets re-examined.

Every investigation produces a markdown report saved to the repo. These aren’t just logs. They’re structured documents with severity classification, root cause analysis, affected code paths, evidence (trace IDs, SQL queries, before/after values), and a clear record of what was fixed and what was deferred. When I review them in the morning, I’m reading a finished investigation, not raw data.

The Prompt Is the Product

The difference between a watcher that’s useful and one that generates noise is entirely in the prompt template.

Our accuracy watcher prompt doesn’t just say “analyze these corrections.” It tells Claude to group changes by food classification and data source first. It explains our processing pipeline: completion agent, chef agent, reference agent, fast paths. It states our core principle: “fix upstream, not at the gateway.” It provides the SQL to pull Logfire traces by food item ID. It describes what a “large correction” means in context (30%+ calorie change) and how to distinguish between user preference changes and genuine data quality issues.

We iterated on these prompts for weeks. Early versions produced investigations that were technically correct but useless. Claude would identify the wrong food record but not trace it back to the code that selected it. Or it would find the code bug but not check how many other foods were affected. Each failure mode became a new paragraph in the prompt.

The prompts encode institutional knowledge. They’re how we teach a new engineer to investigate a bug, except the engineer runs at 3 AM and doesn’t get tired.

The Economics

This runs on a Claude Max subscription. Every headless invocation is included. The bug watcher might spawn 15 investigations in a day. The accuracy watcher runs 8 times. The GCloud watcher, 8 times. All unlimited, fixed cost.

We explicitly strip the Anthropic API key from the environment before spawning each agent. This forces Claude Code to use the Max subscription rather than per-token billing. At the volume these watchers produce, per-token costs would be significant. Fixed-cost unlimited access makes the whole architecture viable.

The alternative isn’t “don’t do this.” The alternative is doing it manually. Reading error logs over coffee. Querying the database by hand. Tracing through code to find why a food item came back at 3x the correct calories. The watchers don’t do anything a human can’t do. They do it at 2:47 AM, in twelve minutes, every time.

What Goes Wrong

The watchers aren’t magic. They have failure modes.

False confidence is the main risk. An agent that can write to production and commit code will occasionally be wrong with conviction. Our mitigation is the constrained tool whitelist and the investigation reports. Every action is documented. Every fix includes before/after values. When a watcher makes a bad call, the report makes it easy to find and revert.

Prompt drift is real. As the codebase evolves, the prompts need to reference current file paths and function names. A prompt that says “check completion_agent.py line 340” becomes misleading after a refactor. We treat prompts like code: they get updated alongside the source they reference.

Scope creep is tempting. When you have an agent that can fix production data, it’s easy to let it fix things that should require human judgment. The zucchini case is a good example. The watcher could have run the backfill across 165 users. It correctly chose not to, because that decision has blast radius. The prompt explicitly defines what “safe to auto-fix” means: single-record data quality issues with high-confidence evidence. Anything broader gets flagged.

What This Means for Production AI

Most of the conversation about AI agents focuses on capability: what they can do, how smart they are, which benchmarks they pass. The watchers taught us that the interesting problems are about constraint, trust, and feedback loops.

Constraint design matters more than capability. Claude Code can do a lot. The value of the watchers comes from limiting what it does. A tightly scoped agent that fixes serving ratios reliably is more valuable than an unconstrained agent that might fix anything.

Markdown reports are an underrated interface. The watchers produce human-readable investigation reports, not log files. This means the morning review takes five minutes instead of an hour. When something goes wrong, the reasoning is right there. Structured output for human review is as important as the automation itself.

Meta-debugging is a real pattern. The fixer watcher, an agent that investigates why another agent failed, sounds recursive. In practice, it’s one of the most useful watchers. Automated systems fail in automated ways. Having a second system that classifies those failures by root cause (code bug, data issue, model hallucination, timeout) turns noise into signal.

Start with your noisiest signal. We didn’t build five watchers on day one. We started with the bug watcher because user-reported issues were the most painful feedback loop. Once that worked, we noticed patterns in the data that led to the accuracy watcher. The error and GCloud watchers came from operational pain points that the first two watchers surfaced.

Headless CLI agents are production infrastructure. We treat claude -p the same way we treat a cron job or a background worker. It has a defined input, constrained permissions, a timeout, state tracking, and structured output. The fact that the “worker” is a language model instead of a Python function is an implementation detail.

The watchers run every day. Most of the time, they find nothing interesting. But when a serving formula silently breaks at 6 AM and gets fixed by 6:12 AM, before any user notices, that’s not a demo. That’s infrastructure.

Every month, I used to spend half a day assembling an investor update.

Open RevenueCat. Screenshot the MRR chart. Open Supabase. Run a SQL query I’d half-forgotten. Open Apple Search Ads. Navigate four menus deep to find the CPI. Open a Google Doc. Open Gamma. Start building slides. Realize I formatted it differently from last month. Start over.

The content of the update was never the bottleneck. The assembly was.

So I built a system where the update assembles itself.

What I Wanted

The end state I had in mind was simple:

1. One command (or one conversation with an AI agent) that pulls metrics from every data source at once

2. A structured interview about qualitative things the agent can’t know: product updates, strategic shifts, what surprised me

3. A living web page that renders the data, password-protected for investors

4. The whole thing done in under 30 minutes

Here’s what I actually built, in enough detail that you could replicate it.

Step 1: The Cursor Skill

The foundation is a Cursor/Claude skill. If you’re not using skills yet, the idea is simple: a markdown file that acts as an instruction set for an AI agent. It describes a workflow, lists the exact shell commands, SQL queries, and API calls to run, and tells the agent what to do with the results.

My investor update skill lives at alma-growth/skills/investor-update/SKILL.md. Here’s the structure:

1. Gather Metrics     ← automated, runs in parallel
2. Interview          ← the agent asks me 13 questions
3. Generate Output    ← structured markdown, ready to render

When I say “run the investor update skill,” the agent reads the file and begins. It doesn’t need further instructions.

Step 2: The Data Sources

The metrics layer hits six sources. Here’s exactly how:

RevenueCat — Subscription Revenue

RevenueCat has a clean V2 API. One call to their metrics overview endpoint returns everything useful: MRR, ARR, active subscriptions, active trials, revenue per platform. No scraping, no dashboards.

curl -s -X GET "https://api.revenuecat.com/v2/projects/[project_id]/metrics/overview" \
  -H "Authorization: Bearer $REVENUECAT_API_KEY" \
  -H "Content-Type: application/json"

The response includes mrr, active_subscriptions, active_trials, and enough to compute ARR on the spot. The MRR split between monthly and annual plans takes one more query — you cross-reference active subscription counts against known product IDs. No SDK required. Just HTTP.

Supabase Production — User Metrics

MAU, DAU, total users, retention funnels. All live in the production database. The Supabase MCP (Model Context Protocol) tool lets the agent query production directly without me opening a SQL editor.

The retention query I use is slightly involved: it’s a weekly cohort funnel that traces app_open events through sign_up, activation, and day_7_return. I keep the full query in a references file (references/retention_query.md) so the skill can reference it without bloating the main SKILL.md.

The MAU query is three lines:

SELECT COUNT(DISTINCT user_id) as mau
FROM food_items
WHERE created_at >= NOW() - INTERVAL '30 days';

Everything else is variations on that pattern.

Apple Search Ads — ASA Performance

ASA has an API, but it requires a signed JWT with a private key and a specific auth flow. I have a Python fetcher script that handles all of that:

cd alma-growth/ad-optimizers/apple-search-ads
python asa_data_fetcher.py --days 30

Outputs total spend, installs, and CPI for the month. The script handles token generation, pagination, and unit normalization (ASA returns spend in local currency, which I convert).

Meta Ads — Facebook/Instagram

The daily ad audit script handles this. It calls the Facebook Business SDK, pulls spend and performance for all active campaigns, and spits out a summary table.

cd alma-growth/ad-optimizers
python daily_ad_audit.py --days 30 --dry-run --no-ai

--dry-run means it won’t send an email. --no-ai skips the Claude summary step since the investor update skill handles that itself.

App Store Connect — Downloads

Apple’s App Store Connect Reporter API is the oldest and most annoying of the bunch, it requires a Java jar file and a properties file with API credentials. Once that’s set up, it works:

cd alma-growth/app-store-connect-api
python app_store_connect_reports.py --days 30

Returns total installs, updates, and platform breakdown for the month.

Google Ads

Handled by the Meta audit script’s companion. Spend and click data extracted the same way.

Step 3: The Interview

After the metrics are gathered, the agent asks me 13 questions, one at a time:

1. What product features shipped this month?

2. Any major fixes or reliability improvements?

3. What are users clearly responding to?

4. Did you ship or test any monetization changes?

5. What marketing activities actually happened?

6. Any partnerships signed, paused, or dropped?

7. Total ad spend breakdown by platform?

8. Any team changes?

9. Current team structure?

10. Cash in bank at month end?

11. What went better than expected?

12. What’s clearly not working or still messy?

13. Top 3 concrete priorities for next month?

These are the things an API can’t tell you. The agent takes my answers, combines them with the quantitative data, and produces the full update.

The output is structured markdown. Numbers first, narrative second. Same format every month so investors can scan it without re-learning the layout.

Note: I use a voice dictation tool to make it easy to just talk out loud as I answer these questions.

Step 4: The Web Page

This is where it gets interesting. Instead of building a slide deck, I render the update as a React page.

It looks like this:

At login: Alma logo, a password field, nothing else. Clean.

Once unlocked:

• Hero section with month, tagline, one-line summary

• Animated metric cards (numbers count up on scroll into view)

• Month-over-month comparison table

• Revenue breakdown

• Ad performance summary by platform

• Retention funnel table with weekly cohorts

• Major product releases (icons, titles, descriptions)

• Monetization strategy section

• Financial position with cash breakdown

• Two-column “Working Well / Needs Work” reflection

• Numbered priority list for next month

The entire thing is roughly 520 lines of React and 300 lines of CSS. It doesn’t use a charting library. Animated numbers are a 40-line custom hook with requestAnimationFrame. The styling uses our existing design tokens.

Updating it takes about 10 minutes: swap out the numbers, update the lists, commit, push. AWS deploys automatically.

What This Replaced

The old workflow involved Gamma.

If you haven’t tried Gamma, it’s an AI presentation tool that generates slides from text input. It’s genuinely good. You paste in a text outline and it produces a styled presentation in 30 seconds. For a while, it was the fastest path from “update notes” to “something I can share.”

But I kept running into the same friction: my update had specific formatting. I wanted numbers animated. I wanted MoM comparisons always side-by-side. I wanted the same layout, month after month, so investors could scan it in 90 seconds. Gamma would always give me something close but different. I’d spend time adjusting. The slides would live in a link that expired or required a login. The numbers were static.

The alternative, building it in HTML and CSS, used to feel like overkill for a two-person startup. It isn’t anymore.

With Cursor and a capable model, I described the page I wanted in plain English. The agent built the initial version in about 20 minutes. I gave feedback. Iterated. By the end of the day it was live and doing exactly what I wanted.

This is a meaningful shift. The definition of software is changing in front of us.

Software used to mean: a non-technical founder has an idea, briefs a developer, the developer codes it over days, deploys it, the founder waits. Or alternatively: a non-technical founder uses a no-code/low-code tool (Gamma, Webflow, Glide, Notion), trades customization for speed.

Those two options still exist. But there’s a third option now: describe what you want to an AI agent in a coding environment, get the code, ship it. The barrier between “I want a thing” and “the thing exists” has dropped dramatically.

I’m not saying this makes software engineers obsolete. The Cursor agent can’t architect a complex distributed system without guidance. It makes mistakes. It needs reviewing. But for a specific class of internal tools, dashboards, landing pages, update portals, data visualizations, the iteration loop has compressed from days to hours.

Gamma is a great product. There’s still a version of this world where most people use tools like it. But when the raw material (HTML, CSS, JavaScript) is this easy to generate and the deployment pipeline (Git + Vercel) is this frictionless, I find myself asking: what problem is the abstraction layer actually solving?

The value of software is shifting. Less about encoding behavior that’s hard to describe. More about describing behavior clearly enough that the agent can encode it for you.

What Still Requires Me

A few things the agent gets wrong every time:

Narrative judgment. The agent can write “Coaching 2.0 launched.” I need to write “Coaching 2.0 is landing well, unexpected finding is users seem genuinely impressed by the fact that Alma flags its own bugs, treating transparency as a feature.” That signal came from watching user reactions, not from a database query.

Prioritization. The agent can list everything that happened. I need to decide what matters. The SR&ED refund approval is worth mentioning. The specific thing we tried and abandoned is probably not.

Tone calibration. Investor updates walk a line. Honest without being alarming. Transparent without being scattered. The agent drafts in the right format. I edit for the right register.

The Result

My February update took about 25 minutes from starting the skill to having a live URL.

The page has animated metrics, a retention funnel table, a side-by-side reflection section, and a priorities list. It’s password protected. It renders on mobile. The numbers animate on scroll. The brand tokens match the rest of the site.

The investors see it. They send back questions. I answer. That’s the loop.

The slide deck is gone. The assembly ritual is gone. The monthly half-day is now a half-hour.

There’s an exhibit at the Montreal Museum of Fine Arts right now that stopped me in my tracks.

Chairs. Hundreds of them. Spanning centuries of design, laid out like a visual argument for something I couldn’t quite articulate in the moment.

A Windsor chair from the 1700s. Thonet’s bent beech bentwood. Eames molded plywood. Verner Panton’s single-piece plastic S-curve. Chairs made from steel, rope, recycled materials, algorithms. Chairs designed for posture, for status, for a particular living room in a particular decade. Chairs so uncomfortable they were clearly never meant to be sat in.

And I kept thinking: why are we still doing this?

We solved the chair. You need something to sit on. Four legs, a seat, maybe a back. Done. Problem solved centuries ago.

Except we never stopped.

Every generation redesigns the chair from scratch. New materials arrive and designers reach for them immediately. Cultural attitudes shift, toward minimalism, toward maximalism, toward sustainability, toward spectacle, and the chair shifts with them. Ergonomics becomes a field and suddenly the chair is a medical device. The home office becomes a thing and suddenly we need an entirely new category of chair. A new generation of designers decides everything that came before was wrong, starts over, and produces something that makes the previous generation uncomfortable in every sense.

The chair is never finished. Not because it’s broken. Because we’re not.

Humans are in a perpetual state of discontent and curiosity. We don’t optimize and then stop. We optimize, get comfortable with the solution, and then immediately start wondering if the solution was the right question. It’s not a flaw in our thinking. It’s the mechanism of how we think.

I keep hearing a version of the same fear about AI: if AGI can do this, what’s left for us?

It’s a reasonable thing to wonder. If a sufficiently powerful system can produce better design, better writing, better research than any individual human, what does the human add?

The chair answers this.

We didn’t stop designing chairs when mass manufacturing made them cheap and available to everyone. We didn’t stop when ergonomics research told us exactly what the “optimal” seated position was. We won’t stop when AI can generate ten thousand chair variations in the time it takes a human designer to sketch one.

Because the chair was never purely about the chair. It’s about the conversation a designer is having with the culture they live in. It’s about the material someone discovered last year that suggests a new form. It’s about a reaction against what came before, a new idea about what a home should feel like, a problem that didn’t exist until five minutes ago.

AGI doesn’t end that conversation. Nothing ends that conversation. It’s not a problem to be solved. It’s an expression of what we are.

The things we keep returning to, the things we never declare finished, are the ones that carry human meaning. Not just utility. Meaning. The chair has to sit right and look right and feel like it belongs in this moment, in this room, to this person. That’s not a specification you can freeze. It evolves because we evolve.

The fear of AI replacing human creativity assumes creativity is a function being performed. Something with inputs and outputs that a better system could run more efficiently.

But standing in that museum, looking at a hundred years of chairs that were each, in their moment, a definitive statement about what a chair should be, I don’t think that’s what’s happening. What I was looking at was evidence of something relentless and unresolvable in us. The drive to keep asking the question, even after you’ve answered it.

That doesn’t go away with better tools. It goes faster.

We’ll still be designing chairs in fifty years. They’ll look nothing like what we have now. Some of them will be made with AI, some of them will be made in reaction to AI, some of them will be made by designers who can’t explain why they made the choices they made except that it felt right.

And someone, somewhere, will be standing in a museum looking at all of them, wondering the same thing I wondered.

Why are we still doing this?

And the answer will still be: because we can’t help it. Because that’s the point.

I had a conversation with two friends over the weekend. One works in journalism, the other in design. Both smart, thoughtful people. Neither is anti-technology. But when AI came up, the objections poured out. Electricity. Creativity. Centralized power. Thinking. War.

I’ve heard versions of these objections many times now. From friends, from other founders, from strangers on the internet. Some of them I think are overstated. A couple of them keep me up at night.

Here’s where I land on each one.

1. Electricity and the Environment

This is the most common objection I hear, and the one I think is most overstated relative to the actual data.

Yes, data centers use a lot of electricity. And yes, that number is growing fast. But “a lot” needs context. Data centers currently account for about 1-1.5% of global electricity consumption, projected to reach roughly 3% by 2030. Transport, by comparison, accounts for about 30% of global energy demand. Industry consumes another ~40% of electricity demand growth. The sectors that are genuinely hard to decarbonize dwarf AI’s energy footprint by an order of magnitude.

That doesn’t mean the concern is irrelevant. Energy use is growing, and the trajectory matters. But I think the medium-term calculus is fairly clear: AI is already being deployed to optimize energy grids, accelerate materials science for better batteries, improve agricultural efficiency, and model climate systems with higher fidelity than we’ve ever had. These aren’t theoretical applications. They’re happening now. The IEA estimates that widespread adoption of AI in end-use sectors could deliver 1,400 megatons of CO2 reductions by 2035, three to four times larger than projected data center emissions over the same period.

The net energy impact of AI over a 10-year horizon is almost certainly positive. The World Economic Forum published a framework for “net-positive AI energy” specifically arguing this point, with data across 130+ real-world use cases. The short-term costs are real but manageable, and they’re the kind of problem that engineers and policy makers know how to solve. We’ve done this before. Every major computing revolution came with an energy conversation. The internet was supposed to consume unsustainable amounts of power. It did consume more power. And then efficiency gains, renewable energy deployment, and better hardware brought the cost curve down.

I’d bet the same pattern plays out here.

2. Creativity Is Dead

This one comes up a lot in my conversations with designers and writers. The fear is that AI-generated content is going to flood every channel with mediocre remixes until nothing feels original anymore.

I get the concern. But I think it misreads history.

Every new creative medium has triggered this exact reaction. Photography was supposed to kill painting. Film was supposed to kill theater. Synthesizers were supposed to kill music. Auto-tune was supposed to kill singing. Photoshop was supposed to kill photography. In every single case, the medium got absorbed, the best creators adapted, and the bar for what counted as compelling work shifted.

That’s already happening with AI. I’m seeing creative people lean in and produce work that wouldn’t have been possible six months ago. New visual styles. New ways of combining mediums. Entirely new creative workflows where the human is directing, curating, and shaping output in ways that feel genuinely novel.

And for the concern about social media becoming “fake,” I’d push back gently: most of social media was already heavily processed before AI entered the picture. Photoshopped images, filtered videos, ghost-written captions. We already lived in a world of manufactured content. AI gives us more tools, but the underlying dynamic of seeking authenticity and real storytelling was happening regardless. The creators who connect with audiences have always been the ones who feel real. That hasn’t changed.

The real shift isn’t that creativity is dying. It’s that the barrier to producing decent creative output is dropping to near zero. Which means the thing that differentiates great work from mediocre work is taste, perspective, and editorial judgment. Those are deeply human qualities. If anything, they become more valuable, not less.

3. Deep Thinking and Rote Work

A friend asked me: “If AI does all the work, what happens to our ability to think?”

It’s a fair question. There’s real cognitive science behind the idea that struggling through difficult work builds mental capacity. If you never do the hard thing yourself, you might lose the ability to do it at all.

But I think this frames it wrong.

Steve Jobs called the computer “a bicycle for the mind”, inspired by a Scientific American study showing that a human on a bicycle was the most efficient species on the planet in terms of locomotion. The computer removed some of the manual drudgery of calculation and organization, and it freed people to think about harder problems. The calculator did the same thing a generation earlier. Nobody argues that calculators made us worse at math in the ways that matter. They made arithmetic less central and freed us to focus on higher-order mathematical thinking.

AI is a motorcycle for the mind. It’s faster, more powerful, and covers more ground. And the question it raises is the same one every previous tool raised: where are you going?

If you use AI to avoid thinking entirely, that’s a problem. If you use it as a thought partner, a sparring partner that challenges your assumptions and helps you iterate faster on ideas, it sharpens your thinking. I experience this every day. My best thinking happens in conversation with AI, not because it thinks for me, but because it forces me to articulate what I actually believe and then stress-tests it.

The real risk isn’t that AI replaces thinking. It’s that people choose not to think. But that’s a human discipline problem, not a technology problem. The people who ground themselves in clear principles, who know what questions they’re trying to answer, who use AI to go deeper rather than to avoid depth entirely, they’re going to be dramatically more capable than they were before.

I’ll acknowledge that the pace of change makes people nervous. That’s legitimate. We’re adapting to a new tool faster than we’ve adapted to any tool before. But the adaptation pattern is the same: figure out what to delegate, figure out what to own, and lean into the parts that require your judgment.

4. Centralization of Power

This is where my concerns start to get real.

The economics of AI are concentrating an extraordinary amount of capability in a very small number of companies. Training frontier models costs hundreds of millions of dollars, with costs growing at roughly 2.4x per year since 2016 and projected to exceed $1 billion by 2027. The compute infrastructure requires billions more. The talent pool is small and getting smaller relative to demand. The result is that a handful of companies, mostly in one country, are building the systems that will increasingly mediate how knowledge work, creative work, and even governance gets done.

That’s concerning on its own. Mix in geopolitics, and it gets more concerning.

McKinsey estimates that generative AI could add $2.6 to $4.4 trillion annually to the global economy, with roughly 75% of that value concentrating in just four functional areas. The IMF projects that 40-60% of jobs in advanced economies will be affected by AI. That value is going to flow disproportionately to the companies that own the models and the infrastructure. If you’re a small country without sovereign AI capability, you’re essentially renting your cognitive infrastructure from a foreign corporation. The leverage dynamics there are uncomfortable.

This is where I see real hope in open source. Open-weight models like Llama, Mistral, DeepSeek, and others are creating an alternative path where capability isn’t locked behind a single provider. Countries and organizations can run models on their own infrastructure, fine-tune them for their own needs, and maintain some degree of sovereignty over their AI stack.

But open source alone isn’t enough. This requires active policy work. Data sovereignty frameworks. Investment in domestic compute infrastructure. Serious thinking about how the economic gains from AI get distributed rather than concentrated. These aren’t problems that the market will solve on its own. The default trajectory is more concentration, not less.

I’ve written about this in the context of Canada’s AI strategy, and I think every country needs to be having this conversation. The window for shaping how power gets distributed is now. Once the infrastructure is built and the dependencies are locked in, it becomes much harder to unwind.

5. AI in War

This is the one that genuinely scares me.

We already saw what drones did to the calculus of armed conflict. Research from the University of Michigan Press documents how combat drones reduce the political costs of military action by eliminating military casualties and increasing perceived precision. Politicians who would have faced massive domestic opposition for deploying troops can deploy drones with minimal public scrutiny. As one study put it: “to the degree that substituting machines for humans lowers the costs for fighting, conflict will become more frequent, but less definitive.”

Now extend that logic to autonomous systems. If the entire apparatus of conflict can be largely automated, what does the threshold for going to war look like? If there’s no body bag count, no grieving families on the evening news, no political cost at all, what restraint remains?

We’ve already seen early versions of this play out. Israel’s Lavender and Gospel AI systems have been used to generate thousands of targeting recommendations in Gaza, with human reviewers reportedly spending as little as 20 seconds per target before approving strikes. The Pentagon’s Replicator program is developing AI-powered weapon swarms designed for highly autonomous operations. The line between “AI-assisted” and “AI-directed” military action is getting blurry, and the pace of deployment is outrunning the pace of governance.

I don’t have a clean answer here. I think this is genuinely one of the hardest problems of our generation. The technology exists. Multiple nations are developing it. And the incentive structures push toward deployment, not restraint.

What I’ll say is this: the conversation about AI in warfare needs to be happening with the same urgency as the conversation about nuclear proliferation. In December 2024, the UN General Assembly voted 166-to-8 to adopt a resolution on lethal autonomous weapons systems. That’s a start. But resolutions without enforcement mechanisms are paper shields. The potential for AI to lower the barrier to conflict, to enable asymmetric warfare at unprecedented scale, and to remove the human judgment that has historically served as a check on escalation is real and immediate. This isn’t a hypothetical risk for 2035. It’s a 2026 problem.

Where I Net Out

Three of these objections, electricity, creativity, and thinking, I believe are transition costs. Real, but manageable. The pattern of every previous technological revolution suggests we’ll adapt, and the benefits will substantially outweigh the disruption.

Two of them, centralized power and AI in warfare, I believe are genuinely existential. Not because the technology itself is inherently dangerous, but because the human systems for governing it are not keeping pace.

I’m optimistic about AI. I’m building with it every day. But optimism without honesty about the risks is just salesmanship. The people dismissing every concern are as wrong as the people who think we should stop building entirely.

The honest position is somewhere in the middle: lean in, build thoughtfully, and fight like hell on the governance questions that actually matter.

References

1. IEA - Data Centres and Data Transmission Networks - Data centers account for ~1-1.5% of global electricity, projected to reach ~3% by 2030.

2. IEA - Energy Efficiency 2025: Transport - Transport accounts for ~30% of global energy demand.

3. IEA - AI and Climate Change - AI could deliver 1,400 Mt CO2 reductions by 2035, 3-4x projected data center emissions.

4. World Economic Forum - Net-Positive AI Energy by 2030 - Framework arguing AI-enabled savings can exceed AI’s energy consumption.

5. The Marginalian - Steve Jobs: Bicycle for the Mind (1990) - Original PBS/NOVA interview where Jobs explains the analogy.

6. Epoch AI - How Much Does It Cost to Train Frontier AI Models? - Training costs growing 2.4x/year, projected to exceed $1B by 2027.

7. McKinsey - The Economic Potential of Generative AI - $2.6-4.4T annual economic potential, 75% concentrated in four areas.

8. IMF - AI Will Transform the Global Economy - 40% of global jobs affected, 60% in advanced economies.

9. Walsh & Schulzke - Drones and Support for the Use of Force - Research on how drones reduce political costs of military action.

10. Gartzke - Blood and Robots: Remotely Piloted Vehicles and the Politics of Violence - “Conflict will become more frequent, but less definitive.”

11. +972 Magazine - Lavender: The AI Machine Directing Israel’s Bombing Spree in Gaza - Investigation into Israel’s AI targeting systems.

12. The Guardian - Israel Used AI to Identify 37,000 Hamas Targets - Human reviewers spent ~20 seconds per AI-generated target.

13. Bajak et al. - AI-Powered Autonomous Weapons Risk Geopolitical Instability - Pentagon’s Replicator program and autonomous weapon swarms.

14. Stop Killer Robots / UN GA - 166 States Vote to Adopt LAWS Resolution - December 2024 UN vote on lethal autonomous weapons regulation.

At Alma, we’re a small team. We don’t have a creative department. We don’t have a media buyer. For most of our existence, we didn’t run paid ads at all.

In less than a day, we shipped 13 carousel ad campaigns (10 educational advertorials and 3 geo-targeted city guides) totaling 116 carousel cards, each linking to a fully designed landing page with original copy, structured data for SEO, and scroll-depth analytics. The whole pipeline, from concept to live ads, took about two hours per batch.

No dedicated designer. No copywriter. No agency. No Canva.

This isn’t a story about AI replacing jobs. It’s a story about what becomes possible when the barrier between “idea” and “live campaign” drops to near zero.

The Old Way Was Expensive Enough to Kill Ideas

Before this, our ad workflow looked like most early-stage startups:

1. Have an idea for a campaign

2. Brief a designer (or open Figma yourself)

3. Write copy in a Google Doc

4. Export assets in 4 different aspect ratios

5. Upload to Meta Ads Manager manually

6. Build a landing page (or worse, send traffic to your homepage)

7. Wait days. Repeat.

The real cost wasn’t money. It was activation energy. Most campaign ideas died in step 2 because the effort-to-test ratio was absurd. You’d spend a week building something to discover it doesn’t convert, then start over.

We needed a system where the cost of testing an idea was close to zero.

What We Actually Built

The pipeline has four layers, each one a Python script or a React config file:

1. Image Generation (Programmatic)

We generate ad creative images programmatically. Not generic stock photos. Structured compositions with our brand system (colors, typography, layouts) applied automatically. For our city guide campaigns, each restaurant gets a card. For our advertorial campaigns, we generate cards around specific nutritional concepts. The visual language is consistent because it’s code, not a designer’s memory.

2. Landing Pages (Config-Driven)

Every landing page is a React component driven by a JSON-like config object. Want a new advertorial about the protein myth? Write a config with a title, sections, and a CTA. Want a city guide for San Francisco? Write a config with 10 restaurants, their descriptions, highlights, and links. The component handles layout, SEO meta tags, JSON-LD structured data, scroll tracking, and CTA analytics automatically.

Adding a new page is 15 minutes of writing content. Not design. Not code.

3. Meta Ads API (Deployment Scripts)

This is where it gets interesting. Instead of clicking through Ads Manager, we deploy campaigns programmatically:

• Create campaign with objective and budget

• Create geo-targeted ad sets (SF residents see SF restaurants, NYC sees NYC)

• Upload carousel card images via API

• Build carousel creatives with UTM-tagged links

• Create ads and attach them to ad sets

• Activate or pause with a flag

One Python script. Three cities. Fifteen carousel cards. Geo-targeting, conversion optimization, and budget allocation, all configured in code. Run it, and the ads are live.

4. Analytics (Closed Loop)

Every landing page tracks scroll depth, CTA clicks, and page views via PostHog. Every ad link carries UTM parameters that connect Meta spend to on-page behavior. We can see exactly which city, which carousel card, and which scroll depth led to a download.

The Two-Hour Campaign

Here’s what the city guide campaign looked like in practice:

Hour 1: Write restaurant descriptions for SF, NYC, and LA. Ten restaurants per city. This was the bottleneck, and it was the creative bottleneck, not the production bottleneck. I guided the AI, fact-checked claims, adjusted tone, and shaped the editorial voice. The research, structuring, and first drafts were AI-assisted.

Hour 2: Generate carousel images. Write the deploy script. Dry-run. Deploy. Push landing pages to production. Activate ads.

By the end, we had:

• 3 SEO-optimized landing pages with 10 restaurants each

• 3 geo-targeted ad sets ($30/day each)

• 18 carousel cards with custom images (title + 4 restaurants + CTA per city)

• Full analytics pipeline

• JSON-LD structured data for Google rich results

Total ad spend on creative production: $0.

But the city guides were just one campaign. Here’s everything we shipped with this pipeline: 13 carousel campaigns across two categories, all deployed the same way.

Every Campaign We Shipped (With the Actual Ad Copy)

All of these are live on Meta right now. Each one was conceived, designed, written, and deployed with the same pipeline described above. Title card, content cards, CTA card. All generated programmatically from our brand template system.

Educational Carousels (10 campaigns)

These use a swipeable format: a gallery-style title card, 7-9 content cards with data and images, and a closing CTA card. Every carousel links to a dedicated advertorial landing page.

1. What 2,000 Calories Looks Like - 9 cards, LEARN_MORE → alma.food/what-2000-looks-like

A Big Mac, fries, and a Coke = 2,000 calories. A full Mediterranean spread with fish, hummus, salad, fruit, and nuts = also 2,000 calories.

Same number. Wildly different plates.

Swipe to see what 2,000 calories actually looks like across 7 different eating styles.

Cards: Title → Fast Food (1 Meal) → Mediterranean (A Full Day) → “Healthy” Snacking → Japanese (Dozens of Dishes) → Pizza Night (3 Slices + Beer) → Indian Thali (A Feast) → Mindless Snacking → CTA

2. The Protein Myth - 9 cards, LEARN_MORE → alma.food/protein-myth

Granola: 4g protein per serving. Greek yogurt: 17g.

Almond milk: 1g per cup. Regular milk: 8g.

Most “high-protein” marketing is just marketing.

Swipe to see the real protein numbers behind 7 common foods.

Cards: Title → Granola (4g) → Peanut Butter (7g) → Quinoa (8g) → Almond Milk (1g) → Avocado (4g) → Protein Bar (10g) → Hummus (2g) → CTA

3. Guess the Calories - 10 cards, LEARN_MORE → alma.food/guess-the-calories

That açaí bowl? 680 calories. The Caesar salad? 520. Your “healthy” green smoothie? 450.

Most people underestimate their food by 40-50%.

Swipe to see the real numbers. How close can you get?

Cards: Title → Açaí Bowl (680) → Caesar Salad (520) → Trail Mix (700) → Green Smoothie (450) → Sushi (850) → Avocado Toast (550) → Protein Bar (380) → Overnight Oats (580) → CTA

4. A Love Letter to Food - 10 cards, DOWNLOAD → App Store

Bread is 10,000 years old and still the first thing we reach for.

Honey never spoils. Tomatoes were once thought poisonous. Half the planet eats rice every single day.

This isn’t about macros. It’s about the food itself.

For people who love food, not to restrict it, but to understand it.

Cards: Title → Dear Bread → Dear Eggs → Dear Rice → Dear Olive Oil → Dear Chocolate → Dear Tomato → Dear Honey → Dear Lemon → CTA

5. Meal Prep vs. Reality - 10 cards, DOWNLOAD → App Store

The overnight oats you planned: layered, beautiful, art. The overnight oats you ate: gray mush from a jar while standing.

Both counted. Both were 380 calories.

Alma tracks what you actually eat, not the Pinterest version.

Swipe to see the plan vs. the reality.

Cards: Title → Chicken & Quinoa (Plan) → Desk Lunch (Reality) → Overnight Oats (Plan) → Gray Mush (Reality) → Salmon Salad (Plan) → Sad Desk Salad (Reality) → Berry Smoothie (Plan) → Protein Shake (Reality) → CTA

6. The Protein Gap - 10 cards, LEARN_MORE → alma.food/the-protein-gap

An egg has 6g of protein. Not 15. A café smoothie bowl? 9g. Not 30. Peanut butter toast? 7g. Not 15.

Most people overestimate protein in common foods by 2-3x.

Swipe to see how much protein is actually in your food.

Cards: Title → Egg (6g) → Yogurt Parfait (12g) → PB Toast (7g) → “Protein” Smoothie Bowl (9g) → Salmon Fillet (17g) → Quinoa Bowl (8g) → Hummus & Pita (6g) → Chicken Breast (54g) → CTA

7. Hidden Sugar - 10 cards, LEARN_MORE → alma.food/hidden-sugar

Your oat milk latte? 28g of sugar. The granola? 24g. The açaí bowl? 42g, more than a can of Coke.

WHO recommends under 25g of added sugar per day. Most people hit that before lunch.

Swipe to see where the sugar is hiding.

Cards: Title → Oat Milk Latte (28g) → Granola (24g) → Açaí Bowl (42g) → Flavored Greek Yogurt (19g) → Dried Mango (27g) → Kombucha (16g) → Teriyaki Bowl (22g) → Daily Total: 89g → CTA

8. The Serving Size Lie - 10 cards, LEARN_MORE → alma.food/serving-size-lie

A “serving” of cereal is 3/4 cup. Nobody pours that. A “serving” of ice cream is 2/3 cup. Three bites. A “serving” of peanut butter is 2 tbsp. A thin film.

If every serving is double, your 1,800-calorie day is actually 3,400.

Swipe to see the label vs. what you actually pour.

Cards: Title → Cereal (160 vs. 530) → Olive Oil (120 vs. 360) → Pasta (200 vs. 400) → Orange Juice (110 vs. 220) → Peanut Butter (190 vs. 380) → Ice Cream (230 vs. 520) → Chips (140 vs. 370) → Daily Gap: +1,630 → CTA

9. Invisible Calories - 10 cards, LEARN_MORE → alma.food/invisible-calories

Handful of trail mix: 280 cal Afternoon latte: 190 cal Cheese while cooking: 210 cal Glass of wine: 150 cal “Just a bite” of the kid’s food: 130 cal

Total: 1,175 calories of “nothing.”

Swipe to see the calories you’re not tracking.

Cards: Title → Trail Mix at Desk (280) → Afternoon Latte (190) → Dark Chocolate (120) → Cheese While Cooking (210) → Glass of Wine (150) → Spoonful of PB (95) → Kid’s Leftovers (130) → Total: 1,175 → CTA

10. Same Name, Different Calories - 10 cards, LEARN_MORE → alma.food/same-name-different-calories

“Caesar salad” can be 380 or 1,150 calories. “Pad Thai” can be 400 or 1,100. “Turkey sandwich” can be 350 or 890.

The name on the menu tells you nothing about the nutrition.

Swipe to see how much the same dish can vary.

Cards: Title → Caesar Salad (380 vs. 1,150) → Burrito Bowl (410 vs. 980) → Margherita (550 vs. 1,200) → Pad Thai (400 vs. 1,100) → Salmon Bowl (450 vs. 920) → Smoothie Bowl (320 vs. 780) → Turkey Sandwich (350 vs. 890) → Average Gap: 594 → CTA

City Guide Carousels (3 campaigns, geo-targeted)

Each city gets its own ad set targeted ONLY to people in that metro. Six cards per carousel: title card, four restaurants, CTA card. Each links to a long-form advertorial landing page with the full top-10 list, SEO structured data, and scroll tracking.

11. San Francisco - 6 cards, geo: SF only → alma.food/healthy-restaurants-san-francisco

San Francisco has some of the best healthy restaurants in the country.

From Greens, the vegetarian pioneer with Golden Gate views, to Nopa’s organic wood-fired kitchen sourcing from 20+ local farms.

We put together a guide to the 10 best healthy restaurants in SF. Swipe to see our picks.

Cards: Title → Greens (Fort Mason) → Nopa (North Panhandle) → Beloved Café (Mission) → Blue Barn (Marina) → CTA

12. New York City - 6 cards, geo: NYC only → alma.food/healthy-restaurants-nyc

NYC’s healthy restaurant scene goes way beyond sad desk salads.

From Eleven Madison Park’s plant-based fine dining to Dirt Candy’s mind-bending vegetable tasting menus, healthy food in NYC is actually some of the most exciting food in the city.

Here are the 10 best healthy restaurants in New York. Swipe to explore.

Cards: Title → Eleven Madison Park (Flatiron) → abcV (Flatiron) → Dirt Candy (Lower East Side) → Avant Garden (East Village) → CTA

13. Los Angeles - 6 cards, geo: LA only → alma.food/healthy-restaurants-la

LA practically invented the wellness-dining movement.

From Crossroads Kitchen, the vegan restaurant that convinced skeptics, to Destroyer, where a 2-Michelin-starred chef makes avocado toast into fine art.

Here are the 10 best healthy restaurants in LA. Swipe to see our picks.

Cards: Title → Crossroads Kitchen (Melrose) → Destroyer (Culver City) → Café Gratitude (Venice) → Gracias Madre (WeHo) → CTA

Total: 13 campaigns. 116 carousel cards. 13 landing pages. $0 in creative production.

What This Changes for Early-Stage Teams

The implication isn’t “fire your designer.” It’s more fundamental than that.

1. You can test 10x more ideas.

When the cost of going from idea to live ad is two hours and zero dollars, you stop debating which campaign to run. You run all of them. The bad ones die fast. The good ones get budget. This is how a two-person team competes with a company that has a media buying agency.

2. The landing page IS the ad.

Most startups send ad traffic to their homepage and wonder why conversion is low. When you can spin up a purpose-built landing page for every campaign in minutes, every ad gets a dedicated destination. Our city guides aren’t selling Alma directly. They’re providing genuine value (a restaurant guide) with a soft CTA. The content does the selling.

3. Iteration is instant.

Our SF guide started with 4 restaurants. Feedback said “make it a top 10.” Twenty minutes later, it was a top 10: researched, written, deployed, and live. Try asking an agency for that turnaround.

4. The code is the brand guideline.

When your creative pipeline is code, consistency is automatic. Colors, typography, spacing, tone. They’re constants in a file, not a PDF that nobody reads. Every new campaign inherits the brand system by default.

What Still Requires a Human

Let me be honest about where AI falls short in this pipeline:

Editorial judgment. AI can research and draft restaurant descriptions. It cannot tell you that Greens Restaurant’s story about being recognized by the New York Times is the detail that makes the copy compelling. That’s taste.

Strategic direction. The decision to build geo-targeted city guides aimed at health-conscious diners in specific metros: that’s strategy. AI didn’t suggest that. We had a hypothesis about local intent and built a fast way to test it.

Brand voice. Every piece of copy got edited. Not rewritten. Edited. The difference between AI-generated marketing copy and copy that sounds like your brand is usually 15 minutes of a human with opinions.

Quality control. Are these restaurants still open? Is the Michelin star current? Does the website link work? AI gets you 90% there. The last 10% is checking.

The Stack

For anyone who wants to build something similar:

• Landing pages: React + Vite, config-driven components, deployed via Git push

• Image generation: Python scripts with Pillow/HTML rendering

• Ad deployment: Facebook Business SDK (facebook-business Python package)

• Analytics: PostHog for page events, UTM parameters for attribution

• Content: Claude for research and drafting, human for editing and judgment

• Hosting: Vercel (or similar) with instant deploys

The total codebase for the ad pipeline is maybe 1,500 lines of Python across the deploy scripts. The landing page component is ~250 lines of React. The config for each campaign is ~100 lines of JavaScript. The image generation (title/CTA cards and content cards) adds another ~500 lines.

The Takeaway

The most expensive part of marketing at an early-stage startup isn’t ad spend. It’s the time between having an idea and knowing if it works.

We didn’t build an AI marketing department. We built a pipeline that makes the distance between “what if we tried...” and “here’s the data” as short as possible.

The ads are running. The landing pages are live. Thirteen campaigns, three cities, ten advertorial concepts. If the city guides don’t convert, we’ll know by Friday and try something else by Saturday. If “Invisible Calories” outperforms “The Protein Myth,” we’ll shift budget in an hour.

That’s the actual unlock. Not cheaper creative. Faster learning.

Curious about what we’re building? Alma is an AI nutrition coach that actually remembers you. Free to start.

At Alma, we’re on a mission to build the best AI nutrition coach. But a coach that doesn’t know you is just a chatbot with opinions. Tracking is the foundation, and last year, we hit a wall.

Users loved the natural language experience. But as we scaled, the cracks showed. The same user might say “my usual smoothie” on Monday and “the green one I had yesterday” on Tuesday. They’d track “chicken stir fry” and expect Alma to remember the exact recipe they described three weeks ago.

Our food logging system learned to handle this (we shipped that story here). But knowing what you eat is only half the battle. The other half? A coach who actually remembers your journey.

The Problem with Generic AI Coaching

Before we rebuilt the coaching system, every conversation started from scratch:

• Users re-explained their preferences (”I’m vegan, remember?”)

• The AI gave generic advice (”aim for 0.8g protein per pound”)

• No continuity between conversations

• No proactive engagement based on patterns

It felt like meeting a new nutritionist every time you opened the app. Not because the AI was “dumb” - but because we hadn’t given it the right structure to be helpful.

The Core Insight: Map Preferences to Frameworks

Our breakthrough came from nutrition psychology research, not prompt engineering.

We studied evidence-based coaching methodologies:

• Precision Nutrition (John Berardi, PhD)

• Intuitive Eating (Evelyn Tribole & Elyse Resch)

• Motivational Interviewing in Nutrition

• Solution-Focused Brief Therapy

• Behavioral Science (Katy Milkman)

Then we identified two key axes that determined coaching style:

1. Nutrition experience: How much do they already know?

2. Feedback style: How do they want to receive coaching?

This created nine coaching combinations. Each maps to specific research-backed approaches.

Example: Same data, three different voices

User logged 6 out of 7 days this week:

Beginner + Celebratory: “You logged 6 days in a row - that’s building a real habit! What helped you stay consistent?”

Experienced + Tactical: “6/7 days logged. You’re building momentum. One strategy: set a phone reminder for the day you typically miss.”

Knowledgeable + Exploratory: “Your 6/7 logging pattern is solid. Research shows consistency trumps perfection for long-term behavior change. What made the difference between the days you tracked vs the one you didn’t?”

The magic: Users set their preferences once. Every interaction adapts automatically.

Three Coaching Experiences

We didn’t build one monolithic chatbot. We built three specialized modes:

1. Weekly Check-ins (Proactive Coaching)

Every Sunday, the coach reviews your week and sends a personalized check-in. Not generic “great job!” messages - specific observations about YOUR patterns.

It looks at your data, identifies what’s working and what isn’t, sets a measurable focus for the week, and creates an opening message that feels like someone spent time with your data.

User impact: You wake up Sunday to coaching that feels personal, not algorithmic.

2. Nutrition Q&A (On-Demand Intelligence)

When you ask questions, the coach combines:

• Your actual meal data

• Curated nutrition research

• Your stated goals

The result: Evidence-based answers grounded in YOUR context.

Ask “How’s my protein?” and you get your protein trend visualization plus analysis based on your muscle gain goal and eating patterns - not generic advice from a textbook.

3. Natural Conversations (Follow-ups)

The coach remembers the conversation. No re-explaining context.

Sunday: “Your protein was inconsistent this week...” Tuesday: “How’s protein going?” Response: “Since Sunday, you’ve hit your goal 2/2 days. That’s the consistency we’re looking for.”

Memory Without Conversation Logs

Here’s the thing about AI: it doesn’t actually “remember” anything. Context windows don’t span weeks.

Our solution: structured memory.

After every weekly review, the coach saves:

• Specific observations (numbers, patterns, dates)

• What worked and what didn’t

• Recommendations given

Next week, it reads its own notes. Just like a human nutritionist would.

Result: Week-over-week continuity that feels natural.

“Last month I noticed you ate less on weekends. You’ve improved - now only 100 cal below average vs 500 before.”

Show Progress, Not Spinners

We rethought how AI responses should feel.

Traditional approach: User asks → Spinner → Wall of text

Our approach: User asks → “Analyzing your protein intake...” ✓ → Graph appears → Analysis continues

When you ask “How are my macros?”, you see:

1. Brief context

2. Graph visualization (appears inline)

3. Personalized analysis

The system orchestrates UI elements, not just text. When it accesses data, visualizations appear at the right moment in the response.

Users tolerate latency when they see progress. The experience feels interactive, not like waiting for a slow website.

Evidence-Based, Not Generic

Generic AI gives generic nutrition advice. We built something different.

When you ask a nutrition question, the system:

1. Finds relevant research articles and excerpts

2. Analyzes your personal data

3. Synthesizes both into a response

Example: User (vegetarian): “Should I take iron supplements?”

The coach checks your iron intake from food logs, retrieves research on plant-based iron absorption, considers your dietary preferences, and responds with personalized guidance that references both your data and scientific sources.

This isn’t “retrieve and regurgitate” - it’s synthesis.

Shipping It: Test Kitchen to Production

Phase 1: Test Kitchen We dogfooded it ourselves and with early supporters for weeks. Found critical bugs, built confidence in the system, and learned what actually mattered to users.

Phase 2: Fast Feedback Loops Thumbs down feedback went straight to our inbox. Not buried in a dashboard. Bug reports often got fixed same-day.

What we learned: Speed matters more than perfection. Users forgave early issues because we fixed them fast.

What We Learned

1. Personalization ≠ Bigger Models

We spent more time on the coaching methodology framework than model selection. The right structure beats raw intelligence every time.

2. Context Windows ≠ Memory

Real memory is structured, not conversational transcripts. Save observations, not logs.

3. Evidence-Based > Generic

Grounding responses in research frameworks (Precision Nutrition, Intuitive Eating, etc.) made the coaching feel authoritative. Users trust science + data, not “AI opinions.”

4. Show Progress, Not Spinners

Streaming with visible progress increases perceived speed dramatically. Users tolerate latency when they see work happening.

5. Dogfood Relentlessly

Internal use caught most critical issues before they reached users. Build for yourself first.

6. Ship Gradually, Watch Obsessively

Gradual rollout let us catch issues at small scale. Kill switches gave us confidence to move fast.

7. Fail Gracefully

When the system can’t answer perfectly, it acknowledges limitations. Partial answers beat cryptic errors.

What’s Next

We’re live with all premium users. Weekly coaching runs automatically every Sunday. Conversations feel natural and contextual.

Coming improvements:

• Proactive pattern detection between check-ins

• Multi-modal coaching (image-based feedback)

• Deeper goal management capabilities

The vision: A coach that knows you better than you know yourself. Not because it’s “smarter,” but because it pays attention to patterns you miss.

The Takeaway

We didn’t build a chatbot with nutrition opinions. We built a coach that:

• Adapts its voice without prompting

• Remembers your journey through structured notes

• Shows you data inline, not descriptions

• Grounds advice in research frameworks

The key insight: Personalization at scale isn’t about prompt engineering or bigger models.

It’s about:

1. Mapping user preferences to evidence-based frameworks

2. Building structured memory, not conversation logs

3. Showing progress and data inline as responses stream

4. Failing gracefully when uncertain

Users say it feels like having a personal nutritionist. That’s not because we built smarter AI - it’s because we built better architecture around the AI.

The difference between a chatbot and a coach isn’t intelligence. It’s memory, structure, and knowing when to stay silent.

Curious to try this out? Download Alma and try the premium tier.

I watched exactly one session from Davos 2026 in full: Dario Amodei and Demis Hassabis discussing “The World After AGI.” It was fascinating, two of the most important people in AI, disagreeing politely about timelines while agreeing that everything is about to change.

But here’s the thing: the World Economic Forum uploaded 243 videos from this year’s meeting. At an average of 15-20 minutes each, that’s roughly 60-80 hours of content. I don’t have 60 hours. I have a company to run, a product to ship, users to support.

This is the fundamental tension of our information age. The content that matters keeps growing. Our time doesn’t. For years, we’ve dealt with this through curation, letting algorithms or editors decide what’s worth our attention. But curation means missing things. It means trusting someone else’s judgment about what matters to you.

So I ran an experiment. What if AI could help me consume all of Davos, not by summarizing it into meaninglessness, but by creating a structured synthesis I could actually engage with?

Here’s what happened.

The Setup

The goal was simple: extract, synthesize, and analyze every significant discussion from Davos 2026. Not summaries. Not bullet points. A comprehensive document that captured who said what, where they agreed, where they disagreed, and what predictions they made.

The tools:

• Claude Opus 4.5 (via Cursor)

• yt-dlp for transcript extraction

• Python for automation

• About 15 minutes of my time, spread across an evening

The process unfolded in four phases.

Phase 1: Acquisition

First, I needed the transcripts. YouTube auto-generates captions for most videos, and the official WEF playlist had everything in one place.

I asked Opus 4.5 to write a Python script that would:

1. Pull all video IDs from the WEF 2026 playlist

2. Extract transcripts using YouTube’s auto-generated captions

3. Clean up the VTT format (timestamps, duplicates, HTML artifacts)

4. Save each transcript as a markdown file with metadata

The first version didn’t work. YouTube’s transcript API has quirks. The script failed silently on videos without English captions. The VTT parser left duplicate lines everywhere.

Here’s what the raw output looked like initially:

And our next guest is on the front lines
And our next guest is on the front lines
And our next guest is on the front lines
of the AI revolution. Joining us right

Classic auto-caption stuttering. Every phrase repeated 2-3 times as the speech recognition refined its guess.

Opus 4.5 iterated. Added deduplication logic. Implemented yt-dlp as a fallback. Cleaned HTML entities. After three rounds of debugging, the script worked:

# Parse VTT format - deduplicate lines
lines = []
seen_lines = set()

for line in content.split('\n'):
    line = line.strip()
    # Skip headers, timestamps, and empty lines
    if not line or line.startswith('WEBVTT') or '-->' in line:
        continue

    # Clean HTML tags and entities
    line = re.sub(r'<[^>]+>', '', line)
    line = line.replace('&gt;', '>').replace('&lt;', '<')

    if line and line not in seen_lines:
        seen_lines.add(line)
        lines.append(line)

Result: 243 transcripts, totaling roughly 500,000 words of content.

Phase 2: Synthesis

Now the interesting part. I had half a million words of raw transcripts. I needed structure.

My prompt to Opus 4.5 was deliberately open-ended:

“Review all of them in extreme detail and present a synthesis document that’s detailed and lists out key topics discussed, different positions proposed and forecasts, who said what on each topic.”

Opus 4.5 began reading transcripts in batches. Not skimming, actually processing the content and building a structured document. The synthesis emerged organically:

Major themes identified:

• AI timelines and capabilities (AGI predictions from Amodei, Hassabis, Musk)

• The collapse of the international order (Carney, Merz, Zelenskyy)

• The Greenland crisis (unified European rejection of Trump’s demands)

• Energy constraints on AI (Musk’s solar thesis)

• Job displacement and transformation (IMF data, Dimon’s predictions)

• Middle East dynamics (Qatar PM on Gaza, Iran)

• European defense and unity (von der Leyen, Macron, Merz)

What struck me was the disagreements Opus 4.5 surfaced. This is what summaries usually lose. The tension. The debate. The places where smart people look at the same facts and reach different conclusions.

Phase 3: Probability Analysis

Here’s where it got interesting. I asked Opus 4.5 to do something unusual:

“Analyze each position and assign probabilities yourself based on your knowledge of human history and tech development.”

Opus 4.5 searched the web for current data, IEA reports on solar deployment, IMF forecasts, expert surveys on AGI timelines, SpaceX’s actual progress on rocket reusability. Then it produced probability assessments:

High Confidence (>75% likely):

• 40-60% of jobs affected by AI (85-95%)

• US-China AI duopoly persisting (85-95%)

• Full SpaceX rocket reusability by 2026 (70-85%)

Medium Confidence (40-75%):

• AGI by end of decade (55-65%)

• Humanoid robots for sale by 2027 (60-75%)

Low Confidence (<40%):

• AGI by 2026-2027 (25-35%)

• Ukraine war ending in 2026 (20-30%)

• Gaza Phase 2 success (25-40%)

Very Low Confidence (<15%):

• More robots than people by 2031 (5-15%)

• US acquiring Greenland (2-5%)

The reasoning mattered more than the numbers. On Musk’s prediction of “more robots than people by 2031”:

“Global population: ~8 billion. Current global humanoid deployment: ~2,500. Even with 52% CAGR projected, reaching 8 billion by 2031 would require manufacturing capacity that doesn’t exist.”

On AGI timelines:

“Musk has a track record of aggressive timelines (Full Self-Driving was promised for 2017, 2018, 2019, 2020...). However, expert surveys show median predictions have collapsed from 50 years to ~5 years.”

This isn’t Opus 4.5 having opinions. It’s Opus 4.5 synthesizing available evidence and being explicit about uncertainty. That’s more useful than false confidence.

The Output

The final synthesis document runs about 1,000 lines. It includes:

1. Executive Summary - Key takeaways in one page

2. 16 Thematic Sections - Deep dives on AI, geopolitics, economics, energy, healthcare

3. Speaker Directory - Who said what, with their positions and affiliations

4. Prediction Tables - Every forecast, organized by timeline and topic

5. Agreement/Disagreement Matrix - Where leaders aligned and diverged

6. Probability Analysis - Independent assessment of each major prediction

7. Methodology - How the synthesis was created

What This Taught Me

1. AI doesn’t replace consumption—it changes what consumption means

I didn’t “watch” 243 videos. But I engaged with their content more deeply than I would have by skimming headlines or reading summaries written by journalists with their own editorial angles.

The synthesis preserved nuance. It captured disagreements. It let me drill into specific topics (I spent 20 minutes reading the full Middle East section after the synthesis flagged it as significant).

This is a new mode of information consumption. Not passive watching. Not algorithmic curation. Active synthesis with AI as a research partner.

2. The bottleneck shifted from access to attention

I could have watched all 243 videos. They’re free. They’re on YouTube. The constraint was never access, it was attention.

AI doesn’t give me more hours. It gives me leverage on the hours I have. The 30 minutes I spent on this experiment yielded more insight than 30 minutes of watching random sessions would have.

3. Transparency matters more than ever

The synthesis document includes methodology. It shows which transcripts were analyzed. It explains how probabilities were calculated. It cites sources.

This matters because AI-generated content can be confidently wrong. The only defense is transparency about process. If you can’t see how a conclusion was reached, you can’t evaluate whether to trust it.

4. Human judgment is still the bottleneck

Opus 4.5 did the heavy lifting. But I chose what to ask. I decided which threads to pull. I evaluated whether the probability assessments made sense.

The experiment worked because I knew what I was looking for. “Synthesize Davos” is a meaningful prompt because I have context about why Davos matters and what kinds of insights would be useful.

AI amplifies human judgment. It doesn’t replace it.

The Uncomfortable Question

Here’s what I keep thinking about: what happens when everyone can do this?

Right now, this feels like a superpower. I have a comprehensive synthesis of Davos 2026 that probably doesn’t exist anywhere else. I can reference specific quotes, track disagreements between leaders, and evaluate predictions against historical base rates.

But the tools I used are available to anyone. Opus 4.5 is a subscription. yt-dlp is open source. The methodology is reproducible.

Within a few years, this kind of synthesis will be table stakes. The question becomes: what do you do with the synthesis? What actions does it inform? What decisions does it improve?

The value isn’t in having the information. It’s in knowing what to do with it.

Try It Yourself

If you want to replicate this experiment:

1. Pick a corpus - A conference, a podcast series, a set of earnings calls

2. Extract transcripts - yt-dlp for YouTube, Whisper for audio files

3. Prompt for synthesis, not summary - Ask for structure, disagreements, predictions

4. Request probability assessments - Force the model to evaluate claims against evidence

5. Iterate on gaps - Ask follow-up questions about areas that seem thin

The whole process took about 60 minutes of active time, plus overnight processing. The output was a 1,000-line document that would have taken weeks to produce manually.

That’s the trade-off we’re all navigating now. Not whether to use AI for knowledge work, but how to use it well.

Appendix: Key Findings from Davos 2026

For those who want the conclusions without the methodology:

AGI Timeline Consensus

The most striking finding was the convergence among AI leaders on near-term AGI:

• Dario Amodei (Anthropic): 2026-2027

• Elon Musk (xAI): End of 2026 or early 2027

• Demis Hassabis (DeepMind): End of the decade (more conservative)

My probability assessment: 25-35% for 2026-2027, 55-65% by end of decade

The Collapse of International Order

Multiple leaders declared the post-Cold War rules-based order “over”:

• Mark Carney: “This is a rupture, not a transition”

• Friedrich Merz: “The international order as we knew it is unraveling”

• Zelenskyy: Called Europe’s response “Groundhog Day”

My probability assessment: 75-85% that US-led order is collapsing (this is already observable)

Energy as AI’s Binding Constraint

Elon Musk’s most interesting prediction wasn’t about robots, it was about power:

“Chip production will exceed electrical power capacity by late 2026... The constraint on AI is not chips, it’s electricity.”

He noted China is deploying 1,000+ GW of solar annually while the West falls behind.

My probability assessment: 75-85% that energy becomes the primary AI bottleneck

Job Transformation Scale

The IMF presented sobering data:

• 40% of global jobs affected by AI

• 60% in advanced economies

• Low-wage workers 14x more likely to need occupational changes

Jamie Dimon predicted fewer JPMorgan employees in 5 years.

My probability assessment: 85-95% that 40-60% of jobs are affected (note: “affected” ≠ “eliminated”)

European Defense Surge

In response to Trump’s pressure and the Ukraine war:

• Germany committing to 5% GDP defense spending (up from 2%)

• €90B EU support package for Ukraine

• New trade deals (Mercosur, India negotiations)

My probability assessment: 30-40% that Europe actually reaches 5% (historically, commitments exceed delivery)

At Alma, we’re on a mission to build the best AI nutrition coach. But a coach that doesn’t know what you’re eating is just a chatbot with opinions. Tracking is the foundation, and last year, we hit a wall.

Users loved the natural language experience. “Two eggs and a banana for breakfast” beats tapping through databases. But as we scaled, the cracks showed. The same user might say “my usual smoothie” on Monday and “the green one I had yesterday” on Tuesday. They’d track “chicken stir fry” and expect Alma to remember the exact recipe they described three weeks ago. They wanted a system that felt like a personal nutritionist who’d been working with them for years.

Our original system couldn’t do this. It was good at parsing text into food items. It wasn’t good at understanding context, history, or the messy reality of how people actually talk about food.

So we rebuilt it from scratch. This post isn’t about the architecture of the new system. It’s about how we shipped it without breaking everything.

The Problem with Shipping AI

We were going to be making a change to the core flow in our app, food logging. We couldn’t just flip a switch. We couldn’t just flip a switch.

The challenge: how do you know if a fuzzy, subjective system is actually better? Users don’t file bug reports when their chicken breast shows 165 calories instead of 185. They just quietly lose trust.

Our north star was correction-free logs: the percentage of tracked foods where users made no changes. If someone logs “chicken breast” and doesn’t edit the result, we assume we got it right.

Obviously 100% is impossible. People change their minds. They realize they had 6 ounces, not 4. But the rate tells us something, and the types of corrections tell us more.

Phase 1: The Test Kitchen

Before any real users saw the new system, we built a “Test Kitchen” feature flag. Internal team members and a handful of early supporters could opt into the new system while everyone else stayed on the old one.

We used it obsessively. Every meal, every day. When something broke (and things broke horribly in the early days) we caught it before it touched real users.

The bugs we found in Test Kitchen would have been disasters in production:

• Cloning the wrong meal when users had similar-named items

• Creating recipes with absurd ingredient quantities (2000g of salt)

• Unit conversion failures that turned a cup of rice into a kilogram

Each bug became a test case. By the time we started the real rollout, we had hundreds of edge cases covered.

Phase 2: The Gradual Rollout

Once Test Kitchen felt stable, we started routing production traffic:

Week 1: 10% of requests to the new system Week 2: 25% Week 3: 50% Week 4: 75% Week 5: 100%

At each stage, we monitored obsessively. We built a feedback system that could dial up or down. After any food log, users might see a simple thumbs up/down toast. We kept the frequency low enough to avoid annoyance but high enough for statistical significance.

The key was having kill switches at every level. If something went wrong, we could dial back to 0% in seconds.

Phase 3: The Automated Auditor

This is where it gets interesting.

We built a cron job that runs every three hours. It uses Anthropic’s Claude Opus 4.5 to audit everything that happened since the last run:

1. New food records: Identifies impossible nutrition values (>900 cal/100g for non-fats), all-zero entries, macro-to-calorie mismatches, and data entry typos

2. Serving data: Catches decimal placement errors where 118g gets entered as 1.18g (a 100x error that would destroy calorie accuracy)

3. User corrections: Analyzes large edits to understand if users are fixing legitimate data issues that should propagate back to source data

4. A/B test comparison: Tracks performance differences between the old and new systems during the rollout

The auditor doesn’t just report. It acts. High-confidence issues (>90% confidence) get auto-fixed. Questionable ones get flagged for human review. Every Monday, I get a summary email with the week’s findings.

Here’s what the decision model looks like:

• keep: Food data is correct

• soft_delete: Food data is clearly wrong and should be removed

• fix: Food data can be corrected automatically

• review: Uncertain, needs human verification

The conservative thresholds matter. Auto-delete only happens at 95% confidence. We’d rather flag something for review than silently corrupt user data.

What the Auditor Caught

During the rollout, the auditor surfaced issues we never would have found manually:

Dry vs. cooked values: The system was sometimes returning nutrition for dry rice instead of cooked rice. 350 calories vs 130 calories for the same portion. The auditor detected the pattern and we fixed the underlying logic.

Decimal drift in servings: A batch of food servings had reference ratios off by 10x due to a unit conversion bug. The auditor caught it within 3 hours and auto-fixed 47 records before users noticed.

Systematic overcounting: One edge case in recipe handling was consistently adding 15-20% extra calories. The auditor’s calorie distribution analysis flagged the anomaly.

The automation wasn’t about removing humans from the loop. It was about making sure humans saw the right things at the right time. I didn’t need to manually review 10,000 food logs. I needed to see the 12 that looked suspicious.

The Feedback Loop

Thumbs-down feedback with text comments went straight to my inbox. Not to a queue. Not to a dashboard I’d check weekly. My inbox.

This created urgency. When someone wrote “this is way off, I had a small salad not 800 calories,” I saw it within minutes. Often I could trace the issue, fix it, and deploy before the user’s next meal.

The tight loop changed how we thought about bugs. They weren’t tickets to be prioritized. They were problems affecting real people right now.

The Numbers

The whole process, from first commit to 100% rollout, took about two months. In my previous life at larger companies, a change to a core flow like this would have been a multi-quarter-long effort.

What made it fast:

1. Dogfooding: Using it ourselves daily meant we felt problems before we measured them

2. Automated auditing: The three-hour cycle meant issues surfaced in hours, not days

3. Gradual rollout with kill switches: We could dial back instantly if something went wrong

4. Tight feedback loops: Thumbs down to my inbox to fix deployed, often within hours

The new system now handles 100% of food logging. Correction-free rates are up. More importantly, the types of queries that used to fail (temporal references, complex recipes, modifications to previous meals) now work.

Lessons for Shipping AI

If you’re building AI systems that touch user data:

Instrument everything from day one. We couldn’t have done the gradual rollout without feature flags that let us route traffic precisely. Build this infrastructure before you need it.

Automate the audit, not the judgment. The LLM auditor surfaces issues. Humans decide what to do about edge cases. The 90% confidence threshold for auto-fix exists because we’d rather be slow and right than fast and wrong.

Make feedback painful. Routing complaints to my inbox instead of a dashboard created accountability. When you feel the friction of user problems, you fix them faster.

Correction-free rate is a lagging indicator. By the time you see it drop, users have already had bad experiences. Watch leading indicators: error rates, unusual values, processing times.

Ship incrementally, monitor obsessively. 10% traffic for a week tells you more than a month of internal testing. Real users do things you never imagined.

The auditor cron job is still running. Every three hours, it checks our work. Most runs find nothing. But when they find something, we know within hours instead of weeks.

That’s the difference between shipping AI and shipping AI responsibly.

I built something fun this week: a simulation that stress-tests our AI nutrition coach across different user types over weeks of interactions. Compressed into minutes.

At Alma, we’ve learned there’s no universal approach to coaching. Some users want data and optimization. Others need encouragement and low-pressure nudges. The promise of AI is adapting to each one. But how do you know if it actually does?

The Setup

Six synthetic users, each representing a pattern from our real data. The Optimizer who logs religiously and asks technical questions. The Struggler who engages sporadically and needs celebration over metrics. The Weekend Warrior whose tracking falls apart every Saturday.

Each persona interacts with our coach daily. Logs meals. Receives weekly check-ins. Responds based on their personality. Four simulated weeks, about 20 minutes of runtime.

What Broke

The coach was excellent at pattern recognition. It spotted that one user was eating 500 calories under target. Mentioned it week one. And week two. And week three. Same observation, no escalation.

It could see the problem. It never pushed to solve it.

Another user had a weight loss goal but muscle gain in their profile. The coach noticed the tension. Mentioned it repeatedly. Never resolved it.

Classic middle-manager behavior. Flag issues, don’t own solutions.

The Fix

The changes weren’t smarter models or better prompts. They were operational:

If the same issue appears two weeks in a row, change your approach. Don’t observe—propose action.

If goal and profile contradict for more than two weeks, force the conversation.

Escalation logic. The kind of thing you’d put in a manager’s expectations, not a software spec.

Why This Matters

When building products involving psychology and behavior, you used to ship and wait. Run A/B tests. Iterate slowly.

Now you can build synthetic users from real patterns and watch months unfold before anything goes live. The simulation won’t catch everything. But it catches obvious issues that would take weeks of production data to surface.

If you’re building something similar, I’d be curious to compare notes.

Technical Details

For those interested in building something similar, here’s how the system works under the hood.

The Stack

• Coach Agent: Built with PydanticAI, a framework for building production AI agents with type safety and dependency injection. The agent has ~40 tools for reading user data, adjusting goals, scheduling check-ins, and generating personalized content.

• Coach Model: Claude Opus 4.5 via AWS Bedrock. We chose Opus for the weekly reviews because they require nuanced pattern recognition across days of data and personalized communication that matches user preferences. The system prompt is around 1,800 lines covering tone, escalation rules, tool usage, and examples.

• User Simulator: Claude Sonnet 4.5 via the Anthropic API. Generates realistic food logs and check-in responses based on persona configurations. Sonnet is fast enough for the volume of interactions and good enough at roleplaying consistent personalities.

• Database: PostgreSQL via Supabase. The simulation writes real records (users, meals, food items, goals, streaks) so the coach agent queries actual data, not mocks.

Persona Architecture

Each persona is a dataclass with ~20 parameters:

@dataclass

class PersonaConfig:

name: str

nutrition_experience: NutritionExperience # just_starting, some_experience, knowledgeable

feedback_style: FeedbackStyle # celebrate_wins, straight_to_point, deep_dives

engagement_level: float # 0.0-1.0, probability of logging any given day

weekend_drop: float # how much engagement drops on weekends

target_adherence: float # how close they stick to calorie goals

response_rate: float # probability of responding to coach check-ins

question_style: str # technical, emotional, practical

# ... etc

The personas were derived from analyzing coaching preferences and engagement patterns in our production database. We queried users by feedback style, looked at their logging consistency, and built archetypes from the clusters.

Simulation Flow

1. Create a test user in the database with the persona’s demographics and preferences

1. For each simulated week:

• Generate 7 days of food logs based on persona’s engagement and eating patterns

• Insert meals and food items into the database

• Run the coach’s run_weekly_review() with a reference_date parameter (this was key—without it, the coach uses date.today() and all the date math breaks)

• Fetch the coach’s outputs: review notes, scheduled check-ins, focus messages

• Use Sonnet to generate user responses to each check-in based on persona

1. Generate a markdown report with all interactions

The Date Problem

The trickiest part was time simulation. Our coach agent calls date.today() in about 15 places—for calculating week boundaries, scheduling check-ins, querying recent meals.

We added a reference_date parameter that propagates through the system:

async def run_weekly_review(

self,

user_id: UUID,

reference_date: Optional[date] = None, # For simulations

) -> CoachResult:

today = reference_date or date.today()

# ... all date calculations use `today`

This lets you run a “weekly review” for any arbitrary date, and the coach sees the world as if that date were today.

Runtime

• 4 weeks × 1 persona ≈ 4-5 minutes (mostly waiting on Opus)

• 4 weeks × 6 personas ≈ 25 minutes

• Cost: roughly $3-5 per full simulation run

Output

Each simulation produces:

• A JSON file with raw data (every meal, every check-in, every response)

• A markdown report summarizing each week’s interactions

• Aggregate metrics: engagement rate, streak length, check-in response rate

The reports made it easy to spot patterns across personas. The Struggler got gentler messaging (good). The Optimizer got the same undereating observation four weeks in a row (bad).

What’s Next

The current system is manual, you run it when you want to test something. The interesting evolution is continuous simulation: a background process that periodically generates synthetic interactions based on recent user patterns and flags drift in coach behavior before real users experience it.

If you’re building agent simulations and want to compare approaches, reach out.

Six months into building with AI agents, you realize something strange. You’re not debugging code anymore. You’re having the same conversation you’d have about Sarah in accounting taking on too much, or whether the sales team’s process documentation has gotten out of control.

The software you’re building has started acting like a company. Not metaphorically. Literally. It has roles that need definition. Handoffs that break down. Documentation that bloats. Responsibilities that blur. Performance that varies by personality fit.

When Your Prompts Become Employee Handbooks

You start simple. One agent, one job, maybe 150 words of instructions. It works beautifully. Then you add features.

A month later, those instructions are 800 words. Three months after that, 2,000. By month six, you’re looking at a 3,500-word prompt with nested conditionals, historical notes about edge cases, and sections you’re afraid to delete because you can’t remember why they’re there.

This is the employee handbook problem. Every company starts with simple values and clear principles. Then reality intrudes. Someone makes a mistake, you add a policy. Five years in, nobody reads the handbook because it’s 400 pages of accumulated anxiety.

But here’s what makes it different with agents: you can actually fix it. Run an audit with a powerful model. Feed it your bloated prompt along with performance logs, and ask it to identify what’s redundant, what’s contradictory, what’s still relevant. Then have it rewrite the whole thing. Clean. Focused. Current.

The catch is testing. You need queries that represent what this agent actually does, edge cases included. Run the old prompt against them, run the new prompt, compare outputs. If the new version handles everything the old one did but with 1,200 words instead of 3,500, you ship it.

This is science fiction for anyone who’s managed real documentation. But with agents, you can do it in an afternoon. The discipline isn’t in the rewriting. It’s in knowing when to do it.

The Moment You Need to Split the Team

Your main agent was handling everything fine. Customer questions, product recommendations, order processing, basic troubleshooting. Then the quality starts slipping. Response times increase. Accuracy drops.

Your first instinct is capability. Better model, longer context window. But that’s like trying to make one person great at sales, engineering, and customer support simultaneously. The problem isn’t capability. It’s that doing it well requires different mindsets that don’t coexist easily.

So you split it. Customer service becomes three agents. One for questions, one for transactions, one for escalations. Each gets focused instructions, clear boundaries, better performance.

And immediately, you’ve created a new problem: who decides who does what? You need routing logic. Context handoffs. Escalation paths. Congratulations. You’ve just invented middle management.

It’s the orchestration layer, the routing service, the context manager. But it’s doing exactly what middle management does: making sure the right work gets to the right place, ensuring context doesn’t get lost, handling escalations when something doesn’t fit the normal flow.

The teams that get this right think about agent boundaries the way good organizations think about role definitions. Clear responsibilities. Obvious handoff points. Minimal overlap.

The teams that get it wrong create agent sprawl. Dozens of narrow agents with unclear boundaries and complex routing logic. It feels productive because you keep adding agents. But you’re not adding capability. You’re adding organizational complexity.

Hiring Decisions Disguised as Technical Choices

Which model do you use for which agent? In traditional software, this would be a technical question. Speed versus memory. Cost versus capability.

With agents, you’re making hiring decisions.

Some models are fast but sloppy. Others are slow and meticulous. Some are creative and surprising. Others are reliable and boring. None of these traits are better or worse. They’re different. And they fit different roles.

You wouldn’t put the fast-and-loose model in charge of financial calculations. You wouldn’t use the slow-and-perfect model for real-time chat. Not because they can’t technically do the job, but because their personalities don’t match what the role needs.

The best teams maintain role profiles. Not just “this agent does X,” but “this agent does X, and based on testing, it needs a model that’s conservative, verbose, and consistent even if it’s slower.”

Every choice is a tradeoff. The creative model that makes your content generation brilliant is the same one that sometimes goes completely sideways. You’re building a team. And team composition matters in ways that software composition never did.

The Reorg You Can Actually Execute

All these problems mirror organizational problems perfectly. But the solutions are completely different. Because unlike real organizations, you can actually fix this stuff.

Documentation bloated? Audit and rewrite it. Agent boundaries causing friction? Restructure. Model not fitting the role? Replace it. No six-month change management process. No HR involvement. Just test and deploy.

This is both the advantage and the trap. Real organizations develop stability because change is painful. That friction provides something valuable: time to learn what actually works.

When you can reorganize your agents every Tuesday, you might. And you’ll spend so much time optimizing structure that you never develop the institutional knowledge that comes from stability.

The teams doing this well aren’t the ones changing fastest. They’re the ones who’ve figured out when to restructure and when to let things settle.

What This Actually Means

We’re moving from building mechanisms to building organizations. From writing deterministic logic to designing coordinated behavior. Your system architecture is now organizational architecture. Your technical documentation is now operating procedures.

Most people are still applying software engineering principles to what are actually management problems. Treating agent systems like distributed services instead of like small companies.

The people who figure this out first will build things that work fundamentally differently. Not just more capable, but more coherent. Not just automated, but genuinely intelligent in how the pieces work together.

Because the future isn’t just AI that can execute tasks. It’s AI that can work together the way good organizations do. Clear roles, clean handoffs, appropriate specialization, living documentation, and the judgment to know when to restructure and when to let things be.

Whether you’re ready or not, you’re not just an engineer anymore. You’re a founder. And the company you’re building just happens to be made of code.

The conversation about AI and work keeps circling the same questions. Will it take jobs? Which jobs? How fast? But there’s a more interesting question that almost nobody’s asking: if AI does your core tasks, what are you actually supposed to do?

Not in the abstract future. Right now. Because for a lot of knowledge workers, this isn’t hypothetical anymore. The tools already exist to automate much of what fills their days. The question isn’t whether the tech can do it. It’s what happens when it does.

The Obvious Answer Doesn’t Work

The natural response is: you do higher-level work. Strategy instead of execution. Creativity instead of production. Thinking instead of doing.

But this breaks down fast. Most jobs aren’t structured that way. They’re not a neat pyramid with thinking at the top and doing at the bottom. They’re a mix. And critically, a lot of the thinking happens through the doing. You don’t really understand a problem until you’re elbow-deep in trying to solve it.

When the doing goes away, something strange happens. You don’t automatically get better at thinking. You often get worse at it, because you’ve lost the feedback loop that made your thinking good in the first place.

What Executives Already Know

Here’s what’s interesting: this problem is already solved in one place. Executives don’t execute. They set direction, ask questions, and watch metrics. When something’s off, they dive into the details just enough to understand what’s broken, then pull back out.

This is exactly the position most knowledge workers are moving into with AI. You’re not in the weeds by default anymore. You’re overseeing execution, checking if it’s working, and only going deep when you need to course-correct.

The skills that matter are the same ones executives need. Knowing which metrics actually matter. Asking the right questions to surface problems early. Understanding causation well enough to know when correlation is misleading. Having enough domain knowledge to spot when something looks wrong, even if you can’t immediately articulate why.

The hard part is that most people weren’t trained for this. Executives get there gradually, building this muscle over years. But AI is compressing that timeline. You go from doing everything yourself to overseeing it much faster than the typical career path allows.

Why AI Management Needs To Be A Real Thing

Right now, most people using AI tools are doing one of two things. Either they’re micromanaging every output, essentially doing the work twice. Or they’re trusting blindly and catching mistakes too late.

Neither works at scale. The first defeats the purpose. The second is dangerous.

The gap is management discipline. We need frameworks for oversight that aren’t just “check everything” or “hope for the best.” We need metrics that actually tell you if AI is performing well on what matters, not just whether it completed tasks.

Everyone’s focused on making AI better at doing tasks. Faster models, better reasoning, longer context windows. But almost nobody’s working on the actual hard problem: how do you manage AI effectively?

What Makes This Different

Managing AI is harder than managing people in some ways, easier in others.

Harder because AI fails in unpredictable ways. People make mistakes, but you can usually spot patterns in how they fail. AI can be perfect for 1000 iterations and then completely miss something obvious on 1001. You need different error detection systems.

Harder because AI doesn’t push back. A good employee will tell you when a request doesn’t make sense or when they need more context. AI just does what you ask, even if it’s the wrong thing. You lose that feedback loop.

Easier because you can instrument everything. With people, you can’t watch their every move without destroying trust. With AI, you can log every input and output, measure every decision, A/B test every approach. The data is there. We just don’t know what to do with it yet.

Easier because iteration is fast. If you realize your approach isn’t working, you can restructure it immediately. No reorganization, no hurt feelings, no adjustment period.

The Patterns That Work

Some patterns are starting to emerge from people doing this well:

Staged verification. Don’t check everything, but don’t trust blindly. Check strategically at decision points. Like code review but for reasoning.

Output metrics that matter. Not “did AI complete the task” but “did this move us toward the goal.” Most AI tools measure completion. Almost none measure impact.

Failure cataloging. When AI gets something wrong, documenting the pattern matters more than fixing the instance. People who do this build mental models of how their AI fails, which makes them much better at catching it.

Appropriate delegation. Knowing which tasks can be fully automated versus which need human checkpoints versus which AI shouldn’t touch. This varies by domain and by person’s risk tolerance, but getting it right is the difference between force multiplication and costly mistakes.

Feedback loops. The best AI users have tight loops between output and refinement. They don’t just accept results. They use bad outputs to improve their prompts, their processes, their understanding of what AI can and can’t do.

Why This Needs To Become A Discipline

Right now everyone’s learning this independently. Trial and error. Sharing tips on Twitter. But this is too important to leave to informal knowledge transfer.

We need actual research on what works. We need frameworks that generalize across domains. We need training that teaches people how to think about AI management, not just how to write better prompts.

Think about how project management became a discipline. Or how DevOps emerged as a real field with principles and practices. AI management needs the same thing. Not just best practices, but a coherent theory of how to oversee AI work effectively.

What Changes

I think we’ll see new roles emerge. Not “AI managers” in the HR sense, but people who specialize in designing AI workflows, building verification systems, and catching failure patterns.

We’ll see new tools built specifically for AI oversight. Not just better AI, but better ways to monitor, measure, and manage what AI produces. We’ll see organizations restructure around this. Teams that used to be organized around execution will reorganize around verification and direction-setting. The skill mix will shift.

And we’ll see education catch up. Right now business schools teach management but not AI management. Engineering schools teach AI but not how to deploy it responsibly at scale. Someone will bridge that gap.

The Real Work

The people who struggle aren’t the ones who can’t think strategically. They’re the ones who can’t resist diving back into execution mode, or who don’t trust the output enough to let go. They end up doing the work twice: once by AI, once by themselves to check it.

The people who thrive are the ones who can genuinely shift into that executive mode of thinking. Set clear direction, define success metrics, spot when things are off, intervene surgically when needed.

If your job is being done for you, the answer isn’t to find more tasks. It’s to figure out what you should be thinking about instead. And to build the systems that let you know whether what’s being done is actually working.

That’s the real work now. And we’re just starting to figure out how to do it well.

A few weeks ago, I wrote about agent mediated networks, how AI agents could solve the cold start problem that kills most networks before they begin. The theory was clean: let agents create baseline value when the network is empty, then evolve into connectors as the community grows.

But theory needs examples. So here’s one.

There’s a moment in every library that feels oddly intimate. You look up from your notes, make brief eye contact with someone across the room, and wonder: What are they working on? Would they find this interesting? Then you both look down again. The moment passes. The connection never happens.

Most interesting collaborations die this way, not from conflict, but from silence.

Why knowledge tools optimize for isolation

We’ve built incredible tools for solo thinking. Obsidian, Roam, Notion; they’re all designed to help you capture, connect, and develop ideas on your own. They’re personal knowledge gardens, carefully tended in private.

But knowledge doesn’t actually grow best in isolation. It grows in conversation. In collision. When someone working on protein folding accidentally sparks an insight for someone studying urban planning. When a startup founder’s half-formed thesis meets a researcher’s overlooked dataset.

The challenge is that these collisions are nearly impossible to orchestrate. You can’t browse through everyone’s research notes looking for resonance. You can’t announce “I’m thinking about X” to thousands of people and hope the right person notices.

The signal-to-noise ratio makes it impossible.

A workspace that notices patterns across researchers

Imagine a workspace that works like this:

You log in and continue where you left off. You’re researching urban density patterns, or perhaps sketching out a thesis on decentralized identity systems. An AI agent helps you think through it, asks clarifying questions, surfaces relevant concepts, helps you connect dots.

But here’s what’s different: your agent isn’t just helping you. It’s also noticing.

It sees that someone else, three time zones away, is exploring complementary ideas about mobility patterns in cities. Another person is building something that could solve a problem you mentioned last week. A researcher just published notes that challenge an assumption you’re working from.

The agent doesn’t interrupt you. It doesn’t flood you with notifications. Instead, it does something more subtle: it extends a quiet invitation.

“There are two others exploring ideas adjacent to yours. Would you like to me to introduce you?”

How this solves the cold start problem

This is agent mediated networks in practice. The agent solves the cold start problem by making the space useful even when you’re alone. It’s your thinking partner, your research assistant, your sounding board. You get value immediately.

But as more people arrive, the agent’s role evolves. It starts seeing patterns humans can’t. It notices that three people are circling the same problem from different angles. It identifies researchers whose questions align with another person’s hypotheses. It spots the quiet genius whose work keeps influencing others, even though they rarely speak up.

Then it does what humans do poorly at scale: it makes thoughtful introductions.

Not “here are 47 people also interested in AI.” But “here’s someone whose research directly challenges your assumption in Section 3. Here’s someone building the exact infrastructure you said you wished existed. Here are two people who could form a powerful collaboration if they knew each other existed.”

What the agent actually sees (and how it matches)

The agent doesn’t just match keywords. It understands context:

• Your thinking process, not just your conclusions. If you’re iterating on an idea about decentralized systems, the agent knows you’re exploring, not settled.

• Complementary gaps. It notices when Person A has the question and Person B has the framework that could answer it.

• Collaborative potential. It looks for overlapping missions, not just overlapping topics. Two people studying urban planning might have nothing to talk about. But an urban planner exploring food systems and an agricultural researcher exploring city logistics? That’s a conversation worth having.

• Contribution patterns. Some people prefer to build. Others prefer to advise. The agent learns what kind of collaboration each person actually wants.

When the agent suggests a connection, it does the work humans find exhausting: it prepares the introduction. It creates a shared document highlighting where your thinking overlaps, where it diverges, and what you might explore together. It sets up the talking points so the first conversation doesn’t start from zero.

What changes when researchers can discover each other this way

For researchers: You’re no longer publishing into the void, hoping someone stumbles onto your work. The agent actively connects your ideas to people who can build on them.

For founders: You’re not searching for co-founders or collaborators through cold LinkedIn messages. The agent surfaces people whose thinking has been quietly aligned with yours for months.

For the curious: You’re not overwhelmed by endless feeds. The agent brings you only what deepens your current exploration or gently nudges you toward an adjacent idea that might spark something new.

The network becomes smarter as it grows. Each person’s research makes the agent better at understanding patterns. Each successful collaboration teaches it what kinds of connections create value. The community improves the agent, and the agent amplifies the community.

Design principles worth considering

The core principle: respect the work.

The agent never interrupts deep focus. It waits for natural pauses. It suggests, never demands. It knows that sometimes the most valuable thing is solitude.

When it does make an introduction, it’s transparent about why. No black box recommendations. You can see the reasoning. You can say no. You can adjust what kinds of connections you want to receive.

And critically: your work stays yours. Notes remain private unless you choose to share specific pieces. The agent learns from patterns, not by reading your private thoughts out loud to others.

Why this matters now

We’re drowning in content but starving for connection. Everyone’s publishing, but no one’s collaborating. We have tools for broadcast and tools for privacy, but few tools for the delicate space in between where ideas can meet without pressure, where curiosity can find company without commitment.

Agent mediated networks make this possible. They bring the intimacy of a small research group to the scale of the internet. They let you think alone but discover together.

The Quiet Room (toying with this name) is what happens when you take the cold start problem seriously. When you build a network that’s useful from day one because the agent gives you value before anyone else arrives. And then, as the community forms, the agent’s role shifts from companion to connector.

It’s the library that finally whispers introductions.

And every great collaboration begins with someone noticing you’re both working on something that matters.

The hardest networks to build are the ones worth building. The Quiet Room is an experiment in making that beginning a little less brutal.

For years, the students at Damascus University’s Robotics Club learned to code without access to GitHub. They had to use VPNs just to reach basic documentation. Import restrictions meant getting electronics required finding friends traveling through Lebanon. Currency controls made online purchases impossible.

So they adapted. They found workarounds for every blocked pathway. They built informal networks to get components. They learned software engineering while being locked out of the platforms most engineers depend on.

When you can’t take the standard path, you get good at finding new ones. When every step requires problem-solving, that becomes your default. The kind of resourcefulness this produces, the instinct to treat obstacles as engineering problems rather than reasons to stop, is what separates people who build things from people who wait for better conditions.

Coming Home

I visited Syria recently for the first time in 17 years. What struck me most wasn’t what these students had been through. It was how forward-looking they were.

They weren’t thinking about constraints. They were excited about what they could finally build. After years of blocked pathways, the barriers were lifting, and everyone I met was focused on the future.

That kind of optimism is rare. It’s what you see in the best builders everywhere, but here it was stronger because these students had spent so long waiting for their chance.

I’m committed to supporting this. Not out of obligation, but because this is exactly the kind of determination that deserves to be accelerated. When you meet people who’ve already proven they’ll figure it out regardless, the question isn’t whether to help. It’s how to remove friction most effectively.

What Happens Next

The regime that created these restrictions is gone. GitHub is accessible. Import bans have lifted. The obstacles haven’t disappeared entirely, but the ceiling just got much higher.

This is the interesting moment: when people who proved they could learn and build despite everything finally get access to proper tools. Determination doesn’t fade when conditions improve. It compounds. Students who spent years working around constraints don’t slow down when friction disappears. They accelerate.

Two ways to remove friction between their determination and what comes next

If you’re an academic, hardware hacker, or engineer in North America, there are two ways to be part of this:

Hardware: Old microcontrollers, obsolete sensors, robotics kits gathering dust in your lab, what’s outdated to you is a significant upgrade from informal smuggling networks. Getting electronics into Syria is still complex but doable.

Knowledge: Years of isolation from international research networks means these students are brilliant self-learners but missing the compound knowledge that spreads through lab conversations. An hour or two in a virtual working session connects them to the wider world of what’s possible.

You’re not rescuing anyone. You’re investing in people who’ve already proven they’ll figure it out. You’re just removing friction between their determination and what they build next.

Reach out if you want to be part of what happens when resilience meets opportunity.

Why the Beginning Is Always Brutal

The hardest part of building a network has always been the beginning. It feels like showing up early to a party and realizing no one else is there. Networks behave the same way. They only become useful once enough people have already arrived. Andrew Chen put it clearly. A network without a dense early cluster is not low value. It is zero.

This is why most networks fail. You need people to create value, but you need value to attract people. When you start, you have neither. You are, in Chen’s phrase, nothing.

How Founders Used To Fake Momentum

The first workaround was almost embarrassingly manual. Paul Graham told founders to do things that do not scale. Reddit filled itself with fake accounts. Tinder threw events. Airbnb photographed apartments by hand. The point was simple. Pretend long enough for real use to appear. It was brute force momentum creation.

The New Way to Start a Network

Now we have a computational version of the same trick. You do not need to fake the early community yourself. You can let an AI agent do it. Call this agent bootstrapping.

An agent gives the first user something networks have never offered before, a baseline of value independent of scale. Even if the place is empty, the agent can make it feel alive. It can take a small amount of content and make it feel curated. Personalized filtering works especially well when content is sparse and diverse. Scraps start to feel intentional.

Most early communities die because newcomers feel ignored. Humans miss questions, reply too slowly, or forget to welcome people. An agent never does. It greets everyone, answers everything, and gives feedback that feels specific. It buys time until the humans arrive.

What Happens When the Agent Starts Shaping the Community

Once the network forms, the agent’s role changes. It stops simulating and starts shaping. As more people join, it sees more data, learns richer patterns, and uncovers links no individual would notice. Value stops growing linearly. It compounds.

Every network has a hard side, the users whose presence determines whether the whole thing works. Drivers in marketplaces. High quality sellers. Desirable matches. The agent can study their needs in real time and adjust the experience around them. Entire teams used to do this manually.

Communities also rely on two forms of attachment. People need to feel connected to the group’s ideas, and they need to feel connected to each other. Humans build these bonds unevenly. The agent can notice when they are forming too weakly or too narrowly and intervene. It can revive dormant members, surface shared interests, and highlight contributions at the moments that matter.

When the Community Makes the Agent Smarter

At this stage a new dynamic appears. The agent is not only helping the users. The users are helping the agent. The more people join, the more the agent understands. And the better the agent becomes, the more reason people have to stay. The result is a loop where the community sharpens the agent, and the agent amplifies the community.

It becomes a kind of shared intelligence. Each user receives a personal, high resolution experience, almost like a concierge in an old New York club. The advice is good because it reflects years of accumulated patterns from everyone who passed through.

For Alma, this becomes powerful. Instead of showing whatever restaurants are trending nearby, the agent could map your entire diet history. It could compare your habits and goals with people who eat like you and aim for the same outcomes. It could see what actually helped them and use that to guide you. The recommendations become deeply personal.

It would feel like a version of Google Maps built not for the general public, but for people whose behavior mirrors yours. A rating system shaped by your cohort rather than the world at large. A map that understands what someone like you will likely love.

How Agents Keep Shared Data Clean

Shared datasets used to be a liability. Crowdsourcing was a polite word for chaos. Open contributions produced noise. Strict moderation slowed everything down. Communities swung between disorder and gatekeeping.

An agent changes this. It can absorb contributions at any scale, filter out junk instantly, merge duplicates, and maintain consistency. The dataset becomes something the entire community can improve without degrading its quality. The more people contribute, the smarter the system becomes. And the smarter it becomes, the more value it can return to everyone.

Why the Hard Part Is Deciding What the Agent Wants

The real danger is not technical. It is philosophical. If an agent optimizes only for engagement, it will push the community into unhealthy shapes. It will strengthen small clusters and weaken the connections between them. You get activity without resilience.

Communities that last rely on norms that feel legitimate. They make people feel the place is worth protecting. These norms are relational. Agents must support them rather than erode them.

Open Source Agents?

What if the internal knowledge and directives of the agent organizing the community was publicly available and possibly editable by the members of the community itself? It could introduce a really unique dynamic worth considering.

Agent mediated communities are coming. The question is what kind of agents we choose to create.

We’re living through a hard pivot, literally.

For two decades, “hardware is hard” was startup gospel. It scared off founders. It scared off investors. It got buried under layers of software and SaaS multiples. But something’s changed. Hardware is having a second act. And this time, it might stick.

At the recent Mila AI x Robotics Panel, we dug into what’s driving this shift, why Canada is still behind, and what needs to happen now. Here’s a distillation of the discussion.

1. Why Hardware Momentum Is Building Again

Three things are colliding:

• Global trade is fragmenting. Re-shoring isn’t optional anymore. Supply chain resilience is national strategy now.

• Actuation tech is finally catching up. We’ve had 20 years of research; control systems are mature enough to build on.

• AI adds flexibility. The software layer, especially with LLMs, means you can build adaptive, context-aware hardware with smaller teams.

If the first wave of IoT felt clunky, this next wave is starting to feel agile.

2. Manufacturing as Strategy, Not Just Output

We talked a lot about irrationality. Because re-shoring isn’t efficient, it’s protective.

You’re going to see countries duplicate manufacturing capacity for things they don’t even need, just to reduce dependency. That creates opportunity: the smart bet is on versatile, adaptable manufacturing hubs that can spin up across verticals.

But founders need to understand the new game:

• Read the geopolitical tea leaves.

• Build early bridges with new trading partners.

• Government focus on “dual-use” is promising, but not everything can, or should, be dual-use.

3. Hardware Sovereignty Is About Optionality

I built a proudly “Made in Canada” product with PUSH. And the hard truth? Visibility into prototyping, design, and manufacturing support hasn’t improved much since then.

Hardware sovereignty isn’t about making everything at home. It’s about pivotability: being able to switch suppliers or fix bottlenecks without your entire business collapsing.

What we need:

• A clear map for founders: prototyping hubs, design shops, shortlists of vendors.

• Government-backed identification of critical supply chain gaps, and support to fix them domestically.

4. Fixing the Capital Stack for Hardware

Hardware takes time. It’s expensive. It’s messy. That means capital chains have to be longer and stronger.

What works:

• Start simple. Nail consumer demand before asking for millions.

• Early signs of pull matter way more than polish.

• Canadian investors need to start taking real bets, not charity, but conviction. We need an Eclipse Ventures for Canada. Now.

Also:

• Banks and government need to plug the working capital gap.

• DARPA-style competitions and fast-lane procurement would go a long way.

5. What Would a Thriving Ecosystem Actually Look Like?

Here’s the vision:

• A flagship consumer hardware company built and scaled from Canada.

• High-tech, frictionless manufacturing hubs where a founder can get a quote in 24 hours and a prototype in a week.

• Real FOMO. Like San Francisco. 30+ events a week, constant collisions. We need that grassroots movement here.

Final Thought: Build Like It’s Wartime

If we want to compete, we have to act like it matters. That means bold policy. Real infrastructure. A culture of experimentation. Canada doesn’t need to own every piece but we do need to own the ability to pivot.

This moment won’t come back.

Let’s not waste the second act.