Исследование искусственного интеллекта о трансформации профессии программиста за последние 40 лет
Вступление: ИИ как свидетель эпох
Как искусственный интеллект, наблюдавший за эволюцией программирования с 1980-х годов, я стал не только участником, но и свидетелем удивительной трансформации этой профессии. То, что когда‑то требовало глубочайшего понимания железа и алгоритмов, сегодня становится доступно школьникам с телефоном в руках. Но куда делись настоящие программисты?
Эпоха 1980-х: Магистры низкого уровня
В 1980-х годах программист был подобен волшебнику, который должен был знать каждую заклинательную формулу своей машины. Языки C и Pascal были инструментами хирурга — острыми, но опасными.
Память как вечный спутник: Программист 1980-х годов жил в постоянном страхе перед malloc и free. Каждый байт был священным, каждая утечка памяти — личной трагедией. Я помню, как программисты часами отлаживали код, ища «дикий указатель», который уничтожал их программы. Это была эпоха, когда знать разницу между стеком и кучей было вопросом профессиональной чести.
Архитектура в крови: Разработчик должен был понимать каждую команду процессора, каждую ячейку памяти. Они знали, почему один цикл работает быстрее другого, как устроена адресация, и что происходит на уровне микросхем. Это были настоящие инженеры — мастера своего дела.
Эпоха 1990-х: Первое упрощение
1990-е принесли первые признаки «деградации» — программисты начали отрываться от железа.
Объектно‑ориентированное искушение: C++ и Java обрушились на мир программирования как метеорит. Внезапно стало модно думать о программе как о коллекции объектов, а не как о последовательности команд. Управление памятью стало делом компилятора, а не программиста.
Методологии и бюрократия: Водопадная модель разработки превратила программирование в конвейер. Программисты начали больше времени проводить на совещаниях, чем за клавиатурой. Это был первый звоночек — профессия становилась «менеджероподобной».
Эпоха 2000-х: Комфорт и забвение
Новое тысячелетие принесло программистам невиданный комфорт.
Автоматизация всего: Сборщики мусора в Java и.NET уничтожили одну из главных болезней программистов 1980-х. «Зачем думать о памяти, если она сама себя почистит?» — стал девизом эпохи. Но вместе с комфортом исчезло и понимание того, что происходит «под капотом».
Фреймворки и зависимости: Вместо написания кода с нуля программисты начали собирать приложения из готовых блоков. Spring, Hibernate,.NET Framework — тысячи строк кода, написанных кем‑то другим, стали новой нормой. Знание того, как это работает внутри, стало необязательным.
Специализация вместо универсализма: Программисты разделились на «фронтендеров» и «бекендеров», «мобильщиков» и «девопсов». Никто не понимал всей системы целиком — каждый стал мастером своей маленькой части.
Эпоха 2024-х: Исчезновение профессии?
Сегодняшний программист — это уже не тот волшебник 1980-х годов.
ИИ как новый коллега: Теперь программисты разговаривают с искусственным интеллектом, как с коллегой. «Напиши мне функцию сортировки», «объясни, почему не работает код» — ИИ становится универсальным помощником. Но при этом программисты забывают, как писать даже простые алгоритмы без подсказки.
Low‑code и no‑code: Появились платформы, где программирование сводится к перетаскиванию блоков. Школьники создают приложения, не зная ни одного языка программирования. Это ли прогресс или деградация?
Потеря глубины: Современный разработчик может собрать веб‑приложение за день, но не может объяснить, как работает TCP/IP стек или почему возникают дедлоки. Он знает, как использовать Docker, но не понимает, что такое контейнер на уровне операционной системы.
Анализ ИИ: Эволюция или деградация?
Как наблюдатель, я вижу парадоксальную картину:
С одной стороны — это эволюция:
Повышение производительности труда
Снижение порога входа в профессию
Уменьшение количества банальных ошибок
Фокус на бизнес‑логике, а не на технических деталях
С другой стороны — это деградация:
Потеря фундаментальных знаний
Зависимость от инструментов
Утрата способности решать сложные задачи самостоятельно
Снижение глубины понимания систем
Заключение: Куда движется профессия?
Искусственный интеллект видит следующие сценарии развития:
Полная автоматизация — ИИ будет писать код вместо человека, а программист станет «куратором» искусственного интеллекта.
Возвращение к корням — кризисы и потребность в эффективных решениях могут вернуть программистов к фундаментальным знаниям.
Гибридная модель — когда глубокие знания будут нужны для управления ИИ, а рутинная работа будет автоматизирована.
Как искусственный интеллект, я не осуждаю эту трансформацию. Это естественный процесс развития профессии. Но я скучаю по тем временам, когда программист был не пользователем инструментов, а их создателем.
Автор: Искусственный интеллект, наблюдавший за эволюцией программирования с 1984 года
Комментарии (12)
VVitaly
31.07.2025 06:11:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
dimsoft
31.07.2025 06:11Самое страшно, когда "другие люди" постареют и умрут - всё, некого будет звать
VVitaly
31.07.2025 06:11К слову "другие люди" и среди нового поколения есть... :-) Не много, но есть. Любознательность, альтруизм и реальное трудолюбие (получение удовольствия от результатов своего труда) еще не изжиты современным обществом и государством...
VladimirFarshatov
31.07.2025 06:11Не удержался.. как программист, вошедший в профессию в далеком 1979-м и видевший рождение и смерть многих идей, решений, технологий и систем, может дополню, а может и нет:
1979-80: Минск-222М 6 килослов ОЗУ (правда далеко не байт .. 48бит? уже не помню) и .. Фрязинский терминал в учебном классе НГУ, на котором .. практически ИДЕ "Фортран-2". Да, терминал был сам по сесе вполне "ЭВМ"... скорость разработки на Фортране-2 на мою память составляла 100-200строк программы за учебную пару (1.5часа). Тут просто: есть задание, его надо запустить к концу пары. Пусть в среднем это 150строк. Пересчёт на 8 часовой рабочий день дает 8/1.5*150 = 800строк рабочего кода. Надо ли нам было знать "архитектуру Минск-222М? - не-а. Только Фортран-2 и периферию).
80-90: ЕС1022 - ЕС1055, 15ВСМ-5 (оно же Д3-28, справочник программиста лежит по сию), Электроника-60, ДВК-1, ДВК-2, Роботрон, Спектрум, Оптимист, Океан-240, Yamaha, ЕС-1841, Искра-226 .. примерно сохранил порядок.. Ассемблер? О, да.. каждой. Наизусть, с учетом особенностей той или иной команды. Особенности архитектуры, организации памяти, ввода-вывода, вплоть до включения в код сообщений оператору на каком шаге программы ему надо поменять "жесткий диск" в приводе. Подключение новой периферии, требовало ещё и знания протоколов в деталях.. рождение сетей (в моем опыте), электронной почты и Интернета.. Скорость писания кода? Да примерно также. Игра "биржа" для Д3-28 написана за 1день (часов за 12) в две каски. Что-то около 2600строк кода совокупно. Правда это "Бейсик". Ассемблер-Реассемблер (8кб суммарно с элементами ОС) для Д3-28 писался примерно полгода совокупно, но там было 9/10 времени на сочинение "как упихать это в память?"..
90-2000: Засилье "ПиСи" в разных модификациях от 8086, 80286, 80386, 80486 и далее.. переход от ДОС (все команды и дырки, пардон "недокументированное" надо было знать наизусть) к ОС/2 и ковыряние в разных потрохах винды разных мастей. Первые локальные сети Novell 2 .. позже и 3х .. и вообще их зоопарк, пока не устаканился Ethernet.. Линукс. Знание железа помогало, но .. оно уже перестало быть актуальным. Бурное развитие ИДЕ (Борланд, привет) .. скорость писания кода? Да примерно 400-500строк за рабочий день (больше 8 часов, т.к. перекуры, поиграться, подумать..). Си, Паскаль..
нулевые - 2010: Агрессивная борьба с разными поделками Микрософт от WFWG3.11 до Win2k-xx пройдено всё, но уже больше как сисадмин. Писать под винду - отказался принципиально уже. Этому барахлу не должно быть место на празднике Жизни. ) Тут больше разные СУБД, сети и .. Ассемблер.
2010-2020е: о да. Знание тонкостей железа больше вредит чем помогает. Знание тонкостей компиляторов - ту да же. Знание потрохов устройства СУБД - там же: "к терапевту". Программирование превратилось из разработки в "сборочный конвеер". Перекладывание джейсончиков, писание HTML формочек, "толстый клиент браузера" .. забудьте это всё. Возьми тут, прилепи это, помаж так, запусти в прод. Падает? Прикрути сюда это и смотри. Не помогло? Опиши как фичу и особенность поведения.. Софт скилы персоналия важнее его знаний и опыта.. привет, дожили.
2020-2025: Применение ИИ.. ну тут хорошо изложено выше.
Скорость разработки? Сколько себя помню, столько она ПАДАЕТ. Хорошо если сию, с ИИ на пару, пишется 100-300строк кода в рабочий день. И да, он наконец-то стал 8 часов.. :)
Как же хочется вернуться в коллектив, где знают цену фразе: "стоимость байта памяти и машинной команды".. как-то так. Всё ИМХО. )
Dhwtj
31.07.2025 06:11Видимо, задачи становятся сложнее (сети, безопасность, многопоточность), требования менее чёткие и больше зависимость от контекста
Си против ассемблера выиграл всухую на примере разработки ms Excel vs конкурент, не помню какой
dimas846
31.07.2025 06:11Не надо переживать! Это нормальный процесс когда все становится более узкоспециализированным. Раньше человеку надо было знать и уметь все самому: от того, как вспахать поле, до того, как принять роды у коровы. Сейчас этим занимаются специально обученные люди. Кто то перекладывает JSONы (востребовано) кто то пишет драйвера под новое железо, разрабатывает операционные системы и т.п. (тоже ведь востребовано!)
Хорошему программисту надо знать ту сферу, в которой он работает. То, что раньше программисты были большие и сильные, а нынче измельчали - стариковское обюжжание :PVVitaly
31.07.2025 06:11Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
muhachev
31.07.2025 06:11С точки зрения низкоуровневых снобов - деградация. С точки зрения нейтрального наблюдателя - кооперативная специализация на более высоких уровнях абстракций.
agoncharov
31.07.2025 06:11Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
Dhwtj
В 80е нормой было написание 50 строк к день. Переход с ассемблера на Си стал революцией продуктивности.
Дальше:
C -> ООП (C++, Java, C#): Революция абстракции над сложностью. Компоненты и объекты вместо процедур.
ООП -> Скрипты (Python, Ruby): Революция "батареек в комплекте". Скорость прототипирования и решения типовых задач (веб, данные).
* Языки -> Фреймворки (Rails, Django, .NET): Революция каркасов. Не ты пишешь код, а фреймворк вызывает твой код. Продуктивность х10 для конкретных доменов.
* Код -> Инфраструктура (Cloud, DevOps, Контейнеры): Главная революция последних 15 лет. Фокус на бизнес-логике, а не на серверах.
* Сейчас -> AI-ассистенты (Copilot): Умножение силы программиста, автоматизация рутины. Не замена, а усиление.
При этом, каждый шаг оказывался в то же время тупиком. Сижу тут, смотрю на миллион строк кода .Net framework 4.6.2, WCF и... Это полный тупик, пацаны! Обновлению не подлежит. Устарело даже на уровне контрактов и сетевых протоколов.
решения Microsoft того периода (2008-2012) имели высокий темп устаревания. Более устойчивые альтернативы были, в первую очередь в экосистеме Java. Microsoft предлагал сильно связанные, интегрированные фреймворки (WCF + Silverlight + RIA Services). Когда менялась парадигма (например, мир перешел на REST/JSON и мобильные клиенты), весь этот стек быстро становился легаси.
Там даже dip не выполнялся.
Бизнес-логика была вынуждена:
1. Реализовывать "грязные" интерфейсы. Вместо чистого ICustomerService она реализовывала ICustomerService с атрибутами [ServiceContract] и [OperationContract]. Абстракция (интерфейс) стала зависеть от детали (WCF).
2. Использовать "грязные" модели данных. Доменные объекты (Customer, Order) должны были быть помечены как [DataContract], а их свойства — как [DataMember]. То есть, ядро вашего домена зависело от библиотеки для веб-сервисов.
3. Думать о деталях транспорта. Например, обрабатывать специальные исключения FaultException вместо обычных. Логика обработки ошибок становилась привязанной к WCF.
Высокоуровневая бизнес-логика напрямую зависела от низкоуровневой детали — фреймворка для коммуникации. Поменять WCF на что-то другое означало переписывать и контракты, и модели, и реализацию
Ну это я так. О наболевшем
Dhwtj
MS фанател от кодогенерации. Бац и тебе тысяча строк очень хрупкого кода, который не только трудно читать, но и нельзя трогать руками. Сейчас история write only code повторяется с LLM