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


Kanal geosi va tili: Rossiya, Ruscha


Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь: @yatimur | Визитка: timurkhakhalev.t.me

Связанные каналы

Kanal geosi va tili
Rossiya, Ruscha
Statistika
Postlar filtri


Про мутационные тесты

Мутационное тестированиеэто метод оценки качества набора юнит-тестов. В исходный код программы намеренно вносят мелкие ошибки (мутации) вроде замены плюса на минус. Затем запускают тесты: если тесты «поймали» изменение и упали, значит, они работают хорошо. Если тесты прошли успешно, значит, код проверяется плохо.

У меня тут наконец-то дошли руки попробовать это (спасибо стриму Кости Доронина) и вот делюсь впечатлениями.

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

976 0 33 6 17

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

2.8k 1 52 86 30

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?

3k 2 72 14 50

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

4k 2 69 18 25

инсайт который пришёл мне этой ночью, пока я жёг токены

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

попросите codex использовать tool read_thread.
если вы раннее видели как codex читает чужие треды, то вы наверняка знаете, что это за tool – он позволяет кодексу читать соседние треды.

но вчера до меня дошло, что его можно просить читать и свой тред тоже.

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

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

вы уже знали про такой лайфхак?

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

6.1k 5 173 18 77

вот такое вот "горе от ума" получается с 5.6 поколением gpt

мы долго жаловались на посредственное качество кода и решений, но выходит, что чтобы получит офигенное качество, нужно сделать космолёт))

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

4.2k 2 41 17 30

DEKSDEN notes dan repost
⚪️ Текущие впечатления от поколения 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


Подборка постов моего канала

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

а вы используете китайцев? какие модели посоветуете?

3.9k 0 55 117 39

я тут недавно стартовал исследование зрелости ai coding в компаниях. результатов пока не много, но вот что заинтересовало.

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

мне стало интересно: как у вас выглядит такая инфраструктура и какие задачи с помощью нее выполняются? как она реализована? это один единый api backend к которому подключаются агенты по api/mcp получают/мутируют данные?
как у вас выглядят агенты?

гоу хвастаться в комментах! 👇


friendly reminder для тех, кто планировал приобрести курс.

старт уже скоро – в следующий понедельник, 10 августа.

первый групповой созвон будет 11 августа, во вторник.

если вы откладывали покупку курса, то лучше это сделать сегодня!


Video oldindan ko‘rish uchun mavjud emas
Telegram'da ko‘rish
Вы не раз говорили про ответственность разработчика, код ревью, что это важно при работе с агентами.

Но ничего не говорили про само качество кода, безопасность.

Ощущение, что качество решения, паттерны разработки уходят на второй план, а в первую очередь главное доставить фичи, это так?


Вот такой вопрос был после моего выступления.
Ответ на видео

А вы уже применяете такие подходы?

#performance@the_ai_architect

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

4.5k 1 25 41 24

В AI индустрии всё меняется каждый месяц

В чатах по AI время от времени вижу от новичков запрос: "посоветуйте курс по AI". В ответ, народ часто говорит, что нормальных курсов сейчас нет, потому что сейчас всё быстро меняется в индустрии и быстро становится неактуальным, так что, мол, зря потратите деньги!

Я с этим не согласен и не просто потому что я сам продаю курс по AI Coding 🙂

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

Это как в школе – если в 6 классе вы прогуляли умножение/деление, то дальше будет тяжело, потому что весь остальной материал отстраивается от этих знаний.

И скипнуть эти знания не получится никак.

Так и в курсах по AI (в том числе у меня 🙄).

Без знаний о том, как работает контекст, attention, feedback loop, вам будет тяжело.

Вы не сможете собрать новый, свой, фреймворк Plan & Act или модифицировать мой.

Не сможете собрать эффективный skill для реализации code review.

Да, вроде бы, понимание, как работает LLM (не уходя в математику) это не rocket science, но вот что ещё полезного есть обычно в курсах (ну, у меня точно, я же практик) – это практический опыт автора.

Я работаю с LLM с конца 2022 года и за это время успел попробовать много разных инструментов и подходов. Успел набить шишки и набраться опыта, чтобы смочь вам подсказать:

• "фрактальные промпты" это какой то буллщит
• использование XML в промптах в актуальных SotA моделях не даст вам никаких преимуществ
• промпты вы можете писать как на русском, так и на английском, французском, монгольском, китайском или хинди – выбирайте любой, на котором вам удобнее излагать свои мысли. Современная SotA LLM любой язык поймёт, а экономить на спичках (токенах) не считаю нужным.

И вот такие инсайты удобнее всего слушать и смотреть с дополнительным контекстом вокруг этих инсайтов – с понятными примерами, картинками, схемами.

Курсы, обычно, призваны экономить ваше время.

За деньги вы покупаете возможность не тратить на это всё месяца хождения кругами, получаете структурированную информацию и правильный путь по изучению AI Coding.

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

4.8k 0 12 32 62



Исследование практики AI Coding в компаниях

Последний раз такое исследование я проводил более полугода назад, с тех пор прошло много времени и многое поменялось. Так что стало интересно провести такое исследование опять.

• Вы "чемпион" по AI Coding в вашей компании или новичок? А ваши коллеги?
• Какими достижениями можете похвастаться? А что бесит больше всего?
• Ваша компания поддерживает развитие? Или ставит палки в колёса?

Пройдите опрос и помогите понять реальное положение дел в компаниях (в РФ и зарубежных).

А спустя время я обязательно поделюсь результатами здесь у себя на канале

Пройти опрос

И не забудьте репостнуть этот опрос вашим друзьям, чтобы у нас получилось собрать ещё больше информации.

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

20 ta oxirgi post ko‘rsatilgan.