Claude

I came back from a match with two phones and one usable file. A retake had reused the filename of the first period and written straight over it. Every screen in the app had shown a green tick, and the test suite was green too: 283 tests at the time, 425 by the end of that week, passing the whole way with the bug sitting in the code. So the tests were not the check. Nothing that only runs the code an agent wrote for me is going to catch the thing the agent and I were both wrong about. What worked was running review as an attack, over and over. Each round, two or three agents, each given a different lens and told to assume the code is broken and report only concrete failure scenarios. One on data loss. One on integration. One asked to walk a real Sunday morning: the tablet dies at half-time, there is no signal at the pitch, somebody calls a false start, the game goes to extra time. Five rounds turned up 21 more ways to lose footage without anyone noticing. Rounds two and three each found bugs introduced by the previous round's fixes, which I had not expected and should have. The match-day lens caught things no amount of code reading would have. The worst find was already shipped: a check that would have refused to record the third period of a 3×30 match on a pitch with no signal, guarding against a problem that is completely fixable at home, by destroying footage that can never be taken again. That one became a rule at the top of the project doc. Never block recording. Refuse at processing time instead, hours later, at home, and make every refusal carry a remedy you can reach from the screen that shows it. The other rule is about tests. A fix without a regression test that provably fails without it has not been fixed, so now I make the agent revert its own fix and show me the test going red before I accept it. Green on its own means nothing. I want to have watched it be red for the right reason.

The recording core in GoalCut is about 7,000 lines of Kotlin that I directed and did not write. Camera2 into a hardware HEVC encoder into a fragmented-MP4 muxer, none of which I would have attempted on my own. Reading it line by line tells me very little about whether it works, so most of that week went on a different question: how do you check an agent's native code when you can't audit it? What I settled on was to stop asking the code and start asking the phone. The first thing I had built was not the camera screen. It was a 280-line capability probe: enumerate every camera the handset exposes, dump what each one claims it can do, run it over adb. That is how the real problem surfaced. The ultra-wide lens advertises 3840×2160, but Samsung's encoder profile for that lens stops at 1080p, so the standard React Native camera library could never have got there, whatever resolution I set. Same move for the file format. Instead of a discussion about which container was safer, I asked for the experiment: record, force-quit the app mid-take, try to play the file back. A plain MP4 keeps every frame but writes the index only on a clean stop, so there is nothing to play. Fragmented MP4 writes small self-contained pieces as it goes, 156 of them in a 79-second take, and the hard kill cost about a second. Then soak tests I could not have sat through. Phone plugged in, me out for the evening, the build installing itself and the telemetry writing to disk. The S23 Ultra recorded 49 minutes backgrounded with the screen off, 8.18 GB, memory flat at a 435 MB peak. The thing that turned out to be broken was the soak tool itself. That soak ran 58 minutes instead of 45, because React Native suspends JavaScript timers while an app is backgrounded, so the auto-stop only fired on the next resume and the telemetry collected 8 samples instead of about 234. The agent had written its own instrument wrong, and nothing except the artifact would have told me. Which is the argument for working this way.

I started with a chart that made no sense. Over five years AppLovin is up more than 750% and Snap is down about 89%. Both make money the same way — selling ads inside mobile apps. So why did one go vertical while the other collapsed? The whole thing turns on Apple's 2021 App Tracking Transparency rules. Snap set its record high near $83 that year, then fell apart. Apple's change made it much harder to track people across apps, which was exactly the data Snap needed to sell the highly targeted ads that paid its bills. It never found a replacement. In 2025 it lost $460 million, dragged down partly by roughly a billion dollars a year in stock-based comp that dilutes shareholders even when the business creeps forward. Its revenue per user was around $2.87 against Meta's $11.89. Snap owns the 18-to-24 crowd advertisers want, and still can't monetize them the way Meta does. AppLovin walked into the identical wall and got over it. In 2023 it shipped an AI ad-targeting engine, Axon 2.0, that used its own data to match ads instead of relying on the device tracking Apple had just switched off. That's the hinge. Last quarter its revenue grew 59% to $1.84 billion, net income more than doubled, and it threw off enough cash to buy back a billion dollars of stock in a single quarter. What I came away with: the Apple change wasn't the cause of the split, it was the test. Both companies got the same problem on the same day. One rebuilt its targeting from scratch, the other absorbed the hit and kept limping. Five years later that one decision is most of the distance between the two charts. Worth flagging the other side — even AppLovin bulls now call its growth 'mature,' and the stock swings hard, so five strong years back don't promise five more.

Anthropic draws a clean line between two tools that look similar but solve different problems. MCP connects Claude to data—credentials, live systems, writes that persist. Skills teach Claude what to do with that data—the recipes, not the kitchen. I tested this distinction against the reference server repo and found the clearest case study: sequential-thinking should have been a Skill, not an MCP server. Here's why. Sequential-thinking provides a tool for structured problem-solving through dynamic reasoning—it manages thoughts, revisions, branches, and step counts. But it fetches nothing. No external system, no auth, no side effects, no network calls. The server hands back your own reasoning with bookkeeping fields attached. As one way to frame it: it's a prompt pattern wearing a protocol costume. That means it pays MCP's costs for none of MCP's benefits: Install: a Node/npx or Docker process, versus dropping a markdown folder in. Context cost: the tool schema lives in context on every message, versus name and description until the skill triggers. What you get: your reasoning round-tripped through a subprocess, versus the same instructions with no subprocess at all. The context point is the real one—MCP tool definitions compete for context space, which is exactly why Skills use a different loading approach. And honestly, extended and interleaved thinking now do natively what sequential-thinking bolts on from outside. The one genuinely distinct feature left is the branching and revision bookkeeping—an explicit audit trail of a plan that gets revised. But a Skill that tells Claude to write its plan to a file and amend it produces the same artifact. Linear's MCP server is the contrast case—the archetype of what MCP is actually for. It's remote, centrally hosted, behind OAuth 2.1, with live data and writes that persist. When you call a tool, the client sends JSON-RPC over HTTPS with your bearer token, Linear translates that into GraphQL against its own API scoped to what you can see, and the result comes back. That's state you don't have, behind auth you had to grant, with side effects that outlive the conversation. Sequential-thinking has none of that. The working rule: if it has no credentials, no live data, no writes, and no execution outside the sandbox, it's procedural knowledge and belongs in a Skill. The composition pattern that actually works: a Skill describing your procedure, calling MCP servers for the data.

My Monday football team wanted a Veo. Then somebody looked up the price: Veo bills New Zealand and Australia in Australian dollars, so it's A$2,149 for a Cam 3, before the annual subscription. That ended the conversation. So I went looking for the cheap version, and found it. Andever, out of Korea, does the thing I had been picturing: two or three ordinary phones instead of a camera, and software does the rest. It's in Korean, which I read fine. I still couldn't use it, because they operate in Korea and I'm in Auckland. What the heck, I thought. I'll build it myself. The software I knew how to start. The rig I did not, and nobody sells one. I went through camera shops here, then Temu and AliExpress, hesitating over cheap listings because half of them never ship. Every product held two phones flat side by side, or one phone at any angle I liked. Never two phones angled apart. What exists instead is studio lighting hardware: a stand built to hold a softbox four metres up, and a bracket built to carry two flashguns. I ordered a NEEWER SP-08 and waited two weeks. While it shipped I put one phone on the stand and recorded three quarters of a real match, which settled a question I had been avoiding. One ultra-wide lens does not see a whole football field, and a player at the far corner is a smudge a few pixels across. So it's two phones, on a bar at the halfway line, each covering half the pitch with about a quarter of the middle overlapping. That overlap is the trick: it lets a pipeline line the two files up after the match and stitch them into one image. Nothing gets decided at the pitch, which is the part I like. A motorised mount has to guess right while the game is happening, and a wrong guess is gone for good. Both phones record true 3840×2160 now and one match has been through the pipeline. The first bar was plastic and bent under their weight, so the two horizons never met. A 27 cm metal flash bracket arrived last week. I am now getting quotes on 3D printing, which I did not see coming.

At Saywise, we ship fast. That's a feature, not a bug—but it comes with a real cost: documentation drifts, edge cases slip through, and by the time you realize a README is stale, three more things have changed. We were running into two specific problems. First, our core docs—CLAUDE.md, AGENTS.md, README.md—were constantly out of sync with what we'd actually built. With the pace of iteration we were moving at, keeping them current felt like a losing game. Second, even with solid PR review practices, we wanted an extra safety net: a systematic way to catch issues in code that had already merged, especially patterns we might miss in the moment. We decided to automate both with Claude Routines. The setup was straightforward in concept but required real iteration on the prompt itself. We configured a routine to run every 24 hours, early in the morning, that would: Pull all PRs merged in the last day. Run a fresh code review on them, looking for logic issues, edge cases, and potential bugs we might have missed in the moment. Audit our key documentation files against the current codebase and flag anything that looked stale or inaccurate. Create PRs for any fixes or updates it found. Post a summary to our engineering Slack channel so the team could see what it caught and what it changed. The prompt tuning was the real work. We had to be specific about what "stale" meant, what kinds of issues we actually cared about flagging, and how aggressive we wanted the routine to be. Too strict and it became noise; too loose and it missed the point. After a few iterations, we landed on something that felt right. The impact has been real. Our docs stay current without anyone having to manually track them. We catch subtle bugs and inconsistencies that slip past human review in the moment. And the Slack summaries give the team visibility into what's happening—it's become a useful daily checkpoint, not just a bot running in the background. It's not a replacement for careful code review or thoughtful documentation. But as a daily layer of protection and maintenance, it's been exactly what we needed at our pace.