Isaac Is Laughing

New engineers now start their careers judging code they didn't write and answering architecture questions I didn't get until I was senior. Here's what I'd learn first if I were starting today. medium.com/@mosquera/startin…

My friend Kate recommended What Happy People Know by Dan Baker. One line in it describes strategy better than most strategy books: "Freedom is choice, and choice is what makes us human. Everyone has the power to make choices, but unhappy people don't know they have it." Strategy is mainly about making choices. Which customers you will serve, which markets you will skip, which bets you will fund, and which work you will stop. Everything else is a plan to carry out the choice. Good strategy makes us more human. Most of us who lead have the authority to make those choices. We avoid them because we are scared of choosing wrong. Narrowing the audience excludes someone. Funding one bet starves another. Somebody will be disappointed, and you're the one who made that decision. So we hedge. We write strategies that say "increase revenue" or "expand margin" and call them direction. Revenue and margin are outputs. They move because of choices made upstream: the customer you decided to serve, the market you walked away from, the project you cancelled to pay for the one you funded. A strategy that only talks about outputs tells nobody what to do on Tuesday. A vague strategy is a comfortable prison. Every open question gets debated again next week. Every team member carries the fear of guessing wrong. The what-ifs and risks get rehashed at every team meeting. I have never felt freer than in the days after making a hard call. The fear of choosing wrong ends the moment you choose. This is true for life too: breaking up with a girlfriend, finding a new job, moving to the city you always wanted to move to, letting go of the toxic employee. The what-ifs lose their grip, and the week goes to executing. Time will tell you whether the choice was right. If it was wrong, you will have learned something your lack of choices never teaches. The courage the book describes is available to anyone with a decision in front of them. Count the questions your team has reopened this quarter. Each one is a choice you already have the power to make.

Software companies were valued partly on how hard their products were to copy. AI is erasing that, and I think the value of software itself is heading toward zero (in many cases). For PE, that means a five-year value creation plan can go stale in eighteen months. What I'd change across a portfolio for engineering and product practices: 1. Reward engineering for decisions and outcomes, not feature throughput. 2. Restructure teams to change direction without layers of approval. Much smaller teams. 3. Find the next defensible advantage (data, workflows, distribution, trust) and revisit it often. 4. Tie every AI initiative to EBITDA and reallocate based on what works. Full piece: medium.com/@mosquera/when-so…

My bet is that open-weight models are going to eat a growing share of the work Anthropic and OpenAI do today. For two years the industry ran on demos. Everybody was building "Jarvis" demos, but that was it, they were just demos (Also, please, for the love of god, stop doing these useless Jarvis demos) Open-weight models were good enough for plenty of that work the whole time. Nobody cared. Cost wasn't the question. Then coding agents showed up and ate up everything. Engineers live in them them all day, happily hitting the "accept" response all damn day. I'm not poking, I do the same. The token counts are absurd, and I can tell finance is having a headache trying to make this make sense. Qwen and GLM will keep getting better every few months, and even if trails behind the frontier models, and the work will get triaged. Routers will send the more predictable grunt work to the cheap model and call the frontier model for the "hard" stuff, the way you bring in a sous chef you can't afford to keep on every shift. Most work will need something reliable at a price that doesn't drive your CFO insane. Spotify and others are already doing this and as the tooling progresses, you'll see more of this because it'll become easier over time to do on your own with OSS tools. Kubernetes already showed us how this goes. Early on we cared about one thing: get it running, make it scale. Then we all got the cloud bill, and overnight everybody had opinions about resource quotas and right-sizing. Hell, many created startups on this very problem. The better agents get, the more we'll use them, and the bill will grow right along with them. The next big shift will be learning when you actually need the expensive model.

Engineering job interviews are going to dramatically change in the next 12 months. A lot less coding practices and more about architecture choices.

Breaks my heart a bit, but this post didn't age well. And aged in such unpredictable ways. My son stopped coding right after this in 2020, as his interest in soccer grew. We went back at it earlier this year in 2026, all with AI. We didn't look at the code once. Every time we encountered an error I just told him "Ask the agent". The agent fixed the problem and we moved on. We were for sure more "productive", but there was certainly less joy—but also less pain. No surprise, but his heart is still set on being better than Lamine Yamal 😜

My son stopped coding for a few years as his interest for soccer grew. We recently went back to coding a small project, and you're right, we never looked at the code once. He will never feel the joy & pain again of coding. Well... not in this way

Entry-level dev roles are reportedly down about 20% from peak because AI writes more of the code juniors used to learn on. When I hired junior engineers on whether they could code, I saved the product, market, and business questions for senior candidates. I assumed the business sense would come later, after a few years of implementing and closing tickets. That job is gone (and if not now, it soon will be). AI closes and implements many of those tickets now with very little review (or so I'm told), so juniors get far less time to pick it up. The first-year engineer you hire today needs what I used to expect at staff level. They know who the customer is and what that customer is trying to get done. They can explain how a feature makes or saves money. And they ask why a ticket exists before building it, because an agent will happily build the wrong thing based on its worldly assumptions. If you're starting out, sit in on customer calls, read the support queue, ask your PM what the company is measured on this quarter, and get an opinion, quickly! I'd keep hiring juniors, give them the career training this work now demands, and make the expectations clear. The bar is moving quickly.

There's a meme going around that a coder's keyboard from ten years ago has every key worn down, and a coder's keyboard today has two worn keys: Ctrl+C and Ctrl+V. I giggled for a bit, then looked at my own keyboard. Damn it. But if that's what your team is doing.... or if that's what you're doing as an engineer, then maybe, just maybe, you should be doing something else, those days are numbered. The bar is moving uncomfortably fast.

History is littered with fools who did the impossible.

No?

AI agents write code fast. The slow part is knowing when it's ready to ship. So I have mine follow TDD: failing tests first, then code until they pass. I check the results and only read the diff where something looks off. Good tests let me hand off whole features.

It's not a surprise that the best soccer player ever, also made the most mistakes ever. You don't get rewarded by playing it safe.

I'm a little bit sad about this post: I no longer look at code 😢 I look at verifiable outcomes (By this, I mean tests). Which is arguably better, I guess. But there was always something about looking at beauty of code design. Coding language nerds will get this.

Art doesn’t have to be on a traditional canvas or take the form of a sculpture. It can be a silly little app or something you build out of wood. Consume less. Create more. “I wanted to see if I could make it” is a perfectly good reason.

People expect business to be all data driven, but being data driven will only get you to small, incremental progress. Nothing revolutionary comes from looking into the past. Wonder and creativity is what drives innovation and progress

I'm guilty of offering the lecture instead of the hug