Thinking in Software
There is a lot of talk about how AI makes you faster — faster at writing emails, faster at summarizing documents, faster at producing the things you already produce. Maybe it does. But I keep coming back to a question that Cal Newport and others have pushed: in the knowledge economy, is faster actually better? A salesperson who sends ten thousand emails a day and books no meetings hasn't improved anything. Speed applied to the wrong thing is just efficient waste.
So where does the real value live? I think it lives in a shift most people haven't made yet: learning to think in software terms.
That sounds more abstract than it is. When spreadsheet software became widely available in the 1980s, the people who got the most out of it weren't the ones who were already fast at arithmetic. They were the ones who learned to think differently — who looked at a messy business problem and asked, "What if I could structure this?" They didn't just replace a calculator. They replaced whole categories of manual reasoning. The spreadsheet didn't give them speed. It gave them a new kind of agency.
That's what I think is happening now with tools like Claude Code, Codex, and the growing family of vibe coding environments. For someone who doesn't know how to program, these tools don't just make coding faster — they make coding possible. And that matters because software, at its core, is just automation with memory. Any repetitive task you do, any information you track manually, any decision you make the same way every week — that is a candidate for a small, custom piece of software.
The catch is that you have to be able to imagine the software before you can build it. You have to shift from "I wish this were easier" to "what would the app actually do?" What triggers it? What does it take in? What does it put out? That mental shift is the skill. The AI handles the code; you handle the design.
To make this concrete: say you follow a niche esports team and want a single dashboard that pulls in match results, standings, and news — tailored exactly to what you care about. Five years ago, your options were to learn to code, hire someone, or find an app that mostly did what you wanted. Now, for roughly twenty dollars a month, you can describe what you want and iterate toward something that actually works. Not perfectly, and not without some trial and error. But the ceiling on what a non-programmer can build has moved considerably.
The harder part is retraining your instincts. Most of us, when we hit friction, think in terms of tasks: "I need to do X." Thinking in software means going one level up: "What is the underlying system that would handle X for me?" Those are different questions, and asking the second one opens up different possibilities.
My challenge to myself this week — and I'd invite you to try it too — is to catch those moments of friction and reframe them. Not "I wish ordering groceries were less annoying," but "what would the software that handles this actually look like?" You don't have to build it. Just practising the question is a good start.
What recurring friction in your life, if you framed it as a software problem, might actually have a solution?
Take care,
Emanuel
P.S. This post was inspired by this Vergecast episode: https://www.youtube.com/watch?v=leuWbaMUieg— I suggest you check it out for even more concrete examples.