Если вы посмотрите на индустрию без розовых очков, то вместо деградации увидите жёсткую эволюцию. Классические сеньоры-программисты никуда не денутся. Взять тот же бигтех вроде Яндекса или Сбера — здесь всегда будет спрос на глубокую низкоуровневую разработку.
Высокооплачиваемый инженер всё так же неделями будет пилить архитектуру фронтенда под одну конкретную страницу, оптимизируя каждый рендер.
Это вы сейчас про Яндекс, который свой пилотный Дзен зарелизил вообще без десктопной вёрстки (там реально теги на белом фоне были, школьник бы лучше сверстал)?
Или про Сбер (ну ок, у них вроде всё норм, хотя сокращают пачками) про Тиньков, у которых система позволяла покупать доллары дешевле курса и потом продавать? И потом они это пытались "вернуть взад", забирая деньги со счетов?
Пришла пора перестать наслаждаться иллюзиями. Высокоуровневая разработка - это всегда просто лысая обезьяна, которая составляет цепочку из криво-подписанных-маркером чёрных ящиков, обкладывает их тестами и надеется, что всё отработает как задумано. Потому что в каждом из этих ящиков больше кода, чем мозг может удержать в контексте (9-10 сущностей у здоровых). И в этом случае уже абсолютно без разницы, писал эти черные ящики человек или ИИ, и какой у этой обезьяны IQ и всё остальное. Разработчик - это просто конкретный сотрудник, который готов взять ответственность за часть кода и подорваться с места, чтобы его поправить. Как сантехник при засорении унитаза.
Если бы вам в школе сразу калькулятор дали - вы бы никогда не освоили устный счёт
И потом даже в магазине не смогли бы прикинуть общую стоимость товаров в корзине
Ну вот вам пример. Я вчера вечером развлекался тем, что прикидывал кол-во секунд в году. Без калькулятора, без всего. Школа 90-х, тогда не то что GPT-шки, а даже интернета не было и калькулятор с собой носил едва ли каждый 10й.
А вот сегодня пошёл в магаз - и цену корзины прикинуть нормально не смог. Ошибся порядка 20-30 %. На менее чем 10 товарах.
Можете сколько угодно потчевать своё эго фантазиями о своём превосходстве и о том, какие адские кары ожидают тех, кто не такой как вы (религия очень часто использует подсознательное стремление человека к таким фантазиям). Просто не забывайте, что в таких мыслях больше эмоций, чем реальности.
Возможно, в каких-то системах это идентично, но для меня "planning mode" это про план, который я обсуждаю с LLM и рассчитанный на дальнейшее выполнение этой LLM, а "делаем план для..." - это когда потом его ещё людям можно будет показать (т.е. без лишних подробностей реализации и повторения очевидных вещей).
Режим планирования использую, но редко. Это аналогично "думательному" режиму LLM (thinking mode/deep think/ и как его только не называли, чтобы не совпасть в формулировке и чтоб не засудили за это) - генерация более развёрнутого промпта перед решением задачи.
Применимость объясняется просто - дать LLM изучить проект (файлы, БД, консоль), без внесения каких-либо изменений. Как жесткое требование - "смотри, но не трогай".
По какой причине? По причине того, что у задачи иногда есть очевидное решение за пределами кода. Но ИИ-шка его не может порекомендовать, её учили писать код, вот она его и будет всегда писать, излишне переусложняя структуру, добавляя костылей и неоднозначной логики.
Простой пример - вот есть некий интернет-магазин. У него есть товары, которые время от времени обновляются из 1С. Иногда по этим товарам заканчиваются остатки на складах. Что с такими товарами делать? Показывать 404? Ставить редирект на актуальные товары? Или на раздел? Просто показывать страницу с возможностью "оставить заявку, на случай, если вдруг товар вернётся"?
А ответ - внезапно - зависит от того, какие вообще это товары и от бизнес-логики магазина. Иногда заранее известно, что товар уже точно не вернётся. Иногда, наоборот, карточка товара есть - значит скоро будет. А иногда это только менеджер может определить.
Если слепо отдать решать эту задачу LLM, то она набурагозит десятиуровневую настройку в админке на все случаи жизни, увидев которую, менеджер задумается о том, чтобы пойти (обратно) в таксисты. А иногда код даже трогать не надо - просто сказать менеджерам "А вот те товары, которые точно больше не надо - давайте их не обнулять в 1С, а тупо удалять, а фолбек на такой случай уже есть".
Но такое можно увидеть только в режиме планирования, с правильным промптом.
Или, например, вариант, сделать раздельную логику для разных типов товаров. Предложение - есть о чём задуматься, но опять же, только в режиме планирования. В обычном режиме LLM-ка brrrr генерит вам новый код под ваш запрос, нет времени думать.
Для меня вот, например, до сих пор чудо, что если насыпать большую кучу полу-случайных текстов из интернета (с кучей ошибок и мусора, принципиально неустранимых) и статистически по ним пройтись, то итоговый результат сможет написать вообще хоть какую-то рабочую программу. Не взять с SO готовый шаблон FizzBuzz и заменить там 5 на 7, а прям написать, с нуля, по ТЗ. Математически доказуемо рабочую, даже если простую.
А ставить такой системе задачи "напиши развесистый рабочий продукт за 48 часов" это сродни тому, как если бы в гугле вводить запрос "какая вывеска была на заднем плане в таком-то малоизвестном фильме в определённый момент" и ожидать получить ответ. Тут единственный способ показать человеку, что так не бывает - дать попробовать самому.
Просто задумайтесь, кому нужно это ускорение – вам или вашему работодателю?
Просто задумайтесь, что происходит с трудоустройством сотрудника, когда работодатель не получает то, что ему нужно.
А так-то да, можно и в курьеры пойти, и там гордо заявить, что не собираетесь ни при каких условиях пользоваться любым транспортом, потому что хотите больше физкультурничать. Эффект будет примерно такой же.
Именно, добавьте к этому, что даже в типовых задачах есть сотни редких, но встречающихся нюансов, которые запросто могут "работу в 1 час" превратить в "головную боль на весь день" и получается, что когда разработчика просят оценить работу наперёд, ему нужно закладывать бюджет по-максимуму, чтобы точно уложиться. А значит, умножать его в N раз. Что, соответственно, в N раз увеличивает размер глаз заказчика, который будет этот бюджет читать.
Ещё компании среднего размера в том же вебе обычно платят от 200
Не платят, по опыту могу сказать.
Также некоторые мапят баксовые работы на рубли, тут платят в среднем намного больше в большинстве юрисдикций во всех типах компаний и просто тонна стартапов которым СНГ разработчики только и вмещаются в раунд - где условно лимит на разраба 120-150к на год, из-за чего в том же США тир 1 спецов не могут нанять
Если вы пропустили последние 4 года, с этим в РФ сейчас есть некоторые проблемы.
Всякие здоровенные аутсорсинги для джунов и мидлов типа epam вообще вряд ли нанимают меньше чем на 3к+
Погуглил - epam с начала известно чего не работает с Россией прям вообще.
Я бы сказал в статистике по большей части нижняя часть пирамиды РФ рынка участвует
Если бы это было так, то работающих людей в вебе с ЗП в районе 100к сейчас бы не могло существовать - их бы тупо уже через месяц спылесосили, потому что работающий специалист в 10 раз надёжнее безработного соискателя (возможно, уволенного или выгоревшего).
Это просто особенность русского менталитета - у нас быть "выше среднего" = буржуйство. Поэтому каждый, увидев среднюю ЗП меньше своей текущей, будет доказывать, что, мол это неправда и перекошенная выборка, средняя ЗП - это как у меня или даже вот чуть больше, чисто по ощущениям.
Цените, если у вас ЗП выше, не так много ещё таких мест осталось.
Это как с ситуацией, когда Зам. Директора по закупкам получает больше, чем Директор. Потому что "директор", он может быть чего угодно директор, хоть чебуречной. А "зам" бывает только в уже средне-крупных компаниях, а там и у топ-менеджмента ЗП соответствующие.
Так и тут. В мелких компаниях не может быть отдельно фронтэндеров и бэкендеров - просто не хватает пула задач, чтобы держать их постоянно занятыми. А в больших компаниях нет смысла держать много фулстеков, если задач по одному из направлений много.
И когда вы будете нанимать разработчиков на доработку вашего продукта поверьте, ценник вас неприятно удивит.
Вы не учитываете важный ньюанс - эти самые разработчики в современности будут переделывать проект не "по старинке", а с использованием ИИ-агентов, что заметно сокращает время и ценник.
А вот вайбкодинг очень-преочень хочет казаться мега архитектором и синьором, которому и социальную сеть написать под силу, поэтому спустя n недель вайбкодинга, ваш проект станет утыкан такими конструкциями, от которых у разработчиков глаза не то, что на лоб полезут, я боюсь они просто вылезут.
У меня есть опыт работы с плохой архитектурой, переделкой, и как раз это - одна из задач, с которой ИИ справляется лучше всего (меньше всего ошибается). Это не "додумай систему по огрызку кода и пофикси баг, который физически не можешь воспроизвести", это не "напиши тысячу идеально верных строк кода на одну строку промпта". Тут вся нужная информация есть в контексте.
Да, старые инстинкты заставляют вздрагивать, когда видишь, например, SQL-запрос такого размера, что он не умещается на экране, или функцию-бога на тысячу строк. Да что там, даже
уже заставляет волосы шевелиться везде, при том что это всего лишь безобидная валидация email-адреса по RFC 5322.
"Ух, ё... Это ж сколько времени и головной боли займёт всё это переделывать по-нормальному?"
А потом ты просто пишешь промпт с точным описанием того, как это должно быть (потому что знаешь, как оно должно быть), и уходишь на обед, а возвращаешься уже к свежему коду, где всё уже в целом переделано и читаемо. Потестировал, доработал напильником и готово.
Такие задачи можно сравнить с переделкой всего кода большого проекта под полное соответствие какому-то строгому стандарту. На первый взгляд, без опыта, кажется - титанический труд, "да я выгорю быстрее, чем это всё доделаю". На деле - со знанием линтеров, инструментов и опытом - недолгая и ненапряжная задача.
Вот и с ИИ сейчас многие проблемы, которые раньше считались фатальными, переосмысляются и становятся менее пугающими.
Один из прошлых руководителей рассказывал. Около-гос-контора.
Давно работал, захотел стол себе хороший поставить. "Бюджета на такое нет, но за свои - ставь". Ну что делать, купил, поставил.
Через несколько лет - инвентаризация. Клеют бирку на его стол, а он говорит "нет, это мой", а ему в ответ "вся мебель должна быть инвентаризирована, таковы правила, мы просто пометку поставим в списке, что это ваш".
Ещё через несколько лет он решил проверить - нет, говорят, стол сейчас числится как собственность конторы, ничего не знаем.
И тогда даже никакой камеры не нужно будет, достаточно будет на микрофон записать как очередная бабушка причитает "Ой, как тижало теперь всё стало... Тааак... Ноооль... Четыыре... Пяяять... Один!"
Не пробовал Opencode, но звучит так, что вы кодите "в режиме чата", вручную скармливая LLM крохи контекста. Особенно с учетом фразы "Но чаще всего не работающего, особенно с первого раза".
Так даже топовые модели ерунду пишут (и настаивают на своей правоте) и так никто сейчас не делает. Попробуйте Cursor или любую другую современную AI IDE. Он сам находит нужный контекст, анализирует, где на проекте уже что-то подобное делалось и почему именно так. Он грепает по файлам со скоростью света - вы ещё не успеете прочитать, что он ищет, а он уже нашёл, прочитал, сделал выводы и пошёл искать следующее.
Озвученных проблем уже несколько лет не встречал, пока не решил однажды на пробу в режиме чата с одной из свежих Sonnet написать простенький скрипт по текстовому описанию. Написало криво, с ошибками в коде и логике, как какой-нибудь ГигаЧат, ей богу, разница очень значительная.
А тут уже вероятности. Сначала попробуют школьника, потому что 200р не жалко, а сервер потом всегда откатить можно.
И если раньше, с StackOverflow или с ChatGpt 3.5 школьник бы и забуксовал, то сейчас с Cursor всё чаще и чаще проблема просто берёт и решается. И достаточно одного удачного раза, чтобы бизнес округлил глаза от экономии и принял долгоиграющее решение о том, с кем он в дальнейшем будет работать.
Так и фраза "Курсор, пожалуйста, сделай чтобы работало" точно также передаёт задание внешней подсистеме. И если поставить температуру ЛЛМки в 0, то можно даже получить один и тот же детерминированный результат.
Только вы заранее не знаете, какой именно это будет результат, поэтому его детерминированность не имеет значения. Так же, как вы заранее не знаете, как именно отработает mail().
Как раз таки компетентность нужна, чтобы понимать, что бизнесу не важна детерминированность компиляции. А важно им, например, чтобы письма с формы обратной связи уходили на ящик отдела продаж. Или чтобы весь сайт не падал с ошибкой.
И вот спросили они школьника с ИИ-шкой, сколько это займёт. Школьник ответил "по простому - 15 минут, а если не получится, то хз, ковырять надо. Но рано или поздно доковыряю."
А потом спросили синьора-помидора старой закалки... и получили тот же самый ответ.
Только школьник стоит 200 р в час, а синьор - 2000. А вот это для бизнеса уже измеримая разница.
Бухгалтер может был бы и рад, чтобы новую версию 1С-Бухгалтерии переписали на чистом ассемблере, там где хитрыми фокусами с памятью и математикой можно добиться того, чтобы оно летало на любом железе и весило меньше, чем главная страница Хабра. Объективно лучше любого другого языка программирования. Но есть ньюанс, почему этого никто не делает.
Он упадёт с ошибкой? Вернёт true или false? Письмо дойдёт до получателя? Каждый раз одинаково отработает или есть вероятности?
Детерминированность у кода была бы, если бы результат запуска всегда соответствовал тому, что программист у себя "скомпилировал в уме", но за пределами примитивных задачек с литкода, в реальных production системах человеческая голова как-то не особо с этим справляется, поэтому и результат выполнения программы никогда не будет полностью предсказуемым.
Это вы сейчас про Яндекс, который свой пилотный Дзен зарелизил вообще без десктопной вёрстки (там реально теги на белом фоне были, школьник бы лучше сверстал)?
Или про
Сбер(ну ок, у них вроде всё норм, хотя сокращают пачками) про Тиньков, у которых система позволяла покупать доллары дешевле курса и потом продавать? И потом они это пытались "вернуть взад", забирая деньги со счетов?Пришла пора перестать наслаждаться иллюзиями. Высокоуровневая разработка - это всегда просто лысая обезьяна, которая составляет цепочку из криво-подписанных-маркером чёрных ящиков, обкладывает их тестами и надеется, что всё отработает как задумано. Потому что в каждом из этих ящиков больше кода, чем мозг может удержать в контексте (9-10 сущностей у здоровых). И в этом случае уже абсолютно без разницы, писал эти черные ящики человек или ИИ, и какой у этой обезьяны IQ и всё остальное. Разработчик - это просто конкретный сотрудник, который готов взять ответственность за часть кода и подорваться с места, чтобы его поправить. Как сантехник при засорении унитаза.
Ну вот вам пример. Я вчера вечером развлекался тем, что прикидывал кол-во секунд в году. Без калькулятора, без всего. Школа 90-х, тогда не то что GPT-шки, а даже интернета не было и калькулятор с собой носил едва ли каждый 10й.
А вот сегодня пошёл в магаз - и цену корзины прикинуть нормально не смог. Ошибся порядка 20-30 %. На менее чем 10 товарах.
Можете сколько угодно потчевать своё эго фантазиями о своём превосходстве и о том, какие адские кары ожидают тех, кто не такой как вы (религия очень часто использует подсознательное стремление человека к таким фантазиям). Просто не забывайте, что в таких мыслях больше эмоций, чем реальности.
Возможно, в каких-то системах это идентично, но для меня "planning mode" это про план, который я обсуждаю с LLM и рассчитанный на дальнейшее выполнение этой LLM, а "делаем план для..." - это когда потом его ещё людям можно будет показать (т.е. без лишних подробностей реализации и повторения очевидных вещей).
Режим планирования использую, но редко. Это аналогично "думательному" режиму LLM (thinking mode/deep think/ и как его только не называли, чтобы не совпасть в формулировке и чтоб не засудили за это) - генерация более развёрнутого промпта перед решением задачи.
Применимость объясняется просто - дать LLM изучить проект (файлы, БД, консоль), без внесения каких-либо изменений. Как жесткое требование - "смотри, но не трогай".
По какой причине? По причине того, что у задачи иногда есть очевидное решение за пределами кода. Но ИИ-шка его не может порекомендовать, её учили писать код, вот она его и будет всегда писать, излишне переусложняя структуру, добавляя костылей и неоднозначной логики.
Простой пример - вот есть некий интернет-магазин. У него есть товары, которые время от времени обновляются из 1С. Иногда по этим товарам заканчиваются остатки на складах. Что с такими товарами делать? Показывать 404? Ставить редирект на актуальные товары? Или на раздел? Просто показывать страницу с возможностью "оставить заявку, на случай, если вдруг товар вернётся"?
А ответ - внезапно - зависит от того, какие вообще это товары и от бизнес-логики магазина. Иногда заранее известно, что товар уже точно не вернётся. Иногда, наоборот, карточка товара есть - значит скоро будет. А иногда это только менеджер может определить.
Если слепо отдать решать эту задачу LLM, то она набурагозит десятиуровневую настройку в админке на все случаи жизни, увидев которую, менеджер задумается о том, чтобы пойти (обратно) в таксисты. А иногда код даже трогать не надо - просто сказать менеджерам "А вот те товары, которые точно больше не надо - давайте их не обнулять в 1С, а тупо удалять, а фолбек на такой случай уже есть".
Но такое можно увидеть только в режиме планирования, с правильным промптом.
Или, например, вариант, сделать раздельную логику для разных типов товаров. Предложение - есть о чём задуматься, но опять же, только в режиме планирования. В обычном режиме LLM-ка brrrr генерит вам новый код под ваш запрос, нет времени думать.
Тут просто разный уровень "чуда" ожидается.
Для меня вот, например, до сих пор чудо, что если насыпать большую кучу полу-случайных текстов из интернета (с кучей ошибок и мусора, принципиально неустранимых) и статистически по ним пройтись, то итоговый результат сможет написать вообще хоть какую-то рабочую программу. Не взять с SO готовый шаблон FizzBuzz и заменить там 5 на 7, а прям написать, с нуля, по ТЗ. Математически доказуемо рабочую, даже если простую.
А ставить такой системе задачи "напиши развесистый рабочий продукт за 48 часов" это сродни тому, как если бы в гугле вводить запрос "какая вывеска была на заднем плане в таком-то малоизвестном фильме в определённый момент" и ожидать получить ответ. Тут единственный способ показать человеку, что так не бывает - дать попробовать самому.
Просто задумайтесь, что происходит с трудоустройством сотрудника, когда работодатель не получает то, что ему нужно.
А так-то да, можно и в курьеры пойти, и там гордо заявить, что не собираетесь ни при каких условиях пользоваться любым транспортом, потому что хотите больше физкультурничать. Эффект будет примерно такой же.
Классика же, в корзине можно содержать несколько файлов с одинаковыми именами.
Именно, добавьте к этому, что даже в типовых задачах есть сотни редких, но встречающихся нюансов, которые запросто могут "работу в 1 час" превратить в "головную боль на весь день" и получается, что когда разработчика просят оценить работу наперёд, ему нужно закладывать бюджет по-максимуму, чтобы точно уложиться. А значит, умножать его в N раз. Что, соответственно, в N раз увеличивает размер глаз заказчика, который будет этот бюджет читать.
Не платят, по опыту могу сказать.
Если вы пропустили последние 4 года, с этим в РФ сейчас есть некоторые проблемы.
Погуглил - epam с начала известно чего не работает с Россией прям вообще.
Если бы это было так, то работающих людей в вебе с ЗП в районе 100к сейчас бы не могло существовать - их бы тупо уже через месяц спылесосили, потому что работающий специалист в 10 раз надёжнее безработного соискателя (возможно, уволенного или выгоревшего).
Это просто особенность русского менталитета - у нас быть "выше среднего" = буржуйство. Поэтому каждый, увидев среднюю ЗП меньше своей текущей, будет доказывать, что, мол это неправда и перекошенная выборка, средняя ЗП - это как у меня или даже вот чуть больше, чисто по ощущениям.
Цените, если у вас ЗП выше, не так много ещё таких мест осталось.
Как бы да, но не только.
Это как с ситуацией, когда Зам. Директора по закупкам получает больше, чем Директор. Потому что "директор", он может быть чего угодно директор, хоть чебуречной. А "зам" бывает только в уже средне-крупных компаниях, а там и у топ-менеджмента ЗП соответствующие.
Так и тут. В мелких компаниях не может быть отдельно фронтэндеров и бэкендеров - просто не хватает пула задач, чтобы держать их постоянно занятыми. А в больших компаниях нет смысла держать много фулстеков, если задач по одному из направлений много.
Иногда для оцифровки книги её быстрее/дешевле распилить на листки (т.е. по сути уничтожить).
Вы не учитываете важный ньюанс - эти самые разработчики в современности будут переделывать проект не "по старинке", а с использованием ИИ-агентов, что заметно сокращает время и ценник.
У меня есть опыт работы с плохой архитектурой, переделкой, и как раз это - одна из задач, с которой ИИ справляется лучше всего (меньше всего ошибается). Это не "додумай систему по огрызку кода и пофикси баг, который физически не можешь воспроизвести", это не "напиши тысячу идеально верных строк кода на одну строку промпта". Тут вся нужная информация есть в контексте.
Да, старые инстинкты заставляют вздрагивать, когда видишь, например, SQL-запрос такого размера, что он не умещается на экране, или функцию-бога на тысячу строк. Да что там, даже
Вот такой вот regex
(?:[a-z0-9!#$%&'*+\x2f=?^_
\x7b-\x7d~\x2d]+(?:\.[a-z0-9!#$%&'*+\x2f=?^_\x7b-\x7d~\x2d]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9\x2d]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9\x2d]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9\x2d]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])уже заставляет волосы шевелиться везде, при том что это всего лишь безобидная валидация email-адреса по RFC 5322.
"Ух, ё... Это ж сколько времени и головной боли займёт всё это переделывать по-нормальному?"
А потом ты просто пишешь промпт с точным описанием того, как это должно быть (потому что знаешь, как оно должно быть), и уходишь на обед, а возвращаешься уже к свежему коду, где всё уже в целом переделано и читаемо. Потестировал, доработал напильником и готово.
Такие задачи можно сравнить с переделкой всего кода большого проекта под полное соответствие какому-то строгому стандарту. На первый взгляд, без опыта, кажется - титанический труд, "да я выгорю быстрее, чем это всё доделаю". На деле - со знанием линтеров, инструментов и опытом - недолгая и ненапряжная задача.
Вот и с ИИ сейчас многие проблемы, которые раньше считались фатальными, переосмысляются и становятся менее пугающими.
А бывает и наоборот.
Один из прошлых руководителей рассказывал. Около-гос-контора.
Давно работал, захотел стол себе хороший поставить. "Бюджета на такое нет, но за свои - ставь". Ну что делать, купил, поставил.
Через несколько лет - инвентаризация. Клеют бирку на его стол, а он говорит "нет, это мой", а ему в ответ "вся мебель должна быть инвентаризирована, таковы правила, мы просто пометку поставим в списке, что это ваш".
Ещё через несколько лет он решил проверить - нет, говорят, стол сейчас числится как собственность конторы, ничего не знаем.
И тогда даже никакой камеры не нужно будет, достаточно будет на микрофон записать как очередная бабушка причитает "Ой, как тижало теперь всё стало... Тааак... Ноооль... Четыыре... Пяяять... Один!"
Не пробовал Opencode, но звучит так, что вы кодите "в режиме чата", вручную скармливая LLM крохи контекста. Особенно с учетом фразы "Но чаще всего не работающего, особенно с первого раза".
Так даже топовые модели ерунду пишут (и настаивают на своей правоте) и так никто сейчас не делает. Попробуйте Cursor или любую другую современную AI IDE. Он сам находит нужный контекст, анализирует, где на проекте уже что-то подобное делалось и почему именно так. Он грепает по файлам со скоростью света - вы ещё не успеете прочитать, что он ищет, а он уже нашёл, прочитал, сделал выводы и пошёл искать следующее.
Озвученных проблем уже несколько лет не встречал, пока не решил однажды на пробу в режиме чата с одной из свежих Sonnet написать простенький скрипт по текстовому описанию. Написало криво, с ошибками в коде и логике, как какой-нибудь ГигаЧат, ей богу, разница очень значительная.
А тут уже вероятности. Сначала попробуют школьника, потому что 200р не жалко, а сервер потом всегда откатить можно.
И если раньше, с StackOverflow или с ChatGpt 3.5 школьник бы и забуксовал, то сейчас с Cursor всё чаще и чаще проблема просто берёт и решается. И достаточно одного удачного раза, чтобы бизнес округлил глаза от экономии и принял долгоиграющее решение о том, с кем он в дальнейшем будет работать.
Так и фраза "Курсор, пожалуйста, сделай чтобы работало" точно также передаёт задание внешней подсистеме. И если поставить температуру ЛЛМки в 0, то можно даже получить один и тот же детерминированный результат.
Только вы заранее не знаете, какой именно это будет результат, поэтому его детерминированность не имеет значения. Так же, как вы заранее не знаете, как именно отработает mail().
Как раз таки компетентность нужна, чтобы понимать, что бизнесу не важна детерминированность компиляции. А важно им, например, чтобы письма с формы обратной связи уходили на ящик отдела продаж. Или чтобы весь сайт не падал с ошибкой.
И вот спросили они школьника с ИИ-шкой, сколько это займёт. Школьник ответил "по простому - 15 минут, а если не получится, то хз, ковырять надо. Но рано или поздно доковыряю."
А потом спросили синьора-помидора старой закалки... и получили тот же самый ответ.
Только школьник стоит 200 р в час, а синьор - 2000. А вот это для бизнеса уже измеримая разница.
А зачем бухгалтеру писать программы?
Бухгалтер может был бы и рад, чтобы новую версию 1С-Бухгалтерии переписали на чистом ассемблере, там где хитрыми фокусами с памятью и математикой можно добиться того, чтобы оно летало на любом железе и весило меньше, чем главная страница Хабра. Объективно лучше любого другого языка программирования. Но есть ньюанс, почему этого никто не делает.
Так а он ещё раньше начинается. Что произойдёт при запуске PHP кода
mail("someone@example.com","My subject","Hello, world");Он упадёт с ошибкой? Вернёт true или false? Письмо дойдёт до получателя? Каждый раз одинаково отработает или есть вероятности?
Детерминированность у кода была бы, если бы результат запуска всегда соответствовал тому, что программист у себя "скомпилировал в уме", но за пределами примитивных задачек с литкода, в реальных production системах человеческая голова как-то не особо с этим справляется, поэтому и результат выполнения программы никогда не будет полностью предсказуемым.