Средовой подход вместо системного: как проектировать ИТ-продукты, которые растят сами себя
Привет, Хабр! В своей прошлой статье про будущее ИТ я писал о важности формулирования новых вызовов в индустрии:
Как мы перестраивали работу аналитиков под разработку с ИИ-агентами и SDD
Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.
Opus оркеструет, DeepSeek V4 пишет код: как собрать связку внутри Claude Code и сэкономить деньги
Однажды я открыл биллинг и просто посмотрел, на что уходят токены. Не на «подумать над архитектурой». А на переименование переменных, генерацию тестов по готовому ТЗ и прогон миграций. Всё это считалось по тарифу флагманской модели, хотя такую работу вытянет модель в десятки раз дешевле.Ниже – как развести действительно сложные задачи и рутину по двум моделям внутри Claude Code, не ставя ни одного стороннего форка. И три зоны, куда дешёвую модель я не пускаю принципиально. Что на самом деле сжигает токены
Как научить ИИ-ассистента писать тесты и моделировать угрозы безопасности в процессе кодинга
Главная уязвимость ИИ-кодогенерацииОсновная претензия к коду, написанному искусственным интеллектом, заключается в низком уровне его надежности и безопасности. Стремясь как можно быстрее выдать работающее решение, языковые модели часто пренебрегают тестами, игнорируют обработку крайних случаев и допускают критические уязвимости вроде SQL-инъекций или межсайтового скриптинга (XSS).
Как интегрировать нейросети в работу тестировщика
Эта статья основана на реальном опыте использования Claude в работе QA-инженера. Все оценки времени — практические, не теоретические. Работа тестировщика предполагает много разных задач: написать чек-листы, оформить баг-репорты, прочитать очередное техническое задание и составить тестовую документацию, которую, скорее всего, кроме него никто не увидит. На это уходят часы, которые могли бы идти на реальное тестирование, исследование продукта или профессиональный рост.
Почему хороший ответ ИИ иногда ведёт к плохому результату
Иногда я прошу ИИ улучшить производительность страницы и получаю на вид хороший результат: компонент становится проще, лишний код исчезает, рендеров становится меньше. Позже выясняется другое: страница тормозила из-за тяжёлого запроса, большого списка или лишней загрузки данных.Так часто бывает с производительностью. Видно медленный участок интерфейса, и рука тянется к самому заметному месту:Оптимизируй этот компонент.
Как мы за 3 дня сделали ИИ-ревьюер кода и что поняли месяц спустя
С код-ревью есть такой парадокс: все согласны, что этот процесс важен, но времени на него обычно ни у кого нет. В результате ревью часто превращается в формальность. Очевидные баги при этом ловятся, а мелкие, вроде пропуска в условиях, перепутанных знаков, забытых edge cases и т.д., могут спокойно уехать в мердж и вернуться уже в виде задач в багтрекере. В Content AI мы активно внедряем ИИ в разработку, и одна из задач, которую мы решали в этом году, — автоматизация код-ревью. В этой статье рассказываем, как одна из наших команд собрала ИИ-ревьюера, встроенного в Pull Request, и что мы поняли спустя месяц использования.
Как заставить AI-ассистента верстать премиальные интерфейсы вместо унылых серых шаблонов
Почему AI по умолчанию верстает плохоМногие фронтенд-разработчики замечают закономерность: какой бы современной ни была языковая модель, сгенерированный ею дизайн интерфейса обычно выглядит устаревшим. По умолчанию вы получаете серые кнопки, стандартный Tailwind и резкие переходы.Причина проста: нейросети обучались на гигантских массивах кода из открытых источников. В этих данных преобладают простые, утилитарные и зачастую серые интерфейсы. Модель выдает наиболее вероятный, то есть средний по качеству вариант.
Один промпт разросся в регламент: как я разделяю ответственность внутри AI-навыка
У меня был рабочий AI-навык для инженерных задач. Сначала он выглядел как обычная инструкция: роль, задача, формат ответа и несколько ограничений. Этого хватало, пока сценарии были короткими: посмотреть фрагмент кода, подсказать план, разобрать очевидную ошибку.Потом навык начал получать задачи сложнее. Например: “посмотри PR перед merge”. В такой фразе много скрытой работы. Нужно понять, что меняется, какие есть ограничения, где может быть риск, чем подтверждён вывод, какие замечания действительно блокируют принятие изменений, а какие остаются пожеланиями.
