My Thoughts on AI in 2025

Disclaimer: this post was NOT written with AI.

I often hear folks speaking about some negative aspect of AI – AI was wrong about <<thing>>, AI is coming for our jobs, or AI isn’t good at <<thing>> yet.

These points cover about 80% of the complaints that I hear about AI, anecdotally. Given my experience with AI, these sentiments don’t sit well with me; I don’t agree. I’d like to look at each of these complaints in the context of my view of AI. At a high level,

AI is a tool

It’s a tool, nothing more. You can hurt yourself and others with a hammer, or with a saw. You can also hurt yourself with AI.

Tools are imperfect, and they have specific uses. Furthermore, tools can be used improperly. Each person, when using a tool, brings their own unique life experience into the operation of the tool – they use the tool in their own way, even if they learned how to use the tool from someone else. As with any tool, having a crystal-clear idea of the problem is the first step toward a successful outcome.

Tools improve over time. Tools evolve. Using the example of the hammer, in my own lifetime I’ve seen the hammer evolve with new materials to create a lighter, more durable yet more balanced tool, or more shock-absorbent handles to protect the user’s hand. Long gone are the days of simple wood handle shoved inside a piece of molded metal. Similarly, we’ve seen a recent development in AI that’s had a big, meaningful impact on the way we use AI today: Model Context Protocol (MCP) – basically, how a Large Language Model gets new info. I’ll write more about MCP in an upcoming article, but what this signals is that the AI tools available today will eventually be replaced with ones which are more robust, featured and easy to use.

We as wielders of hammers must know how to use the hammer properly. And while we’ve been using the simplistic example of a hammer to illustrate the properties of a tool, AI is more of a car-building robot sitting atop a mammoth excavator – there will be a slight learning curve.

Thinking about AI as a tool is important because it helps to stay realistic about what it’s capable of. It’s not capable of doing everything. But if you’re not using it at all today, the likelihood is that it could be incorporated somewhere in your workflow to your benefit.

Tool Example 1: ChatGPT Kinda Sucks at Coding

A little part of me dies inside every time I hear that a newbie has picked up AI but they’re using some version of ChatGPT to do their coding. In my early days of using AI to write code, I tried repeatedly to get GPT-5 to produce good coding results. It simply doesn’t. It makes mistakes, is overconfident, and doesn’t do a good job of correcting itself or preventing future mistakes – to the extent that I usually ask it to not write code for me. Thankfully, there are other options – specifically, the Anthropic models, and OpenAI’s GPT-Codex models. Both of these models are fantastic at producing code that works well.

Understanding that ChatGPT doesn’t code well is an important step toward treating AI as a tool – while it doesn’t code well, it does diagram, summarize, and even investigate very well. Continuing the hammer metaphor, a hammer could be used to split a thin board into two relatively even pieces by smashing through it. The resulting board would be hideous, and probably unusable. A better tool for this use case would be a saw – a tool designed specifically to cut wood smoothly and precisely. Our saw in this case, if wood-cutting is writing code, is the Anthropic Claude Sonnet family of models. The Anthropic models are designed for coding, and they do a fantastic job at this task. They can refactor code, find and fix bugs, they can run and fix tests. They are a magnificent set of models with wonderful coding capabilities.

However, in my experience it can be difficult to get Claude Sonnet to not think about and write code. Sometimes I simply want to reason about something and do some planning before I formally write code. You might se where I’m going with this. The dynamic between these two platforms means that ChatGPT is a great tool for planning, and Sonnet is a good tool for coding, to be simplistic. I’ve found great success with a workflow where I plan my code and architecture changes, etc. in ChatGPT and then have Sonnet perform any code changes – using the right tool for the job.

Tool Example 2: You Might Hurt Yourself

Some AIs outright upset me. I hesitate to say anything negative about DuckDuckGo because their search offering is superb, but their Search Assist AI offering is anything but. It’s absolutely awful. I can at this point almost guarantee that it’ll give me the wrong answer to a question. It’s very fast – but highly hallucinatory. In practice, I’m willing to wait a bit longer for a correct answer.

For me, this underscores two needs: one, to ensure the right tool is being used. And two, to verify the output of AI, especially if the outcome is to be used in a meaningful way or for any important task.

One good example is writing code. We’ve talked about how the Anthropic models are great at writing code – but they still make mistakes sometimes. They can introduce bugs, build failures, test failures, or outdated syntax. It’s important in these scenarios to ensure there are appropriate tests and build automation in place to catch these issues in real-time. Thanks to MCP, some AI systems are even able to run the tests themselves, granting the ability to ask an AI system to write new code or refactor while maintaining passing tests.

AI can omit small details, too. I recently used AI to understand my legal rights in a situation involving one of the companies I’d founded, and at a critical juncture where I felt I might have been ready to take action, I decided to pause and validate my ChatGPT output using Grok. I’m glad I did – Grok found one important piece missing from the entire process, and this realization lead me to understand that what I really needed was a professional. I was still able to use ChatGPT to help guide me and prepare, but it’s clear that the system isn’t ready to completely replace a lawyer yet. This is the case for software engineering, and perhaps many other professions, too. In order to truly produce something meaningful using an AI system, the output must eventually be verified by an expert.

The way I like to think of it is, until we have a Roomba™ that can clean my entire house without getting stuck under a couch or on a carpet, we’ll continue to need human experts to vet the output of AI systems – cleaning a floor is always going to be simpler than creating performant software systems.