Так все таки мышление письмом или печатанием, или...?
Я обещал рассказать о результатах моего "аналогового" мышления письмом примерно два месяца назад.
🤔 TLDR; Феноменальных преимуществ вообще нет!
Но как так то? Я решил немного углубиться. Не все так печально.
Записывая своими словами (не тупо переписывание!) по ходу изучения руководства по Рациональной Работе я естественным образом начал двигаться медленнее – слепая печать на клавиатуре намного быстрее чем писать от руки, по крайне мере в моем случае.
Важнее то, что я вообще не заметил качественных инсайтов – руководство разрывало мне мозги одинаково.
Потому что в нем используются рабочие техники обучения, о которых я написал чуть ниже.
Получается что результат скоре отрицательный – я замедлился в прохождении материалов многократно.
Итак! Главное просто писать свои мысли, мыслить письмом. Но как учиться еще лучше? Так чтобы прям мозги пухли от интеллекта?✏️
В аналоговых заметках все еще есть смысл, во-первых – посмотрите какой у меня офигительный блокнот из Австрии!
А во-вторых и без шуток – письмо от руки все таки активирует намного больше мозговых соединений в сравнении с довольно минимальной активностью при печатании (Frontiers in Psychology, 2023). Только дело не в активности, в смысле кол-в вспышек во время фиксирования информации на носителях.
К сожалению много учебных заведений (в СНГ уж точно) до сих пор заставляют тупо переписывать тексты. В ВУЗах кажется чт с этим чуть получше – там могут лекции читать очень быстро, и придется как то сокращать, у спевать. Но это не мышление письмо а стресс. Так что...
И ручка и клавиатура меркнут в сравнении с главными инсайтами из Learning Science, качественно обучать свою нейросеть в голове! А именно:
- Повторение через интервалы
- Активное воспроизведение из памяти (то есть не только сразу мыслим письмом, а попытаемся через какое то время без подглядок что-то припомнить и выразить в тексте)
- И чередование тем
Ровно то как составлены руководства, и то как я буду любое свое обучение по темам планировать дальше!
Ручка все еще круто работает как минимум для отдыха от экрана, брейнштормов, коротких и важных заметок, может быть планировании, прототипировании и других тезисных размылений.
Для глубокой проработки концепций и ворочания текстами — точно typing + spaced repetition в цифровом экзокортексе. Слишком много всего надо загружать в голову, фронтир очень быстро меняется, а отставать совершено неприемлемо.
Доп. источники почитать на выходные:
- Mueller & Oppenheimer 2014
- Nature Reviews Psychology 2022
Я обещал рассказать о результатах моего "аналогового" мышления письмом примерно два месяца назад.
Но как так то? Я решил немного углубиться. Не все так печально.
Записывая своими словами (не тупо переписывание!) по ходу изучения руководства по Рациональной Работе я естественным образом начал двигаться медленнее – слепая печать на клавиатуре намного быстрее чем писать от руки, по крайне мере в моем случае.
Важнее то, что я вообще не заметил качественных инсайтов – руководство разрывало мне мозги одинаково.
Получается что результат скоре отрицательный – я замедлился в прохождении материалов многократно.
Итак! Главное просто писать свои мысли, мыслить письмом. Но как учиться еще лучше? Так чтобы прям мозги пухли от интеллекта?
В аналоговых заметках все еще есть смысл, во-первых – посмотрите какой у меня офигительный блокнот из Австрии!
А во-вторых и без шуток – письмо от руки все таки активирует намного больше мозговых соединений в сравнении с довольно минимальной активностью при печатании (Frontiers in Psychology, 2023). Только дело не в активности, в смысле кол-в вспышек во время фиксирования информации на носителях.
К сожалению много учебных заведений (в СНГ уж точно) до сих пор заставляют тупо переписывать тексты. В ВУЗах кажется чт с этим чуть получше – там могут лекции читать очень быстро, и придется как то сокращать, у спевать. Но это не мышление письмо а стресс. Так что...
И ручка и клавиатура меркнут в сравнении с главными инсайтами из Learning Science, качественно обучать свою нейросеть в голове! А именно:
- Повторение через интервалы
- Активное воспроизведение из памяти (то есть не только сразу мыслим письмом, а попытаемся через какое то время без подглядок что-то припомнить и выразить в тексте)
- И чередование тем
Ровно то как составлены руководства, и то как я буду любое свое обучение по темам планировать дальше!
Ручка все еще круто работает как минимум для отдыха от экрана, брейнштормов, коротких и важных заметок, может быть планировании, прототипировании и других тезисных размылений.
Для глубокой проработки концепций и ворочания текстами — точно typing + spaced repetition в цифровом экзокортексе. Слишком много всего надо загружать в голову, фронтир очень быстро меняется, а отставать совершено неприемлемо.
Доп. источники почитать на выходные:
- Mueller & Oppenheimer 2014
- Nature Reviews Psychology 2022
Please open Telegram to view this post
VIEW IN TELEGRAM
AWS очень большая и сложная система. Я совершенно не удивлен в том что ребята настолько активно применяют формальные методы. Ну как иначе то делать и продавать 999999999? 😎
Скорее меня удивило встретить эту статью среди прочего низкосортного в одной рассылке:
https://cacm.acm.org/practice/systems-correctness-practices-at-amazon-web-services/
Там про то, как TLA+ оказался когнитивно слишком тяжелым, и AWS сделали свой язык P (у меня как то были знакомые которые на серьезных щах верили в то что под капотом весь AWS только на Питоне, Си и баше написан). Интересно что P теперь помогает не только на этапе просто дизайна спек, но и в продакшене через PObserve - они сгребают логи систем и проверяют что они соответствуют спекам!
И еще очень круто про continuous подход в фаззинг и хаос тестировании. При том последнее довольно агрессивное, сильнее чем я думал. Кроме того что AWS сам себя постоянно пытается сломать, у них есть Fault Injection Service который позволяет нам как клиентам в свою инфру запускать разных агрессивных обезьян🤬
Радует еще то что отдельно говорят о том что грустно это – низкая популярность формальных методов в индустрии из за сложности в понимании / обучению, но тут есть большие надежды на AI. Пока, правда, только надежды.
В статье больше подробностей в приближении и примеров, читайте!
Скорее меня удивило встретить эту статью среди прочего низкосортного в одной рассылке:
https://cacm.acm.org/practice/systems-correctness-practices-at-amazon-web-services/
Там про то, как TLA+ оказался когнитивно слишком тяжелым, и AWS сделали свой язык P (у меня как то были знакомые которые на серьезных щах верили в то что под капотом весь AWS только на Питоне, Си и баше написан). Интересно что P теперь помогает не только на этапе просто дизайна спек, но и в продакшене через PObserve - они сгребают логи систем и проверяют что они соответствуют спекам!
И еще очень круто про continuous подход в фаззинг и хаос тестировании. При том последнее довольно агрессивное, сильнее чем я думал. Кроме того что AWS сам себя постоянно пытается сломать, у них есть Fault Injection Service который позволяет нам как клиентам в свою инфру запускать разных агрессивных обезьян
Радует еще то что отдельно говорят о том что грустно это – низкая популярность формальных методов в индустрии из за сложности в понимании / обучению, но тут есть большие надежды на AI. Пока, правда, только надежды.
В статье больше подробностей в приближении и примеров, читайте!
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭2
Правила созданы для того, чтобы их нарушать, слышали такое?
Не менее актуально это звучит в эпоху AI, скорее наоборот.
У кого-то одна только мысль о нарушении правил может вызвать сильное бурление из-за несостыковки представлений – “правила нарушать нельзя!!!”
На эту тему можно спекулировать слишком широко, но сегодня нас интересуют именно формальности в организации работы и ее методов. Это про всех – живых и неживых агентов.
Беда в том, что сам мой посыл уже ошибочен.
Пусть даже мы определим контекст еще более конкретным, например — организация работы в команде, которая разрабатывает AI-продукт.
Тут все еще недостаточно приближения для формализации. Ибо работа неотрывно связана с агентом, который ее выполняет, и его ролью.
Помимо функционального рассмотрения роли нас интересуют и другие «штуки». Например, какие у роли интересы и предпочтения? Что ей важно для работы, а что нет? Есть ли в ее методах работы опасность (нужно учесть все риски), и многое другое в зависимости от прикладной области.
Игра в онтологическое моделирование сложна, из простого в ней только одно — если начинаем играть, то играть надо хоть сколько-нибудь по-взрослому, в нескольких размерностях. Иначе ерунда.
Нахватавшись и напихав в головы несколько представлений, методов из популярных учебников, будь то Agile, DevOps или любых других модных и хороших практик, без детального объяснения того что мы делаем, как делаем, зачем, и кто и что именно должен делать, почему именно эти методы выбраны в компании, мы поедем… я не знаю куда, ну… куда-то! В лучшем случае это движение наощупь, в худшем – вообще непонятно куда.
Многих такая масштабность и сложность онтологического моделирования пугает — “Ууууух, блин, это сколько надо подумать и продумать! Да и вообще это вот щас гестапо правил будет, кошмар бюрократический, нам бы погибше да попроще быть”.
В смысле гибкости и сложности – все наоборот.
Любые формальные описания методов работы неизбежно подвергаются изменениям при всего лишь паре условий: • Есть кто-то (роль, агент) кто должен следить за исполнением методов и собирать метрики • Целью всего моделирования было не само моделирование, а благородная направленность на изменение качества и эффективности работы – применяем что намоделировалось.
Все это очень гибко и бурно меняется на начальных этапах, когда модель сырая и было собрано слишком мало фидбека от агентов-исполнителей — естественно, мы заинтересованы (должны быть) как можно быстрее нашу модель сделать удобной и понятной для всех. Иначе какой вообще смысл?
Понятность и прикладная применимость, полезность модели характеризуется ее разделяемостью — имеется в виду, что модель понятна и полезна разным агентам в разных ролях.
Ничего, кроме взрослого моделирования методов работы (особенно когда в процессы интегрируется AI – им так же детально нужно на символьных описаниях объяснять что делать и как), не даст нам настоящего буста в эффективности, скорости доставки и всего желанного прочего.
Верить, что можно затыкать дыры “гениями которые сами разберутся”, просто некорректно, потому что каждый такой “гений” все равно говорит на своем языке — на языке своего семантического общества (как минимум менеджер на менеджерском, а инженер на инженерном). И тут модель предприятия, онтология и набор методичек по работе как минимум поможет им заговорить на одном языке. Это уже очень много, в смысле эффективности.
Взрослая системная инженерия, формализация процессов/методов не просто не боится нарушений формальностей — она предвосхищает их и ставит на высокий пьедестал ценности как очень нужный и важный материал, потенциал, бесценную возможность улучшить саму модель путем ее уточнения (да хоть полного переделывания, если придется), тем самым улучшая как весь жизненный цикл предприятия, так циклы отдельных кусочков, и рабочий опыт вообще.
О да, думать придется дохрена, зато какой результат!
Не менее актуально это звучит в эпоху AI, скорее наоборот.
У кого-то одна только мысль о нарушении правил может вызвать сильное бурление из-за несостыковки представлений – “правила нарушать нельзя!!!”
На эту тему можно спекулировать слишком широко, но сегодня нас интересуют именно формальности в организации работы и ее методов. Это про всех – живых и неживых агентов.
Беда в том, что сам мой посыл уже ошибочен.
Пусть даже мы определим контекст еще более конкретным, например — организация работы в команде, которая разрабатывает AI-продукт.
Тут все еще недостаточно приближения для формализации. Ибо работа неотрывно связана с агентом, который ее выполняет, и его ролью.
Помимо функционального рассмотрения роли нас интересуют и другие «штуки». Например, какие у роли интересы и предпочтения? Что ей важно для работы, а что нет? Есть ли в ее методах работы опасность (нужно учесть все риски), и многое другое в зависимости от прикладной области.
Игра в онтологическое моделирование сложна, из простого в ней только одно — если начинаем играть, то играть надо хоть сколько-нибудь по-взрослому, в нескольких размерностях. Иначе ерунда.
Нахватавшись и напихав в головы несколько представлений, методов из популярных учебников, будь то Agile, DevOps или любых других модных и хороших практик, без детального объяснения того что мы делаем, как делаем, зачем, и кто и что именно должен делать, почему именно эти методы выбраны в компании, мы поедем… я не знаю куда, ну… куда-то! В лучшем случае это движение наощупь, в худшем – вообще непонятно куда.
Многих такая масштабность и сложность онтологического моделирования пугает — “Ууууух, блин, это сколько надо подумать и продумать! Да и вообще это вот щас гестапо правил будет, кошмар бюрократический, нам бы погибше да попроще быть”.
В смысле гибкости и сложности – все наоборот.
Любые формальные описания методов работы неизбежно подвергаются изменениям при всего лишь паре условий: • Есть кто-то (роль, агент) кто должен следить за исполнением методов и собирать метрики • Целью всего моделирования было не само моделирование, а благородная направленность на изменение качества и эффективности работы – применяем что намоделировалось.
Все это очень гибко и бурно меняется на начальных этапах, когда модель сырая и было собрано слишком мало фидбека от агентов-исполнителей — естественно, мы заинтересованы (должны быть) как можно быстрее нашу модель сделать удобной и понятной для всех. Иначе какой вообще смысл?
Понятность и прикладная применимость, полезность модели характеризуется ее разделяемостью — имеется в виду, что модель понятна и полезна разным агентам в разных ролях.
Ничего, кроме взрослого моделирования методов работы (особенно когда в процессы интегрируется AI – им так же детально нужно на символьных описаниях объяснять что делать и как), не даст нам настоящего буста в эффективности, скорости доставки и всего желанного прочего.
Верить, что можно затыкать дыры “гениями которые сами разберутся”, просто некорректно, потому что каждый такой “гений” все равно говорит на своем языке — на языке своего семантического общества (как минимум менеджер на менеджерском, а инженер на инженерном). И тут модель предприятия, онтология и набор методичек по работе как минимум поможет им заговорить на одном языке. Это уже очень много, в смысле эффективности.
Взрослая системная инженерия, формализация процессов/методов не просто не боится нарушений формальностей — она предвосхищает их и ставит на высокий пьедестал ценности как очень нужный и важный материал, потенциал, бесценную возможность улучшить саму модель путем ее уточнения (да хоть полного переделывания, если придется), тем самым улучшая как весь жизненный цикл предприятия, так циклы отдельных кусочков, и рабочий опыт вообще.
О да, думать придется дохрена, зато какой результат!
AWS тут в "бесплатно попробовать" выкатило свой VSCode с Sonnet 4.0...
https://kiro.dev/
Первые впечатления – фигня фигней. Нет ничего wow или нового, чего-то что не может легковестный и обожаемый claude code.
Буквально, "spec" мод, которым Kiro бахвалится, не отличается ни чем от того, если бы вы в claude code сказали – так, милок, давай напишем PRD вот на эту идею, мучай меня вопросами по кругу пока все не станет понятно.
Только Kiro не мучает вопросами – он предсказывает блоб текста и его приходится вычитывать, и после этого задавать уже кучу вопросов - крайне не удобно.
Что там еще "отличается", да ну... Agent Hooks какие-то сделали. История о том как потратить запросы по подписке (это сейчас kiro бесплатно можно попробовать, на странице прайсинга уже представлены уровни подписок с лимитами запросов per месяц) – выбираем триггер и пишем промпт который должен выполняться...
Ну, ТАКОЕ. claude code memory или рулы в курсоре работают примерно так же – "Всегда запускай линтер/тесты и бррбрр после измненеий в коде"
Пусть cursor у меня уже больше IDE и сайдкик для claude code, даже у него "вайб лучше" чем у kiro. Мертворожденное, в общем.
¯\_(ツ)_/¯
Впрочем и claude code и cursor без нескольких mcp серверов уже тоже представить сложно, расскажу о них когда нибудь потом 🙂
https://kiro.dev/
Первые впечатления – фигня фигней. Нет ничего wow или нового, чего-то что не может легковестный и обожаемый claude code.
Буквально, "spec" мод, которым Kiro бахвалится, не отличается ни чем от того, если бы вы в claude code сказали – так, милок, давай напишем PRD вот на эту идею, мучай меня вопросами по кругу пока все не станет понятно.
Только Kiro не мучает вопросами – он предсказывает блоб текста и его приходится вычитывать, и после этого задавать уже кучу вопросов - крайне не удобно.
Что там еще "отличается", да ну... Agent Hooks какие-то сделали. История о том как потратить запросы по подписке (это сейчас kiro бесплатно можно попробовать, на странице прайсинга уже представлены уровни подписок с лимитами запросов per месяц) – выбираем триггер и пишем промпт который должен выполняться...
Ну, ТАКОЕ. claude code memory или рулы в курсоре работают примерно так же – "Всегда запускай линтер/тесты и бррбрр после измненеий в коде"
Пусть cursor у меня уже больше IDE и сайдкик для claude code, даже у него "вайб лучше" чем у kiro. Мертворожденное, в общем.
¯\_(ツ)_/¯
Kiro
Kiro is an agentic IDE that helps you go from prototype to production with spec-driven development.
Опять github only походу будет.
И снова это почти ничем не оправдать.
Как бы агентские тулы не были реализованы под капотом – разве что совсем лапшой нераспутываемой, навайбкодить интеграцию с api гитлаба это достаточно простое, быстрое и милое дело.
Продолжаем смотреть🎥
И снова это почти ничем не оправдать.
Как бы агентские тулы не были реализованы под капотом – разве что совсем лапшой нераспутываемой, навайбкодить интеграцию с api гитлаба это достаточно простое, быстрое и милое дело.
Продолжаем смотреть
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭2
Привет! Ну, с почином меня, я начинаю постить за paywall.
Отличная возможность, для всех кто хотел, начать меня поддерживать!
Первый разминочный пост про кеширвание в AI системах уже на boosty🔗
А дальше будет цикл про паттерны проектирования, подписывайтесь📝
В довесок средствами boosty вы должны получить доступ в приватный чат в телеграмм, где со мной можно пообщаться чуть плотнее чем в комментах тут, запросить посты на конкретные темы, или получить микро-консультацию.
За пейволом как обычно ссылка на мой статик блог, только не публичная.
А, и да, я снова изменил стили на сайте, теперь он выглядит лучше чем когда либо💃
Отличная возможность, для всех кто хотел, начать меня поддерживать!
Первый разминочный пост про кеширвание в AI системах уже на boosty
А дальше будет цикл про паттерны проектирования, подписывайтесь
В довесок средствами boosty вы должны получить доступ в приватный чат в телеграмм, где со мной можно пообщаться чуть плотнее чем в комментах тут, запросить посты на конкретные темы, или получить микро-консультацию.
За пейволом как обычно ссылка на мой статик блог, только не публичная.
А, и да, я снова изменил стили на сайте, теперь он выглядит лучше чем когда либо
Please open Telegram to view this post
VIEW IN TELEGRAM
boosty.to
Prompt Caching, и вообще Caching в AI Системах - Ivan Zakutnii
Обзор возможностей, технологий и эвристик кеширования. Разбираемся с 4 уровнями кеширования в AI-системах.
🌭2
Давненько не было постов, особенно не про AI а про махровую, вечную и светлую программную инженерию.
Сегодня небольшой материал про генерацию исключений, а точнее о том – почему это злющее зло.
Отправь другу который любит try/except 🙂
Сегодня небольшой материал про генерацию исключений, а точнее о том – почему это злющее зло.
Отправь другу который любит try/except 🙂
Ivanzakutnii
Генерация исключений это чистое зло
И это не шутка
GPT-5 хорошая крутая.
Cursor выпустил свой cli, который никуда не годится в сравнение с claude-code – странно "ходит" по проекту, даже не пытается его как то "индексировать" (индексирования тут в кавычках потому что claude code просто собирает факты о проекте и сохраняет под себя).
Очень сырое, cursor поторопился с релизом.
GPT-5 очень хорош в аутентичных бенчмарках, себя показал (в пузомерках там вообще фурор, но у них фурор на каждый чих).
Есть основания полагать, что в разработке оно сильнее моделей антропки, НО давайте это проверять вместе🦍
На примерe cursor-agent тулы хорошо видно, как плохая реализация может закопать все сильные стороны модели (запускал я его дефолтно, уже с gpt-5).
Это все важные новости к этому часу.
Cursor выпустил свой cli, который никуда не годится в сравнение с claude-code – странно "ходит" по проекту, даже не пытается его как то "индексировать" (индексирования тут в кавычках потому что claude code просто собирает факты о проекте и сохраняет под себя).
Очень сырое, cursor поторопился с релизом.
GPT-5 очень хорош в аутентичных бенчмарках, себя показал (в пузомерках там вообще фурор, но у них фурор на каждый чих).
Есть основания полагать, что в разработке оно сильнее моделей антропки, НО давайте это проверять вместе
На примерe cursor-agent тулы хорошо видно, как плохая реализация может закопать все сильные стороны модели (запускал я его дефолтно, уже с gpt-5).
Это все важные новости к этому часу.
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭2
100% покрытие тестами гарантирует нам:
Anonymous Poll
3%
Проверку всей проектной логики 🙂
3%
Проверку примерно 50% проектной логики 🏃♀️
95%
Само по себе покрытие не гарантирует вообще ничего 😑
🌭1
Даже если там под капотом просто LLM с условным «REPL» в Lean – это очень и очень круто! 🤓
🌭1
Forwarded from Дизраптор
Ещё одна важная новость из мира эйай:
Стартап Harmonic запустил приложение с чатботом, став первым общедоступным математическим эйай-сервисом с формальной проверкой результата. А скоро обещают и API для компаний выкатить.
Обычный* генеративный ИИ работает примерно как ребёнок, которого родители научили, что ветер дует, потому что деревья качаются, и он говорит: "ветер дует". А почему он дует? И дует ли?
Другими словами, если попросить ChatGPT или Claude расписать математическую формулу, то он её... как бы сказать... попробует угадать в формате "я зделяль". Но ответить и пояснить за свой генеративный базар не сможет. Можно ли такой формуле доверять и закладывать её в серьёзные расчёты - судите сами.
А ИИшка от Harmonic под названием "Aristotle" работает не так. Генеративный ИИ (LLM) предлагает гипотезу или часть решения и передаёт её в специальный доказательный движок, который всё проверяет с точки зрения формальной логики, аксиом, мат. определений. Алгоритмически, то бишь.
Весь процесс происходит на Lean - это такой интерактивный инструмент доказательства теорем. По сути, специальный язык программирования и формальной логики, где каждое утверждение должно быть доказано шаг за шагом, а пруф должен быть проверяем машиной.
Если движок "Аристотеля" не может верифицировать решение от LLM, то генерится другое решение. Потом его снова проверяют. И так по новой, пока проверка не будет пройдена. И лишь тогда решение выплюнется юзеру.
За счёт этого Harmonic не галлюционирует, и (по идее) его можно использовать для взрослых математических и логических задач. От академической математики до инженерии, фин. анализа и даже юридических рассуждений.
* Генеративный ИИ теперь обычный, дожили, хех😈
Дизраптор
Стартап Harmonic запустил приложение с чатботом, став первым общедоступным математическим эйай-сервисом с формальной проверкой результата. А скоро обещают и API для компаний выкатить.
Обычный* генеративный ИИ работает примерно как ребёнок, которого родители научили, что ветер дует, потому что деревья качаются, и он говорит: "ветер дует". А почему он дует? И дует ли?
Другими словами, если попросить ChatGPT или Claude расписать математическую формулу, то он её... как бы сказать... попробует угадать в формате "я зделяль". Но ответить и пояснить за свой генеративный базар не сможет. Можно ли такой формуле доверять и закладывать её в серьёзные расчёты - судите сами.
А ИИшка от Harmonic под названием "Aristotle" работает не так. Генеративный ИИ (LLM) предлагает гипотезу или часть решения и передаёт её в специальный доказательный движок, который всё проверяет с точки зрения формальной логики, аксиом, мат. определений. Алгоритмически, то бишь.
Весь процесс происходит на Lean - это такой интерактивный инструмент доказательства теорем. По сути, специальный язык программирования и формальной логики, где каждое утверждение должно быть доказано шаг за шагом, а пруф должен быть проверяем машиной.
Если движок "Аристотеля" не может верифицировать решение от LLM, то генерится другое решение. Потом его снова проверяют. И так по новой, пока проверка не будет пройдена. И лишь тогда решение выплюнется юзеру.
За счёт этого Harmonic не галлюционирует, и (по идее) его можно использовать для взрослых математических и логических задач. От академической математики до инженерии, фин. анализа и даже юридических рассуждений.
* Генеративный ИИ теперь обычный, дожили, хех
Дизраптор
Please open Telegram to view this post
VIEW IN TELEGRAM
Я пообщался с ребятами на Reddit (и не только) по поводу испытываемых ими болей при разработке AI систем.
Сами проблемы вообще не удивительно, ничего нового нет:
- Недетерминированные результаты, постоянно глючит
- Только добились нормального поведения, выходит новая SoTA модель, но с ней внезапно система работает намного хуже
- Постоянно переписывают evaluation тесты, и толка от них мало (см пункт 1)
- Ну и мое любимое – нормального агента на function-calls как они есть в API построить очень и очень сложно. Ребята пишут что максимальная точность, которой они смогли добиться, составила примерно 80%, при этом было написано более 100 eval тестов, кроме которых еще приходилось постоянно a/b тестировать руками привлекая свои семьи😨
Вишенка на торте:
Я так понял что подразумевалось удовлетворение этих самых потребностей с использованием LLM.
И вот это удивительно – коллеги одновременно не могут найти решения своим страданиям, и при этом пародаксальным образом начинают решать реальные боли клиентов проще и лучше, чем любые другие своим стартапные начинания.
На фоне этого небольшого исследования я написал пост на boosty где я раскрываю конкретную причину всех этих страданий(сама причина крайне обширная, но все еще очень конкретная) , и даю базовый но емкий чеклист вместе со ссылкой на хорошее описания SoTA паттерна разработки AI систем.
in my honest opinion этот чеклист, понимание проблемы, и упомянутая техника при должном применении решат просто огромное количество упомянутых бед🫣
***
Поделитесь тут в комментариях своими болями, самому дущераздирающему комменту отдам пост с бусти прямым линком.
Сами проблемы вообще не удивительно, ничего нового нет:
- Недетерминированные результаты, постоянно глючит
- Только добились нормального поведения, выходит новая SoTA модель, но с ней внезапно система работает намного хуже
- Постоянно переписывают evaluation тесты, и толка от них мало (см пункт 1)
- Ну и мое любимое – нормального агента на function-calls как они есть в API построить очень и очень сложно. Ребята пишут что максимальная точность, которой они смогли добиться, составила примерно 80%, при этом было написано более 100 eval тестов, кроме которых еще приходилось постоянно a/b тестировать руками привлекая свои семьи
Вишенка на торте:
"Мы так задолбались что решили вообще переключиться с попытки разрабатывать свои AI продукты на удовлетворение потребностей наших прямых клиентов"
Я так понял что подразумевалось удовлетворение этих самых потребностей с использованием LLM.
И вот это удивительно – коллеги одновременно не могут найти решения своим страданиям, и при этом пародаксальным образом начинают решать реальные боли клиентов проще и лучше, чем любые другие своим стартапные начинания.
На фоне этого небольшого исследования я написал пост на boosty где я раскрываю конкретную причину всех этих страданий
in my honest opinion этот чеклист, понимание проблемы, и упомянутая техника при должном применении решат просто огромное количество упомянутых бед
***
Поделитесь тут в комментариях своими болями, самому дущераздирающему комменту отдам пост с бусти прямым линком.
Please open Telegram to view this post
VIEW IN TELEGRAM
boosty.to
Ошибка которую допускают 99% начинающих AI Инженеров - Ivan Zakutnii
Почему в 2025 году разрабы AI систем продолжают получать больше и в найме и на фрилансе? Это же просто бек где надо дергать OpenAI API, да?
А еще вся эта история про общение с зарубежными коллегами заставила продолжать переосмысливать формат моего блога, и платной и бесплатной части. Особенно то почему я стал писать реже и неосознанно подрывать деятельность, не инвестировать в рекламу boosty.
Причин несколько.
Во-первых, очень врядли что хоть сколько нибудь большое количество людей будут платить за блог на boosty – не сколько из за отношения, сколько потому что boosty далеко не все зарубежные карты принимает, ну и там тупо неудобно читать (кто подписан на меня знает, что я просто скрытые линки раздаю там с того же самого публичного блога что живет на ivanzakutnii.com)
Во-вторых, практически все хорошие блоги живут на формате почтовых рассылок вроде substack. Я точно не знаю почему, но мне самому как читателю сабстаков просто тупо удобно получать новые посты на почту.
Ну и публиковаться я продолжаю на двух языках, и менять этого не планирую. Как минимум есть проблемы, запрос.
Кто тут сидит давно помнит короткий период жизни моего сабстака. Почему я бросил туда писать? Ну... не бросил, туда публикуются посты без пейвола💧
TL;DR – Stripe не работает в Армении, а двигаться я никуда не собираюсь 🙂
Я эту запару упоминал тут и опрашивал вас.
Чтож-делать чтож-делать? Писать на английском нужно, и продавать подписки тоже нужно везде. Мой ментор несколько месяцев назад подкинул посмотреть на ghost.org – я посмотрел и история там примерно такая же.
Это opensource платформа, но у них есть облачные тарифы, все круто и выглядит даже чуток лучше чем сабстак если бы не одно но – нормальную интеграцию ребята сделали тоже только со страйпом, и уже третий или четвертый год на всех форумах и issue где люди плачут что у них страйп в стране не работет получают в ответ – "ну вот тут у нас есть admin api, вы тут можете как нибудь двумя костыликами подпереть на вебхуках, или zapier'ом из патреона подписчиков синхронизировать"
Учитывая это, и то что хотелось бы вести блог-рассылку и на территории РФ я чуть ли не единственным выходом вижу... Напилить свою мини-платформу и платежи тоже самому интегрировать ¯\_(ツ)_/¯
mailgun + verifone пока фавориты технологий под капотом, а усилий выглядит не многим больше чем лепить костыли вокруг ghost, или еще хуже – вести несколько разных платформ и пытаться как то их синхронизировать. Я думал развиватьс boosty + patreon для остального мира но это очень странно, и теряется очень и очень ценная штука – база подписчиков, тупо список с почтовыми ящиками.
такие дела.
Причин несколько.
Во-первых, очень врядли что хоть сколько нибудь большое количество людей будут платить за блог на boosty – не сколько из за отношения, сколько потому что boosty далеко не все зарубежные карты принимает, ну и там тупо неудобно читать (кто подписан на меня знает, что я просто скрытые линки раздаю там с того же самого публичного блога что живет на ivanzakutnii.com)
Во-вторых, практически все хорошие блоги живут на формате почтовых рассылок вроде substack. Я точно не знаю почему, но мне самому как читателю сабстаков просто тупо удобно получать новые посты на почту.
Ну и публиковаться я продолжаю на двух языках, и менять этого не планирую. Как минимум есть проблемы, запрос.
Кто тут сидит давно помнит короткий период жизни моего сабстака. Почему я бросил туда писать? Ну... не бросил, туда публикуются посты без пейвола
TL;DR – Stripe не работает в Армении, а двигаться я никуда не собираюсь 🙂
Я эту запару упоминал тут и опрашивал вас.
Чтож-делать чтож-делать? Писать на английском нужно, и продавать подписки тоже нужно везде. Мой ментор несколько месяцев назад подкинул посмотреть на ghost.org – я посмотрел и история там примерно такая же.
Это opensource платформа, но у них есть облачные тарифы, все круто и выглядит даже чуток лучше чем сабстак если бы не одно но – нормальную интеграцию ребята сделали тоже только со страйпом, и уже третий или четвертый год на всех форумах и issue где люди плачут что у них страйп в стране не работет получают в ответ – "ну вот тут у нас есть admin api, вы тут можете как нибудь двумя костыликами подпереть на вебхуках, или zapier'ом из патреона подписчиков синхронизировать"
Учитывая это, и то что хотелось бы вести блог-рассылку и на территории РФ я чуть ли не единственным выходом вижу... Напилить свою мини-платформу и платежи тоже самому интегрировать ¯\_(ツ)_/¯
mailgun + verifone пока фавориты технологий под капотом, а усилий выглядит не многим больше чем лепить костыли вокруг ghost, или еще хуже – вести несколько разных платформ и пытаться как то их синхронизировать. Я думал развиватьс boosty + patreon для остального мира но это очень странно, и теряется очень и очень ценная штука – база подписчиков, тупо список с почтовыми ящиками.
такие дела.
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭2
Эта записка только для тех кто хочет сдвинуться с мертвого места.
Хотя комфорт это даже не "мертвая зона". Комфорт – это стопроцентный паралич💀
Мы находимся одновременно в ситуации где имеем:
– ограниченные ресурсы
– бесконечную бомбардировку помойной информацией вытекающей в дешевый дофамин
– кучу адекватных хотелок которые никак не реализуются (они у всех примерно одинаковые)
– кучу неадекватных хотелок которые чудесным образом реализуются, путем траты на них тех самых ограниченных ресурсов, но никак нас не подталкивают к реализации хотелок адекватных
– исчерпывающий набор когнитивных искажений, о которых часто и не подозреваем
Чо ж с этим всем делать?
Кажется что сперва надо четко определиться с тем что вообще надо, а потом маленькими шагами двигаться в сторону, в которой предположительно это самое «надо» находится.
Круто, просто, и так понятно, только мало когда делается.
На деле главное, первое что надо сделать, это признаться самому себе в саботировании всех начинаний, найти в себе разумную смелость, готовность к сложностям.
Готовность к постоянным жертвам.
Это не просто про "выйди из зоны комфорта", это про полное и безоговорочное принятие жизненной модели, в которой мы безжалостно жертвуем никчемной ерундой.
Ерундой ROI которой не просто минимален, а вообще отсутствует.
Без этого не поможет даже самый дорогой и лучший ментор.
Да, до какой то степени пинки снаружи стимулируют нас, и чем болезненне эти пинки тем лучше стимул...
Только вот без модели, без системы, без адекватной и свежей прошивки своих мозгов после консультации даже у просветленного монаха мы стремительн и радостно бежим в свое болотце.
---
Первая система которую нам надо построить, это система-терминатор всех паразитов в нашей жизни, которым мы добровольно отдаем то самое ценное что есть – время самой жизни.
Давайте пока вместе сядем и подумаем – "Где я буду через 5 лет, если ничего не изменю в модели своего поведения? Если не начну отказываться от своих деструктивных убеждений?"
Хотя комфорт это даже не "мертвая зона". Комфорт – это стопроцентный паралич
Без системы работать как надо не будет ничего.
Вообще ничего.
Мы находимся одновременно в ситуации где имеем:
– ограниченные ресурсы
– бесконечную бомбардировку помойной информацией вытекающей в дешевый дофамин
– кучу адекватных хотелок которые никак не реализуются (они у всех примерно одинаковые)
– кучу неадекватных хотелок которые чудесным образом реализуются, путем траты на них тех самых ограниченных ресурсов, но никак нас не подталкивают к реализации хотелок адекватных
– исчерпывающий набор когнитивных искажений, о которых часто и не подозреваем
Чо ж с этим всем делать?
Кажется что сперва надо четко определиться с тем что вообще надо, а потом маленькими шагами двигаться в сторону, в которой предположительно это самое «надо» находится.
Круто, просто, и так понятно, только мало когда делается.
На деле главное, первое что надо сделать, это признаться самому себе в саботировании всех начинаний, найти в себе разумную смелость, готовность к сложностям.
Готовность к постоянным жертвам.
Это не просто про "выйди из зоны комфорта", это про полное и безоговорочное принятие жизненной модели, в которой мы безжалостно жертвуем никчемной ерундой.
Ерундой ROI которой не просто минимален, а вообще отсутствует.
Без этого не поможет даже самый дорогой и лучший ментор.
Да, до какой то степени пинки снаружи стимулируют нас, и чем болезненне эти пинки тем лучше стимул...
Только вот без модели, без системы, без адекватной и свежей прошивки своих мозгов после консультации даже у просветленного монаха мы стремительн и радостно бежим в свое болотце.
---
Первая система которую нам надо построить, это система-терминатор всех паразитов в нашей жизни, которым мы добровольно отдаем то самое ценное что есть – время самой жизни.
Давайте пока вместе сядем и подумаем – "Где я буду через 5 лет, если ничего не изменю в модели своего поведения? Если не начну отказываться от своих деструктивных убеждений?"
Please open Telegram to view this post
VIEW IN TELEGRAM
Как заставить думать обоих – машину и себя самого.
В любой системе где есть хоть какой-то интеллект можно обнаружить так называемое концептуальное пространство.
Что это вообще такое и почему важно?
Совсем просто, на пальцах – прочитав сейчас вот это слово – "кресло", вы совершенно точно, однозначно представили себе какую-то штуку (скорее всего мягкую и удобную) на которую можно поместить свое тельце в сидячем положении.
А теперь – "красота", "любовь", или вот, еще лучше – "справедливость".
Про эти штуки можно с большой уверенностью сказать – сколько людей, столько и мнений. Эти идеи сильно зависят от культурных особенностей, убеждений и прочих ментальных напылений.
А важно, потому что зная про плотность смыслов можно:
- лучше проектировать AI системы
- научиться обращать свое внимание на любые "размытости"
Находя таки размытости мы получаем шанс избавиться от них.
***
Небольшое оступление:
Сильные и выразительные системы типов в языках программирования автоматически заставляют разработчика нагонять плотность в концептуальное пространство программы "наперед", во время смой разработки.
Но это история про Software 1.0, весь интеллект там был белковый, распределенный по головам людей.
Сейчас же, когда мы внедряем LLM в свои системы, по существую у нас есть одно единственное желание – пусть эта новая и умная система работает точно, отвечает на вопросы как надо и не путается! Ну... пожалуйста.
Мы берем большую модель, и как сову на глобус пытаемся натягивать ее на наш небольшой кусок мира, некоторую прикладную область.
Нет ни одной гарантии что в двух организациях, из вроде бы одной и той же прикладной области, сотрудники будут говорить на одном и том же "прикладном языке"
Как же мы тогда можем ожидать от LLM что они нас "поймут" и будут давать предсказуемый и нужный результат?
Короче говоря, нам нужен способ заставить "думать как надо" этот новый искуственный интеллект.
Нам нужен способ повысить плотность концептуального пространства.
Почему не работает подход "просто засунь все в контекст" я уже писал например здесь, где в заключении призывал думать прежде чем делать, приводя в пример короткий список заземляющих вопросов.
Но это все очень смешно и размыто. Легко сказать "думай давай", делать то что?
Если вы внедряете AI я предлагаю, нет, я настаиваю что вам нужно в обязательном порядке ознакомиться со Schema Guided Reasoning и попробовать применить в своих проектах.
Ринат Абдуллин формализатор и амбассадор SGR, на русском много полезного прочитать по теме и пообщаться с ним вы можете в его канале.
***
Другого надежного способа заставить LLM думать так как нам нужно сейчас попросту нет.
Structured Output сам по себе работает лучше любой другой техники промт инжиниринга просто потому что мы получаем возможность физически загнать результат работы модели в рамки и типы описанные в JSON схеме.
При этом, конечно же, не отбирая у нас системный промпт как источник дополнительного контекста.
А еще разрабатывая AI системы через SGR призму мы автоматически заставляем самих себя болььше и детальнее думать "наперед" про домен задачи, важные сущности нашей системы, важные знания, которые могут потребоваться для LLM при решении поставленных задач.
Мы именно что моделируем процесс мышления с помощью этой штуки. И это замечательно – превращать нечеткие требования в надежно работающие системы.
Если вы искали хороший материал про Context Engineering о котором сейчас пишет каждый первый AI журналист – вы наконец его прочитали.
В любой системе где есть хоть какой-то интеллект можно обнаружить так называемое концептуальное пространство.
Что это вообще такое и почему важно?
Совсем просто, на пальцах – прочитав сейчас вот это слово – "кресло", вы совершенно точно, однозначно представили себе какую-то штуку (скорее всего мягкую и удобную) на которую можно поместить свое тельце в сидячем положении.
А теперь – "красота", "любовь", или вот, еще лучше – "справедливость".
Про эти штуки можно с большой уверенностью сказать – сколько людей, столько и мнений. Эти идеи сильно зависят от культурных особенностей, убеждений и прочих ментальных напылений.
А важно, потому что зная про плотность смыслов можно:
- лучше проектировать AI системы
- научиться обращать свое внимание на любые "размытости"
Находя таки размытости мы получаем шанс избавиться от них.
***
Небольшое оступление:
Сильные и выразительные системы типов в языках программирования автоматически заставляют разработчика нагонять плотность в концептуальное пространство программы "наперед", во время смой разработки.
Но это история про Software 1.0, весь интеллект там был белковый, распределенный по головам людей.
Сейчас же, когда мы внедряем LLM в свои системы, по существую у нас есть одно единственное желание – пусть эта новая и умная система работает точно, отвечает на вопросы как надо и не путается! Ну... пожалуйста.
Мы берем большую модель, и как сову на глобус пытаемся натягивать ее на наш небольшой кусок мира, некоторую прикладную область.
Нет ни одной гарантии что в двух организациях, из вроде бы одной и той же прикладной области, сотрудники будут говорить на одном и том же "прикладном языке"
Как же мы тогда можем ожидать от LLM что они нас "поймут" и будут давать предсказуемый и нужный результат?
Короче говоря, нам нужен способ заставить "думать как надо" этот новый искуственный интеллект.
Нам нужен способ повысить плотность концептуального пространства.
Почему не работает подход "просто засунь все в контекст" я уже писал например здесь, где в заключении призывал думать прежде чем делать, приводя в пример короткий список заземляющих вопросов.
Но это все очень смешно и размыто. Легко сказать "думай давай", делать то что?
Если вы внедряете AI я предлагаю, нет, я настаиваю что вам нужно в обязательном порядке ознакомиться со Schema Guided Reasoning и попробовать применить в своих проектах.
Ринат Абдуллин формализатор и амбассадор SGR, на русском много полезного прочитать по теме и пообщаться с ним вы можете в его канале.
***
Другого надежного способа заставить LLM думать так как нам нужно сейчас попросту нет.
Возможно когда то у нас будут квантовые супер-компьютеры на которых мы сможем в день тысячи раз обучать, модели с сотнями миллиардов параметров, но это все таки пока еще далекий sci-fi
Structured Output сам по себе работает лучше любой другой техники промт инжиниринга просто потому что мы получаем возможность физически загнать результат работы модели в рамки и типы описанные в JSON схеме.
При этом, конечно же, не отбирая у нас системный промпт как источник дополнительного контекста.
А еще разрабатывая AI системы через SGR призму мы автоматически заставляем самих себя болььше и детальнее думать "наперед" про домен задачи, важные сущности нашей системы, важные знания, которые могут потребоваться для LLM при решении поставленных задач.
Мы именно что моделируем процесс мышления с помощью этой штуки. И это замечательно – превращать нечеткие требования в надежно работающие системы.
Если вы искали хороший материал про Context Engineering о котором сейчас пишет каждый первый AI журналист – вы наконец его прочитали.
Значит, Эмбеддинги.
Вчера у меня в гостях был мой замечательный дружище, который сейчас работает в одной махровой компании – у них там всякие интеграции аккаунтингов, онлайн магазины и так далее.
Ну, говорю же – махровая😊
Зашел долгий разговор про эмбеддинги, начиная с "а что с ними вообще можно сделать?"
Я весь разговор пересказывать не буду, но TLDR такой – никакие эмбеддинги им там не нужны, и старое решение работает более чем замечательно.
На сам вопрос "что сделать то можно", я много и рассказать не смог, потому что со страхом и ненавистью RAG все понятно, а остальные кейсы хоть и крайне специфичные, но с разной скоростью всегда сваливаются в "насколько X похоже на Y"😯
Мы сначала подумали что можно было-бы сделать улучшенный поиск товаров, но в итоге оказалось что улучшать попросту нечего – там сейчас очень и очень шустро поиск работает на redis c redis-search плагином.
---
Но вообще хороший пример некоторого более общего применения эмбеддингов это идея библиотеки semantic-router.
Я уже неоднократно ее использовал для того чтобы собирать пайпланы с высоким требованием к точности "выбора". При том выбирать то можно почти что угодно :)
Например RAG источники, правильное под-системы (агент, если хотитите. Основная идея либы), или даже выборать функций для вызовов.
Последнее получается много лучше чем нативные function-calls, как минимум потому что можно добиться большей степени детерминированности и в смысле конечного результата, и в смысле работы самой системы если строим pipeline/workflow без всяких графов.
Самое классное что есть под капотом у semantic-router это fastembed – быстрая векторная rust молотилка, работающая на ONNX. Оно легкое и более чем сносно работает без GPU.
В общем если вам правда надо в эмбеддинги – рекомендую сразу смотреть на fastembed.
А на счет "правда" и "надо" напишу позже отдельно📝
Вчера у меня в гостях был мой замечательный дружище, который сейчас работает в одной махровой компании – у них там всякие интеграции аккаунтингов, онлайн магазины и так далее.
Ну, говорю же – махровая
Зашел долгий разговор про эмбеддинги, начиная с "а что с ними вообще можно сделать?"
Я весь разговор пересказывать не буду, но TLDR такой – никакие эмбеддинги им там не нужны, и старое решение работает более чем замечательно.
На сам вопрос "что сделать то можно", я много и рассказать не смог, потому что со страхом и ненавистью RAG все понятно, а остальные кейсы хоть и крайне специфичные, но с разной скоростью всегда сваливаются в "насколько X похоже на Y"
Мы сначала подумали что можно было-бы сделать улучшенный поиск товаров, но в итоге оказалось что улучшать попросту нечего – там сейчас очень и очень шустро поиск работает на redis c redis-search плагином.
---
Но вообще хороший пример некоторого более общего применения эмбеддингов это идея библиотеки semantic-router.
Я уже неоднократно ее использовал для того чтобы собирать пайпланы с высоким требованием к точности "выбора". При том выбирать то можно почти что угодно :)
Например RAG источники, правильное под-системы (агент, если хотитите. Основная идея либы), или даже выборать функций для вызовов.
Последнее получается много лучше чем нативные function-calls, как минимум потому что можно добиться большей степени детерминированности и в смысле конечного результата, и в смысле работы самой системы если строим pipeline/workflow без всяких графов.
На дворе 2025 год а loop-like LLM агенты до сих пор в бесконечные циклы проваливаются.
Самое классное что есть под капотом у semantic-router это fastembed – быстрая векторная rust молотилка, работающая на ONNX. Оно легкое и более чем сносно работает без GPU.
В общем если вам правда надо в эмбеддинги – рекомендую сразу смотреть на fastembed.
А на счет "правда" и "надо" напишу позже отдельно
Please open Telegram to view this post
VIEW IN TELEGRAM
Значит, вайбкодинг.
За последний год с хвостиком мой голос по поводу вайбкодинга принимал совершенно разные значения на шкале от "Боже, это просто омерзительно" до "Боже, это просто восхитительно".
А в какой-то момент я на эту тему просто замолчал. Просто потому что естественным образом использование LLM-based ассистентов и прочего в большей части моей деятельности стало практически неотъемлемым.
Сейчас пишу об этом, потому что вчера меня спросили – "Слушай, а какое у тебя соотношение написанного кода к сгенерированному?"
И я впал в ступор, натурально. Потому что:
- Кода генерируется много, процентов 80% как минимум
- Кода генерируется мало (в смысле бойлерплейт мусора, об этом дальше)
- 90% сгенерированного кода вычитывается настолько внимательно, насколько это возможно
- Все что нужно исправить – исправляется либо вручную (если мало), либо в точечных последующих промптах
При этом я знаю людей которые генерируют 100% прод кода с телефона и живут припеваючи.
***
Интересно то, насколько сильно отличается сгенерированный код у разных людей в смысле качества, стиля, и вообще функционально; Не знаю обращали ли вы на это внимание.
Точнее как, у не очень опытных в программной инженерии человеков как раз таки получается примерно одинаковый результат, его достаточно просто распознать как "LLM-blob":
- Решения – странные, неуместные;
- Избыточные комментарии там где они не нужны, или полное отсутствие комментариев в откровенно переусложненном коде;
- Использование паттернов, которые нигде в проекте больше не живут без какого либо архитектурного оправдания;
- и так далее.
А кидать такие вот шмоты мертвого кода друг другу на code-review это не менее чем производственное преступление.
***
Мне нравится шутливо называть LLM поломанным хорадрическим кубом.
Если вы играли в Diablo 2 то знаете о чем я – такая волшебная коробочка через которую одни предметы можно превращать в другие.
Умножать предметы перестало быть возможным после исправления багов в игре🤪
Так вот LLM это такой поломанный куб, в том смысле, что он
Кроме общей инженероной подкованности, хороший вайбкод еще рождаются благодаря инфраструктурным улучшениям.
Для локальной разработки, например, хорошо набросать всякие MCP, которые будут давать больше контекста ассистенту. И как бы там курсор не пыжился в кросс-сессионную память, более продвинутые решения вроде openmemory работают просто лучше.
Навык вовремя сделать шаг назад и сбросить контекст придет только c практикой.
В качестве доп. чтения вот еще хорошая статейка на английском.
Короче говоря – 2 часа изучать код, собирать контекст чтобы написать детально проработанный промт, а потом за 40 минут сделать задачу, на которую без ллм вообще ушло бы 2 дня –
Ставьте огоньки если тема интересна, буду писать еще примеры на пальцах примеры о том как сам вайб-проектирую и вайб-работаю :)
---
“It bothers me that I can’t press a button and check on the rest of the world, or at least the small parts of it that I’m interested in. I’m not the only one. You haven’t been able to walk around and see it, dear, but the irritability threshold around here is lower than it used to be. We’re not in our natural habitat anymore. We’ve become denizens of the net. Homo datum.”
― Pat Cadigan, Synners
За последний год с хвостиком мой голос по поводу вайбкодинга принимал совершенно разные значения на шкале от "Боже, это просто омерзительно" до "Боже, это просто восхитительно".
А в какой-то момент я на эту тему просто замолчал. Просто потому что естественным образом использование LLM-based ассистентов и прочего в большей части моей деятельности стало практически неотъемлемым.
Сейчас пишу об этом, потому что вчера меня спросили – "Слушай, а какое у тебя соотношение написанного кода к сгенерированному?"
И я впал в ступор, натурально. Потому что:
- Кода генерируется много, процентов 80% как минимум
- Кода генерируется мало (в смысле бойлерплейт мусора, об этом дальше)
- 90% сгенерированного кода вычитывается настолько внимательно, насколько это возможно
- Все что нужно исправить – исправляется либо вручную (если мало), либо в точечных последующих промптах
При этом я знаю людей которые генерируют 100% прод кода с телефона и живут припеваючи.
***
Интересно то, насколько сильно отличается сгенерированный код у разных людей в смысле качества, стиля, и вообще функционально; Не знаю обращали ли вы на это внимание.
Точнее как, у не очень опытных в программной инженерии человеков как раз таки получается примерно одинаковый результат, его достаточно просто распознать как "LLM-blob":
- Решения – странные, неуместные;
- Избыточные комментарии там где они не нужны, или полное отсутствие комментариев в откровенно переусложненном коде;
- Использование паттернов, которые нигде в проекте больше не живут без какого либо архитектурного оправдания;
- и так далее.
А кидать такие вот шмоты мертвого кода друг другу на code-review это не менее чем производственное преступление.
***
Мне нравится шутливо называть LLM поломанным хорадрическим кубом.
Если вы играли в Diablo 2 то знаете о чем я – такая волшебная коробочка через которую одни предметы можно превращать в другие.
Умножать предметы перестало быть возможным после исправления багов в игре
Так вот LLM это такой поломанный куб, в том смысле, что он
драматически умножает поданные на вход когнитивные усилия и качество этих усилий.
Кроме общей инженероной подкованности, хороший вайбкод еще рождаются благодаря инфраструктурным улучшениям.
Для локальной разработки, например, хорошо набросать всякие MCP, которые будут давать больше контекста ассистенту. И как бы там курсор не пыжился в кросс-сессионную память, более продвинутые решения вроде openmemory работают просто лучше.
Навык вовремя сделать шаг назад и сбросить контекст придет только c практикой.
В качестве доп. чтения вот еще хорошая статейка на английском.
Короче говоря – 2 часа изучать код, собирать контекст чтобы написать детально проработанный промт, а потом за 40 минут сделать задачу, на которую без ллм вообще ушло бы 2 дня –
НОРМ.Ставьте огоньки если тема интересна, буду писать еще примеры на пальцах примеры о том как сам вайб-проектирую и вайб-работаю :)
---
“It bothers me that I can’t press a button and check on the rest of the world, or at least the small parts of it that I’m interested in. I’m not the only one. You haven’t been able to walk around and see it, dear, but the irritability threshold around here is lower than it used to be. We’re not in our natural habitat anymore. We’ve become denizens of the net. Homo datum.”
― Pat Cadigan, Synners
Please open Telegram to view this post
VIEW IN TELEGRAM
Судя по количеству реакций, как минимум 10 человек меня читают с интересом.
Спасибо вам!
Мне очень важно собрать хотя бы от половины из вас фидбек про канал и материалы. Обещаю что это не займет более 10 минут.
Если вы готовы ответить на несколько вопросов на этой неделе – напишите, пожалуйста, в комменты что нибудь❤️
Спасибо вам!
Мне очень важно собрать хотя бы от половины из вас фидбек про канал и материалы. Обещаю что это не займет более 10 минут.
Если вы готовы ответить на несколько вопросов на этой неделе – напишите, пожалуйста, в комменты что нибудь
p.s. просто обозначьтесь, я скину вам форму с опросом потом :)Please open Telegram to view this post
VIEW IN TELEGRAM
Значит, AI заменит программистов.В последнее время я наблюдаю радикально позитивную тенденцию – пусть и зачастую почти беспредметно, но в популярных AI-движ рассылках и прочих медиа все чащепроявляется топик "AI системы это просто программные системы в которых где-то есть LLM".
И это хорошо.
В общем и целом, для IT индустрии LLM это просто новая, но уже укоренившаяся бэкенд технология.
А AGI, ai-2027 и прочее, кажется что обитает примерно в той же пространственн-временной линии, где DeFI блокчейн евангелистов победивший/поглотивший "старую экономику."
Мы туда как-бы стремимся, но с ближайшей реальностью это мало общего имеет.
Конечно технология прекрасна, предоставляет огромные возможности и ускорения, но нам должно быть понятно вот что – требования к разработке программных систем не то чтобы не ослабевают, а ровным счетом наоборот.
Особенно если там где-то внутри есть хорадрические кубики.
***
Вот тут наисследовали влияние на занятость с появлением AI.
Нас в первую очередь интересует IT: джунам стало труднее, ибо LLM асссистенты пожрали подавляющее число задач на которых джуны учились в профессию, а сеньоры получают примерно столько же денег, но вынуждены осваивать новые технологии быстрее.
Для последних так словно вообще ничего не поменялось
Иными словами – AI пожирает простые прикладные задачи но требует мастерства, превращая программирование из потокового ремесла в инженерное искусство проектирования и управления сложными системами.
Например, spec-driven development – великолепный тренд, ознакомьтесь.
Значит ли это что стать программистом или каким нибудь SRE/DevOps стало сейчас сложнее?
Не значит – стало сложнее идти по старой дорожке, когда мы довольно быстро могли нахвататься относительно простых навыков кодирования и/или администрирования.
Но учиться теперь стало многократно проще, в том числе "вкатываться в айти с нуля в 27 лет"
Если раньше у нас просто был интернет с кучей знаний которые надо было лишь поискать, то теперь есть возможность за условные 20 баксов получить крайне компетентного ментора – в объеме знаний, в вечно хорошем настроении, и с очень быстрым циклом обратной связи!
Впрочем это не отменяет ценности белкового менторства, как по мне и то и другое замечательно работает в синергии.
Claude или ChatGPT может для вас составить и план обучения, и провести вас по нему за ручку – вопрос только в вашей находчивости и желании чему-то научиться.
Спорный момент – когда мы совсем ничего не знаем про предметную область, мы даже не в курсе что вообще спрашивать, и не способны трезво оценить качество предоставляемой в ответ информации.
Мое мнение тут такое – не беда. Даже с учетом всех возможных галлюцинаций и чуть-чуть устаревшего датасета в большинстве случаев можно получить отличные результаты если просто начать задавать вопросы.
Привет! Я хочу стать [X]. Помоги мне составить план обучения.
Мой текущий уровень: [полный ноль/базовые знания/etc]
Мои цели: [найти работу через X месяцев/изучить для личных проектов/etc]
Сколько времени могу уделять: [X часов в неделю]
Составь:
1. Пошаговый план обучения с временными рамками
2. Конкретные ресурсы для каждого этапа
3. Практические проекты для закрепления
4. Критерии оценки прогресса
Задавай уточняющие вопросы, если что-то непонятно.
AI не убивает программистов — он убивает тех кто не готов адаптироваться и самосовершенствоваться.
Please open Telegram to view this post
VIEW IN TELEGRAM