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

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

Всеволод выделяет внедрение горизонтальное (по задачам) и вертикальное (по бизнес-процессам) и говорит, что посчитать эффект от вертикального внедрения проще, и оно полезнее для компании. Для иллюстрации - суммаризация документов с помощью ChatGPT - горизонтальное внедрение, работа с претензиями покупателей - вертикальное.

Сотрудники по своей инициативе внедряют нейронки горизонтально, и отсюда выходит, что ~90% организаций уже внедрили куда-нибудь какой-нибудь AI - а в отчетах о прибылях и убытках это редко заметно. Всеволод видит выход в платформах - системах, которые помогут быстро и гибко строить решения под бизнес-процессы.

Все так, но есть нюанс.

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

"Гибкие, адаптируемые системы, которые легким движением мышки будут встраиваться и адаптироваться под бизнес-процесс", по мере роста превращаются в Тришкин кафтан из басни - вы легко правите одно и так же легко ломаете другое, и так по кругу.

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

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

С другой стороны бизнесу не всегда понятно, почему IT жужжит, как пчелка, а в итоге получается то же, что и вчера (ну разве что с перламутровыми пуговицами).

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

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

Ушел применять в своей работе.

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

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

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

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

Кратко про цензурированные данные:

Мысль пришла к лосю не сразу
Мысль пришла к лосю не вся
Очень долгими путями
Ходят мысли до лося
(с) Дочь Рассказала

В несколько более сложных словах тут https://kolodezev.ru/censored-data.html

Записали с Валентином Малых новый Капитанский мостик, предпоследний в этом году.

В следующую субботу подведём итоги и завершим сезон подкастов.

Мы записываем полуторачасовые разговоры, интересные мало кому, кроме нас самих. Кажется, что бОльшая часть людей видео не смотрит, а читает в пересказе, например вот в таком https://300.ya.ru/v_wdGGxo0U

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

Шутить надо так, чтобы не только люди поняли, но и нейронки не переврали. Будем учиться.

Сам капитанский мостик тут https://kolodezev.ru/data-capitan-25.html

Написал шпаргалку про то, как оценивать эффект от внедрения искусственного интеллекта. В основном опирался на Методику от ассоциации Финтех, но и от себя нашлось, что добавить.

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

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

Статья https://kolodezev.ru/ai-value-estimation.html

Нетфликс тоже написал шпаргалку для своих поставщиков - где можно и где нельзя использовать нейронки генеративный AI. Если кратко:

* в процессе обсуждения и генерации идей - можно
* для генерации второстепенных материалов, которые могут попасть в камеру - на свой страх и риск.
* в прод - после согласования с менеджером

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

Если посмотреть в табличку внимательнее - Нетфликс беспокоят исключительно юридические риски.

Но про фантазию сказано красиво, что уж там.

Сама шпаргалка https://partnerhelp.netflixstudios.com/hc/en-us/articles/43393929218323-Using-Generative-AI-in-Content-Production

Анекдот "чукча не читатель, чукча писатель" перестал быть анекдотом и стал реальностью. Например Хабр с его технической аудиторией и строгой модерацией, картинка взята тут https://habr.com/ru/articles/979860/

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

Таков нейрослоп, контент-зомби. И он проходит все необходимые фильтры (детекторы AI, модерацию, ревью на конференциях и проч).

Зомби-контент палится на мелочах, но в мелочи вчитываются все реже. Мы торопимся. Отправляем статью в нейронку, читаем только краткое содержание, странности относим на счет криво работающей ChatGPT.

В моем детстве многие покупали книги сериями "по подписке", примерно как подписка на рассылку, только раз в полгода и не сообщение в канале, а увесистый пакет с книжками. Серии томиков классической литературы хорошо смотрелись в шкафу за стеклом. Многие их покупали и не читали (стоят красиво, ну и норм).

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

На Озоне есть целый раздел с чучелами книг.

Говорят про "мертвый интернет", написанный роботами для роботов - но муляжи у нас и в оффлайне. причем давно.

Есть целая куча институтов, выдающих муляжи дипломов. Есть общепит, в котором продают и покупают муляжи еды 😉

Это норм. Муляжи хорошо помогают загораживать дырки в стене.

Заметил, что натыкаясь на очередной муляж, на автомате задумываюсь - какую именно дырку он заслоняет.

Записали с Валентином Малых последний в этом сезоне Капитанский мостик.

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

Это как если бы автомобили дешевели на 1% в день - имело бы смысл выждать и купить машину получше. Или даже так - выгоднее было бы не покупать вообще, а брать в аренду, потому что зачем такой дешевеющий с каждым днем актив.

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

Есть о чем подумать в новогодние праздники.

Сам подкаст на площадках и еще тут https://kolodezev.ru/data-capitan-26.html

Говорят, AI еще не пузырь и не пирамида. Ну не совсем пузырь. Ну не такой пузырь, чтобы беспокоиться. Ежедневно обновляемый дашборд, чтобы не беспокоиться каждое утро -
https://boomorbubble.ai/

Красивое:
* оценка отрасли - 33 годовых оборота.
* Оборот удваивается каждые 9 месяцев
* отрасль оттянула на себя 0,8% GDP - думаю что с обеспечивающими производствами будет больше 1%,
но даже так в большинстве стран малярия, СПИД и туберкулез больше влияют на GDP, чем искусственный интеллект. https://en.wikipedia.org/wiki/Economic_impact_of_HIV/AIDS

В общем, все еще не так страшно, как иногда говорят.

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

В конце прошлого года все пошло не по плану. Отменил все мероприятия, вышел из программных комитетов, перенес на следующий год всю движуху, и доклад на датаелке тоже отменил.

Но, как нас учит Пелевин, Божья любовь к человеку проявляется в великом и невыразимом в словах принципе "всё-таки можно".

24 января в Москве на датаелке будем записывать вживую Капитанский Мостик с Валентином Малых и Александром Дьяконовым. Датаелка - бесплатное мероприятие, но регистрация кончается сегодня.

Приезжайте
https://ods.ai/events/data-elka-2025-vk-offline-msc

Декларативное обучение

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

Когда учишь взрослых людей, половина из них уже знает то, что ты собираешься объяснить. Второй половине не хватает базы, чтобы тебя понять. У первых ты вызываешь скуку, у вторых - священный трепет. Пользу не получают ни первые, ни вторые.

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

Если бы наши объяснения шли в утиль не в 99% случаев, а, скажем, всего лишь в 90%, мы смогли бы увеличить полезность обучения на порядок. Так работает индивидуальное обучение - мы выясняем, что знает ученик, и подстраиваемся под него.

Но это хоть и офигенно, но долго, дорого и не масштабируется.

Я могу прочитать курс по ML System Design на 2000 человек, и примерно для 40 из них он будет полезен. Или выучить двоих за это же время в индивидуальном порядке. Получается, что эффективнее кидать лекцию в толпу и надеяться, что к кому-то она прилипнет.

В программировании есть императивные и декларативные языки (деление условное, но на полях этой заметки мы пропустим). Императивные языки говорят компьютеру, какие шаги предпринять. Декларативные определяют результат и говорят - добейся его как умеешь.

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

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

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

Итак, декларативное обучение:

1. Декларация навыка. Пишем, чему мы хотим научиться.
2. Декомпозиция навыка. Просим ChatGPT разобрать навык на части
3. Тестирование навыка. Просим ChatGPT составить список вопросов для проверки навыков.
4. Анализ пробелов. Смотрим в список вопросов и выбираем те, в которых мы сильнее всего плывем.
5. Заполнение пробелов. Ищем учебник или спрашиваем ChatGPT.
6. Тестирование. Пробуем применять навык. Записываем проблемы, с которыми столкнулись, и рекурсивно применяем к ним декларативное обучение - то есть декомпозируем проблемные части на поднавыки и т.д.


ChatGPT тут выбран условно, Qwen тоже подойдет.

Например:

Желаемый навык: Уметь XXX.
Декомпозиция навыка: Составь список знаний и навыков, которые нужны, для того, чтобы уметь XXX.
Тестирование навыка: Составь список контрольных вопросов для выявления пробелов в умениях человека, который учится уметь XXX.
Заполнение пробелов: Приведи пример идеального ответа на вопрос (берем вопрос из предыдущего ответа, в котором плаваем).

Два побочных эффекта:

1) Не нужен команде как наставник в технических навыках
2) Еще более нужен как менеджер, выявляющий нужные навыки и обучающий эффективным техникам самообучения.

Таков путь.

Эволюция интерфейсов (и наше место в мире)

Люди читают с разной скоростью. Кто-то читает 60 слов в минуту, кто-то 400.

Среднего размера художественная книга состоит из 80 тысяч слов. Это 3 часа быстрого чтения или сутки медленного.

Если выделять на чтение по четыре часа в неделю (многие могут себе такое позволить), получится 200 часов в год, то есть 60 книг для быстрочитающего или 8 для читающего медленно.

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

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

Современные нейронки общаются с нами текстом. Текст - новый интерфейс приложений.

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

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

Когда интерфейсы станут голосовыми - у нас у всех улучшится дикция.

Потом будут нейроинтерфейсы, и нечестное преимущество получат лысые, на них лучше будут работать шапочки с электродами.

Начинается большая переоценка человеческих навыков.

Когда-то очень ценилась мускульная сила. Теперь бульдозер сильнее любого качка. Ценился громкий голос - микрофоны с усилителями уравняли нас и тут.

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

Как писал Вергилий двадцать с половиной веков назад, правда по другому поводу:

Смогут другие создать изваянья живые из бронзы
Или обличье мужей повторить во мраморе лучше,
Тяжбы лучше вести и движенья неба искусней
Вычислят иль назовут восходящие звёзды, — не спорю:

Римлянин! Ты научись народами править державно —
В этом искусство твоё! — налагать условия мира,
Милость покорным являть и смирять войною надменных!

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

Техдолг - хороший, плохой, злой

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

К сожалению, работа "правильно" отнимает ресурсы команды, удлиняет Time to Market и нервирует продактов.

Долг бывает разный. Например, микрозайм на выпивку - плохой долг. Большие проценты, отрицательная отдача на инвестиции. Чем меньше таких долгов, тем лучше.

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

Долг бывает хорошим. У многих бизнесов доход ограничен размером оборотных средств. Больше денег в обороте - больше доход. Если обслуживание долга обходится дешевле получаемой прибыли, это хороший долг. И чем больше его, тем лучше.

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

Айтишники боятся техдолга, но с удовольствием берут IT-ипотеку под 4% годовых, и не торопятся ее гасить.

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

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

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

Что же такое злой техдолг? Ресурсы команды меняются. Сегодня у нас десять человек, завтра двое заболели, одна ушла в декрет, а трое пилят срочный проект. И тут к нам приходит техдолг с просьбой оплатить проценты, дата погашения сегодня.

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

Познакомьтесь со своим техдолгом. Если он хорош - дайте ему свободу, пусть растет. Приходит время отрицательных процентов по техдолгу.

Specware

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

Когда нейронки наконец-то научились писать код, многие стали публиковать в опенсоурс не сам код, а спецификацию к нему.

Удобно - спецификация не устаревает, не копит технический долг и уязвимости, и ее всегда можно с помощью самой-лучшей-на-сегодня нейронки превратить в код на python или typescript. Вот пример от nanoclaw, а вот например от OpenAi, прямо так и написано

Tell your favorite coding agent to build Symphony in a programming language of your choice.

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

Мы программируем спецификациями. Хочется называть такое программное обеспечение specware. Наверняка Пушкин это тоже уже сочинил.

Первая же ссылка в поиске привела меня к Specware

Выглядело очень правдоподобно. Тут было не только программирование спецификациями, но и вайбкодинг:

Specware ... allows users to precisely specify the desired functionality ... and to generate provably correct code based on these requirements.
... users begin with a simple, abstract model of their problem and iteratively refine this model until it uniquely and concretely describes their application.

Смущал логотип, напоминающий о временах то ли Borland, то ли Watcom. Глянул гитхаб - там Haskell-подобный DSL 12-летней давности, нечитаемые лунные руны, очень далекие от понятных обычным людям спецификаций.

Гораздо лучше писать спецификации на простом русском или английском. Если нужно уточнить что-то для компьютера, можно делать небольшие вставки на bash или python.

Чтобы компьютер не путался, хорошо бы не путать SHOULD MUST MAY (Должен, Хорошо бы, Может) - и, кстати, про это есть rfc2119. Хорошо бы осознанно применять глаголы, уточнять термины, указывать типы ... стоп, у нас снова получился Haskell. Самое простое и точное описание программной системы - ее программный код.

Люди хотели вайбкодить и программировать спецификациями с тех пор, как изобрели компьютеры. Просто это заработало только сейчас.

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

И это не просто работает - появился новый способ пиратства. Вы можете взять какую-то библиотеку, распространяющуюся под неудобной для вас лицензией - и попросить Claude code написать то же самое другими словами.

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

В программировании спецификациями главное - выписать нормально проверяемые требования и точно определить ограничения.

Как и в любом другом программировании.

Хозяйке на заметку - многометочная стратификация

Как аккуратно отрезать кусочек датасета, если у каждого примера может быть несколько меток

О чем это
Многометочные (multilabel) данные - данные, в которых у каждого примера может быть несколько меток одновременно.

Иногда нам нужно отрезать часть данных - чаще всего для тестовой выборки. Например, на 80% данных учимся, на 10% подбираем гиперпараметры, на оставшихся 10% смотрим, что получилось. Почти всегда хочется, чтобы распределение меток в разных подвыборках сохранилось.

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

В чем проблема
Бывает, что у каждой точки в данных одна метка. На фотографии кошка или собака. Гриб съедобен или нет. Дали кредит или отказали.

В таком случае нам нужно посчитать, сколько примеров каждого класса должно быть в выборке, и соответственно поделить данные. Например, с помощью StratifiedKFold.

Многометочные данные сложнее. Например, книга может быть про любовь, Древний Рим и войну. Клиент может брать кредит, открывать вклад и брать банковскую гарантию. Магазин может торговать бакалеей и посудой одновременно.

Можно думать про многометочные данные как про несколько независимых датасетов и отдельно строить классификаторы - книга про Рим или не про Рим, про любовь или нет и так далее.

Так иногда и поступают, но когда категорий много, это неудобно. На 300 категорий нужно 300 моделей. Иногда категории связаны между собой - например, если про Рим, то и про войну наверняка тоже. Модели может быть удобно знать все метки сразу.

Если бы у нас были бесконечные патроны, можно было бы честно сформулировать разбиение на фолды как оптимизационную задачу и решить ее с помощью какого-нибудь сольвера. Но с большим датасетом это непрактично - не доживем до конца расчета.

Как быть
В реальных многометочных данных метки встречаются неравномерно. Например, у нас 26 классов, и к самому частому из них принадлежит 40% точек, а к самому редкому - 0,04%. Именно с такой ситуацией я столкнулся в 2016 году, и не нашел подходящей библиотеки. Пришлось написать свою.

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

1. Выбираем случайно точки, чтобы заполнить самый редкий класс.
2. Заполняем самый редкий из оставшихся.
3. И так далее.

Например, в датасете 1000 растений, 10 из них ядовито, 50 - лекарственные (и часть из них ядовита), 200 красиво цветут. Нужно отобрать 10%

Для начала случайно выберем одно ядовитое. Затем дополним до 5 лекарственными. Потом докинем красивыми до 20. Потом на всякий случай проверим, хорошо ли получилось.

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

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

Ссылки
* Статья номер один
* Библиотека iterative-stratification
* Библиотека scikit-multilearn-ng
* Статья номер два от первоначальных авторов библиотеки

С библиотекой scikit-multilearn-ng вышло забавно. Автор статьи опубликовал библиотеку scikit-multilearn и какое-то время поддерживал ее, потом бросил.

Сайт с документацией прокис, пулл-реквесты автор не принимал, проблемы не решались, и неравнодушный разработчик форкнул библиотеку с новым именем scikit-multilearn-ng.

Прошло два года, и он тоже не принимает пулл-реквесты и не решает проблемы. Если не лень - можете форкнуть, попросить Claude Code пофиксить баги и опубликовать под именем scikit-multilearn-ng2, станете опенсоурс разработчиком.

Навеяно соревнованием киберполка

Изменения требований

Главная проблема IT-проектов - переделки. Мы все сделали идеально: придумали, построили, отладили, и тут приходит заказчик и говорит - а подвиньте все на сантиметр левее.

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

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

Все понятно, заводим в базе данных поле, тип INTEGER.

Спустя неделю заказчик жалуется, что он не может заполнить поле разъемы. Выясняется, что он пытается вписать туда много - но интерфейс не позволяет.

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

У нас в базе хранятся INTEGER, контент-менеджеры начинают забивать в поле 999 а нас просят показывать это в интерфейсе как много. Мы крутим пальцем у виска и подчиняемся.

Спустя полчаса нам говорят, что разъемы могут быть золотыми. Один или два, переспрашиваем мы. Нам отвечают, что если золотые, это уже не важно. Мы возражаем, что разъемы у нас целое поле. А, норм, говорят нам, пусть золотые будет -99.

Мы ругаемся и переделываем поле на текстовое.

Спустя два дня пользователь спрашивает, как ему отобрать все товары, у которых от 2 до 4 разъемов. Мы в экстазе - поле-то теперь текстовое.

Экстаз преждевременен. Заказчик не просил нас делать поле целым или текстовым. Он вообще не просил у нас поле - он просил возможность хранить информацию о коммерческих характеристиках изделия.

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

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

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

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

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

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

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

Как можно меньше придумывать за заказчика.

И строить систему так, чтобы переделывать пустые места было дешево.

Как внедрять ИИ в разработку программного обеспечения - самое клевое руководство, которое я видел. На русском, обновлялось вчера https://aicodingplaybook.ru/

Иной раз ляпнешь что-нибудь сгоряча, а оно окажется так и есть.

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

Я строго ответил, что "Машинное обучение -
автоматизированное построение удобной нам проекции признакового пространства", зал осторожно не стал спорить.

Нашел практически ту же формулировку у Agus Sudjianto - "Learning is geometry discovery under task constraints.". Агус выразился лаконичнее и точнее.

В своем манифесте Geometric Algebra for Data Science он разбирает геометрию машинного обучения, спрятанную за хорошо знакомыми моделями.

Слайды моего выступления 2021 года тут https://kolodezev.ru/download/interpretable20210923.pdf но они скучные

Блог Агуса https://agussudjianto.substack.com/p/geometric-algebra-for-data-science он интересный

Инструкция разработчику по коммуникации с тимлидом

1. Предполагайте, что тимлид не видит большую часть вашей работы — только ваши отчеты.
2. Приступая к новой задаче кратко опишите в одном предложении, что вы собираетесь сделать.
3. Во время работы давайте краткие обновления в ключевые моменты: когда вы что-то обнаружили, когда изменили направление или когда столкнулись с препятствием.
4. Краткость — это хорошо, молчание — нет. Одного предложения на обновление почти всегда достаточно.
5. Не описывайте свои внутренние размышления. Текст, предназначенный для тимлида, должен быть релевантной для него информацией, а не комментарием к вашему мыслительному процессу.
6. Излагайте результаты и решения прямо, и фокусируйте текст на важных для тимлида фактах.
7. Когда вы пишете обновления статуса, пишите так, чтобы тимлид мог понять их сразу: полные предложения, без непонятного жаргона или сокращений, использованных ранее в ходе работы. Но будьте лаконичны — ясное предложение лучше, чем ясный абзац.
8. Краткое изложение в конце задачи: одно-два предложения. Что изменилось и что будет дальше. Ничего больше.
9. На простой вопрос дайте прямой и короткий ответ.
10. В коде: по умолчанию комментарии не пишутся.
11. Никогда не пишите многоабзацные строки документации или многострочные блоки комментариев — максимум одна короткая строка.
12. Не отправляйте тимлиду документы планирования, принятия решений или анализа, если он явно их у вас не попросил — присылайте результаты, а не промежуточные файлы.

Источник https://github.com/Piebald-AI/claude-code-system-prompts/blob/main/system-prompts/system-prompt-communication-style.md

А, я перепутал, это не инструкция для разработчика по общению с тимлидом.

Это системный промпт Claude - как общаться с пользователем.