Авторский канал.
Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь через ЛС канала | Визитка: timurkhakhalev.t.me
Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь через ЛС канала | Визитка: timurkhakhalev.t.me
какая же astra быстрая и умная это ппц! для большинства задач хватает reasoning light.
я привык, что нужно отправить промпт, а потом ждать минут 3-5 ответа (как было с sol medium-high)
а теперь непривычно, что ответ готов за меньше чем за 30 сек! и это даже не fast mode
у вас как проходит опыт использования astra?
я привык, что нужно отправить промпт, а потом ждать минут 3-5 ответа (как было с sol medium-high)
а теперь непривычно, что ответ готов за меньше чем за 30 сек! и это даже не fast mode
у вас как проходит опыт использования astra?
Почему разработка с 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, подписывайтесь!
Многие разработчики привыкли работать с 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 отсутствие таких процессов будет сильно замедлять работу.
А ИИ-трансформация во многих компаниях заканчивается в лучшем случае на оплате подписок для сотрудников, а в худшем - на снятии запретов на использование агентов (подписки оплачивайте сами).
Лайк, репост,
Тут немного завирусился skill от humanlayer – show-me.
Суть – помочь пользователю понять diff'ы с помощью кратких диаграмм, псевдокода или HTML.
Я попробовал, мне понравилось, рекомендую и вам!
Установить:
npx skills add humanlayer/skills --skill show-meПример на скриншотах.
Лайк, репост,
agi is here
5.6 sol high целый час пытался настроить тайцы2 (кто шарит тот шарит. в обсуждение этого в комментах не углубляемся) чтобы у меня работал ютуб
у него ничего не получалось.
сменил в этом же чате модель на gpt-6-astra medium и через 3 мин задача была решена
помимо этого, astra общается сильно приятнее, чем предыдущие gpt 5.*.
но тратит прям оч много usage. очень жду следующих моделек поменьше на базе gpt-6. должно быть очень классно.
продолжаю наблюдения.
а у вас какие отзывы о работе astra?
5.6 sol high целый час пытался настроить тайцы2 (кто шарит тот шарит. в обсуждение этого в комментах не углубляемся) чтобы у меня работал ютуб
у него ничего не получалось.
сменил в этом же чате модель на gpt-6-astra medium и через 3 мин задача была решена
помимо этого, astra общается сильно приятнее, чем предыдущие gpt 5.*.
но тратит прям оч много usage. очень жду следующих моделек поменьше на базе gpt-6. должно быть очень классно.
продолжаю наблюдения.
а у вас какие отзывы о работе astra?
Результаты опросов 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 в компаниях и самым насущным проблемам.
Опросы прошли около 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 потому что он нифига не понимает наш проект, не сможет написать тесты и вообще, с проектом умеют работать только наши бородатые синьоры, которые сидят на нём уже лет 5 минимум.
Сегодня работал с одним легаси проектом и вспомнил одну проблему некой фичи, с которой часто сталкиваются пользователи. У проекта даже есть целая пачка инструкций для саппорта по тому, как правильно диагностировать её.
В этот раз, мне стало интересно описать эту проблему кодексу как есть и попросить его разобраться, почему это происходит. По логике вещей, это не нормально, но за 6 лет работы этой фичи, это стало нормой.
Через 10 мин кодекс выдал по четыре P0-P3 issues для исправления, чтобы такого больше не повторялось. И все они действительно актуальны.
За 6 лет существования этой фичи, эта проблема не была ни кем исправлена, потому что, чтобы заниматься этим проектом, нужно было погрязнуть в диагностике на пару дней. А потом ещё продумать, как бы проверить решение, потому что тестов там не было вообще ) да и отследить проблему довольно сложно – она на стыке network, app, db. Ну и нафиг туда лезть, если в целом в 90% случаев оно работает?)
Так вот, возвращаясь к тому, что AI нифига не может писать тестов и вообще кодить ваш проект.
Скорее всего, проблема в том, что ваш легаси – лапшеобразный велосипед, знания о котором бережно хранятся в головах ваших синьоров и им ревностно отдавать эти знания жалкой железяке (чтобы не заменила вдруг).
Мало кому приятно признавать свои ошибки и плохие решения перед своими коллегами и начальством (которое пушит AI трансформацию), потому что AI вскрывает такие гнойники на раз.
А ещё, вы можете себе представить, чтобы взрослый дядька, который с большим скепсисом относится к этому AI и вообще со большим снисхождением пускает копилот себе на проект, смог бы признать, что он был неправ при дизайне архитектуры?
Какой-то там T9 на стероидах/новый пузырь/очередной хайп, смог найти критические проблемы в моём решении? Да ну, фигня какая то!
Вот и выходит, что одно из актуальных бутылочных горлышек, в переходе на AI SDLC – это перенос вот таких вот тайных знаний об устройстве велосипедов (это называется tacit knowledge) от "дедов" проекта в документацию.
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Сегодня работал с одним легаси проектом и вспомнил одну проблему некой фичи, с которой часто сталкиваются пользователи. У проекта даже есть целая пачка инструкций для саппорта по тому, как правильно диагностировать её.
В этот раз, мне стало интересно описать эту проблему кодексу как есть и попросить его разобраться, почему это происходит. По логике вещей, это не нормально, но за 6 лет работы этой фичи, это стало нормой.
Через 10 мин кодекс выдал по четыре P0-P3 issues для исправления, чтобы такого больше не повторялось. И все они действительно актуальны.
За 6 лет существования этой фичи, эта проблема не была ни кем исправлена, потому что, чтобы заниматься этим проектом, нужно было погрязнуть в диагностике на пару дней. А потом ещё продумать, как бы проверить решение, потому что тестов там не было вообще ) да и отследить проблему довольно сложно – она на стыке network, app, db. Ну и нафиг туда лезть, если в целом в 90% случаев оно работает?)
Так вот, возвращаясь к тому, что AI нифига не может писать тестов и вообще кодить ваш проект.
Скорее всего, проблема в том, что ваш легаси – лапшеобразный велосипед, знания о котором бережно хранятся в головах ваших синьоров и им ревностно отдавать эти знания жалкой железяке (чтобы не заменила вдруг).
Мало кому приятно признавать свои ошибки и плохие решения перед своими коллегами и начальством (которое пушит AI трансформацию), потому что AI вскрывает такие гнойники на раз.
А ещё, вы можете себе представить, чтобы взрослый дядька, который с большим скепсисом относится к этому AI и вообще со большим снисхождением пускает копилот себе на проект, смог бы признать, что он был неправ при дизайне архитектуры?
Какой-то там T9 на стероидах/новый пузырь/очередной хайп, смог найти критические проблемы в моём решении? Да ну, фигня какая то!
Вот и выходит, что одно из актуальных бутылочных горлышек, в переходе на AI SDLC – это перенос вот таких вот тайных знаний об устройстве велосипедов (это называется tacit knowledge) от "дедов" проекта в документацию.
Лайк, репост,
Подборка постов моего канала
Здесь собрал материалы для тех, кто смотрит на 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, подписывайтесь!
Здесь собрал материалы для тех, кто смотрит на 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
Лайк, репост,
всё что он умеет - это отвечать на вопросы по постам канала.
зачем?
мне показалось, что у меня в подписчиках есть люди, которым что-то могло быть непонятно, или они хотели бы узнать побольше по каким нибудь темам, но по каким-то причинам не задают эти вопросы тут в комментах.
поэтому, я решил сделать бота, в который можно задавать любые ваши вопросы и он постарается ответить на них!
что там под капотом?
форк pi.dev – flue, под управлением qwen3.7-flash.
как работает поиск?
каждый мой пост классифицируется по категориям.
агенту доступны инструменты поиска по постам и просмотр постов по категориям. работает вполне ок, но думаю вы наверняка найдёте баги, которые мне нужно будет пофиксить :)
пользуйтесь на здоровье! в комменты можно слать фидбек, если что-то не будет работать.
открыть бота
Про мутационные тесты
Мутационное тестирование — это метод оценки качества набора юнит-тестов. В исходный код программы намеренно вносят мелкие ошибки (мутации) вроде замены плюса на минус. Затем запускают тесты: если тесты «поймали» изменение и упали, значит, они работают хорошо. Если тесты прошли успешно, значит, код проверяется плохо.
У меня тут наконец-то дошли руки попробовать это (спасибо стриму Кости Доронина) и вот делюсь впечатлениями.
Сначала пробовал запускать их локально на маке, но быстро столкнулся с тем, что они жрут очень много 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, подписывайтесь!
Мутационное тестирование — это метод оценки качества набора юнит-тестов. В исходный код программы намеренно вносят мелкие ошибки (мутации) вроде замены плюса на минус. Затем запускают тесты: если тесты «поймали» изменение и упали, значит, они работают хорошо. Если тесты прошли успешно, значит, код проверяется плохо.
У меня тут наконец-то дошли руки попробовать это (спасибо стриму Кости Доронина) и вот делюсь впечатлениями.
Сначала пробовал запускать их локально на маке, но быстро столкнулся с тем, что они жрут очень много 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
На этой неделе я упомянул несколько проблем 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, подписывайтесь!
На этой неделе я упомянул несколько проблем 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
Лайк, репост,
Если вам о чём-нибудь говорит имя Андрей Бреслав (один из создателей Kotlin), то у меня для вас хорошие новости!
Мой коллега Костя Доронин каким-то образом договорился с ним о совместном эфире, куда придут ещё Макс Этихлид @etechlead и Валера Ковальский @neuraldeep.
Ребята поговорят про подходы к AI Coding:
- как писать код с AI-агентами?
- а если командой?
- что нужно учесть, чтобы этот код не положил продакшн?
Эфир будет уже завтра, 20 августа, в четверг, в 19:00 МСК.
Вопросы можно задать под оригинальным постом.
Мой коллега Костя Доронин каким-то образом договорился с ним о совместном эфире, куда придут ещё Макс Этихлид @etechlead и Валера Ковальский @neuraldeep.
Ребята поговорят про подходы к AI Coding:
- как писать код с AI-агентами?
- а если командой?
- что нужно учесть, чтобы этот код не положил продакшн?
Эфир будет уже завтра, 20 августа, в четверг, в 19:00 МСК.
Вопросы можно задать под оригинальным постом.
Telegram
Константин Доронин
Как писать код с AI-агентами?
А если командой?
Что нужно учесть, чтобы этот код не положил продакшн?
Эти и другие не менее интересные вопросы мы обсудим на следующем стриме на моём YouTube-канале.
Для обсуждения я позвал очень интересных гостей:
Андрей…
А если командой?
Что нужно учесть, чтобы этот код не положил продакшн?
Эти и другие не менее интересные вопросы мы обсудим на следующем стриме на моём YouTube-канале.
Для обсуждения я позвал очень интересных гостей:
Андрей…
Я тут наткнулся на тред hackernews где обсуждают проблему ai coding.
Мне чёт казалось, что все эти проблемы уже решены и ничего из этого не актуально.
но, может быть я в пузыре нахожусь, так что решил спросить моих подписчиков, че думаете?
для вас эти проблемы всё ещё актуальны и вы страдаете от них?
1) Неконтролируемый техдолг — AI позволяет генерировать код быстрее, чем команда успевает его осмысливать. То, что раньше занимало 100 инженеров 5 лет, теперь 5 инженеров делают за 6 месяцев — но это legacy-код сразу. (коммент 2, 13, 104)
2) Код превращается в AI slop — При vibe-delivery множества фич за спринт кодовая база становится непредсказуемой мешковиной. (коммент 86)
3) Потеря ментальной модели — Построение ментальной модели — 90% работы, сам код — 10%. AI-подсказки ломают flow state, в котором модель транслируется в код. (коммент 1, 5)
4) Команда теряет знание проекта — При 99% AI-generated changes команда коллективно теряет понимание кодовой базы. Любая проблема, с которой AI не справляется, занимает значительно дольше — работают как с чужим кодом. (коммент 102)
5) Люди делегируют AI анализ — Появляются «AI-анализы», которые автор даже не читал. «Я могу сам спросить Claude — нет выгоды, только длинные вопросы, которые тратят моё время». (коммент 3, 4)
6) Потеря навыков для собеседований — Разработчикам приходится вручную писать код дома, чтобы не забыть синтаксис — LeetCode всё ещё актуален даже для Staff+. (коммент 36, 39, 41)
7) Deskilling через потерю боли повторения — В losing the pain of repetition, we lost the incentive towards abstraction. До AI боль заставляла разработчиков создавать инструменты и абстракции. AI убил этот стимул. (коммент 71)
8) Spec-driven = возврат к waterfall — AI-подходы переоткрывают провальные методологии 60-х. Разделение «архитекторов» и «реализаторов» — провальная идея. «Код — это спецификация». (коммент 97)
Мне чёт казалось, что все эти проблемы уже решены и ничего из этого не актуально.
но, может быть я в пузыре нахожусь, так что решил спросить моих подписчиков, че думаете?
для вас эти проблемы всё ещё актуальны и вы страдаете от них?
1) Неконтролируемый техдолг — AI позволяет генерировать код быстрее, чем команда успевает его осмысливать. То, что раньше занимало 100 инженеров 5 лет, теперь 5 инженеров делают за 6 месяцев — но это legacy-код сразу. (коммент 2, 13, 104)
2) Код превращается в AI slop — При vibe-delivery множества фич за спринт кодовая база становится непредсказуемой мешковиной. (коммент 86)
3) Потеря ментальной модели — Построение ментальной модели — 90% работы, сам код — 10%. AI-подсказки ломают flow state, в котором модель транслируется в код. (коммент 1, 5)
4) Команда теряет знание проекта — При 99% AI-generated changes команда коллективно теряет понимание кодовой базы. Любая проблема, с которой AI не справляется, занимает значительно дольше — работают как с чужим кодом. (коммент 102)
5) Люди делегируют AI анализ — Появляются «AI-анализы», которые автор даже не читал. «Я могу сам спросить Claude — нет выгоды, только длинные вопросы, которые тратят моё время». (коммент 3, 4)
6) Потеря навыков для собеседований — Разработчикам приходится вручную писать код дома, чтобы не забыть синтаксис — LeetCode всё ещё актуален даже для Staff+. (коммент 36, 39, 41)
7) Deskilling через потерю боли повторения — В losing the pain of repetition, we lost the incentive towards abstraction. До AI боль заставляла разработчиков создавать инструменты и абстракции. AI убил этот стимул. (коммент 71)
8) Spec-driven = возврат к waterfall — AI-подходы переоткрывают провальные методологии 60-х. Разделение «архитекторов» и «реализаторов» — провальная идея. «Код — это спецификация». (коммент 97)
openai на прошлой неделе выпустили новую фичу – computer history.
это фича, которая отслеживает ваши действия на компьютере, записывает их в файл, а потом, раз в 10 мин отправляет в llm запрос на суммаризацию этих данных. а раз в 6 часов делает суммаризацию по этим 10-ти минутным блокам.
как они сами рассказывают, основные вопросы которая она закрывает, это:
- вспомнить, чем мы занимались до обеда
- вспомнить недавнюю работу которой мы занимались
- предложить автоматизировать повторяющиеся действия в ваших рабочих процессах и создать на основе этого skills
мне эта фича стала интересной и я разобрался как оно работает под капотом.
так я узнал, что
- данные хранятся 48 часов, потом удаляются
- events данные хранятся в .json и не зашифрованы, а саммари хранятся в .md. openai в документации прямо заявляет о том, что перекладывает ответственность за хранение этих данных на пользователей
- для создания саммари используется та же модель, что и для создания MEMORY.md – в api она называется openai-memgen, а под капотом там на самом деле используется gpt-5.5-low
я поразмышлял, что ещё полезного и ценного для юзера можно было бы сделать с такими собранными данными и вот такие мысли у меня:
- включив эту фичу всего лишь на один день, я увидел что я переделал кучу дел и на самом деле продуктивен :) мне кажется для некоторых людей было бы полезно показывать сколько всего они успели переделать за день, за неделю, за месяц, чтобы можно было оценивать результаты.
- computer history уже умеет создавать skills по workflows юзера, но что если ещё можно корректировать сами workflows? например, подсказывать юзеру, что он не правильно создает функции для своей таблицы в excel, и лучше делать вот так.
- на основе замеченных ошибок в юзерских workflows лезть глубже и смотреть сетапы - может быть есть чего улучшить? например, мы видим, что пользователь постоянно матерится на codex. А что если залезть к нему в репо и посмотреть как оформлен например AGENTS.md? сравнить его с best practices и предложить улучшения?
что думаете по поводу этой фичи? она может представлять какую-то ценность для пользователя? а если будет работать на локальном llm?
это фича, которая отслеживает ваши действия на компьютере, записывает их в файл, а потом, раз в 10 мин отправляет в llm запрос на суммаризацию этих данных. а раз в 6 часов делает суммаризацию по этим 10-ти минутным блокам.
как они сами рассказывают, основные вопросы которая она закрывает, это:
- вспомнить, чем мы занимались до обеда
- вспомнить недавнюю работу которой мы занимались
- предложить автоматизировать повторяющиеся действия в ваших рабочих процессах и создать на основе этого skills
мне эта фича стала интересной и я разобрался как оно работает под капотом.
так я узнал, что
- данные хранятся 48 часов, потом удаляются
- events данные хранятся в .json и не зашифрованы, а саммари хранятся в .md. openai в документации прямо заявляет о том, что перекладывает ответственность за хранение этих данных на пользователей
- для создания саммари используется та же модель, что и для создания MEMORY.md – в api она называется openai-memgen, а под капотом там на самом деле используется gpt-5.5-low
я поразмышлял, что ещё полезного и ценного для юзера можно было бы сделать с такими собранными данными и вот такие мысли у меня:
- включив эту фичу всего лишь на один день, я увидел что я переделал кучу дел и на самом деле продуктивен :) мне кажется для некоторых людей было бы полезно показывать сколько всего они успели переделать за день, за неделю, за месяц, чтобы можно было оценивать результаты.
- computer history уже умеет создавать skills по workflows юзера, но что если ещё можно корректировать сами workflows? например, подсказывать юзеру, что он не правильно создает функции для своей таблицы в excel, и лучше делать вот так.
- на основе замеченных ошибок в юзерских workflows лезть глубже и смотреть сетапы - может быть есть чего улучшить? например, мы видим, что пользователь постоянно матерится на codex. А что если залезть к нему в репо и посмотреть как оформлен например AGENTS.md? сравнить его с best practices и предложить улучшения?
что думаете по поводу этой фичи? она может представлять какую-то ценность для пользователя? а если будет работать на локальном llm?
Грабли во внедрении ИИ в SDLC – Николай Шейко
3 июля проходила конфа Agentic Dev Conf, на которой я был в качестве члена программного комитета, а Коля @ai_grably выступал спикером.
https://www.youtube.com/watch?v=Nm3MsnngCJg
Мне выступление оч понравилось – оно было очень живым, без духоты и корпоративной напыщенности.
Вот некоторые из проблем, про которые Коля рассказал и объяснил, как они решаются:
- агент пишет код, а человек идет вручную кликать и проверять результат в браузере.
- сходу давать агенту задачу в разработку
- использование старых подходов разработки или экономия на токенах и актуальных llm
- попытка заставить пользоваться ИИ всех подряд
Так что рекомендую к просмотру!
—
Кстати, если вам тоже есть, что рассказать про ваш опыт в AI (технический, бизнесовый), то подавайте заявку на выступление https://ainativeconf.ru/
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
3 июля проходила конфа Agentic Dev Conf, на которой я был в качестве члена программного комитета, а Коля @ai_grably выступал спикером.
https://www.youtube.com/watch?v=Nm3MsnngCJg
Мне выступление оч понравилось – оно было очень живым, без духоты и корпоративной напыщенности.
Вот некоторые из проблем, про которые Коля рассказал и объяснил, как они решаются:
- агент пишет код, а человек идет вручную кликать и проверять результат в браузере.
- сходу давать агенту задачу в разработку
- использование старых подходов разработки или экономия на токенах и актуальных llm
- попытка заставить пользоваться ИИ всех подряд
Так что рекомендую к просмотру!
—
Кстати, если вам тоже есть, что рассказать про ваш опыт в AI (технический, бизнесовый), то подавайте заявку на выступление https://ainativeconf.ru/
Лайк, репост,
Подборка постов моего канала
Продолжаю делиться любимыми постами с канала. В этой подборке — Codex, Claude Code, субагенты и реальные рабочие процессы.
• Советы от создателя Claude Code Бориса Черного — как команда Claude Code использует агентов, параллельную работу и автоматизацию.
• Как сотрудник OpenAI использует Codex — реальный рабочий процесс разработчика внутри OpenAI.
• Как разработчики Telegram Desktop используют Codex и Claude Code — разбор их подхода к AI Coding и ошибок, допущенных при внедрении.
• Как оплачивать ChatGPT и Claude из России — подборка доступных вариантов оплаты зарубежных AI-сервисов.
Если пропустили какие-то из этих материалов — самое время наверстать.
Сохраняйте подборку и пересылайте коллегам, которые только начинают погружаться в AI Coding.
#posts_collection@the_ai_architect
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Продолжаю делиться любимыми постами с канала. В этой подборке — Codex, Claude Code, субагенты и реальные рабочие процессы.
• Советы от создателя Claude Code Бориса Черного — как команда Claude Code использует агентов, параллельную работу и автоматизацию.
• Как сотрудник OpenAI использует Codex — реальный рабочий процесс разработчика внутри OpenAI.
• Как разработчики Telegram Desktop используют Codex и Claude Code — разбор их подхода к AI Coding и ошибок, допущенных при внедрении.
• Как оплачивать ChatGPT и Claude из России — подборка доступных вариантов оплаты зарубежных AI-сервисов.
Если пропустили какие-то из этих материалов — самое время наверстать.
Сохраняйте подборку и пересылайте коллегам, которые только начинают погружаться в AI Coding.
#posts_collection@the_ai_architect
Лайк, репост,
Если вы сейчас разрабатываете ai coding agent, то обязательно добавляйте себе такую фичу
Я про управление harness'ом с помощью агента, как это реализовано у Codex и как недавно повторили тоже самое для Claude Code.
В чём суть фичи?
Вы даете агенту управлять своей оболочкой:
- читать соседние треды (чаты)
- отправлять в них сообщения
- создавать новые проекты (и другие entities вашего harness)
- и т. д.
Главные плюсы от этой фичи для юзера:
- снижение фрикций при онбординге и дальнейшем использовании;
юзеру не надо помнить, как у вас устроена та или иная фича, даже название помнить не надо. достаточно описать словами, агент сам поймёт и дернет за необходимую ручку
- экономия времени при рутинных задачах, когда нужно передать запрос в соседний тред или прочитать его или найти информацию по предыдущим сессиям
для вашего harness это открывает возможность оркестрации другими тредами из одного треда. по сути, это тоже самое что и субагенты, но в другой оболочке.
при этом, конечно, фича эта не простая, так как нужно продумать все кейсы где агент может наступать на грабли или чего-нибудь сломать
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Я про управление harness'ом с помощью агента, как это реализовано у Codex и как недавно повторили тоже самое для Claude Code.
В чём суть фичи?
Вы даете агенту управлять своей оболочкой:
- читать соседние треды (чаты)
- отправлять в них сообщения
- создавать новые проекты (и другие entities вашего harness)
- и т. д.
Главные плюсы от этой фичи для юзера:
- снижение фрикций при онбординге и дальнейшем использовании;
юзеру не надо помнить, как у вас устроена та или иная фича, даже название помнить не надо. достаточно описать словами, агент сам поймёт и дернет за необходимую ручку
- экономия времени при рутинных задачах, когда нужно передать запрос в соседний тред или прочитать его или найти информацию по предыдущим сессиям
для вашего harness это открывает возможность оркестрации другими тредами из одного треда. по сути, это тоже самое что и субагенты, но в другой оболочке.
при этом, конечно, фича эта не простая, так как нужно продумать все кейсы где агент может наступать на грабли или чего-нибудь сломать
Лайк, репост,
инсайт который пришёл мне этой ночью, пока я жёг токены
вы сталкивались когда-нибудь с такой проблемой: прорабатываешь с codex scope задачи или архитектурное решение и порой бывает, что это занимает довольно много контекста и может выполниться парочку compaction.
да, у codex действительно лучший compaction на рынке и у нас есть почти бесконечное контекстное окно, но всё же важные детали после compaction в любом случае теряются.
особенно, если эти детали не были зафиксированы где-нибудь в файлах, которые можно почитать после compaction.
что делать?
попросите codex использовать tool
если вы раннее видели как codex читает чужие треды, то вы наверняка знаете, что это за tool – он позволяет кодексу читать соседние треды.
но вчера до меня дошло, что его можно просить читать и свой тред тоже.
таким образом, можно прочитать детали, которые он писал в треде, до наступления compaction и восстановить их, чтобы потом сохранить в вашем плане.
вы уже знали про такой лайфхак?
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
вы сталкивались когда-нибудь с такой проблемой: прорабатываешь с codex scope задачи или архитектурное решение и порой бывает, что это занимает довольно много контекста и может выполниться парочку compaction.
да, у codex действительно лучший compaction на рынке и у нас есть почти бесконечное контекстное окно, но всё же важные детали после compaction в любом случае теряются.
особенно, если эти детали не были зафиксированы где-нибудь в файлах, которые можно почитать после compaction.
что делать?
попросите codex использовать tool
read_thread.если вы раннее видели как codex читает чужие треды, то вы наверняка знаете, что это за tool – он позволяет кодексу читать соседние треды.
но вчера до меня дошло, что его можно просить читать и свой тред тоже.
таким образом, можно прочитать детали, которые он писал в треде, до наступления compaction и восстановить их, чтобы потом сохранить в вашем плане.
прочти весь наш тред через read_thread и убедись что ты собрал все детали которые мы с тобой обсуждали и на которых остановилисьвы уже знали про такой лайфхак?
Лайк, репост,
вот такое вот "горе от ума" получается с 5.6 поколением gpt
мы долго жаловались на посредственное качество кода и решений, но выходит, что чтобы получит офигенное качество, нужно сделать космолёт))
я тоже устал бороться с оверинжинирингом и для своего plan&act сделал этап simplify - запускается субагент, который смотрит на всё это дело и предлагает упрощения, а основной агент принимает или отклоняет правки. При этом, решение об отклонении или принятии он делает довольно хорошее - нет такого что он всё дефает или со всем соглашается
мы долго жаловались на посредственное качество кода и решений, но выходит, что чтобы получит офигенное качество, нужно сделать космолёт))
я тоже устал бороться с оверинжинирингом и для своего plan&act сделал этап simplify - запускается субагент, который смотрит на всё это дело и предлагает упрощения, а основной агент принимает или отклоняет правки. При этом, решение об отклонении или принятии он делает довольно хорошее - нет такого что он всё дефает или со всем соглашается
