Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(
В этом, к сожалению, и проблема... Я с одной стороны никоим образом не хочу душить техническое творчество, пусть даже и не подкрепленное специальным образованием. А с другой стороны - надо понимать, что ваше устройство опасно. И что еще хуже - те кто будут у вас его повторять с сайта - понимают еще меньше вас. А дальше с увеличением количества пользователей - статистика бессердечная сука: начнутся пожары и трупы. Нет, наверное формально к вам претензий предъявить будет нельзя. В принципе, правила электрической и пожарной безопасности ясно говорят - использование кустарных нагревательных приборов в помещениях запрещено. Использование бытовых нагревательных приборов разрешается только под присмотром. Для того, чтобы термостат можно было воткнуть в розетку и уйти из дома - у него должен быть сертификат. Но вы же знаете отношение нашего человека к правилам и запретам... В общем, я бы себя чувствовал морально плохо, если бы выкладывал на сайт устройство которое часть пользователей обязательно оставит без дома (а кого-то еще и без отца/матери/детей/etc).
Как минимум - добавили бы вы в дисклеймер, что эту штуку запрещается оставлять без присмотра! Это оставляет ей кучу применений - какие-нибудь лабораторные установки, котлы где есть дежурный круглосуточно, и т.д - но хотя бы никто не убьет себя по глупости...
А если вы хотите спроектировать штуку, которая действительно может легально (тут без шуток - правила безопасности писаны кровью) работать автономно - то хочешь-не хочешь надо изучать правила проектирования отказоустойчивых систем. И да, абсолютно безопасных устройств не бывает, и подход к безопасности всегда риск-ориентированный. Принцип простой - по нормативу задаетесь такой вероятностью, чтобы за время использования вашего устройства вероятность погибнуть от его отказа была меньше чем под колесами автомобила или от сосульки с крыши зимой. Будет десять в минус какой-то степени на час (месяц, год) работы. Дальше по другим справочникам раскладываете это в надежность компонентов и подтверждаете что ваши схемотехнические решения действительно позволяют человеку скорее попасть в автомобильную аварию чем сгореть от отказа термостата. И в принципе все, ваше устройство получает право работать без присмотра...
P.S. Никому и никогда не говорите что вы их делали на заказ. Случись что - попадете под уголовное дело. Оно и раньше было не то чтобы очень здорово - даже если не посадят а дадут условно... А сейчас наиболее вероятно, что до суда даже не доживете - "уговорят" подписать контракт - а дальше вы и сами знаете...
При всем уважении к автору - в таком исполнении на устройстве должна быть надпись: "Эксплуатация допускается только под присмотром потребителя". Потому что без присмотра такое оставлять нельзя!
Ни одного упоминания об аппаратном WDT (причем не с прерыванием где флаг сбрасывается, а со сбросом только при нормальном состоянии устройства и датчиков). Автор уже встретился с тем, что ЭМП могут произвольно менять флаги в регистрах, а устройство - зависать, но выводов не сделал...
При этом, я бы не доверял и аппаратному WDT. Когда вы управляете чем-то нагревающим, да с мощностью в киловатты - наверное не трудно поставить пару транзисторов и разделительный конденсатор, чтобы работа нагревателя разрешалась не постоянным уровнем на ноге, а меандром (который генерируется не через PWM на канале таймера, а честным дерганьем PORTx в основном цикле при условии что датчики и данные с них идут нормальным потоком).
При этом, я бы не доверял и этому - потому что при пробитии транзистора или симмистора оно все-равно может неуправляемо разгоняться. Поэтому нужна независимо действующая система безопасности (например, одноразовый термопредохранитель прикрученный к нагревателю), которая будет рвать питание вне зависимости от того, что происходит в контроллере... Или биметаллический таймер, который не дает физически держать нагреватель включенным непрерывно больше чем определенное время (гарантированно не приводящее к пожару).
Конечно - реализовать это все в формате Tiny2313 может не хватить ресурсов. Но положа руку на сердце - вы не серию миллионную гоните, где для вас каждый рубль экономии - путь к несметному богатству! Вы делаете единичные устройства - ну так поставьте Atmega328! Ну будет оно на сто рублей дороже, и что ?! Зато спать спокойно ночью будете...
Вы сознательно, или несознательно игнорируете существенный момент - ВСЕ ранее перечисленные инструменты (счеты, 1С, etc) являлись детерминированными. А LLM - принципиально вероятностная система. Одно дело - заменять прошлую детерминированную систему - другой детерминированной системой. Другое - менять известный предсказуемый (!) тулсет на принципиально более производительный, но время от времени сходящий с ума. Первое - несомненно прогресс. Второе - сомневаюсь... :-(
Ну как бы да - я пользуюсь maven не глядя в его код. Но maven - детерминированный тул, а агент на базе LLM - нет. Он пишет по одной и той же спеке немного разное. А один раз на N запусков может вообще все зафакапить...
В общем, на текущем уровне развития ИИ, я не готов объявить code - secondary артефактом который можно дешево регенерировать. Вне зависимости от того, какой harness мне дадут, и сколько текста в спеку оно напишет. Потому что оно нет нет, а напишет одно - а сделает другое...
Возможно, моя осторожность проистекает из отрасли в которой мы сидим. Если ошибка в проде никого серьезно не напрягает, и просто является сигналом перегенерировать код и попробовать снова - то можно и поиграть в игру 'spec is a source of truth, not the code". Я в это (пока!) играть не готов...
Но оно же так в реальности на проектах не работает! Это не улица с односторонним движением - от бизнеса через требования и спецификации к коду. Наоборот, если бизнес сумел нахреначить спецификаций без нашего ведома - значит скорее придется делать двойную работу - сначала отменять то что уже успели утвердить, а потом еще раз утверждать уже то, что нужно. Правильный подход - это когда бизнес вам намекает на проблему (или даже если это хороший бизнес - то прямо рассказывает в чем она заключается), а дальше вы с бизнесом делаете несколько итераций пытаясь найти такое решение, чтобы оно и в существующую реализацию хорошо легло, и бизнес устроило... Нет, понятно что все это можно сделать и на спецификациях - но я хочу понять какую проблему вы этим пытаетесь решить ? Из наших экспериментов с SDD - мы увидели выигрыш только в одном случае: у вас на проекте почему-то разбежались все люди которые умеют читать и писать код (разрабы), но остались люди которые умеют и любят читать английские тексты (аналитики). Тогда без SDD вы будете стоять пока девелоперы не вернутся - а с SDD вы будете криво-косо, но ехать практически без умения читать код. Но поскольку эксплуатировать дальше продукт без чтения кода нельзя - то движение это ограниченное, и потом придется технический долг вернуть...
Э-э, дайте пожалуйста определение энтропии которым вы пользуетесь ? Если мы говорим о классическом термодинамическом понимании - то высокая энтропия соответствует "естественному" или "случайному" распределению элементов системы. И живая система соответствует очень низкому уровню энтропии - и ее естественное термодинамическое движение - это умереть и распасться. Но пока солнышко поставляет нам на планету энергию (лучи света) с низкой энтропией (высокой частотой), а мы излучаем обратно в космос то же количество энергии но с более высокой энтропией (низкая частота, ИК-диапазон) - живые существа начиная с растений адсорбируют эту разницу в энтропии и используют для того, чтобы поддерживать себя в живом (аномальном с точки зрения теории вероятности) состоянии.
Это немного отклонение от темы - но я лично вместо spec-driven и далее по списку - использую ИИ там, где он несомненно полезен: первый раз на этапе ideation/solutioning - чтобы получить доступ к широким знаниям модели. Второй раз - на этапе деталей реализации (ибо оно помнит конкретные методы spring batch или spring security сильно лучше чем я). Но в середине между этим: выбор способа реализации, обозначение границ - я предпочитаю работать сам. Чтобы ИИ у меня работал в режиме "спишите, расставляя пропущенные буквы" (C). Третий раз я его использую после того как написаны интеграционные тесты, чтобы он посмотрел на code coverage map, и сформулировал мне существенные бизнес-кейсы и edge-cases которые нами не покрыты - и дописал тестов на них.
SDD мы пробовали - но остались в задумчивости. Если не читать тонны текста которые он производит - то в чем смысл ?! Если читать - то кто это будет делать и за чьи деньги ? Если в процессе реализации спеки LLM все-таки налажала, то надо ли все сбросить, и пробовать еще раз улучшив спеки (а куда списать затраченные токены) ? Или пробовать делать корректирующую спеку (а кто потом будет разбираться в этой лапше) ?...
Возможно, ситуация будет лучше если проект с самого начала делается по SDD и спеки периодически грумятся. И то - у меня вопросики относительно того, не сожрет ли чтение спецификаций весь разумный контекст...
В нашем случае - мы делаем нечто сильно более легкое чем SDD - мы заставляем ИИ поддерживать онтологии разного функционала системы. Это позволяет ткнуть ИИ в готовую онтологию, и предотвратить постоянное шараханье по дереву исходников: "А давайте прочитаем build.gradle, а давайте прочитаем еще контроллеры, а давайте прочитаем то, а еще вот это...".
Если бы в авиации был единственный способ все делать - то летчик точно был бы не нужен: запрограммируй этот способ (он же один!) - и профит! С другой стороны, если вы Cloudflare и оно упало - то чинить вы будете в таком же стрессе как пилот, у которого замигала лампа "пожар 1 двиг"... Я не говорю что надо механически переносить руководящие документы из авиации в ИТ - но их опыт (пере) автоматизации надо изучать, и свои документы писать с оглядкой на него...
Проблема любых методов программирования, которые опираются на естественные языки (спецификации) - заключается в том, что между людьми спецификация объясняет главные идеи - а остальное люди сами достраивают исходя из логики, контекста и знания предметной области. Поэтому опытный разработчик ценится больше чем начинающий - из-за контекста в голове, а не потому что он знает слова языка программирования лучше. Любая попытка "улучшить" спецификации сделав их более подробными - на самом деле ухудшает дело, потому что примерами человеческих подробных спецификаций являются законы (которые хрен прочитаешь и поймешь без специального образования). Кроме того, удачи вам ловить противоречия в тоннах английского текста. Если мы достаточно упорны - то мы будем упрощать язык и ужесточать его правила, чтобы было легче анализировать спецификации не только LLM, но и формальными методами. И через несколько итераций мы придем к тому, что идеальная спецификация пишется на специально сконструированном языке с жесткими языковыми конструкциями и структурой. Дальше достаточно посмотреть вокруг, и убедиться что такие языки: Java, Python, C/C++, Бейсик прости господи - уже давно изобретены и используются.
Пока речь идет о куске кода целиком под вашим контролем - все относительно хорошо. Добавляем сеть и базу данных - и оно перестает описываться в формате доказуемых свойств. Ну или вы будете вынуждены описать БД так, что мат.модель ее будет очень далека от действительности - и фактически вы сможете доказать только happy-path (что дешевле проверить тестами - и все так и делают!).
Поспорю - действительно, виды работ разные. Но творческий подход и у программистов ограничен - мы пишем на достаточно строгих языках, шаг вправо-влево - ошибка компиляции. Аналогию codebase awareness с situational awareness - считаю принципиально правильной: чрезмерное применение автоматизации вызывает деградацию человека в цикле управления - и когда происходит факап, выясняется что никто точно не понимает как оно случилось, и что делать. Последствия разные - это правда. Но тем ценнее перенимать опыт из индустрий где ошибки стоят дорого, и поэтому они раньше нас задумываются что с ними делать...
Э-э, какие ? Есть класс программ с полным доказательством инвариантов - в свое время этим баловался Кнут и другие академические исследователи. Это безусловно работает - ибо математику не перешибешь - но не позволяет описывать сколько-нибудь сложные реальные системы. А все остальное так или иначе сводится к тестированию - которое может доказать что специфическое поведение есть, но никак не может показать что другого поведения вне тестов - нет...
С аргументом что ИИ генерирует код лучше программистов - не согласен. Любая спецификация на входе ИИ-агента - принципиальна неполна и/или противоречива. Смысл утверждения на естественном языке раскрывается только если источник и приемник разделяют контекст, в котором сделано высказывание. При этом - люди-программисты со временем согласуют свою голову с контекстом (отраслью, проектом) в котором они работают - а у LLM веса зафиксированы, и учиться она не собирается. Нет, можно пытаться подавать опыт через контекст - но там и так места немного, и несмотря на похвальбу в 1М токенов, после трети контекста, ИИ начинает писать как будто хлопнул стопарик водки... а потом еще один, и еще...
В авиации тоже было не реально - когда все были влюблены в парадигму максимальной автоматизации на всех этапах полета. Потребовалось убить в этой парадигме несколько сотен человек чтобы получить общественный резонанс, и подумать еще раз!
Однозначно верная статья! И рецепт лечения надо брать из авиации - situational awareness: пилот должен мыслями "лететь" впереди самолета, вместо того, чтобы действовать реактивно.
То есть - команда (или разработчик) до запуска агента должна иметь видение того, что должно быть построено - и сверять то что делает агент - со своим видением. Это ставит жи-и-рный крест на всякой ереси типа spec-driven development, вайб-кодинге, code as secondary artifact - и заставляет проектировать agentic SDLC таким образом, чтобы человек сохранял ситуационную осведомленность! И при соблюдении этих условий, ИИ-инструменты будут безусловно полезны!
А ничего что у вас окружающий мир так устроен, что все площади простых фигур содержат вторую степень параметра ? И что большая часть взаимодействий поля идет "обратно пропорционально квадрату расстояния" ? А если вы не поняли простой случай с двумя координатами и многочленом второй степени, то как вы потом собираетесь понимать пространства высших размерностей и многочлены высоких степеней, где нельзя ни понятно нарисовать, ни аналитическое решение написать в общем случае ?!
Но вы же понимаете, что если у ребенка есть выбор между "разбираться как брать производную по частям" или "валяться и ржать над видосиками в тик-ток" - то 90% выберут второе. И что вы будете делать в цивилизации, где только 10% живущих как-то понимают устройство техники, которая повсеместно применяется ?
Нет, я не говорю что ваша добровольная модель образования невозможна. Просто тогда СРЕДНИЙ уровень сложности общества надо вернуть обратно между 18 и 19 веками. Будет ли это равномерная деградация - или 10% знающих как-то соберутся на компактной территории и начнут загонять детей в школу и принудительно их обучать - образуя стабильный анклав технически развитой цивилизации - знать не могу...
Вы не поняли главную мысль, к сожалению. То, что сейчас находится далеко от границы познанного человеком - это не "непознанное" а именно "непознаваемое". Познаваемое - это то что лежит близко от границы. Конкретная размерность и форма которой вы будете представляеть познанное - не имеет существенного значения.
Вы не сможете понять "магнитное поле", "проводник", "эдс" без широкой базы, которую вам дали в школе. Или - будете вынуждены просто запомнить физическое явление как феномен. Что случается когда наука феноменизируется таким образом - хорошо реконструировано у Хайнлайна в "Пасынках вселенной": "[...] Джордан решил, и час настал - из мрака и тьмы он Корабль создал! // Миля за милей уютных жилищ, и для плодов золотых хранилищ..." (С).
Еще раз посмотрте на проблему шире - любая школа вынуждена считаться с тем, что она НЕ ЗНАЕТ у кого какие на самом деле способности и кто куда пойдет. Та же музыкальная школа - всех детей гоняет петь в хоре, изучать историю музыки, сольфеджио, играть на фортепиано (даже если ты не пианист), и т.д. Хотя очевидно же, что НИКТО из детей не будет одновременно солистом, певцом в хоре, композитором и далее по тексту. Проблема в том, что невозможно заранее определить кто будет. Поэтому школа учит всех всему до какого-то уровня. КПД образования при этом низкий - потому что одному-двум из сотни все пригодилось, десятку - пригодилась половина, а остальные забыли как страшный сон 90%. Но другого способа просто нет! Если, конечно, вы хотите и дальше жить в развитой машинной цивилизации...
А вы уверены, что все дети в пятом классе достаточно осознанны, чтобы сделать такой выбор ? А не выберут наиболее халявные курсы, потому что реально хочется не в школе сидеть, а по крышам гаражей скакать ?! А еще раз повторю - класса с 8-го уже и так есть выбор - хочешь иди в маткласс, хочешь в гуманитарный, хочешь - в школу олимпийского резерва...
Это вам сейчас кажется, что все можно изучить когда оно понадобиться. Проблема в том, что обучение так не работает. Это не моя специальность - кроме курса "психология обучения взрослых" в районе последнего года магистратуры - но выводы я помню до сих пор. Если вы представите знания человека в виде круга - то внутри будет то, что он знает, снаружи от границы будет тонкая граница возможного познания - а за этой границей зона непознаваемого. Только единицы гениев могут перешагнуть эту границу и сразу попасть в ранее непознаваемое. Обычный человек работает не так - он может воспринять, освоить и превратить в умение-навык только то, что сейчас находится по соседству с понятиями, которые ему уже хорошо известны и освоены. Когда он осваивает кусок этой границы познаваемого - ему открывается новая граница, куда раньше он дотянуться не мог.
У ребенка перед школой - этот круг очень маленький. Соответственно, граница доступного к познанию - тоже небольшая. Школа старается максимальными темпами догнать этот круг познанного до некой общественой нормы, чтобы вы дальше могли в любом направлении двигаться самостоятельно (или при методической поддержке ака образовательные видео, курсы, учебники, институт, и т.д.).
Есть альтернативный способ работы с непознаваемым - запоминать это в виде частных ответов и ритуалов. В принципе, это возможно - и человек сможет даже сносно существовать с такой нео-мифологической картиной мира. Проблема в том, что полноценно оперировать этими знаниями он не сможет. Ближайшая аналогия - алхимик в средние века: знаем много частных случаев, ничего не можем толком с этим поделать, ищем философский камень...
Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(
В этом, к сожалению, и проблема... Я с одной стороны никоим образом не хочу душить техническое творчество, пусть даже и не подкрепленное специальным образованием. А с другой стороны - надо понимать, что ваше устройство опасно. И что еще хуже - те кто будут у вас его повторять с сайта - понимают еще меньше вас. А дальше с увеличением количества пользователей - статистика бессердечная сука: начнутся пожары и трупы. Нет, наверное формально к вам претензий предъявить будет нельзя. В принципе, правила электрической и пожарной безопасности ясно говорят - использование кустарных нагревательных приборов в помещениях запрещено. Использование бытовых нагревательных приборов разрешается только под присмотром. Для того, чтобы термостат можно было воткнуть в розетку и уйти из дома - у него должен быть сертификат. Но вы же знаете отношение нашего человека к правилам и запретам... В общем, я бы себя чувствовал морально плохо, если бы выкладывал на сайт устройство которое часть пользователей обязательно оставит без дома (а кого-то еще и без отца/матери/детей/etc).
Как минимум - добавили бы вы в дисклеймер, что эту штуку запрещается оставлять без присмотра! Это оставляет ей кучу применений - какие-нибудь лабораторные установки, котлы где есть дежурный круглосуточно, и т.д - но хотя бы никто не убьет себя по глупости...
А если вы хотите спроектировать штуку, которая действительно может легально (тут без шуток - правила безопасности писаны кровью) работать автономно - то хочешь-не хочешь надо изучать правила проектирования отказоустойчивых систем. И да, абсолютно безопасных устройств не бывает, и подход к безопасности всегда риск-ориентированный. Принцип простой - по нормативу задаетесь такой вероятностью, чтобы за время использования вашего устройства вероятность погибнуть от его отказа была меньше чем под колесами автомобила или от сосульки с крыши зимой. Будет десять в минус какой-то степени на час (месяц, год) работы. Дальше по другим справочникам раскладываете это в надежность компонентов и подтверждаете что ваши схемотехнические решения действительно позволяют человеку скорее попасть в автомобильную аварию чем сгореть от отказа термостата. И в принципе все, ваше устройство получает право работать без присмотра...
P.S. Никому и никогда не говорите что вы их делали на заказ. Случись что - попадете под уголовное дело. Оно и раньше было не то чтобы очень здорово - даже если не посадят а дадут условно... А сейчас наиболее вероятно, что до суда даже не доживете - "уговорят" подписать контракт - а дальше вы и сами знаете...
При всем уважении к автору - в таком исполнении на устройстве должна быть надпись: "Эксплуатация допускается только под присмотром потребителя". Потому что без присмотра такое оставлять нельзя!
Ни одного упоминания об аппаратном WDT (причем не с прерыванием где флаг сбрасывается, а со сбросом только при нормальном состоянии устройства и датчиков). Автор уже встретился с тем, что ЭМП могут произвольно менять флаги в регистрах, а устройство - зависать, но выводов не сделал...
При этом, я бы не доверял и аппаратному WDT. Когда вы управляете чем-то нагревающим, да с мощностью в киловатты - наверное не трудно поставить пару транзисторов и разделительный конденсатор, чтобы работа нагревателя разрешалась не постоянным уровнем на ноге, а меандром (который генерируется не через PWM на канале таймера, а честным дерганьем PORTx в основном цикле при условии что датчики и данные с них идут нормальным потоком).
При этом, я бы не доверял и этому - потому что при пробитии транзистора или симмистора оно все-равно может неуправляемо разгоняться. Поэтому нужна независимо действующая система безопасности (например, одноразовый термопредохранитель прикрученный к нагревателю), которая будет рвать питание вне зависимости от того, что происходит в контроллере... Или биметаллический таймер, который не дает физически держать нагреватель включенным непрерывно больше чем определенное время (гарантированно не приводящее к пожару).
Конечно - реализовать это все в формате Tiny2313 может не хватить ресурсов. Но положа руку на сердце - вы не серию миллионную гоните, где для вас каждый рубль экономии - путь к несметному богатству! Вы делаете единичные устройства - ну так поставьте Atmega328! Ну будет оно на сто рублей дороже, и что ?! Зато спать спокойно ночью будете...
Вы сознательно, или несознательно игнорируете существенный момент - ВСЕ ранее перечисленные инструменты (счеты, 1С, etc) являлись детерминированными. А LLM - принципиально вероятностная система. Одно дело - заменять прошлую детерминированную систему - другой детерминированной системой. Другое - менять известный предсказуемый (!) тулсет на принципиально более производительный, но время от времени сходящий с ума. Первое - несомненно прогресс. Второе - сомневаюсь... :-(
Ну как бы да - я пользуюсь maven не глядя в его код. Но maven - детерминированный тул, а агент на базе LLM - нет. Он пишет по одной и той же спеке немного разное. А один раз на N запусков может вообще все зафакапить...
В общем, на текущем уровне развития ИИ, я не готов объявить code - secondary артефактом который можно дешево регенерировать. Вне зависимости от того, какой harness мне дадут, и сколько текста в спеку оно напишет. Потому что оно нет нет, а напишет одно - а сделает другое...
Возможно, моя осторожность проистекает из отрасли в которой мы сидим. Если ошибка в проде никого серьезно не напрягает, и просто является сигналом перегенерировать код и попробовать снова - то можно и поиграть в игру 'spec is a source of truth, not the code". Я в это (пока!) играть не готов...
Но оно же так в реальности на проектах не работает! Это не улица с односторонним движением - от бизнеса через требования и спецификации к коду. Наоборот, если бизнес сумел нахреначить спецификаций без нашего ведома - значит скорее придется делать двойную работу - сначала отменять то что уже успели утвердить, а потом еще раз утверждать уже то, что нужно. Правильный подход - это когда бизнес вам намекает на проблему (или даже если это хороший бизнес - то прямо рассказывает в чем она заключается), а дальше вы с бизнесом делаете несколько итераций пытаясь найти такое решение, чтобы оно и в существующую реализацию хорошо легло, и бизнес устроило... Нет, понятно что все это можно сделать и на спецификациях - но я хочу понять какую проблему вы этим пытаетесь решить ? Из наших экспериментов с SDD - мы увидели выигрыш только в одном случае: у вас на проекте почему-то разбежались все люди которые умеют читать и писать код (разрабы), но остались люди которые умеют и любят читать английские тексты (аналитики). Тогда без SDD вы будете стоять пока девелоперы не вернутся - а с SDD вы будете криво-косо, но ехать практически без умения читать код. Но поскольку эксплуатировать дальше продукт без чтения кода нельзя - то движение это ограниченное, и потом придется технический долг вернуть...
Э-э, дайте пожалуйста определение энтропии которым вы пользуетесь ? Если мы говорим о классическом термодинамическом понимании - то высокая энтропия соответствует "естественному" или "случайному" распределению элементов системы. И живая система соответствует очень низкому уровню энтропии - и ее естественное термодинамическое движение - это умереть и распасться. Но пока солнышко поставляет нам на планету энергию (лучи света) с низкой энтропией (высокой частотой), а мы излучаем обратно в космос то же количество энергии но с более высокой энтропией (низкая частота, ИК-диапазон) - живые существа начиная с растений адсорбируют эту разницу в энтропии и используют для того, чтобы поддерживать себя в живом (аномальном с точки зрения теории вероятности) состоянии.
Это немного отклонение от темы - но я лично вместо spec-driven и далее по списку - использую ИИ там, где он несомненно полезен: первый раз на этапе ideation/solutioning - чтобы получить доступ к широким знаниям модели. Второй раз - на этапе деталей реализации (ибо оно помнит конкретные методы spring batch или spring security сильно лучше чем я). Но в середине между этим: выбор способа реализации, обозначение границ - я предпочитаю работать сам. Чтобы ИИ у меня работал в режиме "спишите, расставляя пропущенные буквы" (C). Третий раз я его использую после того как написаны интеграционные тесты, чтобы он посмотрел на code coverage map, и сформулировал мне существенные бизнес-кейсы и edge-cases которые нами не покрыты - и дописал тестов на них.
SDD мы пробовали - но остались в задумчивости. Если не читать тонны текста которые он производит - то в чем смысл ?! Если читать - то кто это будет делать и за чьи деньги ? Если в процессе реализации спеки LLM все-таки налажала, то надо ли все сбросить, и пробовать еще раз улучшив спеки (а куда списать затраченные токены) ? Или пробовать делать корректирующую спеку (а кто потом будет разбираться в этой лапше) ?...
Возможно, ситуация будет лучше если проект с самого начала делается по SDD и спеки периодически грумятся. И то - у меня вопросики относительно того, не сожрет ли чтение спецификаций весь разумный контекст...
В нашем случае - мы делаем нечто сильно более легкое чем SDD - мы заставляем ИИ поддерживать онтологии разного функционала системы. Это позволяет ткнуть ИИ в готовую онтологию, и предотвратить постоянное шараханье по дереву исходников: "А давайте прочитаем build.gradle, а давайте прочитаем еще контроллеры, а давайте прочитаем то, а еще вот это...".
Если бы в авиации был единственный способ все делать - то летчик точно был бы не нужен: запрограммируй этот способ (он же один!) - и профит! С другой стороны, если вы Cloudflare и оно упало - то чинить вы будете в таком же стрессе как пилот, у которого замигала лампа "пожар 1 двиг"... Я не говорю что надо механически переносить руководящие документы из авиации в ИТ - но их опыт (пере) автоматизации надо изучать, и свои документы писать с оглядкой на него...
Проблема любых методов программирования, которые опираются на естественные языки (спецификации) - заключается в том, что между людьми спецификация объясняет главные идеи - а остальное люди сами достраивают исходя из логики, контекста и знания предметной области. Поэтому опытный разработчик ценится больше чем начинающий - из-за контекста в голове, а не потому что он знает слова языка программирования лучше. Любая попытка "улучшить" спецификации сделав их более подробными - на самом деле ухудшает дело, потому что примерами человеческих подробных спецификаций являются законы (которые хрен прочитаешь и поймешь без специального образования). Кроме того, удачи вам ловить противоречия в тоннах английского текста. Если мы достаточно упорны - то мы будем упрощать язык и ужесточать его правила, чтобы было легче анализировать спецификации не только LLM, но и формальными методами. И через несколько итераций мы придем к тому, что идеальная спецификация пишется на специально сконструированном языке с жесткими языковыми конструкциями и структурой. Дальше достаточно посмотреть вокруг, и убедиться что такие языки: Java, Python, C/C++, Бейсик прости господи - уже давно изобретены и используются.
Пока речь идет о куске кода целиком под вашим контролем - все относительно хорошо. Добавляем сеть и базу данных - и оно перестает описываться в формате доказуемых свойств. Ну или вы будете вынуждены описать БД так, что мат.модель ее будет очень далека от действительности - и фактически вы сможете доказать только happy-path (что дешевле проверить тестами - и все так и делают!).
Поспорю - действительно, виды работ разные. Но творческий подход и у программистов ограничен - мы пишем на достаточно строгих языках, шаг вправо-влево - ошибка компиляции. Аналогию codebase awareness с situational awareness - считаю принципиально правильной: чрезмерное применение автоматизации вызывает деградацию человека в цикле управления - и когда происходит факап, выясняется что никто точно не понимает как оно случилось, и что делать. Последствия разные - это правда. Но тем ценнее перенимать опыт из индустрий где ошибки стоят дорого, и поэтому они раньше нас задумываются что с ними делать...
Э-э, какие ? Есть класс программ с полным доказательством инвариантов - в свое время этим баловался Кнут и другие академические исследователи. Это безусловно работает - ибо математику не перешибешь - но не позволяет описывать сколько-нибудь сложные реальные системы. А все остальное так или иначе сводится к тестированию - которое может доказать что специфическое поведение есть, но никак не может показать что другого поведения вне тестов - нет...
С аргументом что ИИ генерирует код лучше программистов - не согласен. Любая спецификация на входе ИИ-агента - принципиальна неполна и/или противоречива. Смысл утверждения на естественном языке раскрывается только если источник и приемник разделяют контекст, в котором сделано высказывание. При этом - люди-программисты со временем согласуют свою голову с контекстом (отраслью, проектом) в котором они работают - а у LLM веса зафиксированы, и учиться она не собирается. Нет, можно пытаться подавать опыт через контекст - но там и так места немного, и несмотря на похвальбу в 1М токенов, после трети контекста, ИИ начинает писать как будто хлопнул стопарик водки... а потом еще один, и еще...
В авиации тоже было не реально - когда все были влюблены в парадигму максимальной автоматизации на всех этапах полета. Потребовалось убить в этой парадигме несколько сотен человек чтобы получить общественный резонанс, и подумать еще раз!
Однозначно верная статья! И рецепт лечения надо брать из авиации - situational awareness: пилот должен мыслями "лететь" впереди самолета, вместо того, чтобы действовать реактивно.
То есть - команда (или разработчик) до запуска агента должна иметь видение того, что должно быть построено - и сверять то что делает агент - со своим видением. Это ставит жи-и-рный крест на всякой ереси типа spec-driven development, вайб-кодинге, code as secondary artifact - и заставляет проектировать agentic SDLC таким образом, чтобы человек сохранял ситуационную осведомленность! И при соблюдении этих условий, ИИ-инструменты будут безусловно полезны!
А ничего что у вас окружающий мир так устроен, что все площади простых фигур содержат вторую степень параметра ? И что большая часть взаимодействий поля идет "обратно пропорционально квадрату расстояния" ? А если вы не поняли простой случай с двумя координатами и многочленом второй степени, то как вы потом собираетесь понимать пространства высших размерностей и многочлены высоких степеней, где нельзя ни понятно нарисовать, ни аналитическое решение написать в общем случае ?!
Но вы же понимаете, что если у ребенка есть выбор между "разбираться как брать производную по частям" или "валяться и ржать над видосиками в тик-ток" - то 90% выберут второе. И что вы будете делать в цивилизации, где только 10% живущих как-то понимают устройство техники, которая повсеместно применяется ?
Нет, я не говорю что ваша добровольная модель образования невозможна. Просто тогда СРЕДНИЙ уровень сложности общества надо вернуть обратно между 18 и 19 веками. Будет ли это равномерная деградация - или 10% знающих как-то соберутся на компактной территории и начнут загонять детей в школу и принудительно их обучать - образуя стабильный анклав технически развитой цивилизации - знать не могу...
Вы не поняли главную мысль, к сожалению. То, что сейчас находится далеко от границы познанного человеком - это не "непознанное" а именно "непознаваемое". Познаваемое - это то что лежит близко от границы. Конкретная размерность и форма которой вы будете представляеть познанное - не имеет существенного значения.
Вы не сможете понять "магнитное поле", "проводник", "эдс" без широкой базы, которую вам дали в школе. Или - будете вынуждены просто запомнить физическое явление как феномен. Что случается когда наука феноменизируется таким образом - хорошо реконструировано у Хайнлайна в "Пасынках вселенной": "[...] Джордан решил, и час настал - из мрака и тьмы он Корабль создал! // Миля за милей уютных жилищ, и для плодов золотых хранилищ..." (С).
Еще раз посмотрте на проблему шире - любая школа вынуждена считаться с тем, что она НЕ ЗНАЕТ у кого какие на самом деле способности и кто куда пойдет. Та же музыкальная школа - всех детей гоняет петь в хоре, изучать историю музыки, сольфеджио, играть на фортепиано (даже если ты не пианист), и т.д. Хотя очевидно же, что НИКТО из детей не будет одновременно солистом, певцом в хоре, композитором и далее по тексту. Проблема в том, что невозможно заранее определить кто будет. Поэтому школа учит всех всему до какого-то уровня. КПД образования при этом низкий - потому что одному-двум из сотни все пригодилось, десятку - пригодилась половина, а остальные забыли как страшный сон 90%. Но другого способа просто нет! Если, конечно, вы хотите и дальше жить в развитой машинной цивилизации...
А вы уверены, что все дети в пятом классе достаточно осознанны, чтобы сделать такой выбор ? А не выберут наиболее халявные курсы, потому что реально хочется не в школе сидеть, а по крышам гаражей скакать ?! А еще раз повторю - класса с 8-го уже и так есть выбор - хочешь иди в маткласс, хочешь в гуманитарный, хочешь - в школу олимпийского резерва...
Это вам сейчас кажется, что все можно изучить когда оно понадобиться. Проблема в том, что обучение так не работает. Это не моя специальность - кроме курса "психология обучения взрослых" в районе последнего года магистратуры - но выводы я помню до сих пор. Если вы представите знания человека в виде круга - то внутри будет то, что он знает, снаружи от границы будет тонкая граница возможного познания - а за этой границей зона непознаваемого. Только единицы гениев могут перешагнуть эту границу и сразу попасть в ранее непознаваемое. Обычный человек работает не так - он может воспринять, освоить и превратить в умение-навык только то, что сейчас находится по соседству с понятиями, которые ему уже хорошо известны и освоены. Когда он осваивает кусок этой границы познаваемого - ему открывается новая граница, куда раньше он дотянуться не мог.
У ребенка перед школой - этот круг очень маленький. Соответственно, граница доступного к познанию - тоже небольшая. Школа старается максимальными темпами догнать этот круг познанного до некой общественой нормы, чтобы вы дальше могли в любом направлении двигаться самостоятельно (или при методической поддержке ака образовательные видео, курсы, учебники, институт, и т.д.).
Есть альтернативный способ работы с непознаваемым - запоминать это в виде частных ответов и ритуалов. В принципе, это возможно - и человек сможет даже сносно существовать с такой нео-мифологической картиной мира. Проблема в том, что полноценно оперировать этими знаниями он не сможет. Ближайшая аналогия - алхимик в средние века: знаем много частных случаев, ничего не можем толком с этим поделать, ищем философский камень...