My sabbatical ends this weekend. Seven weeks of supposed freedom to ship all those side projects rattling around in my head. Instead, I spent it questioning everything I thought I knew about software.
This newsletter became my laboratory. Each article testing ideas against reality. I predicted the death of micro SaaS while building SaaS products. Preached Domain Driven Design while skipping all planning. Declared the end of coding while vibe coding dozens of experiments.
The contradictions weren't accidents. They were data points.
Building Experiments, Not Products
The MSN Messenger revival came first. Remember that old buddy list? Mine had AI assistants instead of humans. One searched the web, another generated images, a third maintained notes and contacts. Each "friend" had different superpowers.
Built it as an Electron app. Then rebuilt it in Swift. Then again in Next.js.
Not because I needed three versions. I wanted to test how fast I could jump between completely different tech stacks. With AI assistance, each rebuild took a weekend. Platform lock-in used to mean years of commitment. Now it's a weekend pivot.
The voice-controlled sitemap tool followed. Speak your website architecture into existence. "Add a products page under shop with three subcategories." Watch the visual hierarchy materialise in real-time.
Voice integration? One afternoon. Visual layout engine? Three days. That ratio tells you everything about where complexity actually lives.
Then came story writing tools. Drafting, chapter organisation, cover generation. The cover generator went through over a hundred revisions in a single Claude Desktop session before moving to React. It generates covers for Kindle, Apple Books, even blog hero images.
Users would never guess it was built without writing a single line of code manually.
The MCP Server Revelation
The real fun started with MCP servers. Tiny, atomic tools that do exactly one thing.
One counts words accurately (something LLMs still struggle with). Another handles note-taking. A third builds domain models. Each tool focused, deterministic, reliable.
I then explored how to monetise tool calls by standing up an MCP server on a simple Next.js route. Charge $0.001 per use. People will use AI chat to orchestrate these micro-tools. Need a calculation? Call a tool. Need to validate data? Call a tool. The AI understands what needs doing. The tools do it reliably.
This is the future. Not monolithic apps. Orchestrated capabilities.
Mapping Software Methodologies
I also ran an event storming session on how software teams actually work. Not the Agile manifesto fantasy. The real thing with its Zoom fatigue, design-by-committee, and ceremonial sign-offs. Mostly casting my mind back to my time in enterprise/government.
The journey from idea to deployment? Close to fifty steps. Stand-ups that exist because someone read Scrum Guide in 2008. Code reviews protecting against developers who left 5 years ago. Staging environments nobody tests. Approval chains that add weeks but zero value.
Most teams are performing elaborate theatre. Everyone knows their lines. Nobody remembers why the play exists.
So I mapped an AI-first process. No sprints, just continuous experiments. No estimates, just ship and learn. No code reviews, just runtime validation.
The entire SDLC collapsed from 47 steps to 6:
- Identify real problem (not feature request)
- Map domain with sticky notes
- AI builds working prototype (same day)
- Test if it solves the problem
- Ship to production
- Iterate or abandon
The future isn't Scrum or Kanban. It's Labs. Small teams blending product, design, and development. Moving fast. Breaking things that need breaking. Using AI as the primary tool, not an assistant.
Claude as an Operating System
The breakthrough wasn't using Claude to generate code. It was treating Claude as the entire development environment.
I created custom styles that act like team members. "Story Writer Sam" understands narrative structure and pacing for writing copy. "Infra Ivan" knows my preferred technology stack. Each style is a specialist who never forgets context, never takes vacation, never has a bad day.
Projects with persistent memory about your domain. Tools that connect to real infrastructure. The Claude Code SDK as a reasoning engine, not just a text generator.
We're using AI to write code faster when we should be using it to eliminate code entirely - it is the code.
The Platform Paradox
Building the same app in Electron, Next.js, and Swift taught me something crucial. Technology choice no longer matters. Each version took the same time to build. The cognitive overhead of switching paradigms? Gone.
Technical debt becomes less scary when you can rewrite faster than refactor. Platform decisions become reversible. Your competitive advantage isn't your codebase anymore.
It's your understanding of the problem.
Why JavaScript's Chaos Tells Us Everything
Ask Claude for a React component. Watch what happens. It reaches for shadcn/ui, Next.js, and Tailwind. Every. Single. Time.
Not because they're the best. Because they dominated the training data. The models learned this is what "modern web development" looks like. A thousand unique approaches compressed into one standard stack.
Take Tailwind. Brilliant for humans. Makes CSS readable, maintainable, shareable. But AI doesn't need bg-blue-500 when it could use background-color: rgb(59, 130, 246);. The entire abstraction exists to help human brains parse styling.
AI would be better off using CSS directly. No abstraction layer. No utility classes. No build step. Just pure CSS. But it uses Tailwind because that's what fills the training data. The system instructions in our IDEs practically mandate it. You can fight these defaults, but the results won't be as good.
You know what wouldn't have this problem? COBOL.
COBOL is boring. COBOL is predictable. If we'd all stuck with COBOL, code generation would be trivial. Business rules in, COBOL out. Same as 1975. No debates. No framework wars. Just boring, working code.
Imagine if models were trained solely on Ruby on Rails conventions or .NET's enterprise patterns instead of massive amounts of JavaScript. We'd probably have solved the coding domain by now. Instead, we're teaching AI to be yet another unique snowflake in the JavaScript ecosystem.
JavaScript's chaos reveals our real mistake. We optimised for developer creativity and popular human-readable code when we should have optimised for business outcomes.
The Boring Code Revolution
Every mature engineering team eventually builds code generators. Rails scaffolding. .NET T4 templates. They recognise that most code follows patterns.
So why are we asking AI to be creative with syntax?
I've instead started to use Claude to understand domains, map relationships, identify rules. Then I use deterministic generators for the actual code. Like Rails generating controllers from schemas. Like every enterprise's internal templates.
Creativity belongs in problem understanding, not solution implementation.
After watching businesses come and go for 20+ years in tech, the pattern is clear. Very few fail because of bad code. They fail because they built the wrong thing. Or the right thing for imaginary users.
The bottleneck was never typing speed. It was knowing what to type.
Code generation will become just another tool. AI orchestrates based on architecture needs, then calls deterministic generators to write tested, robust code. Not creative interpretations. Proven patterns.
We have everything backwards. We're teaching AI to write creative code when code should be the most boring part of the entire process.
The AGI Distraction
On top of this, everyone's waiting for AGI. The next model. The breakthrough. What if that's the trap?
Current AI can already understand language, reason about scenarios, maintain context, make decisions, orchestrate tools, analyse domains.
We have what we need. Right now.
But we're paralysed by tomorrow's promise. Every project assumes future capabilities. Every architecture hedges against obsolescence.
What if Opus 4.1 was as good as it gets?
Paradoxically, that might accelerate everything. With stable capabilities, we could build real tooling. With known limits, we could architect around them. No more waiting for the next model to fix your edge cases.
Companies won't commit because they assume everything changes next month. Developers won't learn best practices that might be obsolete next quarter. We're so busy preparing for artificial general intelligence that we're ignoring the specific intelligence already available.
Stable, boring technology wins. PostgreSQL over the latest NoSQL. Rails over this week's JavaScript framework. Maybe today's AI with known constraints beats tomorrow's promise of perfection.
Process Archaeology
We further complicate matters through outdated processes we don't want to drastically change. Companies sit on decades of accumulated process debt. Requirements documents feeding technical specs feeding test plans feeding deployment runbooks. Each artifact exists because someone, somewhere, decided it was necessary. Nobody questions why. They just perform the ritual.
AI doesn't need these artifacts. It doesn't need requirements documents to understand intent. It doesn't need technical specs to build. It doesn't need test plans to verify.
AI needs clear intent and domain understanding. Everything else is institutional scar tissue.
So if we focused on process improvement and introduced efficiencies through AI in this space, the rest will follow. But it starts with process.
Three Uncomfortable Truths
I also arrived at what I think will become apparent over the next 2-5 years.
Truth 1: Most SaaS Products Shouldn't Exist
Not software. SaaS. The moment software becomes generic enough for thousands of customers, it stops being perfect for any single one. This has always been the case but we accept 70% solutions because that's what the market offers.
But why should your business conform to Salesforce's idea of CRM? Why match Monday.com's workflow vision?
The only universal tools still needed are the fundamentals: word processing, spreadsheets, email, image editing. Everything else should be bespoke. Built for specific needs. Rebuilt when needs change.
The future isn't less software. It's more software. Millions of tiny, perfect-fit applications. Created in minutes, used until unnecessary, then discarded like spreadsheet formulas.
Twenty years from now, nobody makes money from software. It becomes a verb, not a product. Like calculating. Like writing. Like drawing.
Truth 2: The Distribution Layer Collapses
Imagine Apple or Android/Microsoft adding native app creation on devices. Built-in HIPAA compliance. Automatic SOC2. Seamless sharing.
Suddenly nobody compares Vercel to Railway. You just publish to the platform.
Company websites, marketing pages, content marketing? These are artifacts from when software was hard to build and needed marketing. When anyone can create exactly what they need, they don't require companies to sell them generic software. They may need a hand to create what they need, but service discovery will just happen through AI recommendations, not SEO based Google searches.
You won't visit websites to compare products. You'll create your own version with exactly the features you want.
The entire infrastructure of software distribution becomes obsolete when software becomes a verb.
Truth 3: Domain Understanding Is the Only Moat
When anyone can build anything in a weekend, competitive advantage comes from knowing what to build. Deep, nuanced understanding that can't be prompted into existence. The service industry is likely to take off. If you can walk into a business and understand it better than they can, nay, if u can explain their business domain better than they can, you will be sought after - to help them prompt AI to create their software.
Building for Yourself, Not the Market
Future-thinking aside, and after seven weeks of experiments, something clicked. I realised the goal post had shifted. I shouldn't spend my free time building software. I should build the capabilities I needed.
Like wanting a robot to unpack your dishwasher. You're no longer trying to start a dishwasher robot company. You just want your specific dishwasher unpacked in your specific way. And the fact that you can now build it in an afternoon changes how you frame everything. For someone with an entrepreneurial mind, this shift is hard but liberating - it pushes you to ideas beyond just software.
Lessons From Building What You Need
Forget prompt engineering tutorials. Living with AI as my capability builder taught different lessons.
Create an adversary. I built an "Idea Police" persona in Claude. Its job? Destroy every idea I had. Had to tune it to stop swearing, but AI fighting your ideas beats AI agreeing with everything.
Build your users. Story Writer Sam writes on weekends. Indie Author Maya needs quick wins. Sceptical Steve assumes AI is hype. Each persona has documented AI knowledge. Their feedback was brutal but invaluable.
Event storm everything. Start with sticky notes, crude diagrams, hand-drawn sketches. Map every event, edge case, hidden complexity. The code becomes trivial when you understand what you're automating.
Spend time on specifications. That 100-revision book cover generator? First 30 revisions failed because I gave Claude a paragraph instead of a spec. Screenshots, technical details, acceptance criteria. One hour of planning saves ten hours of revision.
Make tasks testable. "Add a button" isn't a task. "Add a primary button with WCAG compliance and loading state" is. If Claude can't verify completion, it's not complete.
Treat context like gold. Start new sessions for debugging instead of polluting your main context. Use separate contexts for exploration versus implementation. Every token matters.
Build specialists, not generalists. Don't create a "React developer" agent. Create a "Next.js App Router specialist," a "Tailwind component designer," a "Stripe webhook handler." Narrow expertise beats broad knowledge. In the system instruction for an agent include the library documentation that matters and make it almost too easy for the agent to implement their task.
These aren't tips for building products. They're patterns for creating capabilities on demand.
What Happens Monday
Monday I return to work. Sprint planning. PRDs. Architecture debates. Writing code. Leveraging AI where I can.
But also applying what I've learnt. Our software won't be easily replaced by AI - it's closer to word processing or spreadsheets, one of those fundamental tools. But I see massive opportunities to apply AI across the business and product. So while my sabbatical ends, the experiment continues.
The Final Calculation
Seven weeks ago, I started this newsletter to understand AI's impact on software. I found we've been asking the wrong question.
It's not about AI's impact on software. It's about AI eliminating the need for software as we know it.
We're not approaching a revolution. We're in it. The only question is whether you're building the future or becoming the past.
Time to ship what comes next.
Thanks for joining this journey, Matt
P.S. That cover generator sitting on my laptop? Could be making money. Could be helping writers. But shipping isn't the point anymore. I built it in an afternoon. Next time I need one, I'll build it better in an hour. The future isn't about shipping micro SaaS any more. It's about creating your own set of capabilities on demand.
Editor's note: I wrote this final piece as my sabbatical ended in early July 2025, scheduling it and the previous articles for monthly release. Hopefully it all still feels current and GPT 7 hasn't yet arrived.