Канал заметок о строительстве и развитии систем в век автономности. Прикладной ИИ и как с ним строить. Технология <- Продукт <- Бизнес.
Всем привет! Я Иван, предприниматель и инженер.
Построил uav-siberia.com, вышел, переехал в долину, строю nautex.ai. В Nautex AI продуктизирую свой архитектурный и системно-инженерный опыт.
Инженерная часть меня прошла путь делая hardware&software: встраиваемые системы-контроллеры, космическую аппаратуру, системы управления полётом беспилотников. Как предприниматель строил и развивал амбициозные команды, технологии и продукты в аэрокосмосе.
Особенность аэрокосмических проектов в том, что цена ошибки очень велика. Ошибка может отбросить проект на годы или полностью уничтожить его шансы на успех. Так вышло, что наблюдал за динамикой успехов и падений многократно, внутри процессов клиентов, внутри собственных реалий.
Такая интенсивность, где ставки высоки и ошибаться крайне опасно не могла пройти бесследно и оставиламножественные шрамы и увечья полезную интуицию о том как строить и как не строить технические и не технические системы.
Грань между техническими и не техническими системами стирается ускоряющимся темпами.
Планета залетает на огромной скорости в новую реальность адаптирующихся машин: ИИ Агентов, Роботов. Систем внутри систем.
И внутри этой динамики много всего интересного и того, что мы хотим поставить на службу в свою жизнь и выигрывать внутри этой трансформации.
Из конкретных тем:
- контекст инжиниринг, LLM
- автономное строительство софта через LLM
- системная инженерия, практика, примеры, любопытные наблюдения
- системное мышление: как выявлять и вычленять главное, отбрасывать шум, разбирать на детальки сложное; да ещё и так, чтобы собралось обратно
- мемасы по теме
картинки:
- Сицилия, снятая 2012м году с моей аппаратуры с космического аппарата Юбилейный 2 (следующая картинка),
- взлёт беспилотника, разработки uav-siberia.com
- аппаратура, что я разрабатывал внутри ctlst.tech (не полетело)
- скриншот nautex.ai (таблица задач кодинг агентам, сгенерированных по PRD)
Всем привет! Я Иван, предприниматель и инженер.
Построил uav-siberia.com, вышел, переехал в долину, строю nautex.ai. В Nautex AI продуктизирую свой архитектурный и системно-инженерный опыт.
Инженерная часть меня прошла путь делая hardware&software: встраиваемые системы-контроллеры, космическую аппаратуру, системы управления полётом беспилотников. Как предприниматель строил и развивал амбициозные команды, технологии и продукты в аэрокосмосе.
Особенность аэрокосмических проектов в том, что цена ошибки очень велика. Ошибка может отбросить проект на годы или полностью уничтожить его шансы на успех. Так вышло, что наблюдал за динамикой успехов и падений многократно, внутри процессов клиентов, внутри собственных реалий.
Такая интенсивность, где ставки высоки и ошибаться крайне опасно не могла пройти бесследно и оставила
Грань между техническими и не техническими системами стирается ускоряющимся темпами.
Планета залетает на огромной скорости в новую реальность адаптирующихся машин: ИИ Агентов, Роботов. Систем внутри систем.
И внутри этой динамики много всего интересного и того, что мы хотим поставить на службу в свою жизнь и выигрывать внутри этой трансформации.
Из конкретных тем:
- контекст инжиниринг, LLM
- автономное строительство софта через LLM
- системная инженерия, практика, примеры, любопытные наблюдения
- системное мышление: как выявлять и вычленять главное, отбрасывать шум, разбирать на детальки сложное; да ещё и так, чтобы собралось обратно
- мемасы по теме
картинки:
- Сицилия, снятая 2012м году с моей аппаратуры с космического аппарата Юбилейный 2 (следующая картинка),
- взлёт беспилотника, разработки uav-siberia.com
- аппаратура, что я разрабатывал внутри ctlst.tech (не полетело)
- скриншот nautex.ai (таблица задач кодинг агентам, сгенерированных по PRD)
🔥4❤🔥1❤1🐳1😇1
This media is not supported in your browser
VIEW IN TELEGRAM
Требования и системный дизайн как основа любой системы, работают как ствол дерева. Правильный ствол и ветки дают системе путь к развитию, масштабу и устойчивости.
❤🔥3
Невероятного качества исполнения интерактивная инфографика по исторической динамике биологии, технологий и власти.
Культурный и инженерный шок.
https://calculatingempires.net/
Культурный и инженерный шок.
https://calculatingempires.net/
calculatingempires.net
Calculating Empires: A Genealogy of Technology and Power since 1500
Explore how technical and social structures co-evolved over five centuries in this large-scale research visualization.
👍5❤🔥1
Media is too big
VIEW IN TELEGRAM
Наконец дошли руки скомпилировать видео недавних достижений Nautex AI.
Specification Driven Development.
Nautex AI управляет Claude Code и человеком в контуре обратной связи для имплементации https://pixall.art
Система строит систему на практике.
Specification Driven Development.
Nautex AI управляет Claude Code и человеком в контуре обратной связи для имплементации https://pixall.art
Система строит систему на практике.
🔥4❤1❤🔥1👍1
Спецификации как новый код. Компиляция в процессе.
Вероятностная "компиляция" это не набор эвристик, как в традиционной линейно трансляции/оптимизации одной нотации в другую.
"Вероятностная" компиляция это о том, как управлять контурами отрицательных обратных от желаемого к действительному по тому какие получаются артефакты (рабочий код, сервисы).
Трюк в том, чтобы на этапе планирования научиться предсказывать точки с наибольшим риском и заранее планировать архитектуру, чтобы была в них легко и автономно тестируема (коротким и быстрым контуром проверки).
Вероятностная "компиляция" это не набор эвристик, как в традиционной линейно трансляции/оптимизации одной нотации в другую.
"Вероятностная" компиляция это о том, как управлять контурами отрицательных обратных от желаемого к действительному по тому какие получаются артефакты (рабочий код, сервисы).
Трюк в том, чтобы на этапе планирования научиться предсказывать точки с наибольшим риском и заранее планировать архитектуру, чтобы была в них легко и автономно тестируема (коротким и быстрым контуром проверки).
spec2code
Делал демо на встрече от AI Thinkers в Сан Франциско на тему spec2code компиляции.
Пока ехал на встречу наговорил в Nautex что хочу (простой симулятор орбитальной механики, ниже можно найти как поиграться), скомпилировал спеку вычистил TODO.
Уже на месте Claude Code закодировал спецификацию до момента интеграции математики с графикой. И на самой демке уже фокус с выходом изза печки, Claude Code автономно доделал математику и на демке всем нарисовалась чётка низкая орбита.
Managing Project Technical Success Rate - должно стать новой олимпийской дисциплиной.
Тут можно поиграться в вывод спутника на геостационарную орбиту. Ведь именно этого вам нехватало всю рабочую неделю. Можно во вторую и в третью космическую скорость тоже.
https://orbit-sim.demos.nautex.ai
Делал демо на встрече от AI Thinkers в Сан Франциско на тему spec2code компиляции.
Пока ехал на встречу наговорил в Nautex что хочу (простой симулятор орбитальной механики, ниже можно найти как поиграться), скомпилировал спеку вычистил TODO.
Уже на месте Claude Code закодировал спецификацию до момента интеграции математики с графикой. И на самой демке уже фокус с выходом изза печки, Claude Code автономно доделал математику и на демке всем нарисовалась чётка низкая орбита.
Managing Project Technical Success Rate - должно стать новой олимпийской дисциплиной.
Тут можно поиграться в вывод спутника на геостационарную орбиту. Ведь именно этого вам нехватало всю рабочую неделю. Можно во вторую и в третью космическую скорость тоже.
https://orbit-sim.demos.nautex.ai
🔥5
У меня есть гипотеза, что будущий b2b софт будет иметь игровой UX.
По той причине, что оркестрировать потребуется только высокоуровневые корневые решения, а 90% - 95% нюансов могут быть отработаны автономно.
Иными словами, UX сахарочки вокруг excel/spreadsheet парадигмы в UX старкрафта, а для харкодных ниш - factorio
(Медведь не мой, мем с ним мой)
По той причине, что оркестрировать потребуется только высокоуровневые корневые решения, а 90% - 95% нюансов могут быть отработаны автономно.
Иными словами, UX сахарочки вокруг excel/spreadsheet парадигмы в UX старкрафта, а для харкодных ниш - factorio
(Медведь не мой, мем с ним мой)
Вчера в СФ было соревнование по вайбкодингу, в одной из задачек запостил это (на картинке).
Вообще не хватило одного очка из 18 чтобы попасть в финал, при том что я опаздал на начало на 40 минут, из 120 возможных, считаю неплохим результатом, в следующий раз нужно выиграть.
Там в финале, ребят мучали микроконтроллером и задачкой с поморгать диодной матрицей. Не решил никто. Вайбкод вайбкодом, а hard skill is hard skill.
Вцелом, важно праздновать и оптимизм и критическое мышление. По-праздновать с конфетти можно по тут
Вообще не хватило одного очка из 18 чтобы попасть в финал, при том что я опаздал на начало на 40 минут, из 120 возможных, считаю неплохим результатом, в следующий раз нужно выиграть.
Там в финале, ребят мучали микроконтроллером и задачкой с поморгать диодной матрицей. Не решил никто. Вайбкод вайбкодом, а hard skill is hard skill.
Вцелом, важно праздновать и оптимизм и критическое мышление. По-праздновать с конфетти можно по тут
🔥3⚡1🦄1
aws us-east-1
Как всё было, запись скрытой камерой плюс наша пропреитарная аналитика.
полная версия тут
Если о системах, то ошибкам/отказам и их распротранению нужны барьеры их распротранения. Причем неприятным моментом является то, что самые опасные и коварные ошибки обладают вероятностью возникновения, которая никак себя не проявит на отрезке времени, где наше внимание способно их увидеть и проанализировать не вооруженным глазом.
Легко вычислить ошибки которые идут на этапе отладки, практически невозможно "в домашних условиях" детектировать ошибки которые возникают раз на 10 000 пусков и реже.
Приходится либо придумать как совершить эти 10 000 пусков быстро и дёшево (и с релевантной средой), либо регистрировать все релевантные параметры и анализировать после того, как дефект проявится. Выбор параметров идёт от гипотезы дефекта, которая может быть и не верна. Может не хватить частоты регистрации, либо избыточное логгирование ломает условия проявления дефекта и он исчезает.
Как всё было, запись скрытой камерой плюс наша пропреитарная аналитика.
полная версия тут
Если о системах, то ошибкам/отказам и их распротранению нужны барьеры их распротранения. Причем неприятным моментом является то, что самые опасные и коварные ошибки обладают вероятностью возникновения, которая никак себя не проявит на отрезке времени, где наше внимание способно их увидеть и проанализировать не вооруженным глазом.
Легко вычислить ошибки которые идут на этапе отладки, практически невозможно "в домашних условиях" детектировать ошибки которые возникают раз на 10 000 пусков и реже.
Приходится либо придумать как совершить эти 10 000 пусков быстро и дёшево (и с релевантной средой), либо регистрировать все релевантные параметры и анализировать после того, как дефект проявится. Выбор параметров идёт от гипотезы дефекта, которая может быть и не верна. Может не хватить частоты регистрации, либо избыточное логгирование ломает условия проявления дефекта и он исчезает.
💋1
"Here is the Software System. The Crown is thriving when the foundation is right."
Развил образ кибер-дерева, символизм которого в идее основания, роста и связанности элементов.
Дерево теперь живёт на сайте
На реддите в комментариях рассказал как сделано.
Развил образ кибер-дерева, символизм которого в идее основания, роста и связанности элементов.
Дерево теперь живёт на сайте
На реддите в комментариях рассказал как сделано.
Media is too big
VIEW IN TELEGRAM
🔥2👏1🌚1🆒1
Недавно, в качестве догфуддинга (когда сам используешь свой продукт) делал через nautex.ai несколько сторонних full stack проектов веб приложений с ЛЛМками и специфичным "думаньем"; общим объёмом 65 000 строк кода.
Целью было проверить на прочность весь tool-chain: nautex -> Coding Agents.
Одна из спецификаций была 150 страниц!
Делать спецификацию такой сложности с нуля, даже об ИИ внутри nautex, было супербольно, нужно признать. Особенно первый день, это прям отдельная проблема. (Пути решения как раз стали понятны лучше, будут имплементированы в следующем цикле.)
На 2й - 3й день уже было сильно проще, "мыщца" решаемой проблемы разработалась. В сумме, думаю, было два полноценных рабочих дня на всю спеку.
Спека дальше декомпозировалась на файлы кода проекта ("пространственный" план, spacial plan) и на задачи (временнОй план, temporal plan). Пример задачек на картинке.
Пробелы, ошибки и не стыковки в спеке были, возврат к их ликвидации и доработкам в коде был не слишком проблемным.
Причем сама имплементация была достаточно тупой работой. "Не так, не работает, хватит тупить".
Нужно было следить, чтобы агенты писали код строго по спеке, не отвлекались и не выпадали. Иногда требовалось по-месту гдето поглубже разбить задачи. Часть работы наложилась на период деградации Claude Code, но мы справились. В процессе перешёл на codex cli (как раз стал набирать обороты) и тупой работы стало сильно меньше.
99.99 % кода было написано автономно. И большую часть его я не видел. А если и видел, то меня устраивало.
То есть вполне себе вайб-токсик-CTO процесс.
И тут любопытный момент. Кто вайбкодил знает, что в код заглядывать лучше не нужно. Там что-то не масштабируемое и не перевариваемое и не обслуживаемое. С чётким планом файлов же и спецификацией код предсказуем и, самое главное, у вас полный ownership (код "ваш"), всего что там написано. Ну и разумеется рабочее приложение с недостижимой функциональностью для вайбкодинга в лоб.
Главный вывод, что когнитивная сложность разработки сдвигается в сторону проектирования, куда, вообщем, и то ломится nautex.ai со своим решением.
Make waterfall great again!
Целью было проверить на прочность весь tool-chain: nautex -> Coding Agents.
Одна из спецификаций была 150 страниц!
Делать спецификацию такой сложности с нуля, даже об ИИ внутри nautex, было супербольно, нужно признать. Особенно первый день, это прям отдельная проблема. (Пути решения как раз стали понятны лучше, будут имплементированы в следующем цикле.)
На 2й - 3й день уже было сильно проще, "мыщца" решаемой проблемы разработалась. В сумме, думаю, было два полноценных рабочих дня на всю спеку.
Спека дальше декомпозировалась на файлы кода проекта ("пространственный" план, spacial plan) и на задачи (временнОй план, temporal plan). Пример задачек на картинке.
Пробелы, ошибки и не стыковки в спеке были, возврат к их ликвидации и доработкам в коде был не слишком проблемным.
Причем сама имплементация была достаточно тупой работой. "Не так, не работает, хватит тупить".
Нужно было следить, чтобы агенты писали код строго по спеке, не отвлекались и не выпадали. Иногда требовалось по-месту гдето поглубже разбить задачи. Часть работы наложилась на период деградации Claude Code, но мы справились. В процессе перешёл на codex cli (как раз стал набирать обороты) и тупой работы стало сильно меньше.
99.99 % кода было написано автономно. И большую часть его я не видел. А если и видел, то меня устраивало.
То есть вполне себе вайб-токсик-CTO процесс.
И тут любопытный момент. Кто вайбкодил знает, что в код заглядывать лучше не нужно. Там что-то не масштабируемое и не перевариваемое и не обслуживаемое. С чётким планом файлов же и спецификацией код предсказуем и, самое главное, у вас полный ownership (код "ваш"), всего что там написано. Ну и разумеется рабочее приложение с недостижимой функциональностью для вайбкодинга в лоб.
Главный вывод, что когнитивная сложность разработки сдвигается в сторону проектирования, куда, вообщем, и то ломится nautex.ai со своим решением.
Make waterfall great again!
🔥9❤1😁1😐1👀1😎1
Любопытный анонс.
JetBrains планирует дать возможность подключать в среду авторизацию в пользовательский аккаунт основных LLM провайдеров.
$200-300 в месяц стало нормой трат для профессионального применения, но сложно представить что такую сумму готовы платить на каждый отдельный узкий инструмент.
Примечательным видится вот что:
- для LLM провайдера - это стратегия повышения удержания пользователей: авторизируй интеллект направо и налево в прикладной слой;
- для разработчиков приложений (тех же JetBrains), это стратегия не отстать по функциям и при этом не выстраивать навороченную и часто субсидируемую usage-based пристройку основной инфраструктуры;
Пока на уровне гипотезы.
Или wishful thinking?
Генерация проекта на 4-5к строк средней сложности в токенах через API - это 30-40 долл (моя грубая оценка и опыт с Claude Code).
Траектория nautex.ai это генерировать приложения по требованиям вплоть до деплоя контейнера в тот же Digital Ocean. И тут жизнеспособным вариантом была бы авторизация агентов пользтователя в платформу и последующая автономная имплементация с затратами, списанными на подписку Anthropic / OpenAI / Google.
Как минимум видно, что провайдеры такое применение, пока, не блокируют и, наверное, стоит планировать такую интеграцияю в nautex.
Что думаете?
Открыл комменты.
(повторный пост, чтобы появился переход)
JetBrains планирует дать возможность подключать в среду авторизацию в пользовательский аккаунт основных LLM провайдеров.
$200-300 в месяц стало нормой трат для профессионального применения, но сложно представить что такую сумму готовы платить на каждый отдельный узкий инструмент.
Примечательным видится вот что:
- для LLM провайдера - это стратегия повышения удержания пользователей: авторизируй интеллект направо и налево в прикладной слой;
- для разработчиков приложений (тех же JetBrains), это стратегия не отстать по функциям и при этом не выстраивать навороченную и часто субсидируемую usage-based пристройку основной инфраструктуры;
Пока на уровне гипотезы.
Или wishful thinking?
Генерация проекта на 4-5к строк средней сложности в токенах через API - это 30-40 долл (моя грубая оценка и опыт с Claude Code).
Траектория nautex.ai это генерировать приложения по требованиям вплоть до деплоя контейнера в тот же Digital Ocean. И тут жизнеспособным вариантом была бы авторизация агентов пользтователя в платформу и последующая автономная имплементация с затратами, списанными на подписку Anthropic / OpenAI / Google.
Как минимум видно, что провайдеры такое применение, пока, не блокируют и, наверное, стоит планировать такую интеграцияю в nautex.
Что думаете?
Открыл комменты.
(повторный пост, чтобы появился переход)
Кибернетические системы с заботой о биологических.
На реддите консенсус, что выдумка. Но не сложно представить, что станет правдой и в какой-то момент будет обязательным требованием. Под угрозой штрафов и банов от площадок дистрибьюции.
У кодинг агентов то лимиты уже есть, а так ведь, гэмбла гэмблой, если вайбкодить.
На реддите консенсус, что выдумка. Но не сложно представить, что станет правдой и в какой-то момент будет обязательным требованием. Под угрозой штрафов и банов от площадок дистрибьюции.
У кодинг агентов то лимиты уже есть, а так ведь, гэмбла гэмблой, если вайбкодить.
Systems Build Systems
spec2code Делал демо на встрече от AI Thinkers в Сан Франциско на тему spec2code компиляции. Пока ехал на встречу наговорил в Nautex что хочу (простой симулятор орбитальной механики, ниже можно найти как поиграться), скомпилировал спеку вычистил TODO. Уже…
Помните генерировал веб симулятор орбитальных маневров?
С недавним обновлением nautex.ai двигаю бенчмарк на новый уровень.
Все те же самые delta V маневры на орбите, но:
- трёхмерные (было в плоскости экватора)
- планирование манёвров, нескольких включений двигателей
- автопилотная ориентация аппарата (ориентация не моделировалась вообще)
- автопилот всех орбитальных запланированных манёвров
Вообщем вайбкоженый kerbal space program на 2-3 шага ближе :)
С недавним обновлением nautex.ai двигаю бенчмарк на новый уровень.
Все те же самые delta V маневры на орбите, но:
- трёхмерные (было в плоскости экватора)
- планирование манёвров, нескольких включений двигателей
- автопилотная ориентация аппарата (ориентация не моделировалась вообще)
- автопилот всех орбитальных запланированных манёвров
Вообщем вайбкоженый kerbal space program на 2-3 шага ближе :)
🔥3❤2🤯1🆒1
