Примечание переводчика: на тему «ИИ в кодинге» есть много «хайповых» текстов, но мало технических. Вместо общих слов хотелось бы видеть разборы реальных ситуаций. Такой пост есть у Митчелла Хашимото (создателя терминала Ghostty), и мы решили перевести его для Хабра. Он опубликован ещё осенью, поэтому что-то могло устареть, но главные выводы остаются актуальными. Далее повествование идёт от лица Митчелла.

Недавно я выпустил улучшение для Ghostty (ненавязчивые автоматические обновления для macOS), которое разработал в основном с помощью ИИ.

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

Если подать один и тот же текст в Opus 4.7 и Opus 4.6, в новой модели он может оказаться представлен гораздо большим числом токенов. А тогда он и обходится дороже, и занимает больше места в контекстном окне. Получается «скрытая инфляция»: цены и лимиты указаны прежние, но на практике расходы могут возрасти.

Как именно всё изменилось и почему? В каких случаях число токенов вырастет максимально, а в каких останется прежним? Это хочется понимать не только из-за Opus: подобное ведь может произойти и с другой моделью. Но полных официальных ответов нет.

Поэтому мы и собрали доступную информацию, и самостоятельно проверили через API, что происходит с разными типами текстов. Мы делаем редактор кода с поддержкой разных ИИ-моделей, так что нам важно, как эта разница может сказаться на наших пользователях. Ну, и конечно, нам самим любопытно разобраться, что происходит в индустрии.

Примечание: это перевод свежего поста из блога Mozilla о том, что дало использование ИИ для поиска уязвимостей в Firefox. Ранее на схожие темы уже высказывались мейнтейнеры Linux, но пост Mozilla интересен общим оптимистичным прогнозом для индустрии.

С февраля команда Firefox непрерывно работает с передовыми ИИ-моделями, чтобы выявлять и устранять скрытые уязвимости в браузере. Ранее мы уже писали о нашем сотрудничестве с Anthropic по сканированию Firefox с помощью Opus 4.6, благодаря чему были исправлены 22 критические ошибки в Firefox 148.

Далее в рамках сотрудничества с Anthropic мы смогли применить к Firefox раннюю версию Claude Mythos Preview. И выпущенная на этой неделе версия Firefox 150 включает исправления 271 уязвимости, которые были выявлены в ходе этого тестового использования.

Сейчас такие возможности становятся доступны всё большему числу специалистов по безопасности, и многие команды сейчас испытывают то же головокружение, которое испытали мы, когда впервые обратили на это внимание. В 2025 году для закалённого временем проекта даже одна такая уязвимость стала бы поводом для «красной тревоги», а когда их обнаруживается столько сразу — задумываешься, возможно ли вообще поспевать за этим.

Одна из сложностей с LLM: как понять, какая модель способнее? Их создатели наперебой кричат «мы совершили революцию», но как пробиться сквозь хайп и измерить, кто чего реально добился?

Казалось бы, для этого есть много популярных бенчмарков. И о преимуществах моделей зачастую рассуждают со ссылками на них: «Смотрите, эта на 5% лучше». Однако с такими бенчмарками связан целый ряд проблем, и им нельзя слепо доверять.

А нам в Kodik важно разбираться, потому что мы делаем редактор кода с ИИ, так что должны понимать, какая модель в нём как себя покажет. И в результате мы не только смотрим на результаты чужих бенчмарков, но и создали для внутреннего использования свой KodikBenchmark.

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

О поиске уязвимостей с помощью LLM заговорили давно. Но когда это делают создатели самих LLM, бывает сложно разделить факты и рекламу. Вот сейчас в Anthropic заявили: «Наша новая модель Mythos так хороша в создании эксплойтов, что не станем её публично релизить, это опасно». В интернете спорят, что это значит: началась новая эпоха, где любой проект уязвим, или там просто набивают себе цену?

Однако недавно о вопросе заговорили и люди с другой стороны: мейнтейнеры важных опенсорсных проектов, включая ядро Linux. Например, Грег Кроа-Хартман заявил, что security-репорты в ядро перестали быть «ИИ-слопом» и стали полезными. А создатель cURL Дэниел Стенберг говорит о «цунами реальных репортов», на обработку которого у него уходят часы каждый день.

Мы в Kodik считаем, что это важная тема для Хабра (главное подходить к ней вдумчиво, а не хайповать попусту). Поэтому собрали и перевели несколько таких заявлений. А какие именно выводы правильнее сделать — можно обсудить в комментариях. Особенно интересно услышать ваш взгляд, если вы сами недавно имели дело с подобными репортами.

О проблемах с ИИ-кодингом на Хабре написано уже много. Но хочется перейти к конструктивному подходу: да, наломать дров с ИИ легко, а вот как работать с ним наиболее профессионально?

Известные разработчики вроде Митчелла Хашимото (создателя Terraform и Ghostty) всё чаще говорят что-то в духе «вот тут уже ни строчки кода не написал вручную». При этом Хашимото — противник слопа, и он подчёркивает, что добился от ИИ качественного кода. А что помогает добиваться?

Мы в проекте Kodik подобные вопросы ощущаем особенно остро, потому что в редакторе кода с ИИ делаем… собственно, сам этот редактор кода с ИИ. Так что для нас все проблемы особенно наглядны, а их решения — особенно важны.

Поэтому мы собрали вместе идеи и из опыта мировой IT-индустрии, и из нашего собственного. Это не какая-то «окончательная истина»: сейчас вся планета только разбирается, ни у кого ещё нет полных ответов, и полезно обмениваться опытом. Так что смело дополняйте в комментариях: интересно узнать, что помогает вам, и собрать «общехабровую кладезь знаний». Если кто-то захочет конструктивно возразить, такое обсуждение тоже полезно.