Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Узкое место это формулировка того, что должно быть истинно. Люди остаются единственными, кто может сказать, что мы хотим получить и зачем.
И число таких людей, увы, сильно меньше числа тех, кто умеет проверять код. А порой и вовсе равно нулю - то есть, никто из людей (как и машин) заранее не знает, что именно "должно быть истинно" в данной конкретной ситуации. В бухгалтерии - принципиально знают. В авиакомпании - знают (инцидент = исключение, как его обрабатывать, принципиально понятно). А в жизни в целом - не всегда.
Ограниченность человеческого знания - всего человеческого знания вообще, а, значит, и машинного знания тоже, - это еще один универсальный ограничитель. Но об этом, увы, нечасто вспоминают.
Как мне кажется, это принципиальная ошибка и фундаментальное ограничение при внедрении ИИ в разработке, это ограниченность человека, так как он не может (и не должен) быть ревьювером при такой скорости генерации кода, какие может позволить простейший агент. И единственный способ разрешить эту ситуацию, использовать не полный по Тьюрингу язык, который позволяет математически доказывать корректность кода даже ценой большей многословности исходного текста.
единственный способ разрешить эту ситуацию, использовать не полный по Тьюрингу язык, который позволяет математически доказывать корректность кода
Корректность кода, допустим, вы докажете. А как доказать, что код корректно делает именно то, что от него требуется? Требуется не коду и не агенту, его написавшему, и даже не тимлиду с архитектором. Требуется пользователям.
Ошибки в коде найти принципиально можно. Ошибки в его исходной модели найти труднее. И, увы, - их никакой агент сам не найдет.
Контрактное программирование - хотя мне очень НЕ нравится использовать это термин, но общепринято подобную модель разработки называть именно так (применять ограничения ТЗ/модели на реализацию алгоритма).
Я не об этих ограничениях говорю. Модель может быть очень точной, но делать не то, что нужно. С точки зрения кодера - такая модель идеальна. С точки зрения юзера - бесполезна или лаже вредна. С точки зрения кастомера (деньги за нее заплатившего) - потеря денег.
В ситуации, когда кодирование становится по сути бесплатным, именно это выйдет, я думаю, на первый план: корректность модели, а некодс, ее реализующего.
Как выглядит “модель” и чем принципиально запись “модели” отличается от кода, который эту модель реализует?
Хороший вопрос. Если упрощенно, спецификация - один из видов такой модели. Если спецификация неправильно описывает реальную ситуацию и косячит в требованиях, никакой код это не исправит. А исправлять все равно придется - и вносить изменения в модель (спецификацию) тоже. Но это несколько сложнее, чем если модель с самого начала корректно описывает ситуацию и действия в ней.
Другой вид модели - архитектура программы. Если косяки на этом уровне, то код может быть сколь угодно корректным сам по себе, но поведение программы будет отличаться от требуемого, как минимум, в каких-то ситуациях. Кодом это не исправить.
А есть еще и такая вещь, как ментальные ошибки, недосмотры и прочие косяки на стороне заказчика. Они, в конечном счете, отражаются в спецификации. А их основа - неверная ментальная модель: заказчику кажется так, а на самом деле не совсем. Опять же, никаким кодом это не лечится.
И если даже написание математически корректного кода будет стоить ноль, то эти косяки в нем все равно останутся. Все тесты, сколько их ни напиши, будут зелеными, сбоев не будет - а толку все равно ноль. И вот эту проблему никакие агенты сами по себе решить не смогут, ибо эта проблема касается реального мира, в котором программа стоит реальных денег - даже если ее код ничего не стоит.
P.S. Про ментальную модель см. в (не моем) комментарии ниже по тексту. Я полностью подписываюсь под этим определением.
Ладно, попробую сформулировать по другому.
Я задавал вопрос про способ записи модели и без разницы, какой её вид используется (спецификация, архитектура, ментальная или какая либо другая), пытаясь до вас донести, что в идеальном (гипотетическом) случае код программы, это и есть описание модели для её реализации.
И в этом случае доказательное (контрактное) программирование будет является математическим доказательством корректности реализованной модели. Т.е. в этом случае отпадает необходимость в ревью, так как корректность реализации будет математически доказана.
Как только код пишется быстрее, чем читается, начинает копиться непонятое. Это называется легаси.
Ну да. Легаси = нет ментальной модели, фактической и/или требуемой. Ментальная модель = понимание что происходит, набор абстракций, позволяющий эффективно управлять проектом: проектировать (предлагать изменения), принимать решения (по изменениям) разного масштаба, изменять поведение программы. Понимание упрощённое, но достаточное.
От оценки что такое "эффективно" зависит качество ментальной модели
Но вот читают смыслы по-прежнему люди. Скорость написания выросла, скорость проверки не поспевает. То, что копилось двадцать лет, теперь копится за год. Это не прогноз, это уже видно в проектах, где код пишут агенты, а ревью делают по диагонали теми же ИИ-агентами. Код стареет, не успев родиться
Да. У меня ни один крупный вайбовый (где почти не читал код) проект/изменение не ушёл на прод. Каждый такой уходил в болото за мерцающим светом болотных огней, без твердой опоры под ногами. Где я переставал понимать и доверять.
Любая программа может абсолютно корректно делать не то, чего от неё ожидает юзер. Ии здесь, статические анализаторы и т.д. никак не помогут
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неожиданный антивайб разработки через ИИ-агентов