Уравновесим поток ура-ура новостей про ИИ.
Вот Саша Юмашев, очень крутой программист, основатель успешного SaaS-бизнеса, (лучшей) тикетницы Jitbit, подробно матерится (англ) на Claude Opus 4.6, что та не может сделать простую, монотонную работу в уже существующем проекте — заменить jQuery на ванильный JavaScript.
Текущие модели на самом деле дают гораздо более впечатляющие результаты на новых проектах (это и правда проще).
Люблю статьи Антропика, в них чувствуется живой человек, а не только пресс-релизы, как у OpenAI.
В этот раз исследователи нащупали пределы того, на что способны «команды» из агентов, работающие автономно, без участия человека: 16 агентов в параллели, в течении 2000 сессий разработали компилятор языка Си на Rust. Компилятор успешно собирает ядро линукса, QUEMU, ffmpeg, sqlite, postgres, redis, успешно проходит 99% тестов компиляторов.
Под капотом это несколько простых баш-скриптов, запускающих docker-контейнер с агентом, синхронизируется всё через git. Каждый раз, когда агент берет задачу, он коммитит файл с именем задачи в репозиторий, чтобы не было такого, что два агента работают над одним и тем же. Никакой хитрой оркестрации или «главного агента» с мастер-планом: каждый агент выбирает, что он считает самым важным, работает над этой фичей, сохраняет историю, и так в бесконечном цикле.
Звучит магически, но мне вся эта история напоминает очень крутую Машину Голдберга. Да, нейросети создают компилятор «самостоятельно», но рядом с ними 7 инженеров тратят несколько недель на филигранную настройку среды под это. Они следили, где модели затыкаются и корректировали упряжь, в первую очередь тесты и инфраструктуру, чтобы в следующий раз их не занесло.
Работу по написанию кода они заменили на работу по настройке упряжи.
И получили на выходе, конечно же, супер хрупкую штуку, которую невозможно развивать и поддерживать. Например, исследователи пишут, что так и не смогли создать таким способом работающие ассемблер и линкер, а некоторые проекты так и не скомпилировались; пытаясь исправить одну часть, нейросети ломали другую.
Это классическая ситуация, в которой оказываются команды со слишком большим техническим долгом. Тот самый легаси! Меня регулярно зовут делать аудиты и приводить такие системы в порядок, до боли знакомая картина.
В видео-анонсе Антропик пишет, что то, что заняло бы у команды людей месяцы, нейросети сделали за 2 недели. Абсолютно верно! Обычные команды разработки доходят до такого жуткого состояния легаси за годы разработки. С помощью нейросетей можно заспридранить этот процесс за 2 недели с минимальным участием людей! И стоит всего 20 тысяч долларов на API запросы!
То есть на выходе мы имеем полурабочее легаси без какого-либо пути к улучшению. Только если в обычном легаси у нас есть хотя бы углубленное понимание задачи, то в этом случае всё понимание задачи ограничивается тестами, которые они взяли на стороне как вводные для проекта. И попробуй ещё найти задачу, для которой существуют настолько же хорошие (восхитительные) тесты, как для компиляторов; человечество вложило в них человеко-годы!
Как говорил персонаж в сериале Чернобыль: «3.6 roentgen—not great, not terrible».
Гораздо важнее траектория развития способней моделей. 4-я модель «Опуса» еле-еле генерировала работоспособный компилятор. 4.5 первым прошел крупные тесты, но не мог скомпилировать реальные проекты. 4.6 вышедший на днях может компилировать реальные проекты. Что сможет следующая модель?
Исследование очень классное и тональность статьи идеальная — без лишнего хайпа. Рекомендую первоисточник.
Иллюстрация — тот самый вечный цикл, в котором крутились агенты.
Интересно: с одной стороны, вся эта движуха с нейросетями, агентами и прочим «запустим продукт за неделю».
С другой стороны, больша́я часть наших проектов — «разобраться в огромной 20-летней системе, половина которой на хранимках, половина в MSSQL, половина в PostgreSQL (хорошо если не Oracle), а большая часть в C++ и Delphi, чтобы вернуть прозрачность и управляемость, опять быстро вносить изменения / запустить тот же бизнес в новой географии».
В таких проектах нейросети тоже полезны, но главный ограничитель этих задач — не в скорости программирования или числе разработчиков (рук). Там главное — системное мышление, опыт, умение разговаривать с людьми, здравый смысл и вкус. ❤️
Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.
Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.
Дальше автор делает печальное наблюдение, что большинство программистов работают с плохим кодом, который увидели вчера. Мол, в таких ситуациях нейросети будут полезны.
—
Удивительно, как теория переплетается с практикой.
Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».
Более точная формулировка: в числе прочего, мы придумали, как привести их код в соответствие с предметной областью. Для этого мы нарисовали схему их предметной области, выделили контексты и домены, а потом придумали разделение ответственности по задачам между сервисами.
Красиво!
Как перезапустить проект технически?
Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.
Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.
Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?
Первый порыв любого программиста — переписать всё с нуля. Благо, проект ещё не очень большой, за месяца 3–4 парой программистов, наверное, можно управиться. Составить список фичей, написать их заново, потушить сервис на пару часов, импортировать данные из старой системы в новую и запуститься.
Но это — ошибка. Во-первых, мы не понимаем истинного объема бизнес-логики, который успел накопиться в коде. Скорее всего, сам клиент её недооценивает. Во-вторых, пока будем переписывать — проект продолжит развиваться. Придется догонять. В-третьих, любой, кто делал импорт данных, скажет вам, что это задача из ада, и чем старее данные — тем сложнее их вытащить. Настроить тестирование этого нового проекта будет сложно, да и полноценным оно не может быть по определению.
В результате, в момент включения новой платформы в продакшен, точно возникнут проблемы, которые придется героически исправлять «прямо сейчас», в стрессе. Мало предсказуемости, о реальном объеме работы мы узнаем только в самом конце проекта, при попытке переключения. Мы такое не любим.
Правильный ход — это strangler fig pattern. Пишем небольшую обертку для старого бэкенда. Этот новый бэкенд действует как прокси — передает запросы к старому бэкенду, запоминая сами запросы и ответы. Дальше выделяем первые эндпоинты бэкенда, которые мы можем запрограммировать заново, красиво. Дублируем эти запросы пользователей в старый и новые движки. Сравниваем ответы нового движка с ответами старого, исправляем ошибки. Накапливаем информацию в новую, аккуратно составленную базу данных. И только после продолжительного тестирования на живых данных начинаем отдавать пользователю ответы нового бэкенда. Берем следующую пачку эндпоинтов и повторяем процесс.
Получается, у нас нет момента «большого рубильника», который переключит весь трафик со старого движка на новый, мы «едим этого слона по частям». Переход со старого бэкенда на новый происходит плавно, незаметно для бизнеса. Ошибки в новой системе видны только программистам и не затрагивают клиентов.
Не менее важна предсказуемость. В первом подходе мы весь проект живем под дамокловым мечом — какие сюрпризы нас ждут при запуске? Во втором подходе мы размазываем эту неопределенность по всей продолжительности проекта, так что уже через пару недель можно увидеть реальную скорость разработки, включая исправление ошибок, и оценить общий объем работы и сроки.
Наконец, этот подход позволяет выкатывать новые фичи в продукте внутри нового бэкенда до окончания переезда, параллельно с рефакторингом.
К сожалению, кажется, что каждый молодой программист обречен пытаться всё переписать правильно с нуля. Технарь, предлагающий strangler fig pattern, не лучше, просто за его обучение уже заплатил другой заказчик.
На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.
Классная и довольно безумная история о Unicode-символе, предназначение которого никто не знает.
Unicode — огромная таблица письменных символов, которые нужны человечеству. Даже больше, это стандарт, описывающий, как мы — люди что-либо записываем.
Именно благодаря юникоду мы можем написать в одном сообщении слово на русском, слово на английском, слово на арабском, китайский иероглиф и разбавить это всё эмоджи. Технически это чудо.
Стандарт включает 144 тысячи символов из 159 систем письма. В общем, это система, в которой соседствуют буква «а», эмоджи «❤️» и древнеегипетский иероглиф члена «𓂸».
Не знал, что в юникоде есть и такие вот затерянные символы, которые переехали в него из каких-то прошлых систем. Великая сила преемственности (legacy).
Выглядит символ так: «⍼», а называется он «прямой угол с зигзагообразной стрелкой вниз» 🤷♀️
Слетал в первую командировку за этот ковидный год, представил результаты аудита крупной финтех компании в Казахстане. Полгода говорили с руководителями, менеджерами и инженерами, разбирались в архитектуре, вместе с внешними экспертами изучали исходный код огромной легаси системы на 5 языках программирования.
На этой неделе представил результаты аудита на очных встречах и доредактировал отчет. Каждый раз начинаю писать такие отчеты как формальный документ, а заканчивается тем, что объясняю высшему руководству как устроена разработка на пальцах. Такой довольно дорогой персональный курс обучения IT-разработке для высшего руководства, кастомизированный под конкретную ситуацию плюс специфичные для ситуации рекомендации. Просто рекомендации не работают, а когда руководство понимает, какая логика у происходящего — тогда инвестиции и изменения более вероятны.
Конкретно в этом случае, бойцы, готовые менять разработку в компании в лучшую сторону уже есть, нужна политическая воля и бюджеты. Надеюсь, наш аудит эту волю даст.
Изменения уже начались. Например, даст бог через полгода-год члены команды смогут спокойно уходить в отпуск. Слышали фразу «я уже давно не был в отпуске, везде беру с собой ноутбук и не выключаю телефон»? Это — красный флаг. То, насколько часто и полно ваши инженеры отключаются от проекта (уходят в отпуск) — четкий маркер зрелости инженерной организации. Обычно, за этим, казалось бы, простым симптомом кроется «целый букет заболеваний», мешающих бизнесу развиваться и несущих серьезные риски.
А ещё, я впервые увидел большие горы и встретил день рождения в горах ❤️
Сегодня я видел небольшой самодельный ERP (много мелких крудов типа оформления отпуска) на скале, с Кафкой и Кассандрой. Там есть блоги. На скале.
А вчера — высоконагруженное e-commerce решение с ядром на битриксе.
Не могу решить, что мне нравится больше 👀
Мой учитель по психотерапии говорит, что почти в каждом терапевте есть мазохистическая часть личности, иначе в профессии делать нечего. В IT-аудите — похожая история.
Ещё круто, что как не издевайся над здравым смыслом — все равно ведь работает и даже деньги зарабатывает. Мир шире и богаче, чем я себе представлял.
Раз уж речь о NYTimes, вот вам свежая статья от их вице-президента по инженирии (VP of Engineering, non penis canina) про то, как они изобрели свой собственный язык программирования.
Всё началось с желания показывать имя зарегистрированного читателя прямо на главной странице в 2001 году. Чуваки решили, что PHP + CGI будут тормозить при больших нагрузках и придумали небольшой компилируемый язык. Ну а дальше как всегда. Закончилось тем, что все страницы NYTimes компилировались в код на этом самопальном языке Context и исполнялись в специальной виртуальной машине. А ещё на нем работала баннерокрутилка. А ещё собственная система сборки.
Я это пишу и чувствую, как волосы на моей шее встают дыбом. Есть в этом даже какая-то своя безумная красота.
Автор признает, что это была ошибка; особенно трудно было с поиском новых программистов.
Я в Медузе часто равнялся на NYTimes. Я давно понял, что не боги горшки обжигают, но такие вот подтверждения того, что мы все люди — очень ценны. Чуваки большие молодцы, что не стесняются рассказывать о таком (приурочена статья тому, что они только что выключили последнюю строчку на Context).
Ну всё, теперь можно всё.
P.S. Теперь у них там всё модно молодежно (React, GraphQL, Apollo), как и ожидается в Нью-Йорке.
Душераздирающая статья про COBOL. Это такой язык программирования из 1960-70х, на котором написано некоторое число банковских систем, которые безумно дорого заменить на свежие. Теперь у директоров банков проблема - специалисты не то, чтобы на пенсии - оттуда ещё можно вытащить человека, предложив достаточно много денег; они умирают от старости. И история компании, которая специализируется на такого рода поддержке. Молодежью там называют сотрудников, которым по 40-50 лет. Какой разительный контраст со смузи-тусовкой.
http://mobile.reuters.com/article/technologyNews/idUSKBN17C0D8