Возможно мои мысли могут встретить сопротивление у приверженцев традиционного программирования или олдскулов. Но реальность такова, что происходит трансформация роли программиста — и мне кажется, её отлично иллюстрирует аналогия с промышленной революцией.
Вспомним переход от мануфактур и ремесленных мастерских к фабрикам и заводам в XVIII–XIX веках:
Ремесленник кропотливо создавал изделие вручную — каждое было уникальным, но дорогим и редким.
Сопротивление: луддиты ломали станки, опасаясь потери работы и обесценивания мастерства. Многие считали, что машинное производство убивает «душу» вещи.
Фабрика (завод) внедрила стандартизацию и массовое производство. Результат: товары стали доступнее, объёмы выросли в разы, но роль рабочего изменилась — он стал не творцом, а оператором станка, контролирующим процесс.
Новая реальность: ремесло не исчезло — оно перешло в нишу премиальных, эксклюзивных изделий. Ручная работа стала дороже и ценится именно за уникальность и «прикосновение мастера».
Разве ничего не напоминает. Перенесём эту модель на разработку ПО и ИИ:
«Ремесленная стадия» — программист пишет код полностью вручную. Это требует высочайшей квалификации, долго, дорого, но даёт полный контроль и уникальность решения.
Сопротивление ИИ‑ассистентам: опасения, что «ИИ отберёт работу», что код станет шаблонным, а навыки программистов деградируют. Звучат призывы «писать код самим, как раньше».
«Заводская стадия» (ИИ‑ассистирование) — ИИ становятся «станками» для кода роль программиста меняется: он становится дирижёром или технологом — проектирует архитектуру, выбирает решения, курирует процесс, оптимизирует результат. И именно сейчас мы находим в той стадии где меняется реальность и задаются неудобные вопросы:
«ИИ отберёт работу у программистов?» - думаю рутинные задачи уйдут к ИИ, но вырастет спрос на архитекторов систем и промпт-инженеров.
«Код станет шаблонным и безликим?» - возможно появятся «дизайнеры кода» — те, кто придаёт решениям стиль и элегантность. Кто писал через github copilot или на аналогах, поймут иронию)))
«Не деградируют ли навыки программистов?» - программист будет реже писать код с нуля, но должен понимать, как работает и почему ему ИИ предложил то или иное решение т.е. больше архитектуры нежели чем писать.
«Что будет с опенсорсом?» - как и в аналогии фабрики не убили ремесло, а массовый опенсорс будет создаваться с помощью ИИ быстрее и дешевле.
«Кто автор кода, сгенерированного ИИ?» - так-же подводя аналогию я думаю, что нужны новые юридические модели т.к. должно учитываться и явно указанным на каком "заводе" и как сделано продукт. Например, указание на «совместную разработку с ИИ‑ассистентом» и прозрачность обучения модели на каких опенсорс‑проектах она обучалась. Ну тут жаль что я не юрист а могу только предложить)))
Новая реальность: массовый код создаётся с помощью ИИ — быстро, дёшево, стандартизировано (как товары с завода). А «ручная работа» остаётся в премиальном сегменте сложные архитектурные решения или оптимизация критических участков (производительность, безопасность) или проекты, где важен уникальный подход и полный контроль над кодом.
Наша реальность и акценты в программировании и отношении к коду меняются. Как и в промышленной революции. Программист будущего — это не человек, который быстрее всех пишет циклы for, а тот, кто: грамотно ставит задачи (промпт‑инжиниринг); видит общую архитектуру системы. Для себя с опытом ещё 20-х годах уже сделал акцент что архитектура важнее.
Полностью понимаю автора с его болью в изменениях. Имел такой опыт работы в компании, где с тебя требуют изменений, но извини людей нет иди мотивируй текущих на дополнительную работу после основной работы. Сам обозначь цель, замотивируй и принеси результат ты же должен работать на результат. В тоге после долгих попыток выбить бюджет, обозначить что руководство должно обозначать цели - я не выдержал и ушёл)) Как сейчас вижу не зря это сделал т.к. прошлая компания всё ещё в поисках волшебства!
всё очень просто. Проще построить пирамиду, чтобы за тебя школьники которые себя считаю хацкерами делали всё эту работу а ты собирал только логи и продавал их. Старая схема сбора персональных данных
Очень знакома и близка "Причина 2: разочарование в работе" историей Дениса. Работал архитектором в компании с численностью от 250 ИТ специалистов. Да, долго через муки и страдания понял что ценности расходятся и как я хотел ИТ компанию тут не построить а готовы только делать сервисный центр для агрохолдинговой компании. Какие либо встречи как автор советует "обсудить ситуацию с руководителем", не помогали т.к. мой руководитель был директор компании и он только подбадривал т.к. его основная цель была удержать любыми правдами и не правдами. Что в итоге делало выгорание только хуже. Совет всем кто подозревает что его работа "не делает мир лучше" и есть симптомы выгорания начать с общих встреч: Начните с обычной ретроспективы, выделите проблемы с командой и сотрудниками с которыми работаете и намети шаги. Если вы увидите что команда в упор не видят проблемы которые видите вы, то попробуйте их раскрыть. Цель понять что корабль в котором вы плывёт по тому-же адресу, который вам нужен. Так вы сразу поймёте стоит ли менять компанию т.к. плыть в корабле не потому адресу только нагоняет депрессию.
В итоге я для себя принял решение сменить работу и полностью этому рад. Да, это было сложно во всех обстоятельствах и были сомнения. Но и тог я рад
Дополню исходя из опыта. В репозитории хорошо иметь не только README.md а ещё и License, Authors и важно Changelog. Все коммиты должны быть связанны с Changelog историей разработки поэтому каждый коммит должен начинатся с {code-task-tracker} а если мы делаем не монолит а микросервисы то мы должны иметь общий индекс системы чтобы понимать ещё и связи {index} и того чтобы понять что это лучше взять в квадратные скобках т.к. вот так git commit -m "[SHOP-ISSUE-994] feat: добавлен вывод строки" # index = shop, code-task-tracker = issue 994 т.к. так трекер не всегда может быть частью git. И нам остаётся только в Changelog указать что мы закрыли issue 994 для shop)))) и естественно описав что изменили.
История коммитов это очень хорошо. Главное не забывать что есть ещё теги, история изменений и правила ветвления. Всё в мести при правильном использования как раз и даёт полноту картины и удобства использования.
Отличные новости, ждём пакет с адаптацией CycleORM под Yii3! т.к. нам в Yii2 не хватает полноценной ORM, которая реализована по модели DataMapper. Так-же кому интересно про ЭФКО можно подробней ознакомиться на Хабр.Карьера https://career.habr.com/companies/efko
да, когда у нас только 3х разделения:
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
Бизнесу нужны DevOps, а то наберут этих админов и программистов, а они в ответ это не моя задача не в моей ответственности. (сарказм)
Я вот работаю веб-программистов(на каком говне только не пишу), но также администрирую веб-сервера и реализую полную CI интеграцию для проектов. Что я теперь DevOps? Нет я так не считаю, считаю, что я просто могу провести веб проект от начала до конца.
Доля правды в этом есть. Встречал у нас на работе специалиста который всю жизнь писал на беке и тут решил на js написать часть со словами, а там всё просто. Так для того чтобы сделать «динамическую форму» он отправлял на сервере в сесии всю таблицу всё делал на сервере и на клиенте назад принимал сессию (не json). Кто угадает что он делал на клиенте, правильно ajax на jquery. А что он делал на сервере, правильно сортировку и математические вычисления. Странно почему код тормозил.
Я работаю в компании где на каждое действия есть свой регламент. Есть регламенты даже на общение сотрудников внутри офиса и походов в туалет за несоблюдение которые начисляются штрафы. Конечно компания берёт в себя все новые веяния корпоративы, вывозки на природу, но реализует их в соответствие со своими правилами т.е. компания организует, а за корпоротив платишь ты, сходил не по регламенту с тебя штраф, а если не сходил, то пишешь объяснительную. Очередной раз читаю таю статью думаешь, как же у нас переделают под себя.
Может и удобно погрузится а экосистему одного продукта. Но для меня это не плюс мне интересно и нужно чтобы продукт был интегрирован со сторонним софтом и железом. Как выше я писал пока не не вижу чтобы продукты Яндекса вообще как-то работали со сторонним софтом (Их вообще нет в play market с поддержкой больших экранов :-) и управление клавиатурой или пультом вообще лучше молчать :-) )
Ради будильника покупать))) Я про то что интеграция со сторонним софтом страдает. У того же гугл ассистента больше поддержек ПО (но там и так очевидно). А на androidTV так они вообще не могут уже больше 2х лет что-то сделать (считают от отправленных писем в поддержку)
Спасибо за статью!
Возможно мои мысли могут встретить сопротивление у приверженцев традиционного программирования или олдскулов. Но реальность такова, что происходит трансформация роли программиста — и мне кажется, её отлично иллюстрирует аналогия с промышленной революцией.
Вспомним переход от мануфактур и ремесленных мастерских к фабрикам и заводам в XVIII–XIX веках:
Ремесленник кропотливо создавал изделие вручную — каждое было уникальным, но дорогим и редким.
Сопротивление: луддиты ломали станки, опасаясь потери работы и обесценивания мастерства. Многие считали, что машинное производство убивает «душу» вещи.
Фабрика (завод) внедрила стандартизацию и массовое производство. Результат: товары стали доступнее, объёмы выросли в разы, но роль рабочего изменилась — он стал не творцом, а оператором станка, контролирующим процесс.
Новая реальность: ремесло не исчезло — оно перешло в нишу премиальных, эксклюзивных изделий. Ручная работа стала дороже и ценится именно за уникальность и «прикосновение мастера».
Разве ничего не напоминает. Перенесём эту модель на разработку ПО и ИИ:
«Ремесленная стадия» — программист пишет код полностью вручную. Это требует высочайшей квалификации, долго, дорого, но даёт полный контроль и уникальность решения.
Сопротивление ИИ‑ассистентам: опасения, что «ИИ отберёт работу», что код станет шаблонным, а навыки программистов деградируют. Звучат призывы «писать код самим, как раньше».
«Заводская стадия» (ИИ‑ассистирование) — ИИ становятся «станками» для кода роль программиста меняется: он становится дирижёром или технологом — проектирует архитектуру, выбирает решения, курирует процесс, оптимизирует результат. И именно сейчас мы находим в той стадии где меняется реальность и задаются неудобные вопросы:
«ИИ отберёт работу у программистов?» - думаю рутинные задачи уйдут к ИИ, но вырастет спрос на архитекторов систем и промпт-инженеров.
«Код станет шаблонным и безликим?» - возможно появятся «дизайнеры кода» — те, кто придаёт решениям стиль и элегантность. Кто писал через github copilot или на аналогах, поймут иронию)))
«Не деградируют ли навыки программистов?» - программист будет реже писать код с нуля, но должен понимать, как работает и почему ему ИИ предложил то или иное решение т.е. больше архитектуры нежели чем писать.
«Что будет с опенсорсом?» - как и в аналогии фабрики не убили ремесло, а массовый опенсорс будет создаваться с помощью ИИ быстрее и дешевле.
«Кто автор кода, сгенерированного ИИ?» - так-же подводя аналогию я думаю, что нужны новые юридические модели т.к. должно учитываться и явно указанным на каком "заводе" и как сделано продукт. Например, указание на «совместную разработку с ИИ‑ассистентом» и прозрачность обучения модели на каких опенсорс‑проектах она обучалась. Ну тут жаль что я не юрист а могу только предложить)))
Новая реальность: массовый код создаётся с помощью ИИ — быстро, дёшево, стандартизировано (как товары с завода). А «ручная работа» остаётся в премиальном сегменте сложные архитектурные решения или оптимизация критических участков (производительность, безопасность) или проекты, где важен уникальный подход и полный контроль над кодом.
Наша реальность и акценты в программировании и отношении к коду меняются. Как и в промышленной революции. Программист будущего — это не человек, который быстрее всех пишет циклы
for, а тот, кто: грамотно ставит задачи (промпт‑инжиниринг); видит общую архитектуру системы. Для себя с опытом ещё 20-х годах уже сделал акцент что архитектура важнее.Спасибо, что поднимаете эту важную тему!
Спасибо! Для статьи про настройку домашнего оркестратора с Flow‑процессами на no‑code планирую оформить удобный скрипт развёртывания.
Тоже хочу понять где происходит SAFe представлен как противоположность? Акцент на том что SAFe дополняет TOGAF для одного из вариантов Agile.
Вся статья про то как часть архитекторы упускают азы и допускают ошибки опираясь только на прошлый опыт. Поэтому это как опыт-совет от начала до конца
Полностью понимаю автора с его болью в изменениях. Имел такой опыт работы в компании, где с тебя требуют изменений, но извини людей нет иди мотивируй текущих на дополнительную работу после основной работы. Сам обозначь цель, замотивируй и принеси результат ты же должен работать на результат. В тоге после долгих попыток выбить бюджет, обозначить что руководство должно обозначать цели - я не выдержал и ушёл)) Как сейчас вижу не зря это сделал т.к. прошлая компания всё ещё в поисках волшебства!
всё очень просто. Проще построить пирамиду, чтобы за тебя школьники которые себя считаю хацкерами делали всё эту работу а ты собирал только логи и продавал их. Старая схема сбора персональных данных
Очень знакома и близка "Причина 2: разочарование в работе" историей Дениса. Работал архитектором в компании с численностью от 250 ИТ специалистов. Да, долго через муки и страдания понял что ценности расходятся и как я хотел ИТ компанию тут не построить а готовы только делать сервисный центр для агрохолдинговой компании. Какие либо встречи как автор советует "обсудить ситуацию с руководителем", не помогали т.к. мой руководитель был директор компании и он только подбадривал т.к. его основная цель была удержать любыми правдами и не правдами. Что в итоге делало выгорание только хуже. Совет всем кто подозревает что его работа "не делает мир лучше" и есть симптомы выгорания начать с общих встреч: Начните с обычной ретроспективы, выделите проблемы с командой и сотрудниками с которыми работаете и намети шаги. Если вы увидите что команда в упор не видят проблемы которые видите вы, то попробуйте их раскрыть. Цель понять что корабль в котором вы плывёт по тому-же адресу, который вам нужен. Так вы сразу поймёте стоит ли менять компанию т.к. плыть в корабле не потому адресу только нагоняет депрессию.
В итоге я для себя принял решение сменить работу и полностью этому рад. Да, это было сложно во всех обстоятельствах и были сомнения. Но и тог я рад
Дополню исходя из опыта. В репозитории хорошо иметь не только README.md а ещё и License, Authors и важно Changelog. Все коммиты должны быть связанны с Changelog историей разработки поэтому каждый коммит должен начинатся с {code-task-tracker} а если мы делаем не монолит а микросервисы то мы должны иметь общий индекс системы чтобы понимать ещё и связи {index} и того чтобы понять что это лучше взять в квадратные скобках т.к. вот так git commit -m "[SHOP-ISSUE-994] feat: добавлен вывод строки" # index = shop, code-task-tracker = issue 994 т.к. так трекер не всегда может быть частью git. И нам остаётся только в Changelog указать что мы закрыли issue 994 для shop)))) и естественно описав что изменили.
История коммитов это очень хорошо. Главное не забывать что есть ещё теги, история изменений и правила ветвления. Всё в мести при правильном использования как раз и даёт полноту картины и удобства использования.
Отличные новости, ждём пакет с адаптацией CycleORM под Yii3! т.к. нам в Yii2 не хватает полноценной ORM, которая реализована по модели DataMapper. Так-же кому интересно про ЭФКО можно подробней ознакомиться на Хабр.Карьера https://career.habr.com/companies/efko
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
Я вот работаю веб-программистов(на каком говне только не пишу), но также администрирую веб-сервера и реализую полную CI интеграцию для проектов. Что я теперь DevOps? Нет я так не считаю, считаю, что я просто могу провести веб проект от начала до конца.