Вот несколько интересных особенностей Antigravity

◼️ Судя по всему, новый форк VSCode был разработан под руководством Varun Mohan – он бывший фаундер Windsurf, попал в DeepMind летом 2025 после того, как развалилась сделка о покупке Виндсёрфа компанией OpenAI
◼️ Antigravity пока что бесплатный и это единственный способ попробовать Gemini 3 Pro бесплатно в IDE/CLI. Или можно попробовать в браузере, через ai.dev
◼️ Есть два режима: Planning (планирование, потом исполнение) и Fast (сразу исполнение)
◼️ Во время работы, Antigravity может создавать Artifacts
◾️ Task List - красивый список тасок в текущем диалоге
◾️ Implementation Plan - план выполнения задачи. Есть возможность дополнять его комментами, отвечать на вопросы модели, а затем обновлять план. Всё тоже самое, что я делаю вручную))
◾️ Walktrough - саммари выполненной задачи. Очень удобно резюмировать что было сделано!
◾️ Screenshots - скриншоты, которые браузер делает во время работы
◾️ Browser Recordings - в этой IDE есть browser subagent, который управляет браузером! Этот субагент может в последствии записать экран своей работы. Самый очевидный юзкейс - E2E тесты! Наконец-то!
◾️ Knowledge - аналог Memory Bank! Здесь хранятся полезные инсайты, паттерны, солюшены из кодинговой сессии
◼️ Нативная интеграция с браузером Chrome

Звучит очень офигенно! Жаль только что IDE пока что сырая, вижу это по отзывам в коммьюнити и по видосу Theo

Надо будет обязательно попробовать в работе.

Надеюсь, этот IDE не убьёт Gemini CLI, как это обычно бывает у гугла))

✔️ Timur Khakhalev про AI Coding, подписывайтесь!
⭐️ Консультации по AI Coding

Вчера Anthropic выпустили очень жирный релиз – Opus 4.5, который опять является the best model in the world for coding, agents, and computer use, и теперь стал дешевле в 3 раза! Эту новость вы наверняка слышали и в других источниках, но я хотел рассказать об интересных обновлениях Сlaude Developer Platform, которое выпустили вместе с новым Опусом.

1. Tool Search Tool – Антропики прочитали мой пост и узнали, что github mcp жрёт очень дофига токенов! Поэтому, они придумали сделать тул, который будет искать другие тулы.

Работает очень просто: вы, как разработчик MCP сервера можете пометить каждый тул флагом defer_loading: true. Такой тул не будет загружен в контекст модели с запуском системы. Когда модель, вдруг, захочет запустить такой тул, то она сначала воспользуется поиском, найдет его, загрузит его промпт в свой контекст и потом вызовет.

Плюсы - лучшая экономия токенов в контекстном окне; модель больше не тратит своё драгоценное внимание на ненужные тулы.
Минус - скорее всего, придётся чаще подсказывать модельке дергать нужные тулы и использовать свой поисковик.

Документация, пример использования

2. Programmatic Tool Calling – в начале ноября Антропики выпускали статью о том, что они придумали штуку покруче чем mcp, о чём я писал пост, который стал самым популярным у меня в канале. Эта фича даёт возможность модельке самостоятельно писать код под задачу, использовать и выкидывать его, когда он станет не нужен.
Теперь, доступно и для разработчиков Claude Dev Platform. Там же, в блоге, Антропики подсказывают, когда стоит это использовать:
- Работа с большими датасетами, где нужно извлечь часть информации
- Запуск multi-step workflows с несколькими вызовами иниструментов
- Пре-процессинг данных перед отправкой в модель
- Параллельные задачи

Когда не стоит:
- простые задачи, где достаточно одного вызова тула
- задачи, где важно показать модельке всю информацию

Документация, пример реализации

3. Tool Use Examples – few shot examples в удобной обёртке в API! Теперь при определении тулов, можно удобно показать, как стоит вызывать инструменты. Мелочь, а приятно.

Документация

✔️ Тимур Хахалев про AI Coding, подписывайтесь!

Как подчищать за агентом

Если кто не в курсе, то существует такой инструмент — knip (TypeScript). Он позволяет найти в вашем проекте неиспользуемые части кода. Работает плоховастенько (false positive) и довольно медленно, но если учитывать эти минусы, то это довольно неплохой инструмент для того, чтобы отлавливать накопившийся мусор после работы вашего агента.

Что важно помнить перед использованием этого инструмента:
- knip может возвращать false positive — т. е. некоторые части кода он может пометить как неиспользуемые, но на самом деле это не так.
- важно "сохраниться" коммитом перед началом такой операции

Как начать использовать с агентом (любым, не только Claude Code):
▪️ Иметь в package.json команду knip, а так же команду type-check для проверки, что типы TS сходятся
▪️ Рассказать агенту, что у нас есть команды knip и type-check и мы хотим удалить ненужный код. Агенты уже знают что такое knip, и что он часто false positive
▪️ В конце работы агента, проверить что всё ок

Мой опыт
Я сейчас провел чистку интерфейсов в одном проекте и сэкономил около 400 loc ))

Я знаю что у меня есть штук 5 файлов с интерфейсами (zod schemas, TS types), где очень много неиспользуемых типов и схем.

Сначала, я попросил Claude Code просто запустить эту команду pnpm knip | grep "$mask" и удалить неиспользуемые типы.
Спустя некоторое время я заметил, что ему очень тяжело — после удаления кусков кода команда type-check возвращает ошибки и агент ходит кругами.

Ок, значит, надо декомпозировать задачу

▪️ Попросил агента (Claude Code) запустить команду knip ещё раз, оценить результат и изменения в каждом файле делегировать одному субагенту
▪️ Запустить таким образом в параллель 3 субагента
▪️ Сделал то же самое ещё 3 раза и обработал все нужные файлы. - type-check сошёлся. Успех!

А какие похожие инструменты используете вы?

#ai_coding@the_ai_architect

✔️ Тимур Хахалев про AI Coding, подписывайтесь!

Письмо авторам телеграм-каналов

- Может быть покапитанствую местами - но куда ж без этого)

- Там на самом деле нет откровений, всё уже сообществом придумано и опробовано )

- Чет вообще ничего писать не хочется

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

Ребята, не надо так!!!

Я прошу вас, пишите самые очевидные для вас вещи, которые вы знаете! Будьте капитанами очевидности!

Да, кому то это будет очевидно и некоторые могут покрутить пальцем у виска, но чаще всего таких меньшинство! Особо одаренные могут ещё написать "и ради этого стоило выступать на конференции?".

Прошло время токсичности выскочек, которые кричат "это баян", "это и так очевидно всем" давайте таких молча банить. Stackoverflow умирает, потому что людям с глупыми вопросами больше не нужно хавать токсичность, им проще задать вопрос chatgpt и получить в ответ "какой классный вопрос! вы зрите в самый корень проблемы!"

Но при этом я точно знаю, что есть абсолютное большинство вашей аудитории, которым эта информации будет полезна!

Ваша аудитория сможет взглянуть на известные им вещи под другим углом – с вашей оптикой личного опыта, что в свою очередь может помочь человеку решить какую-нибудь задачу. А это очень ценно.

Кто знает, может именно ваш пост "как устроен RAG" познакомит человека (эксперт в X, не айтишник) с RAG, а тот в свою очередь сделает Cursor для X! Это же круто!

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

Ребята, отложите перфекционизм!

Давайте писать просто ваши мысли о чём нибудь!

Наша индустрия только-только развивается, нам нужно ещё успеть попробовать применить всё, что было в других индустриях. Поэтому, надо чаще пробовать и делиться мыслями друг с другом.

Здесь как раз в тему будет пост Глеба из 5 слов о том что ОПУС КРУТА – собрал почти 50 комментов и реакций.

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

Не бойтесь показаться несерьёзными и написать посты не соответствующие своему формату!

Здесь как раз очень в тему пост Николая Мячина (автор ютуб канала Простая Экономика) о том, что нужно экспериментировать и постоянно публиковать контент. И ещё один про "проклятие знаний"

Если вы не знаете о чём написать – напишите об этом пост!

Серьезно!

Спросите у вашей аудитории, что им было бы интересно.
Спросите, как у них идут дела с Cursor.
Спросите об их опыте в чем нибудь, в чем вы очень разбираетесь.

Так вы либо откроете для себя что-нибудь новое, либо получите идеи для новых постов.

---

Скиньте этот пост вашему любимому автору тг канала, от которого вы уже давно ждёте постов!

✔️ Тимур Хахалев про AI Coding, подписывайтесь!

Plan & Act на Практике

Ссылка:
https://youtu.be/Xf0xFpvaIcY

Я использую Codex CLI для планирования и Claude Code для имплементации кода.

Чтобы показать, как это работает на практике, решил записать видео. Пишите в комментах на ютубе, как вам? Насколько понятно?

Да, при записи видео возникли некоторые проблемы 🌚, но думаю так даже интереснее. В будущем планирую записать ещё видео со своим подходом.

#ai_codi@the_ai_architect

✔️ Timur Khakhalev про AI Coding, подписывайтесь!
⭐️ Консультации по AI Coding

> no, web-app/.env already will have these variables. Do not specify them again

● You're absolutely right! The env_file: - apps/web-app/.env already handles it. Let me remove the redundant environment section:

В docker compose + Dockerfile есть штук 5 способов передать env variables для приложения.

Мне удобен подход, когда мы храним весь файл .env в одной переменной в github/gitlab - т. е. просто создаем новую переменную WEB_APP_ENV_FILE и кладем туда контент .env.

Далее, во время ci/cd, берем значения оттуда, создаем файл .env рядом с сорсами приложения и билдим.

В compose.yaml я указываю путь к этому файлу через

web-app:
    build:
        context: .
        dockerfile: ./apps/web-app/Dockerfile
    env_file:
        apps/web-app/.env

Таким образом, env variables из .env сразу доступны внутри Dockerfile и не нужно никаких лишних телодвижений

Проблема в том, что нейронки кто-то научил делать по-другому - указывать ARGS внутри Dockerfile и перечислять там КАЖДУЮ переменную из .env файла, что ведет к тому, что у нас теперь более одного source of truth в проекте и управлять переменными теперь надо не только из .env файлика, но и из Dockerfile.

И вот каждый раз приходится по 3-4 раза объяснять как нужно сделать, но они всё равно пытаются сделать по-своему. Что sonnet, что codex. Это какой то ужас!
Они игнорируют compose.yaml файл, который если почитать, то станет очевидно, как мы работаем с переменными в проекте, но им пофиг.

Вот тут теперь становится понятна логика свидетелей T9 - видимо они пишут на непопулярных языках, примеров которых было мало в интернете, по сравнению с TS/Python))

✔️ Timur Khakhalev про AI Coding, подписывайтесь!

Ещё раз про Context Engineering и Feedback Loop

Возможно, вы знаете, что при работе с моделями типа Sonnet, я советую держать контекстное окно в пределах 100к токенов, а ещё лучше до 80к, потому что дальше – больно. Качество ухудшается, лимиты в Claude Code тратятся заметно быстрее.

Я тут на просторах интернета наткнулся на такое же мнение и обрадовался, что я не один это заметил.

Тут автор пишет про тесты и советует убирать "TESTS PASSED" строки из вывода инструментов, которые запускают тесты.
Обычно, когда мы запускаем npm run test команды, то видим несколько экранов строк, которые говорят о том, что тесты успешно пройдены. Модели же знать об этом незачем, так что можно сократить эти строки до простого "✓ Utils tests". Если же тесты зафейлятся, то появится сообщение об ошибке.

Таким образом, мы сэкономим большое количество токенов.

Можно использовать такую обёртку:

run_silent() {
    local description="$1"
    local command="$2"
    local tmp_file=$(mktemp)

    if eval "$command" > "$tmp_file" 2>&1; then
        printf "  ✓ %s\n" "$description"
        rm -f "$tmp_file"
        return 0
    else
        local exit_code=$?
        printf "  ✗ %s\n" "$description"
        cat "$tmp_file"
        rm -f "$tmp_file"
        return $exit_code
    fi
}

run_silent "Simple tests" "pnpm test:run"

Сделайте

chmod +x ./run-silent.sh

Результат:

./run-silent.sh
  ✓ Simple tests

Ещё автор советует врубить fail-fast, т. е. если у вас 10 ошибок в тестах, то тесты будут показывать по 1-й ошибке за раз, до тех пор, пока не пофиксятся все 10.
Если ошибки не тривиальные (не фиксятся one-shot исправлением по нескольким файлам), то это поможет модельке хорошо подумать над каждой ошибкой по-очереди и не распыляться разом на все ошибки, что может вести к более худшему качеству исправления этих ошибок

#ai_coding@the_ai_architect

✔️ Timur Khakhalev про AI Coding, подписывайтесь!
⭐️ Консультации по AI Coding

Codex CLI Skills и Subagent

Ну, почти

Неделю назад в сети было замечено, что в codex cli добавили Skills прямо как в Claude Code. Доступно пока что только в alpha версиях и с парочкой приседаний, но оно работает!

Сегодня мне пришла в голову идея из подручных средств собрать субагента для codex cli))

Суть заключается в том, что мы инструктируем codex cli как запускать самого себя же в режиме headless.

По этому поводу записал демо видео и подготовил репо с инструкциями:
📱 Github
📱 YouTube


✔️ Timur Khakhalev про AI Coding, подписывайтесь!
⭐️ Консультации по AI Coding

Результаты опроса практиков AI Coding

На прошлой неделе мы создали опросник по AI Coding, собрали около 80 осознанных ответов и делимся с вами ключевыми инсайтами.

Я покажу интересные цифры, которыми поделились участники опроса.

Как изменилась эффективность при использовании AI Coding

1. Full-stack разработчик

Задача: Написание 630 тестов.
Результат: Сделано за 6 часов (4 часа кодинга + 2 часа планирования).
Сравнение: Оценка ручной работы составляла 110 часов.
Выигрыш: ~18 раз.

2. Engineering Manager / CTO

Задача: Апгрейд фреймворка (Ruby on Rails 5 -> 8), затронуто 500 файлов.
Результат: Сделано за 2-3 вечера.
Сравнение: Экономия 2-4 недели работы.

3. Founder

Цитата: "Сейчас за 30-40 минут могу сделать то, что 2-3 года назад заняло бы неделю".
Выигрыш: ~40-80 раз (субъективная оценка).

4. Backend разработчик
Задача: Реализация сложного E2E сценария с шедулером.
Результат: Выполнено за 1 день.
Сравнение: "Задача, на которую я бы потратил неделю".
Выигрыш: ~5 раз.

5. Founder:

Задача: Миграция 40 SQL-запросов на ORM в Node.js сервисе.
Результат: Один рабочий день.
Сравнение: Вместо недели ручной миграции.

6. Разработчик:

Задача: Разработка админки.
Результат: В 5-10 раз быстрее, чем год назад аналогичная задача вручную.

Если вам интересно узнать, как именно эти люди добились такого результата, то успейте принять участие в опросе до 21 декабря, а после мы вам отправим анонимизированные ответы всех участников

Но не все отзывы положительны

Есть несколько упоминаний о том, что AI крадёт время:

1. Backend:

Попытки использовать "супер-крутой промптинг" занимают кратно больше времени, а результат улучшают максимум на 10%.

2. Team Lead:

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

3. Team Lead:

Где-то AI "убирает час-два времени", но кодинг на огромной базе провалился ("играли в context engineering... проиграли").

Какой можно сделать вывод?

Те, кто научился делегировать рутину (тесты, миграции, бойлерплейт) и ускорять планирование, сообщают об ускорении в 5-20 раз. Те, кто пытается заставить AI писать идеальный код "одной кнопкой" или использует его для сложных неопределенных задач без декомпозиции, часто тратят больше времени на исправление ошибок.

Здесь можно посмотреть мнения моих коллег:
Макс Романовский
Коля Шейко

✔️ Тимур Хахалев про AI Coding, подписывайтесь!

Настало время подведения итогов года!

2025-й выдался очень насыщенным на обновления в AI и в особенности в AI Coding!

Мы с ребятами собрались и решили провести голосования по разным темам.

Я выбрал тему Событие 2025 года в AI Coding

И вот кандидаты

◾️ Появление Vibe Coding
Можем ли мы представить себе работу без вайб-кодинга после того самого судьбоносного твита в феврале 2025? Я - нет

◾️ Релизы Claude моделей - Sonnet, Opus, Haiku
А можем ли мы представить себе вайб-кодинг без моделей Anthropic? Я - тоже нет. Кстати, за этот год сменилось 4!! поколения модели Claude - 3.7, 4, 4.1, 4.5! (Ещё есть слухи что до конца года выйдет Sonnet 4.7)

◾️ Релиз Claude Code
Вместе релизом Claude Sonnet 3.7, мы увидели новый инструмент, который в последствии *перевернул индустрию* программирования — Claude Code.

И по сей день этот инструмент остается для меня топ-1 при выборе.

◾️ Релизы Gemini 2.5-3 Pro моделей

Релиз модели Gemini 2.5 Pro в начале года тоже существенно повлиял на рынок, я почти весь год пользовался этой моделью до появления следующего поколения – Gemini 3 Pro.

◾️ Смена прайсинга Cursor
В конце весны Cursor поменяли прайсинг - они больше не дают 500 запросов за $20. Помимо этого, они были замечены в непонятных махинациях с контекстным окном, что вело к отуплению моделей. Это вызвало негативную реакцию как у аудитории, так и у меня лично. С тех пор я не пользуюсь курсором.

◾️ Релиз GPT-5.* моделей
В начале года Сэм Альтман пообещал нам, что он избавит нас от запутанных названий модели OpenAI.

К концу года мы имеем 20 версий GPT-5 в Cursor.

Тем не менее, модели семейства GPT-5 получились очень хорошими, 5.2 моё почтение!

◾️ Релиз codex-cli
В августе OpenAI выпустили конкурента Claude Code. У него нет столько фич, как у CC, но codex сделан очень добротно и занял свою нишу в AI Coding

◾️ Релиз Antigravity
С релизом Gemini 3 Pro мы увидели новый инструмент кодинга от Google. Он пока что ещё сырой, но имеет очень крутые фичи и хороший доступ и к G3 Pro и к Claude Sonnet/Opus 4.5! Пользуйтесь, пока не прикрыли.

◾️ Релиз z.ai моделей
Летом и осенью китайцы z.ai выпустили не побоюсь этого слова революционные модели - GLM-4.5 и GLM-4.6 и наконец сравнялись с SotA моделями прошлых поколений - Sonnet 3.7, 4!

◾️ Появление Spec Driven Development / Document Driven Development подходов
В 2025 получил свою популярность SDD/DDD подход к AI Coding – это когда мы кладём в документацию к коду информацию, которая не очевидна из кода, что в итоге повышает качество написанного кода с помощью AI

◾️ Миграция пользователей Codex -> Claude Code -> Cursor -> Antigravity и обратно
Летом-осенью мы с вами были свидетелями перебежек пользователей с одного инструмента на другой, как только вендоры выпускали новую модель или лоботимизировали старую

Голосуйте или умом, сердцем или чем угодно! (голосовалка ниже)

Делитесь своими мыслями в комментах!

Через недельку мы подведём итоги голосования.

А вот голосования от других авторов:
Если одна подписка, то какая? - 🔗Поляков считает: AI, код и кейсы
Код вместе с ИИ в 2025. Чем пользоваться? - 🔗Глеб Кудрявцев про AI кодинг
AI-headliner – 🔗Константин Доронин
ИИ-компаньон года – 🔗Бунак и Цифра: chatGPT / AI в бизнесе

#ai_coding@the_ai_architect
✔️ Тимур Хахалев про AI Coding, подписывайтесь!