Во‑первых, внутренний переход. Всё больше джуниоров будут набирать из числа тестировщиков (для бэкенда), аналитиков (тоже для бэкенда) и дизайнеров (для фронтенда). Да, это не чистые программисты с нуля, а уже «полуфабрикаты»: большинство из них владеет основами кодинга и, что важнее, хорошо знает внутренние бизнес-процессы. Им не нужно тратить время на погружение в предметную область — они уже там работают.
Во‑вторых, приток из фундаментальных наук. В сложных предметных областях (финансы, биоинформатика, физическое моделирование) проще нанять квалифицированных математиков, физиков или биологов, чем учить программиста матчасти. Тем более что большинство таких технарей уже владеет азами программирования — ещё со школы или университета (Python, R, Matlab, C++ — в зависимости от специальности). Они приносят с собой строгость мышления и умение формализовать задачи, а базовый код им уже знаком.
Дальше у компаний будет развилка: либо дать таким новичкам мощный ИИ-инструмент и позволить ему «дописывать» код, либо вложить время и ресурсы в их системное обучение программированию. Первый путь — быстрый, но рискованный (ведёт к «поколению Approve»). Второй — медленный, но, вероятно, единственный способ вырастить инженеров, способных принимать самостоятельные решения.
ИИ — это мультипликатор производительности. Сам по себе он не заменяет джуниоров, но связка «сеньор + ИИ» способна заменить десятки джунов.
Я использую ИИ при разработке в очень сложной предметной области. Он заметно ускоряет написание кода, но для этого приходится очень плотно с ним взаимодействовать. Нельзя просто отдать команду и уйти пить кофе — нужно постоянно контролировать происходящее.
Именно поэтому планка требований к разработчикам растёт: для эффективной работы с ИИ как раз и нужна высокая квалификация. Раньше программирование было похоже на любительский футбол по уровню входа — научиться и начать играть мог почти каждый. Но в футболе за любительский уровень не платят, а в программировании платили. Сейчас планка выросла.
Сейчас программирование всё больше начинает напоминать игру в го.
По сути, то же самое у нас, тоже недавно родственница заболела, вызвали скорую, она отвезла ее в инфекционную с подозрением на кишечную инфекцию, там ее положили в палату со всеми удобствами, под капельницу, и там она с соседкой пролежала дней 5. Единственное передвигаться по больнице нельзя было, по понятным причинам.
Насчет роботов я не был бы так уверен, хотя софтверная часть активно развивается, но материальная база пока сильно отстает, для гуманоидных роботов с приемлемым соотношением цена/полезность требуются другие технологии.
Доступ к некоторым российским СМИ был ограничен в ЕС в соответствии с законами о DSA/санкциях Тем временем, все западные медиа-каналы Telegram остаются в свободном доступе в России Кто бы мог подумать, что в 2025 году российские пользователи Telegram будут пользоваться большей свободой, чем европейские?
При прочтении данной статьи, возникло ощущение, что автор уже определился с выбором. А статью написал просто, чтобы обосновать этот выбор остальным.
Но вообще конечно это треш, ради не слишком сложных проверок использовать вычислительные мощности языковой модели, работу которой ты не проверишь и не отладишь.
Складываются ощущение, что большая часть претензий автора к коду высосана из пальца и решается правильной реализацией принципов ООП и SOLID в коде. Это в языках типа С от if было никуда не деться, а в С# есть Стратегия для сложных проверок, и множество разных методов для простых. Если проверок становиться слишком много можно использовать Validations Frameworks или самому создать нечто подобное.
Возможно конечно у автора есть какие то более весомы доводы для использования языковой модели, но из статьи они не очевидны.
16 килобаксов это реально очень дешево, промышленные роботы типа рука, стоят пару лямов деревянных , скорее всего в цене робота пропущено пара нулей. Иначе сложно объяснить почему он ужу не бегает на производстве.
Есть подозрение, что если бы чел оставался в IT, то зарабатывал бы сейчас куда больше. Тем более судя по по всему способности у него к программированию есть. С 15 года популярность Unity прилично выросла.
Очевидно, нет серебряной пули, каждый случай индивидуален. Например, когда у тебя небольшая утилита для расчетов, делать для которой полноценные конфиги избыточно и затратно, то в этом случае тот же settings.py замечательно подойдет.
Один мой друг, как то за год поменял 3 или 4 работы, так как те его, по тем или иным причинам, не устраивали. Ту которая нравиться так и не нашел. Часто вспоминает самую первую компанию от которой ушел за большим рублем.
Странная статья, если бы не межзвёздная пыль, то в небе мы наблюдали бы второй солнце, от Балджа (облако звезд из центра галактики) , настолько большая там интенсивность излучения, там ничего живого просто не выживет при той температуре, это как в центре звезды находиться.
Откуда возьмутся новые кадры?
Я вижу два основных источника.
Во‑первых, внутренний переход. Всё больше джуниоров будут набирать из числа тестировщиков (для бэкенда), аналитиков (тоже для бэкенда) и дизайнеров (для фронтенда). Да, это не чистые программисты с нуля, а уже «полуфабрикаты»: большинство из них владеет основами кодинга и, что важнее, хорошо знает внутренние бизнес-процессы. Им не нужно тратить время на погружение в предметную область — они уже там работают.
Во‑вторых, приток из фундаментальных наук. В сложных предметных областях (финансы, биоинформатика, физическое моделирование) проще нанять квалифицированных математиков, физиков или биологов, чем учить программиста матчасти. Тем более что большинство таких технарей уже владеет азами программирования — ещё со школы или университета (Python, R, Matlab, C++ — в зависимости от специальности). Они приносят с собой строгость мышления и умение формализовать задачи, а базовый код им уже знаком.
Дальше у компаний будет развилка: либо дать таким новичкам мощный ИИ-инструмент и позволить ему «дописывать» код, либо вложить время и ресурсы в их системное обучение программированию. Первый путь — быстрый, но рискованный (ведёт к «поколению Approve»). Второй — медленный, но, вероятно, единственный способ вырастить инженеров, способных принимать самостоятельные решения.
ИИ — это мультипликатор производительности. Сам по себе он не заменяет джуниоров, но связка «сеньор + ИИ» способна заменить десятки джунов.
Я использую ИИ при разработке в очень сложной предметной области. Он заметно ускоряет написание кода, но для этого приходится очень плотно с ним взаимодействовать. Нельзя просто отдать команду и уйти пить кофе — нужно постоянно контролировать происходящее.
Именно поэтому планка требований к разработчикам растёт: для эффективной работы с ИИ как раз и нужна высокая квалификация. Раньше программирование было похоже на любительский футбол по уровню входа — научиться и начать играть мог почти каждый. Но в футболе за любительский уровень не платят, а в программировании платили. Сейчас планка выросла.
Сейчас программирование всё больше начинает напоминать игру в го.
Ни одного, знакомого названия 🤔.
По сути, то же самое у нас, тоже недавно родственница заболела, вызвали скорую, она отвезла ее в инфекционную с подозрением на кишечную инфекцию, там ее положили в палату со всеми удобствами, под капельницу, и там она с соседкой пролежала дней 5. Единственное передвигаться по больнице нельзя было, по понятным причинам.
Насчет роботов я не был бы так уверен, хотя софтверная часть активно развивается, но материальная база пока сильно отстает, для гуманоидных роботов с приемлемым соотношением цена/полезность требуются другие технологии.
Павел Дуров https://t.me/durov/387
При прочтении данной статьи, возникло ощущение, что автор уже определился с выбором. А статью написал просто, чтобы обосновать этот выбор остальным.
Но вообще конечно это треш, ради не слишком сложных проверок использовать вычислительные мощности языковой модели, работу которой ты не проверишь и не отладишь.
Складываются ощущение, что большая часть претензий автора к коду высосана из пальца и решается правильной реализацией принципов ООП и SOLID в коде. Это в языках типа С от if было никуда не деться, а в С# есть Стратегия для сложных проверок, и множество разных методов для простых. Если проверок становиться слишком много можно использовать Validations Frameworks или самому создать нечто подобное.
Возможно конечно у автора есть какие то более весомы доводы для использования языковой модели, но из статьи они не очевидны.
Сейчас ИИ довольно бурно развивается, подозреваю через короткое время учебники уже устареют.
16 килобаксов это реально очень дешево, промышленные роботы типа рука, стоят пару лямов деревянных , скорее всего в цене робота пропущено пара нулей. Иначе сложно объяснить почему он ужу не бегает на производстве.
Круто, давно не видел, чтобы так емко, кратко и поделу.
Есть подозрение, что если бы чел оставался в IT, то зарабатывал бы сейчас куда больше. Тем более судя по по всему способности у него к программированию есть. С 15 года популярность Unity прилично выросла.
Очевидно, нет серебряной пули, каждый случай индивидуален. Например, когда у тебя небольшая утилита для расчетов, делать для которой полноценные конфиги избыточно и затратно, то в этом случае тот же settings.py замечательно подойдет.
Если книга в электронном виде, то спиратить ее гораздо легче.
Один мой друг, как то за год поменял 3 или 4 работы, так как те его, по тем или иным причинам, не устраивали. Ту которая нравиться так и не нашел. Часто вспоминает самую первую компанию от которой ушел за большим рублем.
Странная статья, если бы не межзвёздная пыль, то в небе мы наблюдали бы второй солнце, от Балджа (облако звезд из центра галактики) , настолько большая там интенсивность излучения, там ничего живого просто не выживет при той температуре, это как в центре звезды находиться.