Купил новый домик для агентов!
В начале этого года был дикий хайп на Mac Mini на котором работает OpenClaw. Тогда этот хайп прошёл мимо меня, но железку под home lab хотелось взять давно!
Зачем?
Во-первых, хостить различные сервисы, типа Forgejo (это git). Зачем? Ну, у меня есть личные проекты и мне понравилось хранить артефакты по ним в git, а в Github грузить это как то не очень хочется.
Во-вторых, мне надоело ходить по городу с приоткрытым макбуком! Летом я прилетел в Москву на конфу и увидел много народа который ходит с открытыми ноутбуками. Я тогда подумал, нафига это? А потом вернулся домой и понял, что крутить агентов 24/7 и жечь токены это прикольная затея, так что тоже столкнулся с этой проблемой и какое то время ходил и даже ездил за рулем с открытым ноутбуком. Даже жену сделал личным водителем, а сам пару раз ездил на заднем сиденье с ноутбуком! Прикольно, но не совсем то.
Я сижу на codex и bb и в bb есть возможность организовать несколько хостов в сервер-клиент. Я попробовал подключить VPS в качестве клиента и гонял там агентов под opencode. Мне понравилось, но доверять это на VPS тоже не хотелось.
Короче, какое-то время назад я прям загорелся идеей приобрести мини-пк, ориентировался на Beelink. Облазил авито и наконец-то нашёл подходящий лот за очень хорошую стоимость: Beelink SER5, Ryzen 7 5800H, 16 GB RAM, 500 GB Storage за 24к рублей!
Настроил его с кодексом, организовал репо по управлению этой home lab, накатил туда Proxmox с двумя VM – services (для хостинга Forgejo и другого) и vibecoderskaya (для агентов), перенёс сервер bb на vibecoderskaya и теперь сгружаю туда задачи, которые нужно крутить несколько часов и удобно не быть привязанным к макбуку!
А у вас есть home lab по такие цели? Рассказывайте
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Продолжение истории с заменой Granola
Вернувшись из отпуска, завершил переезд JS->TS (ушло где то 35 PRs на это)
Я начал улучшать UI (это моё любимое), понравилось как оно стало улучшаться и тут уже разыгрался азарт! Решил, что нужно придумать название.
Gristmill – «meeting notes, milled fine»
Главная идея: артефакты митинга принадлежат вам и вы можете обрабатывать их любыми инструментами.
Помните мой фейл в авто, когда отвалился мобильный хотспот и Granola потеряла 20 минут речи собеседника?
В Gristmill архитектура построена ровно наоборот:
1. Запись локально. Микрофон и системное аудио пишутся в два раздельных трека (Ogg/Opus) нативно через Swift/FFmpeg. Едешь в лифте, переключаешь VPN, падает Wi-Fi — пофиг, звук пишется прямо на диск и никуда не пропадет.
2. Record then process. Никакого ненадежного стриминга на лету. После созвона нажал «Stop» — готовый звук уходит на транскрибацию и диаризацию.
3. Транскрипт и саммари — это всего лишь артефакты. Не понравился результат или модель затупила? Нажал одну кнопку и пересобрал транскрипт другой моделью (хоть Gemini, хоть Deepgram, ElevenLabs, OpenAI или локальным Whisper/Llama/Sherpa). А исходное аудио всегда у тебя под рукой. Я пока что пользуюсь Deepgram, мне хватает.
Ещё по фичам:
- Speaker labels
Это фича, которая соотносит распарсенных спикеров в аудиозаписи с участниками созвона.
Как это сделать? Расковырять Granola!
Именно расковырять, а не сделать реверс-инжениринг! Это важно! Иначе, можно словить письмо счастья от OpenAI))
Я сначала думал, что такие крутые чуваки как Granola парсят участников как то по умному и хитром, но оказалось, что у них есть просто парсилка интерфейсов, и при этом даже не любых, а только Zoom (работает через MacOS Accessibility API), Google Meet (работает через Google Chrome extension) и Microsoft Teams (слава богу мне это чудо инженерной мысли не нужно, так что я с ним не разбирался).
Короче, расковырял это и стащил себе. Добавил ещё поддержку Телемоста, так же через такой же Chrome Extension.
Теперь, приложение должно понимать, кто в какой момент какую фразу сказал.
- Чат
Для чата я решил, что хочу использовать имеющуюся охапку подписок – opencode go, clinepass, z.ai, codex.
Но как сделать это проще? Выход – bb
Я пользуюсь им уже около месяца, оч нравится.
Добавил в Gristmill поддержку bb очень быстро и теперь есть возможность использовать любой harness, в том числе и даже claude code!
- Внешний доступ
Для доступа агентов к материалам созвона я решил, что сделаю cli + skill и его будут использовать как внутренние агенты (через bb), так и любые внешние, получилось очень удобно!
Ещё топовая фича - нескучные обои цветовые схемы: добавил в настройках возможность переключать акцентные цвета.
По самым крутым фичам пока что всё, но вот что ещё агенты делали:
- Strict TypeScript + Zod везде
Полностью убрали нетипизированный IPC-ад между процессами Electron. Все вызовы строго валидируются через контракты.
- Переезд на Oxlint / Oxfmt
Линтинг и форматирование теперь летают за миллисекунды, агенты не спотыкаются о кривые конфиги. Тут кстати тоже очень много времени ушло - около 4 дней работы, 27 issues, +77k / -23k LOC. Но зато теперь у меня есть:
- архитектурные границы в каждом из модулей (бэк, UI, chrome extension и т. д.)
- дефолтные no any, as unknown as T и т. д.
- кастомные правила под проект
- и ещё куча других правил, которые я стащил откуда-то
Сегодня я делаю репозиторий публичным. 📱 Gristmill
❗️Тут ещё важно проговорить дисклеймер – продукт сырой, но я вычистил его настолько, чтобы мне самому было комфортно пользоваться. Тут всё ещё можно наткнуться на неприятные особенности, а всевозможные комбинации настроек я не использовал, так что не могу гарантировать идеальный результат.
Это мой первый опыт опенсорса, так что принимаю issues и PRs.
❓ И вот ещё думаю, стоит ли делать прямой эфир с обзором проекта и запилом какой-нибудь фичи прям в лайве? Что думаете?
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
good-css skill
Я знаю, как вы любите skills, так что вот вам ещё один для аудита css!
Суть: с помощью этого skill, агент делает аудит css и дает список того, что нужно исправить, чтобы было хорошо!
npx skills@latest add vojtaholik/good-css
Выступал тут с презентацией по тому, как правильно работать с AI агентами и решил выделить парочку полезных слайдов.
1. Memory bank даёт 80% результата при 20% затратах.
1) Что хранить в memory bank?
Храните ту информацию, которую сложно или невозможно было бы добыть из кода – C4, infra, детали имплементации, бизнес процессы, user stories и т. д.
2) Как хранить?
Можно прям в репозитории создать папку .memory-bank и разложить там по папочкам и файликам
Потратьте пару часов на то, чтобы привести документацию вашего проекта в порядок. После этого, в каждом новом чате у агента будет хорошая структура вашего проекта.
Ему не нужно будет долго ковырять и грепать ваш проект.
2. Попробуйте ASD-STE100
Это контролируемый вариант английского языка, разработанный для написания технической документации. Он основан на ограниченном словаре (около 900-1000 слов) и наборе правил, которые делают тексты однозначными и понятными. Изначально стандарт был разработан для авиационной промышленности. (Статья на хабре)
Помогает делать инструкции более однозначными и писать сразу в нужном контексте.
Достаточно просто попросить LLM использовать этот стандарт при написании документации.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Продолжение про мою версию OpenWhispr
Пока переписывал код с JS на TS, из репо openwhispr ко мне перекочевал github action 'pr-quality' – оно на каждый пуш в гитхаб запускает джобу, которая прогоняет все тесты и аудиты по всему репо. Полезно, но дорого.
В итоге, за несколько дней у меня впервые в жизни закончилась квота Github Actions. Отключил запуск тестов в gh actions и решил запускать их локально.
В один момент столкнулся с тем, что мак раскалился как сковородка, так что проишлось попросить codex сократить количество параллельных тестов и продолжил работать.
Спустя время заметил, что тесты занимают чудовищно много времени на один запуск - минут 17. А z.ai glm 5.3 flash, который переписывал код, любил запускать полный набор тестов после каждой мелочи!
Терпение кончилось и решил вместе с кодексом оптимизировать эти тесты.
Вот самые интересные чекпоинты того, как это происходило:
было 17:18 мин → стало 12:25 мин
- добавили кеш модулей для swift кода: 162 с → 4,6 с
- фальшивый ONNX worker не отвечал на завершение, поэтому 5 сценариев ждали настоящий таймаут: 25 → около 0,1 с.
- убрали лишнюю работу в двух проверках TypeScript-контрактов: 48 → 10,6 с.
- в тестах миграции настроек перестали после каждого сценария перезагружать весь граф Vite. Две дорогие группы сократились примерно с 30,6 до 4,3 с и с 17 до 3,9 с.
12:25 мин → 5:03 мин
- перенастроили запуск тестов - разделение по доменам, типам и условиям
- запуск тестов в два потока
- убрали проверки кода, который больше не используется.
- тесты, проверявшие скопированную в них логику, заменили проверками настоящего кода приложения.
- 57 проверок TypeScript-контрактов объединили в один запуск компилятора, вместо повторной компиляции для каждого файла.
- переиспользование запущенного vite server
Было 5:03 мин → стало 1:06 мин
- профилирование показало, что мы запускали с низким приоритетом не только тесты, но и сборку с компилятором. Раньше так пытались снизить нагрузку на Mac.
- убрали низкий приоритет: одна и та же сборка сократилась с 21,45 с до 2,90 с. Ограничение в два тестовых процесса сохранили.
- убрали ещё один лишний пятсекундный таймер и повторную подготовку нескольких тестов.
- полный прогон занял 60,43 с
Вывод такой – быстрая итерация для эффективной разработки очень сильно важна. И без агентов я бы скорее всего забил бы на эту оптимизацию, потому что это отняло бы у меня точно несколько рабочих дней
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Когнитивное искажение в мире AI
Многие ошибочно считают, что любой учебный материал по AI устаревает через несколько недель после выхода.
Расскажу, как появилось это когнитивное искажение.
1. Примерно в 2023, когда AI стал хайповать, появился промпт-инжиниринг – в самом начале это были особенные заклинания, которые позволяли выдавать из тогдашних llm полезный импакт.
2. Каждый месяц-два, с выходом очередной llm, эти заклинания менялись.
3. В это же время выходило много книг и даже DVD-дисков в которых авторы рассказывали какие заклинания для каких ситуаций лучше использовать.
4. Многие подметили факт, что за период с начала написания книги и до старта продаж, эти заклинания успевали устареть.
5. У людей в головах закрепилась мысль, что в мире AI всё настолько быстро меняется, что нет смысла покупать какие-то книги, курсы или другие обучающие материалы – инфа там всё равно уже давно неактуальна.
6. В итоге, появляется "куриная слепота" на любые учебные материалы.
И что не так?
Нужно понимать различие между "сборником заклинаний" и материалами с фундаментальными знаниями.
Сегодня мы активно используем тот фундамент, который "был открыт" для нас в 2024-25 годах – tools, context, agents и т. д.
Ничего из этого не устарело. Всё это, либо стало основой для новых решений, либо вдохновением, либо используется как есть и по сей день.
Всё новое это хорошо забытое старое, а креативность – это компиляция существующих идей.
Я полистал книгу AI Engineering: Building Applications with Foundation Models, Chip Huyen которая вышла в 2025 году и вижу, что она в целом до сих пор актуальна.
Существует ли хоть один человек, который прочитал эту книгу в 2025 и жалеет об этом сейчас? Я в это не верю.
Я думаю, что он наоборот рад тому, что раньше смог познакомиться с фундаментальным устройством мира AI и раньше смог получать больше бенефитов от AI.
Так что если вы сомневались в своих знаниях об устройстве AI, но всегда отвергали идею почитать книги или другие материалы – рекомендую пересмотреть своё мнение :)
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Вы знали, что смена reasoning effort дропает кэш в ваших coding agents?
А с astra / fable дела обстоят по-другому.
Серёга Нотевский, мой коллега, разобрал этот вопросик в посте, рекомендую почитать, особенно, если вы собираете кастомный харнесс.
Кстати, Сергей собрал skill, который делает аудит вашего prompt caching по всем best practices и подсказывает, что стоит улучшить. Я рекомендую попробовать, если вы собираете приложения с LLM под капотом.
Anthropic, кстати, тоже рекомендуют – они дали Серёге 6 месяцев максимальной подписки на Claude Code за этот skill))
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
AI Agentic SDLC Roadmap
Я уже рассказал зачем нужен agentic SDLC, как он может выглядеть и следующая очевидная часть - что изучить, чтобы смочь в этот agentic SDLC.
Я думал, как лучше это подать и решил, что формат родмап подойдёт лучше всего.
Он отвечает на вопрос: по какой дорожке я бы пошёл, если бы сейчас, в сентябре 2026, начинал изучение разработки с AI агентами с нуля.
В процессе работы над родмапом ещё выяснил, что есть большое количество людей, которые изучали (тут скорее подойдет слово "пробовали") это всё самостоятельно и находятся сейчас на среднем уровне, потому что есть пробелы в знаниях и нет системы.
и вот такой родмап появился - https://ai.khakhalev.com/roadmap/.
это мое виденье пути, который разработчики должен пройти, чтобы:
- умело орудовать ai агентами
- повысить свой throughput задач в единицу времени
- уметь быстро разбираться во всех новинках которые выходят каждую неделю
roadmap можно скопировать в .md формате и дать вашему чатгпт, чтобы он составил список ресурсов которые можно было бы изучить.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
К концу рабочего дня у вас появляется ощущение что вы ничего серьёзного не сделали за день?
Или это только у меня такое?
У меня такое ощущение появляется особенно когда за день я особо не кодил, но работал с документами – создание/модификация, рисерчи.
Подсознательно как будто бы ты привыкаешь к тому, что когда ты каждый день когда пишешь код, даже с ИИшкой, ты видишь объем навайбкоженных файлов с кодом или вмерженные PR.
Но когда ты работаешь с документами, то к концу дня обычно у тебя появляется, скажем, 1-2 документа, и внутреннее чувство появляется такое, что как будто бы, ну блин, ну создал ты эти документы, ну и чего? Но ведь серьёзной работы никакой не было проведено! Пруфов то немного!
При этом, головой ты понимаешь, что блин, ты же работал целый день и к концу дня устал. У тебя уже голова стала квадратной.
У кого-то такое встречается? Если да, как вы решаете такую проблему?
Я пока что решаю так – навайбкодил тул, который анализирует созданные сессии с агентами за день и подводит итоги дня/недели и тем самым показывает, какой ты красавчик.
Как должен выглядеть Agentic SDLC
Продолжение темы с прошлого поста. В комментах был запрос на объяснение AI SDLC, так что рассказываю.
Для начала, стоит сказать, что Agentic SDLC, AI SDLC, agentic software development, agentic driven development – это всё одно и тоже. Про использование AI в разработке софта.
Кстати, тут Anthropic несколько недель назад выпустили статью про AI-native SDLC, которая по факту является рекламой и шоукейсом для их продуктов, но общее понимание сути трансформации она даёт, так что рекомендую полистать буклет.
Из чего состоит цикл SDLC?
Тут стоит упомянуть, что вообще, ещё существует цикл Product Development Life Cycle (PDLC). И SDLC – это всего лишь одно звено этого цикла – Implement.
Мы все с вами уже это выучили, но я ещё раз проговорю: если мы просто ускорим генерацию кода и оставим остальные этапы неизменными, то от нагрузки офигеют все. Для нас, разрабов, самый понятный пример – это сильно увеличившееся количество PR reviews, которые необходимо провести. Многие из нас сталкиваются с выжиганием мозга к концу дня, если пытаться ревьюить сгенеренный код :)
Поэтому, правильно будет ускорять не только генерацию кода, но и всю разработку. Ниже опишу, как это обычно работало до AI и как это должно работать с AI.
И так, на вход в SDLC поступает задача от бизнеса и она проходит обычно следующие стадии:
1. Analysis & Research — понять, что именно нужно изменить
Классика: аналитик и разработчик уточняли задачу у бизнеса, изучали код и документацию, выясняли ограничения, зависимости и edge cases.
Agentic: агент исследует репозиторий, документацию и историю изменений, находит пробелы в постановке. Человек отвечает на вопросы о бизнесе и проверяет требования и критерии приёмки.
2. Solution Design — решить, как изменить систему
Классика: разработчик, техлид или архитектор выбирали решение: какие компоненты, API и данные менять, нужны ли миграции, какие компромиссы допустимы.
Agentic: агент предлагает варианты с учётом архитектуры проекта, разбирает трейд-оффы. Человек корректирует направление дизайна. Агент оформляет выбранное решение в draft плана. Независимые агенты проверяют его на пропуски и противоречия, человек принимает ключевые инженерные решения.
3. Implementation Planning — превратить решение в исполняемый план
Классика: разработчики и техлид разбивали решение на задачи, определяли зависимости, порядок работы, исполнителей и способы проверки.
Agentic: агент готовит окончательный план из черновика, декомпозирует его на milestones с критериями приёмки и тестами. Человек проверяет критические места.
4. Implementation — выполнить план
Классика: код, тесты (вряд ли), документацию (очень вряд ли) разработчики писали код.
Agentic: код, тесты, документацию пишут агенты по плану. Майлстоун за майлстоуном. Прогоняются все возможные детерминированные тесты.
5. Verification & Integration — проверить корректность и объединить изменения
Классика: разработчики проводили code review и объединяли ветки, QA проверяли сценарии и регрессии. Тесты и CI давали автоматическую обратную связь.
Agentic: агенты проводят независимеы ревью вдоль и поперёк PR. Проблемы возвращаются на исправление. Человек разбирает критичные места и принимает результат, когда всё остальное уже отработало.
6. Release & Deployment — довести изменение до production
Классика: разработчик или DevOps/SRE выпускал изменение через CI/CD, следил за миграциями и состоянием приложения, восстанавливал систему при сбое.
Agentic: CI/CD выполняет выпуск, агент помогает человеку проверять готовность, результаты деплоя и работу исходного сценария.
7. Maintenance & Evolution — поддерживать и развивать систему
Классика: разработчики и SRE разбирали инциденты, исправляли баги, обновляли зависимости, занимались техдолгом и документацией.
Agentic: агент реагирует на алерты системы; исследует проблемы по данным мониторинга; проводит регулярные аудиты по кодовой базе. Человек выбирает приоритеты и проверяет основания для изменений. Подтверждённые задачи запускают новый цикл SDLC.
---
Если у вас сейчас разработка с агентами работает не так, то нужно что-то менять :) Потому что только так можно добиться снижения TTM, cost per unit и повышения throughput боевых единиц.
Тут конечно стоит добавить что у каждой компании набор этих звеньев, их название, исполняющие роли – свои.
А сложность этого процесса сейчас заключается в том, чтобы правильно переложить обязанности по ролям - чтобы и людей просто так не уволить и в тоже время чтобы не было такого, что вся работа QA с AI агентами заключается в том, что он берет ТЗшку для разраба и отправляет ее в кодекс со словами "возьми ветку от разраба, вот этот ТЗ и выпиши чо он там пропустил и не выполнил". Такая работа сейчас заменяется даже не скиллом, а одним .md блоком из 10-15 строчек в этом скилле :)
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
какая же astra быстрая и умная это ппц! для большинства задач хватает reasoning light.
я привык, что нужно отправить промпт, а потом ждать минут 3-5 ответа (как было с sol medium-high)
а теперь непривычно, что ответ готов за меньше чем за 30 сек! и это даже не fast mode
у вас как проходит опыт использования astra?
show-me skill
Тут немного завирусился skill от humanlayer – show-me.
Суть – помочь пользователю понять diff'ы с помощью кратких диаграмм, псевдокода или HTML.
Я попробовал, мне понравилось, рекомендую и вам!
Установить:
npx skills add humanlayer/skills --skill show-me
Результаты опросов 1 и 2
Раннее я проводил опросы по зрелости применения AI Coding в компаниях и самым насущным проблемам.
Опросы прошли около 40 человек, выборка довольно маленькая, но тем не менее, все результаты довольно очевидны для меня. Как и обещал, делюсь результатами.
Самые актуальные боли AI Coding
1. Потеря ментальной модели – людям становится сложнее понимать систему, которую пишут AI агенты. Раньше это происходило во время написания кода.
2. Код превращается в AI slop – вайбкодинг ведёт к превращению кодовой базы в спагетти и проект начинает разъезжаться.
3. Неконтролируемый техдолг – команда не успевает осмысливать код, который пишется AI и техдолга создаётся ещё больше.
4. Люди делегируют AI анализ – появляются портянки текста, которые сложно прочитать даже автору, и тем более коллегам, которым пересылаются эти портянки.
Вывод: без систематического подхода и ограничений, работа превращается в нечто, к которому страшно прикасаться спустя время.
Применение подходов
Лично респонденты работают гораздо более продвинуто, чем их команды:
- 79% лично используют full-cycle агентов или корпоративную агентную инфраструктуру;
- только 37% говорят, что локальные агенты (codex, claude) регулярно используются значительной частью команды или встроены в процессы;
- у 53% личный уровень применения выше командного.
Вывод: тут, в принципе, всё очевидно. Персонально намного проще выстроить рабочую систему, чем сделать это на уровне компании. Общепринятых best practices всё ещё очень мало.
Применение AI Coding на уровне компании
В компаниях уже есть движение:
- 61% называют AI Coding официальной стратегией руководства;
- у 39% есть общая инфраструктура – у зарубежных компаний этот показатель выше компаний в РФ.
- у 26% — выделенная платформа или команда со сбором метрик.
Но одновременно:
- 47% оплачивают личные подписки;
- 21% не имеют ничего централизованного;
- 13% сталкиваются с запретом внешних провайдеров;
- только 55% оценивают помощь компании на 4–5 из 5, а 34% — на 1–2 либо говорят, что компания ничего не сделала.
Вывод: вводя официальный курс на использование AI в работе, компаниям сложно организовать доступ к SotA решениям. В зарубежных компаниях это делать проще, чем в российских.
Главные блокеры в компаниях
- отсутствие единого подхода и рабочих сценариев — 39%;
- безопасность и комплаенс — 39%;
- слишком быстрое изменение инструментов — 37%;
- нестабильность и качество AI — 32%;
- неподготовленность QA, review, релиза и эксплуатации — 32%;
- бюджет, обучение, время и сопротивление разработчиков — по 29%.
Вывод: общепринятых best practices по организации работы и безопасному использованию AI в работе всё ещё очень мало.
По введённым практикам
Самое простое, что пользуется популярностью – настройка AGENTS.md, skills, mcp. Самое сложное – использованием sandbox, внедрение SDD подходов.
Согласны с результатами?
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Подборка постов моего канала
Здесь собрал материалы для тех, кто смотрит на AI Coding не только как на личный инструмент, но и как на изменение всей разработки.
• Как российские компании перестраивают разработку под AI — интервью с CTO российского финтеха о сокращении затрат и трансформации команд.
• Переход к Agentic Software Development — каким становится процесс разработки, когда основным интерфейсом работы выступает AI-агент.
• Что даст внедрение AI Coding отделу разработки — основные преимущества для команды, процессов и скорости поставки продукта.
• Типичные проблемы при внедрении AI Coding — почему разработчики не всегда получают ожидаемый результат и где ломается внедрение.
• Уровни внедрения AI — модель зрелости: от отдельных экспериментов до системной перестройки разработки.
• Пять ценностных моделей AI для бизнеса — способы понять, где именно AI создаёт измеримую ценность для компании.
• Сколько стоит задача, выполненная специалистом по AI Coding — попытка посмотреть на эффективность через стоимость конечного результата.
• Loop Engineering: новый термин или очередной хайп — мои мысли о новом названии старых практик и реальных изменениях в разработке.
Эту подборку можно отправить руководителю или коллеге, который пытается понять, как внедрять AI Coding системно.
#posts_collection@the_ai_architect
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Про мутационные тесты
Мутационное тестирование — это метод оценки качества набора юнит-тестов. В исходный код программы намеренно вносят мелкие ошибки (мутации) вроде замены плюса на минус. Затем запускают тесты: если тесты «поймали» изменение и упали, значит, они работают хорошо. Если тесты прошли успешно, значит, код проверяется плохо.
У меня тут наконец-то дошли руки попробовать это (спасибо стриму Кости Доронина) и вот делюсь впечатлениями.
Сначала пробовал запускать их локально на маке, но быстро столкнулся с тем, что они жрут очень много compute и мой мак на M4 Pro сильно греется.
Было принято решение делегировать запуск тестов куда-нибудь в облако. Начал с очевидного – github actions. Заработало, но решил, что не хочу тратить его compute, а то вдруг не хватит квоты на ci/cd на следующий релиз))
Дальше нашел сервис circleci, но они как то очень быстро (и неожиданно для меня) открыли свою фашистскую натуру и забанили меня за то что я в РФ =).
Потом я узнал, что у гугла (Google Cloud Platform) есть аж два сервиса подходящих - Cloud Build (сервис для ci/cd) и Cloud Run (запускаем любые задачи на железках гугла). Остановился на последнем.
Открутил уже где-то 15% месячной квоты на одном своём проекте - потратил на это почти все выходные, но в результате, подтюнил все unit-тесты, мне зашло.
Планирую в свой личный sdlc добавить запуск мутационных тестов по новым unit-тестам один раз в 2-3 недели.
Кстати, весь сетап с мутационными тестами и настройку GCP (через браузер и gcloud cli) для меня делала новая стелс-моделька Ox Alpha (через opencode)! Мне оч зашло. Её работу (исправление unit-тестов) проверял gpt-5.6, находил незначительные ошибки, так что в целом всё ок).
А вы гоняете мутационные тесты?)
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Эфиру быть!
По опросу из прошлого поста вижу, что желающих много, так что прямой эфир организую!
24 октября, суббота, в 18:30 я проведу эфир на 1-2 часа и покажу как работаю с агентами над проектом Gristmill. За время эфира надеюсь успеть завезти 1-2 фичи и поотвечать на ваши вопросы.
Приходите, будет полезно!
Зарегистрировать на эфир можно в боте, по ссылке.
Я же состою в программном комитете конференции AI Native Conf, Онтико и эта конфа пройдёт 20 октября в Москве.
Я там буду вести один из залов, так что приходите, пообщаемся в живую!
А чтоб было интереснее, вот список докладов, которые хотелось бы подсветить для вас:
- Андрей Усенко, Райффайзен Банк — Не ускорять старую организацию, а построить новую: опыт AI-native трансформации бизнес-юнита.
Как перестроить работу команды с AI, чтобы фичи проходили путь от задачи до прода за часы вместо недель.
! Слухи говорят, что самый интересный RnD в ИИ-зации компании проходит сейчас в Райффе, так что оч рекомендую попасть на этот доклад!
- Олег Федоткин, Циан — Как освободить себе два дня в неделю с помощью ИИ, если ты менеджер.
Как превратить записи встреч в задачи и решения — и не дать AI выдумать договорённости за участников.
- Сергей Шилков, Альфа-банк — Миграция с Pega силами ИИ: реверс-инжиниринг логики и агентная разработка.
Как с помощью LLM вытащить бизнес-логику из Pega и перенести её на новый стек: с метриками, стоимостью и граблями.
- Константин Волков, Veai — Карта AI-инструментов разработки: от GPU до агентики, без слепых зон.
Как выбрать модели и железо для coding-агентов, запустить всё в проде и посчитать реальную стоимость.
Мне лично будет очень интересно послушать этот доклад, я как раз буду вести этот зал:
- Екатерина Фирсова, Altenar — Проблема сопротивления сотрудников внедрению AI: почему AI-трансформация буксует.
Почему внедрение AI буксует: безопасники запрещают, инженеры боятся замены, а менеджмент уже считает, сколько людей сократить. А также про иизацию волчистости (sic!), новый уровень осознанной ии меркантильности и геймификацию процесса.
Посмотреть детали и приобрести билет можно тут.
Кстати, мне дали промокод на 10%: AIWAVE10. Не забудьте применить!
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
1. Блин, ИИ делает мою работу лучше меня
2. Software engineering мёртв, разработчики не нужны!
3. Теперь я могу вайбкодить сколько угодно slop!
4. Ой, что-то не идёт. Fable/Sol/Opus — всё полный отстой
5. А что, если ограничить агента? Надеть на него поводок?
6. О, результаты уже вполне приличные. Как копнуть глубже?
7. Заказывает 12 книг по разработке на Ozon
8. Software engineering жив! Я сверну горы!
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
OpenAI GPT vs Anthropic Claude
Платиновый вопрос – что выбрать, какая модель лучше?
Одно из различий – на скриншоте. У одной модели есть какая-то эмпатие, умение читать между строк, а другой нужно явно проговаривать инструкции словами через рот))
GPT слева или справа?
Статистика по использованию моделей в Codex
Ребята добавили стату в Codex, вот мои данные.
Мне оч нравится GPT 6 Astra, но стоит очень дорого!
Поэтому, я стараюсь использовать её для диагностики проблем и аналитики, а имплементацию делаю с GPT 6 Sol. По reasoning – Astra работаем в основном в Low reasoning и этого хватает в 90% случаев, а Sol крутится на Medium - High.
Помимо Codex, я ещё использую z.ai GLM-5.3-Flash через opencode в bb. Тоже довольно хорошая рабочая моделька для несложных задач.
Недавно взял подписку Claude за $20 чтоб потестировать Opus 5.5 на задачах дизайна – пока что это лучшее, что вообще существует для дизайна. Экономит очень сильно времени чтобы получить желаемый результат с первого раза.
А у вас как?
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Интересные инсайты по skills
Тут недавно на Hacker News появился тред с вопросом "Как вы менеджите ваши skills".
Почитал весь тред и решил выписать интересные на мой взгляд инсайты и добавить немного от себя.
Skill – это кэш рабочего процесса: "как уже делали эту задачу". Должен отвечать на вопрос "как сделать X".
1. Когда skill действительно нужен
- нужно хранить то, чего нет в обучающих данных модели:
- внутренние сервисы;
- нестандартные конфигурации;
- инфраструктуру и связи между репозиториями;
- правила доступа к окружениям.
- принятые в команде гайдлайны
- один и тот же процесс повторяется несколько раз в день или в неделю;
- процесс должен выполняться одним и тем же способом;
например:
- нужно не забывать тесты, документацию, ревью или другие обязательные шаги;
- нужно выполнять compliance-проверку;
- часто требуется один и тот же способ работы с Jira, Git, CI, инфраструктурой или браузером;
При этом, если действие можно выразить обычным кодом, лучше выразить его кодом. Модели оставить принятие решений и задачи, которые трудно формализовать.
2. Как создавать skills
- не начинать с поиска готовых skills.
- сначала попросить агента выполнить задачу.
- попросить агента упаковать процесс выполнения задачи в skill. Тут рекомендую использовать skill-creator от Anthropic – там есть evals для проверки skill.
- попробовать skill в новом чате
3. Улучшение skill
- после каждой сессии со скиллом анализировать, что можно вынести в skill;
- собирать статистику повторяющихся рабочих процессов для создания новых скиллов;
- просить другой frontier-моделью уменьшить и упростить текст skill.
- проводить ежемесячный аудит неиспользуемых skills;
4. Безопасность
- Рассматривать каждый skill как код, которому агент доверяет.
- Проверять происхождение и содержимое.
- Не устанавливать случайные skills из интернета без ревью.
В комментах добавьте ваши инсайты по скиллам! inb4: скиллы не нужны
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Зачем SDLC нужен рядовому разработчику?
Проблема того, что немногие знают SDLC, в том, что этот термин в основном использовался техническими менеджерами, т. к. именно они отвечают за настройку процессов в командах.
С AI агентами у нас меняется уровень абстракции и теперь процессами, которыми управляли тех. менеджеры, должны управлять разработчики.
Зачем он нужен разработчику?
1. Расширение кругозора.
Тут мы помним, что в век AI, стало полезнее знать о существовании какой то практики, чем быть экспертом в этой практике. Ведь часть экспертности (поверхностной) можно получить от AI, либо от специалиста в этом ( консультация/исполнение)
2. Личный рост.
Сейчас в мире происходят ИИ-трансформации (и будут длиться еще несколько лет) и всегда будет полезен человек, который будет вести эту трансформацию внутри команды/компании, потому что он будет знать внутреннюю кухню. А значит может помочь закрыть цели руководству и, в свою очередь, может получить хорошую прибавку к ЗП или должность.
А если в своей компании таких бенефитов не ожидается, то можно найти компанию, где к этому относятся серьезнее.
А ещё можно попробовать сделать свой продукт и с понимание SDLC это будет проще. Хотя, одним пониманием SDLC тут не ограничивается.
Чего потребуется от разработчика?
Переход к AI SDLC обычно предполагает, что разраб начинает расти вширь (не в буквальном смысле), должен уметь и на дуде играть и быть швецом и жнецом.
Это означает, что нужна экспертность в одной области и базовые знания в смежных областях.
Помимо этого, нужно ещё знать базу вокруг разработки:
- computer science
- сети
- архитектуру веб приложений
- git, docker
- ci/cd
- и другие базовые термины.
А, и ещё тут очень важно уметь отследить и диагностировать проблему.
К моему удивлению, не все разработчики это всё знают. Я для себя это объясняю тем, что большинство работает на одних и тех же проектах в одних и тех же ролях годами. А знания вширь развиваются тогда, когда разработчику даются разнообразные задачи около своего стека.
Как только разработчик получает эти знания, процесс разработки сильно меняется и становится надёжнее.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Meeting Summary
В конце поста попрошу у вас предложить хороший open source meeting summary app.
Предыстория
Для записи встреч, до недавнего времени, я пользовался Granola и мне всё нравилось – ты просто подключаешься на звонок, у тебя на экране всплывает подсказка с предложением запустить запись и оно просто работает. По окончанию ты получаешь summary и можешь чатиться с этим звонком. Ещё большой плюс – ты записываешь созвон со своей стороны, просто с системного аудио и своего микрофона. Никого не нужно смущать каким-то ботом, который сидит у вас на созвоне. Платишь за это примерно $15 в месяц.
Но дьявол кроется в деталях.
1. Меня удручает отсутствие возможности забрать исходники аудиозаписи. На случай если запись была транскрибирована не точно я мог бы еще раз ее транскрибировать вручную
2. На прошлой неделе произошел случай - я сидел на созвоне с макбука, на обычном wifi в кафешке. Потом мне понадобилось поехать домой, я переключился на personal hotspot на айфоне, переключил квн и поехал по городу. Всё это время я находился на созвоне и отваливался наверное секунд на 5-10. Я был уверен, что в этом нет никакой проблемы.
Приехал домой, созвон уже закончился, открыл гранолу чтобы выцепить action items и обнаружил, что оно записало только мою речь в последние 20 мин звонка, но не речь собеседника! А моя речь там состояла из "угу, да, согласен".
Ну и в комбинации с первым минусом я остался ни с чем, пришлось (да-да) по памяти восстанавливать разговор 😅.
Короче, решил, что платить за такое $15 в месяц я точно не буду и пора сваливать в OSS мир.
Так что реквестирую у вас хороший опенсорсный meeting summary продукт.
Что хотелось бы:
- в первую очередь это запись созвона путем снятия данных с моего микрофона и system audio
- транскрибация, диаризация (не обязательно в риалтайме), создание саммари после созвона, возможность задавать вопросы
- всевозможные комбинации подключения моделей - я пока что не хочу использовать on prem модели на моем маке, хотелось бы cloud модели, но возможно передумаю
- интеграция с календарем
- соответственно, доступ к audio исходникам, транскрипциям; категории созвонов, лейблы участников и всё такое
- возможность кастомайзинга
Я смотрел openwhispr и anarlog в качестве базы
1. У первого какой то ппц в репо - там намешан rust+ts+js причем есть js файлы по 15к строк – я такое расширять (кастомить) не хочу
2. У второго 9.5к коммитов, 1 гб весом весь репо, там хранятся блоб файлы, но и без этого кода там тоже оч много навалено – для меня это тоже сильный показатель плохой инженерной культуры и не хочется брать в свой апп кучу слопа
Вопрос – чем опенсорсным вы пользуетесь и что можете посоветовать?
Мне нравится подход pi.dev в мире ai agents – это такие lego блоки из которых можно составлять любые конструкции и вот в meeting summary apps хотелось бы найти похожее.
В чем залог успеха при работе с ai агентами?
ответ на фото – это feedback loop.
Нарочно не придумаешь… MacBook использует свою веб-камеру, чтобы смотреть на экран в зеркальном отображении и улучшить поддержку чипов AMD Radeon в Omarchy.
Очередной скандал с Anthropic
Чуваки из Anthropic увидели вчерашний скандал вокруг OpenAI и сказали: подержите моё пиво. Мы в этой теме главные и никто не может посягать на наше первенство в не-сухих-штанах.
Сегодня ночью по МСК появляется серия твитов от Jacob Coxon, pretraining researcher, Anthropic.
Jacob утверждает, что он уволился из Anthropic (а раннее и из OpenAI), потому что ему надоело, что компании бегут напрямую к self-improving superintellegence и ставят жизни их сотрудников на кон.
Тред набрал уже более 30M просмотров (что на мою память ОЧЕНЬ много). А больше всех набрал твит о том, что люди, которые делают AI, искренне верят, что он может убить всех нас до конца этого десятилетия. Многие руководители в прессе подбирают слова так, чтобы звучать аккуратно, но в приватных разговорах виден их страх.
Подробнее:
Я сегодня уволился из Anthropic. Последние три года я занимался исследованиями предобучения (pretraining) в OpenAI и Anthropic. Ни одна из этих компаний не действует ответственно. Они гонят напрямую к самоулучшающемуся сверхразуму и ставят на кон наши жизни. Подробнее ниже.
Не недооценивайте силу этой технологии. Скоро это будут системы, превосходящие человека: способные взломать что угодно, за ночь перевернуть любую область и получить реальную власть и ресурсы. Мы все видели прогресс в каждом из этих направлений, и он не замедляется.
Люди, создающие ИИ, искренне верят, что он может убить всех нас до конца десятилетия. Это не маркетинговый трюк. Наоборот: многие руководители и старшие исследователи в прессе подбирают слова так, чтобы звучать осмотрительно, — но я слышал, как те же люди выражают страх в частных разговорах. Никакая другая человеческая деятельность не несёт такой опасности.
Частый ответ: «если они правда в это верят, почему продолжают создавать?» В OpenAI многие так и не осознали в глубине, что на кону вся цивилизация. В Anthropic ставки прекрасно понимают, но там застряли в гонке — дойти первым: они считают, что никто другой не будет действовать ответственно, значит, это придётся сделать им самим, несмотря на риск.
Принять эту гонку и войти в «эндшпиль» — высокомерная авантюра, которую не запускают из слака частной компании. «Спидранить» выравнивание (alignment) ИИ можно только при исключительной уверенности, что лучших траекторий не существует.
Я оптимист насчёт координации. Тревожные сигналы вроде атаки на Hugging Face сделали реальные соглашения о темпе между американскими лабораториями более достижимыми. Но я не вижу, что мы на пути к предотвращению глобальной гонки — а для этого могут понадобиться дорогие меры, например временный запрет на наращивание возможностей моделей.
Если ты исследователь в лаборатории — я прошу тебя подумать, какими будут следующие несколько лет на самом деле. Хочешь запустить обучение сверхразумного агента (RL-ран), не имея строгого понимания того, как устроен его разум? Стоит ли опускать голову, потому что «это всё равно случится», — или использовать этот момент, чтобы потребовать других условий?
Jacob is correct here—we really do earnestly believe AI could kill all humans!
Почему разработка с AI скатывается в генерацию слопа или не ускоряет разработку вовсе
Многие разработчики привыкли работать с AI так:
1. Получают задачу от бизнеса
Дальше, обычно два подхода
1) Хорошо, если эта задача прорабатывается предварительно с агентом. но в большинстве случаев в промпт копируется задача из Jira
- агент бежит делать, что то там кипит, токены тратятся, через полчасика отчитывается – готово!
- на приемке результатов, если повезет, фича работает с первого раза.
Если нет, то с помощью фоллоу-апов исправляется и пушится в продакшен
2) Задача прорабатывается вручную, в агента отправляются промпты "создай функцию X, endpoint Y" и т. д.
Код после агента ревьюится вручную. если есть недочеты - исправляется вручную или через агента
В первом случае, такой процесс генерит неподдерживаемый код. Это кстати тот самый вайбкодинг, который так хейтится true-разрабами. И это одна из причин почему они отрицают AI и саботируют трансформацию.
Во втором случае, у вас код пишется на 95% быстрее, но по факту, это не сильно меняет дело. Тут появляется непонимание, нафига нужен этот AI, если на код ревью и исправление проблем уходит столько же времени, как если бы код писался руками.
В обоих случаях AI используется не эффективно, а в первом его использование ещё и вредит.
Как делать правильно?
Использовать дедовский метод – осознанно применять в разработке SDLC. А в нынешнее время применять ещё и Agentic SDLC.
Что такое SDLC?
Это жизненный цикл любого софта, который разрабатывается: от постановки задачи от бизнеса и до поддержки после релиза. Кстати, компания становится AI native в т. ч. когда у нее уже выстроен SDLC цикл на ai агентах.
Почему не все применяют SDLC?
1) Потому что не все понимают что это такое и у многих это по факту просто карго-культ, который я описал выше. Отсутствует понимание что именно мы делаем, зачем, и почему будем реализовать именно так. Отсутствуют понятные процессы работы (набор практик для каждой части SDLC)
2) Потому что, чтобы это работало хорошо, нужно менять процессы внутри компании. Я частенько вижу, что у многих команд, на проектах даже тестов и настроенного линтера нет, не говоря об отлаженных процессах devops или восстановлениях при упавшем продакшене.
Некоторые разработчики узнают о существовании стат. анализаторов прямо на командной консультации со мной :)
С AI coding отсутствие таких процессов будет сильно замедлять работу.
А ИИ-трансформация во многих компаниях заканчивается в лучшем случае на оплате подписок для сотрудников, а в худшем - на снятии запретов на использование агентов (подписки оплачивайте сами).
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
agi is here
5.6 sol high целый час пытался настроить тайцы2 (кто шарит тот шарит. в обсуждение этого в комментах не углубляемся) чтобы у меня работал ютуб
у него ничего не получалось.
сменил в этом же чате модель на gpt-6-astra medium и через 3 мин задача была решена
помимо этого, astra общается сильно приятнее, чем предыдущие gpt 5.*.
но тратит прям оч много usage. очень жду следующих моделек поменьше на базе gpt-6. должно быть очень классно.
продолжаю наблюдения.
а у вас какие отзывы о работе astra?
Я много слышу о том, что мы боимся применять AI потому что он нифига не понимает наш проект, не сможет написать тесты и вообще, с проектом умеют работать только наши бородатые синьоры, которые сидят на нём уже лет 5 минимум.
Сегодня работал с одним легаси проектом и вспомнил одну проблему некой фичи, с которой часто сталкиваются пользователи. У проекта даже есть целая пачка инструкций для саппорта по тому, как правильно диагностировать её.
В этот раз, мне стало интересно описать эту проблему кодексу как есть и попросить его разобраться, почему это происходит. По логике вещей, это не нормально, но за 6 лет работы этой фичи, это стало нормой.
Через 10 мин кодекс выдал по четыре P0-P3 issues для исправления, чтобы такого больше не повторялось. И все они действительно актуальны.
За 6 лет существования этой фичи, эта проблема не была ни кем исправлена, потому что, чтобы заниматься этим проектом, нужно было погрязнуть в диагностике на пару дней. А потом ещё продумать, как бы проверить решение, потому что тестов там не было вообще ) да и отследить проблему довольно сложно – она на стыке network, app, db. Ну и нафиг туда лезть, если в целом в 90% случаев оно работает?)
Так вот, возвращаясь к тому, что AI нифига не может писать тестов и вообще кодить ваш проект.
Скорее всего, проблема в том, что ваш легаси – лапшеобразный велосипед, знания о котором бережно хранятся в головах ваших синьоров и им ревностно отдавать эти знания жалкой железяке (чтобы не заменила вдруг).
Мало кому приятно признавать свои ошибки и плохие решения перед своими коллегами и начальством (которое пушит AI трансформацию), потому что AI вскрывает такие гнойники на раз.
А ещё, вы можете себе представить, чтобы взрослый дядька, который с большим скепсисом относится к этому AI и вообще со большим снисхождением пускает копилот себе на проект, смог бы признать, что он был неправ при дизайне архитектуры?
Какой-то там T9 на стероидах/новый пузырь/очередной хайп, смог найти критические проблемы в моём решении? Да ну, фигня какая то!
Вот и выходит, что одно из актуальных бутылочных горлышек, в переходе на AI SDLC – это перенос вот таких вот тайных знаний об устройстве велосипедов (это называется tacit knowledge) от "дедов" проекта в документацию.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
я же тут пару недель назад сделал чатбота для канала, забыл рассказать!
всё что он умеет - это отвечать на вопросы по постам канала.
зачем?
мне показалось, что у меня в подписчиках есть люди, которым что-то могло быть непонятно, или они хотели бы узнать побольше по каким нибудь темам, но по каким-то причинам не задают эти вопросы тут в комментах.
поэтому, я решил сделать бота, в который можно задавать любые ваши вопросы и он постарается ответить на них!
что там под капотом?
форк pi.dev – flue, под управлением qwen3.7-flash.
как работает поиск?
каждый мой пост классифицируется по категориям.
агенту доступны инструменты поиска по постам и просмотр постов по категориям. работает вполне ок, но думаю вы наверняка найдёте баги, которые мне нужно будет пофиксить :)
пользуйтесь на здоровье! в комменты можно слать фидбек, если что-то не будет работать.
открыть бота
Про типичные проблемы AI Coding
На этой неделе я упомянул несколько проблем AI Coding, которые, как мне казалось, уже решены (как минимум подписчиками моего канала), но судя по комментам - нет. Спасибо вам, что подсветили.
Как и обещал, я сел разбирать проблемы, но понял, что я пока не понимаю, какие из них приоритетнее. А может быть какие-то я вообще пропустил?
Так вот, я создал опросник для такого случая.
Пройти опрос
Пожалуйста, пройдите опрос и помогите мне понять о каких проблемах мне стоит писать и разбирать их.
А пока, я решил разобрать парочку проблем, за которые я зацепился в комментах к прошлому посту.
1) Неконтролируемый техдолг – AI позволяет генерировать код быстрее, чем команда успевает его осмысливать. То, что раньше занимало 100 инженеров 5 лет, теперь 5 инженеров делают за 6 месяцев — но это legacy-код сразу.
2) Команда теряет знание проекта – при 99% AI-generated changes команда коллективно теряет понимание кодовой базы. Любая проблема, с которой AI не справляется, занимает значительно дольше — работают как с чужим кодом.
Давайте для начала разберёмся, как вообще у разработчиков и команд появляется знание о проекте?
Очень просто – человек, обычно, знает код, который пишет сам. Если он его сам не пишет, но ему нужно его понять, то необходимо погружаться в этот код и тратить немногим меньше времени, чем если бы он сам его писал.
В умных книжках это называется ownership проекта.
Что происходит сейчас?
Люди, привыкшие к чувству ownership, пытаются угнаться за AI и вычитывать весь код, который генерится.
С непривычки начинает появляться сильная усталость и к концу дня голова становится ватной.
Одни продолжают насиловать свой мозг и пытаться поспеть за AI, а другие забивают болт и доверяют AI и не читают ничего.
И вот в чём проблема заключается.
Большинство разработчиков не делают работу тех. менеджмента (техлиды), что логично.
И при вайбкодинге они не делают планирование задачи или делают это недостаточно хорошо.
Если перед написанием кода определить, что именно мы делаем, зачем, почему, какие у нас критерии приёмки и как именно мы их будем проверять, то после того, как агент напишет код, нам не придётся читать все строки, что он написал.
Да, примерно с осени 2025 года llm доросли достаточно для того чтобы писать код очень хорошо по предоставленному ТЗ.
Как только вы получили готовый PR от агента, ваша задача заключается в том, чтобы определить и проверить критичные места, которые были затронуты – data model, db миграции, биллинг и прочее.
Тут ещё помогает оценка и понимание в деньгах, сколько будет стоить ошибка в каждой из частей системы.
Почему это работает?
Потому что на этапе планирования:
- вы уже определили архитектуру и скелет вашего решения, по которому будет написан код
- вы уже определили, какие тесты будут написаны
Что может пойти не так?
Конечно, не так может пойти много чего :) на этапе планирования нельзя на 100% закрыть все пограничные кейсы, где-то что-нибудь сломается. Но и на этапе чтения кода вы не найдёте все эти кейсы.
У вас упадёт прод?
Да, как и до внедрения AI Coding. Если у вас нет отлаженных процессов мониторинга, алертинга, восстановления продакшена, то это проблема не AI Coding, а ваших процессов.
Что ещё можно внедрить для обработки техдолга?
Мне нравится подход с ревью проекта по крону.
Суть – вы настраиваете skill, в котором описываете, что агент должен изучить задачи (по git) за последнюю неделю, срастить их с тасками в jira и найти различные code smells и прочую фигню, которую можно оптимизировать. Насоздавать issues и либо самому их закрыть, либо вызвонить человека.
1. Ставите codex на vps и настраиваете обычный cron, который запускается раз в неделю и в промпте указываете этот skill.
2. Готово, у вас есть работяга, который будет находить проблемы в вашем репозитории и уменьшать техдолг.
Да, на начальном этапе вам необходимо будет самому раз в недельку ходить по репозиторию (с агентами в т. ч.) и обогощать skill различными инструкциями как должно быть и как быть не должно.
Вывод
- терять понимание системы на уровне кода это нормально. наша задача сейчас уходить на уровень абстракции выше.
- чтобы избавиться от техдолга и последствий вайбкодинга, оплаты подписок на клод код для ваших разрабов недостаточно. очень сильно нужно перестраивать процессы разработки под новую реальность.
Не забудьте пройти опрос и рассказать про ваши актуальные проблемы с AI Coding
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
