The post has been translated automatically. Original language: Russian
Title:AI Makes Developers Faster. But Does It Make Them More Reliable?
AI tools have already become part of developers’ daily work. Some use them to generate code, others to check errors, write documentation, find solutions, or quickly build prototypes.
At first glance, it makes perfect sense: developers spend less time on routine tasks, find possible solutions faster, and can complete work more efficiently.
But there is one question companies often underestimate: if work has become faster, has it also become more reliable?
The problem is not AI itself. The problem is that many teams started using AI tools faster than they managed to agree on clear internal rules.
What can be uploaded to an AI service, and what cannot?Is it acceptable to paste parts of client code?Who checks the result if AI suggests a solution that works but is not secure?Where is the line between helping a developer and creating a risk for the company?
The IBM Cost of a Data Breach Report 2025 notes that most organizations either do not have a full AI governance policy or are still developing one. IBM also highlights that AI-related incidents are more common in organizations without proper access controls for AI tools.
For businesses, this is an important signal. Banning AI completely is not realistic — employees will still look for convenient tools. But allowing everything to happen without clear rules is also risky.
In my opinion, companies need simple internal rules:
— what data must never be uploaded to AI tools;
— who is responsible for reviewing the code;
— which AI tools are allowed;
— how AI usage should be documented in a project;
— where manual review is mandatory.
AI can be a powerful assistant. But it should not become an invisible project participant that no one is responsible for.
The question is no longer whether companies should use AI or not. The real question is how mature the team is when using it.
How does your company handle this? Do you already have rules for using AI tools, or is everything still based on personal responsibility?
Source: IBM, Cost of a Data Breach Report 2025.
AI-инструменты уже стали частью работы разработчиков. Кто-то использует их для генерации кода, кто-то — для проверки ошибок, написания документации, поиска решений или быстрого прототипирования.
На первый взгляд, всё выглядит логично: разработчик тратит меньше времени на рутину, быстрее находит варианты решений и может закрывать задачи оперативнее.
Но есть вопрос, который компании часто недооценивают: если работа стала быстрее, стала ли она надежнее?
Проблема не в самом AI. Проблема в том, что многие команды начали использовать AI-инструменты быстрее, чем успели договориться о правилах.
Что можно загружать в AI-сервис, а что нельзя?Можно ли вставлять фрагменты клиентского кода?Кто проверяет результат, если AI предложил рабочее, но небезопасное решение?Где граница между помощью разработчику и риском для компании?
В отчете IBM Cost of a Data Breach Report 2025 отмечается, что у большинства организаций нет полноценной политики AI governance или она находится в разработке. Также IBM обращает внимание, что инциденты, связанные с AI, чаще происходят там, где нет правильного контроля доступа к AI-инструментам.
Для бизнеса это важный сигнал. Использование AI нельзя просто запретить — сотрудники всё равно будут искать удобные инструменты. Но и пускать процесс на самотек рискованно.
На мой взгляд, компаниям нужны простые внутренние правила:
— какие данные нельзя загружать в AI;
— кто отвечает за проверку кода;
— какие AI-инструменты разрешены;
— как фиксировать использование AI в проекте;
— где нужна обязательная ручная проверка.
AI может быть сильным помощником. Но он не должен становиться невидимым участником проекта, за которого никто не отвечает.
Вопрос уже не в том, использовать AI или нет. Вопрос в том, насколько зрелой стала команда, которая его использует.
А как у вас в компаниях: уже есть правила по использованию AI-инструментов или пока всё держится на личной ответственности сотрудников?
Источник: IBM, Cost of a Data Breach Report 2025.
Share
