Wednesday, October 7, 2026ArchiveSearchAsk the paper

The Computomatix Times

All the posts fit to save — curated from @computomatix's bookmarks & likes on X

Aakash Gupta Lays Out Six-Stage Path to Becoming an AI Product Manager

Aakash Gupta Lays Out Six-Stage Path to Becoming an AI Product Manager

Aakash Gupta outlines a six-skill learning path for becoming an AI product manager, citing Glassdoor data showing average AI PM total pay of $198K versus about $151K for PMs overall. Each stage ends in a portfolio artifact, such as a Claude Project of past PRDs or a recurring agent task.

Original post · 3 min read
To become an AI PM, you need six skills on top of core PM. Here's the order to learn them.

The pay gap is why it's worth it. Glassdoor puts the average AI PM at $198K in total pay, against about $151K for PMs overall.

Most AI PM learning maps I see are generic PM concepts with "AI" in the title. They skip what hiring managers screen for, which is proof you've done the work.

So in this map, every stage ends in something you can show.

1. Learn how the models work

Tokens, context windows, embeddings, tool calls, agents. You don't need to train a model, but you should be able to sketch everything that happens between a user's prompt and the reply. A PM I coach hit exactly this depth check in technical screens at both Nvidia and Glean.

2. Engineer the context

Everyone rents the same models, so the edge is what you feed them. Climb only as far as you need. Prompting first, RAG when answers depend on your data, fine-tuning when a style has to stick. Your proof is a Claude Project loaded with your past PRDs that drafts a spec your team would sign off on.

3. Hand work to agents

Chat answers a question. An agent finishes the whole task, as long as your brief has a goal, the right context, the tools it can touch and a clear definition of done. Your proof is one recurring task, like a weekly competitor recap, running on Claude Code or Codex while you only review the output.

4. Prototype it yourself

Alex Danilowicz, CEO of Magic Patterns, said on my podcast that the classic mistake is spending two hours debugging a database when all you needed was a clickable mockup to show five customers. Reach for Bolt.new when you need real data and logins, and Magic Patterns for flows on your design system.

5. Ship it to real users

AI fails in ways no demo shows. Before launch, instrument task success rate, human handoff rate, cost per successful task and how often users hit regenerate. Then put your prototype on a live URL and synthesize feedback from 20 real users.

6. Prove it with evals

A vibe check is an eval. You're using your own brain as the scoring function, which works right up until you're the bottleneck. Hamel Husain and Shreya Shankar walked me through the sequence I'd copy. Read 100 real traces, name the failure modes, add cheap code checks, then build one LLM judge per failure mode and check it against your own labels.

Your proof is your top five failure modes, each with an eval that catches it.

Stack all six proofs and you have an AI PM portfolio.

A deep dive for each stage

1. AI foundations → news.aakashg.com/p/ai-foundations-for-pms
2. Context engineering → news.aakashg.com/p/context-engineering
3. AI agents → news.aakashg.com/p/ai-agents-pms
4. Bolt.new guide → news.aakashg.com/p/pm-guide-bolt
5. AI evals → news.aakashg.com/p/ai-evals
6. LLM judges → news.aakashg.com/p/ai-pm-llm-judge
7. AI PM portfolio → news.aakashg.com/p/vibe-code-pm-portfolio

Learn the stage. Then ship the proof.
♥ 223 · ⟲ 28 · 👁 17.8KView on X ↗

More in Culture & Ideas

How Avery Wang's Shazam Algorithm Identified Songs Without AI

Aakash Gupta explains that Shazam's 2002 system, invented by Stanford PhD Avery Wang, used spectrogram peaks, constellation maps and hash lookups instead of AI, and was published openly in 2003. Apple acquired the company in 2018.

Original post · 2 min read
Shazam could name any song back in 2002, on flip phones, with zero AI. You dialed the number 2580, held your phone up to the speaker, and hung up. 15 seconds later, a text came back with the song name. That same core trick still runs the app today.

The inventor was Avery Wang, a Stanford PhD in audio signal processing. His problem was brutal. Match a short clip recorded on a 2002 cell phone mic, in a noisy bar, against a database of a million songs, in seconds, over a phone call.

His solution treated music as geometry instead of sound.

The algorithm converts audio into a spectrogram, a picture of the song, then throws almost all of it away. It keeps only the peaks, the loudest frequency points at each moment in time. Bar chatter and blown-out speakers can wreck most of a recording. The peaks survive. Shazam only ever needed the peaks.

Those surviving points form what Wang called a constellation map, because it looks like a star field. Pairs of peaks get converted into hash numbers, and identifying a song becomes a dictionary lookup rather than an audio comparison. That made it fast enough to search a million tracks on 2002 hardware.

Wang published the full method openly in 2003 in a paper called "An Industrial-Strength Audio Search Algorithm." Anyone could read exactly how the magic worked. The moat was the database and the deals with carriers, never the secret.

Apple bought the company in 2018 for a reported $400 million. People have tagged over 100 billion songs since the very first one, Jeepster by T. Rex, during the beta in April 2002.

One deterministic signal-processing trick, written before most people had heard the phrase machine learning, and it's still so good that in 2026 everyone assumes it must be AI.
Nathan Ruff @TheNathanRuff
Dude, how did Shazam work 15 years ago without AI!?
♥ 10.9K · ⟲ 1.9K · 👁 543.5KView on X ↗

FBI Arrests Fortnite Player Using Epic's Voice Chat Recording

Aakash Gupta reports that the FBI arrested Edward Frith after Epic Games reviewed a reported voice clip of his threat and sent it to authorities, and explains how Fortnite's rolling five-minute voice buffer and reporting system work.

Original post · 2 min read
The FBI just arrested a Fortnite player using a recording the game made of his own voice. He had no idea his headset was taping him. Almost nobody playing does.

Edward Frith, 29, had logged into his account over 1,700 times. In September he told another player that if the FBI showed up at his door he'd shoot them too. Someone in the lobby pressed the report button. Epic reviewed the clip, sent it to the FBI on September 20, and agents arrested him within days.

The design of the system is the clever part.

Recording every player would be a privacy disaster and a storage bill nobody wants. So Epic built voice reporting in 2023 to work like a flight recorder. The audio buffer lives on your own device, overwrites itself every five minutes, and never leaves your machine unless another player in the match reports it. The moment someone does, the clip gets packaged and sent to Epic's safety team with the speakers tagged.

He said it to one stranger in a lobby. That stranger had a button that turns the last five minutes into a federal exhibit.

I was a producer on Fortnite, and this is the part people outside the building never see. Threats of real-world violence got treated with the same urgency as a revenue outage. The game is full of kids, and Epic acts like it.

Fortnite is actually the conservative version of this. It still requires a human to press the button. Call of Duty has run AI moderation directly on live voice chat since 2023, no report needed. Every major platform with a microphone is converging on the same architecture.

The era where anything said into a gaming headset stayed in the lobby is ending one match at a time.
Dexerto @Dexerto
A Fortnite player who threatened to shoot the FBI in voice chat was arrested by the FBI

WagesOfNinja told another user "Let's see if the FBI is going to show up at my door because I'll shoot them motherf**kers too"
♥ 158 · ⟲ 41 · 👁 37.8KView on X ↗

Ohio's New Rome Dissolved Over Speeding Ticket Revenue

Aakash Gupta describes how New Rome, Ohio, and Macks Creek, Missouri, depended on speeding fines for most of their budgets, leading to dissolution in Ohio and bankruptcy in Missouri. Missouri subsequently capped ticket revenue at 20% of city budgets.

Original post · 2 min read
Ohio once dissolved an entire town because its main business was writing speeding tickets.

New Rome had 60 residents and a 14-officer police force. One cop for every four people in town. They collected around $400,000 a year in fines, 92% of the village budget, mostly by working a stretch of road where the speed limit dropped from 45 to 35.

A state audit then found the village was spending 82% of that budget on the police force. The town's only real industry was funding the thing that funded the town. In 2004 a judge ruled New Rome had effectively dissolved itself through corruption and erased it from the map. Its land got absorbed into the neighboring township.

Missouri ran the same experiment with Macks Creek, population 272, sitting on the highway to Lake of the Ozarks. The town wrote 2,900 tickets a year. Eight a day, almost all tourists who would never drive back to fight them. More than 75% of town revenue came from fines.

Then an officer there pulled over a state legislator. He went back to the capitol and passed a law capping how much of a city's budget can come from traffic tickets. Macks Creek lost its revenue stream, went bankrupt, laid off its entire police force, and disincorporated. The IRS seized the town's bank account.

Speed traps cluster wherever a highway full of out-of-towners meets a sudden limit drop in a state that lets the town keep the money. Missouri now caps ticket revenue at 20% of a city's budget. Ohio had to pass a law aimed at one specific village.

A speeding ticket heatmap doubles as a map of who's allowed to keep the fine money.
Terrible Maps @TerribleMaps
Where you’re most likely to get a speeding ticket in the U.S.
♥ 260 · ⟲ 44 · 👁 70.4KView on X ↗

Deedy Explains Shazam's Spectrogram Peak Hashing Method

Deedy Explains Shazam's Spectrogram Peak Hashing Method

Deedy outlines how Shazam extracts high-amplitude spectrogram peaks, hashes them with timestamp and track ID, and performs recognition via a hash table lookup. He notes that his college CS class built a version and recommends the original paper.

Original post · 1 min read
The serious answer to how Shazam worked is it took the peaks of a spectrogram of short clips of every song, find the peaks from the highest amplitude bits, hash it with the value being (time stamp, track id) and then the actual recognition is a hashtable lookup.

We did this for a college CS project. The original paper is fantastic:
Nathan Ruff @TheNathanRuff
Dude, how did Shazam work 15 years ago without AI!?
♥ 3.8K · ⟲ 357 · 👁 111.6KView on X ↗

Aakash Gupta Offers Formula for Valuing Private Company Equity Grants

Card comparing Google and OpenAI offers

Aakash Gupta shares a formula for valuing private equity grants by discounting quoted equity by payout probability and years to liquidity. He compares a $400K Google grant to a $400K OpenAI grant, estimating the latter at about $242K.

Original post · 1 min read
A $400K grant from Google is worth $400K.

A $400K grant from OpenAI is worth about $242K today.

Same number on the offer letter. You can sell Google stock the day it vests. OpenAI is private, so you sell only when the company runs a tender.

Here's the formula I use for any private grant:

Value = Quoted equity × P(payout) ÷ 1.15^years to liquidity

The 15% is your discount for money you can't touch. For a late-stage company with real revenue and a tender history, P(payout) is 70-90%.

OpenAI, 2 years to a sale at 80% odds: $400K × 0.8 ÷ 1.15² = ~$242K.
1 year at 90%: ~$313K. 3 years at 70%: ~$184K.

Earlier stage gets brutal. A $400K grant at a Series C with an IPO 5 years out at 40% odds: $400K × 0.4 ÷ 1.15^5 = ~$80K.

The formula gives no credit for growth past today's price, and OpenAI has had a lot of it: $157B to $852B in 17 months. So treat the number as your floor.

Compare offers on what the equity is worth today. Then negotiate the gap in base and sign-on.
♥ 94 · ⟲ 6 · 👁 29.1KView on X ↗

Puneet Patwari Outlines Path to Senior Distributed Systems Career

Amazon Principal Engineer Puneet Patwari describes compensation for L5 and L6 engineers and offers a learning path for distributed systems: mastering fundamentals, building systems with real tradeoffs, and reverse-engineering engineering blogs from major tech companies.

Original post · 3 min read
At Amazon, a strong L5 with 7 to 8 years of experience can cross ₹1 Cr+ CTC. At L6, compensation can go well beyond ₹1.5 Cr+ depending on team, location, stock, and level.

But the interesting part is not just the money.
Look at why recruiters reach out for these roles.

It is because their background shows they understand hard systems, and they have enough proof of work that people can see it.

Today I am a Principal Engineer, but if I were starting in distributed systems from scratch and wanted to turn that skill into career leverage, this is exactly how I would do it.

[1] Build the fundamentals before touching big scale

I would first get comfortable with the building blocks:
→ networking and request lifecycle
→ databases, indexes, transactions
→ caching
→ queues and async processing
→ replication
→ sharding
→ consistency
→ retries, idempotency, backpressure
→ observability and failure handling

Basically, have the understanding to see what happens when one normal backend service gets slower, busier, or partially unavailable.

[2] Build systems where the tradeoffs come into the picture.

Do not only watch architecture videos.
Build things.

Start with:
→ URL shortener
→ rate limiter
→ notification service
→ job scheduler
→ file upload system
→ search service
→ payment workflow

Then deliberately make them harder.
– What happens at 10x traffic?”
– What if Redis dies?”
– What if the same event arrives twice?”
– What if one shard becomes hot?”

[3] Read engineering blogs and reverse-engineer decisions

Uber, Netflix, Stripe, Discord, Cloudflare, LinkedIn, Meta, Amazon.
There’s golden material out there.

While reading, ask yourself:
– Why did they choose this?
– What was breaking before?
– What tradeoff did they accept?
– What new problem did their solution create?

That is how engineers actually learn architecture.

[4] Put your thinking in public

This part is massively underrated.
Write about what you learn.

Publish:
→ design breakdowns
→ architecture diagrams
→ GitHub projects
→ incident analyses
→ open-source contributions
→ performance experiments

Build enough public proof that when someone searches your name, they can tell what kind of engineer you are.

That is when learning starts compounding.

You study distributed systems to become better at engineering.
Then that knowledge helps you design better systems.
Those systems give you better stories.
Those stories become public proof.

And eventually, opportunities start finding you instead of you constantly chasing them.

That is the leverage.
Jordan @ Jobbie @i7solar
getting cold emailed by amazon is crazy
♥ 999 · ⟲ 80 · 👁 140.9KView on X ↗