← На главную

С августа 2025 года в Ashby больше половины кода пишет ИИ — и ничего не рухнуло

04.06.2026 14:48 · hackernews

С августа 2025 года больше половины нового кода в продакшн-системах Ashby написано ИИ. Количество обращений в поддержку при этом не выросло. Больше пользователей, больше AI-кода — и ничего не рухнуло. Качество кода, скорость разработки и время онбординга инженеров не ухудшились. Наоборот, понимание кодовой базы даже улучшилось. Ashby — не игрушечный проект. Это платформа для подбора персонала: больше 100 000 активных пользователей в неделю, миллионы откликов, функциональность уровня Calendly или Looker.

Колин, глава инженерии Ashby в EMEA, формулирует тезис: стоимость производства кода стремится к нулю. ИИ не заменяет инженеров — он берёт на себя механическую работу: синтаксис, связующий код, набор символов. Самое важное — ваше суждение, вкус и понимание пользователей — становится только ценнее. Раньше ценность инженера тоже определялась его judgement, но теперь этот фактор выходит на первый план.

Два жёстких правила. Первое: эмпатию ИИ не заменит. LLM не знают ваших пользователей, у них нет вкуса и чувства прекрасного. Они пишут длинные, бездушные описания PR, которые тратят время коллег. Описание должно объяснять «зачем», а не «что». Второе: ты отвечаешь за то, что выпускаешь. LLM могут быть уверенно неправы — и звучать убедительно. Если ИИ случайно удалил пакет из package.json, виноват не ИИ, а ты. Скепсис должен расти, а не уменьшаться: требуй альтернатив, спрашивай про граничные случаи, заставляй LLM критиковать себя.

Нужно думать больше, а не меньше. Легко кинуть задачу в LLM, сгенерировать описание, тесты и отправить на ревью — но при этом решить не ту проблему. Многозадачность с агентами — то же многозадание, только на стероидах. Вы не принимаете лучших решений, когда переключаетесь между пятью агентами.

Спецификации остаются для людей. LLM может их съесть как дополнительный контекст, но писать их надо для человека. Человеку нужно знать, почему вы выбрали Redis вместо Postgres, а не перечисление всех значений enum.

Два режима работы с ИИ: sidekick и delegate. Sidekick по умолчанию — вы за рулём, ИИ помогает с информацией и реализацией. Так работают с высокорисковыми вещами: миграциями БД, безопасностью, архитектурой. Delegate — когда радиус взрыва мал: прототипы, локальные инструменты. Ключевой навык — понимать, какой режим включён сейчас.

В Ashby не замеряют использование токенов и не заставляют пользоваться ИИ. Безопасность встроена в инфраструктуру: линтеры, DangerJS, CodeRabbit на первом проходе, собственный инструмент для поиска редких багов, который использует много токенов. Есть общее хранилище Git-метаданных в SQLite — инженеры и LLM могут быстро искать прошлые баги. Обученный внутренний LLM автоматически триажит обращения в поддержку и отправляет их в нужную команду. В некоторых случаях это сократило время исправления с часов до десяти минут.

Что дальше. Объём вывода ИИ растёт быстрее, чем люди могут ревьюить. Ревью надо переосмыслить: не проверять строки, а оценивать, имеет ли смысл само изменение, разумны ли абстракции, каковы риски. LLM плодят копии вместо переиспользования — теперь толкать код в сторону простоты одна из главных задач ревьювера. Писать код стало дёшево, верификация — узкое место. Нужно больше тестов: fuzz, фронтенд-юнит, статический анализ. ИИ должен проверять ИИ на производительность, PII, обработку ошибок. Хорошая новость: писать тесты тоже становится бесплатно.

Кодовая база теперь читается не только людьми, но и LLM. ИИ воспринимает её буквально. Грязный код замедляет не только коллег — он портит каждый AI-сгенерированный кусок, который к нему прикасается. Качество кода всегда было важно. Теперь оно накапливается.

Инженеры Ashby проводят больше времени за просмотром сессий пользователей, чтением интервью и разговоров поддержки. Понимание продукта — ключевая инженерная компетенция. Скорость реализации — множитель на качество суждений. Команды, которые просто исполняют заказы, станут не нужны. А те, кто понимает, для кого и что строит, станут только сильнее.

Читать оригинал →