Вы как-то не так используете AI. Может модель слабая (попробуйте Claude Sonnet/Opus). Может Вы режим агента не включили на полную (чтобы AI за один запрос написал и код, и тесты, запустил линтеры+тесты и исправил все ошибки, и только потом выдал результат на ревью). Может Вы плохо ставите задачу модели, например не описав достаточно хорошо суть проекта и используемые подходы в CLAUDE.md/AGENTS.md (там должно быть примерно всё то, что выдаётся новичку при онбординге в проект). У Вас в профиле написано "ведущий", значит Вы умеете ставить задачи коллегам - вот ровно так же ставьте задачу и модели.
У меня вот эффект наблюдается прямо противоположный: задачи с ИИ стали крупнее, сложнее и интереснее. С ИИ я берусь за то, что раньше месяцами откладывал, потому что было сложно (или наоборот, нудно) подступиться к этим задачам.
И да, ровно как при переходе на высокоуровневые языки, количество строк уменьшилось на порядок - тех строк, что я набираю модели, чтобы получить тот же результат, как если бы я сам набрал код.
А ему это и не нужно. Он определит доступность серверов телеги и внешний IP, после чего траффик к этому внешнему IP забанят предполагая что это VPN (раз телега доступна).
Нет. Они рассчитывают на то, что у пользователя на этом же устройстве будет стоять ещё и Max, который определит наличие VPN и его выходной адрес, что позволит легко его заблокировать.
Кстати, интересная идея - использовать двух-хоповую настройку VPN: телефон подключается к VPN с IP1, сервер с IP1 роутит трафик через сервер с IP2, в результате в инет трафик отправленный на IP1 выходит с IP2 ⇒ РКН определяет IP2, блокирует трафик к IP2 ⇒ всё продолжает работать.
Проблемы сложности написания кода на сях решаема в масштабах человечества банальным наращиваем экспертизы со временем.
Так о том и речь. Мы наращивали экспертизу в C более 50 лет. И эта экспертиза нам однозначно говорит: ручное управление памятью абсолютно большинство разработчиков не вытягивают. Или Вы предлагаете ещё лет 50 понаращивать, в надежде что что-то изменится? :)
Или KeePass. Он тоже умеет OTP делать. Правда, обычно в нём же и пароль лежит, т.е. это уже не 2FA по сути. Но это можно решить сделав для 2FA отдельную БД и держать её на другом устройстве. Ну или не заморачиваться, если есть уверенность в защищённости основной БД и компа, на котором она используется.
Смешно. А по факту - это война меча и щита. И буквально пару дней назад она меня задолбала и я купил отдельный телефон для таких капризных приложений, потому что у меня уже нет ни времени ни моральных сил пытаться запустить Google Wallet под Magisk+LSPosed+XPrivacyLua не отключая при этом все эти защиты для Google Play Services сотоварищи. Я попытался, оно сходу с минимально допустимыми (для меня) ограничениями не завелось, ну и вот. Может там и получилось бы что-то нашаманить убив на это несколько часов, но не факт. И даже если бы получилось, то не факт, что через несколько недель после очередного обновления оно бы снова не поломалось. Когда я некоторое время назад тестил Safety Net на этом телефоне - всё проходило, но, видать, Google Wallet этого мало.
Работая вот так, по кусочкам, Вы не просто видите все куски - Вы видите промежуточные, часто некорректные куски. Если дать агенту самому выполнить весь цикл включая тесты, то Вам понадобится изучить только один, финальный вариант. Т.е. Ваших усилий это потребует меньше, весь процесс пройдёт быстрее, но при этом будет ровно тот же уровень контроля: Вы смотрите абсолютно все изменения до коммита в репо.
Ну, так было раньше. Сейчас настраиваются предпочтения проекта в AGENT.md/CLAUDE.md плюс аналогичные предпочтения пользователя в глобальных конфигах, добавляется инструмент memory - и степень амнезии у ИИ сильно уменьшается.
И потом никто не знает, что это за код и что он на самом деле делает.
В смысле? Вы попросили реализовать фичу/пофиксить баг, агент сделал, дальше смотрите git diff и разбираетесь, что вы сейчас собираете закоммитить в репо - ровно так же, как при работе без ИИ.
Такая разработка, со стороны человека, является по сути не разработкой, а приёмкой.
Всё верно. И во всех компаниях этот подход активно практиковали задолго до ИИ - называется "сениор делает ревью PR созданного миддлом". Тут снова ничего не изменилось - кроме того, что миддл на жёсткие замечания в ревью мог обидеться и испортиться, а ИИ не обижается (пока, по крайней мере). Ну и переделывает в соответствии с замечаниями ИИ быстрее любого миддла.
вся ответственность возлагается на авось
Не на авось, а на разработчика использующего ИИ.
Соответствия ТЗ это не даёт.
LLM - это случайный алгоритм.
Да, но с людьми та же фигня: написанный людьми код часто не соответствует ТЗ, и качество написанного кода зависит от случайности - насколько хорошего разработчика удалось нанять и насколько этот разработчик был "в ресурсе" в день работы над этой задачей.
Ваша проблема - в Ваших ожиданиях. Вы привыкли, что если что-то делает программа/алгоритм, то она делает это надёжно и одинаково - в отличие от людей. Но ИИ в этом плане ближе к людям, чем к программам.
ИИ выполняет задачу быстрее и дешевле людей, но качество решения будет примерно как у среднего человека - такое же ненадёжное, но более-менее рабочее.
Не надо просить модель выдавать код страницами. Надо использовать режим агента, чтобы она сама писала код в файлы, писала тесты в файлы, запускала тесты и линтеры, исправляла все ошибки, и только потом сообщала пользователю что она выполнила задачу. Это сразу исключит любые галлюцинации, API не тех библиотек и т.п. Но вместо этого добавит вопрос безопасности: если ИИ может запускать тесты, которые сама же и написала, то по факту у неё уже есть полный доступ к компу под аккаунтом текущего пользователя, даже если прямой доступ к шеллу ИИ не давать.
Вы упускаете из виду, что гадят - не программисты. Программисты (настоящие, у которых глаза горят, а не вкатуны) как раз наоборот, по большей части перфекционисты и предпочли бы такого не делать. Ключевая причина в том, что бизнес требует "быстрее, больше, дешевле!!!" - и именно эту бизнес-задачу решают все упомянутые Вами подходы и технологии, включая текущий ИИ. А дальше в процессе работы программистам отбивают в принципе перефекционизм, они привыкают писать так, как нужно бизнесу - и потом тащат эти подходы даже в свои пет-проекты, к сожалению.
лень следить за памятью
А вот это не совсем правда. Без помощи инструментов (сборщика мусора или компилятора как в rust) люди за последние десятилетия однозначно продемонстрировали неспособность вручную уследить за выделением и освобождением памяти - нашего мозга на это физически не хватает, тут дело вовсе не в лени. (Во всём мире известны имена всего нескольких разработчиков, которым хватало мозгов писать надёжный и безопасный код на C. Добавим неизвестных героев - получим ну сотню, ну две сотни таких уникумов. В масштабе планеты это - погрешность.)
взяв любой проект мы не можем быть убеждены что GPT доведёт решение а не надоедает кучу каши, не откроет кучу дыр в безопасности, не поломать логику
Да, но с людьми ровно то же самое. Особенно если это максимум миддлы.
А в вашем примере попросили написать код, который уже по факту написан, оно и не удивительно что зная исходный код компилятора можно и свой создать.
Это, кстати, правда. И, тем показательнее описанный в блоге кейс: даже имея доступ (и на этапе обучения, и на этапе обработки промпта) к исходникам 100% рабочих компиляторов ИИ справилась с задачей далеко не на 100%. Но, опять же, я абсолютно уверен, что и обычные миддлы выдали бы примерно такой же результат, и тоже не смотря на доступ к исходникам других компиляторов.
А почему интересно при замене программистов не говорят например про замену тех же самых топ менеджеров?
Потому что топы - это не про работу руками (где ИИ что-то может), а про ответственность (где ИИ не может в принципе ничего). Прогнозируют и анализируют не топы, а аналитики/маркетологи/etc. - и вот их ИИ может заменить. (И да, в вырожденном случае, когда топ - это "племянник кого надо" и по факту никак не отвечает за свои решения - технически ИИ его заменить действительно может… только кто же позволит заменить племянника-то. Так что нет, ИИ топов не заменит никогда.)
Только опытный разработчик может поднять, что код написанный ИИ стоит дороже в обслуживании, в определённый момент вы перестаете владеть кодом.
При вайб-кодинге - безусловно. Но если тщательное ревьювить сгенерированный код и доводить его (вручную, или уточнением промпта/добавлением правил в AGENT.md) до своего обычного уровня - то владение кодом сохраняется.
пока что нет такого GPT, решение которого бы сходились к правильному спустя какое-то количество итераций (без участия разработчика)
Вы немного отстали - такой уже есть. При условии что проект не очень большого размера и приемлемости качества кода уровня миддл-разработчика. Но при росте размера проекта или заметном усложнении требований - проект начнёт разваливаться ровно так же, как он развалится если такой проект пишут одни миддлы. Хороший пример такой ситуации - как разраб Anthropic тестировал новую модель Opus 4.6 на задаче разработки компилятора C в стиле вайб-кодинга: https://www.anthropic.com/engineering/building-c-compiler
Тесты, в том числе написанные людьми, вообще мало что гарантируют - из того, что нам бы хотелось, чтобы они гарантировали. Именно поэтому весь существующий код полон багов и уязвимостей, несмотря на покрытие тестами.
Если без иллюзий, то юнит-тесты гарантируют только то, что покрытый тестами код запускается и делает то, что от него ожидает автор тестов. Причём ожидания автора тестов могут быть далеки от реальных требований бизнеса к этому коду. Более высокоуровневые типы тестов проверяют что-то более близкое к реальным бизнес-требованиям, но из-за медленного выполнения таких тестов и сложности (из-за комбинаторного взрыва и невозможности мокать разные мелочи внутри) написания таких тестов - они проверяют незначительный процент реальных вариантов использования. В результате как ни танцуй, но никаких реально полезных для бизнеса гарантий никакие тесты не дадут - они просто проверят что базовые сценарии использования действительно работают (что уже не так и мало, но это нельзя назвать "гарантиями").
В случае ИИ у тестов появляется дополнительная задача: они нужны для того, чтобы автоматически вычистить из кода нейрослоп/галлюцинации, и сделать это до того, как показать сгенерированный код разработчику для ревью. Поэтому мельком глянуть наличие тестов, как я описал, обычно достаточно, чтобы появился смысл тратить своё время на ревью сгенерированного кода - по крайней мере это даёт уверенность, что это код более-менее рабочий.
Всё это не мешает отдельно попросить ИИ добавить тесты для конкретных use cases, и мельком глянуть что добавленные тесты действительно выполняют именно эти use cases. И в итоге обычно получается покрытие тестами (и качество этих тестов) не хуже, чем обычно при работе без ИИ - но как правило оно заметно лучше, потому что люди ленятся писать тесты, это всегда было самой неприятной частью работы.
Так она и тесты соответствующим образом поправит, и таким образом ошибку замаскирует.
Ну, люди тоже так частенько поступали. Иногда такое ловится на ревью, но нередко так и идёт в прод, пока этот баг не отрепортят пользователи.
И зачем тогда они нужны?
Убедиться что хоть что-то хоть как-то работает. Повысить шансы отловить регрессии при изменении кода. Это не те гарантии от наличия тестов, о которых мечтается, но тоже очень немало.
что вручную делалось в основном через копипаст
Через встроенные в IDE сниппеты оно делалось.
В моей практике тесты это своего рода "двойная запись" из бухгалтерии, тщательная составленная манифестация ожиданий.
Ну, никто не мешает и дальше настолько вкладываться в тесты. Просто эту манифестацию теперь достаточно изложить ИИ на русском чтобы он быстро набрал нужные тесты. И никто не мешает потом их тщательно ревьювить, если в этом ощущается необходимость. Но сам процесс набора этих тестов ИИ в любом случае сильно ускоряет, да и тесты обычно у него проверяют именно то, что сказано.
Осталось показать, что «машкоды → ассемблер → C/Pascal» и «неиспользование чатботов → использование чатботов» это процессы одного типа.
Думаю, это зависит от подхода к использованию ИИ. В моём случае это ощущается именно так - как повышение уровня абстракции, работа с кодом на более высоком уровне.
Я продумываю изменение функционала, проектирую - а ИИ потом тупо набирает и отлаживает тот код, который я в общих чертах себе представил по результату проектирования. В результате работа становится более творческой (в смысле, процент времени на проектирование увеличивается, а на механический набор кода и отладку уменьшается), фичи и багфиксы реализуются быстрее, процент покрытия тестами становится выше, документация обновляется оперативнее.
новый способ реюза кода
В моём подходе - это вообще не похоже на реюз кода, потому что ИИ просто набирает практически тот же код, который бы набрал и я сам. И на ревью я в основном сравниваю предложенный ИИ код с собственными ожиданиями и синхронизирую их.
А вот если подход не такой, как у меня, а вайб-кодинг - вот тогда да, это действительно похоже на то, что Вы описали. Ну так вайб-кодинг это не единственный вариант использования ИИ (как по мне - это вообще не вариант).
Но программисты код уже не понимают, поэтому исправить ничего не могут.
Такое имеет место давно, люди такое устраивали без всякого ИИ. Обычно в таких случаях либо ищут уникума, который ещё помнит как работать с этим кодом, либо переписывают на более современных технологиях, специалистов для которых на рынке хватает.
отрицательным развитием.
В каком-то смысле - так и есть. Но ручное написание кода - далеко не первый утерянный навык. Ещё мы (не программисты, а банально 99% городских жителей) разучились охотиться, строить себе дома, выращивать урожай, ковать оружие… деградировали, в общем.
Когда-то все писали в машинных кодах. (На компах лично я это не застал, но на ПМК я этим пару лет занимался с удовольствием.) Потом появился ассемблер, и разработчики деградировали - больше они писать в машинных кодах не способны.
Потом многие писали на ассемблере. (Тут я уже застал в полный рост, даже дипломную работу в компьютерном колледже написал на x86 ассемблере, а не на C/Pascal как большинство одноклассников. Было очень интересно делать разные системные штуки, которые на языках высокого уровня сделать было либо невозможно либо они делались крайне странно/неэффективно.) Увы, но я деградировал, и сегодня еле-еле способен асм читать, скорее догадываясь чем понимая современные диалекты. Писать точно не в состоянии.
Так что да, скорость деградации поражает. Но, нет, это не проблема - потому что деградируют только ненужные навыки. Поэтому мы вполне можем называть этот процесс не деградацией, а развитием!
Вы как-то не так используете AI.
Может модель слабая (попробуйте Claude Sonnet/Opus).
Может Вы режим агента не включили на полную (чтобы AI за один запрос написал и код, и тесты, запустил линтеры+тесты и исправил все ошибки, и только потом выдал результат на ревью).
Может Вы плохо ставите задачу модели, например не описав достаточно хорошо суть проекта и используемые подходы в
CLAUDE.md/AGENTS.md(там должно быть примерно всё то, что выдаётся новичку при онбординге в проект). У Вас в профиле написано "ведущий", значит Вы умеете ставить задачи коллегам - вот ровно так же ставьте задачу и модели.У меня вот эффект наблюдается прямо противоположный: задачи с ИИ стали крупнее, сложнее и интереснее. С ИИ я берусь за то, что раньше месяцами откладывал, потому что было сложно (или наоборот, нудно) подступиться к этим задачам.
И да, ровно как при переходе на высокоуровневые языки, количество строк уменьшилось на порядок - тех строк, что я набираю модели, чтобы получить тот же результат, как если бы я сам набрал код.
А ему это и не нужно. Он определит доступность серверов телеги и внешний IP, после чего траффик к этому внешнему IP забанят предполагая что это VPN (раз телега доступна).
Нет. Они рассчитывают на то, что у пользователя на этом же устройстве будет стоять ещё и Max, который определит наличие VPN и его выходной адрес, что позволит легко его заблокировать.
Кстати, интересная идея - использовать двух-хоповую настройку VPN: телефон подключается к VPN с IP1, сервер с IP1 роутит трафик через сервер с IP2, в результате в инет трафик отправленный на IP1 выходит с IP2 ⇒ РКН определяет IP2, блокирует трафик к IP2 ⇒ всё продолжает работать.
Так о том и речь. Мы наращивали экспертизу в C более 50 лет. И эта экспертиза нам однозначно говорит: ручное управление памятью абсолютно большинство разработчиков не вытягивают. Или Вы предлагаете ещё лет 50 понаращивать, в надежде что что-то изменится? :)
Или KeePass. Он тоже умеет OTP делать. Правда, обычно в нём же и пароль лежит, т.е. это уже не 2FA по сути. Но это можно решить сделав для 2FA отдельную БД и держать её на другом устройстве. Ну или не заморачиваться, если есть уверенность в защищённости основной БД и компа, на котором она используется.
Смешно. А по факту - это война меча и щита. И буквально пару дней назад она меня задолбала и я купил отдельный телефон для таких капризных приложений, потому что у меня уже нет ни времени ни моральных сил пытаться запустить Google Wallet под Magisk+LSPosed+XPrivacyLua не отключая при этом все эти защиты для Google Play Services сотоварищи. Я попытался, оно сходу с минимально допустимыми (для меня) ограничениями не завелось, ну и вот. Может там и получилось бы что-то нашаманить убив на это несколько часов, но не факт. И даже если бы получилось, то не факт, что через несколько недель после очередного обновления оно бы снова не поломалось. Когда я некоторое время назад тестил Safety Net на этом телефоне - всё проходило, но, видать, Google Wallet этого мало.
Работая вот так, по кусочкам, Вы не просто видите все куски - Вы видите промежуточные, часто некорректные куски. Если дать агенту самому выполнить весь цикл включая тесты, то Вам понадобится изучить только один, финальный вариант. Т.е. Ваших усилий это потребует меньше, весь процесс пройдёт быстрее, но при этом будет ровно тот же уровень контроля: Вы смотрите абсолютно все изменения до коммита в репо.
Ну, так было раньше. Сейчас настраиваются предпочтения проекта в AGENT.md/CLAUDE.md плюс аналогичные предпочтения пользователя в глобальных конфигах, добавляется инструмент memory - и степень амнезии у ИИ сильно уменьшается.
В смысле? Вы попросили реализовать фичу/пофиксить баг, агент сделал, дальше смотрите git diff и разбираетесь, что вы сейчас собираете закоммитить в репо - ровно так же, как при работе без ИИ.
Всё верно. И во всех компаниях этот подход активно практиковали задолго до ИИ - называется "сениор делает ревью PR созданного миддлом". Тут снова ничего не изменилось - кроме того, что миддл на жёсткие замечания в ревью мог обидеться и испортиться, а ИИ не обижается (пока, по крайней мере). Ну и переделывает в соответствии с замечаниями ИИ быстрее любого миддла.
Не на авось, а на разработчика использующего ИИ.
Да, но с людьми та же фигня: написанный людьми код часто не соответствует ТЗ, и качество написанного кода зависит от случайности - насколько хорошего разработчика удалось нанять и насколько этот разработчик был "в ресурсе" в день работы над этой задачей.
Ваша проблема - в Ваших ожиданиях. Вы привыкли, что если что-то делает программа/алгоритм, то она делает это надёжно и одинаково - в отличие от людей. Но ИИ в этом плане ближе к людям, чем к программам.
ИИ выполняет задачу быстрее и дешевле людей, но качество решения будет примерно как у среднего человека - такое же ненадёжное, но более-менее рабочее.
Не надо просить модель выдавать код страницами. Надо использовать режим агента, чтобы она сама писала код в файлы, писала тесты в файлы, запускала тесты и линтеры, исправляла все ошибки, и только потом сообщала пользователю что она выполнила задачу. Это сразу исключит любые галлюцинации, API не тех библиотек и т.п. Но вместо этого добавит вопрос безопасности: если ИИ может запускать тесты, которые сама же и написала, то по факту у неё уже есть полный доступ к компу под аккаунтом текущего пользователя, даже если прямой доступ к шеллу ИИ не давать.
Вы упускаете из виду, что гадят - не программисты. Программисты (настоящие, у которых глаза горят, а не вкатуны) как раз наоборот, по большей части перфекционисты и предпочли бы такого не делать. Ключевая причина в том, что бизнес требует "быстрее, больше, дешевле!!!" - и именно эту бизнес-задачу решают все упомянутые Вами подходы и технологии, включая текущий ИИ. А дальше в процессе работы программистам отбивают в принципе перефекционизм, они привыкают писать так, как нужно бизнесу - и потом тащат эти подходы даже в свои пет-проекты, к сожалению.
А вот это не совсем правда. Без помощи инструментов (сборщика мусора или компилятора как в rust) люди за последние десятилетия однозначно продемонстрировали неспособность вручную уследить за выделением и освобождением памяти - нашего мозга на это физически не хватает, тут дело вовсе не в лени. (Во всём мире известны имена всего нескольких разработчиков, которым хватало мозгов писать надёжный и безопасный код на C. Добавим неизвестных героев - получим ну сотню, ну две сотни таких уникумов. В масштабе планеты это - погрешность.)
Да, но с людьми ровно то же самое. Особенно если это максимум миддлы.
Это, кстати, правда. И, тем показательнее описанный в блоге кейс: даже имея доступ (и на этапе обучения, и на этапе обработки промпта) к исходникам 100% рабочих компиляторов ИИ справилась с задачей далеко не на 100%. Но, опять же, я абсолютно уверен, что и обычные миддлы выдали бы примерно такой же результат, и тоже не смотря на доступ к исходникам других компиляторов.
Потому что топы - это не про работу руками (где ИИ что-то может), а про ответственность (где ИИ не может в принципе ничего). Прогнозируют и анализируют не топы, а аналитики/маркетологи/etc. - и вот их ИИ может заменить. (И да, в вырожденном случае, когда топ - это "племянник кого надо" и по факту никак не отвечает за свои решения - технически ИИ его заменить действительно может… только кто же позволит заменить племянника-то. Так что нет, ИИ топов не заменит никогда.)
Лучше скажите, как там с Perl 6 в проде - он вообще существует?
При вайб-кодинге - безусловно. Но если тщательное ревьювить сгенерированный код и доводить его (вручную, или уточнением промпта/добавлением правил в
AGENT.md) до своего обычного уровня - то владение кодом сохраняется.Это сильно зависит от используемой модели. GPT-4.1 делает именно то, что Вы описали, а вот Claude Sonnet/Opus выдают вполне адекватный код.
Вы немного отстали - такой уже есть. При условии что проект не очень большого размера и приемлемости качества кода уровня миддл-разработчика. Но при росте размера проекта или заметном усложнении требований - проект начнёт разваливаться ровно так же, как он развалится если такой проект пишут одни миддлы. Хороший пример такой ситуации - как разраб Anthropic тестировал новую модель Opus 4.6 на задаче разработки компилятора C в стиле вайб-кодинга: https://www.anthropic.com/engineering/building-c-compiler
Тесты, в том числе написанные людьми, вообще мало что гарантируют - из того, что нам бы хотелось, чтобы они гарантировали. Именно поэтому весь существующий код полон багов и уязвимостей, несмотря на покрытие тестами.
Если без иллюзий, то юнит-тесты гарантируют только то, что покрытый тестами код запускается и делает то, что от него ожидает автор тестов. Причём ожидания автора тестов могут быть далеки от реальных требований бизнеса к этому коду. Более высокоуровневые типы тестов проверяют что-то более близкое к реальным бизнес-требованиям, но из-за медленного выполнения таких тестов и сложности (из-за комбинаторного взрыва и невозможности мокать разные мелочи внутри) написания таких тестов - они проверяют незначительный процент реальных вариантов использования. В результате как ни танцуй, но никаких реально полезных для бизнеса гарантий никакие тесты не дадут - они просто проверят что базовые сценарии использования действительно работают (что уже не так и мало, но это нельзя назвать "гарантиями").
В случае ИИ у тестов появляется дополнительная задача: они нужны для того, чтобы автоматически вычистить из кода нейрослоп/галлюцинации, и сделать это до того, как показать сгенерированный код разработчику для ревью. Поэтому мельком глянуть наличие тестов, как я описал, обычно достаточно, чтобы появился смысл тратить своё время на ревью сгенерированного кода - по крайней мере это даёт уверенность, что это код более-менее рабочий.
Всё это не мешает отдельно попросить ИИ добавить тесты для конкретных use cases, и мельком глянуть что добавленные тесты действительно выполняют именно эти use cases. И в итоге обычно получается покрытие тестами (и качество этих тестов) не хуже, чем обычно при работе без ИИ - но как правило оно заметно лучше, потому что люди ленятся писать тесты, это всегда было самой неприятной частью работы.
Ну, люди тоже так частенько поступали. Иногда такое ловится на ревью, но нередко так и идёт в прод, пока этот баг не отрепортят пользователи.
Убедиться что хоть что-то хоть как-то работает. Повысить шансы отловить регрессии при изменении кода. Это не те гарантии от наличия тестов, о которых мечтается, но тоже очень немало.
Через встроенные в IDE сниппеты оно делалось.
Ну, никто не мешает и дальше настолько вкладываться в тесты. Просто эту манифестацию теперь достаточно изложить ИИ на русском чтобы он быстро набрал нужные тесты. И никто не мешает потом их тщательно ревьювить, если в этом ощущается необходимость. Но сам процесс набора этих тестов ИИ в любом случае сильно ускоряет, да и тесты обычно у него проверяют именно то, что сказано.
Думаю, это зависит от подхода к использованию ИИ. В моём случае это ощущается именно так - как повышение уровня абстракции, работа с кодом на более высоком уровне.
Я продумываю изменение функционала, проектирую - а ИИ потом тупо набирает и отлаживает тот код, который я в общих чертах себе представил по результату проектирования. В результате работа становится более творческой (в смысле, процент времени на проектирование увеличивается, а на механический набор кода и отладку уменьшается), фичи и багфиксы реализуются быстрее, процент покрытия тестами становится выше, документация обновляется оперативнее.
В моём подходе - это вообще не похоже на реюз кода, потому что ИИ просто набирает практически тот же код, который бы набрал и я сам. И на ревью я в основном сравниваю предложенный ИИ код с собственными ожиданиями и синхронизирую их.
А вот если подход не такой, как у меня, а вайб-кодинг - вот тогда да, это действительно похоже на то, что Вы описали. Ну так вайб-кодинг это не единственный вариант использования ИИ (как по мне - это вообще не вариант).
Такое имеет место давно, люди такое устраивали без всякого ИИ. Обычно в таких случаях либо ищут уникума, который ещё помнит как работать с этим кодом, либо переписывают на более современных технологиях, специалистов для которых на рынке хватает.
В каком-то смысле - так и есть. Но ручное написание кода - далеко не первый утерянный навык. Ещё мы (не программисты, а банально 99% городских жителей) разучились охотиться, строить себе дома, выращивать урожай, ковать оружие… деградировали, в общем.
Когда-то все писали в машинных кодах. (На компах лично я это не застал, но на ПМК я этим пару лет занимался с удовольствием.) Потом появился ассемблер, и разработчики деградировали - больше они писать в машинных кодах не способны.
Потом многие писали на ассемблере. (Тут я уже застал в полный рост, даже дипломную работу в компьютерном колледже написал на x86 ассемблере, а не на C/Pascal как большинство одноклассников. Было очень интересно делать разные системные штуки, которые на языках высокого уровня сделать было либо невозможно либо они делались крайне странно/неэффективно.) Увы, но я деградировал, и сегодня еле-еле способен асм читать, скорее догадываясь чем понимая современные диалекты. Писать точно не в состоянии.
Ещё вчера почти все писали на языках высокого уровня. А теперь они снова норовят деградировать, сволочи (и я тоже)! Никогда такого не было, и вот, опять! © (Ещё пару лет назад я писал тесты и учил других их писать так, чтобы это было не больно и полезно. А сегодня я тесты максимум проглядываю мельком, понимая их очень в общих чертах - примерно как ассемблер. Потому что их пишет ИИ, и от меня на ревью требуется убедиться, что тесты в принципе есть, и вроде бы тестируют реальный код на то, что нужно проверять - и всё. Вникать в реализацию тестов детальнее сегодня смысла вообще ноль.)
Так что да, скорость деградации поражает. Но, нет, это не проблема - потому что деградируют только ненужные навыки. Поэтому мы вполне можем называть этот процесс не деградацией, а развитием!