If you feel like you can't keep up with the new AI tools — that's not a question of your discipline. This field simply grows faster than anyone can track. The good news: to work effectively, you don't need all of it. A narrow toolkit of a few tools of your own, plus a simple way to decide what's even worth trying, is enough. I'll show you both: the set of tools I actually use day to day, and the way of thinking that protects you from the constant sense of falling behind.
Fewer tools, not more
The first surprise: even though I test a huge number of AI tools for a living, day to day I work on a very narrow set. The whole core is a handful of items, and two of them would be enough to get through a full day. The rest are specialists you reach for only on a specific task, plus "trial" tools you needn't take seriously at all.
Before you read on, two terms that will keep coming up. An agent is an AI-based program that doesn't just answer questions but carries out multi-step tasks — it reads files, uses other tools, does something for you. An automation is a setup where such an agent runs a repeatable process on its own, without you involved at every step.
It's the proportion worth remembering, not the specific names. The names will change — in six months some of these tools will be called something else or be gone. What stays is the principle: a narrow set beats a broad one. The fewer tools in daily circulation, the fewer things to learn, update and keep an eye on.
What the core actually consists of
For the record — here are the tools I recommend and that make up my daily core. Treat them as one example of how the pieces fit, not as a shopping list.
- Claude Code — a tool where an AI model works on engineering and operational tasks: it reads the files in a project, executes steps, operates within a single directory. Here it serves as the main working environment.
- VS Code — an IDE, that is, an editor for writing and organizing a project's files. It isn't an AI tool in itself; it's sometimes a convenient place to launch Claude Code from.
- Glido — speech-to-text (dictation). Fast, private; it replaced an earlier tool of this kind.
- Codex — an agent similar to Claude Code, used alongside it, because its strengths cover the other's weaknesses.
- Hermes — an agent that "wakes on demand" when you message it through a messenger. Handy for working away from the computer; simpler to get going than the full setup of other agents.
- Perplexity and Grok — for research: searching the web and finding specific threads or posts, usually for an automation.
That's the whole core. Alongside it are specialists called in for single tasks — generating images, cloning a voice, pulling data from particular services. You reach for them when they're needed and set them aside when they aren't. You don't need to know them now.
One more term, because it comes back below. An API is the way one tool connects to another — something like a socket that programs plug into. Thanks to it, an agent can, say, run a search engine or an image generator itself, instead of asking you to.
The tools are interchangeable, your way of working isn't
The most important thought in all of this: AI agents are just "shells." On the surface they differ from one another, and underneath they may use different models, but they all do the same thing — they operate within your directory, the folder holding the project's files. If you have an organized project, you can attach one agent to it today and another tomorrow, and each will know how to work in it.
Hence the practical takeaway: build an order that outlives any single tool. There's no telling which one will be best in a few months. What is clear is that if you keep your files, notes and processes in a clean, well-described folder, the next tool — whatever it turns out to be — can be plugged into it. You're investing in your way of working, not in an app's name.
From this comes an honest resilience test, too. Imagine your main tool goes down for a day — the service has an outage, access is blocked. Can you switch to another and keep working? If not, that's a signal not to rest all your work on a single provider. It's worth being able to slot at least one backup tool into your set.
The question isn't "which tool is best"
Any work you do is a process made of smaller steps. And the right question isn't "which tool is best overall," but: "which is best for this specific step, in this specific situation."
Here's an example: putting together one video. The research can be done in Perplexity. The structure of the material — in an agent that knows your context. The script itself — in a plain chat with a model. The thumbnail — in an image generator. A small graphic effect — in a different, narrower tool. The editing — in a classic video program, with no AI at all.
Two conclusions follow. First: not every step of a process has to use AI. Second: even the ones that do don't have to use the same tool. Break the task into small steps and, for each one separately, ask which tool in your set will do the job best.
A simple filter: does it solve a problem I have right now
That leaves the question that nags the most: how do you know what to learn when there are so many new releases? A simple filter helps here — a few questions worth asking yourself about each new thing.
- Does it solve a problem I have right now? Most often the answer is "no." If not — but the tool looks interesting — just save a link to it for later. That's all. You don't have to learn anything today.
- If yes — test it on a real task, not a made-up one. Not a month of playing around, just one genuine use. The important thing is that it not be risky: don't test on a mass email send or a rebuild of an important database. Pick something real, but safe.
- After a week, ask outright: did it deliver? If it genuinely solved your problem — move it into your daily set. If not — set it aside. No regrets.
And a point that takes off a lot of the pressure. There's a difference between knowing that something exists and being able to do it. Most of the time the former is enough. Watching a ten-minute video doesn't oblige you to spend the next day learning and reproducing everything it showed. You note that the tool exists, and you come back to it only when you actually run into a problem it solves.
What actually counts as productivity
To close, three notes that put the rest in order.
Every change costs you up front. With every change of tool or process, expect a temporary dip in performance — say, a fifth or so — because change always costs something. The question is: after that dip, will you end up higher than you were, or just back where you started? A change is only worth it if it genuinely lifts you above your previous level. If after the dip you barely return to what was — it wasn't worth the trouble.
Productivity is output per hour, not the number of hours worked. A twelve-hour day spent reading threads, watching videos and planning can yield less than four hours of doing things that genuinely move the matter forward. Start the day with one concrete goal and make sure each thing you do leads to it.
Define your own overarching goal. Your goal is almost certainly different from mine. I have to test every new release — that's part of my job. If your goal is to build a company that does one thing really well, then most of the hot new releases aren't your route to the goal, just a distraction. The most common mistake is to do too much at once and let yourself be pulled in every direction.
And that's the real moral. The point isn't to have every tool, but to have a narrow, proven set, a clear goal and a simple filter for the new releases. That's enough to stop drowning.