Choosing AI Tools in Engineering. Insights from the Inspeerity Team

Because of that, we need to be open about how development is changing and how we use AI, where it is allowed.

This blog is part of a new series on how we use AI in Inspeerity. The results show how development is changing and what current engineering looks like.

AI is changing what developer skills mean

Development used to be about typing, fixing small issues, and slowly building a solution. There was a clear loop. You struggled, you figured it out, and that moment mattered.

AI breaks that loop.

It lets developers work quickly. Large blocks of ready-to-use, well-tested code can now be produced in weeks. A year ago, that would have sounded hard to believe.

If you don’t use these tools, you lose the game. The output is faster and, as of writing, the same as what a developer could produce alone.

Because of this, the skill is no longer just knowing a language or a framework. It is knowing how to think clearly, explain problems well, give the system the right context, and assess the result.

The work is still technical, just in a different way.

This change leads to a question: what tools are developers really using to do this work today?

Which AI tools are our developers using?

Other tools

Next to the main tools, there was also a list of less common AI tools.

Examples include:

• Agent and automation tools: Taskmaster, CodeRabbit, custom in-project agents, AI modes in Postman and Playwright
• Research and knowledge tools: NotebookLM, Brave Search, Lumo, Fireflies
• Design and creative tools: Midjourney, ElevenLabs, Figma Make, icon generators
• Platform and client tools: GitLab Duo, Amazon Q, Microsoft 365 Copilot, client-provided ChatGPT wrappers
• Local and privacy-focused setups: Ollama, LM Studio, vLLM, local GPU clusters, models like Qwen-Code, DeepSeek, Mistral
• Other tools: Windsurf, Cline, Continue, RooCode, Replit-style builders

Choosing the right AI tool is a technical decision

I see the best results when people stick to a small number of tools and learn them properly. Not just how to use them, but how they work, and where they go wrong.

Also, I don’t believe in one tool for everything. I often mix tools on purpose. I might use one environment only for version control, another for writing, and something else for AI-assisted planning. That choice depends on the job, not on what is popular that month.

The same is true for models. The “best model” changes constantly. Three weeks ago, it was one thing, a month ago, something else. It will change again. The key point is knowing which model fits a specific problem and how to give it the right context.

Tools don’t work equally across teams. What works great for frontend does not always make sense for backend or DevOps. A setup that helps one team can slow another down. Context matters more than rankings.

Choosing the right AI is the same as choosing the right database, framework, or build system. The work is still technical. The ownership is still mine.

Your AI stack defines how you work

For me, the most important takeaway here is not which tool comes out on top.
It is how developers think about their work now.

I don’t see strong engineers sticking to specific tools or models. They focus on their way of working. They spend time on clear problem descriptions, solid documentation, and careful review. They build workflows that let AI work on its own, but never blindly.

The tools will keep changing. Some of the ones listed here will disappear. Others will replace them. Some will look old much faster than we expect.

That, for me, is what developer skill looks like right now.

In the next articles, we’ll go deeper into our approach – showing where AI truly helps, where it doesn’t, and how we use it responsibly in real engineering work.