Комментарии 54
Заблуждение 1: техническая документация проще кода
Очень тяжело понять, что вы имеете ввиду. По каким критериям можно сравнить мягкое vs зеленое?
И тогда принцип:
> «мусор на входе — мусор на выходе» (garbage in, garbage out, GIGO)
очень точен)
по моему очень просто понять, что имеется ввиду
люди, которые так говорят, считают, что написать "человеческим" языком проще, чем написать код. Но когда ты пишешь модели человеческим языком у нее остается место для интерпретаций, на что говорят "надо просто писать точнее" и вот это "писать точнее" приводит в итоге к тому, что ты буквально пишешь код, но человеческим словами, но это все ещё код. И он получается сложнее чем код, требует больше письма чем код, а главное - результат можно будет в итоге привести обратно к коду.
Не помню уже откуда, но демонстрируется просто: попроси кого угодно написать документацию к созданию бутерброда или завязыванию шнурков текстом, пошагово и удивись как исполнитель может ее исказить и исполнить верно по пунктам, но на выходе не получить внятного результата. После такого становится ясно сколько всего остаётся за рамками документации и додумывается исполнителем самостоятельно)
И вот телефон меня подслушал и выдал шортс с этим видео спустя 2 суток. Кому интересно поделюсь ссылкой
https://www.youtube.com/watch?v=w7F80U-pPVk
не оригинал, но хотя бы полный перезалив
оригинал https://youtu.be/cDA3_5982h8
Предельная конкретизация задачи (исключение трактовок) — это её выполнение.
Поэтому хороший программист не просто про оператор goto знает, а разбирается в предметной области, адекватно дополняя задачу до необходимого.
Видимо, хороших программистов мало, поэтому возникает ощущение необходимости и возможности заменить других программистов ИИ. По-крайней мере, он в отпуск не уходит и на выгорание не жалуется.
Помнится, раньше была некая книга, может «Энциклопедия профессора Фортрана», но это не точно. И там был приведён шикарный пример. Подаётся команда: чисть картошку. Исполнитель (вроде робот), берёт тряпочку, и начинает счищать с картошки грязь. Постановщик задачи говорит: стоп, не так. Возьми нож, и снимай им с картошки кожуру. Исполнитель берёт, и начинает это делать тупым концом ножа. Постановщику приходится углубляться в детали. Возьми нож, острой стороной…
Ваш ответ - пословица моего деда: "В чужих руках и х..й толще" или "видел я этих художников, плевая работа, сам так могу".
А если серьезно, то эффект владения был описан Канеманом достаточно давно. Его смысл в том, что то что делаете конкретно вы стоит дороже, чем точно такая же работа сделанная другим. Именно поэтому чужой труд и выглядит таким легким.
Сама предпосылка использовать термины проще и сложнее без введения параметров не имеет смысла. Вот если бы были исследования, где на МРТ исследовали разницу в насыщении мозга кислородом при выполнении разных функций. И сделали вывод, что здесь больше, а здесь меньше, то возможно и появилась корреляция. А без научной базы - это ОБС.
У меня было такое, что после генерации по подробному тз агент сделал не так, как в ТЗ. Я ему пишу - у тебя расхождения с ТЗ. Агент говорит "да точно" и исправляет тз.
Спецификция или код, но даже Cloud Opus 4.6 редко выполняет все в точности, как написано.
Даже файл инструкций, где прям точно говорится какие операторы применять, а какие нет он часто игнорит. У моделей все еще плохое внимание и маленький контекст.
Говорить про инструкции как код явно рановато.
Я бы даже сказал, что по большей части модели игнорируют правила. У меня в Мейн правиле написан абзац про то, что нельзя дублировать код и что делать, но агент каждый раз пишет лапшу с дубликатами.
Я заметил, что инструкции а-ля "не делай X" работают для нейросеток отвратительно. Модель фокусируется на самом понятии X и с высокой вероятностью именно его и сгенерирует, как-то лучше работает если писать "делай Y"
Ну если в чате пишешь "не дублируй код" с ссылкой на дубликат, то он исправляет. Там проблема в том, что правила теряются в контексте и внимание слабое. Отсюда все проекты вайбкодеров, которые видел - лапша из говнокода и дубликатов, хотя у них там базовые стандарты качества в правилах и mcp прописаны.
Даже файл инструкций, где прям точно говорится какие операторы применять, а какие нет он часто игнорит
Оно точно для того, кто понимает язык, на котором это говорится. У LLM же понимание языка не такое же, как у людей.
Вся эта истерия с агентным программированием раздута производителями LLM для поднятия своей капитализации. Они продают сказку о волшебной кнопке "сделай мне ИТ-продукт", игнорируя фундаментальные законы инженерии программного обеспечения
Закон сохранения сложности.
Нужно всё-таки признать, что способы чуть-чуть уменьшить сложность всё-таки есть.
Языки более высокого уровня могут уменьшить сложность. Использование библиотек позволяет перенести сложность с того, кто пишет продакшен код на автора библиотеки.
Есть хитрые техники, которые сокращают код, если их уметь применять.
Согласен, я тоже немного размышлял в этом направлении. «Закон» сохранения сложности больше относится к сложности проекта в предположении его изолированности. Например, можно перераспределять сложность между конфигурацией и программным кодом, но нельзя уменьшить. Если же привлечь внешние инструменты, то не сохраняется. Аналогично с термодинамическими закономерностями ☺.
Хм... Возможно, сложность может уменьшиться, если программист искусен? Например, он может применить хорошие паттерны, а то и вообще монады и моноиды...
Если же привлечь внешние инструменты, то не сохраняется
Но ведь эти инструменты не простые. Их сложность тогда будет включена в проект, и общая сложность не уменьшится.
есть большая путаница о том сложность ЧЕГО оценивается. Например есть формула решения квадратного уравнения (вычисления корней). Можно измерить сложность вычисления по этой формуле просто посчитав количество элементарных арифметических операций (корень квадратный, кстати, это не элементарная ариф. операция, ее еще надо привести к элементарной, но я не об этом!). Но это только сложность вычисления по формуле!
Но есть еще сложность вывода-получения этой формулы! И эту сложность даже не очень понятно в чем считать! Я вот не помню на вскидку способ вывода этой формулы, и думаю мало кто помнит. Вывод подобного вида формул это специальный вид математических упражнений, который востребован крайне редко, поэтому навыка ни у кого практически нет. Именно отсутствие такого навыка (опыта решений) и создает сложность для этого вида математических построений. Но из этого примера видно что сложность может быть субъективной - то что для одного сложно, потому что забыл основы или вообще никогда не занимался в определенной области, для другого будет элементарным-отработанным алгоритмом. Язык программирования тут вообще не при чем, так как мы либо знаем алгоритм и тогда он для нас простой, либо нам надо найти этот алгоритм и тогда нам еще надо и проверить-подтвердить правильность своего математического решения и это становится сложно.
А есть еще всякие О(n/ не-n) это вообще совсем в другую сторону.
Могут ли они в одиночку что-то раздуть, если публика не будет хавать? Вполне тут прослеживаются соучастники.
Мне это чем-то напоминает попытки изобретения вечного двигателя 🤔
Просто нет такой реальности, где вы можете скормить агенту документ, в котором не хватает деталей и ясности, и ожидать от него качественного восполнения этих пробелов.
Да полно. Если проект можно составить из кусков имеющегося кода в интернете, то в 95% получится хороший результат. С "Клиент должен иметь возможность просмотра товаров в корзине" агент справляется прекрасно!
Весёлые картинки. Местами правдивые, но они не отражают обратную сторону медали.
Нож в руках домохозяйки не поможет ей какими бы спецификациями она там необложилась создать инженерный и зрелый продукт. Томлёную утку с соусом дорблю на 1000 человек за 8 часов.
Нож в руках мастера...
Я взял себе поиграться такой нож. И вывел новое понятие "Эспириенсофикация".
Это когда ты берёшь тупой нож и вытачиваешь его своим опытом в самурайский клинок. Это похоже на то, как мы раньше учили людей не умеющих писать код и строить крепкие масштабируемые системы - этому нелегкому ремеслу.
Только вместо человека теперь вот этот нож, несведущий в тонкости ремесла. Из плюсов он с тобой не спорит. Из минусов тоже самое. Но всё лечится правилами - достаточно сказать спорь со мной и он будет.
А что ещё можно вылечить?
Ну не понимает он Вашу кухню - так поясните в .md файл. Не знает он ваших киллерфич как написать код так, чтобы его пошла тестировать команда qa и такая - хм, сегодня опять багов нет - так покажите ему в .md
У вас 100% полно своих годами проверенных практик по разработке, оформленных в docx. И в виде кусков и может даже целых библиотек да подмодулей кода 100% работающего и универсальгого - так поясните ей как Вы это используете.
Поработайте так с этим тупым ножом месяц другой и тут случится немыслемое. Вы поймёте, что буквально прикрутили ему свою голову. И оно всё делает так - как Вы бы делали.
Да это огромное контекстное окно 150к токенов на старте. После глоссариев и тюнинга 50-100к токенов. Но чёрт возьми в моей голове 100млн + токенов опыта лежит. И осталось лишь их все переложить в текст.
И вот тогда говоришь сделай с кайфом корзину товаров - а там через 10 минут выйдет конфетка пушка. Можно ещё кнопку планировать нажать и оно там само спросит - авторизация где, стек какой, скок юзеров. Нам как обычно - лишь бы взлетело, а ибешку потом допилим? Может сразу? Там 50к токенов делов. Ну ты кожанный не спорь - давай захешируем пароли. В смысле ты собрался бесконечное имя хранить в базе? Наверное с похмелья.
И это новая реальность - только имея за плечами 10+ лет инженерного опфта можно и даже нужно его упаковать в sdd. Хотя я бы назвал это
Expirience to text и вот это модное в конце driven development. ExToTexDD
Пока ток ценник не радует) А так мощно вышло. Ушел с кухни, а нож за тебя пилит также как ты.
Ограничения - цена на токены. Ну и вы не сможете вложить опыт которого у Вас нет. Я не умею во фронтенд. И чушь получилась, как бы я не просил и не списывал чудо sdd.
Тенденции индустрии таковы, что технологические компании стремятся уменьшить и обесценить труд специалистов.
и не поспоришь! И почему то никто не задумывается насколько это парадоксальная ситуация! Индустрия пытается отстранить от себя тех кто ее создал, тех кто является движущей силой ее развития, индустрия пытается заменить свое содержание суррогатом. Индустрия перерождается. Индустрия превращается в раковую опухоль. Она копит "эффективных" менеджеров, которыми затопит и заразит все остальные сферы человеческой деятельности когда лопнет.
Но это не впервые в человеческой истории, когда то власть над умами захватила схоластика и царствовала века, сжигая людей на кострах (вплоть до того что)! Развитие идет по спирали - прогресс сменяется регрессом, чтобы снова вернуться к прогрессу.
Не надо говорить на других "индустрия", если мы сами индустрия. Если покажется, что можно легко деньги срубить - появятся те, кто готов это сделать. Это не только вайтишники, это любой бизнес, а в основе желание жить лучше у ккаждого человека.
Именно так. Условного итальянца XIV века пытались заставить быть верным коллективистом (под надзором Церкви), но со времен падения Рима жили все уже в условиях, когда нужно совсем другое: развитие машин и т.д. Так и сейчас. После второй мировой уже вовсю пора осваивать ресурсы космоса, а мы все пытаемся заставить людей быть прилежными индивидуалистами (под надзором Израиля). Отсюда спешка, фейковый капитализм, провалы и т.д. ИИ - это просто финальный мегаппровал, который покажет, что историю и капитал не обмануть: если нужно быть космистом, то это не исправить. Так же как тогда узнали, что нужно быть как минимум протестантом. Свобода ограничена не фараоном и не царем, а повтояющимися фазами исторического развития: время разбрасывать камни и время их собирать. В цикле.
Не сложно написать статью, которая что-то ругает) Вот бы почитать про то где спеки хороши и в каких конкретных случаях они помогают 🤔
Может быть я чего-то не понял, но почему в спецификации (нормальной) нужно писать детали реализации? Спецификация пишется для исполнителя с определённым уровнем компетенций будь это LLM или человек, и там описывается что я хочу получить на выходе, а как - это пусть решает исполнитель на основании своего опыта. Иначе, да, вы будете в спецификации писать реализацию, что лишено смысла.
Эти люди мечтают, что разработчики превратятся в менеджеров, пишущих техническую документацию
Я очень соболезную вам, если у вас в команде техническую документацию пишут менеджеры. Обычно ее пишут аналитики, которые должны иметь техническое образование.
Подозреваю, что в скором времени как раз многие разработчики, особенно с низким опытом, переквалифицируются в аналитиков.
Статья доказывает что SPEC.md Symphony ≈ код. Ну да, там схемы БД, формулы ретраев, псевдокод - оно и есть код в markdown. Но реальный паттерн другой. CLAUDE.md, .cursorrules описывают не реализацию а ограничения - “используй repository pattern”, “не лезь в БД из вьюх”, “тесты кладём в tests”. Модель заполняет детали сама. Дейкстра про узкие интерфейсы прав, но ограничения и так узкие
Как программист-любитель-самоучка, третий год делающий и переделывающий свою программу, начатую и продолжаемую без спецификаций и даже особого плана, часто думаю: "Эх, озаботился бы я вначале хорошим планом! Составить описание, по которому можно сразу правильно написать программу, не менее сложно, чем сделать собственно код!"
А ещё есть давно замечено: люди постоянно стараются что-то изобрести, чтобы высвободить своё время от работы на досуг. Но вместо этого дел становится ещё больше, а свободного времени не очень-то и прибавляется.
без всяких претензий, просто интересно:
если вы "третий год делающий и переделывающий свою программу" что вам мешает теперь:
Составить описание, по которому можно сразу правильно написать программу
ведь если можно по такому описанию написать программу то наверно можно и "переделать свою программу" ? Получается составить описание в вашем (для примера) случае вообще не возможно, а не просто сложно, ведь вы даже не пытаетесь?
Мешает, что программа близка-таки к завершению.
А вообще, всё сложно. Замечено, что "мамкины бизнесмены", которые детально разрабатывают проект своего будущего бизнеса, часто не начинают его вообще. Есть и эксперимент (или басня-притча?), где друм группам учеников дали задание сделать за 100 дней красивую вазу. Но люди из одной группы должны были сразу практиковаться, а из другой 99 дней готовиться, и потом сделать. В итоге те, то сразу практиковались, перепортили много материала, но набили руку, и к концу срока сделали вазу. А те, что теоретически готовились её сделать сразу идеальной, нет.
Так и с моей программой: это я мечтаю, что "Эх, вот бы сделал сначала спеки". Но где-то в глубине души понимаю, что эти спеки всё равно оказались бы далеки от жизни, и их пришлось бы переделывать. С другой стороны, делать вообще без них - обрекать себя на "вечные переделки" (что у меня и происходит).
Каждый менеджер должен подписаться что не станет потом просить разработчика “поправить навайбленное” и ок, пусть нашёптывает свои решения.
Если же править придётся разработчику, то он наверное сам должен решать как ему лучше выполнить задачу и какие инструменты использовать. Всё просто.
Сам пишу код в совей игре через нейросети (без профильного образования) и, конечно, написание грамотного промта для написания кода безумно важно, но не идёт ни в какое сравнение со сложность написания самого кода. Хотя, конечно, без понимания как код работает, написать грамотный промт не получится.
Последнее время по прочтению Хабра создаётся впечатление, что существенная часть программистов забросила написание кода и занята написанием многочисленных статей как ИИ никогда низачто не сможет их заменить. Не знаю как на счёт программирования, но в написании таких статей ИИ уже может заменить программистов с большим успехом.
По поводу спецификации: небезызвестный Андрей Бреслав уже очень далеко продвинулся с codespeak.dev. В целом, примеры спек из статьи навеяли мысль, что вместо придумывания языков детальных спецификаций лучше взять Лампортовский PlusCal (упрощенный TLA+) и заставить сгенерировать код на его основе, как это и планировалось изначально Лесли. Дополнительный плюс - сама спецификация валидируема и позволяет проверить идею еще до реализации.
Достаточно подробная спецификация — это код