Тимур Хахалев про AI Coding
رفتن به کانال در Telegram
Авторский канал. Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding О канале https://t.me/the_ai_architect/2 Связь через ЛС канала | Визитка: timurkhakhalev.t.me
نمایش بیشتر9 216
مشترکین
-424 ساعت
+377 روز
+20730 روز
در حال بارگیری داده...
کانالهای مشابه
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+204
در 4 کانالها
اوت '26
+202
در 7 کانالها
Get PRO
ژوئیه '26
+387
در 16 کانالها
Get PRO
ژوئن '26
+274
در 7 کانالها
Get PRO
مه '26
+507
در 7 کانالها
Get PRO
آوریل '26
+597
در 8 کانالها
Get PRO
مارس '26
+405
در 3 کانالها
Get PRO
فوریه '26
+7 296
در 11 کانالها
Get PRO
ژانویه '26
+6 055
در 12 کانالها
Get PRO
دسامبر '250
در 10 کانالها
Get PRO
نوامبر '250
در 5 کانالها
Get PRO
اکتبر '250
در 1 کانالها
Get PRO
سپتامبر '250
در 1 کانالها
Get PRO
اوت '250
در 10 کانالها
Get PRO
ژوئیه '250
در 7 کانالها
Get PRO
ژوئن '250
در 13 کانالها
Get PRO
مه '250
در 3 کانالها
Get PRO
آوریل '25
+327
در 2 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 19 سپتامبر | +6 | |||
| 18 سپتامبر | +2 | |||
| 17 سپتامبر | +4 | |||
| 16 سپتامبر | +7 | |||
| 15 سپتامبر | +7 | |||
| 14 سپتامبر | +17 | |||
| 13 سپتامبر | +6 | |||
| 12 سپتامبر | +7 | |||
| 11 سپتامبر | +16 | |||
| 10 سپتامبر | +13 | |||
| 09 سپتامبر | +25 | |||
| 08 سپتامبر | +12 | |||
| 07 سپتامبر | +5 | |||
| 06 سپتامبر | +14 | |||
| 05 سپتامبر | +5 | |||
| 04 سپتامبر | +7 | |||
| 03 سپتامبر | +6 | |||
| 02 سپتامبر | +14 | |||
| 01 سپتامبر | +31 |
پستهای کانال
AI Agentic SDLC Roadmap
Я уже рассказал зачем нужен agentic SDLC, как он может выглядеть и следующая очевидная часть - что изучить, чтобы смочь в этот agentic SDLC.
Я думал, как лучше это подать и решил, что формат родмап подойдёт лучше всего.
Он отвечает на вопрос: по какой дорожке я бы пошёл, если бы сейчас, в сентябре 2026, начинал изучение разработки с AI агентами с нуля.
В процессе работы над родмапом ещё выяснил, что есть большое количество людей, которые изучали (тут скорее подойдет слово "пробовали") это всё самостоятельно и находятся сейчас на среднем уровне, потому что есть пробелы в знаниях и нет системы.
и вот такой родмап появился - https://ai.khakhalev.com/roadmap/.
это мое виденье пути, который разработчики должен пройти, чтобы:
- умело орудовать ai агентами
- повысить свой throughput задач в единицу времени
- уметь быстро разбираться во всех новинках которые выходят каждую неделю
roadmap можно скопировать в .md формате и дать вашему чатгпт, чтобы он составил список ресурсов которые можно было бы изучить.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
| 2 | بدون متن... | 2 480 |
| 3 | Зачем SDLC нужен рядовому разработчику?
Проблема того, что немногие знают SDLC в том, что этот термин в основном использовался техническими менеджерами, т. к. именно они отвечают за настройку процессов в командах.
С AI агентами у нас меняется уровень абстракции и теперь процессами, которыми управляли тех. менеджеры, должны управлять разработчики.
Зачем он нужен разработчику?
1. Расширение кругозора.
Тут мы помним, что в век AI, стало полезнее знать о существовании какой то практики, чем быть экспертом в этой практике. Ведь часть экспертности (поверхностной) можно получить от AI, либо от специалиста в этом ( консультация/исполнение)
2. Личный рост.
Сейчас в мире происходят ИИ-трансформации (и будут длиться еще несколько лет) и всегда будет полезен человек, который будет вести эту трансформацию внутри команды/компании, потому что он будет знать внутреннюю кухню. А значит может помочь закрыть цели руководству и, в свою очередь, может получить хорошую прибавку к ЗП или должность.
А если в своей компании таких бенефитов не ожидается, то можно найти компанию, где к этому относятся серьезнее.
А ещё можно попробовать сделать свой продукт и с понимание SDLC это будет проще. Хотя, одним пониманием SDLC тут не ограничивается.
Чего потребуется от разработчика?
Переход к AI SDLC обычно предполагает, что разраб начинает расти вширь (не в буквальном смысле), должен уметь и на дуде играть и быть швецом и жнецом.
Это означает, что нужна экспертность в одной области и базовые знания в смежных областях.
Помимо этого, нужно ещё знать базу вокруг разработки:
- computer science
- сети
- архитектуру веб приложений
- git, docker
- ci/cd
- и другие базовые термины.
А, и ещё тут очень важно уметь отследить и диагностировать проблему.
К моему удивлению, не все разработчики это всё знают. Я для себя это объясняю тем, что большинство работает на одних и тех же проектах в одних и тех же ролях годами. А знания вширь развиваются тогда, когда разработчику даются разнообразные задачи около своего стека.
Как только разработчик получает эти знания, процесс разработки сильно меняется и становится надёжнее.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь! | 5 |
| 4 | 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 хотелось бы найти похожее. | 3 236 |
| 5 | К концу рабочего дня у вас появляется ощущение что вы ничего серьёзного не сделали за день?
Или это только у меня такое?
У меня такое ощущение появляется особенно когда за день я особо не кодил, но работал с документами – создание/модификация, рисерчи.
Подсознательно как будто бы ты привыкаешь к тому, что когда ты каждый день когда пишешь код, даже с ИИшкой, ты видишь объем навайбкоженных файлов с кодом или вмерженные PR.
Но когда ты работаешь с документами, то к концу дня обычно у тебя появляется, скажем, 1-2 документа, и внутреннее чувство появляется такое, что как будто бы, ну блин, ну создал ты эти документы, ну и чего? Но ведь серьёзной работы никакой не было проведено! Пруфов то немного!
При этом, головой ты понимаешь, что блин, ты же работал целый день и к концу дня устал. У тебя уже голова стала квадратной.
У кого-то такое встречается? Если да, как вы решаете такую проблему?
Я пока что решаю так – навайбкодил тул, который анализирует созданные сессии с агентами за день и подводит итоги дня/недели и тем самым показывает, какой ты красавчик. | 3 475 |
| 6 |  В чем залог успеха при работе с ai агентами?
ответ на фото – это feedback loop.
Нарочно не придумаешь… MacBook использует свою веб-камеру, чтобы смотреть на экран в зеркальном отображении и улучшить поддержку чипов AMD Radeon в Omarchy.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь! | 3 545 |
| 7 | Как должен выглядеть 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, подписывайтесь! | 4 150 |
| 8 | Очередной скандал с 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-ран), не имея строгого понимания того, как устроен его разум? Стоит ли опускать голову, потому что «это всё равно случится», — или использовать этот момент, чтобы потребовать других условий?
Тред репостнул Evan Hubinger и подтвердил, что Jacob прав – AI действительно может убить всех человеков. Вероятность что это произойдет в течение ближайших 4-х лет более 10%:
Jacob is correct here—we really do earnestly believe AI could kill all humans!
(прошу обратить внимание на восклицание)
Да, кстати, Evan – Alignment Science Lead и как никто другой разбирается в том, что говорит.
Что происходит?
Тут два варианта:
1) Эти ребята действительно искренны в своих словах и мир в опасности
2) Впереди IPO, на котором Anthropic нужно продаться как можно дороже, а Dario Amodei доказать, что он круче своего бывшего начальника.
И пока что я больше склоняюсь ко второму варианту.
Я помню, как всю весну компания Anthropic очень некрасиво прогревала людей и совала свои руки очень глубоко в души людей, чтобы вызывать чувство страха, когда пиарила Mythos, и по факту эта модель не оказалась чем-то сверхестественным.
До этого Dario Amodei утверждал, что скоро всех разработчиков уволят за ненадобностью.
Короче, мы уже привыкли к такой риторике Anthropic и у многих людей появляются вопросики к ней и недоверие + омерзение к самой компании.
Я про это планирую ещё пост написать – почему все так не любят Anthropic, чтобы потом можно было кидать его любому, кто задается таким вопросом.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь! | 3 616 |
| 9 | какая же astra быстрая и умная это ппц! для большинства задач хватает reasoning light.
я привык, что нужно отправить промпт, а потом ждать минут 3-5 ответа (как было с sol medium-high)
а теперь непривычно, что ответ готов за меньше чем за 30 сек! и это даже не fast mode
у вас как проходит опыт использования astra? | 3 722 |
| 10 | Почему разработка с 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, подписывайтесь! | 3 797 |
| 11 |  +1show-me skill
Тут немного завирусился skill от humanlayer – show-me.
Суть – помочь пользователю понять diff'ы с помощью кратких диаграмм, псевдокода или HTML.
Я попробовал, мне понравилось, рекомендую и вам!
Установить:
npx skills add humanlayer/skills --skill show-me
📱 Ссылка на github
Пример на скриншотах.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь! | 6 184 |
| 12 | agi is here
5.6 sol high целый час пытался настроить тайцы2 (кто шарит тот шарит. в обсуждение этого в комментах не углубляемся) чтобы у меня работал ютуб
у него ничего не получалось.
сменил в этом же чате модель на gpt-6-astra medium и через 3 мин задача была решена
помимо этого, astra общается сильно приятнее, чем предыдущие gpt 5.*.
но тратит прям оч много usage. очень жду следующих моделек поменьше на базе gpt-6. должно быть очень классно.
продолжаю наблюдения.
а у вас какие отзывы о работе astra? | 4 501 |
| 13 | Результаты опросов 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, подписывайтесь! | 5 437 |
| 14 | Я много слышу о том, что мы боимся применять AI потому что он нифига не понимает наш проект, не сможет написать тесты и вообще, с проектом умеют работать только наши бородатые синьоры, которые сидят на нём уже лет 5 минимум.
Сегодня работал с одним легаси проектом и вспомнил одну проблему некой фичи, с которой часто сталкиваются пользователи. У проекта даже есть целая пачка инструкций для саппорта по тому, как правильно диагностировать её.
В этот раз, мне стало интересно описать эту проблему кодексу как есть и попросить его разобраться, почему это происходит. По логике вещей, это не нормально, но за 6 лет работы этой фичи, это стало нормой.
Через 10 мин кодекс выдал по четыре P0-P3 issues для исправления, чтобы такого больше не повторялось. И все они действительно актуальны.
За 6 лет существования этой фичи, эта проблема не была ни кем исправлена, потому что, чтобы заниматься этим проектом, нужно было погрязнуть в диагностике на пару дней. А потом ещё продумать, как бы проверить решение, потому что тестов там не было вообще ) да и отследить проблему довольно сложно – она на стыке network, app, db. Ну и нафиг туда лезть, если в целом в 90% случаев оно работает?)
Так вот, возвращаясь к тому, что AI нифига не может писать тестов и вообще кодить ваш проект.
Скорее всего, проблема в том, что ваш легаси – лапшеобразный велосипед, знания о котором бережно хранятся в головах ваших синьоров и им ревностно отдавать эти знания жалкой железяке (чтобы не заменила вдруг).
Мало кому приятно признавать свои ошибки и плохие решения перед своими коллегами и начальством (которое пушит AI трансформацию), потому что AI вскрывает такие гнойники на раз.
А ещё, вы можете себе представить, чтобы взрослый дядька, который с большим скепсисом относится к этому AI и вообще со большим снисхождением пускает копилот себе на проект, смог бы признать, что он был неправ при дизайне архитектуры?
Какой-то там T9 на стероидах/новый пузырь/очередной хайп, смог найти критические проблемы в моём решении? Да ну, фигня какая то!
Вот и выходит, что одно из актуальных бутылочных горлышек, в переходе на AI SDLC – это перенос вот таких вот тайных знаний об устройстве велосипедов (это называется tacit knowledge) от "дедов" проекта в документацию.
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь! | 5 389 |
| 15 | Подборка постов моего канала
Здесь собрал материалы для тех, кто смотрит на 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, подписывайтесь! | 4 300 |
| 16 |  я же тут пару недель назад сделал чатбота для канала, забыл рассказать!
всё что он умеет - это отвечать на вопросы по постам канала.
зачем?
мне показалось, что у меня в подписчиках есть люди, которым что-то могло быть непонятно, или они хотели бы узнать побольше по каким нибудь темам, но по каким-то причинам не задают эти вопросы тут в комментах.
поэтому, я решил сделать бота, в который можно задавать любые ваши вопросы и он постарается ответить на них!
что там под капотом?
форк pi.dev – flue, под управлением qwen3.7-flash.
как работает поиск?
каждый мой пост классифицируется по категориям.
агенту доступны инструменты поиска по постам и просмотр постов по категориям. работает вполне ок, но думаю вы наверняка найдёте баги, которые мне нужно будет пофиксить :)
пользуйтесь на здоровье! в комменты можно слать фидбек, если что-то не будет работать.
открыть бота | 3 974 |
| 17 | Про мутационные тесты
Мутационное тестирование — это метод оценки качества набора юнит-тестов. В исходный код программы намеренно вносят мелкие ошибки (мутации) вроде замены плюса на минус. Затем запускают тесты: если тесты «поймали» изменение и упали, значит, они работают хорошо. Если тесты прошли успешно, значит, код проверяется плохо.
У меня тут наконец-то дошли руки попробовать это (спасибо стриму Кости Доронина) и вот делюсь впечатлениями.
Сначала пробовал запускать их локально на маке, но быстро столкнулся с тем, что они жрут очень много 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, подписывайтесь! | 4 447 |
| 18 | Про типичные проблемы 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, подписывайтесь! | 4 715 |
| 19 | Если вам о чём-нибудь говорит имя Андрей Бреслав (один из создателей Kotlin), то у меня для вас хорошие новости!
Мой коллега Костя Доронин каким-то образом договорился с ним о совместном эфире, куда придут ещё Макс Этихлид @etechlead и Валера Ковальский @neuraldeep.
Ребята поговорят про подходы к AI Coding:
- как писать код с AI-агентами?
- а если командой?
- что нужно учесть, чтобы этот код не положил продакшн?
Эфир будет уже завтра, 20 августа, в четверг, в 19:00 МСК.
Вопросы можно задать под оригинальным постом. | 4 287 |
| 20 | بدون متن... | 4 210 |
