"историю пишут победители" - лаконичное и простое объяснение всех нестыковок. И, как ни странно, не разрушает оригинальную фентази, а, наоборот, делает ее более реалистичной.
Да, это популярная точка зрения озвучивается уже достаточно долго. Но посмотрите отчёты. (можно оба за первый и второй квартал). Экономия времени у разработчиков (что в должно было стать поводом к сокращениям) - пока мизирная.
И это при том, что текущее поколение нейронок код пишет очень хороший. Критического улучшения в этом плане уже можно не ждать. Что бы сокращения пошли, нужно, чтоб агенты умели в надёжную автономность, и по стоимости дешевле разработчика.
Джунские вакансии не исчезли, но трансформировались ближе к мид-уровню. Это показывает отчёт первого квартала - там есть метрика, что у джунов существенно возросла производительность. И в общем, сократилась дистанция между "уровнями" инженеров.
Опять же, упала планка З/П. Будет естественный отток, так как молодёжь сомневается в перспективах.
Ни одна модель не снизила свою тарификацию (на постоянной основе). Новые модели стоят дороже, единственно, где можно выиграть по деньгам - переключение на новые модели с понижением "класса". (типа с Опус на Сонет). Токенов же нужно всё больше, контекст из за обвязок только растёт. Плюс субагнеты, плюс внутренние "мысли". И как показывает практика, пока сократить сложно не то, что позицию, а даже достаточно много рабочих часов. Пока нет адекватных решений для замены людей.
Пригнали контрактников с большим опытом (ну то есть они этим занимаются очень долго, больше года).
Контрактники нам паписали скилы вокруг spec-kit, внедрили CodeRabbit, показали каким быть новый процесс, и учат как правильно запускать агентов параллельно в полностью автоматическом режиме, чтобы ты ему эпик из джиры даешь, а утром у тебя все сделано.
Мне вот что интересно, а эти контрактники, у них работа "научить, как надо"? Они и сами-то пишут и поддерживают проекты? Или там всё по закону Мерфи "Кто умеет - делает, кто не умеет - учит"?
Помимо кодописания, ИИ агенты, как инструмент, очень полезен для понимания кода. В отчёте указано несколько метрик, связанных с этим - "10ый PR", например - как быстро новый член команды вливается в разработку, ускорился в 2 раза.
Документирование опять же. Не создание многостраничных документов, а "интерактивная документация", когда я оперативно могу получить актуальную информацию (со схемами и графиками, если надо) по произвольному вопросу.
И это, и то, что Вы сказали, укладывается в текущую реальность "ИИ в разработке - хороший индивидуальный инструмент, но не более того"
Теоретически да, грамотная обвязка решает проблемы. Вот только обвязать не то, что несколько команд на сложном проекте, несколько людей - уже сложно. Хоть весь день "сиди в вайбкодинге и аналитике". Что-то где-то получается, и то - с компромиссами. Убираешь человека с Code Review - очень быстро словишь ситуацию, что агент не так понял и не то сделал. Про мусор в коде я уже молчу, любые скилы и инструкции спасают лишь отчасти. Если же все расписывать в обвязке, она становится обузой, забивает контекст, начинаются конфликты. Вот и остаётся или жертвовать качеством кода и продукта или (пока) смериться с необходимостью контроля человеком. И отчёт показывает, что компании, очевидно, выбирают второе...
У меня за 25 лет карьеры (немного в рф, в основном канада), творить на работе приходилось не часто. Ну так, чтоб думать над архитектурой, обсуждать решения. Это в начале проекта, когда с нуля вырастает продукт. В основном же - поддержка, доработка, исправление. Ремесленник, не творец. Как отдушина - проекты для себя, конкурсные задачки, учёба. Хобби, не работа. Да, соглашусь, через какое-то время, умение читать и понимать код может стать ненужным. Но мой прогноз на это пока сдвигается с краткосрочной (до 3 лет) перспективы на среднесрочную (5+). Вопрос куда смотреть дальше, пока открыт...
Для самоочевидных вещей отлично пишется слоп, в котором тонешь при попытках найти нужное.
Документация, как многостраничный талмуд - это прошлое. Сейчас это интерактивный чат с ответами на вопросы, где не нужно самому искать нужное, где на ходу строятся диаграммы процессов и зависимостей, актуальные на текущий момент. Короче качество документации - таки выросло.
Это же - ведущий аспект, почему адаптация новых сотрудников стала быстрее и почему улучшилось сопровождение кода.
И, кстати, отчет который мы комментируем, это прекрасно отображает. Чтобы настроить агентскую разработку так, чтобы "она там ничего не натворила" и убрать человеческий code review, это капец трудоёмкая задача.
Ну так-то да, стажировка, для компании, это всегда типа накладные расходы. Но учить студентов - надо, и это социальная ответственность работодателей, так-то. Хотя не у всех есть возможность. За 20 лет в канаде я сменил 5 компаний, 3 из 5 стажеров не брали.
Кстати, отвлекают они не сильно, наоборот, интересно переключиться от рутины. У нас прямо очередь быть наставником )
С вакансиями, наверное, так же как везде. Для "программиста обычного" рынок охладился, вилки по з/п упали.
Если я не ошибаюсь, за то, что берём стажёров, компания получает налоговые льготы. И да, я трачу какое-то время на шефство, но студент всё равно делает полезную работу, и учитывая то, что за стаж они денег не получают, компания скорее в заметном плюсе, чем в минусе. Опять же, когда (если) студента берут на работу, уже нет доп. затрат на знакомство с компанией, её бизнесом и процессами.
И, не поймите меня неправильно, - компания чаще ищет сеньёров, чем джунов. Но рост и ротация внутри компании есть, так что и вчерашним студентам место найти можно.
Наша компания (Монреаль, канада) постоянно берёт студентов на практику (3 месяца). Разницы с "толковостью" между студентами "до ИИ" эпохи и сейчас - я не вижу. Реально хочется оставить, наверное, каждого третьего-четвертого, то есть процентов 30 выпускников - толковые ребята и перспективные джуны.
Использую NotebookLM (Gemini Notebook он стал буквально в июле этого года) для анализа всевозможных договоров и контрактов. Очень удобно для понимания юридического лексикона, написанного "мелким шрифтом".
А конкретно по статье - мы читаем иишные тексты, мы начинаем использовать ии-подобную речь в быту. Это как раз нормально и в этом ничего удивительного нет. Наоборот было бы странно - читать много раз в день одни и те же фразы и не использовать их.
Ой не не скажите... Некоторые "иишные фразочки" просто бесят. Когда Gemini, отвечая на вопрос этой зимой, первый раз сказала, что "это классика жанра", я улыбнулся. Но скоро эта оговорка про "классические" проблемы начала подбешивать. Кончилось тем, что поставил в профиле явный запрет на это, не говоря уже о том, что б употреблять такое самому...
Знать, какой текст сгенерирован иишкой - в общем-то полезно. Не понимаю, что некоторые авторы так возбудились на это? В идеале вообще было бы здорово, чтоб после каждого сгенерированного текста стояла подпись, которую при желании, можно было бы дешифровать в "<модель LLM>, <agent> [Skills used], <user prompt summary>"
Как я понимаю, BCS это не работа, это для работы. И вряд ли киприотским чиновникам нужен оригинал, а не заверенный сертифицированный перевод, про что я писал выше.
Но тут ключевое: вы же применяете историю к своему продукту
Применяя чужую историю к своему проекту, я добавляю риски false positive and false negative.
Но если чужая история таки выявит проблему в моём коде, это не значит, что применять эти чужие истории - есть практика улучшения моего продукта. Это значит, что мне нужно пересмотреть мои текущие настройки, обвязки и т.п.
Другими словами, искать зерно истины в куче чужих историй - это с моей т.з. потеря времени (и/или токенов).
Простите, но у вас "продукт" - частная "история", случившиеся в субъективном пространстве. Это нельзя экстраполировать как общий случай для всех систем, учитывая их многообразие (языки программирования, архитектуры, паттерны, используемые агенты и установленные обвязки). Например, то, что актуально для питона, может быть совсем неактуально для других яп.
Ваши воспроизводимые истории с большой степенью вероятности воспроизведутся в схожей с изначальной экосистемой. Но даже и тут нет стопроцентной гарантии. Может быть конфликт инструкций, разность в интерпретациях моделей и т.п.
"историю пишут победители" - лаконичное и простое объяснение всех нестыковок. И, как ни странно, не разрушает оригинальную фентази, а, наоборот, делает ее более реалистичной.
Да, это популярная точка зрения озвучивается уже достаточно долго. Но посмотрите отчёты. (можно оба за первый и второй квартал). Экономия времени у разработчиков (что в должно было стать поводом к сокращениям) - пока мизирная.
И это при том, что текущее поколение нейронок код пишет очень хороший. Критического улучшения в этом плане уже можно не ждать. Что бы сокращения пошли, нужно, чтоб агенты умели в надёжную автономность, и по стоимости дешевле разработчика.
Джунские вакансии не исчезли, но трансформировались ближе к мид-уровню. Это показывает отчёт первого квартала - там есть метрика, что у джунов существенно возросла производительность. И в общем, сократилась дистанция между "уровнями" инженеров.
Опять же, упала планка З/П. Будет естественный отток, так как молодёжь сомневается в перспективах.
Ни одна модель не снизила свою тарификацию (на постоянной основе). Новые модели стоят дороже, единственно, где можно выиграть по деньгам - переключение на новые модели с понижением "класса". (типа с Опус на Сонет).
Токенов же нужно всё больше, контекст из за обвязок только растёт. Плюс субагнеты, плюс внутренние "мысли".
И как показывает практика, пока сократить сложно не то, что позицию, а даже достаточно много рабочих часов. Пока нет адекватных решений для замены людей.
Мне вот что интересно, а эти контрактники, у них работа "научить, как надо"? Они и сами-то пишут и поддерживают проекты? Или там всё по закону Мерфи "Кто умеет - делает, кто не умеет - учит"?
Помимо кодописания, ИИ агенты, как инструмент, очень полезен для понимания кода. В отчёте указано несколько метрик, связанных с этим - "10ый PR", например - как быстро новый член команды вливается в разработку, ускорился в 2 раза.
Документирование опять же. Не создание многостраничных документов, а "интерактивная документация", когда я оперативно могу получить актуальную информацию (со схемами и графиками, если надо) по произвольному вопросу.
И это, и то, что Вы сказали, укладывается в текущую реальность "ИИ в разработке - хороший индивидуальный инструмент, но не более того"
Да нас таких, кто не в теме, целая индустрия.
Теоретически да, грамотная обвязка решает проблемы. Вот только обвязать не то, что несколько команд на сложном проекте, несколько людей - уже сложно. Хоть весь день "сиди в вайбкодинге и аналитике". Что-то где-то получается, и то - с компромиссами. Убираешь человека с Code Review - очень быстро словишь ситуацию, что агент не так понял и не то сделал. Про мусор в коде я уже молчу, любые скилы и инструкции спасают лишь отчасти. Если же все расписывать в обвязке, она становится обузой, забивает контекст, начинаются конфликты. Вот и остаётся или жертвовать качеством кода и продукта или (пока) смериться с необходимостью контроля человеком. И отчёт показывает, что компании, очевидно, выбирают второе...
У меня за 25 лет карьеры (немного в рф, в основном канада), творить на работе приходилось не часто. Ну так, чтоб думать над архитектурой, обсуждать решения. Это в начале проекта, когда с нуля вырастает продукт. В основном же - поддержка, доработка, исправление. Ремесленник, не творец. Как отдушина - проекты для себя, конкурсные задачки, учёба. Хобби, не работа.
Да, соглашусь, через какое-то время, умение читать и понимать код может стать ненужным. Но мой прогноз на это пока сдвигается с краткосрочной (до 3 лет) перспективы на среднесрочную (5+). Вопрос куда смотреть дальше, пока открыт...
Документация, как многостраничный талмуд - это прошлое. Сейчас это интерактивный чат с ответами на вопросы, где не нужно самому искать нужное, где на ходу строятся диаграммы процессов и зависимостей, актуальные на текущий момент. Короче качество документации - таки выросло.
Это же - ведущий аспект, почему адаптация новых сотрудников стала быстрее и почему улучшилось сопровождение кода.
И, кстати, отчет который мы комментируем, это прекрасно отображает. Чтобы настроить агентскую разработку так, чтобы "она там ничего не натворила" и убрать человеческий code review, это капец трудоёмкая задача.
Ну так-то да, стажировка, для компании, это всегда типа накладные расходы. Но учить студентов - надо, и это социальная ответственность работодателей, так-то. Хотя не у всех есть возможность. За 20 лет в канаде я сменил 5 компаний, 3 из 5 стажеров не брали.
Кстати, отвлекают они не сильно, наоборот, интересно переключиться от рутины. У нас прямо очередь быть наставником )
С вакансиями, наверное, так же как везде. Для "программиста обычного" рынок охладился, вилки по з/п упали.
Если я не ошибаюсь, за то, что берём стажёров, компания получает налоговые льготы. И да, я трачу какое-то время на шефство, но студент всё равно делает полезную работу, и учитывая то, что за стаж они денег не получают, компания скорее в заметном плюсе, чем в минусе. Опять же, когда (если) студента берут на работу, уже нет доп. затрат на знакомство с компанией, её бизнесом и процессами.
И, не поймите меня неправильно, - компания чаще ищет сеньёров, чем джунов. Но рост и ротация внутри компании есть, так что и вчерашним студентам место найти можно.
Наша компания (Монреаль, канада) постоянно берёт студентов на практику (3 месяца). Разницы с "толковостью" между студентами "до ИИ" эпохи и сейчас - я не вижу. Реально хочется оставить, наверное, каждого третьего-четвертого, то есть процентов 30 выпускников - толковые ребята и перспективные джуны.
(все джунские вакансии ими и занимаются в итоге)
Использую NotebookLM (Gemini Notebook он стал буквально в июле этого года) для анализа всевозможных договоров и контрактов. Очень удобно для понимания юридического лексикона, написанного "мелким шрифтом".
Ой не не скажите... Некоторые "иишные фразочки" просто бесят. Когда Gemini, отвечая на вопрос этой зимой, первый раз сказала, что "это классика жанра", я улыбнулся. Но скоро эта оговорка про "классические" проблемы начала подбешивать. Кончилось тем, что поставил в профиле явный запрет на это, не говоря уже о том, что б употреблять такое самому...
Знать, какой текст сгенерирован иишкой - в общем-то полезно. Не понимаю, что некоторые авторы так возбудились на это? В идеале вообще было бы здорово, чтоб после каждого сгенерированного текста стояла подпись, которую при желании, можно было бы дешифровать в "<модель LLM>, <agent> [Skills used], <user prompt summary>"
Как я понимаю, BCS это не работа, это для работы. И вряд ли киприотским чиновникам нужен оригинал, а не заверенный сертифицированный перевод, про что я писал выше.
Тоже хотел это процитировать - "за рубежом" нафиг никому не сдался "оригинал".
Чиновники, если нужно подтвердить факт образования - смотрят заверенный перевод. Если будет сомнение в подлинности документа - сами запросят ВУЗ.
В академической среде, например для продолжения учёбы, детализацию по предметам/оценкам попросят, чтоб послал университет.
При устройстве на работу обычно вообще никто диплом не просит показывать. Ни оригинал, ни перевод.
в русский очень чётко вписывается "ИИшка". "иишный код". Если глагол, то можно "наиишить".
Применяя чужую историю к своему проекту, я добавляю риски false positive and false negative.
Но если чужая история таки выявит проблему в моём коде, это не значит, что применять эти чужие истории - есть практика улучшения моего продукта. Это значит, что мне нужно пересмотреть мои текущие настройки, обвязки и т.п.
Другими словами, искать зерно истины в куче чужих историй - это с моей т.з. потеря времени (и/или токенов).
Простите, но у вас "продукт" - частная "история", случившиеся в субъективном пространстве. Это нельзя экстраполировать как общий случай для всех систем, учитывая их многообразие (языки программирования, архитектуры, паттерны, используемые агенты и установленные обвязки). Например, то, что актуально для питона, может быть совсем неактуально для других яп.
Ваши воспроизводимые истории с большой степенью вероятности воспроизведутся в схожей с изначальной экосистемой. Но даже и тут нет стопроцентной гарантии. Может быть конфликт инструкций, разность в интерпретациях моделей и т.п.