Телеграм канал «ivan zakutni»

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


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


От них-то всего и требовалось буквально прочитать описание продукта и список фич, оставить комментарии, если что-то им не нравится))


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


Я не знаю, были ли документы дочитаны до конца, но, похоже, нет, так как комментарии были оставлены в количестве двух штук к "входному" описанию – стратегии разработки, которая ссылается на модели обоих актуальных продуктов. Знаете, что было в комментариях? Вопросы, ответы на которые находятся... в двух маленьких документах рядом 😁


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


«А мы вот видим вот так вотта», да ну вашу ж...))


Текстовые описания нужны ради общей договоренности, которую можно уточнять и уточнять (все же меняется постоянно – новые требования, окружающая среда), в идеале так, чтобы не объяснять по кругу с чистого листа. У текста можно настраивать степень формальности, управлять самим языком, пояснять отдельные понятия. С ним удобно работать и людям, и агентам.


Диаграмма без продуманного текста рядом с ней, поясняющего её, – это, как правило, мусор. При этом получить ощущение, что мы её поняли, очень легко – смотришь, наслаждаешься красотой блоков, низкой нагрузкой на мозги, бегаешь глазами по скудным подписям, кажется, что всё уже понятно – всё же «на виду».


Мы – на коне, игого! 🥳


Вот тут мы и приходим к теме внимания.

Что происходит со смыслом во время чтения, если внимания нет? Ничего не происходит!))) смысл улетучивается, как говорили учительницы в школах (а может и до сих пор говорят) – в одно ухо влетает, в другое вылетает. Я хочу верить что это ощущение/опыт должны быть знакомы каждому человеку кто вообще умеет читать.


Удерживаем ли мы предмет разговора, замечаем ли его подмену, помним ли, зачем вообще открыли этот текст?
Все это вопросы внимания.


Сергей Игоревич Бобровский тут совсем недавно написал:


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


И код – это ведь тоже текст. Это должно быть предельно очевидно: код выражает смыслы. Недаром же языки программирования называются ЯЗЫКАМИ?


При чтении кода нужно точно так же удерживать вниманием многие штуки: к чему относятся имена, что означает выражение/блок кода, с какими объектами мы работаем и какую задачу решаем?


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


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


Так что же со всем этим делать? Как мне отработать 51 хотдог?)))


К сожалению, у меня для вас две новости, и обе плохие.


Внимание – это ментальный навык, и его надо тренировать.
Мне еще целую серию постов придется писать, а вам все это читать (вы кстати как, забыли? я же это в первой строчке написал буквально, что мы начинаем се-ри-ал! :D)


Совсем без полезняшек этот вводный текст не оставим 😈


***


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


Следущий шаг – предложение, абзац, куски текста побольше. Понимаю ли я смысл на каждом из этих уровней? Не перескочил ли фокус на другую систему или объект? Не произошел ли неявный и неоправданный или неконтролируемый (неявный в тексте) сдвиг на системный уровень выше или ниже?


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


И в целом нормально возвращаться или к отдельному слову, или перечитывать абзац, как и нормально иногда громко плеваться и идти спрашивать автора (помним, что автор уже часто кремниевый, да), что он имел в виду, черт возьми))))


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

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

Как этот джидайский скилл тренировать, будем разбираться вместе далее.

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

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

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

Что с этим делать? Ну, походу завлекать внимание разделением экрана и стримом на второй половине subway surfers 💀

Кроме шуток в коллективной работе, похоже, остается только дробить задачи настолько мелко, насколько возможно, и созваниваться по видеосвязи в шапке с колокольчиками (ну или все таки surfrs?)

Вот бы ИИ уже всех заменил, все никак не дождусь 😁

***

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

Если наберется 10-20 сосисок, рассмотрим проблему глубже, есть пара идей :)

Чем же так хорошо функциональное программирование, и почему оно естественным образом приводит голову в порядок, тогда как императивщина и ООП часто приводят… к трихомундии?


Когда я стал использовать ФП, всё стало проще. Хош верь, хош нет – в любой задаче! вообще в любой))) Но нюанс, как всегда имеется.


Для начала хватает самой базовой базы: иммутабельности и разделения чистых вычислений и побочных эффектов. Это вот именно-то что и работает "всегда и в любой:"

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

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

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

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

Функциональная парадигма учит в первую очередь думать... о функциях! Безжалостно пробивать любые попытки в преждевременные абстракции и сперва смотреть на систему целиком – а что она делает вообще? Какое там окружение? Зачем и "какому бизнесу" нужна?

Всегда нужно сперва разобраться со всем этим (жутко скучным), а потом уже выбирать, как всё будет устроенно/закодировано/завайбкожено наконец.

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

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

Я считаю, что базового ФП хватит для, наверное, 90% обычных продуктовых задач. Цена за это – небольшая избыточность.

И повторяюсь: чтобы получить эту пользу, не нужно знать ниндзютсу ФП и думать на хаскелях. Никаких функторов и призм, это все для уже для повернутых продвинутых. Хотя и это "продвинутое фп" под вопросом – мы же помним, что наш код всё ещё иногда надо читать другим агентам, да?

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

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

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

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

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

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

Ну вот в общем то - да. 🙂‍↕️

С днем арбуза.
в айтишном сознании паразитирует идея: "ЫЫшка всё сделает, человеку достаточно поверхностно разбираться"


Ну ок, давайте повторим опять :)


вот поглядите на исследование про генерацию regression-тестов

tl;dr – там в сто с лишним пуллреквестов из разных oss либ напихали ошибок и дали антропиковскому хайку генерировать тесты)))


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


И вы конечно можете наброситься на меня с воплями о том что дивные и всеми любимые слопус 5.5 или аструс 666 такого "никогда не сделают"! 😡


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


Можно попросить агента "проведи deep research и разберись", и получить очень правдоподобную систему, которую у вас никто не купит, и даже даром не будет пользоваться)) Все потому что адекватность продукта проявляется в конкретной прикладной области: кому он нужен, какую работу люди с ним будут делать, в каких условиях, с какими ограничениями, и так далее.


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


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


Даже такая вроде бы совсем тупая crud-фича как "отменить заказ" требует разворачивать инварианты – что делать с уже отгруженным заказом? как обработать повторые отмены? какие данные и состояния в системе при отмене должны сохраниться?


короче говоря – по коду на который вы смотрите можно только лишь узнать, как отмена реализована сейчас, а не как НАДО.


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


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


Поэтому когда я вижу/слышу слишком обобщенные слова, вроде – "Программирование, дизайн, перевод, написание текстов, создание видео, 3D делается ИИ лучше, чем человеком. Скоро это будет справедливо и для научных исследований в математике, физике, биологии, управлении бизнесом и сотнях других функций", мне очень сложно не заподозрить их автора в олИИгофрении или наглой спекуляции (что хуже решайте сами.)


Давайте уточнять – *поверхностное* программирование, *поверхностный* дизайн, *поверхностные* исследования... Впечатлительного качества, с ужасающей скоростью ИИ помогает во всем этом, но *поверхностно* :)


Даже воткнуть FPF или другие более узкие sdd/bdd штуки не особо поможет, если за машиной мы находимся в режиме мясного прокси, а не продолжаем процесс вычисления, не вовлечены в работу.


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


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


Решайте сами в своих проектах насколько критичны риски таких протечек.


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


Поэтому я считаю что высокие требования к человеческому интеллекту лишь растут и будут расти. Мы должны "учиться учиться" – приобретать новое мастерство, когда привычного поверхностного понимания уже недостаточно)


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


Почему? Думайте сами.

Haft с самого начала был полностью завайбкожен.

Был буквально сжигалкой лишних токенов, практически «эй, вот тут FPF - это как кости Дзен, давай наполним мясом»)))

Это мой первый и последний продукт, где 100% кода выдал Ии, а я вообще не открывал исходники.

При этом спеки то были довольно формальными. Но эксперимент провалился. Ну или все таки удался?)))

За историю Haft я сам два раза переставал им пользоваться в пользу чистого FPF. Первый раз, когда это был еще Quint Code из-за слишком угловатого процесса.

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

Я не знаю можно ли этот эксперимент назвать дешёвым.

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

И дело не только в том, что я не читал код. Читать диффы, рефакторить – там ещё… много будет)))

А скорее в том, сколько slow thinking и внимания вообще я тратил на Haft. Если бы было выделено побольше, этих ошибок не было. Никакой тул, никакая методология, система типов, мета-мета-мета…мета подходы не будут работать, если не проинвестировать в них мозг и время.

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

Ничего САМ собой наш родненький ИИ сделать не может нормально.
Так было два года назад было, и сейчас качественного ничего не поменялось: быстрее/лучше/умнее решаются правильно поставленные задачи, «средняя температура правдоподобности» сильно повысилась, высшие приматы радостно генерируют картинки, видео, игры… паршивого качества :)

Важнее всего РЕАЛЬНЫЕ задачи, за которыми стоят РЕАЛЬНЫЕ проблемы.

Ведь параллельно с существованием haft я дофига работал, для ВСЕХ проектов использовал и сам haft разных версий, и «чистый FPF», и бОльшая часть из них заработала и… в примерно половину (если не больше) из них, в смысле в сгенеренный код, я тоже не то чтобы сильно смотрел.

но на думки по каждому тратил много мнооооого часов.

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

Из нового рантайма уходят FPF-компилятор/сайдкар с эмбеддингами и еще ряд велосипедов.

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

Короче - FPF плюс немного скиллов и память для этого FPF 🤷‍♀️

Alpha v10 уже вышла⁠, но если вы вдруг этим пользуетесь - подождите еще пару дней до стабильного релиза.
А велосипеды… у велосипедов есть прямое назначение - на них надо кататься, а не городить в софте)))