Тимур Хахалев про AI Coding

Я много слышу о том, что мы боимся применять AI потому что он нифига не понимает наш проект, не сможет написать тесты и вообще, с проектом умеют работать только наши бородатые синьоры, которые сидят на нём уже лет 5 минимум. Сегодня работал с одним легаси проектом и вспомнил одну проблему некой фичи, с которой часто сталкиваются пользователи. У проекта даже есть целая пачка инструкций для саппорта по тому, как правильно диагностировать её. В этот раз, мне стало интересно описать эту проблему кодексу как есть и попросить его разобраться, почему это происходит. По логике вещей, это не нормально, но за 6 лет работы этой фичи, это стало нормой. Через 10 мин кодекс выдал по четыре P0-P3 issues для исправления, чтобы такого больше не повторялось. И все они действительно актуальны. За 6 лет существования этой фичи, эта проблема не была ни кем исправлена, потому что, чтобы заниматься этим проектом, нужно было погрязнуть в диагностике на пару дней. А потом ещё продумать, как бы проверить решение, потому что тестов там не было вообще ) да и отследить проблему довольно сложно – она на стыке network, app, db. Ну и нафиг туда лезть, если в целом в 90% случаев оно работает?) Так вот, возвращаясь к тому, что AI нифига не может писать тестов и вообще кодить ваш проект. Скорее всего, проблема в том, что ваш легаси – лапшеобразный велосипед, знания о котором бережно хранятся в головах ваших синьоров и им ревностно отдавать эти знания жалкой железяке (чтобы не заменила вдруг). Мало кому приятно признавать свои ошибки и плохие решения перед своими коллегами и начальством (которое пушит AI трансформацию), потому что AI вскрывает такие гнойники на раз. А ещё, вы можете себе представить, чтобы взрослый дядька, который с большим скепсисом относится к этому AI и вообще со большим снисхождением пускает копилот себе на проект, смог бы признать, что он был неправ при дизайне архитектуры? Какой-то там T9 на стероидах/новый пузырь/очередной хайп, смог найти критические проблемы в моём решении? Да ну, фигня какая то! Вот и выходит, что одно из актуальных бутылочных горлышек, в переходе на AI SDLC – это перенос вот таких вот тайных знаний об устройстве велосипедов (это называется tacit knowledge) от "дедов" проекта в документацию. Лайк, репост, ✔️ Тимур Хахалев про 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, подписывайтесь!

я же тут пару недель назад сделал чатбота для канала, забыл рассказать! всё что он умеет - это отвечать на вопросы по постам канала. зачем? мне показалось, что у меня в подписчиках есть люди, которым что-то могло быть непонятно, или они хотели бы узнать побольше по каким нибудь темам, но по каким-то причинам не задают эти вопросы тут в комментах. поэтому, я решил сделать бота, в который можно задавать любые ваши вопросы и он постарается ответить на них! что там под капотом? форк 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, подписывайтесь!

Про типичные проблемы 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, подписывайтесь!

Если вам о чём-нибудь говорит имя Андрей Бреслав (один из создателей Kotlin), то у меня для вас хорошие новости! Мой коллега Костя Доронин каким-то образом договорился с ним о совместном эфире, куда придут ещё Макс Этихлид @etechlead и Валера Ковальский @neuraldeep. Ребята поговорят про подходы к AI Coding: - как писать код с AI-агентами? - а если командой? - что нужно учесть, чтобы этот код не положил продакшн? Эфир будет уже завтра, 20 августа, в четверг, в 19:00 МСК. Вопросы можно задать под оригинальным постом.

Я тут наткнулся на тред 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) саммари создавал ai, так что сорри

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?

Грабли во внедрении ИИ в SDLC – Николай Шейко 3 июля проходила конфа Agentic Dev Conf, на которой я был в качестве члена программного комитета, а Коля @ai_grably выступал спикером. https://www.youtube.com/watch?v=Nm3MsnngCJg Мне выступление оч понравилось – оно было очень живым, без духоты и корпоративной напыщенности. Вот некоторые из проблем, про которые Коля рассказал и объяснил, как они решаются: - агент пишет код, а человек идет вручную кликать и проверять результат в браузере. - сходу давать агенту задачу в разработку - использование старых подходов разработки или экономия на токенах и актуальных llm - попытка заставить пользоваться ИИ всех подряд Так что рекомендую к просмотру! — Кстати, если вам тоже есть, что рассказать про ваш опыт в AI (технический, бизнесовый), то подавайте заявку на выступление https://ainativeconf.ru/ Лайк, репост, ✔️ Тимур Хахалев про 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, подписывайтесь!

Если вы сейчас разрабатываете ai coding agent, то обязательно добавляйте себе такую фичу Я про управление harness'ом с помощью агента, как это реализовано у Codex и как недавно повторили тоже самое для Claude Code. В чём суть фичи? Вы даете агенту управлять своей оболочкой: - читать соседние треды (чаты) - отправлять в них сообщения - создавать новые проекты (и другие entities вашего harness) - и т. д. Главные плюсы от этой фичи для юзера: - снижение фрикций при онбординге и дальнейшем использовании; юзеру не надо помнить, как у вас устроена та или иная фича, даже название помнить не надо. достаточно описать словами, агент сам поймёт и дернет за необходимую ручку - экономия времени при рутинных задачах, когда нужно передать запрос в соседний тред или прочитать его или найти информацию по предыдущим сессиям для вашего harness это открывает возможность оркестрации другими тредами из одного треда. по сути, это тоже самое что и субагенты, но в другой оболочке. при этом, конечно, фича эта не простая, так как нужно продумать все кейсы где агент может наступать на грабли или чего-нибудь сломать Лайк, репост, ✔️ Тимур Хахалев про AI Coding, подписывайтесь!

по курсу: сегодня пара человек мне писали в личку и спрашивали, открыт ли ещё набор на курс? да, открыт! сегодня вечером у нас будет первый созвон для тарифов "В потоке" и "С сопровождением", так что если вы успеете приобрести до вечера, то ничего не пропустите! ссылка: https://ai.khakhalev.com/course/

инсайт который пришёл мне этой ночью, пока я жёг токены вы сталкивались когда-нибудь с такой проблемой: прорабатываешь с codex scope задачи или архитектурное решение и порой бывает, что это занимает довольно много контекста и может выполниться парочку compaction. да, у codex действительно лучший compaction на рынке и у нас есть почти бесконечное контекстное окно, но всё же важные детали после compaction в любом случае теряются. особенно, если эти детали не были зафиксированы где-нибудь в файлах, которые можно почитать после compaction. что делать? попросите codex использовать tool read_thread. если вы раннее видели как codex читает чужие треды, то вы наверняка знаете, что это за tool – он позволяет кодексу читать соседние треды. но вчера до меня дошло, что его можно просить читать и свой тред тоже. таким образом, можно прочитать детали, которые он писал в треде, до наступления compaction и восстановить их, чтобы потом сохранить в вашем плане.

прочти весь наш тред через read_thread и убедись что ты собрал все детали которые мы с тобой обсуждали и на которых остановились

вы уже знали про такой лайфхак? Лайк, репост, ✔️ Тимур Хахалев про AI Coding, подписывайтесь!

friendly reminder - в codex сбросили лимиты, в понедельник сбросят ещё раз, а ещё у вас возможно накопились сбросы которые сгорят 12 августа так что время жечь токены!

вот такое вот "горе от ума" получается с 5.6 поколением gpt мы долго жаловались на посредственное качество кода и решений, но выходит, что чтобы получит офигенное качество, нужно сделать космолёт)) я тоже устал бороться с оверинжинирингом и для своего plan&act сделал этап simplify - запускается субагент, который смотрит на всё это дело и предлагает упрощения, а основной агент принимает или отклоняет правки. При этом, решение об отклонении или принятии он делает довольно хорошее - нет такого что он всё дефает или со всем соглашается

⚪️ Текущие впечатления от поколения 5.6 и флоу Много обсуждали в чате, и, пользуясь служебным положением, резюмирую впечатления от поколения gpt моделей 5.6 Использую, как и все, наверное, Sol и Luna. Terra остаётся не у дел: не ясно зачем она нужна - расход немаленький, а качество пониже Sol. ▶️ Планирую Sol. Попытки планирования Луной не сказать чтобы провальные, но она заметно больше упускает, не так глубоко прорабатывает, и делает все сильно дольше. Что у Sol хорошо: он действительно может глубоко проработать. High / Xhigh ризонинга мне хватало. Max / Ultra практически не включал, смысла не вижу. Что у Sol плохо: мощная тяга все усложнять. Без промптинга на жёсткое упрощение навыком Ponytail/аналогами все время получаем космолёт. И в предыдущих поколениях такое было - но сейчас это правило усложнить на ровном месте . Снижение ризонинга помогает слабо и заметно слабее проработка деталей - поэтому приходится спасаться промпингом. Что ещё плохо: лимиты Sol просто кушает. Кодинг на Sol по качетсву ок, времени мало занимает, пишет сразу все хорошо, но даже на Medium/Low лимиты тают ▶️ Что у Луны хорошо: лимиты практически не кончаются. Я уже и количество подписко в пуле снизил (пока на четверть), потому что у меня остались лимиты при текущей загрузке! Думаю, с таким расходом можно повышать использование, больше проектов одновременно и больше сессий. Надо добивать облачный оркестратор. Что у Луны ещё хорошо: она, в принципе, недурственно справляется со всеми конкретно поставленными задачами. Что у Луны плохо: она не так внимательна, как Sol. Может что-то упускать. Спасает ревью. Что ещё у Луны плохо: скорость. Модель не особо летает, и думает она медленно, токенов на max тратит немало. Что ещё у Луны плохо: если встретилась проблема в протоколе (что то не учли заранее или прописали так, что остаётся люфт) - может под goal очень и очень долго ходить кругами и предлагать ерунду вместо решения проблемы. За долгими сессиями надо следить - благо сейчас /side во время сессии позволяет получить справку чего там происходит, что сделано, что не сделано, какие проблемы. ▶️ Насчёт флоу: не могу нащупать баланс - рельсовые флоу получаются очень долго все прорабатывают, могут крутится часами. Качество, конечно, хорошее - но оптимизации затруднены. Попытки делать роутинг простых задач в более простой флоу автоматически приводят к тому, что модели часто видят ситуацию сложнее, чем оно того стоит, в итоге выбирая более тяжёлые флоу чем я бы выбрал "руками" и чем оно того стоит. Не уверен в том, как это чинить - вроде бы упрощать флоу не хочется, для сложных вопросов оно такое надо, но проблему траты кучи времёни надо решать. Пока склоняюсь к созданию облачного оркестратора и работе просто с большим количеством параллельных сессий. Интерактивные сессии с простыми вручную вызываемыми скиллами - тоже вариант, но чтобы получилось качественно, надо много руками дёргать скиллов/субагентов. Без проработки скиллами/субагентами на проектах крупнее 30-50к loc уже получается слоп. ▶️ В целом, я скорее за рельсовые флоу по мотивам SDD / TDD/ BDD, но надо придумывать как бороть их недостаток: очень "тяжелые". Уже разные оптимизации придумываю, всякий роутинг автоматический, всякий вариант не фокусными агентами делать, а группировать в субагентов аспекты пачками. Есть ещё одна задумка: дорабатывать фичи более лёгким флоу, с последующей глубокой проработкой рефакторингом в фоновом режиме (ночью, в облаке, например) - но это все упирается в слабую способность моделей пилить качественную и простую архитектуру. Надежда на астру в этом плане - нужна не оверинжиниринг в моделях, а сеньёрность, умение сделать максимально просто но с полным функционалом. Ponytail это пробует зафорсить, становится лучше, но здравого смысла к сожалению, добавить не всегда может. Возможно, секрет в нескольких агентах и их коллаборации по таким вопросам. Вопрос требует исследований и экспериментов - делитесь если кто то туда же думает. 👉 Примерно так. Можно спрашивать если что то развернуть или невнятно описал. @deksden_notes

вот такое вот "горе от ума" получается с 5.6 поколением gpt мы долго жаловались на посредственное качество кода и решений, но выходит, что чтобы получит офигенное качество, нужно сделать космолёт)) я тоже устал бороться с оверинжинирингом и для своего plan&act сделал этап simplify - запускается субагент, который смотрит на всё это дело и предлагает упрощения, а основной агент принимает или отклоняет правки. При этом, решение об отклонении или принятии он делает довольно хорошее - нет такого что он всё дефает или со всем соглашается

Подборка постов моего канала За последнее время на канале вышло много материалов про практический AI Coding. Собрал мои любимые посты на случай, если вы что-то пропустили. • Почему AI Coding требует подготовки и системного подхода — почему одного доступа к хорошей модели недостаточно для получения надёжного результата. • Почему Codex стал моим инструментом на каждый день — мой опыт перехода на Codex и задачи, для которых я его использую. • Как я использую Chrome DevTools MCP для E2E-тестов — как хранить пользовательские сценарии в репозитории и проверять фронтенд с помощью AI. • Как Anthropic организует выполнение длительных задач по кодингу — про harness для долгих задач, сохранение прогресса и управление контекстом. • CLI Creator Skill — инструмент для создания качественных CLI-приложений с помощью Codex. • Что такое Skills и как их использовать — хорошее объяснение механики Skills и их роли в работе AI-агентов. • Фишки Codex, о которых вы могли не знать — несколько неочевидных возможностей Codex, которые упрощают ежедневную работу. • Безопасный запуск команд в AI-агентах — как защититься от случайного запуска деструктивных команд. • Четыре совета по работе с AI — практические выводы из моего собственного опыта работы с AI. Сохраняйте подборку и пересылайте коллегам, которые только начинают погружаться в AI Coding. #posts_collection@the_ai_architect Лайк, репост, ✔️ Тимур Хахалев про AI Coding, подписывайтесь!

не одним codex единым! неделю назад решил попробовать китайские модельки (чтоб быть готовым в случае если америкосы обрежут доступы к кодексу и клоду) взял opencode go за $5 (последующие месяцы по $10) и сейчас уже пришлось взять второй аккаунт, потому что лимиты кончились емое! короче, китайцы прям шикарны я сейчас работаю в основном с minimax m3 - выбрал потому что она из немногих поддерживает картинки на вход. а еще ее рекламировали как полная копия клода пробую применять свой planact на китайских модельках, пока что вроде всё ок работает. с виду - качество кода тоже ок а вы используете китайцев? какие модели посоветуете?