Phones aren’t allowed on the warehouse floor, so most of the photos here come from public sources. They match what I saw.

I love factory tours. When a friend bought a Tesla 10 years ago, he booked a tour of the Fremont factory and invited me. I remember vividly the robot arms painted in Tesla’s signature color, Pantone 186C. I’m also a huge fan of How It’s Made, a TV show that shows the step-by-step manufacturing processes of everyday items. So when I came across an ad about public tours at a nearby Amazon fulfillment center, I signed up right away.

A tour is a company’s public relations and marketing tool

The fulfillment center in Tracy, CA is called OAK4. It’s named after its nearest airport, Oakland, and covers about 1.5 million square feet. Tours run twice a day on weekdays, at 10:30 a.m. and 1 p.m.

About 15 of us followed four friendly guides, staying neatly inside the green tape on the floor like elementary school kids on a field trip. No one strayed. No one touched anything. Our headphones protected our ears and carried our guide’s voice. At each station, we lined up and watched. Each guide introduced themselves and described their main job as a packer or a picker. On top of that, they lead tours and serve as learning ambassadors who train new employees and managers.

None of that is unusual. Every company tour is a carefully crafted public image the company wants to project. The question is what that image leaves out.

What we were shown

Amazon robots. Behind a fence, orange robots that look like oversized Roombas move shelving units across the floor. Each can lift 1,500 pounds and drives itself to a charger when it runs low. Maintenance staff only go inside to pick up fallen items or make repairs.

Stow. Amazon used to stock items the way a grocery store does, with all the shampoo on the same shelf. That changed with the release of Harry Potter and the Order of the Phoenix. Millions of preorders sent pickers to the same shelves at once, causing traffic jams and delivery delays. Today, Amazon uses “random stow”: items go into whatever slot is open. A bottle of shampoo might sit next to a phone charger and a box of crayons.

Pick. Robots bring shelves to a person, who pulls each item and drops it into a yellow tote.

Pack. The packer is the final set of eyes on an order. A screen chooses one of about 20 box sizes. The packer scans each item, adds padding, and seals the box with water activated tape. Our guide called this the human touch.

SLAM. Scan, Label, Apply, Manifest. It’s the “last 100 feet” before a package is loaded onto a truck. A machine applies each label with a puff of air. Occasional misses led to labels scattered on the floor. Boxes that fail a quality check get kicked out to a person who opens, audits, reweighs, and retapes them by hand.

The guides spent a lot of time on employee benefits. Health and dental start on day one, which many retailers don’t offer. There’s $5,000 in education support. Workers specialize in one role but can learn others over time. They can listen to music through Amazon approved headphones, and employees at nearby stations run small contests: “Pack more than me, and I’ll buy you a soda.” It all painted a picture of a workplace that takes care of its people. The guides were all smiles. On the floor, the faces were focused and quiet.

All of this is true. It’s also carefully selected.

The questions I didn’t ask

I didn’t ask these questions on the tour, because I knew the guides wouldn’t have the answers. That’s the point. The people who show you the building are not the people who set the targets. I did some research after the tour because I wanted to reconcile what I’d read about Amazon’s warehouse practices with what I saw.

How fast is fast enough, and who decides?

What metrics are workers measured against? California’s AB 701, passed in 2021, requires large warehouses to give workers their quotas in writing. It also bans quotas that prevent meal breaks, rest breaks, or “use of bathroom facilities, including reasonable travel time to and from bathroom facilities.” A law like that only gets written when the problem is real.

What does a 10 hour shift do to a body?

Workers here do four 10 hour shifts a week in an environment so loud that earplugs sit in containers everywhere. During the entire tour, I only saw one restroom, near the main entrance. In a building larger than 20 football fields, how long does it take to walk there and back? And if every minute counts toward a quota, does a bathroom break mean falling behind? What happens to a body that keeps up that pace, shift after shift?

That last question, at least, has a public answer.

In December 2024, the U.S. Senate Committee on Health, Education, Labor and Pensions released a report titled “The ‘Injury-Productivity Trade-off’: How Amazon’s Obsession with Speed Creates Uniquely Dangerous Warehouses.” It found that “Amazon warehouses recorded over 30 percent more injuries than the warehousing industry average in 2023,” and that Amazon “refuses to implement injury-reducing changes because of concerns those changes might reduce productivity.” Amazon disputed the findings.

What happens to the human touch?

Our guide called the packing station the human touch. The robots behind the fence told a different story. In July 2025, Amazon announced it had deployed more than one million robots. That October, The New York Times reported on internal documents showing Amazon hoped automation would let it avoid hiring more than 600,000 people by 2033 and eventually automate 75 percent of its operations. Amazon said the documents didn’t reflect its “entire strategy.” Either way, it’s fair to ask: if the human touch is the selling point today, how long does it last?

Will robots eventually replace all of the people here, or just shrink the staff to a minimum? When I toured the Tesla factory in Fremont 10 years ago, it already felt designed to run with as few people as possible. Tesla later found the limits of that idea. In April 2018, Elon Musk wrote that “excessive automation at Tesla was a mistake” and that “humans are underrated.”

In the long run, does Amazon still need human packers? In 2019, Reuters reported that Amazon was rolling out machines that build a custom box around each order, at “four to five times the rate of a human packer.” By 2025, Amazon announced plans for hundreds of these machines across Europe, framed as a way to reduce packaging waste. Workers still load the items. For now.

Who pays for my convenience?

I asked about returns and cancellations. Returns aren’t handled here. But an order can be picked and packed in about 15 minutes. If I cancel after that, someone has to find my box and pull the item out by hand. On my end, canceling takes one tap. On theirs, it’s a search, and a box opened and resealed at the SLAM station. I’ve changed my mind about orders more times than I can remember, and I never once thought about who was on the other side of that tap. My convenience doesn’t disappear. It just becomes someone else’s work.

What I took home

A tour is built to make you admire the machine, and I did. I walked away impressed by the scale and the automation, and the tour satisfied my curiosity as an Amazon customer.

But I also left thinking about the people inside it, and the targets I couldn’t see. From what I’ve read, those targets are demanding, and they exist to keep the whole system fast.

Every time Amazon raises its shipping promise, it feels like a gift to customers. Inside the building, it’s a new requirement someone is measured against.

I still love fast shipping. I just think about it differently now.

What an Amazon Warehouse Tour Leaves Out was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m training to be a docent at the Computer History Museum. This year we’re trying something new with Small Bytes, ten-minute talks where a docent picks one thing and goes deep. I picked the programming language wall, and then spent three weeks on it.

Almost everything else in that museum is something you can point at: cabinets, cables, vacuum tubes, switches. This wall is the first thing in the gallery you can’t put your hands on. It’s a family tree. About 150 programming languages make the chart, and arrows trace how each one descended from the ones before it. The museum’s label sums the whole thing up in five words:

Few new languages are truly new.

I studied computer science as an undergrad and took a handful of linguistics classes along the way, so for four years I quietly compared the two. This chart is where those paths crossed.

I’ve spent the last 15 years of my career in personalization and recommendations, across e-commerce and digital media, and most recently leading a team working on agentic AI. For two decades the machine’s whole job was to guess what someone wanted before they asked. This past year that flipped. Now the machine waits to be told.

The big idea of my talk was that computers didn’t become powerful because we built better hardware, but because we found better ways to tell them what to do. Standing at that wall with a year of agentic AI behind me, I stopped reading that as a historical observation and started reading it as a question about right now.

First, there was no software.

For the first decade of computing there was no software at all, only machines. Take ENIAC in 1946. In the photograph below, two of the six women who programmed it, Betty Jean Jennings and Frances Bilas, aren’t typing, because there is no keyboard and no screen.

That was programming. ENIAC could calculate an artillery shell’s trajectory in about thirty seconds, but setting up that single problem took days, and the instructions weren’t written down anywhere, because the machine was the program.

Then came the shift that made everything on the wall possible. Put the instructions into memory alongside the data, and a program stops being something the machine is and becomes something the machine reads. Which raised a question nobody had needed to ask before: how do you write it down?

Why 150, and not one?

A programming language has to do two things at once that pull against each other. It has to be close enough to English that a person can write it, and rigid enough that a machine can read it only one way. Every dot on that wall is somebody’s attempt to settle that fight, which is why there are a 150 of them instead of one.

New domains kept arriving, and new languages followed them. COBOL arrived in 1959 for business payroll and inventory, and after it came languages for databases, for statistics, and eventually for the phone in your pocket. Engineers were also getting tired of how painful the existing ones were. John Backus built FORTRAN because writing raw machine code was, in his words, “a pretty lousy business to engage in,” and his solution was as plain as the complaint: “Well, let’s make it a little easier.”

That’s the whole wall in one sentence.

The compiler nobody would touch

Follow one specific line and you can watch this happen. On the left side of the chart sits Flow-Matic, with an arrow running into COBOL, and the person who wrote Flow-Matic was Grace Hopper.

Hopper had a math PhD from Yale, joined the Navy during the war, and was assigned to program the Harvard Mark I. She stayed in computing for forty years and retired a rear admiral. In 1952 she built the first compiler, a program that takes what a person writes and turns it into the code a machine can actually run. Before that, if you wanted a computer to do something, you wrote it in the machine’s own code yourself.

Almost nobody believed it would work, and her account of it has stayed with me since I first read it:

“I had a running compiler and nobody would touch it. They carefully told me computers could only do arithmetic; they could not do programs.”

Carefully is the word that gets me, and it took her about two years to convince people she wasn’t wasting her time. Everything to the right of 1952 on that wall exists because she won that argument.

Where the two paths crossed.

Grace Hopper proved a machine could read what a person wrote. The next question was how to write down the rules.

In 1959 Backus needed a way to define ALGOL’s grammar precisely enough that different teams could write compatible compilers, so he devised a formal notation, later refined by Peter Naur. We call it Backus-Naur Form, and it is still how language grammars are specified today. Two years earlier, Noam Chomsky had published his foundational work classifying the grammars of human language, and although the two efforts were largely independent, Backus-Naur Form turned out to be a notation for one of Chomsky’s exact categories: context-free grammars.

Linguists trying to explain how a child parses a sentence and engineers trying to make a machine parse code had arrived at the same underlying structure within a few years of each other. So the chart really is a family tree, with all the same properties attached: languages have parents, they borrow syntax from their neighbors, and some of them go extinct. And if it’s a family tree, it should have a Latin.

ALGOL is the Latin

Almost nobody writes ALGOL today, and almost everyone writes its descendants. Its structure is baked into Pascal, C, Java, and JavaScript, and block structure, scope, and the shape of a function were all inherited by languages that rarely mention ALGOL by name. Even Python traces its roots back to it.

A dead language whose grammar sits quietly inside everything we write is exactly what Latin is. You don’t speak it; you speak something descended from it, and you don’t notice.

That’s what the museum’s label means. Everything on this wall came from something.

And INTERCAL is the Basque

Basque sits in Western Europe surrounded by Indo-European languages and belongs to none of them, with no known parent and no surviving relatives. Linguists call that an isolate, and the wall has exactly one. Look for INTERCAL, somewhere around 1972, and you’ll find the only dot on the entire chart with no arrows going in or coming out.

Don Woods and James Lyon, two Princeton students, built it as a parody, deliberately designed to share nothing with any language then in existence. It looks like gibberish. But they couldn’t escape entirely, because it still needed an assignment statement, which I find quietly perfect. Even the one language built to have no ancestors inherited something.

Computer scientists don’t just tell jokes. They implement them.

One dot I know personally

John Kemeny and Thomas Kurtz, two math professors at Dartmouth, created BASIC in 1964 so that students who weren’t engineers could use a computer. It wasn’t built to be faster or more powerful than what already existed. It was built to let more people in.

Twenty years later I was one of those high school students, sitting at an Apple IIe, and BASIC was the first language I learned. We subscribed to Family Computing, which printed pages of BASIC code every month, and I spent hours typing those programs in by hand, line by line, then tweaking the code just to see what would break.

So does the wall keep going?

Every language on that wall asked a person to meet the machine halfway, which meant learning its syntax first. When you use an AI model today, you don’t learn anything at all. You type plain English, with no manual, no compiler, and no initiation fee.

Every language on that wall asked a person to learn it. This is the first thing that didn’t.

The optimistic answer to my question is a strong one, and it has seventy years behind it: every arrow on that wall lowered the barrier to entry, and every time computers got easier to direct, more people directed them.

But that answer is about how many people program, and my question is about how many languages get invented. For seventy years those two moved together, so it was easy to treat them as the same thing. They moved together for a practical reason: the only way anyone knew how to lower the barrier was to invent a new notation, so letting more people in meant adding a dot to the chart. Hopper’s compiler, Backus’s FORTRAN, and Dartmouth’s BASIC were the same move made three times.

That’s what just broke. The barrier has dropped further in the last three years than in the previous thirty, and it happened without anyone adding a dot, because English isn’t on the wall.

There’s a second reason the chart may stop growing, and it has nothing to do with how easy programming feels. Training a model takes an enormous amount of existing code, and a language invented tomorrow has none of it. That starts a loop that is hard to break: the assistant writes the new language badly, so developers don’t adopt it, so no code accumulates, so the assistant never gets better at it. Researchers who have looked at which languages models reach for find they lean heavily on Python and a small handful of others, often well past the point where something else would suit the task better. In 1995 a new language needed a compiler and a good book. Now it needs a body of code large enough to train on, and nothing on that wall ever had to clear that bar.

So I think two things are true at once, which hasn’t happened before in this history. We are about to have far more people programming, and far fewer new programming languages.

The part I keep running into

That tension follows me around: easy for a human to express, impossible for a machine to misinterpret.

Large language models solved the first half of it and did almost nothing about the second. Somebody still has to say precisely what they want, and the specifying didn’t disappear when the typing did. It moved into system prompts, tool schemas, test suites, and evals, which is the same job wearing unfamiliar clothes, with far worse tooling than a compiler has offered since 1952.

The clearest thing I took from this past year is that a team’s throughput on generating code can go up by an order of magnitude while the time it takes that same team to agree on what “correct” means doesn’t move at all. That isn’t a productivity win. It’s a bottleneck that relocated, and it moves somewhere nobody has good instruments yet.

That is Grace Hopper’s problem in 1952. She had a machine that could run programs and no good way to state one, and her answer was a new notation. Our answer, so far, is a pile of prompts and evals that nobody would call a language. Though it’s worth remembering that SQL and HTML are both on that wall, and neither of them is a general purpose programming language either.

Back at the wall

We didn’t get here because the hardware got faster, though it did. We got here because for seventy years people kept finding better ways to tell machines what to do, and every one of those ways ended up as a dot with an arrow pointing into it.

Someone will extend that chart eventually, and I don’t know what shape the next node takes, or whether we’ll even recognize it as a language when it shows up.

Every Programming Language Has a Parent, Except One. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ninety minutes with the curator who built Revolution, and four years of design decisions most visitors walk right past.

I just completed day one of a six-Saturday docent training program at the Computer History Museum (CHM) in Mountain View, California.

We spent 90 minutes with Kirsten Tashev, one of the creators of Revolution: The First 2000 Years of Computing. Kirsten spent 20 years at CHM, from its “trailer days” to the design of the exhibits in its current building, which had been part of Silicon Graphics. She walked us through the gallery the way a docent would and shared stories about the exhibits, including her own iPhone, now memorialized in a case. Along the way, she pointed out a few Easter eggs in the exhibit.

The exhibit took three years of conceptualization and one year of production and installation. It finally opened to the public in 2011. Once you know that, you start seeing the decisions.

Before you reach the main gallery, the lobby floor pattern mirrors the holes of vintage punch cards. I had walked across it many times without ever looking down.

The entrance to the exhibit is a dark, narrow pathway. It exists to transition the visitor from the lobby to the start of a 2,000-year history tour. From there you move through 19 galleries and pass under three LED arches. Each one marks the shift from one computing era to the next.

The bigger decisions aren’t physical. Museums generally pick a lane: story-first or object-first. CHM chose objects. There is no single continuous timeline. Content is grouped into themes (Analog Computers, Memory & Storage, Supercomputers, Artificial Intelligence & Robotics, etc.), with timelines running inside each one. This early decision governs everything downstream.

Roughly 40% of CHM’s visitors come from outside the US. The curators built for that, making an effort to keep the story from being US-centric. One entire section is dedicated to IBM PC clones engineered around the world. One of the docent mentors told us about a Swiss visitor who stopped cold in front of the exact machine he grew up with. Not a famous machine. His machine. Apparently this happens all the time, people finding a piece of their own past behind glass.

The docent mentors said the best moments come when someone on your tour turns out to have worked on the machine you’re presenting. Meeting the people who built this history is what makes the work meaningful.

Two objects stuck with me. The Software Tsunami is an arch built from stacked retail software boxes. It’s easy to assume a computer museum is a hardware museum. Hardware survives, and it looks good in a case. Software is harder, because there’s nothing to look at. The boxes are the answer. Stacked together, they show what happened once software stopped coming bundled with the machine and started being something you bought on its own.

Google’s first server rack from 1999 sits in the Networking & the Web gallery. After CHM acquired it, Google sent someone over to wipe the data. The rack itself is a do-it-yourself cluster of off-the-shelf PC boards, custom trays, and hand-mounted cooling fans, holding 80 PCs plus networking equipment. It was one of many identical systems answering search requests in Google’s early days.

Kirsten shared that for curators, it’s not about what you put in, but what you take out. Revolution displays about 1,100 objects, roughly 2% of CHM’s collection. The other 98% sits in storage. Those cuts were made once, for a visitor the curators would not meet.

A docent makes the same cuts, but in the room. Which objects, which stories, which things I love that don’t make the tour, decided partly by who showed up that morning. Every so often one of them will have built the machine behind me.

Product work is mostly the first kind. You make your best guess about a person you’ll never talk to, ship it, and read the analytics later. A tour is the second kind. You watch someone’s face and change course.

I spent thirty years doing the first. I’m about to learn the second.

A docent-in-training’s look behind the scenes at the Computer History Museum was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first time I heard the words “Black-Scholes,” I was in an all-hands listening to our CEO explain why my stock options were worth almost nothing.

It was 2000. Onebox.com, where I worked as a first-time product manager, had just been acquired by Phone.com. The deal was struck with the stock near $128. By the time I could sell, it was less than $30. Alain Rossmann, our founder and a mathematician by training, walked the whole company through how he had repriced our options and the formula he used to do it.

I didn’t get a word of it. A piece of math had just decided what my compensation was worth, and there was nobody to ask. So when I got to Kellogg for my MBA, I took Futures and Options with Professor Kathleen Hagerty. Elegant, rigorous, entirely theoretical. Greek letters on a whiteboard, no money at risk.

Twenty-five years later, two things came together. I started selling options with real money. And I had just spent a year leading about 30 product managers building agentic AI, without having put my own money behind an agent.

I place every trade myself. What I built with Claude is the system that tracks and monitors them. Then I paid attention to what actually happened.

What I built

I make two types of trades. A covered call means I own the stock and sell someone the right to buy it from me at a set price and date, for a fee. A cash-secured put is the mirror image: I sell someone the right to make me buy instead. When either position risks assignment, I roll it: buy back the option I sold, sell a new one in its place, same type, later date or different strike. That keeps the trade on my terms instead of losing the stock or having it put to me. The fee is the premium, mine to keep regardless of outcome. Real options traders will recognize this as the beginner’s set, which is exactly why I chose it.

The system is simple. I place a trade and screenshot the confirmation into chat. Claude reads it, computes the premium net of fees, and updates my tracker and audit log. A Google Apps Script emails me a report every weekday at 6:45 AM Pacific: orders for today, anything at risk of assignment, and every open position with how far it sits from its strike. It runs on Google’s servers, not my laptop, after the first version missed a day because my Mac was asleep.

The whole thing was working in two days. The arithmetic has been right across every trade. It flagged two fee rates in the same account that differed by a factor of two instead of quietly averaging them. It told me when it had assumed an account label rather than read one.

That is the “very good analyst” half of the title, and I am not going to undersell it.

What it got wrong

Three failures, and they get harder to catch in order. A wrong number. A missing number. And correct numbers answering the wrong question.

The obviously wrong number. Claude wrote me an Apple trade plan built on the claim that Apple would not report earnings until late October. Apple had reported the previous evening and dropped 9.7%. It broke my most important rule: never sell an option whose life spans an earnings date, because earnings can move a stock 10% overnight while the market is closed.

It was not a capability gap. The date is on Google Finance. Claude has web search. It had correctly looked up a different company’s earnings date that same week. The capability was there. The habit of using it, rather than answering from memory, was not.

Later, an automated check announced that a position was “814.3% in the money.” The fund was near $50 against a $48 strike, and the number it had grabbed was around $5. I knew instantly something was broken.

The missing number. That $5 belonged to DRAM, a memory-sector ETF I hold a put on. After the absurd reading, the price lookup stopped returning anything at all. Every report since has read: price unavailable.

Two days later that position sat 6.6% from its strike, closer to assignment than anything else I held, and my monitoring could not see it. I caught the absurd number in one second. I did not catch the blank for days, because a blank does not look like a failure. It looks like a field.

The right answer to the wrong question. The third one was mine. I said maximize premium collected, so everything optimized premium collected: every strike suggestion, every roll, every alert threshold.

I asked Claude about tax in a later session and got an uncomfortable answer. Premium is short-term income, taxed at my ordinary rate, while the shares underneath it might have qualified for long-term treatment at a lower one. Put together, the program could be losing to the simplest alternative there is: owning the shares and doing nothing. I have not had that checked by an accountant, which is its own kind of answer.

Both analyses were internally sound. The goal itself went unquestioned, by Claude and by me. Somebody needed to ask “premium to what end?” on day one, and neither of us did.

That is the thing I would change first. Claude is agreeable by default. Give it an objective and it will pursue that objective well, and keep pursuing it long after someone should have asked whether it was the right one. I do not need an assistant that agrees with me faster. I need one that asks what I am optimizing for, and says so when my answer does not hold up.

None of this has cost me money yet. That is luck rather than design, and it is why I am writing this now instead of after it does.

The part I keep coming back to

Every correct DRAM price in my tracker was fetched by hand. The automated feed produced one absurd number and then silence, while every lookup a human initiated worked. So I stopped trusting a single source and asked Claude for alternates. Then I put three side by side.

On AAPL, W and AMZN the three sources agree exactly. On DRAM, Google returns $5.29. Yahoo and CNBC both return $50.37.

Google was not down. It was returning a number ten times too small, and it was the only source my script read. The $5.25 it pulled was a live quote, not a close. Against a $48 strike the arithmetic is right: 814.3% in the money. The calculation never failed. The input did.

A single source is a single point of failure that never announces itself. Nothing inside the system could have caught this. The script read the field correctly. The model reasoned over it correctly. The only thing that catches a confident wrong number is another source with no reason to be wrong in the same way.

The model was never the weak link. The pipe was.

This was not new territory for me. I defined the roadmaps for a team building agentic AI against human operations: accounts payable, insurance underwriting, procurement, and order management. Every one of those workflows depends on reading data from systems we did not own and making a decision on it.

The sequence was roughly the same. We would ship better extraction in one release, better exception handling in the next, fewer approval steps after that, and eventually phase the human out. Capability was the dependency we tracked, because capability is what you can benchmark and put a date against. Nobody benchmarks whether a system can tell its data is wrong, and in accounts payable that is most of the risk.

But a system reasoning brilliantly over a field that reads price unavailable is not held back by its reasoning. It is held back by the field. That is a data problem wearing a reasoning problem’s clothes, and no model release fixes it.

Good data is not the boring layer underneath the agent. It is the agent’s entire contact with reality. When that contact breaks quietly, something outside the system has to notice.

None of this is an original observation. Garbage in, garbage out is the oldest idea in computing. What I did not expect was how invisible the garbage would be, or how fluently the model would reason over it.

A workflow, not an agent

Almost anything gets called an agent now, and the word implies far more independence than most of these systems have.

This is a workflow. The morning email is deterministic code with no model in it at all. Claude does one step, when I invite it. I read every output before it matters. That is the most supervised configuration available, and it still produced everything above.

What would it take to make it a real agent? A live options chain API. An earnings calendar. A scheduled loop that wakes the model up with context. Durable state read from the live system rather than from notes it wrote last session. A broker API with an approval gate. All ordinary engineering. A credit card and a week would close every gap.

And that agent would still make all three mistakes above. It would still answer from memory when it could have looked something up. It would still read a bad price without questioning it. It would still pursue the wrong objective competently. Removing me from the loop repairs none of that. It removes what was catching it.

The obvious replacement is to have the model check itself. That does not work, for structural reasons rather than technical ones. Self-critique runs on the same weights, the same priors, and the same confident register that produced the error. Asking a model whether it is sure produces another fluent answer, not a different kind of answer.

Autonomy is not neutral with respect to correctness. It is negative unless you replace what you took out.

What I am building next

Knowing all of that, I am still building the agent, but not by trying to make the model more reliable. The design principle I have landed on is the opposite: do not ask the model to check itself, and check it instead with something that is not a model.

That works here because almost every rule I trade by is mechanical rather than a matter of judgment. A delta at or below 0.15 is arithmetic. An earnings date inside the option’s life is a date comparison. None of it requires an opinion, and none of it can be made up. So the system has three parts, and I trust each one differently.

The model proposes. It pulls the live option chain, screens the candidates, and writes an order ticket with its reasoning attached. This is the work it is genuinely good at, and it is allowed to be wrong here, because nothing it produces reaches my broker without passing the next two steps.

Ordinary code decides whether that proposal survives. Not a second model, and not a prompt asking Claude to check its own work, but plain rules I write in advance and run against every ticket. Delta out of range, an earnings date inside the window, open interest too thin, or any number arriving without a source and a timestamp, and the ticket dies. Not a warning I can click past. A refusal.

I approve the one step that cannot be undone. The agent can research and propose all day, but it cannot place an order. That is one decision from me per trade instead of a check on everything it produces. A system that needs me to read everything is one I will eventually stop reading properly.

Underneath all three sits the piece I got wrong at first. My instinct was a fallback chain: try Google, and if that fails, try Yahoo, then CNBC. A chain cannot work, because a fallback trusts whichever source answers first and has no way to notice that the first answer is wrong. It would have taken Google’s $5.25 every single morning. So the system now asks every source at once and takes the answer the majority agree on, naming the ones that disagree rather than quietly dropping them.

Two sources will never match to the penny, so the band matters. I settled on 2%, and the report prints the actual spread so I can judge for myself.

It also does nothing about the third failure. Not one line of it would have asked whether maximizing premium was the right goal in the first place. A rule can check a delta. It cannot check an objective, and I do not know yet what would.

The honest summary is this. Claude is not something I can hand $1,000 and a brokerage login, and not because it reasons poorly. It is because the data underneath it can go wrong without saying so, and it will keep reasoning beautifully over the gap.

What it is instead is the best teacher I have had on this subject. It reads a position I am unsure about and works through whether to close it early or let it run, and shows me the reasoning. It proposes a roll and lays out the arithmetic behind it. It does this patiently, at any hour.

The failures in this article are real. So is the fact that I would not have learned this half as fast without it. Those two things are not in tension. That is what a very good analyst is: excellent at the work, and not the person who signs off on it.

Twenty-five years ago I sat in a room while a mathematician explained the formula that had just decided what my compensation was worth. I didn’t get it then. I do now.

The math was never the hard part.

The hard part is knowing when the machine explaining things to me is wrong. My trading rules tell me when I have stepped out of bounds. Claude never does. It is exactly as fluent when it is wrong as when it is right, and I am the only thing in the loop that can tell the difference.

I spent a year building agents on the premise that the goal was fewer human operators. Less checking, fewer approvals, more of the work happening while nobody was watching. Then I became the operator, and it changed my mind.

Not one rule in my system was in the original design, because I did not yet know what I was guarding against. Building the agent will take a week. Learning what to watch for is taking much longer, and I am not finished.

That learning is on nobody’s roadmap, including the ones I defined.

Sources

• Alain Rossmann, founder of Unwired Planet, which became Phone.com and then Openwave. Phone.com’s acquisition of Onebox.com closed April 14, 2000, per SEC filings.
• Openwave’s 2001 stock option exchange program, for anyone curious how a repricing works
• Futures and Options, Professor Kathleen Hagerty, Kellogg School of Management

This is a personal account, not financial or investment advice.

Claude Is a Very Good Analyst. I Am Still the One Checking Its Work. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

It started as one sentence I wrote on a Thursday afternoon. By Sunday the app was in App Store review, waiting to reach my family and friends.

I want to be precise about how the work divided, because it’s the whole point. Claude wrote the code. All of it. I never typed a line of Swift. My job was to decide, thousands of small choices about what the app was, what it said, how it looked, and what it should never do. Claude did the building. I did the deciding.

Here is where it started. The entire product vision, in my own words, was one line: “Build an iOS app to keep track of all the photos I’ve taken at art museums.”

The first commit landed at 6:02pm on July 16, an empty Xcode shell I’d named Gallery. By 8:10 that night the first real version existed: museums, a Been list, a Want to go list, and, already, a Masterpiece of the Day on the Home tab. That last one wasn’t in the sentence, and it came from the first real problem I hit: what does the app show before you’ve imported a single photo? An empty app is a dead end, so on night one I put a masterpiece on the home screen to greet you when you have nothing of your own yet. The vision was one line about tracking. Building it meant a hundred decisions that line never hinted at.

Three days later it had a name, ArtCurato, a tagline, and a whole second half I never wrote down: the art beyond the museum walls, the street murals and buildings and signs I photograph when I travel. My one sentence was about museums. The app turned out to be about both.

One honest caveat, though it turned out to be the whole point. I didn’t start from zero. Six years as a software engineer, then years in product management, and in between I taught myself Swift and Xcode. But the code was never the special part. What I brought was product intuition and a sense for design, knowing what a screen is for, what to cut, which of ten options is right and why. That’s what I’d spent years building, and it’s the part Claude couldn’t do for me. Claude could generate. It couldn’t choose.

There was a clock on it, too. I was building with Fable 5, Claude’s most capable model, in the last few days before it left my Pro plan’s included usage and moved to pay-as-you-go credits on July 20. So I arranged my sleep around usage limits. Three days wasn’t only ambition. It was a deadline I set against a billing change.

Solving the empty room

That first-night masterpiece was a patch. The real answer took shape the next day, and it’s the piece I’m proudest of. A gallery wall of artwork you can scroll through, with a masterpiece of the day in the center. If a piece catches your eye, you tap the museum that holds it and add it to your list. The empty state stops being a dead end and becomes an invitation. The app turns from a record of where you’ve been into a nudge toward where you might go.

Even this had a bug worth remembering. The gallery wall kept showing the same museum-room photo multiple times. Two different Monet titles resolved to the same Wikipedia image, so my water lilies showed up twice. De-duping by title couldn’t catch it. Claude had to track the resolved image URLs. A small thing, but it taught me how often the bug is one level below where you’re looking.

How the sentence outgrew itself

“Keep track of photos taken at art museums” is still the core. The GPS-and-date import files your photos under the museum you were standing in. That never changed. But over three days, piece after piece gathered around that seed, each obvious only after it arrived.

The street photos came first: the murals and signs I shoot when I travel deserved the same care as the museum pieces, so the app grew a second half for the sights beyond the walls. The Want to go list turned a record of the past into a statement of intent. The daily masterpiece turned the archive into inspiration. And only at the end did a tagline show up and name what I’d apparently been building the whole time: your art world, curated by you.

None of it was in the sentence. All of it belonged there anyway.

The debates were the real work

Somewhere in the middle I noticed I was treating Claude like a designer I was in dialogue with, pushing back on its choices, asking it to defend them. But I have to be careful here, because it would be easy to fool myself. A designer pushes back because they have their own stakes and their own taste. Claude has none of that. It pushed back exactly as hard as I asked it to and folded when I wanted it to. So I can’t tell you whether what I felt was real creative friction or a good mirror. What I can say is that it forced me to state out loud why I believed what I believed. Maybe that’s all a design argument ever does.

Either way, the decisions I remember most weren’t about features. They were about words.

“Yet to see” vs. “want to go.” The longest-running argument in the project. “Yet to see” was poetic but passive. “Want to go” carried intent. I picked “want to go” almost everywhere, but let “Waiting for you” survive on the Home tab as the one poetic exception. The compromise is the part I like, plain intent almost everywhere, one line of feeling where it counts.

“Created by” vs. “made by” vs. “handcrafted.” “Handcrafted” oversold it. “Created” felt corporate. “Made by an art lover and avid traveler” won. And it only got there because I caught that my first draft, “an art lover and an avid traveler,” accidentally implied two people.

Disruptive actions. The exchanges I’m proudest of were about scary words. One button let you take a photo out of a museum’s collection, and the first label was “remove from this museum.” It felt destructive, as if it might delete the photo entirely. “Unfile” was accurate but nerdy. I landed on “unlink from this museum,” with a note explaining that the photo itself is never touched. The same instinct shaped the privacy promises, which are written as “will never,” not “we don’t currently” and not “your data is safe.” A button should be honest about exactly what it does, and no more. That’s where a product’s ethics actually live: in its words.

The debugging saga

Some of it was just war. And it’s worth being precise about who fought it. I didn’t fix these. I noticed them, described them, and kept saying “no, that’s still wrong” until the real cause surfaced. The diagnosis was Claude’s. The judgment that it wasn’t fixed yet was mine.

Dark mode was the longest bug hunt of the project. The canvas glowed a strange silver, a fixed light color hiding underneath everything. Then the Liquid Glass tab bar ignored every fix until we rebuilt it from scratch on each switch. Each failure narrowed the diagnosis. The screenshots were what cracked it.

Execution versus judgment

Everyone says AI blurs the roles, that product, design, and engineering melt into one person with a chat window. That’s not what I felt. What I felt was a clean split between execution and judgment. Claude took the execution. What was left in my hands, quietly taking up almost all of my three days, was judgment.

I spent real time on the color palette. On the icon. On the exact wording of a message. On how a single page was laid out, what went first, what could be cut, what a screen was really for. None of that is execution. You can’t prompt your way to it, because the tool will happily generate ten versions and defend all of them. Someone still has to look at the ten and know which one is right, and why.

The honest part, and the real test

I still think the app is a little too complex, and the mental model it asks for might only make sense to me, the person who built it.

These tools make it easy, maybe too easy, to build something that fits only you. Normally other people slow you down, and that friction helps. An engineer questions whether a feature is worth it. Time and cost force you to cut. Those constraints quietly push a product toward working for other people, not just its maker. With an AI, that friction is gone. Nothing pushes back that has taste of its own, so you can follow your own instincts all the way down and end up with something shaped for your head and no one else’s.

I may have proven that design taste and a product manager’s judgment can direct an app into existence. I haven’t yet proven that anyone but me wants to live in it.

Three days, one builder, zero real users. That’s the actual experiment, and it hasn’t started.

What I learned

You still need the fundamentals. You have to know how to navigate Xcode, run the simulator, build to your own phone, feel it in your hand. Distribution is its own skill, and the nuances of TestFlight took real effort no one warns you about until you’re in it.

But the deeper lesson is quieter. When the building stops being the hard part, the choosing is what’s left, and the choosing is relentless. What things are called. What promises to make. What a button should be willing to admit it does. I made those calls for three days straight, and no one else could have made them for me, because they were mine to make.

The idea was the easy part. It was one line long. Now it’s sitting in review with a name it earned along the way, and soon my friends and family will open it and tell me whether it makes any sense to anyone but me. That’s the part I can’t debate my way through.

Claude and I Built an iOS App in Three Days. It Wrote the Code. I Made the Decisions. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently finished reading Steve Jobs in Exile by Geoffrey Cain. There are countless books about Jobs, the founder who reshaped personal computing (Apple I, Apple II, Macintosh), digital music (iPod and iTunes Store), and mobile computing (iPhone). What stood out to me here was his evolution from a highly driven entrepreneur into a leader who learned to channel intensity through strong teams and disciplined execution.

Earlier, I also read Ed Catmull’s Creativity, Inc., which covers the Pixar years and helps complete the picture of Jobs’s time away from Apple. After that, I wanted to understand the missing chapter at NeXT. This book filled that gap.

Last night I saw a preview of Young Washington, a biopic released ahead of the 250th anniversary of American independence. It traces Washington’s early life, from his humble upbringing to his service in the Virginia Regiment during the French and Indian War, and later his return to public leadership.

What do they have in common? Both experienced defining setbacks before their most consequential achievements.

Jobs was forced out of Apple. Washington resigned his commission from the Virginia Regiment in 1758 during the French and Indian War period. Both left the institutions that first shaped their identity, and both stepped away from roles that had defined their public standing. And both returned years later in a different form.

What stands out is not the setback itself, but what it forced them to become.

Jobs returned to Apple with a different operating style shaped by NeXT and Pixar, still intense but more focused on product discipline and team execution. Washington returned to public life with broader experience in governance, negotiation, and long-term statecraft. In both cases, time away expanded their leadership rather than interrupting it.

From my perspective working in tech, this pattern is more common than it appears. The most meaningful transformations often happen after periods of loss or change, when someone has to rebuild without the identity that previously defined them.

Steve Jobs in Exile

Jobs founded NeXT to build high-end workstations for education and research. When hardware struggled to gain traction, the company shifted toward software, and NeXTSTEP became its defining contribution, later licensed more broadly.

This shift contrasted with Jobs’s earlier belief in tightly integrated hardware and software, a principle he later reinforced at Apple.

At Apple, NeXT’s legacy became deeply embedded in the company’s foundation, including the NS frameworks still visible in macOS and iOS today. In many ways, NeXT became a quiet foundation for Apple’s second era.

That influence became most visible after Jobs returned in 1997, when he helped stabilize Apple during a financial crisis and reset its direction. One key decision was securing a $150 million investment from Bill Gates.

The agreement included non-voting Apple shares, continued Microsoft Office development for Mac, and a broader patent cross-licensing arrangement. It marked a turning point in Apple’s stability and in its relationship with Microsoft during the late 1990s antitrust era.

What changed was not just strategy, but posture. A leader once known for rejecting compromise became willing to make it when survival required it.

George Washington in Transition

After resigning his commission in 1758, Washington returned to Mount Vernon and focused on managing his plantation. He also served in the Virginia House of Burgesses, building experience in politics and civic leadership outside the military.

Over time, his leadership broadened. He moved from military command toward governance and negotiation, learning to manage competing interests rather than battlefield outcomes.

That period away from war reshaped how he later led during the American Revolution.

Final Thoughts

Failure is a comma, not a period.

Jobs never lost his intensity. Across NeXT, Pixar, and Apple, that core trait remained constant. What changed was how it was expressed, shifting from direct control toward channeling it through teams and systems that could scale.

Washington’s path reflects a similar pattern: separation from his original role expanded his capacity rather than diminishing it.

Their returns were not repetitions of the past, but continuations shaped by what came between.

The Setback That Redefined George Washington and Steve Jobs was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Samir opened by joking that he got lucky with the post-lunch slot. Then he grounded us in a real event. In 2015, a 7.8 magnitude earthquake hit Nepal. The quake triggered a massive avalanche from Mount Pumori to Everest Base Camp, killing 22 people. That was the scenario we were about to step into.

We started outside in the courtyard. Samir made a bold claim. With nothing but a rope, a group of people could support a full grown adult standing and walking.

One brave volunteer stepped in. With two colleagues supporting him, he was able to walk around like an acrobat. The trust required was intense. What surprised me most was that those of us holding the rope felt even more nervous than the person walking. We were responsible for his safety.

During the debrief, words like trust, dependency, and accountability came up quickly. It set the tone for what followed.

Back in the conference room, chaos took over. Tables were flipped. Water bottles were scattered. There were tents, splints, and food everywhere.

We were split into three teams: blue, red, and green. Each team member had an assigned role: a camp director, a sherpa, people with visual impairment, hand injuries, leg injuries, and one person in shock. I was the person in shock.

Each role came with a character card. Samir made one thing clear. The director was not the boss. They were simply someone who could direct.

The director had the instructions but could not do the actual work. The sherpa had special knowledge and could guide others. Those with injuries were physically restricted. Blindfolds for the visually impaired. Hands tied for hand injuries. Legs bound for leg injuries.

My role was to sit still. I could not move. I could not help. I could not receive first aid until someone noticed me.

For five to ten minutes, I sat there watching my teammates pitch tents and gather supplies. I felt useless.

Slowly, injuries were treated. Splints were added. A brace appeared. Eventually, someone remembered me.

Once I was revived, I became able bodied, but with one catch. I could no longer speak.

I jumped in immediately, collecting food and helping however I could. I just could not say a word.

Our team was the first to evacuate. I held a visually impaired colleague as we moved toward the safe zone. Because I could not talk, another teammate had to guide him, helping him take each step down the stairs carefully.

During the debrief, one question stuck with me. Was the challenge about evaluating our team, or about helping everyone else to safety?

That is where the first real insight landed. Our team was the immediate project. All three teams together represented the company.

When we mapped the roles to our company, the parallels were obvious. The sherpa was someone in a client facing role who understands customer needs deeply. The director resembled a product or project manager articulating requirements. The injured mirrored middle management constrained by process or pressure. The visually impaired were people executing without full context.

And the person in shock felt a lot like a new hire. Someone capable, but lost until someone takes the time to bring them in. My own limitation stood out. Once I recovered, I could not talk. To others, it may have looked like I was ignoring them or disengaged. In reality, it was simply a constraint they could not see. That is what stayed with me.

In complex organizations, we have to trust that people share the same goal and intent. We have to trust that everyone has a role, even when we do not fully understand it. Empathy matters because we rarely know what constraints someone else is operating under.

So much of teamwork, at work and in life, comes down to giving people the benefit of the doubt and trusting that they are doing the best they can with what they have.

Teamwork Under Pressure. Lessons From an Avalanche Simulation Workshop was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

An Old Idea, Making Headlines

This 160-year-old economic concept has recently resurfaced after Microsoft CEO Satya Nadella tweeted about it, reigniting discussion across the tech world.

Satya Nadella on X (formerly Twitter): "Jevons paradox strikes again! As AI gets more efficient and accessible, we will see its use skyrocket, turning it into a commodity we just can't get enough of. https://t.co/omEcOPhdIz / X"

Jevons paradox strikes again! As AI gets more efficient and accessible, we will see its use skyrocket, turning it into a commodity we just can't get enough of. https://t.co/omEcOPhdIz

Radiology as a Real-World Example of Jevons Paradox

Radiology offers a clear illustration of how this paradox plays out in practice. AI helps radiologists review scans faster and more accurately. At first glance, this suggests that fewer radiologists would be needed. In reality, the opposite often occurs. Lower costs and faster turnaround times encourage more scans to be ordered. Preventive screenings expand, new use cases emerge, and overall imaging demand increases.

In 2016, Geoffrey Hinton, one of the pioneers of artificial intelligence, made a provocative claim at a machine learning conference. He suggested that people should stop training radiologists because deep learning would soon outperform them at reading medical images. The comment reflected the rapid progress of AI at the time and reinforced the belief that automation would reduce demand for human radiologists.

Despite these predictions, radiology workloads have continued to rise. CT and MRI usage has increased steadily across the United States, Canada, and other regions. In U.S. emergency departments alone, CT scan use has nearly doubled over the past 15 years, according to data published in Neurology. Rather than shrinking imaging volumes, AI driven efficiency gains have coincided with more studies being performed overall.

The lesson is not that efficiency fails, but that it reshapes demand in ways that are easy to underestimate.

The Three Effects of Jevons Paradox Explained

To make this more concrete, it helps to break Jevons Paradox into three possible effects. Imagine a simple scenario in which AI delivers a 10% efficiency improvement in radiology.

Direct effect: Each scan becomes quicker to review. Radiologists spend less time per case, which is the obvious and intended benefit.

Rebound effect: Some of that saved time is used to do more work. Doctors may order additional scans because it is easier and faster to do so. If half of the efficiency gain goes toward extra scans, volume increases by 5%, partially offsetting the original savings.

Backfire effect: In some cases, demand grows by more than the efficiency gain itself. If scan volume rises by more than 10%, total resource usage increases even though each scan is cheaper and faster. Efficiency ends up driving higher overall consumption.

Together, these three effects show that efficiency can have very different outcomes: it may reduce work, partly offset savings, or even increase total usage.

Back to Nvidia and Deepseek

The same dynamic helps explain what happened to Nvidia after the DeepSeek announcement. When DeepSeek revealed that its R1 reasoning model could rival leading AI models while being cheaper and more efficient to train and run, investors reacted quickly. Nvidia’s share price fell about 17% in a single day, wiping out roughly $600 billion in market value.

The concern seemed logical. If AI models become cheaper and more efficient, fewer high-end chips should be needed. Lower compute per model should mean lower overall demand for GPUs.

Cheaper and faster models lower the barrier to entry, allowing more companies to train AI and more teams to experiment. Faster iteration leads to more total training runs. As AI spreads into new products and workflows, the underlying infrastructure grows alongside it.

The result mirrors radiology. Making each training run cheaper increases total usage. Demand for GPUs and data center capacity doesn’t disappear; it grows. Just as faster scans lead to more scans overall, more efficient AI models can expand the chip market instead of shrinking it.

Jevons Paradox in Action: How AI Efficiency Drives More Demand was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

When news broke that NVIDIA is investing $5B in ailing Intel, my first thought was the $150M Microsoft put into Apple back in 1997 to stabilize a struggling rival. At the time, Microsoft’s stake was about 3% of Apple. By 2003, Microsoft had sold its entire position. Had they held on, it would be worth roughly $90B today — a 600x return, or about 25.7% annualized.

Apple Got a Lifeline from Microsoft in 1997

Microsoft’s $150 million lifeline to Apple in 1997 was more than a bailout — it was a strategic play during an antitrust storm. Apple got the cash it desperately needed to survive, while Microsoft kept its only real rival alive just as the U.S. Department of Justice was intensifying its case against Windows. By propping up Apple, Microsoft undercut accusations of crushing all competition and polished its public image as a supporter of choice in the PC market — critical optics while regulators closed in.

Fast Forward 28 Years: Why NVIDIA and Intel?

Historically, AMD’s main rival was Intel, competing for CPU dominance as the cost-efficient challenger. More recently, AMD has become a real threat to NVIDIA in AI accelerators, particularly in inference — the deployment stage after a model is trained, which requires far more chips than training and makes cost and power efficiency critical. AMD’s lower pricing delivers major savings for cloud providers buying at scale, turning it into a growing challenge to NVIDIA’s dominance.

In response, NVIDIA has found common ground with its old CPU rival Intel, partnering in manufacturing and supply chain strategy. The logic is simple: the enemy of my enemy is my friend. AMD competes with Intel in CPUs and with NVIDIA in GPUs/AI. By working together, Intel and NVIDIA can present a united front against AMD’s rise.

A Strategic Alliance Against AMD

This partnership isn’t just about data centers. NVIDIA and Intel plan to bring GeForce RTX graphics — GPUs known for advanced gaming performance, ray tracing, and AI features — directly into Intel’s x86 CPUs. By combining CPU and GPU in the same package, data moves faster, power use drops, and devices can be made thinner and more efficient.

It’s a clear consumer PC play, moving NVIDIA beyond its reputation in AI data centers and into mainstream laptops and desktops. The move directly challenges AMD’s integrated CPU-GPU chips while positioning Intel and NVIDIA at the heart of the coming AI PC era.

Intel Foundry as Strategic Backup

NVIDIA has long been loyal to TSMC for its most advanced GPUs, a relationship reinforced by Jensen Huang’s personal ties to Taiwan and TSMC’s leadership in manufacturing. That makes Intel Foundry less about replacing TSMC and more about providing strategic backup.

With rising geopolitical risks around Taiwan, diversifying supply has become critical. Intel’s progress in advanced nodes and packaging offers NVIDIA an alternative pathway. Even if flagship GPUs remain at TSMC, having Intel as a second source strengthens NVIDIA’s supply chain resilience, improves bargaining power, and deepens their collaboration in the consumer PC market.

Closing Reflections

Having worked at Apple for five years and spent many more across the industry, I’ve watched rivals become partners, underdogs become leaders, and once-dominant players fight to stay relevant.

Microsoft’s rescue of Apple in 1997 looked strange at the time, but in hindsight it was a brilliant defensive strategy. Today, NVIDIA’s investment in Intel carries a similar flavor — not just financial support, but a way to reshape the competitive landscape against AMD and strengthen its own position in PCs and AI.

The NVIDIA–Intel partnership also reflects bigger forces: it strengthens U.S. chip independence, positions the companies more strategically against hyperscaler in-house chips, and gives NVIDIA a political and regulatory shield.

In this piece, I’ve focused on the AMD rivalry because it offers the clearest window into the stakes of this moment. But it’s only one piece of a much larger story. Alliances in tech shift constantly, and each move carries layers of strategy well beyond what’s visible on the surface. That’s what keeps this industry endlessly fascinating — and why there’s much more to explore in the chapters ahead.

NVIDIA’s $5B Intel Deal: Echoes of Microsoft Saving Apple was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

During my trip earlier this week, I spent time with one of the founders DJ. His passion for Kosovo’s future was so strong it almost brought me to tears. Only afterward, when I looked at DJ’s LinkedIn profile, did I see the line that perfectly captured what I had just experienced:

“On a mission to make Kosovo #1 in agentic AI builders per km² — more than anywhere else on Earth.”

Those words weren’t marketing. They were the conviction of someone who believes deeply in his country and its people. And his declaration made me see Kosovo not just as a new partner, but as a place with world-changing potential.

Young, Gritty, and Building

Over three days in Pristina, I met dozens of computer science undergraduates and early-career professionals. They were young, gritty, and determined to make their mark. They weren’t just studying theory; they were experimenting, collaborating, and putting their skills to work with a confidence well beyond their experience.

Being around them reminded me of what it feels like to stand on the edge of new possibilities — the beginning of careers, the start of a new industry, the building of a country itself. I left not just with new connections, but with the conviction that I want to keep coming back.

A Role Model in Tech

When Kosovars talk about success in the tech world, one name comes up again and again: Mira Murati. Former CTO of OpenAI, she has since joined the top ranks of entrepreneurs raising billions to grow her company. But beyond her accomplishments, she’s admired for her leadership — her employees famously stayed loyal to her even when tempted by lucrative offers from Meta.

For young Kosovars, she’s more than a headline; she’s proof that someone from their broader community can shape the future of technology.

A Teenager Among Nations

Kosovo declared independence in 2008, making it just 17 years old — a teenager among nations. Nearly everyone I met was older than the country itself.

Culturally, Kosovo and Albania are sisters. Around 92–93% of Kosovars are ethnically Albanian, sharing the same language, traditions, and a strong sense of kinship. Yet they remain separate nations, shaped by the political history of the Balkans.

What stood out to me wasn’t division but unity — a shared heritage and pride that transcends borders. In many Kosovar towns, churches and mosques stand just a few meters apart, and both Christian and Muslim holidays are official public holidays. It’s common for Muslims to attend Christmas Mass with their Christian neighbors, just as Christians join in Eid festivities. In a world where faith too often divides, this everyday coexistence felt both rare and inspiring.

Rebuilding with Gratitude

Kosovo’s story is one of resilience. The country was rebuilt through donations after years of conflict. I heard the story of Switzerland sending thousands of cows to restart dairy farms. Not a single cow was eaten.

That spirit of giving is matched by Kosovars’ deep gratitude, especially toward the United States. No matter the administration in power, people I spoke with expressed appreciation for the U.S. role in their independence.

Then there’s the diaspora — Kosovars who left for Germany and other nearby countries, but who are now returning to help build. Their stories carry a sense of responsibility: not just making a living abroad, but bringing knowledge, skills, and energy back home.

Looking Ahead

The next decade will determine whether Kosovo’s software sector matures into a true innovation ecosystem or remains primarily a consultancy hub. The key lies in how quickly product thinking, design excellence, and engineering rigor become the norm.

The immediate opportunity is to build a culture where design, engineering, and product management are integrated disciplines that shape how software is developed. By focusing on solving real problems, practicing user-centered design, and embedding modern engineering practices, Kosovo’s young and adaptable talent can move beyond client-driven outsourcing toward building products with global potential.

If this mindset takes root, Kosovo will not just be a reliable outsourcing market — it will emerge as a birthplace of enterprise-grade, beautifully designed software with worldwide reach.

In Kosovo, Mira Murati’s Story Sparks a New Generation of AI Builders was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.