Спека > инструмент

На днях OpenAI выпустили Symphony - handoff-систему для оркестрации агентов.

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

Там нет "готового серебряного инструмента". Есть спецификация и фоном - пример реализации.

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

Сейчас инструменты растут как грибы. Выходит один проект - через пару дней уже десятки аналогов.

Сегодня день рождения проекта CutCode - ему уже 5 лет. Из них 4 года я делаю MoonShine, и его разработка сводилась к тому, чтобы угодить всем: кому-то не нравится цвет, кому-то расположение блоков, логика… У каждого своё мнение. Мы пытались делать универсально - увеличивая хаос в кодовой базе.

Разработка стала доступна почти каждому.

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

а потом получают:

• проблемы с безопасностью
• невозможность нормально поддерживать код
• архитектурный хаос

Мы уже видим это в продуктах вайбкодинга вроде openclaw, zeroclaw и им подобных.

И вот здесь появляется, как мне кажется, главный тезис нового этапа:

Спека > инструмент

Не готовый инструмент становится центром ценности.
Ценностью становится спецификация:
• какой стек выбрать
• как продумать инфраструктуру
• где будут архитектурные риски
• какие ограничения нужны сразу

А всё остальное уже можно достроить поверх.

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

Что если Symphony - это только первый шаг?
И скоро мы будем продавать не инструменты, а спеки?

Удачи, веселья, не сдохни! Всем хороших выходных.

Хочу просто порекомендовать фильм, который посмотрел вчера — «Удачи, веселья, не сдохни!»

Как говорит один мой друг: жанр — «грибной».
И это, кажется, лучшее описание.

Фильм странный, но цепляет.
Смотришь и ловишь себя на мысли: а мы вообще далеко от этого всего?
Как будто сами уже где-то рядом со шлемом, который подключает к другой реальности.
А может уже подключились.
А может, и не отключались никогда.

В общем, кино своеобразное, но мне зашло.
Гляньте на выходных, а потом расскажите, как вам.

Понял, что в последнее время перед ревью мне не хватает понимания, кто именно писал реализацию. Похоже, теперь во всех моих open-source проектах появится такой PULL_REQUEST_TEMPLATE.md.

Мне ведь тоже важно понимать, какую модель использовали и насколько тщательно подходить к ревью. Мало ли, вдруг там всё на дипсиках генерировалось 😂.

Стало грустно, значит надо писать код!

Последние N месяцев не пишу код руками. N - потому что уже забыл, сколько. Оттупел, возможно. Все это время где-то внутри присутствует тоска. Как будто у меня на балконе стоит офигенный велосипед, который я обожаю: я продолжаю за ним ухаживать, мыть, но не вижу смысла на нем гонять, когда есть тачка. Нет задач, чтобы пойти и покататься на велике - все, что требуется, решает тачка. Да, так бывает, когда ты не в найме😊 Но внутри тоска и постоянное ощущение: а что, если я разучусь кататься на велосипеде? Я ведь столько лет потратил, чтобы кататься хорошо.

Вообще любые циклические мысли тратят кучу энергии. Мы обретаем силу, когда наши мысли чисты и нас не отвлекает лишний шум.

В общем, я тут недавно за день получил три краша от PhpStorm, разозлился и снес все продукты JB, установил Zed. Что хочу сказать? Ну, во-первых, как хорошо я умею соскакивать с одной темы на другую в одном посте😀 Но нет!

Zed - кайф при генерации кода с AI. Но я все-таки решил достать велосипед и погонять на нем - в общем, самому пописать код, и именно в Zed. Поддержка PHP тут близка к нулю, автокомплит - ад, автоперехода нет. И в таких условиях - прям кайф.

В общем, буду периодически устраивать такие вылазки с тачки на велосипед и кататься на нем по квартире (ну, в смысле, кодить в Zed вместо PhpStorm). Или просто пора работу искать 😀

Сегодня быстренько протестировал OpenAI Privacy Filter для поиска и редактирования PII.

Если коротко: это локальный open-weight фильтр для персональных данных. Он находит в тексте имена, телефоны, email, адреса, даты, номер счета, секреты и возвращает spans с byte offsets, после чего текст можно безопасно редактировать перед отправкой в LLM.

Хорошая новость: модель достаточно лёгкая по меркам локальных ML-инструментов. Checkpoint скачивается примерно на 2.8 GB, запускал через Docker на CPU. Это не LLM на десятки гигабайт, а специализированный PII-фильтр, который можно встроить перед прокси/LLM API.

Базовый пример работает нормально:

{
    "detected_spans": [
      {
        "label": "private_person",
        "text": "Иван Иванов"
      },
      {
        "label": "private_phone",
        "text": "79222222222"
      }
    ],
    "redacted_text": "Привет меня зовут <PRIVATE_PERSON> мой номер <PRIVATE_PHONE>"
}

Но на русском языке быстро проявляются те же проблемы, что и у аналогов. Без дополнительного fine-tuning на русскоязычных датасетах я бы не стал использовать это в production как единственный слой защиты.

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

{
    "text": "Привет - это Нормальное Слово",
    "detected_spans": [
      {
        "label": "private_person",
        "text": "Нормальное Слово"
      }
    ],
    "redacted_text": "Привет - это <PRIVATE_PERSON>"
}

Ещё один нюанс: телефонный номер иногда классифицируется не как private_phone, а как account_number:

{
    "by_label": {
      "account_number": 1,
      "private_person": 2,
      "private_phone": 1
    },
    "redacted_text": "Привет меня зовут <PRIVATE_PERSON> мой номер <ACCOUNT_NUMBER>! А меня зовут <PRIVATE_PERSON> и телефон - <PRIVATE_PHONE>"
}

По ресурсам в Docker на CPU получил такие срезы:

CPU RAM
1834.93% 3.838 GiB / 7.648 GiB
2348.13% 4.114 GiB / 7.648 GiB
2272.03% 3.279 GiB / 7.648 GiB

То есть примерно 18-23 логических CPU в пике и около 3.3-4.1 GiB RAM. Потоков внутри контейнера было около 55.

Вывод: штука рабочая и полезная как локальный PII pre-filter перед LLM, особенно если нужен контроль над данными до отправки наружу. Но для русского языка нужно либо дообучение, либо дополнительный слой правил/валидации, иначе будут false positives и нестабильная классификация категорий.

Офигенный подкаст, только что посмотрел. Многое из сказанного осознал совсем недавно, и кстати, автоперевод на русский на YouTube на высоком уровне.
https://youtu.be/IRCZ1Mt2a8M?is=Zj809HfkgFJFmFlg

На днях провел эксперимент с LLM.

Занимался реализацией задачи в проекте, где генерировать код LLM-кой запрещено. Сам проект абсолютно не готов для работы с ИИ, хотя глобально там есть общие универсальные скиллы по тестам, качеству кода, архитектуре и т.д. Они общие, но индивидуального контекста под проект нет.

Суть эксперимента была в том, что я со своими знаниями и экспертностью попробую дать на вход максимум контекста и в итоге оценю результат.

Контекст я готовил половину рабочего дня: делал референсы из ТЗ, собирал контекст из переписок, саммари из созвонов. Было подготовлено много артефактов.

Дальше я запустил генерацию и через 30 минут получил готовый код: покрытый тестами, полностью рабочий. Если отправить его в прод, никто даже не заметит подвоха. QA отчитается, что все кейсы выполнены и все гуд.

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

Что в итоге? Как вы думаете?

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

Это был рабочий мусор.

Думаете, вывод такой: «ха-ха, LLM делает мусор»?

Нет.

Эксперимент на самом деле завершился так, как я и предполагал. ИИ — это просто инструмент. Качественный контекст по задаче даст рабочее решение, но он не выполнит все ваши внутренние соглашения сам по себе.

А вот чтобы все было так, как вы хотите, хотя бы приближенно, нужно потратить кучу времени на подготовку проекта к работе с LLM: выстроить harness, дать примеры того, как нужно писать, и постоянно их поддерживать.

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

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

А дополнительную информацию модель уже должна получать через внутренний MCP: документацию, схемы, соглашения, примеры кода, контракты, историю решений и все остальное, что нужно для нормального погружения в проект.

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

Все это невозможно без смены мышления у всей команды.

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

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

Пока как-то так.

P.s. Манифест "AI Native - Новая культура мышления" уже доступен - https://ai-native.cutcode.dev