Systems Build Systems
62 subscribers
23 photos
4 videos
11 links
Мои мысли о развитии систем в известной нам вселенной.

Предпринимательство, инженерия, философия, мемы.

Иван Макаров, основатель nautex.ai
X: x.com/ivan_mkrv
Download Telegram
У меня есть гипотеза, что будущий b2b софт будет иметь игровой UX.

По той причине, что оркестрировать потребуется только высокоуровневые корневые решения, а 90% - 95% нюансов могут быть отработаны автономно.

Иными словами, UX сахарочки вокруг excel/spreadsheet парадигмы в UX старкрафта, а для харкодных ниш - factorio

(Медведь не мой, мем с ним мой)
Вчера в СФ было соревнование по вайбкодингу, в одной из задачек запостил это (на картинке).

Вообще не хватило одного очка из 18 чтобы попасть в финал, при том что я опаздал на начало на 40 минут, из 120 возможных, считаю неплохим результатом, в следующий раз нужно выиграть.

Там в финале, ребят мучали микроконтроллером и задачкой с поморгать диодной матрицей. Не решил никто. Вайбкод вайбкодом, а hard skill is hard skill.

Вцелом, важно праздновать и оптимизм и критическое мышление. По-праздновать с конфетти можно по тут
🔥31🦄1
Примечательно тут два момента:
- как изменение базовой архитектуры (нет пилотов даже опцией) меняет доминантный дизайн платформы "Транспортный вертолёт средней грузоподъёмности"
- роботы - главные будущие пассажиры этого робота
🔥3👀1
aws us-east-1
Как всё было, запись скрытой камерой плюс наша пропреитарная аналитика.

полная версия тут

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

Легко вычислить ошибки которые идут на этапе отладки, практически невозможно "в домашних условиях" детектировать ошибки которые возникают раз на 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!
🔥91😁1😐1👀1😎1
Please open Telegram to view this post
VIEW IN TELEGRAM
Любопытный анонс.

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 шага ближе :)
🔥32🤯1🆒1
Любопытный новый опыт внутри моего старого ремесла (системы управления полётом).

Вкладываюсь в инструменты диагностики вместо рукопашной диагностики.

Проблемы решаются мгновенно, когда раскладываешь observability нужных цепочек в инструменты. Раньше не хватало времени и гдето диагностировалось все всегда вручную.

А тут путь автоматизации, мало того, что получается продуктивнее в первой итерации, так это еще и организационный слой над-системный вырастает. То что могли позволить себе только организации после экспериментальной части жизни embedded продукта.

Система строит систему.

И система, что строит систему, чтобы строить систему уже видится частным случаем.
🔥3👏1💯1
Как игровой интерфейс и UX приземлить для задачи разработки систем и софта в частности?

Коль скоро оперировать нужно высокоуровневыми абстракциями и архитектурой - это резонный вопрос, в том моменте истории, когда кроме чата больше ничего и нет для общения с ИИ из продуктово понятных "устойчивых" интерфейсов.

Сегодня экспериментировал с UX для этой идеи.
3д моделька и картинка - это то что может быть вместо кубиков. Метафорические образы элементов системы.

Как вы думаете, почему это может не сработать как продукт? Какой главный риск?
❤‍🔥2
Должен.
Стирается грань между системами из людей и системами из машин.

Раньше взгляд на организацию из людей как систему был не всегда полезен. Особенно на ранней стадии.

У вас должен поменяться взгляд на найм. Если он не поменялся, значит вы чтото делаете не так, скорее всего.
Сплошь и рядом, люди уходят, скорость увеличивается.

Будет буксовать рост.

Думайте о вайбкодинге как об модернизации киборг версии себя, расстройке инструментов аналитики вокруг себя.

Хотите конкурировать по старому с киборгами? Никто не запретит :)
1
Твиттер (Х) основная площадка технических и продуктовых новостей планеты.

Встроил в nautex.ai веб поиск и поиск по Х.

Очень порадовало как работает xAI интеграция, задержки индексации замечено небыло.

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

Но не Иксом единым, можно тянуть идеи себе в ТЗ для агентов из hacker news, product hunt, github.
👍3❤‍🔥1🥰1
Media is too big
VIEW IN TELEGRAM
охренеть, конечно
Google Genie 3 модель, в реальном времени управляется и рендерит картинку

Был такой промтп
desert dunes planet with 2 suns: yellow and blue
futuristic buggy car with canon, like mako from mass effect
🤯3🔥2🌚1