Comments 28
Удовлетворения такая работа все равно не приносит. Программист из творца стал прокладкой между клиентом и ИИшкой. Тем, кто привык работать головой и получает от этого удовольствие, все равно рано или поздно придется искать новое занятие. Вот только какое ?
У меня за 25 лет карьеры (немного в рф, в основном канада), творить на работе приходилось не часто. Ну так, чтоб думать над архитектурой, обсуждать решения. Это в начале проекта, когда с нуля вырастает продукт. В основном же - поддержка, доработка, исправление. Ремесленник, не творец. Как отдушина - проекты для себя, конкурсные задачки, учёба. Хобби, не работа.
Да, соглашусь, через какое-то время, умение читать и понимать код может стать ненужным. Но мой прогноз на это пока сдвигается с краткосрочной (до 3 лет) перспективы на среднесрочную (5+). Вопрос куда смотреть дальше, пока открыт...
Смотря что именно приносит удовольствие.
Если писать код в радость - то да, ИИ отберет эту часть. Если нравилось решать проблемы - то ИИ скорее в помощь. Если же по проработке архитектуры фанател - то ИИ вообще незаменим (как исполнитель экспериментов).
Еще одна статья от человека не в теме.
Кто в теме в курсе, что качества достаточно даже не самых передовых и больших моделей. Всё упирается в харнес, то есть обвязку. Нет сейчас харнеса коробочного. Если много сидеть в вайбкодинге или аналитике видно, что постановка и выделение скиллов и mcp закрывают качество
Как гитлаб закрыл коробочно ci/CD вместо самописных скриптов, так и здесь
Да нас таких, кто не в теме, целая индустрия.
Теоретически да, грамотная обвязка решает проблемы. Вот только обвязать не то, что несколько команд на сложном проекте, несколько людей - уже сложно. Хоть весь день "сиди в вайбкодинге и аналитике". Что-то где-то получается, и то - с компромиссами. Убираешь человека с Code Review - очень быстро словишь ситуацию, что агент не так понял и не то сделал. Про мусор в коде я уже молчу, любые скилы и инструкции спасают лишь отчасти. Если же все расписывать в обвязке, она становится обузой, забивает контекст, начинаются конфликты. Вот и остаётся или жертвовать качеством кода и продукта или (пока) смериться с необходимостью контроля человеком. И отчёт показывает, что компании, очевидно, выбирают второе...
Вот обычно пишут про ускорение разработки. То есть человеко-часов на разработку некой фичи уходит меньше. А если соотнести с дополнительными финансовыми тратами (эти самые токены), интересно, на сколько дешевле/дороже стала разработка той же самой фичи?
Судя по убыткам всех участников забега, кроме производителя лопат. Результат видимо, мягко говоря так себе. И постоянные рассказы про мифические метрики типа "эффективности", толсто на это намекают.
более того, когда рассказываю про рост эффективности в 4 10 20 раз, то это всегда вызывает вопросы целесообразности. ведь деньги на ии тратятся, но рост эффективности не гарантирует кратный рост продаж и прибыли. иногда всё утыкается в банальные пределы самого рынка. ты можешь повысить производительность, стать в 4 раза быстрее и банально уткнутся в то, что твоя скорость никому не нужна. рынок не готов потреблять твой подукт с такой скоростью и не готов к столь частым изменения софта на стороне пользователя.
Изначально была куча разговоров про "мы уволим всех человеков" и на разнице между зарплатами и ценой токенов будем жить. В процессе дней выяснилось, что уволить всех человеков не получилось, токены совсем не дешёвые и очевидно будут дорожать. И ещё несколько нюансов. То есть "светлое будущее" опять благополучно не наступило.
Ну всех и не надо, но большинство вполне. А токены сильно дороже вряд ли будут, может и дешевле и это при том, что для тех же задач их нужно будет меньше и меньше.
Ни одна модель не снизила свою тарификацию (на постоянной основе). Новые модели стоят дороже, единственно, где можно выиграть по деньгам - переключение на новые модели с понижением "класса". (типа с Опус на Сонет).
Токенов же нужно всё больше, контекст из за обвязок только растёт. Плюс субагнеты, плюс внутренние "мысли".
И как показывает практика, пока сократить сложно не то, что позицию, а даже достаточно много рабочих часов. Пока нет адекватных решений для замены людей.
Модели классом ниже тоже лучше будут, важно, чтобы модели было достаточно для решения задач. А из-за общего развития моделей, количество токенов для тех же задач нужно будет меньше, это будет компенсироваться немного обвзякой, но позволит избежать сильного роста, а со временем может и уменьшится несколько. Модели будут лучше, дата-центров больше, а количество задач рынка не вырастет так де сильно. Поэтому будут сокращать людей. Вон говорили, что и Джуны нужны будут всегда, но их уже почти нет, как и вакансий соответсвенно, а это всё случилось буквально за 3-4 года. Сокращения займут больше времени, конечно, но 5-10 лет и 70-80% будут вынуждена перепрофилироваться в курьеры, да дворники.
Да, это популярная точка зрения озвучивается уже достаточно долго. Но посмотрите отчёты. (можно оба за первый и второй квартал). Экономия времени у разработчиков (что в должно было стать поводом к сокращениям) - пока мизирная.
И это при том, что текущее поколение нейронок код пишет очень хороший. Критического улучшения в этом плане уже можно не ждать. Что бы сокращения пошли, нужно, чтоб агенты умели в надёжную автономность, и по стоимости дешевле разработчика.
Джунские вакансии не исчезли, но трансформировались ближе к мид-уровню. Это показывает отчёт первого квартала - там есть метрика, что у джунов существенно возросла производительность. И в общем, сократилась дистанция между "уровнями" инженеров.
Опять же, упала планка З/П. Будет естественный отток, так как молодёжь сомневается в перспективах.
И в результате программирование разделится на несколько направлений. Одно где нужно на "отвали". Где качество никому не интересно, да и собственно результат никому не нужен. Будет вайб-кодинг. А где нужно чтобы действительно работало, будут люди. Ну и очевидно разные сочетания этих двух. Так что на мой взгляд профессия программиста никуда не денется, а вот качество программистов (как бы это не казалось странным) вырастет. И всё это что происходит в программировании в контексте ИИ мне лично показывает, что дальше некоторых областей IT ИИ мало куда пойдёт. Пойдёт туда, где результат не очень важен и так сойдёт.
По моему опыту LLM оправдано:
Свистоперделки/демо/смотри, как я умею!
Дендрофекальная индустрия/пластиковые одноразовые инструменты низкого качества
Подняли и перенесли на новый стек без изменений
Гонять агентов по быстрой и чёткой петле обратной связи, набивая шишки об стенд
В остальных случаях грустно и сомнительно.
На новый стек не так просто перенести. Я однажды переносил проект на новую архитектуру с топовыми моделями курсора, потратил 2 мес, упоролся и потом ещё месяц выхватывал разные баги. Хотя по идее это как раз ллм задача
Помимо кодописания, ИИ агенты, как инструмент, очень полезен для понимания кода. В отчёте указано несколько метрик, связанных с этим - "10ый PR", например - как быстро новый член команды вливается в разработку, ускорился в 2 раза.
Документирование опять же. Не создание многостраничных документов, а "интерактивная документация", когда я оперативно могу получить актуальную информацию (со схемами и графиками, если надо) по произвольному вопросу.
И это, и то, что Вы сказали, укладывается в текущую реальность "ИИ в разработке - хороший индивидуальный инструмент, но не более того"
У нас в компании все очень похоже. Сказали отныне будет спек-дривен девелопмент. Пригнали контрактников с большим опытом (ну то есть они этим занимаются очень долго, больше года). Контрактники нам паписали скилы вокруг spec-kit, внедрили CodeRabbit, показали каким быть новый процесс, и учат как правильно запускать агентов параллельно в полностью автоматическом режиме, чтобы ты ему эпик из джиры даешь, а утром у тебя все сделано.
Простые тикеты, типа поменять текст на лейбле, агенты щелкают на ура. Ну как щелкают... Генерируют спеки, планы, таски, тесты, код, playwright-тесты, запускают CodeRabbit (локально, затем на сервере, когда PR создан), затем самописный код-ревью скил, затем человек еще на всякий случай проверяет, затем в тикет дописывается простыня что и как сделано (для аудита), пяток тестовых сценариев для QA, и через полдня и энное количество токенов текст поменян, и тикет уходит в QA, где люди тоже уже подустали от общения в стиле wall-of-text, поэтому не читают а сразу скармливают все Клоду, чтобы тот все разьяснил, а лучше сразу сделал.
В прошлые времена это бы тоже заняло полдня, была бы заметка для QA где и что смотреть, и не было бы всего остального нагенерированного слопа.
Делается ли все теперь в 3-5 раз быстрее, как мечтает менеджмент? Смотря как мерять. Если по сгенерированному объему и покрытию бессмыссленными тестами то да.
С более сложными тикетами узкое место обычно ревью. Так как мы хотим надежный код, то мы на него натравливаем максимальное количество ревью-агентов, которые часто не согласны с кодом, друг с другом, и даже если просто перезапустить, то могут дать разные результаты. Обычно это признак того, что требования слишком размыты. Но узнаем мы об этом поздно, приходится править PR. Но править теперь требуется не только код, но и все связанные нагенерированные артефакты: спеки, план, таски, тесты, сам тикет. Клод при этом всегда что-то пропускает, несоответствия спекам всплывют на ревью снова, и получаем цикл. Можно в принципе оставить агентов гонять этот цикл на ночь, но результат как правило плохой и дорогой в смысле сожженных токенов.
Один из подходов, который тестируем, и пока вроде успешно, это показать агенту "идеальный код" : какое-то простое приложение, где ИИ может почерпнуть все недостающие требования: как генерировать фронтенд (фреймворки, библиотеки, элементы, поведение, и т.д.), как выглядит типичный бэкенд (фреймворки, библиотеки, хранилище, транзакционность, пагинация, параметры ендпоинтов, и т.п.). Но правда писать его приходится ручками...
В общем мы пробуем, работа идет, но ускорится в разы пока не получается...
затем в тикет дописывается простыня что и как сделано
Мы стараемся разделить diff на несколько коммитов и описание по каждому отдельно. Задача разбивается на
Предварительное построение тестов/гардов чтобы не сломать старое
Смысловое ядро изменений с коротким и прозрачным diff. Он должен читаться за 5 минут. Исполнитель презентует его на дейлике.
Догоны по частным случаям, не предусмотренные в изначальной задаче и описание / патч к изначальным требованиям. Они не должны сломать основную часть. Если их много то это видно и возможно проще вернуть на уточнение требований чем ревьювить это.
Пригнали контрактников с большим опытом (ну то есть они этим занимаются очень долго, больше года).
Контрактники нам паписали скилы вокруг spec-kit, внедрили CodeRabbit, показали каким быть новый процесс, и учат как правильно запускать агентов параллельно в полностью автоматическом режиме, чтобы ты ему эпик из джиры даешь, а утром у тебя все сделано.
Мне вот что интересно, а эти контрактники, у них работа "научить, как надо"? Они и сами-то пишут и поддерживают проекты? Или там всё по закону Мерфи "Кто умеет - делает, кто не умеет - учит"?
Забавно что пришли ИИ умельцы все настроили и сделали , а агенты все равно делают ошибки и процесс не создался удобный.
Один из подходов, который тестируем, и пока вроде успешно, это показать агенту "идеальный код" : какое-то простое приложение,
Извините , а "идеальный код" он откуда берётся?
Я бы сказал, что скорее мы ПОКА ЧТО ситуация напоминает: поставили ДВС на телегу и увидели, что телега быстрее 20км/ч не едет.
А проектирование нормальных ЯП и flow разработки (и разработчиков умеющих ими пользоваться) - ещё впереди.
Я лично вижу несколько затыков (и даже несколько сценариев затыков) в ИИ-разработке. И даже несмотря на то, что "в принципе" эти затыки понимаю - не до конца могу с ними справится. Грубо если объяснять ВСЁ - будет не быстрее чем кодить. А если объяснять не всё - периодически приходится "gvim TASK.md, new task" (у нас правда аппаратная разработка - программная часть симуляторы \ драйвера \ библиотеки) - т.к. примерно половину из 100 нюансов он уловил, а остальные не понял и это конкретно сейчас оказалось критичным.
Влияние ИИ на создание ПО. Всё, вышли на плато?