Авторский канал.
Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь через ЛС канала | Визитка: timurkhakhalev.t.me
Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь через ЛС канала | Визитка: timurkhakhalev.t.me
Я знаю, как вы любите skills, так что вот вам ещё один для аудита css!
Суть: с помощью этого skill, агент делает аудит css и дает список того, что нужно исправить, чтобы было хорошо!
npx skills@latest add vojtaholik/good-cssСайт: good-css.com
Лайк, репост,
1. Блин, ИИ делает мою работу лучше меня
2. Software engineering мёртв, разработчики не нужны!
3. Теперь я могу вайбкодить сколько угодно slop!
4. Ой, что-то не идёт. Fable/Sol/Opus — всё полный отстой
5. А что, если ограничить агента? Надеть на него поводок?
6. О, результаты уже вполне приличные. Как копнуть глубже?
7. Заказывает 12 книг по разработке на Ozon
8. Software engineering жив! Я сверну горы!
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
2. Software engineering мёртв, разработчики не нужны!
3. Теперь я могу вайбкодить сколько угодно slop!
4. Ой, что-то не идёт. Fable/Sol/Opus — всё полный отстой
5. А что, если ограничить агента? Надеть на него поводок?
6. О, результаты уже вполне приличные. Как копнуть глубже?
7. Заказывает 12 книг по разработке на Ozon
8. Software engineering жив! Я сверну горы!
Лайк, репост,
1. Memory bank даёт 80% результата при 20% затратах.
1) Что хранить в memory bank?
Храните ту информацию, которую сложно или невозможно было бы добыть из кода – C4, infra, детали имплементации, бизнес процессы, user stories и т. д.
2) Как хранить?
Можно прям в репозитории создать папку .memory-bank и разложить там по папочкам и файликам
Потратьте пару часов на то, чтобы привести документацию вашего проекта в порядок. После этого, в каждом новом чате у агента будет хорошая структура вашего проекта.
Ему не нужно будет долго ковырять и грепать ваш проект.
2. Попробуйте ASD-STE100
Это контролируемый вариант английского языка, разработанный для написания технической документации. Он основан на ограниченном словаре (около 900-1000 слов) и наборе правил, которые делают тексты однозначными и понятными. Изначально стандарт был разработан для авиационной промышленности. (Статья на хабре)
Помогает делать инструкции более однозначными и писать сразу в нужном контексте.
Достаточно просто попросить LLM использовать этот стандарт при написании документации.
Лайк, репост,
Продолжение про мою версию OpenWhispr
Пока переписывал код с JS на TS, из репо openwhispr ко мне перекочевал github action 'pr-quality' – оно на каждый пуш в гитхаб запускает джобу, которая прогоняет все тесты и аудиты по всему репо. Полезно, но дорого.
В итоге, за несколько дней у меня впервые в жизни закончилась квота Github Actions. Отключил запуск тестов в gh actions и решил запускать их локально.
В один момент столкнулся с тем, что мак раскалился как сковородка, так что проишлось попросить codex сократить количество параллельных тестов и продолжил работать.
Спустя время заметил, что тесты занимают чудовищно много времени на один запуск - минут 17. А z.ai glm 5.3 flash, который переписывал код, любил запускать полный набор тестов после каждой мелочи!
Терпение кончилось и решил вместе с кодексом оптимизировать эти тесты.
Вот самые интересные чекпоинты того, как это происходило:
было 17:18 мин → стало 12:25 мин
- добавили кеш модулей для swift кода: 162 с → 4,6 с
- фальшивый ONNX worker не отвечал на завершение, поэтому 5 сценариев ждали настоящий таймаут: 25 → около 0,1 с.
- убрали лишнюю работу в двух проверках TypeScript-контрактов: 48 → 10,6 с.
- в тестах миграции настроек перестали после каждого сценария перезагружать весь граф Vite. Две дорогие группы сократились примерно с 30,6 до 4,3 с и с 17 до 3,9 с.
12:25 мин → 5:03 мин
- перенастроили запуск тестов - разделение по доменам, типам и условиям
- запуск тестов в два потока
- убрали проверки кода, который больше не используется.
- тесты, проверявшие скопированную в них логику, заменили проверками настоящего кода приложения.
- 57 проверок TypeScript-контрактов объединили в один запуск компилятора, вместо повторной компиляции для каждого файла.
- переиспользование запущенного vite server
Было 5:03 мин → стало 1:06 мин
- профилирование показало, что мы запускали с низким приоритетом не только тесты, но и сборку с компилятором. Раньше так пытались снизить нагрузку на Mac.
- убрали низкий приоритет: одна и та же сборка сократилась с 21,45 с до 2,90 с. Ограничение в два тестовых процесса сохранили.
- убрали ещё один лишний пятсекундный таймер и повторную подготовку нескольких тестов.
- полный прогон занял 60,43 с
Вывод такой – быстрая итерация для эффективной разработки очень сильно важна. И без агентов я бы скорее всего забил бы на эту оптимизацию, потому что это отняло бы у меня точно несколько рабочих дней
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Пока переписывал код с JS на TS, из репо openwhispr ко мне перекочевал github action 'pr-quality' – оно на каждый пуш в гитхаб запускает джобу, которая прогоняет все тесты и аудиты по всему репо. Полезно, но дорого.
В итоге, за несколько дней у меня впервые в жизни закончилась квота Github Actions. Отключил запуск тестов в gh actions и решил запускать их локально.
В один момент столкнулся с тем, что мак раскалился как сковородка, так что проишлось попросить codex сократить количество параллельных тестов и продолжил работать.
Спустя время заметил, что тесты занимают чудовищно много времени на один запуск - минут 17. А z.ai glm 5.3 flash, который переписывал код, любил запускать полный набор тестов после каждой мелочи!
Терпение кончилось и решил вместе с кодексом оптимизировать эти тесты.
Вот самые интересные чекпоинты того, как это происходило:
было 17:18 мин → стало 12:25 мин
- добавили кеш модулей для swift кода: 162 с → 4,6 с
- фальшивый ONNX worker не отвечал на завершение, поэтому 5 сценариев ждали настоящий таймаут: 25 → около 0,1 с.
- убрали лишнюю работу в двух проверках TypeScript-контрактов: 48 → 10,6 с.
- в тестах миграции настроек перестали после каждого сценария перезагружать весь граф Vite. Две дорогие группы сократились примерно с 30,6 до 4,3 с и с 17 до 3,9 с.
12:25 мин → 5:03 мин
- перенастроили запуск тестов - разделение по доменам, типам и условиям
- запуск тестов в два потока
- убрали проверки кода, который больше не используется.
- тесты, проверявшие скопированную в них логику, заменили проверками настоящего кода приложения.
- 57 проверок TypeScript-контрактов объединили в один запуск компилятора, вместо повторной компиляции для каждого файла.
- переиспользование запущенного vite server
Было 5:03 мин → стало 1:06 мин
- профилирование показало, что мы запускали с низким приоритетом не только тесты, но и сборку с компилятором. Раньше так пытались снизить нагрузку на Mac.
- убрали низкий приоритет: одна и та же сборка сократилась с 21,45 с до 2,90 с. Ограничение в два тестовых процесса сохранили.
- убрали ещё один лишний пятсекундный таймер и повторную подготовку нескольких тестов.
- полный прогон занял 60,43 с
Вывод такой – быстрая итерация для эффективной разработки очень сильно важна. И без агентов я бы скорее всего забил бы на эту оптимизацию, потому что это отняло бы у меня точно несколько рабочих дней
Лайк, репост,
Ребята добавили стату в Codex, вот мои данные.
Мне оч нравится GPT 6 Astra, но стоит очень дорого!
Поэтому, я стараюсь использовать её для диагностики проблем и аналитики, а имплементацию делаю с GPT 6 Sol. По reasoning – Astra работаем в основном в Low reasoning и этого хватает в 90% случаев, а Sol крутится на Medium - High.
Помимо Codex, я ещё использую z.ai GLM-5.3-Flash через opencode в bb. Тоже довольно хорошая рабочая моделька для несложных задач.
Недавно взял подписку Claude за $20 чтоб потестировать Opus 5.5 на задачах дизайна – пока что это лучшее, что вообще существует для дизайна. Экономит очень сильно времени чтобы получить желаемый результат с первого раза.
А у вас как?
Лайк, репост,
Когнитивное искажение в мире AI
Многие ошибочно считают, что любой учебный материал по AI устаревает через несколько недель после выхода.
Расскажу, как появилось это когнитивное искажение.
1. Примерно в 2023, когда AI стал хайповать, появился промпт-инжиниринг – в самом начале это были особенные заклинания, которые позволяли выдавать из тогдашних llm полезный импакт.
2. Каждый месяц-два, с выходом очередной llm, эти заклинания менялись.
3. В это же время выходило много книг и даже DVD-дисков в которых авторы рассказывали какие заклинания для каких ситуаций лучше использовать.
4. Многие подметили факт, что за период с начала написания книги и до старта продаж, эти заклинания успевали устареть.
5. У людей в головах закрепилась мысль, что в мире AI всё настолько быстро меняется, что нет смысла покупать какие-то книги, курсы или другие обучающие материалы – инфа там всё равно уже давно неактуальна.
6. В итоге, появляется "куриная слепота" на любые учебные материалы.
И что не так?
Нужно понимать различие между "сборником заклинаний" и материалами с фундаментальными знаниями.
Сегодня мы активно используем тот фундамент, который "был открыт" для нас в 2024-25 годах – tools, context, agents и т. д.
Ничего из этого не устарело. Всё это, либо стало основой для новых решений, либо вдохновением, либо используется как есть и по сей день.
Всё новое это хорошо забытое старое, а креативность – это компиляция существующих идей.
Я полистал книгу AI Engineering: Building Applications with Foundation Models, Chip Huyen которая вышла в 2025 году и вижу, что она в целом до сих пор актуальна.
Существует ли хоть один человек, который прочитал эту книгу в 2025 и жалеет об этом сейчас? Я в это не верю.
Я думаю, что он наоборот рад тому, что раньше смог познакомиться с фундаментальным устройством мира AI и раньше смог получать больше бенефитов от AI.
Так что если вы сомневались в своих знаниях об устройстве AI, но всегда отвергали идею почитать книги или другие материалы – рекомендую пересмотреть своё мнение :)
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Многие ошибочно считают, что любой учебный материал по AI устаревает через несколько недель после выхода.
Расскажу, как появилось это когнитивное искажение.
1. Примерно в 2023, когда AI стал хайповать, появился промпт-инжиниринг – в самом начале это были особенные заклинания, которые позволяли выдавать из тогдашних llm полезный импакт.
2. Каждый месяц-два, с выходом очередной llm, эти заклинания менялись.
3. В это же время выходило много книг и даже DVD-дисков в которых авторы рассказывали какие заклинания для каких ситуаций лучше использовать.
4. Многие подметили факт, что за период с начала написания книги и до старта продаж, эти заклинания успевали устареть.
5. У людей в головах закрепилась мысль, что в мире AI всё настолько быстро меняется, что нет смысла покупать какие-то книги, курсы или другие обучающие материалы – инфа там всё равно уже давно неактуальна.
6. В итоге, появляется "куриная слепота" на любые учебные материалы.
И что не так?
Нужно понимать различие между "сборником заклинаний" и материалами с фундаментальными знаниями.
Сегодня мы активно используем тот фундамент, который "был открыт" для нас в 2024-25 годах – tools, context, agents и т. д.
Ничего из этого не устарело. Всё это, либо стало основой для новых решений, либо вдохновением, либо используется как есть и по сей день.
Всё новое это хорошо забытое старое, а креативность – это компиляция существующих идей.
Я полистал книгу AI Engineering: Building Applications with Foundation Models, Chip Huyen которая вышла в 2025 году и вижу, что она в целом до сих пор актуальна.
Существует ли хоть один человек, который прочитал эту книгу в 2025 и жалеет об этом сейчас? Я в это не верю.
Я думаю, что он наоборот рад тому, что раньше смог познакомиться с фундаментальным устройством мира AI и раньше смог получать больше бенефитов от AI.
Так что если вы сомневались в своих знаниях об устройстве AI, но всегда отвергали идею почитать книги или другие материалы – рекомендую пересмотреть своё мнение :)
Лайк, репост,
Интересные инсайты по skills
Тут недавно на Hacker News появился тред с вопросом "Как вы менеджите ваши skills".
Почитал весь тред и решил выписать интересные на мой взгляд инсайты и добавить немного от себя.
Skill – это кэш рабочего процесса: "как уже делали эту задачу". Должен отвечать на вопрос "как сделать X".
1. Когда skill действительно нужен
- нужно хранить то, чего нет в обучающих данных модели:
- внутренние сервисы;
- нестандартные конфигурации;
- инфраструктуру и связи между репозиториями;
- правила доступа к окружениям.
- принятые в команде гайдлайны
- один и тот же процесс повторяется несколько раз в день или в неделю;
- процесс должен выполняться одним и тем же способом;
например:
- нужно не забывать тесты, документацию, ревью или другие обязательные шаги;
- нужно выполнять compliance-проверку;
- часто требуется один и тот же способ работы с Jira, Git, CI, инфраструктурой или браузером;
При этом, если действие можно выразить обычным кодом, лучше выразить его кодом. Модели оставить принятие решений и задачи, которые трудно формализовать.
2. Как создавать skills
- не начинать с поиска готовых skills.
- сначала попросить агента выполнить задачу.
- попросить агента упаковать процесс выполнения задачи в skill. Тут рекомендую использовать skill-creator от Anthropic – там есть evals для проверки skill.
- попробовать skill в новом чате
3. Улучшение skill
- после каждой сессии со скиллом анализировать, что можно вынести в skill;
- собирать статистику повторяющихся рабочих процессов для создания новых скиллов;
- просить другой frontier-моделью уменьшить и упростить текст skill.
- проводить ежемесячный аудит неиспользуемых skills;
4. Безопасность
- Рассматривать каждый skill как код, которому агент доверяет.
- Проверять происхождение и содержимое.
- Не устанавливать случайные skills из интернета без ревью.
В комментах добавьте ваши инсайты по скиллам!
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Тут недавно на Hacker News появился тред с вопросом "Как вы менеджите ваши skills".
Почитал весь тред и решил выписать интересные на мой взгляд инсайты и добавить немного от себя.
Skill – это кэш рабочего процесса: "как уже делали эту задачу". Должен отвечать на вопрос "как сделать X".
1. Когда skill действительно нужен
- нужно хранить то, чего нет в обучающих данных модели:
- внутренние сервисы;
- нестандартные конфигурации;
- инфраструктуру и связи между репозиториями;
- правила доступа к окружениям.
- принятые в команде гайдлайны
- один и тот же процесс повторяется несколько раз в день или в неделю;
- процесс должен выполняться одним и тем же способом;
например:
- нужно не забывать тесты, документацию, ревью или другие обязательные шаги;
- нужно выполнять compliance-проверку;
- часто требуется один и тот же способ работы с Jira, Git, CI, инфраструктурой или браузером;
При этом, если действие можно выразить обычным кодом, лучше выразить его кодом. Модели оставить принятие решений и задачи, которые трудно формализовать.
2. Как создавать skills
- не начинать с поиска готовых skills.
- сначала попросить агента выполнить задачу.
- попросить агента упаковать процесс выполнения задачи в skill. Тут рекомендую использовать skill-creator от Anthropic – там есть evals для проверки skill.
- попробовать skill в новом чате
3. Улучшение skill
- после каждой сессии со скиллом анализировать, что можно вынести в skill;
- собирать статистику повторяющихся рабочих процессов для создания новых скиллов;
- просить другой frontier-моделью уменьшить и упростить текст skill.
- проводить ежемесячный аудит неиспользуемых skills;
4. Безопасность
- Рассматривать каждый skill как код, которому агент доверяет.
- Проверять происхождение и содержимое.
- Не устанавливать случайные skills из интернета без ревью.
В комментах добавьте ваши инсайты по скиллам!
Лайк, репост,
Вы знали, что смена reasoning effort дропает кэш в ваших coding agents?
А с astra / fable дела обстоят по-другому.
Серёга Нотевский, мой коллега, разобрал этот вопросик в посте, рекомендую почитать, особенно, если вы собираете кастомный харнесс.
Кстати, Сергей собрал skill, который делает аудит вашего prompt caching по всем best practices и подсказывает, что стоит улучшить. Я рекомендую попробовать, если вы собираете приложения с LLM под капотом.
Anthropic, кстати, тоже рекомендуют – они дали Серёге 6 месяцев максимальной подписки на Claude Code за этот skill))
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
А с astra / fable дела обстоят по-другому.
Серёга Нотевский, мой коллега, разобрал этот вопросик в посте, рекомендую почитать, особенно, если вы собираете кастомный харнесс.
Кстати, Сергей собрал skill, который делает аудит вашего prompt caching по всем best practices и подсказывает, что стоит улучшить. Я рекомендую попробовать, если вы собираете приложения с LLM под капотом.
Anthropic, кстати, тоже рекомендуют – они дали Серёге 6 месяцев максимальной подписки на Claude Code за этот skill))
Лайк, репост,
Зачем SDLC нужен рядовому разработчику?
Проблема того, что немногие знают SDLC, в том, что этот термин в основном использовался техническими менеджерами, т. к. именно они отвечают за настройку процессов в командах.
С AI агентами у нас меняется уровень абстракции и теперь процессами, которыми управляли тех. менеджеры, должны управлять разработчики.
Зачем он нужен разработчику?
1. Расширение кругозора.
Тут мы помним, что в век AI, стало полезнее знать о существовании какой то практики, чем быть экспертом в этой практике. Ведь часть экспертности (поверхностной) можно получить от AI, либо от специалиста в этом ( консультация/исполнение)
2. Личный рост.
Сейчас в мире происходят ИИ-трансформации (и будут длиться еще несколько лет) и всегда будет полезен человек, который будет вести эту трансформацию внутри команды/компании, потому что он будет знать внутреннюю кухню. А значит может помочь закрыть цели руководству и, в свою очередь, может получить хорошую прибавку к ЗП или должность.
А если в своей компании таких бенефитов не ожидается, то можно найти компанию, где к этому относятся серьезнее.
А ещё можно попробовать сделать свой продукт и с понимание SDLC это будет проще. Хотя, одним пониманием SDLC тут не ограничивается.
Чего потребуется от разработчика?
Переход к AI SDLC обычно предполагает, что разраб начинает расти вширь (не в буквальном смысле), должен уметь и на дуде играть и быть швецом и жнецом.
Это означает, что нужна экспертность в одной области и базовые знания в смежных областях.
Помимо этого, нужно ещё знать базу вокруг разработки:
- computer science
- сети
- архитектуру веб приложений
- git, docker
- ci/cd
- и другие базовые термины.
А, и ещё тут очень важно уметь отследить и диагностировать проблему.
К моему удивлению, не все разработчики это всё знают. Я для себя это объясняю тем, что большинство работает на одних и тех же проектах в одних и тех же ролях годами. А знания вширь развиваются тогда, когда разработчику даются разнообразные задачи около своего стека.
Как только разработчик получает эти знания, процесс разработки сильно меняется и становится надёжнее.
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Проблема того, что немногие знают SDLC, в том, что этот термин в основном использовался техническими менеджерами, т. к. именно они отвечают за настройку процессов в командах.
С AI агентами у нас меняется уровень абстракции и теперь процессами, которыми управляли тех. менеджеры, должны управлять разработчики.
Зачем он нужен разработчику?
1. Расширение кругозора.
Тут мы помним, что в век AI, стало полезнее знать о существовании какой то практики, чем быть экспертом в этой практике. Ведь часть экспертности (поверхностной) можно получить от AI, либо от специалиста в этом ( консультация/исполнение)
2. Личный рост.
Сейчас в мире происходят ИИ-трансформации (и будут длиться еще несколько лет) и всегда будет полезен человек, который будет вести эту трансформацию внутри команды/компании, потому что он будет знать внутреннюю кухню. А значит может помочь закрыть цели руководству и, в свою очередь, может получить хорошую прибавку к ЗП или должность.
А если в своей компании таких бенефитов не ожидается, то можно найти компанию, где к этому относятся серьезнее.
А ещё можно попробовать сделать свой продукт и с понимание SDLC это будет проще. Хотя, одним пониманием SDLC тут не ограничивается.
Чего потребуется от разработчика?
Переход к AI SDLC обычно предполагает, что разраб начинает расти вширь (не в буквальном смысле), должен уметь и на дуде играть и быть швецом и жнецом.
Это означает, что нужна экспертность в одной области и базовые знания в смежных областях.
Помимо этого, нужно ещё знать базу вокруг разработки:
- computer science
- сети
- архитектуру веб приложений
- git, docker
- ci/cd
- и другие базовые термины.
А, и ещё тут очень важно уметь отследить и диагностировать проблему.
К моему удивлению, не все разработчики это всё знают. Я для себя это объясняю тем, что большинство работает на одних и тех же проектах в одних и тех же ролях годами. А знания вширь развиваются тогда, когда разработчику даются разнообразные задачи около своего стека.
Как только разработчик получает эти знания, процесс разработки сильно меняется и становится надёжнее.
Лайк, репост,
AI Agentic SDLC Roadmap
Я уже рассказал зачем нужен agentic SDLC, как он может выглядеть и следующая очевидная часть - что изучить, чтобы смочь в этот agentic SDLC.
Я думал, как лучше это подать и решил, что формат родмап подойдёт лучше всего.
Он отвечает на вопрос: по какой дорожке я бы пошёл, если бы сейчас, в сентябре 2026, начинал изучение разработки с AI агентами с нуля.
В процессе работы над родмапом ещё выяснил, что есть большое количество людей, которые изучали (тут скорее подойдет слово "пробовали") это всё самостоятельно и находятся сейчас на среднем уровне, потому что есть пробелы в знаниях и нет системы.
и вот такой родмап появился - https://ai.khakhalev.com/roadmap/.
это мое виденье пути, который разработчики должен пройти, чтобы:
- умело орудовать ai агентами
- повысить свой throughput задач в единицу времени
- уметь быстро разбираться во всех новинках которые выходят каждую неделю
roadmap можно скопировать в .md формате и дать вашему чатгпт, чтобы он составил список ресурсов которые можно было бы изучить.
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Я уже рассказал зачем нужен agentic SDLC, как он может выглядеть и следующая очевидная часть - что изучить, чтобы смочь в этот agentic SDLC.
Я думал, как лучше это подать и решил, что формат родмап подойдёт лучше всего.
Он отвечает на вопрос: по какой дорожке я бы пошёл, если бы сейчас, в сентябре 2026, начинал изучение разработки с AI агентами с нуля.
В процессе работы над родмапом ещё выяснил, что есть большое количество людей, которые изучали (тут скорее подойдет слово "пробовали") это всё самостоятельно и находятся сейчас на среднем уровне, потому что есть пробелы в знаниях и нет системы.
и вот такой родмап появился - https://ai.khakhalev.com/roadmap/.
это мое виденье пути, который разработчики должен пройти, чтобы:
- умело орудовать ai агентами
- повысить свой throughput задач в единицу времени
- уметь быстро разбираться во всех новинках которые выходят каждую неделю
roadmap можно скопировать в .md формате и дать вашему чатгпт, чтобы он составил список ресурсов которые можно было бы изучить.
Лайк, репост,
Meeting Summary
В конце поста попрошу у вас предложить хороший open source meeting summary app.
Предыстория
Для записи встреч, до недавнего времени, я пользовался Granola и мне всё нравилось – ты просто подключаешься на звонок, у тебя на экране всплывает подсказка с предложением запустить запись и оно просто работает. По окончанию ты получаешь summary и можешь чатиться с этим звонком. Ещё большой плюс – ты записываешь созвон со своей стороны, просто с системного аудио и своего микрофона. Никого не нужно смущать каким-то ботом, который сидит у вас на созвоне. Платишь за это примерно $15 в месяц.
Но дьявол кроется в деталях.
1. Меня удручает отсутствие возможности забрать исходники аудиозаписи. На случай если запись была транскрибирована не точно я мог бы еще раз ее транскрибировать вручную
2. На прошлой неделе произошел случай - я сидел на созвоне с макбука, на обычном wifi в кафешке. Потом мне понадобилось поехать домой, я переключился на personal hotspot на айфоне, переключил квн и поехал по городу. Всё это время я находился на созвоне и отваливался наверное секунд на 5-10. Я был уверен, что в этом нет никакой проблемы.
Приехал домой, созвон уже закончился, открыл гранолу чтобы выцепить action items и обнаружил, что оно записало только мою речь в последние 20 мин звонка, но не речь собеседника! А моя речь там состояла из "угу, да, согласен".
Ну и в комбинации с первым минусом я остался ни с чем, пришлось (да-да) по памяти восстанавливать разговор 😅.
Короче, решил, что платить за такое $15 в месяц я точно не буду и пора сваливать в OSS мир.
Так что реквестирую у вас хороший опенсорсный meeting summary продукт.
Что хотелось бы:
- в первую очередь это запись созвона путем снятия данных с моего микрофона и system audio
- транскрибация, диаризация (не обязательно в риалтайме), создание саммари после созвона, возможность задавать вопросы
- всевозможные комбинации подключения моделей - я пока что не хочу использовать on prem модели на моем маке, хотелось бы cloud модели, но возможно передумаю
- интеграция с календарем
- соответственно, доступ к audio исходникам, транскрипциям; категории созвонов, лейблы участников и всё такое
- возможность кастомайзинга
Я смотрел openwhispr и anarlog в качестве базы
1. У первого какой то ппц в репо - там намешан rust+ts+js причем есть js файлы по 15к строк – я такое расширять (кастомить) не хочу
2. У второго 9.5к коммитов, 1 гб весом весь репо, там хранятся блоб файлы, но и без этого кода там тоже оч много навалено – для меня это тоже сильный показатель плохой инженерной культуры и не хочется брать в свой апп кучу слопа
Вопрос – чем опенсорсным вы пользуетесь и что можете посоветовать?
Мне нравится подход pi.dev в мире ai agents – это такие lego блоки из которых можно составлять любые конструкции и вот в meeting summary apps хотелось бы найти похожее.
В конце поста попрошу у вас предложить хороший open source meeting summary app.
Предыстория
Для записи встреч, до недавнего времени, я пользовался Granola и мне всё нравилось – ты просто подключаешься на звонок, у тебя на экране всплывает подсказка с предложением запустить запись и оно просто работает. По окончанию ты получаешь summary и можешь чатиться с этим звонком. Ещё большой плюс – ты записываешь созвон со своей стороны, просто с системного аудио и своего микрофона. Никого не нужно смущать каким-то ботом, который сидит у вас на созвоне. Платишь за это примерно $15 в месяц.
Но дьявол кроется в деталях.
1. Меня удручает отсутствие возможности забрать исходники аудиозаписи. На случай если запись была транскрибирована не точно я мог бы еще раз ее транскрибировать вручную
2. На прошлой неделе произошел случай - я сидел на созвоне с макбука, на обычном wifi в кафешке. Потом мне понадобилось поехать домой, я переключился на personal hotspot на айфоне, переключил квн и поехал по городу. Всё это время я находился на созвоне и отваливался наверное секунд на 5-10. Я был уверен, что в этом нет никакой проблемы.
Приехал домой, созвон уже закончился, открыл гранолу чтобы выцепить action items и обнаружил, что оно записало только мою речь в последние 20 мин звонка, но не речь собеседника! А моя речь там состояла из "угу, да, согласен".
Ну и в комбинации с первым минусом я остался ни с чем, пришлось (да-да) по памяти восстанавливать разговор 😅.
Короче, решил, что платить за такое $15 в месяц я точно не буду и пора сваливать в OSS мир.
Так что реквестирую у вас хороший опенсорсный meeting summary продукт.
Что хотелось бы:
- в первую очередь это запись созвона путем снятия данных с моего микрофона и system audio
- транскрибация, диаризация (не обязательно в риалтайме), создание саммари после созвона, возможность задавать вопросы
- всевозможные комбинации подключения моделей - я пока что не хочу использовать on prem модели на моем маке, хотелось бы cloud модели, но возможно передумаю
- интеграция с календарем
- соответственно, доступ к audio исходникам, транскрипциям; категории созвонов, лейблы участников и всё такое
- возможность кастомайзинга
Я смотрел openwhispr и anarlog в качестве базы
1. У первого какой то ппц в репо - там намешан rust+ts+js причем есть js файлы по 15к строк – я такое расширять (кастомить) не хочу
2. У второго 9.5к коммитов, 1 гб весом весь репо, там хранятся блоб файлы, но и без этого кода там тоже оч много навалено – для меня это тоже сильный показатель плохой инженерной культуры и не хочется брать в свой апп кучу слопа
Вопрос – чем опенсорсным вы пользуетесь и что можете посоветовать?
Мне нравится подход pi.dev в мире ai agents – это такие lego блоки из которых можно составлять любые конструкции и вот в meeting summary apps хотелось бы найти похожее.
К концу рабочего дня у вас появляется ощущение что вы ничего серьёзного не сделали за день?
Или это только у меня такое?
У меня такое ощущение появляется особенно когда за день я особо не кодил, но работал с документами – создание/модификация, рисерчи.
Подсознательно как будто бы ты привыкаешь к тому, что когда ты каждый день когда пишешь код, даже с ИИшкой, ты видишь объем навайбкоженных файлов с кодом или вмерженные PR.
Но когда ты работаешь с документами, то к концу дня обычно у тебя появляется, скажем, 1-2 документа, и внутреннее чувство появляется такое, что как будто бы, ну блин, ну создал ты эти документы, ну и чего? Но ведь серьёзной работы никакой не было проведено! Пруфов то немного!
При этом, головой ты понимаешь, что блин, ты же работал целый день и к концу дня устал. У тебя уже голова стала квадратной.
У кого-то такое встречается? Если да, как вы решаете такую проблему?
Я пока что решаю так – навайбкодил тул, который анализирует созданные сессии с агентами за день и подводит итоги дня/недели и тем самым показывает, какой ты красавчик.
Или это только у меня такое?
У меня такое ощущение появляется особенно когда за день я особо не кодил, но работал с документами – создание/модификация, рисерчи.
Подсознательно как будто бы ты привыкаешь к тому, что когда ты каждый день когда пишешь код, даже с ИИшкой, ты видишь объем навайбкоженных файлов с кодом или вмерженные PR.
Но когда ты работаешь с документами, то к концу дня обычно у тебя появляется, скажем, 1-2 документа, и внутреннее чувство появляется такое, что как будто бы, ну блин, ну создал ты эти документы, ну и чего? Но ведь серьёзной работы никакой не было проведено! Пруфов то немного!
При этом, головой ты понимаешь, что блин, ты же работал целый день и к концу дня устал. У тебя уже голова стала квадратной.
У кого-то такое встречается? Если да, как вы решаете такую проблему?
Я пока что решаю так – навайбкодил тул, который анализирует созданные сессии с агентами за день и подводит итоги дня/недели и тем самым показывает, какой ты красавчик.
ответ на фото – это feedback loop.
Нарочно не придумаешь… MacBook использует свою веб-камеру, чтобы смотреть на экран в зеркальном отображении и улучшить поддержку чипов AMD Radeon в Omarchy.
Лайк, репост,
Как должен выглядеть Agentic SDLC
Продолжение темы с прошлого поста. В комментах был запрос на объяснение AI SDLC, так что рассказываю.
Для начала, стоит сказать, что Agentic SDLC, AI SDLC, agentic software development, agentic driven development – это всё одно и тоже. Про использование AI в разработке софта.
Кстати, тут Anthropic несколько недель назад выпустили статью про AI-native SDLC, которая по факту является рекламой и шоукейсом для их продуктов, но общее понимание сути трансформации она даёт, так что рекомендую полистать буклет.
Из чего состоит цикл SDLC?
Тут стоит упомянуть, что вообще, ещё существует цикл Product Development Life Cycle (PDLC). И SDLC – это всего лишь одно звено этого цикла – Implement.
Мы все с вами уже это выучили, но я ещё раз проговорю: если мы просто ускорим генерацию кода и оставим остальные этапы неизменными, то от нагрузки офигеют все. Для нас, разрабов, самый понятный пример – это сильно увеличившееся количество PR reviews, которые необходимо провести. Многие из нас сталкиваются с выжиганием мозга к концу дня, если пытаться ревьюить сгенеренный код :)
Поэтому, правильно будет ускорять не только генерацию кода, но и всю разработку. Ниже опишу, как это обычно работало до AI и как это должно работать с AI.
И так, на вход в SDLC поступает задача от бизнеса и она проходит обычно следующие стадии:
1. Analysis & Research — понять, что именно нужно изменить
Классика: аналитик и разработчик уточняли задачу у бизнеса, изучали код и документацию, выясняли ограничения, зависимости и edge cases.
Agentic: агент исследует репозиторий, документацию и историю изменений, находит пробелы в постановке. Человек отвечает на вопросы о бизнесе и проверяет требования и критерии приёмки.
2. Solution Design — решить, как изменить систему
Классика: разработчик, техлид или архитектор выбирали решение: какие компоненты, API и данные менять, нужны ли миграции, какие компромиссы допустимы.
Agentic: агент предлагает варианты с учётом архитектуры проекта, разбирает трейд-оффы. Человек корректирует направление дизайна. Агент оформляет выбранное решение в draft плана. Независимые агенты проверяют его на пропуски и противоречия, человек принимает ключевые инженерные решения.
3. Implementation Planning — превратить решение в исполняемый план
Классика: разработчики и техлид разбивали решение на задачи, определяли зависимости, порядок работы, исполнителей и способы проверки.
Agentic: агент готовит окончательный план из черновика, декомпозирует его на milestones с критериями приёмки и тестами. Человек проверяет критические места.
4. Implementation — выполнить план
Классика: код, тесты (вряд ли), документацию (очень вряд ли) разработчики писали код.
Agentic: код, тесты, документацию пишут агенты по плану. Майлстоун за майлстоуном. Прогоняются все возможные детерминированные тесты.
5. Verification & Integration — проверить корректность и объединить изменения
Классика: разработчики проводили code review и объединяли ветки, QA проверяли сценарии и регрессии. Тесты и CI давали автоматическую обратную связь.
Agentic: агенты проводят независимеы ревью вдоль и поперёк PR. Проблемы возвращаются на исправление. Человек разбирает критичные места и принимает результат, когда всё остальное уже отработало.
6. Release & Deployment — довести изменение до production
Классика: разработчик или DevOps/SRE выпускал изменение через CI/CD, следил за миграциями и состоянием приложения, восстанавливал систему при сбое.
Agentic: CI/CD выполняет выпуск, агент помогает человеку проверять готовность, результаты деплоя и работу исходного сценария.
7. Maintenance & Evolution — поддерживать и развивать систему
Классика: разработчики и SRE разбирали инциденты, исправляли баги, обновляли зависимости, занимались техдолгом и документацией.
Agentic: агент реагирует на алерты системы; исследует проблемы по данным мониторинга; проводит регулярные аудиты по кодовой базе. Человек выбирает приоритеты и проверяет основания для изменений. Подтверждённые задачи запускают новый цикл SDLC.
---
Если у вас сейчас разработка с агентами работает не так, то нужно что-то менять :) Потому что только так можно добиться снижения TTM, cost per unit и повышения throughput боевых единиц.
Тут конечно стоит добавить что у каждой компании набор этих звеньев, их название, исполняющие роли – свои.
А сложность этого процесса сейчас заключается в том, чтобы правильно переложить обязанности по ролям - чтобы и людей просто так не уволить и в тоже время чтобы не было такого, что вся работа QA с AI агентами заключается в том, что он берет ТЗшку для разраба и отправляет ее в кодекс со словами "возьми ветку от разраба, вот этот ТЗ и выпиши чо он там пропустил и не выполнил". Такая работа сейчас заменяется даже не скиллом, а одним .md блоком из 10-15 строчек в этом скилле :)
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Продолжение темы с прошлого поста. В комментах был запрос на объяснение AI SDLC, так что рассказываю.
Для начала, стоит сказать, что Agentic SDLC, AI SDLC, agentic software development, agentic driven development – это всё одно и тоже. Про использование AI в разработке софта.
Кстати, тут Anthropic несколько недель назад выпустили статью про AI-native SDLC, которая по факту является рекламой и шоукейсом для их продуктов, но общее понимание сути трансформации она даёт, так что рекомендую полистать буклет.
Из чего состоит цикл SDLC?
Тут стоит упомянуть, что вообще, ещё существует цикл Product Development Life Cycle (PDLC). И SDLC – это всего лишь одно звено этого цикла – Implement.
Мы все с вами уже это выучили, но я ещё раз проговорю: если мы просто ускорим генерацию кода и оставим остальные этапы неизменными, то от нагрузки офигеют все. Для нас, разрабов, самый понятный пример – это сильно увеличившееся количество PR reviews, которые необходимо провести. Многие из нас сталкиваются с выжиганием мозга к концу дня, если пытаться ревьюить сгенеренный код :)
Поэтому, правильно будет ускорять не только генерацию кода, но и всю разработку. Ниже опишу, как это обычно работало до AI и как это должно работать с AI.
И так, на вход в SDLC поступает задача от бизнеса и она проходит обычно следующие стадии:
1. Analysis & Research — понять, что именно нужно изменить
Классика: аналитик и разработчик уточняли задачу у бизнеса, изучали код и документацию, выясняли ограничения, зависимости и edge cases.
Agentic: агент исследует репозиторий, документацию и историю изменений, находит пробелы в постановке. Человек отвечает на вопросы о бизнесе и проверяет требования и критерии приёмки.
2. Solution Design — решить, как изменить систему
Классика: разработчик, техлид или архитектор выбирали решение: какие компоненты, API и данные менять, нужны ли миграции, какие компромиссы допустимы.
Agentic: агент предлагает варианты с учётом архитектуры проекта, разбирает трейд-оффы. Человек корректирует направление дизайна. Агент оформляет выбранное решение в draft плана. Независимые агенты проверяют его на пропуски и противоречия, человек принимает ключевые инженерные решения.
3. Implementation Planning — превратить решение в исполняемый план
Классика: разработчики и техлид разбивали решение на задачи, определяли зависимости, порядок работы, исполнителей и способы проверки.
Agentic: агент готовит окончательный план из черновика, декомпозирует его на milestones с критериями приёмки и тестами. Человек проверяет критические места.
4. Implementation — выполнить план
Классика: код, тесты (вряд ли), документацию (очень вряд ли) разработчики писали код.
Agentic: код, тесты, документацию пишут агенты по плану. Майлстоун за майлстоуном. Прогоняются все возможные детерминированные тесты.
5. Verification & Integration — проверить корректность и объединить изменения
Классика: разработчики проводили code review и объединяли ветки, QA проверяли сценарии и регрессии. Тесты и CI давали автоматическую обратную связь.
Agentic: агенты проводят независимеы ревью вдоль и поперёк PR. Проблемы возвращаются на исправление. Человек разбирает критичные места и принимает результат, когда всё остальное уже отработало.
6. Release & Deployment — довести изменение до production
Классика: разработчик или DevOps/SRE выпускал изменение через CI/CD, следил за миграциями и состоянием приложения, восстанавливал систему при сбое.
Agentic: CI/CD выполняет выпуск, агент помогает человеку проверять готовность, результаты деплоя и работу исходного сценария.
7. Maintenance & Evolution — поддерживать и развивать систему
Классика: разработчики и SRE разбирали инциденты, исправляли баги, обновляли зависимости, занимались техдолгом и документацией.
Agentic: агент реагирует на алерты системы; исследует проблемы по данным мониторинга; проводит регулярные аудиты по кодовой базе. Человек выбирает приоритеты и проверяет основания для изменений. Подтверждённые задачи запускают новый цикл SDLC.
---
Если у вас сейчас разработка с агентами работает не так, то нужно что-то менять :) Потому что только так можно добиться снижения TTM, cost per unit и повышения throughput боевых единиц.
Тут конечно стоит добавить что у каждой компании набор этих звеньев, их название, исполняющие роли – свои.
А сложность этого процесса сейчас заключается в том, чтобы правильно переложить обязанности по ролям - чтобы и людей просто так не уволить и в тоже время чтобы не было такого, что вся работа QA с AI агентами заключается в том, что он берет ТЗшку для разраба и отправляет ее в кодекс со словами "возьми ветку от разраба, вот этот ТЗ и выпиши чо он там пропустил и не выполнил". Такая работа сейчас заменяется даже не скиллом, а одним .md блоком из 10-15 строчек в этом скилле :)
Лайк, репост,
Очередной скандал с Anthropic
Чуваки из Anthropic увидели вчерашний скандал вокруг OpenAI и сказали: подержите моё пиво. Мы в этой теме главные и никто не может посягать на наше первенство в не-сухих-штанах.
Сегодня ночью по МСК появляется серия твитов от Jacob Coxon, pretraining researcher, Anthropic.
Jacob утверждает, что он уволился из Anthropic (а раннее и из OpenAI), потому что ему надоело, что компании бегут напрямую к self-improving superintellegence и ставят жизни их сотрудников на кон.
Тред набрал уже более 30M просмотров (что на мою память ОЧЕНЬ много). А больше всех набрал твит о том, что люди, которые делают AI, искренне верят, что он может убить всех нас до конца этого десятилетия. Многие руководители в прессе подбирают слова так, чтобы звучать аккуратно, но в приватных разговорах виден их страх.
Подробнее:
Тред репостнул Evan Hubinger и подтвердил, что Jacob прав – AI действительно может убить всех человеков. Вероятность что это произойдет в течение ближайших 4-х лет более 10%:
(прошу обратить внимание на восклицание)
Да, кстати, Evan – Alignment Science Lead и как никто другой разбирается в том, что говорит.
Что происходит?
Тут два варианта:
1) Эти ребята действительно искренны в своих словах и мир в опасности
2) Впереди IPO, на котором Anthropic нужно продаться как можно дороже, а Dario Amodei доказать, что он круче своего бывшего начальника.
И пока что я больше склоняюсь ко второму варианту.
Я помню, как всю весну компания Anthropic очень некрасиво прогревала людей и совала свои руки очень глубоко в души людей, чтобы вызывать чувство страха, когда пиарила Mythos, и по факту эта модель не оказалась чем-то сверхестественным.
До этого Dario Amodei утверждал, что скоро всех разработчиков уволят за ненадобностью.
Короче, мы уже привыкли к такой риторике Anthropic и у многих людей появляются вопросики к ней и недоверие + омерзение к самой компании.
Я про это планирую ещё пост написать – почему все так не любят Anthropic, чтобы потом можно было кидать его любому, кто задается таким вопросом.
Лайк, репост,
✔ ️ Тимур Хахалев про AI Coding, подписывайтесь!
Чуваки из Anthropic увидели вчерашний скандал вокруг OpenAI и сказали: подержите моё пиво. Мы в этой теме главные и никто не может посягать на наше первенство в не-сухих-штанах.
Сегодня ночью по МСК появляется серия твитов от Jacob Coxon, pretraining researcher, Anthropic.
Jacob утверждает, что он уволился из Anthropic (а раннее и из OpenAI), потому что ему надоело, что компании бегут напрямую к self-improving superintellegence и ставят жизни их сотрудников на кон.
Тред набрал уже более 30M просмотров (что на мою память ОЧЕНЬ много). А больше всех набрал твит о том, что люди, которые делают AI, искренне верят, что он может убить всех нас до конца этого десятилетия. Многие руководители в прессе подбирают слова так, чтобы звучать аккуратно, но в приватных разговорах виден их страх.
Подробнее:
Я сегодня уволился из Anthropic. Последние три года я занимался исследованиями предобучения (pretraining) в OpenAI и Anthropic. Ни одна из этих компаний не действует ответственно. Они гонят напрямую к самоулучшающемуся сверхразуму и ставят на кон наши жизни. Подробнее ниже.
Не недооценивайте силу этой технологии. Скоро это будут системы, превосходящие человека: способные взломать что угодно, за ночь перевернуть любую область и получить реальную власть и ресурсы. Мы все видели прогресс в каждом из этих направлений, и он не замедляется.
Люди, создающие ИИ, искренне верят, что он может убить всех нас до конца десятилетия. Это не маркетинговый трюк. Наоборот: многие руководители и старшие исследователи в прессе подбирают слова так, чтобы звучать осмотрительно, — но я слышал, как те же люди выражают страх в частных разговорах. Никакая другая человеческая деятельность не несёт такой опасности.
Частый ответ: «если они правда в это верят, почему продолжают создавать?» В OpenAI многие так и не осознали в глубине, что на кону вся цивилизация. В Anthropic ставки прекрасно понимают, но там застряли в гонке — дойти первым: они считают, что никто другой не будет действовать ответственно, значит, это придётся сделать им самим, несмотря на риск.
Принять эту гонку и войти в «эндшпиль» — высокомерная авантюра, которую не запускают из слака частной компании. «Спидранить» выравнивание (alignment) ИИ можно только при исключительной уверенности, что лучших траекторий не существует.
Я оптимист насчёт координации. Тревожные сигналы вроде атаки на Hugging Face сделали реальные соглашения о темпе между американскими лабораториями более достижимыми. Но я не вижу, что мы на пути к предотвращению глобальной гонки — а для этого могут понадобиться дорогие меры, например временный запрет на наращивание возможностей моделей.
Если ты исследователь в лаборатории — я прошу тебя подумать, какими будут следующие несколько лет на самом деле. Хочешь запустить обучение сверхразумного агента (RL-ран), не имея строгого понимания того, как устроен его разум? Стоит ли опускать голову, потому что «это всё равно случится», — или использовать этот момент, чтобы потребовать других условий?
Тред репостнул Evan Hubinger и подтвердил, что Jacob прав – AI действительно может убить всех человеков. Вероятность что это произойдет в течение ближайших 4-х лет более 10%:
Jacob is correct here—we really do earnestly believe AI could kill all humans!
(прошу обратить внимание на восклицание)
Да, кстати, Evan – Alignment Science Lead и как никто другой разбирается в том, что говорит.
Что происходит?
Тут два варианта:
1) Эти ребята действительно искренны в своих словах и мир в опасности
2) Впереди IPO, на котором Anthropic нужно продаться как можно дороже, а Dario Amodei доказать, что он круче своего бывшего начальника.
И пока что я больше склоняюсь ко второму варианту.
Я помню, как всю весну компания Anthropic очень некрасиво прогревала людей и совала свои руки очень глубоко в души людей, чтобы вызывать чувство страха, когда пиарила Mythos, и по факту эта модель не оказалась чем-то сверхестественным.
До этого Dario Amodei утверждал, что скоро всех разработчиков уволят за ненадобностью.
Короче, мы уже привыкли к такой риторике Anthropic и у многих людей появляются вопросики к ней и недоверие + омерзение к самой компании.
Я про это планирую ещё пост написать – почему все так не любят Anthropic, чтобы потом можно было кидать его любому, кто задается таким вопросом.
Лайк, репост,
