Еще 15% респондентов заявляет о готовности сохранять текущее место работы в течение 3-5 лет при условии, что нынешние условия труда останутся прежними. Более краткосрочные планы — задержаться на 1-2 года — обозначают 16% опрошенных сотрудников.
Подробнее
Производители платформ разошлись по двум противоположным архитектурным лагерям, информационная безопасность вышла на первое место среди критериев выбора решения, а ИИ пока используется скорее фрагментарно, чем системно.
Подробнее
Одним из ключевых препятствий на пути к соответствию новым требованиям становится качество данных. Лишь у 20% опрошенных компаний массивы данных полностью готовы и размечены — то есть адаптированы для обучения алгоритмов.
Подробнее
Автоматизированные квалити гейты
Хочу поделиться практическим приемом. Он мне спас очень много нервов
Поскольку агенты могут дрифтовать и цеплять функционал очень важно обеспечить надежность всех изменений. Особенно, когда мы трогаем архитектуру, шеренные либы или готовые фичи. Перекинуть проект на другой пакетный менджер, заменить сборщик, распилить архитектуру на независимые модули, вынести фуникциональность в лейзи чанки, обновить и централизовать управление общими зависимостями (особенно в микрофронтовой архитектуре). Да даже просто вносить функциональные изменения и багфиксить -- все это требует надежности, нужно чтобы агенты не наворотили лишнего и не сломали тебе код
Я собрал пачку рецептов, которые помогают удержать управление кодовой базой
1. Строгие требования о прокрытии тестами. Если создается новый, изменяется или удаляется существующий функционал, требуем от агентов покрывать все тестами, пишем правила как писать тесты, как мокировать, описываем принципы тестирования, настраиваем агентное ревью. Код без тестов и покрытия не принимается
2. Линтеры. Обязательно настраиваем все стандартные линтеры, как на чистоту кода, так и на следование архитектуре, цикличность зависимостей, протечки абстракций и всё всё всё, что мы считаем плохим кодом и можем быстро проверить программно
3. Тулинги для анализа всего до чего дотянетесь. Анализ лайтхауса, перформанс-графов, размера бандлов, содержание зависимостей в критическом пути. Пакуем все процедурные описания в скиллы, сопровождаем их скриптами и бейслайнами. Агент должен иметь возможность самостоятельно исполнить проверки, убедиться, что результаты соответствуют ожиданиям (не просел лайтхаус, бандл критического пути не распух и так далее)
4. Прекоммит-хуки. Ваше ненавистное. На каждый коммит запускать линтеры. Да. ждать больше не вам, пусть ждет агент. Отдельно убедитесь, что ваши хуки плюются ошибками и ворнингами прямо обратно агенту. Пусть он моментально получает обратную связь и идёт исправлять. Или это потом будете делать вы)
5. Прерпуш-хуки. Тесты. Все аффектед-тесты должны запускаться ДО попадания кода в репозиторий. Да на инфре он еще раз пробежит. Но оно вам потом надо? Важно, чтобы петля обратной связи была как можно быстрее и как можно ближе к работе агента. Пусть также получит всю инфу и инструкции, отлуп и пойдет фиксить
И только потом можно сказать, что "ну ок, можно пушнуть в pull/merge request и отправить собираться на инфрастурктуре.
Бонус: red-green bugfix. Если агент правит багу, он сначала пишет красный тест и воспроизводит баг, потом фиксит. Так вы получаете гарантию, что баг реально закрыт и баг не появиться снова
А если вам все это впадлу и тяжело, чтож) квадратное катание и круглое носите, бог вам в помощь))
Злоумышленники используют в качестве приманки фишинговые письма с вложениями, стилизованными под якобы поврежденные файлы.
ПодробнееНаибольшую активность в заказе ИИ-помощников проявляют финансовые организации — на их долю приходится почти четверть всех запросов.
Подробнее
