Телеграм канал «Лаборатория Математики и Программирования Сергея Бобровского»

.

Облако драгоценностей за неделю.

Во Вселенной впервые обнаружен Зеленый Фонарь!!1


Приватный клуб.

Молодой выскочка-начальник отчитывает тебя за то, что ты пишешь код старомодным способом, без нейронки? Так это справедливо!
Сегодня во многих компаниях, особенно стартапах, программисты работают со скоростью, которая считалась немыслимой всего два года назад. Сегодня же AI пишет 30-60-98% кода, и это нормально...

Уже 3 часа дня, и у вас открыто 7 запросов на доработку. Вы смотрите на быстрые исправления, объединяющие одно, и понимаете, что AI совершенно неправильно понял другое. Пробовать снова и снова. Большие задачи, над которыми вы поручали AI поработать в фоновом режиме, выглядят "почти выполнимыми", но это "почти" тянется часами...


Для донов-начинающих:

Вы не будете учиться быстрее, если будете учиться усерднее. Или если будете проводить более длительные занятия. Вот как правильно...

Большинство людей изучают одну тему до тех пор, пока не почувствуют, что усвоили её, а затем переходят к следующей. И это кажется эффективным, но есть способы куда получше...

+ Начинаем качать темку "войти в ИТ системным аналитиком с ИИ без знания программирования"

Для донов-неначинающих:

111. Абстракции против паттерна MVC
Вы, очень вероятно, используете в своих проектах классический архитектурный шаблон MVC, где у вас есть множество интерфейсов, которые практически всегда сопоставляются 1:1 с объектами, которые их реализуют. Никакие конкретные объекты в вашей системе не реализуют несколько интерфейсов. Вызовет ли это проблемы в будущем? И если да, то какими они будут?..

Продолжаю набор на занятия для неначинающих (миддлы сеньоры), 3 места закончились за 1:18 минуты...

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

(все старые материалы для донов быстро сгорают)

=

Новые материалы для ментатов Лаборатории.

В раздел "Элитный программист" добавлен материал
104) Вглубь потока: прекрати борьбу (база)
Медленная, думающая часть мозга (S2 по Канеману) следит за вами во время работы: рассказывает о том, что вы делаете, сверяет это с правилами, пытается управлять каждым действием "вручную" (микро-менеджмент). Это ваша префронтальная кора осуществляет сознательный контроль, требующий усилий...
Вторая система S1 - автопилот: само по себе отработанное умение писать код без вашего участия. Он знает, как реализовать тот или иной проект, гораздо лучше, чем я могу себе представить...
Проблема заключается в том, что наблюдатель не хочет расставаться с ролью управляющего, и вот что с этим делать...

В курс карьеры добавлен 149-й материал "Инди-хакерство: финал".
Засада в том, что если вы прислушаетесь к типовым бизнес-советам, то снова окажетесь в очередном положении "с 9 до 18", работая над чужими проектами (если вы фрилансер/консультант), которые вы не любите, с людьми, которых вы не любите, за исключением того, что вы работаете теперь по 12 часов в день вместо 8, и всё равно не можете оплачивать счета за квартиру...

=

"Функциональные архитектуры" 183(+2) топиков.
Мета-рекомендации: CQRS для SDLC. Agile, Jira и Confluence в эпоху AI умерли, что теперь становится исполнительной системой, и почему бэклог перестаёт быть главным.

LPF закончен, куда и как дальше => тренажёр спецификаций (первая часть готово ~80%)

=

"ЛаМПовое":

AI-бизнес на засланных казачках, полиморфные типы в C++26, харнес база

=

Мы здесь, потому что это трудно. 💪🏻

=

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

"Охотники Дюны"

Немного про тренажёр спецификаций: это такая интерактивная история, как девопс Олег устраивается на новую работу, и встречается с кучей проблемных спек и всяческими интригами. Каждая небольшая серия под некоторый вид формальной логики, по 3-5 задачек - от простой на 5-10 минут до посложнее на 20-30 минут. Цель: научиться правильно рассуждать спеками.

Код весь hand made 100% (windows), задачки готовлю по заветам Теренса Тао в процессе тесного чатинга с продвинутыми модельками. Наверное можно и навайбкодить, но всё равно придётся редактировать и перепроверять, в каких-то случаях только SAT-солвер поможет (например, семантика Крипке), а в более тяжёлых логиках нужны более мощные модел чекеры (например TLA+ для темпоральной логики), а то и пруф-ассистанты.

Кстати с удивлением выяснил, что и в Lean4 и в Coq/Rocq и в Isabelle/HOL нишево формализованы лишь базовые логики (пропозициональная, классическая предикатов...), а едва например появляется фикс-поинт, автоматика исчезает, и надо много думать ручками интерактивно. Поэтому особо тут фиг навайбкодишь если не PhD (ну ладно, если не мехмат:), и это радует. Возможно придётся пилить свой прувер )

Название не придумал пока, например хорошо SATisfactory :) но занято.

Мыслить спеками - теперь база, но главное конечно не знание формализмов, а логическая грамотность. Нейронки всё лучше пишут не только код, но и доказательства, пред- постусловия и инварианты в Lean/Dafny/Coq, однако узкое место -- правильная формулировка, что нужно формализовать, а это как раз навык человека будет ещё долго (естественный язык размыт, а логика нет). Тесты проверяют отдельные примеры, а формальная спецификация описывает свойства для всех случаев: при сотнях тысяч строк сгенерированного кода это сильный аргумент, согласитесь.

Да, 80% пользы вы получите за 20% усилий: строгая система типов, функциональная архитектура, контракты в коде, property-based тесты. И логиком становиться совсем не обязательно, но мыслить спеками -- в терминах инвариантов, кванторов, состояний, переходов, живучести и безопасности, станет ценным навыком, потому что именно на языках логики точнее всего можно поставить задачу сетке, и проверить результат.

Я дал ребятам первые задачки потестить =>

Во-первых, структурирование своих мыслей по поводу задачи - уже само по себе полезный и важный навык. Я об этом догадывался и раньше, прежде чем начинать делать задачу, сначала пытался всё подробно расписать на бумаге, что зачем и почему, что будет если А и что будет если Б, как и на что будет влиять. И ещё тогда заметил что когда сам себе составляешь такую спецификацию - код потом по ней пишется как по маслу (оно и не мудрено, всё ж уже загружено и прощупано в голове вдоль и поперёк). Очень выручало при реализации сложных задач.

Но тут надо поправку сделать, что я чем-то подобным как раз занимаюсь когда спеки пишу для агента.

Самое бесценное, а именно что из №... вообще не следует, что надо (агенту) бэкапы делать, мне пришло только вечером лежа в кровати :))
Спасибо огромное, 10 системных аналитиков из 10, мне прямо очень понравилось !!!

=

Из тренажёра:

Первую спецификацию Олегу выдали для разминки. Это был сервис заказов, который в компании все называли "тот, что падает по пятницам".

— А как же они договорились о спецификации?
— Никак. Каждый вписывал свои пункты ночью, пока другой спал. Поэтому там "ровно одним способом" и рядом "неверно, что одновременно обоими".

На вторую неделю Олега допустили к продовой корзине. В «ОблакоСофте» корзина была местной легендой: товары в ней иногда исчезали, а иногда появлялись чужие. Пользователи писали в поддержку: "Кто положил мне в корзину шесть пылесосов?"...

Ещё там был спор про релизы: blue-green или canary. Одна фраза говорила "canary только с Prometheus и алертами", другая — "если есть Prometheus и алерты, то canary".
— Это же одно и то же, — сказал Олег.
— Вот и наш прошлый стажёр так сказал, — ответил тимлид. — Подправил спеку. Мы потом месяц катили релизы через blue-green при полностью настроенном мониторинге. Без резервного окружения.
— И как?
— Пылесосы...

ex falso quodlibet

Продолжаю работу с ментатами 🤓

Вообще, как некоторое резюме задания - очень частый соблазн поставить проверку "а вдруг сюда откуда-нибудь дойдут неконсистентные значения параметров". Это очень частая мысль и на самом деле я раньше думал, что это хорошая мысль - значит я хороший программист, раз вижу потенциальную опасность и ставлю защиту :) А оказалось, что это признак плохого дизайна системы...

Раньше я считал «хорошим кодом» максимально точные типы и длинные говорящие имена. Но именно точность множества и порождает мономорфизм: чем конкретнее тип, тем больше сущностей и реализаций ему соответствует, и тем больше мест, где можно ошибиться...

Я приступал к курсу с мыслями:
- у меня с именами переменных всё ок, я же стараюсь давать понятные имена :)
- стиль кодирования влияет только на косметические изменения, а не на суть кода.
Как же я ошибался)

выяснилось, что около 40% сессий пользователей покрываются двумя сценариями, а остальные 60 еще несколькими тысячами...

Оказалось, что OpenSpec даёт такую схему работы, к которой я так или иначе стремился раньше. Думаю, что это результат чтения ваших блогов. В моей голове крутилась мысль, что с ИИ надо работать через спецификации: задаём ему крутую спеку, а код пускай лежит на агенте, главное чётко описать требования...

(и заодно хочу поблагодарить за сайд-квест с ИИ-разработкой, спасибо, было очень полезно, сам бы долго еще полз к этим темам)

В целом концепция логичная и понятная, стараюсь аналогично делать в повседневной практике.
Регулярно сталкиваюсь с прямо противоположными ситуациями от коллег :)

Есть большое множество способов избавиться от if и их можно долго изучать, но всё равно оказываться в ситуации, когда тебе не понятно, а как убрать условие в каком-то конкретном случае. Хорошо, что все эти способы сводятся к паре мета-правил из которых и вытекают многочисленные советы. Тут поймал себя на мысли, что большая часть материалов Лаборатории сводится к таким сильным правилам и идеям, которые лежат в основе множества разнообразных подходов.
Нам достаточно понять эти правила и научиться их применять.

Так приятно, когда ребята уже сами замечают твои мета-схемы )

ФА ещё для меня была крайне интересна потому, что я сразу начал её прикладное применение. Уже и разобрался с value objects, почему они независимы от api моделей, как и почему не делать двойных одинаковых валидаций и т.д. Та мозаика, которую я сам нащупывал (я писал о предыдущем проекте в [...]), теперь после ФА сложилась в цельную непротиворечивую систему.
Я в неё реально погрузился с головой просто забыв обо всём остальном.
Кстати, хорошо что ФА закрыто для начинающих, мне кажется не познав болей на реальном проекте, невозможно по достоинству оценить саму ФА...

- Стараюсь решать задачки в строгой последовательности "декомпозиция - спецификация - дизайн - код" - тоже есть успехи, отчасти благодаря openspec. Но в первую очередь благодаря вам :)

Первое впечатления от курса по теории категорий великолепное. Понимаю что треком «как понять в программировании все» вы мне заложили свинцовый фундамент. Помою тогда я еще плохо умел учиться и просто материалы из подготовительных постов в ВК конспектировал в тетрадку.

Интересная кстати связка с треком по вычислительным моделям, я и сам не замечал.

Честно сказать, мало что могу добавить, кроме повторяющихся слов про проверке типизатором вместо компилятора.
Но наверное это и неплохо - оформилась мысль, что каждый проект на питоне требует (требует!) таких проверок,
потому что надеяться на разум или даже !сверх!разум, как показывает старкрафт, опрометчиво.

Я ровно с этой проблемой столкнулся на проекте [...], где мы пилили агентов (по СИ "156) First principle для внедрения AI в проект").
Так там ещё они постоянно пытались свои недоделанные приляпки заставлять использовать, вместо того же OpenTelemetry, но хотя бы да, двигались в правильную сторону.
Действительно, для недетерминированной системы старые методики наблюдаемости неприменимы.
Да более того, один из агентов как раз по метрикам был в полном порядке, но по факту нёс околесицу и дальше одного инструмента не уходил (а должен был минимум 3 использовать из 5).
Но тогда я чётко для себя понял что без тотального контроля что куда и почему разбирать поведение системы на проде, да и на тестовых контурах, невозможно.
Ещё заметил, что бизнес часто пытается внедрить GenAI туда, где бизнесово детерминированное поведение, которое можно однозначно посчитать, но вот требует потом точно такого же детерминированного поведения от недетерминированной системы.

Это кстати экзистенциальная проблема. когда менеджеры продолжают относиться к нейронкам как к обычным инструментам (библиотеки фреймворки), и пытаются их тупо "внедрять", но это ведь совсем другое, это куда ближе к иррациональным человечкам...

Вообще за последнее время столько новой информации, что "голова" пухнет =)
Вроде только начал разбираться с SDD, а уже вижу spdd, openprose и что лучше пока не понятно.
Хочется попробовать всё, но время ограничено и не успеть (несмотря на то, что использование агентов пока позволило автоматизировать часть ручного труда и успеваю в рабочий день изучать новое) =)
С одной стороны - появилось забытое чувство радости от изучения нового, когда только начинал путь в айти.
С другой стороны - понимание, что каждая новая версия будет обесценивать часть проделанной работы за счёт того, что станет умнее. Но кажется здесь и нужно находить и сосредоточиваться как раз на том, что не зависит от модели (в частности о чём пишется в ФА).
Вообщем здесь ещё работать и работать, но хотя бы появилось некоторое начальное понимание...

Да, и теоркат в помощь) Нейронки формальные описания хорошо воспринимают, а когда везде присутствует композиционность, система хорошо декомпозируется, и сломать что-то довольно сложно.

И вот база айтишки с аишкой на годы вперёд: одним из главных навыков, а скорее всего, и самым главным, станет мышление спецификациями. Спеки теперь -- это основной рабочий инструмент архитектора (разработчика в целом), которым раньше был код как главный артефакт, а документация обычно отставала. Но теперь код можно перегенерировать заново, и (вероятно) точное описание того, а что вообще нужно, остаётся единственным источником истины в проекте.
 
AI делает то, что вы описали, а не то, что вы подразумевали и имели в виду. Даже небольшая неточность в спецификации сразу превращается в неправильный код, причём в больших объёмах; цена нечёткого мышления сильно растёт (а откуда чёткое мышление взять-то? :).
 
Спецификация и есть тест! Чётко заданные контракты (в идеале, системой типов), инварианты и граничные случаи легко превратить в тесты, ведь без них нечем оценить, правильно ли нейронка всё сделала.
 
Спеки -- память проекта. Как говорил выше, на длинной дистанции спецификации и записи о ключевых архитектурных решениях единственные дают AI контекст, без которого он просто ничего не сможет сделать.
 
База =>
 
Думать контрактами: что модуль принимает, что гарантирует, что запрещено. Это собственно тип модуля, только в математическом смысле, о чём подробно пояснял Роберт Харпер, формализовавший языки ML и подготовивший кучу курсов для Карнеги-Меллона, в книге "Модули важнее всего" (в СИ делал выжимку из неё; на бусти скоро будет гайд).
 
Явно задавать инварианты и граничные случаи, то есть то, что "очевидно" человеку, но не сетке.
 
Уметь проводить границы (На "Функциональных архитектурах" у меня есть большой модуль "Математика DDD"): делить систему на части, каждую из которых можно описать и проверять отдельно.
 
Записывать, почему принято то или иное решение, а не только что решили.
 
Видеть, что не описано: уметь находить дыры и неоднозначности в требованиях.
 
Теория категорий очень в помощь для тотальной композиционности всего и на всех уровнях.
 
=
 
И, да, если системный аналитик - самозванец после онлайн-курсов, который не понимает, как подобные системы работают на деле, то он выдумает красивую, но нереализуемую или тормозную спецификацию; то есть инженерная экспертиза хотя бы на уровне крепкого мидла обязательна.
 
Короче, ценность разработчика-27 быстро смещается от умения написать код к умению точно сформулировать спецификации и умению грамотно проверить результаты. Кто умеет ясно и чётко думать спеками и формализовать требования, только и останется в айтишке!

=
 
...Это всё был прогрев на мой новый курс "Стань системным аналитиком с нуля на зп 512k за 4 недели всего за 128 тысяч рублей можно в кредит"!!1

Шутка.

Ментатам по этим темкам будет бесплатно доступен тренажёр спецификаций, уже скоро. Нет, не навайбкоженная фигня. Делаю в основном вручную, качественный контент/задачи без глубокого понимания формальных логик на уровне PhD тут фиг сделаешь :) Понятно, что вайб-клоны появятся быстро, но мне не жалко, чем больше будут учиться формально рассуждать, тем только лучше.

...Но есть маааленький нюанс: на длинной дистанции проект, созданный AI, ломается более чем полностью. Без проектной дисциплины он деградирует на порядки быстрее обычного.

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

Без тестов любая правка может незаметно сломать что-то в логике в другом месте (особенно это страшно в асинхронщине; помните "Незримые механизмы логики"?). На проекте в сотни тысяч строк никто не заметит этого вообще, да и кому замечать-то?

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

Архитектура постепенно расползается: AI хорошо дописывает новое, но слабо переделывает старое, потому что нету никакого понимания. В итоге код стремительно раздувается и запутывается, и технический долг растёт на порядки быстрее, чем в проектах, которые пишут люди.

Абсолютная база: тесты. Это и память проекта, и спецификации в некотором смысле, и защита от регрессий. На длинной дистанции без них вообще никак, сколь бы дорого они не обходились.

Документация: ТЗ, спецификации, описание архитектуры, записи, почему приняты те или иные ключевые решения.

Модульность: мелкие независимые части с понятными границами, чтобы AI мог работать с куском кода, не видя всё целиком (DDD в помощь).

СисА :) Тот, кто отвечает за архитектуру, и имеет целостное её понимание.

=

Короче, запустить весьма приличный проэкт просто "словами в микрофон" реально уже сейчас (если есть баблишко, сотня килорублей на токены :). Даже 100 тысяч строк кстати это очень приличный размер, для сравнения, типовая мобильная игра - это 5, максимум 10 тысяч строк ручного кода. Правда, и AI код раздувает очень сильно, в разы точно, а в сравнении с функциональщиной, так и на порядки.

Так вот, чтобы многими месяцами/годами развивать любой серьёзный проект, нужна полноценная инженерная культура. Нейронка будут постепенно лучше справляться с памятью и контекстом, но необходимость держать продукт и кодовую базу в порядке с помощью человека никуда не денется.

Действительно, нейронка сейчас вполне может создать проект среднего размера на сотни тысяч строк кода просто по словесному описанию. Причём и архитектуру продумает неплохо, и сопровождать и развивать в принципе тоже сможет без излишних затрат. Хотя в целом конечно и платить за это хорошим моделям придётся прилично, суммарно - от одного доллара на каждые 100 строк добавленного/модифицированного кода.

Засада в том, что проект состоит из сотен/тысяч мелких решений: как работают экранные формы, что делать при той или иной ошибке, как вести себя в "редких" случаях (коих всегда воз и маленькая тележка), что важнее - скорость или надёжность. Если их не указать явно, нейронка примет такие решения сама, и далеко не всегда так, как вы представляли себе, т.к. читать мысли пока не умеет.

Кроме того любой проект - это всегда множество внутренних компромиссов, например между откликом и надёжностью; теоремы CAP, FLP (Fischer–Lynch–Paterson), что разбирал на Функциональных архитектурах, доказаны математически. Заложишься на "поскорее сделать", и проект через месяц заткнётся на 50 юзерах или будет лагать по 10 секунд. Ну или бот РКН штрафанёт на миллиончик за утечку персданных :)

=

Ведь по сути полное и точное описание продукта и есть программирование :) только на условно естественном языке. Карпатый недаром недавно рекомендовал упрощённые технические языки вроде ASD-STE100; я за более формальные подходы, потому что порог входа с ними выше, но зато и эффект куда мощнее.

Самые впечатляющие случаи, где AI сам написал огромный проект, как правило, делались на качественной спецификации и больших наборах тестов. Например, когда переписывали компиляторы, там уже был и стандарт и тысячи готовых проверок. А без спек и тестов уже 100 тысяч строк кода нейронка вдолгую совсем не потянет, проект быстро развалится.

Короче, роль чела сильно смещается к продвинутому системному аналитику: тестировщику с качественным фидбеком + продакту + архитектору. Собственно, заказчик всегда "словами описывал" желаемый продукт команде разработчиков, и работало это только при постоянном общении, бесконечных уточнениях и формальной приёмке. С AI всё это и остаётся, только быстрее (и дешевле?).

В любом случае, всегда требуйте в таких процессах от AI задавать уточняющие вопросы "до понимания на 90%", и писать хотя бы регрессионные тесты. Жертвовать ими можно, только если не планируете развивать проект вдолгую.

Мой подход к кибербезу кстати стратегический, а не эти ваши SOC GRC DFIR/TH/MA ... Нормально делай - нормально будет ) Качественное проектирование, формальные методы, по определению снижают количество багов, особенно критических - и соответственно общее время разработки - во многие разы.

Вначале необходимость продумывания архитектуры вас замедляет. Но по мере того, как ваш проект растёт, вас начинает замедлять отсутствие продуманной архитектуры.
Создайте Big Ball of Mud, и агенты с радостью продолжат копаться в говнокоде.
Создайте структурированную систему с разделением задач и чёткими контрактами (типами) между модулями, и агенты будут продуктивно следовать такому шаблону.

Если AI продолжает и продолжает ошибаться в коде, прекратите давать ему больше и больше инструкций, что нужно сделать. Давайте ему наоборот больше информации о том, что должно оставаться неизменным, а что вообще нельзя/не надо делать.

Думайте инвариантами и safe-паттернами на формальных языках, которые нейронке сложно сломать ("Функциональные архитектуры" в помощь).