Forwarded from втф
Топ-5 книг для дизайна первой торговой стратегии
(не прибыльной, очевидно, но будет что показать в портфолио)
1. Ernest P. Chan - Algorithmic Trading: Winning Strategies and Their Rationale
📅 2013 | 📄 208 стр.
💡 Калман-фильтр всегда лучше скользящего окна для адаптивной оценки параметров - даёт оценку неопределённости и плавную адаптацию без резких скачков.
📝 Самая практичная книга для старта. Готовые стратегии mean-reversion и momentum с кодом. Cointegration, Kalman filter, Bollinger, cross-sectional MR.
2. Robert Carver - Advanced Futures Trading Strategies
📅 2023 | 📄 680 стр.
💡 «Не доверяй бэктесту с Sharpe > 2» - почти наверняка переобучение. Если издержки > 1/3 SR - стратегию нельзя торговать на этом инструменте.
📝 Полная система от нуля: выбор стратегии → sizing → risk overlay → execution. 7-шаговый фреймворк без переобучения. Лучшая книга по «как собрать всё вместе».
3. Igor Tulchinsky et al. - Finding Alphas: A Quantitative Approach to Building Trading Strategies
📅 2015 | 📄 245 стр.
💡 Робастная альфа показывает монотонное убывание доходности по квинтилям (Q1→Q5) - немонотонность = хрупкий сигнал, который быстро затухнет.
📝 Методология дизайна альфы от WorldQuant: идея → формализация → бэктест → оценка. 8-мерный фреймворк оценки. Учит думать об альфах, а не копировать формулы.
4. Marcos López de Prado - Advances in Financial Machine Learning
📅 2018 | 📄 432 стр.
💡 Meta-labeling разделяет НАПРАВЛЕНИЕ и РАЗМЕР ставки: первая модель - long/short, вторая (meta) - уверенность. Позволяет улучшить sizing не трогая модель направления.
📝 ML-пайплайн для финансов: triple barrier labeling, fractional differentiation, CPCV-валидация, HRP-портфели. Учит избегать фатальных ошибок (leakage, overfitting, неправильная CV).
5. Giuseppe Paleologo — Elements of Quantitative Investing
📅 2024 | 📄 519 стр.
💡 SE Sharpe Ratio ≈ 1/√T - чтобы отличить SR=0.5 от SR=0 на уровне 2σ, нужно ~16 лет данных. Большинство бэктестов слишком коротки.
📝 Теория за sizing и портфелем. Kelly criterion, Fundamental Law (IR=IC·√nT), spiked covariance, 5 подходов к робастной оптимизации. Объясняет, почему SR - это скилл, а не результат.
#редакция@overzeros
(не прибыльной, очевидно, но будет что показать в портфолио)
1. Ernest P. Chan - Algorithmic Trading: Winning Strategies and Their Rationale
📅 2013 | 📄 208 стр.
💡 Калман-фильтр всегда лучше скользящего окна для адаптивной оценки параметров - даёт оценку неопределённости и плавную адаптацию без резких скачков.
📝 Самая практичная книга для старта. Готовые стратегии mean-reversion и momentum с кодом. Cointegration, Kalman filter, Bollinger, cross-sectional MR.
2. Robert Carver - Advanced Futures Trading Strategies
📅 2023 | 📄 680 стр.
💡 «Не доверяй бэктесту с Sharpe > 2» - почти наверняка переобучение. Если издержки > 1/3 SR - стратегию нельзя торговать на этом инструменте.
📝 Полная система от нуля: выбор стратегии → sizing → risk overlay → execution. 7-шаговый фреймворк без переобучения. Лучшая книга по «как собрать всё вместе».
3. Igor Tulchinsky et al. - Finding Alphas: A Quantitative Approach to Building Trading Strategies
📅 2015 | 📄 245 стр.
💡 Робастная альфа показывает монотонное убывание доходности по квинтилям (Q1→Q5) - немонотонность = хрупкий сигнал, который быстро затухнет.
📝 Методология дизайна альфы от WorldQuant: идея → формализация → бэктест → оценка. 8-мерный фреймворк оценки. Учит думать об альфах, а не копировать формулы.
4. Marcos López de Prado - Advances in Financial Machine Learning
📅 2018 | 📄 432 стр.
💡 Meta-labeling разделяет НАПРАВЛЕНИЕ и РАЗМЕР ставки: первая модель - long/short, вторая (meta) - уверенность. Позволяет улучшить sizing не трогая модель направления.
📝 ML-пайплайн для финансов: triple barrier labeling, fractional differentiation, CPCV-валидация, HRP-портфели. Учит избегать фатальных ошибок (leakage, overfitting, неправильная CV).
5. Giuseppe Paleologo — Elements of Quantitative Investing
📅 2024 | 📄 519 стр.
💡 SE Sharpe Ratio ≈ 1/√T - чтобы отличить SR=0.5 от SR=0 на уровне 2σ, нужно ~16 лет данных. Большинство бэктестов слишком коротки.
📝 Теория за sizing и портфелем. Kelly criterion, Fundamental Law (IR=IC·√nT), spiked covariance, 5 подходов к робастной оптимизации. Объясняет, почему SR - это скилл, а не результат.
#редакция@overzeros
Forwarded from Refat Talks: Tech & AI
AI Evals: 9 принципов которые реально работают
Как говорил мой дед: "Доверяй но verify"! Не буду тут повторяться про то как важны Evals в AI разработке, перейду к сути - вот принципы, к которым я пришел на практике.
1. Сначала реальные проблемы, потом метрики
Не придумывай evals из головы (и уж тем более не проси AI их придумать). Выпусти первую версию, отдай эксперту на разметку, и пусть проверки (а главное их категории!) вырастут из реальных косяков. Исключение: если уже есть verified ground truth (пары вопрос-ответ от экспертов) - можно начать с evals сразу. Тем более размечать готовые трейсы (например из LangFuse) куда удобнее - там есть много важных деталей о ходе работы AI системы.
2. PASS/FAIL лучше чем грейды (1-5, 0..100%)
Бинарные чеки проще согласовать между людьми и между LLM и человеком. Люди и сами нестабильно используют шкалы, а с бинарными оценками дрифт минимальный. Согласование между людьми на бинарных оценках всегда выше. Хочется нюансов? Бинарный вердикт + текстовая критика. Судья пишет pass/fail И развернуто объясняет почему. Нужна гранулярность? Разбей на несколько бинарных чеков.
3. Эксперт - ключевая фигура. Сделай чтобы ему удобно
Доменный эксперт - человек, от которого зависит качество eval-ов. Надо сделать все чтобы ему было удобно и все шло быстро. Например, мы у себя нередко вайбкодим кастомные eval-аппы чтобы экспертам было удобно размечать: cлева исходный документ (например PDF), справа ответ системы и там же поле для аннотации. Или даже тиндер-стайл (мне за эту разработку такую премию дадут!): свайп вправо pass, влево fail, и надиктовать коммент голосом - почему бы и нет? Главное вытащить суть из эксперта и делать это регулярно.
4. Простой кастомный eval лучше готового фреймворка
Generic метрики (coherence, fluency, faithfulness) создают иллюзию контроля. Eval который ты понимаешь и можешь объяснить коллеге за 30 секунд - всегда лучше черного ящика. Привет, RAGAS)
5. Детерминированные проверки в приоритете
Код (regex, assertions, другие code-checks включая простые NLP чеки) - всегда первый выбор. LLM-as-a-judge - только там, где код не справляется. Это надежнее, дешевле, быстрее. LLM-judge оправдан для субъективных вещей: качество передачи контекста, тон, полнота ответа - то что кодом не проверишь.
6. LLM-judge калибруй по эксперту, а не наоборот
Порядок такой: сначала берешь несколько десятков пар, которые размечает эксперт, потом бьешь это на категории (AI в помощь), потом строишь разные скореры - часть кодом, часть LLM-as-a-judge (каждый отвечает четко PASS/FAIL и есть поле с обоснованием/критикой), потом надо снова согласовать выход LLM-as-a-judge с экспертом и править промпт пока согласованность не будет высокой.
7. Разделяй evals по блокам системы
Не один eval на всю систему (хотя и один лучше чем ничего).
Пример с RAG:
- Retrieval: recall, precision, MRR - находит ли система правильные документы?
- Generation ответа: правильно ли модель использует найденный контекст (кастомные скореры)?
Разделение дает четкий сигнал где ломается.
С агентами принцип тот же: eval-ишь отдельные tools изолированно + session-level pass/fail на итог. Но не проверяй конкретные шаги - агент часто находит путь, который ты не предвидел.
8. Синхронизируй версии промптов и evals
Промпт, код и evals легко рассинхронизируются - промпт поменялся, а evals проверяют старое поведение. Неважно как именно ты версионируешь (Git, платформа типа promtfoo или Langfuse, хоть excel) - главное чтобы была сквозная версия. А еще метрики дрифтуют, это нормально, не пытайся сохранить непрерывную линию метрик любой ценой.
9. Процесс важнее инструмента
Даже Google Sheets которыми реально пользуются эксперты лучше чем Promptfoo которым не пользуется никто. Ручной eval на 50 парах лучше чем крутой Eval Pipeline в CI. Не прокрастинируй выбором тулинга. Лучший eval-инструмент - тот, который используется. Тем более потом превратить эту табличку в автоматические проверки будет очень просто.
🔥 ➕ 🔁 @nobilix
Как говорил мой дед: "Доверяй но verify"! Не буду тут повторяться про то как важны Evals в AI разработке, перейду к сути - вот принципы, к которым я пришел на практике.
1. Сначала реальные проблемы, потом метрики
Не придумывай evals из головы (и уж тем более не проси AI их придумать). Выпусти первую версию, отдай эксперту на разметку, и пусть проверки (а главное их категории!) вырастут из реальных косяков. Исключение: если уже есть verified ground truth (пары вопрос-ответ от экспертов) - можно начать с evals сразу. Тем более размечать готовые трейсы (например из LangFuse) куда удобнее - там есть много важных деталей о ходе работы AI системы.
2. PASS/FAIL лучше чем грейды (1-5, 0..100%)
Бинарные чеки проще согласовать между людьми и между LLM и человеком. Люди и сами нестабильно используют шкалы, а с бинарными оценками дрифт минимальный. Согласование между людьми на бинарных оценках всегда выше. Хочется нюансов? Бинарный вердикт + текстовая критика. Судья пишет pass/fail И развернуто объясняет почему. Нужна гранулярность? Разбей на несколько бинарных чеков.
3. Эксперт - ключевая фигура. Сделай чтобы ему удобно
Доменный эксперт - человек, от которого зависит качество eval-ов. Надо сделать все чтобы ему было удобно и все шло быстро. Например, мы у себя нередко вайбкодим кастомные eval-аппы чтобы экспертам было удобно размечать: cлева исходный документ (например PDF), справа ответ системы и там же поле для аннотации. Или даже тиндер-стайл (мне за эту разработку такую премию дадут!): свайп вправо pass, влево fail, и надиктовать коммент голосом - почему бы и нет? Главное вытащить суть из эксперта и делать это регулярно.
4. Простой кастомный eval лучше готового фреймворка
Generic метрики (coherence, fluency, faithfulness) создают иллюзию контроля. Eval который ты понимаешь и можешь объяснить коллеге за 30 секунд - всегда лучше черного ящика. Привет, RAGAS)
5. Детерминированные проверки в приоритете
Код (regex, assertions, другие code-checks включая простые NLP чеки) - всегда первый выбор. LLM-as-a-judge - только там, где код не справляется. Это надежнее, дешевле, быстрее. LLM-judge оправдан для субъективных вещей: качество передачи контекста, тон, полнота ответа - то что кодом не проверишь.
6. LLM-judge калибруй по эксперту, а не наоборот
Порядок такой: сначала берешь несколько десятков пар, которые размечает эксперт, потом бьешь это на категории (AI в помощь), потом строишь разные скореры - часть кодом, часть LLM-as-a-judge (каждый отвечает четко PASS/FAIL и есть поле с обоснованием/критикой), потом надо снова согласовать выход LLM-as-a-judge с экспертом и править промпт пока согласованность не будет высокой.
7. Разделяй evals по блокам системы
Не один eval на всю систему (хотя и один лучше чем ничего).
Пример с RAG:
- Retrieval: recall, precision, MRR - находит ли система правильные документы?
- Generation ответа: правильно ли модель использует найденный контекст (кастомные скореры)?
Разделение дает четкий сигнал где ломается.
С агентами принцип тот же: eval-ишь отдельные tools изолированно + session-level pass/fail на итог. Но не проверяй конкретные шаги - агент часто находит путь, который ты не предвидел.
8. Синхронизируй версии промптов и evals
Промпт, код и evals легко рассинхронизируются - промпт поменялся, а evals проверяют старое поведение. Неважно как именно ты версионируешь (Git, платформа типа promtfoo или Langfuse, хоть excel) - главное чтобы была сквозная версия. А еще метрики дрифтуют, это нормально, не пытайся сохранить непрерывную линию метрик любой ценой.
9. Процесс важнее инструмента
Даже Google Sheets которыми реально пользуются эксперты лучше чем Promptfoo которым не пользуется никто. Ручной eval на 50 парах лучше чем крутой Eval Pipeline в CI. Не прокрастинируй выбором тулинга. Лучший eval-инструмент - тот, который используется. Тем более потом превратить эту табличку в автоматические проверки будет очень просто.
🔥 ➕ 🔁 @nobilix
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
#ништяки 🍑
В поисках крутых инфоповодов и тем для моих постов я наткнулся на довольно крутой курс по всему ML, который включает в себя 260 уроков от линейной алгебры до сложных агентских взаимодействий, а также реально сложные вещи, как инфраструктура, KV-cache и методы квантизации, но главное он АБСОЛЮТНО бесплатный.
Сайт курса: https://aiengineeringfromscratch.com/
Репозиторий курса: https://github.com/rohitg00/ai-engineering-from-scratch
💗 - почаще скидывать такие ништяки
В поисках крутых инфоповодов и тем для моих постов я наткнулся на довольно крутой курс по всему ML, который включает в себя 260 уроков от линейной алгебры до сложных агентских взаимодействий, а также реально сложные вещи, как инфраструктура, KV-cache и методы квантизации, но главное он АБСОЛЮТНО бесплатный.
Сайт курса: https://aiengineeringfromscratch.com/
Репозиторий курса: https://github.com/rohitg00/ai-engineering-from-scratch
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тоже Паша Техник
это одна из самых полезных книг не про модели и не про то, как натянуть очередной алгоритм на задачу, а про то, почему ML-проекты разваливаются уже после красивого demo
главная мысль лично для меня:
ml system design — это сначала понять проблему, цену ошибки, ограничения, как будем интегрировать, что нужно мониторить и только потом уже учить что-то умное.
вообще я бы назвал эту книжку настольной. Иногда перечитывать и заострять свое внимание на важных моментах очень полезно.
вот как раз эти мысли, про которые было бы хорошо вспоминать при разработке различных систем:
1. понимание problem space важнее чем solution space
очень частая ошибка в командах разного уровня: тебе говорят "давайте сделаем персональные рекомендашки" и инженеры начинают блестать своими знаниями о зоопарке различных алгоритмов.
А потом оказывается, что крутая модель по оффлайн метрикам вообще не вывозит онлайн, так как рассматривает товары по одиночке, а бизнесу, например, важно собирать наборы товаров.
книга напоминает: сначала решаем для кого делаем решение, что реально у них болит, как выглядит успешное решение, сколько стоит цена различных ошибок.
2. дизайн док — это не бюрократия, а способ не потратить 3 месяца вникуда. Док нужен, чтобы вовремя понять — может 90% результата можно достигнуть обычными правилами
3. валидация важнее, чем кажется
можно получить красивые оффлайн метрики и потом убить систему в production просто потому, что split был нереалистичным. Банально, если в реальности данные меняются со временем, то random split для разделения выборки часто рисует тебе влажные фантазии а не реальность
4. мониторинг — это не только цпу/рам и задержка!
Нужно смотреть минимум на 4 слоя: инфра, качество данных, качество модели, бизнес метрики.
Да, модель может не сломаться технически, но, например, по метрикам модели или бизнес метрикам вы можете заметить что модель начала деградировать из за дрифта, нового сегмента пользователей или изменения продукта
5. Главная мысль для сеньор уровня.
ml system design = правильно поставить задачу -> выбрать честные метрики -> собрать и провалидировать данные -> построить baseline -> улучшать через анализ ошибок -> упаковать в пайплайн -> встроить в продукт -> мониторить дрифт модели и KPI метрики -> заранее обеспечить поддержку системы в будущем.
В книге это и есть настоящий e2e взгляд на ml систему, где модель лишь один из компонентов, а не центр решения проблемы.
В целом книга понравилась. Иногда было водянисто, но полезные советы выцепить не трудно.
Книга очень коррелирует с моими мыслями: лучше стабильный бейзлайн и итеративное его улучшение, чем крутая модель с полугодовой разработкой, которая после месяца использования деграднет
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дратути Антон
Первые 90 дней
На днях закончил читать книгу Майкла Уоткинса "The First 90 Days". Что ж, читается довольно непринужденно, много полезных советов! В ней повествуется о том, что нужно делать, если вдруг вас назначили на новую должность/позицию/роль управленческого характера.
Мне понравился ход повествования: сначала затрагивались, казалось бы, простые, но весьма фундаментальные вещи, о которых чаще забываешь: про себя, про обучение, про выравнивание картины мира с начальством и доверенными тебе людьми. Затем идут более политические темы: достижение "маленьких" побед, понимание структуры организации, формирование коалиций. Финализируется всё философскими размышлениями о дисциплине, равновесии в работе и жизни, развитии команды.
Я позволю себе прокомментировать несколько цитат из книги😍
По личному опыту, оказывается так, что на новом уровне тебе достаточно сложно пользоваться компетенциями, наработанными за все годы трудов, чтобы действительно хорошо делать свою работу. Самый банальный пример: переход из разработчика в тимлида — практически любой курс начинающего руководителя содержит в себе слова: "Однажды придётся сделать выбор: вам нравится больше код, или управление". И это правда: ты не можешь строить процессы в команде, делать так, чтобы ребята перформили, как боженьки, если будешь ходить и говорить всем что им надо делать. Всё, техничка осталась ребятам, ты занят организацией, процессами, ресурсами, развитием и т.д.
Я не могу вспомнить ни одного периода в своей жизни, когда в период адаптации к новой роли меня не вывели из себя. Это достаточно тяжелый период: с одной стороны тебе нужно понять, что вообще происходит, что от тебя хотят, а с другой стороны — тебе уже в момент назначения нужно выдавать перфоманс, как будто бы много лет работаешь в этой роли. И последнее, конечно же, иллюзия, которая окутывает тебя, важно вовремя это распознать и отпустить.
———
Рекомендую ли книгу?
Определённо да, если вы уже опытный. С оговорками, если новичок: дело в том, что книга написана немного в "душном" корпоративном стиле и скорее для мидл+ руководителей. Поскольку стиль весьма суховат, а новички впитывают информацию словно губка воду, то можно напитаться "корпоративного пафоса", который, как мне кажется, не совсем уместен в IT👨🦳 .
На днях закончил читать книгу Майкла Уоткинса "The First 90 Days". Что ж, читается довольно непринужденно, много полезных советов! В ней повествуется о том, что нужно делать, если вдруг вас назначили на новую должность/позицию/роль управленческого характера.
Мне понравился ход повествования: сначала затрагивались, казалось бы, простые, но весьма фундаментальные вещи, о которых чаще забываешь: про себя, про обучение, про выравнивание картины мира с начальством и доверенными тебе людьми. Затем идут более политические темы: достижение "маленьких" побед, понимание структуры организации, формирование коалиций. Финализируется всё философскими размышлениями о дисциплине, равновесии в работе и жизни, развитии команды.
Я позволю себе прокомментировать несколько цитат из книги
У всех есть сильное желание работать уровнем ниже. Но вы должны работать на том уровне, где вы есть, а не на том, где были
ему придется отказаться от привычки во всем полагаться на свою профессиональную компетенцию
По личному опыту, оказывается так, что на новом уровне тебе достаточно сложно пользоваться компетенциями, наработанными за все годы трудов, чтобы действительно хорошо делать свою работу. Самый банальный пример: переход из разработчика в тимлида — практически любой курс начинающего руководителя содержит в себе слова: "Однажды придётся сделать выбор: вам нравится больше код, или управление". И это правда: ты не можешь строить процессы в команде, делать так, чтобы ребята перформили, как боженьки, если будешь ходить и говорить всем что им надо делать. Всё, техничка осталась ребятам, ты занят организацией, процессами, ресурсами, развитием и т.д.
Жизнь лидера — это всегда компромисс, и самые сильные стрессы он испытывает как раз в периоды адаптации. Неуверенность и неоднозначность положения могут очень сильно выводить из равновесия. Вы даже не знаете, чего вы не знаете.
Я не могу вспомнить ни одного периода в своей жизни, когда в период адаптации к новой роли меня не вывели из себя. Это достаточно тяжелый период: с одной стороны тебе нужно понять, что вообще происходит, что от тебя хотят, а с другой стороны — тебе уже в момент назначения нужно выдавать перфоманс, как будто бы много лет работаешь в этой роли. И последнее, конечно же, иллюзия, которая окутывает тебя, важно вовремя это распознать и отпустить.
———
Рекомендую ли книгу?
Определённо да, если вы уже опытный. С оговорками, если новичок: дело в том, что книга написана немного в "душном" корпоративном стиле и скорее для мидл+ руководителей. Поскольку стиль весьма суховат, а новички впитывают информацию словно губка воду, то можно напитаться "корпоративного пафоса", который, как мне кажется, не совсем уместен в IT
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заметки LLM-энтузиаста
8 AI-клонов единорогов за 8 недель: итоги очередного потока курса по AI-программированию
Коллеги, всем привет!
На прошлой неделе мы завершили очередной поток курса по AI-программированию — за 8 недель сделали 8 рабочих прототипов «компаний-единорогов». С первого потока наш подход сильно эволюционировал: в этот раз мы использовали исключительно Claude Code и собрали из кастомных скиллов готовый пайплайн не только для продуктового реверс-инжиниринга, но и для планирования, написания и верификации кода. Сейчас уровень автоматизации достаточно высокий — на входе указываешь ссылку на SaaS для копирования, на выходе получаешь рабочий прототип, все это - при минимальном сопровождении пайплана (по сути, пара-тройка команд в claude cli) и минимальном последующем траблшутинге.
📐 Методология — 7 этапов
Единый пайплайн для всех проектов:
1️⃣ Уточнение задачи
2️⃣ Ресёрч
3️⃣ Планирование (PRD)
4️⃣ Профилирование (техстек)
5️⃣ Реализация (AI-кодинг)
6️⃣ Тестирование
7️⃣ Деплой и CI/CD
Ключевой приём — промпт-верификация после генерации документации и кода: рой агентов проверяет соответствие кода документации в
📦 Что собрали
🎤 AI Sales Trainer — голосовой тренажёр продаж (Voice-to-Voice + анализ транскрипта)
📈 Polymarket Clone — рынок предсказаний с крипто-кошельками и оракулами
🥗 Noom Clone — генерация персональных планов питания через анкету + LLM
🤖 Manus Clone — автономный агент в E2B-песочнице (поиск, кодинг, анализ)
✂️ Opus Pro Clone — нарезка видео на Shorts/Reels через FFmpeg + оценка виральности
💬 Intercom Clone — ИИ-ассистент для сайтов с Telegram-интеграцией
⭐️ Podium Clone — автосбор отзывов на Яндекс.Картах через SMS и deep links
🎮 Roblox Clone — платформа мини-игр с виральными механиками
Стек: Next.js, Prisma, PostgreSQL, Docker, E2B SDK, Cloud.ru, Cloudflare Pages, Telegram Bot API.
🔑 Инсайты
— Двойная верификация (на этапах планирования и реализации) убирает 85–90% проблем до тестирования
— Кастомизация claude code "оснастки" под техстек и документацию на реализацию кода также позволяет улучшить качество генерации кода
— Качество выстроенного пайплайна напрямую определяет качество сгенерированного кода (и позволяет использовать для решения сложных задач не только модели anthropic)
🔗 Портфолио:
— Гамифицированная версия (Claude Code Web)
— Стандартная версия (Genspark + GH Pages через Claude Code Web)
🚀 Новый поток стартует 1 апреля.
Подробности о курсе: https://productuniversity.ru/cursor
@llm_notes @MAX
#agenticengineering #claudecode #vibecoding #productuniversity #courses
Коллеги, всем привет!
На прошлой неделе мы завершили очередной поток курса по AI-программированию — за 8 недель сделали 8 рабочих прототипов «компаний-единорогов». С первого потока наш подход сильно эволюционировал: в этот раз мы использовали исключительно Claude Code и собрали из кастомных скиллов готовый пайплайн не только для продуктового реверс-инжиниринга, но и для планирования, написания и верификации кода. Сейчас уровень автоматизации достаточно высокий — на входе указываешь ссылку на SaaS для копирования, на выходе получаешь рабочий прототип, все это - при минимальном сопровождении пайплана (по сути, пара-тройка команд в claude cli) и минимальном последующем траблшутинге.
📐 Методология — 7 этапов
Единый пайплайн для всех проектов:
1️⃣ Уточнение задачи
2️⃣ Ресёрч
3️⃣ Планирование (PRD)
4️⃣ Профилирование (техстек)
5️⃣ Реализация (AI-кодинг)
6️⃣ Тестирование
7️⃣ Деплой и CI/CD
Ключевой приём — промпт-верификация после генерации документации и кода: рой агентов проверяет соответствие кода документации в
/docs, находит расхождения и итеративно исправляет.📦 Что собрали
🎤 AI Sales Trainer — голосовой тренажёр продаж (Voice-to-Voice + анализ транскрипта)
📈 Polymarket Clone — рынок предсказаний с крипто-кошельками и оракулами
🥗 Noom Clone — генерация персональных планов питания через анкету + LLM
🤖 Manus Clone — автономный агент в E2B-песочнице (поиск, кодинг, анализ)
✂️ Opus Pro Clone — нарезка видео на Shorts/Reels через FFmpeg + оценка виральности
💬 Intercom Clone — ИИ-ассистент для сайтов с Telegram-интеграцией
⭐️ Podium Clone — автосбор отзывов на Яндекс.Картах через SMS и deep links
🎮 Roblox Clone — платформа мини-игр с виральными механиками
Стек: Next.js, Prisma, PostgreSQL, Docker, E2B SDK, Cloud.ru, Cloudflare Pages, Telegram Bot API.
🔑 Инсайты
— Двойная верификация (на этапах планирования и реализации) убирает 85–90% проблем до тестирования
— Кастомизация claude code "оснастки" под техстек и документацию на реализацию кода также позволяет улучшить качество генерации кода
— Качество выстроенного пайплайна напрямую определяет качество сгенерированного кода (и позволяет использовать для решения сложных задач не только модели anthropic)
🔗 Портфолио:
— Гамифицированная версия (Claude Code Web)
— Стандартная версия (Genspark + GH Pages через Claude Code Web)
🚀 Новый поток стартует 1 апреля.
Подробности о курсе: https://productuniversity.ru/cursor
@llm_notes @MAX
#agenticengineering #claudecode #vibecoding #productuniversity #courses
Agentic Engineering Portfolio
Agentic Engineering: Портфолио AI-проектов
8 проектов от EdTech до Gaming, созданных с помощью AI за часы вместо недель.
Forwarded from Заметки LLM-энтузиаста
В продолжении темы клонирования компаний ...
🛰 Бывший PM Google написал аналог Palantir за выходные
Билавал Сидху (Bilawal Sidhu) — бывший продакт-менеджер Google Maps, 6 лет строивший 3D-картографию изнутри. В феврале 2026 года он запустил WorldView — геопространственный командный центр прямо в браузере. Без секретных допусков. Без команды. За три дня.
Интернет назвал это «vibe coded Palantir». Сооснователь Palantir Джо Лонсдейл лично ответил на пост — и это говорит больше, чем любые лайки.
🔍 Что умеет WorldView
· 🛩 Живые позиции 7 000+ самолётов (OpenSky, ADS-B Exchange)
· 🛰 180+ спутников на реальных орбитах — кликни и следи в реальном времени
· 📷 Реальные CCTV-камеры, наложенные прямо на 3D-модель города
· 🌡 Режимы отображения: ночное видение (NVG), тепловизор (FLIR), CRT-сканлайны, аниме cel-shading
· 🚢 Морской трафик через AIS — танкеры, военные суда, грузовые корабли
· 📡 Зоны подавления GPS в виде гексагональных тайлов
⚡️ Как он это построил — процесс vibe coding
Сидху не написал ни строчки кода вручную. Он управлял роем ИИ-агентов через терминал:
1️⃣ Описывал функцию голосовым сообщением или скриншотом
2️⃣ Скармливал это сразу нескольким агентам одновременно (до 8 штук) - похоже на Best Practice от Черни
3️⃣ Каждый агент отвечал за свою подсистему: один — шейдеры, другой — CCTV, третий — спутники
4️⃣ Сам выступал архитектором и доменным экспертом — направлял, а не кодил
5️⃣ Cursor не использовал вообще — только чистый терминал
Стек: Google Photorealistic 3D Tiles + CesiumJS + Gemini 3.1 Pro + Claude 4.6 + Codex 5.3
🗺 4D-реконструкция Operation Epic Fury
Главный демо-кейс — реконструкция ударов по Ирану исключительно из открытых данных:
· Закрытие воздушных пространств над Ираном, Ираком, Кувейтом
· Массовое перенаправление коммерческих рейсов в реальном времени
· Фиксация кинетических ударов по координатам и времени
· Закрытие Ормузского пролива — паника танкеров на AIS
· Всё это — один человек, диван, публичные данные
💬 Почему Palantir отреагировал
Джо Лонсдейл (сооснователь Palantir) написал в ответ: данные никогда не были их рвом. Их ценность — в аналитическом слое поверх данных.
Сидху согласился: WorldView — это sousveillance (наблюдение снизу вверх). Те же спутники, те же камеры, те же потоки данных — но интерфейс в вашем браузере, и управляете им вы.
📦 Репозиторий и код
· ❌ Оригинальный код Сидху пока не опубликован (запуск платформы — апрель 2026)
· ✅ Самый популярный клон: koala73/worldmonitor — 46K ★ на GitHub
Уже сейчас его можно использовать как хорошую базу для качественных "витрин" Real-time аналитики по текущим событиям. Можно сделать свой клон, снять ограничения Pro-версии, добавить нужную функциональность и запустить с API-ключами, чтобы работала ИИ-аналитика (см. ниже пример).
· 🔜 Сам Сидху обещал open source «по многочисленным просьбам» — подписка на рассылку на spatialintelligence.ai
🎬 Материалы
· Видео: 4D-реконструкция ударов по Ирану
· Видео: Как был написан WorldView
· Статья автора на Substack
· Живое приложение (мой клон)
· Мой интерактивный разбор проекта
@llm_notes @MAX
#vibecoding #osint #geospatial #palantir #aiagents
🛰 Бывший PM Google написал аналог Palantir за выходные
Билавал Сидху (Bilawal Sidhu) — бывший продакт-менеджер Google Maps, 6 лет строивший 3D-картографию изнутри. В феврале 2026 года он запустил WorldView — геопространственный командный центр прямо в браузере. Без секретных допусков. Без команды. За три дня.
Интернет назвал это «vibe coded Palantir». Сооснователь Palantir Джо Лонсдейл лично ответил на пост — и это говорит больше, чем любые лайки.
🔍 Что умеет WorldView
· 🛩 Живые позиции 7 000+ самолётов (OpenSky, ADS-B Exchange)
· 🛰 180+ спутников на реальных орбитах — кликни и следи в реальном времени
· 📷 Реальные CCTV-камеры, наложенные прямо на 3D-модель города
· 🌡 Режимы отображения: ночное видение (NVG), тепловизор (FLIR), CRT-сканлайны, аниме cel-shading
· 🚢 Морской трафик через AIS — танкеры, военные суда, грузовые корабли
· 📡 Зоны подавления GPS в виде гексагональных тайлов
⚡️ Как он это построил — процесс vibe coding
Сидху не написал ни строчки кода вручную. Он управлял роем ИИ-агентов через терминал:
1️⃣ Описывал функцию голосовым сообщением или скриншотом
2️⃣ Скармливал это сразу нескольким агентам одновременно (до 8 штук) - похоже на Best Practice от Черни
3️⃣ Каждый агент отвечал за свою подсистему: один — шейдеры, другой — CCTV, третий — спутники
4️⃣ Сам выступал архитектором и доменным экспертом — направлял, а не кодил
5️⃣ Cursor не использовал вообще — только чистый терминал
Стек: Google Photorealistic 3D Tiles + CesiumJS + Gemini 3.1 Pro + Claude 4.6 + Codex 5.3
🗺 4D-реконструкция Operation Epic Fury
Главный демо-кейс — реконструкция ударов по Ирану исключительно из открытых данных:
· Закрытие воздушных пространств над Ираном, Ираком, Кувейтом
· Массовое перенаправление коммерческих рейсов в реальном времени
· Фиксация кинетических ударов по координатам и времени
· Закрытие Ормузского пролива — паника танкеров на AIS
· Всё это — один человек, диван, публичные данные
«Это безумие — что я смог сделать это за выходные в одиночку... Насколько полную картину можно собрать без проприетарных данных, просто используя OSINT»
— Bilawal Sidhu
💬 Почему Palantir отреагировал
Джо Лонсдейл (сооснователь Palantir) написал в ответ: данные никогда не были их рвом. Их ценность — в аналитическом слое поверх данных.
Сидху согласился: WorldView — это sousveillance (наблюдение снизу вверх). Те же спутники, те же камеры, те же потоки данных — но интерфейс в вашем браузере, и управляете им вы.
📦 Репозиторий и код
· ❌ Оригинальный код Сидху пока не опубликован (запуск платформы — апрель 2026)
· ✅ Самый популярный клон: koala73/worldmonitor — 46K ★ на GitHub
Уже сейчас его можно использовать как хорошую базу для качественных "витрин" Real-time аналитики по текущим событиям. Можно сделать свой клон, снять ограничения Pro-версии, добавить нужную функциональность и запустить с API-ключами, чтобы работала ИИ-аналитика (см. ниже пример).
· 🔜 Сам Сидху обещал open source «по многочисленным просьбам» — подписка на рассылку на spatialintelligence.ai
🎬 Материалы
· Видео: 4D-реконструкция ударов по Ирану
· Видео: Как был написан WorldView
· Статья автора на Substack
· Живое приложение (мой клон)
· Мой интерактивный разбор проекта
@llm_notes @MAX
#vibecoding #osint #geospatial #palantir #aiagents
Forwarded from Заметки LLM-энтузиаста
Создатель Claude Code — о том, как он пишет 30 PR в день без единой рукописной строки 🤖
Послушал интервью Бориса Черни (создатель Claude Code) в подкасте Pragmatic Engineer — одно из лучших про то, как реально меняется работа инженера прямо сейчас.
Интересно, что в самом начале своего пути в Anthropic (после перехода из Meta) Борис получил реджект за первый же PR — потому что написал его руками, а не через ИИ :)
Главное 👇
🔧 Как рождался Claude Code
Борис дал модели единственный инструмент — bash — и спросил: «Какую музыку я сейчас слушаю?»
Sonnet 3.5 написал AppleScript, обратился к плееру и выдал ответ с первого захода.
Главный инсайт: не надо загонять модель в рамки. Дай инструменты — она сама разберётся. Это, по сути, и стало основой Claude Code.
⚡️ Рабочий процесс Бориса сегодня
— 5 параллельных агентов в терминале, каждый — в режиме плана
— 20–30 пул-реквестов в день, от однострочников до тысяч строк
— 0 строк написано вручную
— IDE удалил — и не заметил этого ещё месяц
— ~треть кода пишет... с телефона, запуская агентов с утра 📱
С Opus 4.5 поведение модели изменилось настолько, что хороший план практически гарантирует реализацию с первого захода.
🔍 Код-ревью: как это работает
• Claude Code автоматически ревьюит каждый PR → ловит ~80% багов
• Живой инженер делает второй проход
• Человек всегда в контуре финального одобрения
Плюс: Борис пишет «@Claude, напиши lint-правило для этого» прямо в комментарии к чужому PR — и Claude делает это на месте 🎯
🖨 Интересная аналогия с печатным станком
В Европе XV века писцы — < 1% населения — умели писать. Короли нанимали их, сами будучи безграмотными.
Появился печатный станок:
— стоимость материалов упала в 100× за 50 лет
— количество текстов выросло в 10 000× за 100 лет
— появились писатели и авторы как профессия
Писцы не исчезли — рынок просто расширился до масштабов, которые никто не мог предвидеть.
Разработчики сегодня - в позиции писцов. Вопрос не в том, исчезнет ли профессия. Вопрос — что появится, когда создавать код сможет каждый?
📈 Навыки: что растёт, что падает
Теряют значение:
— холивары о языках и фреймворках
— жёсткая привязанность к «правильному» стилю кода
По-прежнему важны:
— методичность и гипотетическое мышление
— умение отлаживать системно
Растут в цене:
— мультидисциплинарность (инженер + продукт + бизнес)
— адаптивность к быстро меняющимся инструментам
— умение быстро переключаться между контекстами 🔄
📚 Книги от Бориса
• Лю Цысинь — короткие рассказы (не только «Задача трёх тел»)
• «Accelerando» Чарльза Стросса — дорожная карта следующих 50 лет
• «Функциональное программирование в Scala» — учит думать типами, делайте все упражнения
P.S.
1) Полный интерактивный транскрипт интервью на русском подготовил для вас здесь.
2) Гамифицированная версия лучших практик по работе с Claude Code от Бориса тут
(сделана с использованием claude code и лучших практик Бориса :)
@llm_notes @MAX
#claudecode #anthropic #aiengineering #futureofwork #llm #cherny #bestpractice
Послушал интервью Бориса Черни (создатель Claude Code) в подкасте Pragmatic Engineer — одно из лучших про то, как реально меняется работа инженера прямо сейчас.
Интересно, что в самом начале своего пути в Anthropic (после перехода из Meta) Борис получил реджект за первый же PR — потому что написал его руками, а не через ИИ :)
Главное 👇
🔧 Как рождался Claude Code
Борис дал модели единственный инструмент — bash — и спросил: «Какую музыку я сейчас слушаю?»
Sonnet 3.5 написал AppleScript, обратился к плееру и выдал ответ с первого захода.
Главный инсайт: не надо загонять модель в рамки. Дай инструменты — она сама разберётся. Это, по сути, и стало основой Claude Code.
⚡️ Рабочий процесс Бориса сегодня
— 5 параллельных агентов в терминале, каждый — в режиме плана
— 20–30 пул-реквестов в день, от однострочников до тысяч строк
— 0 строк написано вручную
— IDE удалил — и не заметил этого ещё месяц
— ~треть кода пишет... с телефона, запуская агентов с утра 📱
С Opus 4.5 поведение модели изменилось настолько, что хороший план практически гарантирует реализацию с первого захода.
🔍 Код-ревью: как это работает
• Claude Code автоматически ревьюит каждый PR → ловит ~80% багов
• Живой инженер делает второй проход
• Человек всегда в контуре финального одобрения
Плюс: Борис пишет «@Claude, напиши lint-правило для этого» прямо в комментарии к чужому PR — и Claude делает это на месте 🎯
🖨 Интересная аналогия с печатным станком
В Европе XV века писцы — < 1% населения — умели писать. Короли нанимали их, сами будучи безграмотными.
Появился печатный станок:
— стоимость материалов упала в 100× за 50 лет
— количество текстов выросло в 10 000× за 100 лет
— появились писатели и авторы как профессия
Писцы не исчезли — рынок просто расширился до масштабов, которые никто не мог предвидеть.
Разработчики сегодня - в позиции писцов. Вопрос не в том, исчезнет ли профессия. Вопрос — что появится, когда создавать код сможет каждый?
📈 Навыки: что растёт, что падает
Теряют значение:
— холивары о языках и фреймворках
— жёсткая привязанность к «правильному» стилю кода
По-прежнему важны:
— методичность и гипотетическое мышление
— умение отлаживать системно
Растут в цене:
— мультидисциплинарность (инженер + продукт + бизнес)
— адаптивность к быстро меняющимся инструментам
— умение быстро переключаться между контекстами 🔄
📚 Книги от Бориса
• Лю Цысинь — короткие рассказы (не только «Задача трёх тел»)
• «Accelerando» Чарльза Стросса — дорожная карта следующих 50 лет
• «Функциональное программирование в Scala» — учит думать типами, делайте все упражнения
P.S.
1) Полный интерактивный транскрипт интервью на русском подготовил для вас здесь.
2) Гамифицированная версия лучших практик по работе с Claude Code от Бориса тут
(сделана с использованием claude code и лучших практик Бориса :)
@llm_notes @MAX
#claudecode #anthropic #aiengineering #futureofwork #llm #cherny #bestpractice
dzhechko.github.io
Борис Черни: Claude Code и будущее разработки
Полный транскрипт интервью с создателем Claude Code
Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 Квантизация с нуля: как 160-гигабайтная LLM помещается на ноутбук
Помните, мы переводили статью про кэширование промптов? Сегодня подготовили перевод от того же автора — на этот раз про квантизацию. Тот же стиль: интерактивная визуализация, объяснение базы, которая лежит в основе и всё это простыми словами.
Для тех, кто слышит про квантизацию впервые: квантизация — это способ уменьшить размер модели, заменив
За счёт этого модели на 160 ГБ могут поместиться на обычный ноутбук и даже работать быстрее!
Понимание того, как модели устроены изнутри, напрямую влияет на то, насколько хорошо вы их используете. Поэтому считаем такие статьи must have для senior vibecoder 😉
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
Помните, мы переводили статью про кэширование промптов? Сегодня подготовили перевод от того же автора — на этот раз про квантизацию. Тот же стиль: интерактивная визуализация, объяснение базы, которая лежит в основе и всё это простыми словами.
Для тех, кто слышит про квантизацию впервые: квантизация — это способ уменьшить размер модели, заменив
16- или 32-битные числа с плавающей запятой на целые числа меньшего размера.За счёт этого модели на 160 ГБ могут поместиться на обычный ноутбук и даже работать быстрее!
Главный инсайт от автора:
Когда я только захотел написать эту статью, я ничего не знал о квантизации. Я предполагал, что качество модели деградирует линейно по мере сжатия. То есть8-битная квантизацияbfloat16будет вдвое хуже, затем4-битная вдвое хуже8-битной, и так далее.
Это оказалось не так.
Переход с16-битной до8-битной квантизации несёт почти нулевые потери качества. Переход с16-битной до4-битной более заметен, но это точно не «в четыре раза хуже оригинала». Ближе к 90%, в зависимости от метрики.
Не бойтесь запускать локальные квантизованные модели.
Понимание того, как модели устроены изнутри, напрямую влияет на то, насколько хорошо вы их используете. Поэтому считаем такие статьи must have для senior vibecoder 😉
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
Forwarded from AI for Devs
Opus 4.5 набирает 80.6% на SWE-bench Verified. Opus 4 — 72.5%. Значит ли это, что Opus 4.5 лучше программирует, чем Opus 4?
Ну... возможно.
Но SWE-bench Verified это не показывает. Он показывает способность модели чинить небольшие баги в 12 популярных open source Python-репозиториях, которые почти наверняка входят в её обучающие данные.
SWE-bench Verified не тестирует умение ориентироваться в вашем TypeScript-монорепо, Spring Boot-приложении или самописном ORM, на котором настоял предыдущий CTO.
А вы знаете, как устроены самые популярные бенчмарки? Если хочется чуть больше понимать, что происходит за цифрами в каждом новом релизе флагманской модели — добро пожаловать в лонгрид на Хабре.
Разбираем 14 самых популярных бенчмарков на конкретных примерах: что тестирует каждый и как устроена оценка.
@ai_for_devs
Ну... возможно.
Но SWE-bench Verified это не показывает. Он показывает способность модели чинить небольшие баги в 12 популярных open source Python-репозиториях, которые почти наверняка входят в её обучающие данные.
SWE-bench Verified не тестирует умение ориентироваться в вашем TypeScript-монорепо, Spring Boot-приложении или самописном ORM, на котором настоял предыдущий CTO.
А вы знаете, как устроены самые популярные бенчмарки? Если хочется чуть больше понимать, что происходит за цифрами в каждом новом релизе флагманской модели — добро пожаловать в лонгрид на Хабре.
Разбираем 14 самых популярных бенчмарков на конкретных примерах: что тестирует каждый и как устроена оценка.
@ai_for_devs