It is the Midsummer week here in Finland. Whereas I normally tend to publish a newsletter issue on Fridays, this time around our entire nation will be in the countryside, celebrating the sun that refuses to set even at night. So, here’s an early Plus-only issue where I share what has been on my mind recently.
In the past months, I’ve been building more tools than ever before. It has been made possible by AI, of course. I cannot be the only geek around who’s excited to get some time off from work responsibilities during the summer holidays, just so they can build personal tools for themselves. There’s a lot to reflect on in this vibe-coding phenomenon, so let’s start by looking at where it came from.
Build the tools and they will compute
The year 2025 was all about whether or not we’d see AI agents do something meaningful outside the conference keynote demos. To put things into perspective, we didn’t even have a proper definition for what an AI agent is one year ago. Eventually, the technical audience seemed to agree on this one:
An LLM agent runs tools in a loop to achieve a goal.
A few months later, the frontier models had picked up enough capability to succeed in reaching many goals in the area of software development. Combined with cheap tokens bundled in monthly Claude subscriptions, coding became the one area where AI agents were delivering tangible outputs through a repeatable, predictable pattern. The agentic loop combined with CLI tooling started shaking things up in a big way.
I think the tools part is what made all the difference here. Unlike the business information systems that we’ve been building for corporate information workers, the tools that software devs were already using made sense to LLMs as-is. Given a harness like Claude Code plus access to source code in Git repos, the language models were able to figure out what should happen next. The token prediction mechanism was now delivering not just new code but also providing commands to terminal tools. AI no longer needed the human as an intermediary to read the chat response and execute work somewhere else. The agent closed its own loop.
The same thing happened in my non-programmer workflow. The big difference came not from a smarter model but access to computing tools. I stopped trying to paste text and attachments into web-based AI chats like ChatGPT or M365 Copilot and instead began running the agents from a local folder on my PC. I established a local Obsidian vault made of Markdown files to replace all other Microsoft-based note taking and documentation tools in the cloud. Running Claude Code or Codex from that folder and letting AI see, modify and write the exact same files on my PC as I was working on led to a truly transformative leap in both productivity and capability.
Not every useful tool lives on a local Linux box, though, and the same goes for data. The cloud services still matter and access to data determines the usefulness of AI agents in most work tasks in the world. Which has then led the whole industry to double down on making MCP the lingua franca of agentic systems. As I have been working to provide my coding agents better tools for getting useful things done in my line of business, dealing with MCP servers has been a critical part of this. The more time I spend with MCPs, though, the less certain I am that we’ve got the tooling problem of AI agents figured out just yet.
MCP is the answer and the problem all in one
It is often marketed as “the USB for AI”. And sure, USB was great initially — until we got the mess that is USB-C feature bloat and incompatibilities. When it comes to MCP servers, I feel we’ve jumped right past the traditional USB and straight into the USB-C reality. When things just work, it’s beautiful. Then, there are the times when you just want to give up researching the device specs for troubleshooting connectivity issues and buy a dedicated cable instead.
Subscribe to Plus to read the rest.
Become a paying subscriber of Perspectives Plus to get access to this post and other subscriber-only content.
Upgrade

