Если вы сейчас откроете hh.ru или «Хабр Карьера» и введёте в поиск что-то типа PyCharm, PhpStorm либо IDEA, то вы обнаружите, что упоминание этих профессиональных инструментов близко к нулю. По умолчанию работодатели считают, что любой адекватный специалист знает эти инструменты и может ими пользоваться. То есть навык владения профессиональной средой разработки стал таким же базовым и очевидным навыком, как владение Microsoft Word или Microsoft Excel, ибо без умения работать с этими программами ты просто не можешь выполнять свою работу.

И как бы сейчас некоторые айтишники ни сопротивлялись и ни хотели внедрять в свою работу ИИ, хочется признаться, что это становится таким же базовым навыком, как и умение работать с базой данных, понимание форматов XML/JSON и знание языка программирования.

Я сразу же скажу, что я не считаю, что компания может уволить людей, настроить пачку агентов и вайбить по ночам продакшен-код, попивая сок у себя в офисе. Но я считаю, что практически любой программист с ИИ становится более продуктивным, чем без него.

А теперь давай посмотрим на базовые кейсы использования.

1. Написание тестов. Экономия времени: 40–50 минут.

Представьте, что у вас есть проект, в котором есть 1000+ тестов, вы добавляете какую-то функциональность и вам требуется покрыть её тестами и поправить тесты, которые эта функциональность задевает.

Даже если в проекте нет AGENTS.MD с соглашением по разработке (в том числе тестов), то вы можете сделать что-то типа: «Возьми вот эти три класса, напиши и поправь тесты по аналогии с тестами из папки /tests». И оно напишет тесты за 1–2 минуты, которые вам пришлось бы руками писать минут 40–50. Да, возможно, оно будет не идеально, но поправить это всё можно будет за пару минут.

2. Код-стайл и код-формат. Экономия времени: 15–20 минут.

Представьте, что вы сидите в потоке и написали изменения, которые занимают 40–50 файлов (это ошибка с точки зрения валидного размера PR/MR, но иногда такое всё же происходит). Вы можете обнаружить, что GitLab-пайплайны начинают ругаться на ваш код и выводить ряд рекомендаций по его устранению.

Дальше вы можете начать скармливать изменения с PR в автоформатеры, которые всё поправят, а остальное добить руками, что они не могут. Это минут 15–20. Либо вы можете перед финальным коммитом попросить это сделать ИИ, и она это поправит секунд за 15. И оно в 99,9% пройдёт без ручных правок.

3. Консультация коллег по вашему проекту. Экономия времени: 30–40 минут.

Человек открывает ваш проект в первый раз и ему нужно выполнить какую-то правку в вашем проекте для связанной задачи. Обычно происходит какой-то первичный созвон с вами, где вы ему объясняете особенности работы. После этого человек делает свою работу, заходя к вам по тем или иным вопросам. И в самом конце вы делаете ревью, указываете на замечания, и после 2–3 ревью задача проходит в прод.

Это занимает 15 — первичный созвон + 15 — ответы на вопросы + 40 минут (цикл ревью). Порядка 1 часа 10 минут вашего времени на всю задачу.

Когда разработчик использует ИИ, то некоторые вопросы по вашему проекту ему отвечает ИИ, а дальше ИИ помогает сделать задачу в соответствии с соглашениями в этом проекте. Как итог, вы получаете меньше вопросов, и на ревью выходит максимально зрелое решение, которое, возможно, даже не нужно корректировать.

4. Второе мнение перед архитектурным комитетом. Экономия времени: часы, иногда даже дни.

Вы готовите какое-то сложное техническое решение, которое пойдёт в работу при условии, что архитектурный комитет даст на него добро. Обычно вы пишете решение сами, используя песочницу, статьи, книги и какие-то советы от коллег. После этого вы предоставляете решение и оно проходит корректировку (в типичном случае) или полировку (в лучшем случае) за 1–3 созвона.

Если вы используете ИИ, то он так неплохо экономит вам время при разработке первичного решения, ибо даёт ссылки на информацию, которую вы сами бы гуглили бы гораздо дольше. А перед тем как собрать архитектурный комитет, он может провести ревью вашего решения и накидать вопросы, которые позволят либо улучшить решение, либо подготовить ответы на вопросы коллег.

Особенно для работы по техническим решениям можно использовать навыки вот этого парня: https://github.com/mattpocock/skills. Навыки: grill-with-docs и grill-with (за наводку спасибо моему коллеге Дмитрию С.)

5. Сборка конфигов. Экономия времени: 1–2 часа.

Возможно я такой особенный, но я не так часто пишу какие-то плейбуки в Ansible или настраиваю GitLab CI/CD, поэтому каждый раз когда мне нужно что-то добавить или создать с нуля я трачу пару часов на поднятие контекста. Даже если я копирую какой-то конфиг со старого проекта всё равно нужно время чтобы осознать что и как к чему тут происходит.

С помощью ИИ можно конфиг создать (перетащить) сильно быстрее, а дальше с помощью уточняющих вопросов поднять контекст за 5–10 минут вместо пары часов.

6. Написание кода на неосновных языках. Экономия времени: 20–40 минут.

Допустим вам приходит какая-то задача где вам требуется обновить какое-то API которое вызывается из старого плагина для WordPress, который под капотом использует jQuery. Возможно вы даже сами и писали этот плагин лет 5–6 тому назад когда активно занимались разработкой плагинов под разные CRM. И сейчас если писать этот код самостоятельно то вы будете прямо чувствовать как ваш мозг берёт факел и спускается в пучину вашего разума чтобы отыскать сундук со старой едва различимой надписью jQuery-эксперт.

Если вы используете ИИ то он вам поправит этот код за пару минут подсветит места где этот плагин поменялся и либо вы выполните задачу либо увидите контекст задачи и сможете проще вспомнить что надо сделать.

7. Написание Boilerplate-кода. Экономия времени: 1–2 часа.

Давайте говорить откровенно многие задачи не требуют особо мастерства чтобы его выполнить. И тут мы либо можем набирать код ручками либо позволить ИИ создать вам основу которую вы точечно подтюните под конкретные условия.

Тут оговорюсь что если задача предполагает какую-то нетривиальную логику то я предпочитаю набирать весь код самостоятельно ибо при наборе кода я попадаю в поток и пока набираю код могу продумать решение наперёд и увидеть какие-то пограничные кейсы. Если я просто валидирую весь код от ИИ то тут у меня в голове нет полного контекста и потом приходится тратить больше времени на тестах.

8. Вторичная функциональность до которой нет дела. Экономия времени: 2–3 дня и огромный респект от коллег.

Допустим у вас есть какая-то часть работы которая занимает каждый раз 5 минут. Допустим подготовить правильную конфигурацию для тестирования какой-то штуки. И чтобы сделать автоматизацию для этого требуется 2–4 дня работы которые вам никто не даёт ибо кажется ну 5 минут комон не такая уж и потеря.

В итоге либо вы тратите личное время по вечерам (многие крутые инструменты так и были сделаны) либо ждёте простой в основной работе и с разрывом контекста это всё делаете.

С помощью ИИ вы можете собрать MVP за 30–40 минут и уже при тестировании увидеть — получается эту штуку автоматизировать (и тогда ещё за 20–30 минут доделать) а то и показать СТО и принять инструмент в эксплуатацию либо понять что какая-то фигня и забить с потерей минимального времени.

__

Все кейсы которые я описал в своей статье — это вполне типичная работа программиста. Использование ИИ даёт выигрыш в экономии времени начиная от 20 минут заканчивая целыми днями на типичных задачах. Как итог программист который использует ИИ делает работу быстрее чем его коллеги которые этого не делают — ещё раз на типичных задачах!

Поэтому у меня нет сомнения что использование ИИ-инструментов станет таким же базовым навыком как и использование IDE с автодополнениями которые появились 15 лет тому назад. Вы либо адаптируетесь вместе с профессией либо оказываетесь на её обочине.

Отдельным остаётся вопрос разработки регламентов использования ИИ в рамках компании (в лице CFO, CTO и CSO) ибо сейчас это во многом дикий рынок. Но об этом поговорим в следующих статьях.

P.S. Пишите в комментариях то как вы используете ИИ в своей повседневной работе и какую экономию во времени вы получаете. Возможно есть ещё кейсы которые сделают нас эффективней.