Ну, так было раньше. Сейчас настраиваются предпочтения проекта в 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 как большинство одноклассников. Было очень интересно делать разные системные штуки, которые на языках высокого уровня сделать было либо невозможно либо они делались крайне странно/неэффективно.) Увы, но я деградировал, и сегодня еле-еле способен асм читать, скорее догадываясь чем понимая современные диалекты. Писать точно не в состоянии.
Так что да, скорость деградации поражает. Но, нет, это не проблема - потому что деградируют только ненужные навыки. Поэтому мы вполне можем называть этот процесс не деградацией, а развитием!
Круто, но есть нюанс. Если проекты и задачи не личные, идёт совместная работа - то личный Obsidian плохо впишется в рабочий процесс. А если личные, то лично мне не нравится сливать такую инфу о себе сторонней компании - вот когда локально запущенные на видухе модели потянут такую работу, тогда и скажем этому методу "да".
Лично я доверяю Claude больше, чем многим людям вокруг.
И совершенно зря. Уровень Claude при работе с кодом очень высок - по сравнению с остальными AI. Но относительно людей - это уровень крепкого миддла. Есть очень много людей с гораздо более высоким уровнем. А если такие люди ещё и помощью Claude воспользуются, то результат будет в разы лучше, чем то, что Claude способен сделать самостоятельно.
Серьёзно. Пока речь о 3-х PR-ах в месяц абсолютно без разницы сколько стоит сделать ревью. У меня ревью (обучающие) и по 2 часа на PR занимали, но можно в среднем взять упомянутые в статье пол часа. Это 16 PR-ов в день максимум, реально скорее 10. 10 PR-ов в день вполне в состоянии производить компания очень скромного размера. И вот уже мы имеем полноценный фултайм для такого сотрудника.
$20 за 20 мин. это $60/час. Никому не нужен ИИ работающий по цене топового спеца но при этом ни за что не отвечающий и выдающий результат на уровне крепкого миддла в лучшем случае.
Ну, так было раньше. Сейчас настраиваются предпочтения проекта в 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 как большинство одноклассников. Было очень интересно делать разные системные штуки, которые на языках высокого уровня сделать было либо невозможно либо они делались крайне странно/неэффективно.) Увы, но я деградировал, и сегодня еле-еле способен асм читать, скорее догадываясь чем понимая современные диалекты. Писать точно не в состоянии.
Ещё вчера почти все писали на языках высокого уровня. А теперь они снова норовят деградировать, сволочи (и я тоже)! Никогда такого не было, и вот, опять! © (Ещё пару лет назад я писал тесты и учил других их писать так, чтобы это было не больно и полезно. А сегодня я тесты максимум проглядываю мельком, понимая их очень в общих чертах - примерно как ассемблер. Потому что их пишет ИИ, и от меня на ревью требуется убедиться, что тесты в принципе есть, и вроде бы тестируют реальный код на то, что нужно проверять - и всё. Вникать в реализацию тестов детальнее сегодня смысла вообще ноль.)
Так что да, скорость деградации поражает. Но, нет, это не проблема - потому что деградируют только ненужные навыки. Поэтому мы вполне можем называть этот процесс не деградацией, а развитием!
Круто, но есть нюанс. Если проекты и задачи не личные, идёт совместная работа - то личный Obsidian плохо впишется в рабочий процесс. А если личные, то лично мне не нравится сливать такую инфу о себе сторонней компании - вот когда локально запущенные на видухе модели потянут такую работу, тогда и скажем этому методу "да".
И совершенно зря. Уровень Claude при работе с кодом очень высок - по сравнению с остальными AI. Но относительно людей - это уровень крепкого миддла. Есть очень много людей с гораздо более высоким уровнем. А если такие люди ещё и помощью Claude воспользуются, то результат будет в разы лучше, чем то, что Claude способен сделать самостоятельно.
Серьёзно. Пока речь о 3-х PR-ах в месяц абсолютно без разницы сколько стоит сделать ревью. У меня ревью (обучающие) и по 2 часа на PR занимали, но можно в среднем взять упомянутые в статье пол часа. Это 16 PR-ов в день максимум, реально скорее 10. 10 PR-ов в день вполне в состоянии производить компания очень скромного размера. И вот уже мы имеем полноценный фултайм для такого сотрудника.
Да просто голосовалку в пост добавить, и станет прозрачнее.
Мечта о халяве неистребима.
Это валидно, потому что за эти деньги можно оного спеца нанять ревьювить те же PR на почасовке.
$20 за 20 мин. это $60/час. Никому не нужен ИИ работающий по цене топового спеца но при этом ни за что не отвечающий и выдающий результат на уровне крепкого миддла в лучшем случае.