Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
Но в статье я поднимаю немного другую тему: как сделать так, чтобы даже ошибки возникли система продолжала работать насколько это возможно, а пользователь не сталкивался с крашем, потерей данных или “горящим” интерфейсом и надеждой, что его починят как можно скорее. Идеального кода не бывает, а отказоустойчивость — это как раз про то, что делать, когда идеал дал трещину.
Вот именно! Практически в 100% случаев, попытка "продолжить работу после ошибки" - приводит к тому, что система становится не просто бесполезной, но - активно вредной.
Вот у вас нет памяти. Вы начинаете "обходить" ошибки выделения памяти, в результате - теряете данные, пользователь об этом не знает - и получает потерю или искажение пользовательских данных.
Например, разработчик текстового редактора (уровня OpenOffice/MS Word), если попробует "обходить" и "восстанавливаться" после проблем нехватки памяти - запросто может потерять часть документа. Или, например, вставленные рисунки. После чего пользователь этот документ сохраняет - и привет.
Практически единственный пример, когда "обход" ошибок выделения памяти оправдан - это если вы непосредственно по команде пользователя пытаетесь сделать что-то, требующее выделения большого-большого блока памяти, начинаете операцию с выделения памяти - и вот тут реально можно проверить, что память не выделена и операцию выполнить не удастся. И об этом удастся сообщить пользователю, т.к. свободная память ещё есть.
А вот если вы начали большую операцию, выделяете память мелкими кусочками по-объектно, и вот где-то в середине у вас обломалось выделение очередного мелкого объекта - вам кирдык.
Вы не сможете ни сообщить об этом пользователю, ни откатить операцию - так как памяти у вас вообще нет. А на сообщения и откат - сюрприз - нужна память.
Я такое проходил. Допустил утечку памяти, причём, малыми кусочками. За месяц непрерывной работы, память тупо кончилась вся. И дальше, так как программа именно была ориентирована на "продолжение работы" - начала терять функции интерфейса. Пункты из меню. Элементы интерфейса.
Что выглядело совершенным безумием для пользователя. Причём если бы она просто грохнулась - пользователь просто запустил бы её заново.
А, вот откуда появлется куча "программистов", постоянно использующих паттерн:
let data;
try
{
data = this.getSomeData();
} catch(error)
{ data = this.getErrorData();
console.error(error); }
this.doSomething(data);
А ещё паттерн:
bool someFunc(Param * param)
{
if (nullptr == param) return false;
....
}
И ещё хорошо, если ошибку залогируют.
Возможно, если хорошо прищуриться, это может в каких-то редких случаях иметь смысл при разработке фронтенда на JS.
Но! Вот такой подход категорически, абсолютно недопустим при разработке абсолютно любых реально используемых для чего-то разумного продуктов.
Самый разумный подход: это при обнаружении ошибки, которую вы не знаете как можно обработать - немедленно паниковать с сохранением достаточной информации (где и почему) запаниковало.
Попытки продложить работу, если вы обнаружили не предусмотренную вашим алгоритмом ошибку - их необходимо категорически исключить. Продолжая работу при ошибке - вы а) сделаете хуже б) затрудните обнаружение и исправление ошибки.
Включите в ваш набор инструментов аналог макроса assert (я предпочитаю комбинацию verify()/halt())который никогда не отключается, в том числе в релизной сборке.
Активно применяйте его для проверки входных данных, выходных данных, возвращаемых значений и промежуточных условий/утверждений.
Подход "оборонительного программирования" - не означает, что вы должны паниковать и завершать работу, если пользователь указал для сохранения данных файл, не доступный на запись, или если сетевое соединение разорвалось.
Вы можете корректно и разумно обработать эти события? Обрабатывайте. Не можете или вам лень вот прямо сейчас писать код обработки? Ставьте verify().
Но вот если вам в функцию передали nullptr, и в спецификации функции не указано, что "вот этот параметр можно поставить null и поведение будет следующим ..." - паникуйте. Никогда, ни при каких условиях не надо пытаться "маскировать" ошибку.
Читать почту и отвечать на почту. А для того, чтобы ответить на почту - надо знать, что отвечать.
И да, есть такой небольшой нюанс: у нейросети нет отдельного входа для "данных снаружи" и "данных изнутри".
Их можно маркировать "данные присланные снаружи" и "внутренние данные" - но нейросеть технически никак не ограничена в том, чтобы эти данные не могла попутать.
Точно так же, как человек может забыться и в ответ на электронной письмо с незнакомого адреса ответить какой-нибудь конфеденциальной информацией. Типа: "ой, не подумал".
---------------
Теоретически, если у нейросети просто нет доступа к "закрытой" информации - а только к открытой - она не сможет её разгласить. Но тогда особого смысла в этой нейросети и нет.
То есть я правильно понимаю - вместо литературных текстов, системе глубокого обучения дали на вход 22 миллиона спецификаций ферментов и описания их свойств, а далее - для спецификации фермента предложили описать его свойства?
Охренительно. То есть модель никакого физического представляения о самом ферменте (и том, как он работает в огранизме) не имеет, но выдаёт "похожие на настоящие" описания?
Угу. Они покупают комплектующие у американских компаний. А вот производят ли они эти комплектующие в США - или импортируют из Китая - это уже второй вопрос.
И есть большое подозрение, что на каком-то уровне резко выясняется, что "а вот это мы купили в Китае".
Первое, что делаешь, когда сервис не может что-то открыть/запустить/увидеть - отрубаешь SELinux. В большинстве случаев - помогает.
Самоё печальное, что даже в операционках, в которых SELinux поставляется включённым по умолчанию, пакеты установленные из штатного системного репозитария - могут нифига не устанавливать нужные им для функционирования права доступа. Даже такой стандарт, как апач.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
Реально, исторические права доступа в Юниксе - это тот разумный минимум, которым будет пользоваться 95%-98% пользователей. Достаточно просто и удобно, чтобы можно было пользоваться постоянно - и достаточно возможностей/функционала, чтобы решить практически все реальные задачи ограничения прав доступа.
Подход, который реализован в SELinux ( и в системе ограничения прав доступа в Windows ) - он продиктован идеей "давайте сделаем супер-пупер систему, пригодную для суперсекретной деятельности". По спецификации уродов из спецслужб США, которым абсолютно насрать на удобство использования, главное - чтобы "секьюрно".
В результате, 99% пользователей даже и не пытаются с этой системой разобраться. А значит, в принципе не пользуются. А если пользуются - то хрен его знает, не открыто ли там чего лишнего.
"Вся эта документация и проверка относительно десятков «корпоративных стандартов разработки», приемо-сдаточные испытания, проверка кибербезопасности, выкладвание в Реестр Российского ПО, проверка на 4-й уровень доверия ФСТЭК и куча другой бумагомарательной необходимой работы — в идеале будет делаться автоматически."
Вы понимаете, что это одна из проблем внедрения генерирующих нейронных сетей?
Ведь вся эта бумага, вся это "ненужна документация" и "стандарты кодирования" - они все сделаны не для того, чтобы испортить настроение разработчика. Это всё сделано для того, чтобы продуктом можно было нормально пользоваться и его развивать - человеку.
Если вы всё это отдаёте "нейросетям" - значит, можете с тем же успехом всё это просто выкинуть.
Даже хуже - отсутствие документации лучше, чем наличие бессмысленной сгенерированной документации. Которая выглядит почти как настоящая, и на 80% действительно соответствует реальности - а на 20% содержит галлюцинации.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Ну выбирай, будешь крепостным или колхозником?
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
Халява! Оплачивается госдепом США. Всё ради процветания и демократии в Иране!
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Это и называется галлюцинацией нейросети.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
А критиковать Троцкий начал именно тогда, когда проиграл во внутрипартийной борьбе. А проиграл, потому что не смог предложить ничего разумного.
Замечаетельно! Описания коммитов, сгенерированные нейросетью - читать будет только другая нейросеть.
Вот именно! Практически в 100% случаев, попытка "продолжить работу после ошибки" - приводит к тому, что система становится не просто бесполезной, но - активно вредной.
Вот у вас нет памяти. Вы начинаете "обходить" ошибки выделения памяти, в результате - теряете данные, пользователь об этом не знает - и получает потерю или искажение пользовательских данных.
Например, разработчик текстового редактора (уровня OpenOffice/MS Word), если попробует "обходить" и "восстанавливаться" после проблем нехватки памяти - запросто может потерять часть документа. Или, например, вставленные рисунки. После чего пользователь этот документ сохраняет - и привет.
Практически единственный пример, когда "обход" ошибок выделения памяти оправдан - это если вы непосредственно по команде пользователя пытаетесь сделать что-то, требующее выделения большого-большого блока памяти, начинаете операцию с выделения памяти - и вот тут реально можно проверить, что память не выделена и операцию выполнить не удастся. И об этом удастся сообщить пользователю, т.к. свободная память ещё есть.
А вот если вы начали большую операцию, выделяете память мелкими кусочками по-объектно, и вот где-то в середине у вас обломалось выделение очередного мелкого объекта - вам кирдык.
Вы не сможете ни сообщить об этом пользователю, ни откатить операцию - так как памяти у вас вообще нет. А на сообщения и откат - сюрприз - нужна память.
Я такое проходил. Допустил утечку памяти, причём, малыми кусочками. За месяц непрерывной работы, память тупо кончилась вся. И дальше, так как программа именно была ориентирована на "продолжение работы" - начала терять функции интерфейса. Пункты из меню. Элементы интерфейса.
Что выглядело совершенным безумием для пользователя. Причём если бы она просто грохнулась - пользователь просто запустил бы её заново.
А, вот откуда появлется куча "программистов", постоянно использующих паттерн:
let data; try{data = this.getSomeData(); } catch(error){ data = this.getErrorData();console.error(error); }this.doSomething(data);А ещё паттерн:
bool someFunc(Param * param)
{
if (nullptr == param) return false;
....
}
И ещё хорошо, если ошибку залогируют.Возможно, если хорошо прищуриться, это может в каких-то редких случаях иметь смысл при разработке фронтенда на JS.Но! Вот такой подход категорически, абсолютно недопустим при разработке абсолютно любых реально используемых для чего-то разумного продуктов.Самый разумный подход: это при обнаружении ошибки, которую вы не знаете как можно обработать - немедленно паниковать с сохранением достаточной информации (где и почему) запаниковало.Попытки продложить работу, если вы обнаружили не предусмотренную вашим алгоритмом ошибку - их необходимо категорически исключить. Продолжая работу при ошибке - вы а) сделаете хуже б) затрудните обнаружение и исправление ошибки.Включите в ваш набор инструментов аналог макроса assert (я предпочитаю комбинацию verify()/halt())который никогда не отключается,в том числе в релизной сборке.Активно применяйте его для проверки входных данных, выходных данных, возвращаемых значений и промежуточных условий/утверждений.
Подход "оборонительного программирования" - не означает, что вы должны паниковать и завершать работу, если пользователь указал для сохранения данных файл, не доступный на запись, или если сетевое соединение разорвалось.
Вы можете корректно и разумно обработать эти события? Обрабатывайте. Не можете или вам лень вот прямо сейчас писать код обработки? Ставьте verify().
Но вот если вам в функцию передали nullptr, и в спецификации функции не указано, что "вот этот параметр можно поставить null и поведение будет следующим ..." - паникуйте. Никогда, ни при каких условиях не надо пытаться "маскировать" ошибку.
Читать почту и отвечать на почту. А для того, чтобы ответить на почту - надо знать, что отвечать.
И да, есть такой небольшой нюанс: у нейросети нет отдельного входа для "данных снаружи" и "данных изнутри".
Их можно маркировать "данные присланные снаружи" и "внутренние данные" - но нейросеть технически никак не ограничена в том, чтобы эти данные не могла попутать.
Точно так же, как человек может забыться и в ответ на электронной письмо с незнакомого адреса ответить какой-нибудь конфеденциальной информацией. Типа: "ой, не подумал".
---------------
Теоретически, если у нейросети просто нет доступа к "закрытой" информации - а только к открытой - она не сможет её разгласить. Но тогда особого смысла в этой нейросети и нет.
То есть я правильно понимаю - вместо литературных текстов, системе глубокого обучения дали на вход 22 миллиона спецификаций ферментов и описания их свойств, а далее - для спецификации фермента предложили описать его свойства?
Охренительно. То есть модель никакого физического представляения о самом ферменте (и том, как он работает в огранизме) не имеет, но выдаёт "похожие на настоящие" описания?
Хайпожоры, что тут сказать.
Стартап нашёл в открытой прессе его описание, и решил, что уж они-то смогут реализовать отличную идею!
Ну или хотя бы финансирование привлечь...
В крайнем случае, будут продавать русским эти ядерные отходы, типа "переработка на аутсоурсе".
Угу. Они покупают комплектующие у американских компаний. А вот производят ли они эти комплектующие в США - или импортируют из Китая - это уже второй вопрос.
И есть большое подозрение, что на каком-то уровне резко выясняется, что "а вот это мы купили в Китае".
Первое, что делаешь, когда сервис не может что-то открыть/запустить/увидеть - отрубаешь SELinux. В большинстве случаев - помогает.
Самоё печальное, что даже в операционках, в которых SELinux поставляется включённым по умолчанию, пакеты установленные из штатного системного репозитария - могут нифига не устанавливать нужные им для функционирования права доступа. Даже такой стандарт, как апач.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
Реально, исторические права доступа в Юниксе - это тот разумный минимум, которым будет пользоваться 95%-98% пользователей. Достаточно просто и удобно, чтобы можно было пользоваться постоянно - и достаточно возможностей/функционала, чтобы решить практически все реальные задачи ограничения прав доступа.
Подход, который реализован в SELinux ( и в системе ограничения прав доступа в Windows ) - он продиктован идеей "давайте сделаем супер-пупер систему, пригодную для суперсекретной деятельности". По спецификации уродов из спецслужб США, которым абсолютно насрать на удобство использования, главное - чтобы "секьюрно".
В результате, 99% пользователей даже и не пытаются с этой системой разобраться. А значит, в принципе не пользуются. А если пользуются - то хрен его знает, не открыто ли там чего лишнего.
"Вся эта документация и проверка относительно десятков «корпоративных стандартов разработки», приемо-сдаточные испытания, проверка кибербезопасности, выкладвание в Реестр Российского ПО, проверка на 4-й уровень доверия ФСТЭК и куча другой бумагомарательной необходимой работы — в идеале будет делаться автоматически."
Вы понимаете, что это одна из проблем внедрения генерирующих нейронных сетей?
Ведь вся эта бумага, вся это "ненужна документация" и "стандарты кодирования" - они все сделаны не для того, чтобы испортить настроение разработчика. Это всё сделано для того, чтобы продуктом можно было нормально пользоваться и его развивать - человеку.
Если вы всё это отдаёте "нейросетям" - значит, можете с тем же успехом всё это просто выкинуть.
Даже хуже - отсутствие документации лучше, чем наличие бессмысленной сгенерированной документации. Которая выглядит почти как настоящая, и на 80% действительно соответствует реальности - а на 20% содержит галлюцинации.
Угу. И вывод какой замечательный - надо больше микрогридов, больше децентрализации, больше солнечных батарей и домашних аккумуляторов.
Ага, конечно. Больше солнечных батарей богу зелёной энергии к трону его!