ИИ обучается на существующих данных, как джуниор-разработчик на Stack Overflow, и становится похож на мидла. Но сможет ли он когда-нибудь дорасти до сеньора?

Заголовки вроде «Программисты будут не нужны через пять лет» появляются всё чаще, а модели, такие как ChatGPT и GitHub Copilot, демонстрируют впечатляющие способности в написании кода, однако мы считаем, что никаких серьезных изменений в IT-сфере в ближайшие годы не случится. В этой статье мы предлагаем к обсуждению свои аргументы для такого непопулярного мнения.

Новые инструменты часто описываются как серебряные пули, но на практике такими не оказываются

Эта мысль не нова: в статье «No Silver Bullet» Фредерик Брукс ещё в 1986 году писал о том, что нет технологии, способной радикально ускорить разработку. Он говорил, что «серебряной пули» нет:

  • Нельзя автоматизировать творчество и анализ требований.

  • Даже ИИ не устраняет необходимость понимать задачу.

  • 90% работы — это «некодируемые» аспекты: общение, компромиссы, адаптация к изменениям.

Прошло почти 40 лет, но его выводы остаются актуальными. Творчество ИИ — глючно, так как не удовлетворяет неявным требованиям. Связь с реальностью, необходимая для действительного понимания задачи, отсутствует у всех LLM, поэтому они не могут создавать решения без человека. И, конечно, общение с ИИ не заменяет общение в команде, шеринг общего понимания задачи и решения.

Тем не менее в маркетинговых статьях новому инструменту поются дифирамбы. Почему это происходит? В книге «Человеческий фактор» Том Демарко и Тимоти Листер заявляют так: «Многие руководители готовы согласиться с тем, что сталкиваются больше с человеческим фактором, нежели с техническими сложностями. Однако они редко учитывают это на практике. Они руководят так, будто их главной заботой является именно технология. Они проводят столько времени в размышлениях о самых запутанных и интересных головоломках, которые предстоит решать подчиненным, будто сами собираются делать эту работу, а не руководить коллективом. Они находятся в вечном поиске технологического прибамбаса, который должен автоматизировать часть работы (более подробно об этом эффекте рассказано в главе 6 «Лаетрил»), тогда как направление их деятельности, связанное с человеческим ресурсом, зачастую получает низший приоритет.»

Упомянутый лаетрил — это бесцветный экстракт из абрикосовых косточек. Мошенники в Мексике продают его как лекарство от рака. Разумеется, он ничего не лечит. Но раковые больные находятся в отчаянном положении и готовы поверить на слово. Кажется, что и менеджеры в погоне за производительностью приходят в такое же отчаяние, и становятся подвержены ложным надеждам на технологии. Листер и Демарко собрали целый букет ложных надежд в сфере ИТ и перечислили их в разделе «семь надежд руководителя разработки программного обеспечения». Приведем один из примеров: «Все уже автоматизировано; не пора ли напрочь автоматизировать персонал, разрабатывающий программное обеспечение?» И исследователи отвечают: «Это ещё одна вариация на тему иллюзии высоких технологий — вера в то, что разработчики программ выполняют работу, легко поддающуюся автоматизации. Их основная работа — человеческое взаимодействие, позволяющее преобразовать изложенные пользователями потребности в формальное представление. Кто-то должен делать эту работу независимо от того, какие формы принимает цикл жизни продукта. И вряд ли возможно данную задачу автоматизировать.»

При взгляде снаружи кажется, что люди поглощают данные и выплёвывают файлы: аналитики, менеджеры, архитекторы и разработчики — все занимаются этим. Все эти тексты, схемы и картинки хранятся на компьютере в цифровом формате, так почему бы не автоматизировать перевод из одного формата данных в другой?

От потребностей пользователей — в формальное представление, как это происходит?

Преобразование расплывчатых пожеланий пользователей в работающее ПО — многоэтапный процесс, где на каждом шаге теряется часть информации, но добавляется формальность. Сначала требования просто фиксируют на естественном языке: описывают текущие процессы, боли и желания пользователей. Уже здесь возникает первая проблема — люди не привыкли вербализировать весь контекст, который используют в реальном процессе.

Затем начинается анализ: функциональный (что нужно сделать) перетекает в системный (как это реализовать). На каждом этапе часть нюансов теряется, часть — формализуется. Архитектор, получая эти артефакты, проектирует систему, порождая новые документы — спецификации, файлы конфигурации, скрипты. Здесь проявляется неявное знание, которое нельзя было прямо вывести из изначальных требований. Далее менеджеры создают структуру проекта (задачи в трекерах, дорожные карты), а разработчики пишут код.

В принципе, на каждом этапе современные большие языковые модели могут помогать. Но они могут помогать именно как источники шаблонных решений, не учитывающие всего контекста конкретного проекта. И их решение необходимо проверять специалистам соответствующей квалификации.

Итого: даже с ИИ каждый этап требует экспертов, которые:

  1. Восстанавливают утраченные на предыдущих шагах нюансы,

  2. Добавляют профессиональное суждение,

  3. Проверяют, что формальные артефакты действительно решают изначальную проблему.

Именно поэтому «просто записать требования и нажать на кнопку ИИ» не получится — цепочка преобразований слишком сложна и контекстно-зависима.

Производительность разработки ограничена не скоростью написания кода, а скоростью уточнения требований и проверки гипотез

Многие задачи в IT связаны не столько с написанием кода, сколько с пониманием того, что именно нужно реализовать. Поиск общего видения, обсуждение требований, согласование деталей с заказчиком — всё это занимает больше времени и сил, чем кажется. И именно на этом этапе могут возникать недопонимания, которые приводят к правкам и существенно удорожают проект.

Понимание сложных задач требует значительных ресурсов, поэтому их часто доверяют узкому кругу специалистов: продукт-менеджеру, аналитику и архитектору. Эти эксперты полностью погружаются в контекст, удерживают в голове общую картину и разбивают крупную задачу на четкие подзадачи для разработчиков, дизайнеров и тестировщиков. Такой подход позволяет сохранить целостное видение задачи и избежать искажений при передаче.

Но синтез решения становится возможен благодаря личному опыту специалистов, который выступает контекстом решения задачи. Этот контекст по принципу системного мышления никогда не бывает полностью задокументирован. Поэтому даже если ИИ поможет создать решение, его необходимо будет проверить человеку.

Эволюция поиска решений в разработке программного обеспечения

Раньше процесс решения задач разработчиком выглядел примерно так. Столкнувшись с непонятной проблемой, программист сначала погружался в себя, затем обращался к коллегам, искал ответы через Google, изучал решения на Stack Overflow или читал тематические статьи на Хабре. Это был полностью ручной процесс поиска информации, требующий значительных временных затрат. Найденные решения интегрировались и проверялись, а задача отправлялась в тестирование.

С появлением ИИ-технологий процесс изменился не существенно. Теперь разработчик может напрямую обратиться к ИИ-ассистенту, встроенному в среду разработки или доступному через специальные чаты. Такой помощник мгновенно генерирует возможные решения или объяснения. Однако важно понимать, что ИИ не всегда предоставляет идеальные ответы — иногда код оказывается устаревшим или содержит ошибки, а в случае уникальных проблем (например, багов после обновления системы) ИИ и вовсе может оказаться бесполезным. Как и раньше, предложенные решения необходимо проверять.

Эффективность применения ИИ определяется природой самих задач. Для типовых, уже решенных кем-то проблем, современные инструменты (как традиционные, так и ИИ) работают прекрасно. Но поскольку автоматизированные системы обучаются на существующих данных, они не могут помочь, когда разработчик сталкивается с по-настоящему новой, нестандартной задачей.

При этом важно отметить, что основная сложность современной разработки заключается не столько в написании кода (хотя это остается важной частью работы), сколько в грамотном проектировании архитектуры приложений, эффективной автоматизации бизнес-процессов и создании действительно полезных инструментов, улучшающих жизнь пользователей. Именно эти аспекты требуют глубокого понимания и человеческого подхода, который пока не может быть полностью автоматизирован.

А разве ИИ не может помочь с грамотной архитектурой?

ИИ может помочь и с архитектурой, например, предложить подходящие шаблоны проектирования, набросать базовую структуру для работы с данными, но его решения не смогут учесть всех нюансов. Чтобы создать правильный промпт, вам понадобится провести аналитическую работу по сбору требований, а потом еще одну — по проверке предложенного решения.

В каких задачах ИИ может помочь? В рутинных или стандартных, таких как:

  1. Генерация шаблонных решений
    ИИ хорошо справляется с типовыми сценариями: может предложить стандартную схему микросервисов для e-commerce или типовую клиент-серверную архитектуру. Например, по запросу "спроектируй REST API для трекинга заказов" выдаст вполне работоспособную базовую структуру. Но опытные специалисты и раньше не делали работу с нуля, а брали за пример похожее готовое решение или шаблон.

  2. Анализ требований
    Нейросети умеют вычленять ключевые нефункциональные требования (нагрузка, отказоустойчивость) из ТЗ и подсказывать подходящие паттерны (например, предложить кеширование Redis при частых запросах одних данных).

  3. Выявление противоречий
    Некоторые ИИ (например, Amazon CodeWhisperer) могут находить архитектурные антипаттерны в существующем коде — скажем, избыточную связность модулей.

Для младших разработчиков или тех, кто впервые начинает проект, такие подсказки могут показаться значительными. Но для опытных разработчиков использование ИИ избыточно усложняет процесс: когда ты уже понял задачу от бизнеса и знаешь, как лучше её решать — работать над промптом ИИ, а потом проверять его решение.

Проблема заключается не только в том, что решения ИИ нужно проверять, но и в том, что высокая скорость генерации этих решений подталкивает пользователя к созданию вариантов выбора. Однако анализ и выбор из них может занять длительное время. ИИ не сможет принимать решение в следствие ограничений:

  1. Он не понимает всего контекста бизнеса,

  2. Не может учесть всех ограничений реальной системы,

  3. Не понимает специфики legacy-систем, с которыми нужно интегрироваться.

Это напоминает ситуацию с CAD-системами в строительстве: компьютер рисует идеальные чертежи, но инженер должен понимать, где будет стоять здание и кто в нём будет жить.

Конечно, можно сказать: «пусть он не понимает контекста бизнеса, но ведь можно же загрузить ему этот контекст!» Вроде бы действительно можно, если у вас есть документация, список требований, вы готовы загрузить документы, которые касаются бюджета, и главное — есть человек, который этим займётся.

Ключевые решения всё равно принимает человек, потому что:

  1. Архитектура — это компромисс между техникой, бизнесом и людьми,

  2. 50% работы архитектора — это коммуникация (стейкхолдеры, команда), где ИИ бесполезен,

  3. Настоящие проблемы проявляются только в процессе реализации.

Вот как об этом сказал Питер Друкер: «В интеллектуальном труде задачу нужно сформулировать самому. “Каковы ожидаемые результаты этой работы?” — вот главный вопрос, определяющий эффективность интеллектуального работника. Этот вопрос требует рискованных решений. Обычно на него нет правильного ответа — есть только разные варианты действий. Нужно четко понимать конечный результат, чтобы добиться эффективности при его достижении.»

Почему ИИ не заменит менеджеров проектов

Одно из основных препятствий для замены менеджеров ИИ — вопрос ответственности. Управление проектом подразумевает принятие решений и несение ответственности за результат, что невозможно переложить на инструмент, даже самый совершенный. ИИ может выступать консультантом или автоматизировать рутину, но конечное решение всегда остаётся за человеком — точно так же, как в медицине или юриспруденции.

Что ИИ действительно может сделать:

  • Генерировать стандартные отчёты (хотя эту задачу решали и до появления ИИ);

  • Анализировать объёмную переписку и документацию, делая выжимки;

  • Ускорять работу с wysiwyg-редакторами, например, создавать презентации по кратким описаниям.

Но ключевая проблема не в этом:
Когда ИИ экономит время менеджера, бизнес чаще всего использует это не для улучшения качества управления, а для увеличения нагрузки. Менеджер, который раньше вёл один проект, теперь получает два — и вынужден постоянно переключаться между контекстами. Это приводит к поверхностной работе, ошибкам и выгоранию.

Альтернатива — тратить сэкономленное время на:

  • Глубокую работу с командой (фасилитация, налаживание процессов),

  • Личное развитие и отдых сотрудников.

Однако бизнес редко выбирает этот путь: повышение лояльности команды не выглядит для него достаточным аргументом. В результате ИИ становится не инструментом разгрузки, а способом увеличить нагрузку — и это лишь усугубляет главную проблему управления: необходимость человеческого внимания и ответственности.

ИИ изменит не суть работы менеджера, а лишь её интенсивность. Без пересмотра подходов к организации труда автоматизация приведёт не к освобождению, а к перегрузу — и тем ярче проявит ценность настоящего управления, которое невозможно без человеческого участия.

Два типа задач в технической поддержке и роль ИИ

Теперь поговорим о техподдержке — фронтире, на котором одним из первых были введены чат-боты, и который, по мнению некоторых журналистов, должны быть в скором времени полностью заменены ИИ.

В работе технической поддержки можно выделить два принципиально разных типа задач, каждый из которых требует особого подхода:

1. Стандартные запросы: это коммуникация о полностью известной проблеме или задаче. Для таких рутинных операций полностью определена последовательность действий, и нужная информация имеется в базе данных. Часто, подобную задачу можно решить самостоятельно без обращения в техподдержку.

Примеры:

  • Запрос справочной информации;

  • Диагностическая проверка по скрипту;

  • Ответы на часто задаваемые вопросы.

2. Нестандартные запросы. В этом случае коммуникация ведется о новой, неизвестной задаче, для которой необходимо провести анализ и предложить творческое решение. Эти случаи характеризуются:

  • Отсутствием готового шаблона для решения;

  • Необходимостью анализа контекста;

  • Требованием индивидуального подхода;

  • Возможностью множества вариантов интерпретации.

Примеры:

  • Уникальные или новые баги, не описанные в документации;

  • Запросы на доработку системы;

  • Ситуации, когда клиент не может чётко сформулировать проблему;

  • Необходимость найти обходное решение при ограничениях системы.

Проблема применения ИИ в том, что он не может одновременно анализировать контекст и предлагать творческие решения. Он либо строго следует инструкциям и бесполезен для сложных кейсов, либо «фантазирует», рискуя дать ложный ответ.

Первый уровень поддержки — уже регламентирован

Обычно первый уровень поддержки осуществляют люди-операторы, работающие по шаблонам:

  • У них есть готовые сценарии ответов на типовые вопросы;

  • Они действуют строго по протоколу.

Сейчас в некоторых компаниях их заменяют:
✔ Голосовые роботы (распознают речь и отвечают записанными фразами).
✔ Простые ИИ-помощники (например, чат-боты с предсказуемыми ответами).

Такая автоматизация может ускорять решение простых кейсов, но усложняет коммуникацию для нестандартных запросов. Если вопрос выходит за рамки шаблонов, система не справляется — приходится переключать на человека. Клиент раздражается от того, что вынужден «заново» ждать, пока сотрудник поддержки погрузится в их проблему. Поэтому многие сразу пишут в чат «Позовите человека», не желая тратить время на этап с ИИ-ботом. Хотя чат-боты действительно сокращают затраты компаний, живая поддержка сохраняет лояльность клиентов — что в долгосрочной перспективе может принести больше прибыли, чем экономия на персонале.

Клиенто-ориентированная техподдержка — почему её нельзя поручить ИИ

Инженеры техподдержки, обрабатывающие нестандартные запросы клиентов, не могут быть заменены искусственным интеллектом из-за особенностей своей работы.

Во-первых, такой специалист становится полноценным представителем интересов клиента внутри компании. Он имеет доступ к реальным системам логирования и мониторинга, к базам данных и конфигам, внутренним сервисам компании. Он может инициировать межотдельное взаимодействие, например, обратиться к разработчикам для хотфикса.

Во-вторых, инженер, в отличие от ИИ, несёт финансовую и юридическую ответственность, и так же может принимать решения об эскалации проблемы, привлечении ресурсов и изменения приоритетов обработки. Он предсказывает риски и предпринимает шаги для уменьшения последствий для процессов клиента.

В-третьих, специалист техподдержки адекватно интерпретирует эмоциональные обращения и имеет контекстную экспертизу, учитывающую:

  • Историю взаимоотношений с клиентом;

  • Особые условия контракта;

  • Уникальные доработки системы.

Поэтому клиенто-ориентированная поддержка требует полномочий для действий в реальном мире, способности учитывать скрытый контекст и готовности нести ответственность за решения. Всё это могут только люди.

Автоматизация vs. реальная эффективность: почему ИИ не станет «серебряной пулей» для IT

Когда нам предлагают очередное «революционное» решение — стоит задать простой вопрос: кому на самом деле это упрощает жизнь? Cтремление к автоматизации пронизывает всё общество, и прежде чем предрекать замену разработчиков ИИ, давайте рассмотрим эволюцию розничной торговли — здесь уже произошла «революция автоматизации», результаты которой поучительны:

1. Как работал традиционный магазин (1990-е – 2000-е):
Цепочка поставок: Производитель → Оптовый склад → Склад магазина → Продавец.

  • Роль персонала:

    • Товароведы формировали удобную выкладку,

    • Продавцы знали ассортимент и быстро комплектовали заказы,

    • Кассиры профессионально обслуживали очередь.

  • Клиентский опыт: Покупка 10 товаров занимала 5-7 минут.

2. «Оптимизированный» современный супермаркет:

  • Что изменилось:

    • Клиент сам ищет товары в огромном зале (экономия на товароведах),

    • Самообслуживание на кассах (сокращение штата кассиров).

  • В результате — скрытые издержки:

    • Среднее время покупки выросло до 25-30 минут,

    • Ошибки при самопроверке создают очереди на перепроверку,

    • Потеря персонального сервиса.

3. Парадокс автоматизации:
Магазины преподносят это как удобство, но реальные выгоды получает только бизнес:

  • Снижение затрат на персонал на 40-60%,

  • Увеличение импульсных покупок за счет долгого нахождения клиента в зале,

  • Перенос труда (и ответственности за ошибки) на покупателя

Если провести параллель с IT, то становится видно, то же самое происходит с идеей заменить разработчиков ИИ:

  1. Мнимая эффективность:

    • Да, ИИ генерирует код быстрее человека

    • Но вся нагрузка по проверке, тестированию и доработке ложится на:

      • Менеджеров (которые не являются техническими специалистами),

      • Тестировщиков (чей штат не увеличивают),

      • Пользователей (которые хотят быстрого решения своих задач, а не создавать баг-репорты).

  2. Скрытые затраты:

    • Время на исправление ошибок ИИ часто превышает время ручного написания кода,

    • Потеря экспертизы (как в магазинах исчезли профессиональные продавцы),

    • Рост технического долга из-за неоптимальных решений,

    • Потеря лояльности аудитории.

Поэтому автоматизация должна:
✔ Сохранять профессиональные роли,
✔ Учитывать реальные, а не гипотетические процессы,
✔ Улучшать, а не ухудшать качество результата.

Как показал опыт ритейла, перенос труда на конечного пользователя — это не инновация, а регресс. В IT этот принцип проявляется особенно ярко: сложные системы требуют больше, а не меньше экспертизы.

Заключение

ИИ становится привычной частью рабочих процессов, и это — естественное развитие технологий. Инженерам не стоит воспринимать это как угрозу, скорее как возможность. Новые инструменты позволяют сосредоточиться на сложных задачах, оставить рутину машине и делать работу быстрее и качественнее.

Важно помнить, что ценность интеллектуального труда — в человеке, который принимает решения, умеет работать с неопределённостью и создаёт новое. Именно эти качества определяют хорошего инженера, и именно они остаются вне зоны досягаемости ИИ.

Мы считаем, что каким бы умным не был ИИ, он не сможет брать на себя ответственность. Да и вы навряд ли захотите её отдавать. Проверим? Ответьте на пару вопросов!

Комментарии (81)


  1. ivankudryavtsev
    16.06.2025 16:50

    Довольно странный заголовок "ИИ не изменит IT". ИТ - информационный технологии, ИИ - одна из информационных технологий. Таким образом, Вы как бы говорите: "фетучини не заменят пасту".


    1. Wesha
      16.06.2025 16:50

      Вы как бы говорите: "фетучини не заменят пасту".

      Зубную — точно, а ГОИ — уж тем более!


      1. ivankudryavtsev
        16.06.2025 16:50

        Выделив ГОИ ссылкой, пытаетесь продемонстрировать свое интеллектуальное превосходство перед широкой аудиторией знанием полировочных паст?


        1. RulenBagdasis
          16.06.2025 16:50

          Действительно, что этот гой себе позволяет!


          1. vvzvlad
            16.06.2025 16:50

            Где у краба палочка и где у кита обьектив, все уже знают. Но где у гоя находится паста?


        1. BadNickname
          16.06.2025 16:50

          Гражданин поставил своей целью доказать, что он на Хабре Дартальян, а все вокруг... редиски, скажем так.


        1. Wesha
          16.06.2025 16:50

          Выделив ГОИ ссылкой, пытаетесь продемонстрировать

          этим гоям, что это я сейчас не про них!


    1. ivankudryavtsev
      16.06.2025 16:50

      Блин, я затупил - прости автор дуру грешную. Каюсь и посыпаю голову пеплом: не так прочитал буквы. Все претензиии не обоснованны, совпадения случайны.


    1. ulechka Автор
      16.06.2025 16:50

      Любопытный поинт! Мне казалось, тема достаточно развернута в первой паре абзацев: IT как сфера разработки ПО, а не информационный технологии, как множество.


  1. SeApps
    16.06.2025 16:50

    50% работы архитектора — это коммуникация (стейкхолдеры, команда)

    80, на самом деле


    1. ulechka Автор
      16.06.2025 16:50

      В разных источниках по разному оценивается соотношение разных частей. Мне кажется, это зависит от опыта самого архитектора, процессов и размера команды.


  1. durka
    16.06.2025 16:50

    А я всегда говорил - "про творческую работу" затирают только криворукие программисты, чтобы оправдать, что ничего сделать не могут.


    1. Ilusha
      16.06.2025 16:50

      Думаю, если вы распишите, что такое «творческая работа», то окажется, что у вас другое видение значения этого термина.


      1. GospodinKolhoznik
        16.06.2025 16:50

        Как мне кажется это любая работа, где нет никаких жёстких рамок - каким образом делать работу, в какие сроки и делать ли её вообще или не делать. Чем больше свободы, тем больше творческой составляющей.


        1. awsm_yetti
          16.06.2025 16:50

          Это тогда не работа. Немного наблюдал изнутри работу музыкальных групп, и там таки есть сроки, например записи альбома. Более того, есть планирование, как когда и где выкладывать альбом и рекламные материалы. Отдельный ужас, что приходится ещё считать, на какие деньги это делать, и как эти деньги потом увидеть обратно, желательно с прибылью.

          Даже если откинуть коммерческую часть, то музыканту надо каждый день заниматься часами, постоянно писать новый материал, чтобы не потерять навык, опционально искать референсы для своих композиций и т.д. В общем, без рамок, сроков и обязанностей получится хобби. А если ты хочешь зарабатывать, то пахать придется, причем постоянно.


        1. Ilusha
          16.06.2025 16:50

          Думаю, я отдаленно понимаю вас, но в вашем определении нужно дать значения понятию «рамки» и его степеням: «жесткие рамки».

          Когда писателю выдают «два года на книгу» - это рамки? Они жесткие? А если по одной главе в неделю/месяц, как во времена классиков, которые публиковались в периодических изданиях?

          Для меня «творчество» начинается там, где появляется вариативность решений одной и то же задачи.


          1. durka
            16.06.2025 16:50

            "Для меня «творчество» начинается там, где появляется вариативность решений одной и то же задачи. "
            Работа курьера получается творческая. Ведь пиццу клиенту можно доставить множеством маршрутов и способов.


            1. GospodinKolhoznik
              16.06.2025 16:50

              Но у курьера нет возможности доставить пицу через 2 недели, или не доставить её вообще, потому что не было вдохновления.


            1. Ilusha
              16.06.2025 16:50

              Именно так, да. Возможность применить креативное мышление есть и у дворника. Я к этому и вел.

              Поэтому настоящий вопрос в доле творчества в процессе работы. И тут мы имеем шкалу от «вытачивания детали на станке» до «создания уникального произведения искусства», которым может быть в т.ч. как предмет абстрактного искусства, так и результат инженерной работы.


              1. BadNickname
                16.06.2025 16:50

                вытачивания детали на станке

                Бывает очень разным


                1. Ilusha
                  16.06.2025 16:50

                  Да, это я отметил в последних словах своего коммента :)


            1. sic
              16.06.2025 16:50

              Вариативность мышления есть везде. Для бизнеса это баг, а не фича. Поисследуйте современную музыку, кинематограф, поэзию.


            1. ulechka Автор
              16.06.2025 16:50

              Мне кажется, если курьер подходит к своей работе творчески, то может и доставлять разными способами, и наряжаться, играть роли, как-то по-особенному рассказывать о доставке... Творчество — это как раз привнесение чего-то своего, непостоянного и необязательного.


            1. ManulVRN
              16.06.2025 16:50

              Да, а рабочий-станочник может включить станок левой рукой, а может правой! Тоже творчество.


              1. ulechka Автор
                16.06.2025 16:50

                Как ни странно, есть очень похожий пример в книге Чиксентмихайи «Поток». Там работник на конвейере чтобы сделать свою работу более интересной, постоянно повышал скорость выполнения своей задачи. Придумывал, что он может оптимизировать, собирал статистику, сам себя поощрял за рекорды. Мне кажется, человек всегда найдёт, как сделать свою задачу интереснее, или как сократить расходы времени и сил на неинтересное )


  1. TosterScript
    16.06.2025 16:50

    >Вы хотите, чтобы программу для вас написал ИИ?

    В мире нет ни одной нейросети которая может сама написать хоть что-то, нейросети всегда нужен запрос что бы написать ответ. Так что написание любой программы при помощи нейросетей это всегда совместная работа нейросети и человека (напрямую или опосредованно если выстроен какой-то пайплайн).

    Корректный вопрос был бы "Вы хотите что бы программист при написании программы пользовался нейросетью". И я вам так скажу - подавляющему числу людей плевать как именно программы пишутся, им важно что бы программа выполняла свою задачу, а как она работает и уж тем более как она была написана - это мало кого вообще волнует.


    1. chernish2
      16.06.2025 16:50

      Согласен, уровень бреда ИИ и типичного CodeWTF примерно одинаков.


    1. Megakazbek
      16.06.2025 16:50

      Для написания запроса человек не нужен (кроме самого первого)


      1. TosterScript
        16.06.2025 16:50

        Самого первого, Адама что ли?


        1. DSSilver
          16.06.2025 16:50

          Я слышал у него какие-то проблемы с яблоками. Тут, получается, главное чтобы запрос не касался мобильной разработки


    1. ulechka Автор
      16.06.2025 16:50

      Не могу согласиться, что людям нравится быть тестировщиками. В какой-то момент пользователи активно отказывались от виндоус, которую постоянно надо было перезапускать и переустанавливать в пользу макоси, которая просто работала.


      1. TosterScript
        16.06.2025 16:50

        Ну вот именно что юзерам плевать как виндоуз был написан, мясными программистами или нет, если программа плохо работает они не будут ей пользоваться. Как и кем программа была написана их при этом вообще не волнует.

        Это программистов волнуют вопросы того какие фреймворки юзать, какие языки, какие нейросети, какие паттерны, конечным юзерам это все до лампочки.


      1. Vedomir
        16.06.2025 16:50

        Наверное это было очень давно, потому что начиная с 7 система живет до отказа железа. Ну и учитывая, что доля маков 9%, не очень-то и многие отказались.


    1. IamFromUSSR
      16.06.2025 16:50

      А программисту не надо говорить/описывать задачу, которую он должен выполнить?


      1. TosterScript
        16.06.2025 16:50

        Программист может сжать волю в кулак и сам себе задачу поставить, ему не нужен промт что бы начать писать код.


        1. IamFromUSSR
          16.06.2025 16:50

          Устроился на работу и начинаешь писать задачу, что в голову пришла. Хочу на такую )

          P.S. но, в любом случае, тебе минимум дают документация, существующий код, вводя в курс дела. Чем это не промт для кожанного мешка?

          Дают тебе таску с доступом к коду или техническое задание. Все это же можно скормить не человеку, а ИИ. Да, еще не тот уровень, что он может сделать хотя бы так же как человек, но всего 3-4 года назад мысли о подобных разговорах даже не было ... Вообще, я к тому, что человеку(наемному работнику), что ИИ - все равно надо поставить задачу. А назови ее таском, ТЗ или промтом, суть не меняется.


          1. TosterScript
            16.06.2025 16:50

            Программисты не обязательно работают на кого-то, они еще свои проекты пишут, или создают стартапы, или делают свои опенсорсные проекты.


            1. IamFromUSSR
              16.06.2025 16:50

              Данная статья больше о наемных работниках и что их заменят.... И да, ни кто не отрицает, что сейчас нет искуственного интелекта в полном понимании этого слова, а всего навсего LLM.


  1. olku
    16.06.2025 16:50

    Уже поменял, сдвинув фокус человека с кодинга на проектирование. Инструменты прошли стадию чат ботов в Task master и MCP.


  1. AuToMaton
    16.06.2025 16:50

    Преобразование расплывчатых пожеланий пользователей в работающее ПО — многоэтапный процесс, где на каждом шаге теряется часть информации, но добавляется формальность. 

    Это сразу сомнительно. Ребята типа Форда и Джобса объясняли - не надо слушать «расплывчатых пожеланий» ибо люди не знают чего хотят.

    • Потеря экспертизы (как в магазинах исчезли профессиональные продавцы),

    И что? Значит, не так ценна экспертиза как её малюют.

    Я, кажется, а может и не я, уже писал на Хабре, а может не на Хабре, как это формулировалось в старое время:

    Задача программиста состоит в изучении предметной области и записи результатов в виде, понятном как человеку, так и машине.

    С этой точки зрения, ИИ программиста не заменит. Но! Без и до всякого ИИ, программирование, и не только, успешно деградировало. Как пример - то, что они называют boilerplate и приводят написание такового как доказательство полезности ИИ. Извините, если boilerplate существует, то, опять же по нормам старого времени, все эти ваши фреймворки и новомодные технологии реализованы грубо ошибочно. И чем больше ИИ - тем больше будет ошибок и тем грубее будут ошибки. Ожидаемый (мной) результат - программирование, особенно индустриальное которое, видимо, и явилось первоисточником говнокода, станет невозможным без использования ИИ, а использование ИИ, соответственно, повсеместным и вынужденным. Если это не «заменит», то заменит - это как?

    Над этим размышляли, даже сформулировали термин «стрела Аримана»… В своё (старое) время был популярен принцип:

    Люди высшего сорта окружают себя людьми высшего сорта, а люди первого сорта - людьми второго сорта.

    Как обобщение - Человечество преимущественно состоит из посредственностей и, как следствие, тяготеет к посредственности. На средних и длинных временах результат неотличим как от деградации, так и от инволюции.

    Когда-то, естественное стремление помахать мечом или потыкать копьём оказывало компенсаторное воздействие. Иногда даже случалась гиперкомпенсация. Но и тогда всё было не безоблачно - самураи, например, погибали преимущественно от стрел. А потом изобрёлся пулемёт и стало печально, а далее и атомное оружие - с ним число возможных дорог сократилось до двух и обе печальны.

    Подведём итоги. Как у нас дела с живой оркестровой музыкой? Просто с хорошим звуком? Как развивается японская анимация? Уж не так же ли, как когда-то развивалось кажущееся мне равновеликим другое явление - Серебряный Век? И далее везде…

    Да, у ИИ не будет получаться такой же хороший код, как у вменяемого человека. Но вменяемых людей будет мало, а и такому коду будут радоваться. Кроме того - использование ИИ прекрасно освобождает от ответственности (мало статей о том как протолкнуть резюме через фильтры? Не боись, будет больше). И отличный способ скрыть факт манипуляции.

    ИИ банзай, короче.


    1. ugenk
      16.06.2025 16:50

      >Но вменяемых людей будет мало

      вы так говорите, что может показаться что их сейчас много :)


      1. pavelsha
        16.06.2025 16:50

        >Но вменяемых людей будет мало

        вы так говорите, что может показаться что их сейчас много :)

        "Настоящих буйных мало —Вот и нету вожаков." (В. Высоцкий. "Письмо в редакцию.. ")


    1. Wesha
      16.06.2025 16:50

      Да, у ИИ не будет получаться такой же хороший код, как у вменяемого человека. Но вменяемых людей будет мало,

      и все они будут хакерами (ломать то, что написано ИИ).


    1. PeterFukuyama
      16.06.2025 16:50

      Уж не так же ли, как когда-то развивалось кажущееся мне равновеликим другое явление - Серебряный Век?

      Серебряный век был не так уж и велик. Сейчас кажется, что тогда был расцвет творчества, один шедевр сменял другой — но это иллюзия. На самом деле мы видим лишь лучшее из того, что сохранилось, и забываем про массу посредственностей. Качество текстов росло с каждым этапом технического прогресса — от изобретения печатной машинки до появления текстовых редакторов. Плюс, конечно, скзалось уменьшение потребления кокаина. Впрочем, другая проблема — авторам просто не остаётся ничего интересного сказать... Талантливые люди в другие сферы ушли.


    1. ulechka Автор
      16.06.2025 16:50

      Форд конечно придумал замену коню, но полезная функция в надсистеме сохранилась (перевозки людей и грузов). Джобс вообще заменил удовлетворение потребности — навязыванием потребности, я б не стала равнять их в ряд. А общая деградация — это следствие закона гудхарта в капиталистической экономике: «Когда меру превращают в цель, она перестаёт быть хорошей мерой» (Чарльз Гудхарт, экономист, 1975 год). Если бизнес работает для максимизации прибыль, качество страдает. Если учитывать ценность качества, например, через лояльность клиентов и сотрудников, то ИИ не нужен.


      1. vvbob
        16.06.2025 16:50

        Форд не придумал автомобиль (замену коню), даже конвейер и то не он придумал, хотя ему это изобретение приписывают.

        Форд сумел применить конвейер к производству специально разработанного для конвейера автомобиля. Это и было прорывом, он соединил вместе то что раньше не соединяли, и сумел все это заставить вместе работать, что и было основной сложностью.


      1. Vedomir
        16.06.2025 16:50

        >Джобс вообще заменил удовлетворение потребности — навязыванием потребности

        Откровенно странное утверждение


        1. gonzazoid
          16.06.2025 16:50

          Которое по сути принадледит самому Джобсу. Достаточно вспомнить отказ от внешних носителей с затягиваниеи пользователей в облако и связанную с этим риторику.


          1. Vedomir
            16.06.2025 16:50

            А конкретные цитаты можно?

            Вот например у Форда есть цитата "Если бы я спросил у покупателей, что им нужно, они ответили бы: более быстрая лошадь" это уже навязывание потребностей или еще нет. Вы же пишите что у Форда такого не было, а у Джобса в отличие от него было.

            > отказ от внешних носителей с затягиваниеи пользователей в облако

            Я вот идеологию яблочных устройств оценил только после того как потратил почти неделю безуспешно пытаясь научить пожилую тетушку пользоваться компьютером на Windows. Она так и не смогла понять концепции папки, файла, логического диска и не смогла освоить такую операцию как сохранить из письма файл с книжкой и загрузить по USB на читалку.

            Если человек исключительно внутри айти сферы крутится, ему это непонятно, для этого надо пообщаться с далекими от нее людьми.


            1. gonzazoid
              16.06.2025 16:50

              Вы же пишите что у Форда такого не было, а у Джобса в отличие от него было.

              Давайте мы с Вами продолжим разговор после того как Вы покажете где я такое говорил.


              1. Vedomir
                16.06.2025 16:50

                Не заметил, что отвечает не автор того комментария, на который я отвечал. Впрочем все остальные пункты остаются в силе.


                1. gonzazoid
                  16.06.2025 16:50

                  It's not the customer's job to know what they want


  1. sic
    16.06.2025 16:50

    Я не понимаю, зачем пытаться тысячу раз обсуждать, что "автомобиль не заменит конную повозку". Вот сейчас нет, ибо иначе уже бы заменил. Вот потом, - когда заменит, тогда и поговорим (о чем?).

    Красоту раннего мира развития и популяризации области ИТ уже никогда и никто не вернёт.


    1. Wesha
      16.06.2025 16:50

      Вот потом, — когда заменит, тогда и поговорим

      «Жаль только — жить в эту пору прекрасную
      Уж ни придётся: ни мне, ни тебе...» ©


      1. sic
        16.06.2025 16:50

        Ну я то поживу. Любил очень в детстве на велосипеде кататься.


  1. RedHead
    16.06.2025 16:50

    IT меняет саму природу потребления. Все больше товаров становится виртуальными: скины, цифровые услуги, NFT, эмоции по подписке. Зумеры уже не стремятся покупать квартиры и автомобили — им важнее свобода, мобильность и доступ к цифровому контенту. Раньше крутость измерялась 600-м «Мерседесом» у подъезда, сегодня — ножом Karambit | Doppler Sapphire в инвентаре CS2. Символы статуса сместились из физического мира в виртуальный.


    1. pavelsha
      16.06.2025 16:50

      Если смотреть в общем, то глобально ничего не поменялось. Лишь цвет и формы бирюлек другими стали... Я думаю, что, обсуждая особенности поколений, стоит помнить следующее:

      • Сейчас Зуммеры, через 10 лет будут Альфы, потом Бэтты...

      Определенные особенности, конечно, есть, но, пожалуй, тут уместно процитировать Николая Карамзина:

      Умы людей ослеплены.

      Что предков наших обольщало,

      Тем самым мы обольщены;

      Ученье их для нас пропало,

      И наше также пропадет —

      Потомков та же участь ждет.

      Ничто не ново под луною:

      Что есть, то было, будет ввек.

      И прежде кровь лилась рекою,

      И прежде плакал человек,

      И прежде был он жертвой рока,

      Надежды, слабости, порока.


    1. Ilya_JOATMON
      16.06.2025 16:50

      Это справедливо только для кучки гиков. Остальные покрутят пальцем у виска, глядя на цены виртуальных предметов.


      1. karmael
        16.06.2025 16:50

        скорее мамка выпорет


      1. RedHead
        16.06.2025 16:50

        Также как сейчас покрутят у виска глядя на:

        Золотые зубы
        Меховые шубы
        Фарфоровый сервиз
        Ковер на стене

        и т.д. Если ты реже бываешь оффлайн, значит тебе меньше нужны статусные маркеры из оффлайна. Это очевидно.

        Это одиночество 21 века. Суть его в том, что у людей нет единого поля прошлого. Нет доказательства присутствия друг для друга. Раньше все смотрели одно и то же и читали одно и то же. А сейчас у всех свои любимые каналы в ютубе, инстаграме, телеграме, тиктоке и лидеры мнений. Поэтому просто не о чем общаться людям в условном оффлайне. Шанс совпадения 0.000001%. Они находятся в разных представлениях.


    1. RS6
      16.06.2025 16:50

      Не стремятся покупать квартиры и автомобили или не могут себе позволить, и то что мы наблюдаем это типичный "зелен виноград"? Судить по рынку РФ традиционно сложно из-за его чрезвычайной волатильности на больших интервалах, но на более устойчивых и зрелых рунках типа США есть вполне добротная статистика по доступности жилья. И эта доступность сейчас на абсолютных минимумах за весь период наблюдений после Второй Мировой. Купить жильё стало радикально сложнее, чем 60 или 40 лет назад. На некоторых рынках типа Канады или Австралии ситуация гораздо хуже и близка к катастрофической. Стоит ли удивляться, что люди "отпускают ситуацию" и предпочитают покупать то, на что у них есть деньги: еду и виртуальные плюшки? Я вот почему-то уверен, что будь у людей реальный выбор "купить жильё или накупить скинов в любимой игрушке", решение было бы, мягко говоря, предсказуемо.


  1. gonzazoid
    16.06.2025 16:50

    Все гораздо проще. Берем алгоритм реализации которого в открытом доступе нет и просим генератор бреда сгенерить код этот алгоритм реализующий. Я бы вот с удовольствием взглянул бы на промпт генерящий реализацию сравнения двух pushdown automatons. Тупо проверку на эквивалентность. Papers на эту тему хватает, есть что скормить AI.


    1. OlegZH
      16.06.2025 16:50

      >> pushdown automatons

      Извините, нераспознанный токен. ;-(


      1. Rigidus
        16.06.2025 16:50

        Конечный Автомат с магазинной памятью


    1. OlegZH
      16.06.2025 16:50

      Полагаю, что для ИИ это будут семечки.


      1. gonzazoid
        16.06.2025 16:50

        Взглянуть бы на такой ИИ


    1. lehshik
      16.06.2025 16:50

      зачем нужен нестандартный алгоритм, пусть использует стандартные


      1. gonzazoid
        16.06.2025 16:50

        А в чем нестандартность то?


    1. ulechka Автор
      16.06.2025 16:50

      У вас можно увидеть несколько подтем: на чём учат ИИ -- тут есть с одной стороны политические ограничения, с другой стороны нарушение авторских прав при использовании художественной и научной литературы. Отдельные системы обучаются специально на научных корпусах, но не факт что уже есть системы, обученные и на кодовой базе типа гитхаба и на научных данных типа Computer Science.

      Месье, а зачем вы хотите на это взглянуть?


      1. gonzazoid
        16.06.2025 16:50

        Не что бы я жажду взглянуть, просто такой код был бы показателем того что нейросети научили моделировать, чего пока и близко нет. На данный момент это ОЧЕНЬ навороченный агрегатор и поисковик, добавить туда пруфы на каждое утверждение и он действительно поменяет многое. Но на программирование ему пока что рановато замахиваться.


        1. ulechka Автор
          16.06.2025 16:50

          Мне кажется, программистам легко судить о качестве ИИ для программирования. Журналистам легко судить о качестве ИИ для журналистики. Эпистемологи должны бы дисквалифицировать ИИ как ученого, но вместо этого Юдковский пророчит конец света от ИИ. Может, в смысле электричества.


          1. Wesha
            16.06.2025 16:50

            Эпистемологи должны бы дисквалифицировать ИИ как ученого, но вместо этого Юдковский пророчит конец света от ИИ.

            Эффект Даннинга — Крюгера во всей красе.


            1. ulechka Автор
              16.06.2025 16:50

              Знание об эффекте Данинга-Крюгера должно использоваться в первую очередь для того, чтобы усомниться в собственном мнении, а вовсе не для того, чтобы считать других недостаточно компетентными.

              Мы же специально предложили своё мнение к обсуждению и привели свои аргументы. У вас есть возражения по существу статьи?


              1. Wesha
                16.06.2025 16:50

                Знание об эффекте Данинга-Крюгера должно использоваться в первую очередь для того, чтобы усомниться в собственном мнении,

                А чего в нём сомневаться? Я прекрасно знаю, что я ничего не знаю! И именно поэтому имею полное право взарживать над теми, кто считает, что уж он-то знаёт всё.


  1. Fedorkov
    16.06.2025 16:50

    ИИ не изменит IT

    Никогда? Ни через десять лет, ни через сто, ни через тысячу?

    Первый закон Кларка: «когда уважаемый, но пожилой учёный утверждает, что что‑то возможно, то он почти наверняка прав. Когда он утверждает, что что‑то невозможно, — он, весьма вероятно, ошибается».


  1. OlegZH
    16.06.2025 16:50

    ИИ обучается на существующих данных, как джуниор-разработчик на Stack Overflow, и становится похож на мидла. 

    То есть, нам хотят сказать, что типичный мид(д)л — это натасканный на ответы джуниор? Другими словами, нам хотят сказать, что действительная квалификация мид(д)лов ниже заявляемой? Значит, реальный уровень индустрии невысок, раз ИИ способен его воспроизводить. И, значит, само деление на джуниоров и мид(д)лов весьма условное.

    Да, есть начинающие, у которых ещё нет полноценного опыта применения технологий, но которые знают о существовании инструментов, и, даже, умеют ими пользоваться. А есть уже продвинутые, которые уже имеют реальный опыт.

    Другая сторона того же вопроса. Если ИИ становится похож на мидла (примем, таки. эту спорную гипотезу), то не значит ли это, что мы сможем любого джуниора поднимать до мид(л)ла? Чем же тогда занимаются в компаниях? Теряют время? Сделайте, пожалуйста, всех джуниоров мид(д)лами, а на место джуниоров пригласите новых людей. Вы обеспечите постоянный приток рабочей силы и её высокое качество.


  1. OlegZH
    16.06.2025 16:50

    Но сможет ли он когда-нибудь дорасти до сеньора?

    Опять же. У этого вопроса есть две оборотные стороны.

    С одной стороны, это (то, что сможет однажды дорасти) означает, что можно формализовать и довольно сложные вопросы, но это же значит и то, что упомянутые сеньоры сами не вполне сеньоры, поскольку выдают не оптимальные решения, также требующие доработки, как и результат работы ИИ. Появление ИИ, в этом плане, подобно шахматным программам: когда те превзошли человека, появилась возможность объективно оценивать все позиции. Будут трудно мириться с низкой оценкой производительности человеческих программистов.

    С другой стороны, появление ИИ исказит и так искажённую иерархию программистских ценностей. Появятся новые сеньоры, но уже некому будет проверить их квалификацию.

    Всё это не означает, что всеобщая автоматизация невозможна. Но для того, чтобы достичь этой самой всеобщей автоматизации, нужно обсуждать реальные вычислительные модели: какие вычислительные модели выдаёт ИИ, как они обобщают предшествующий опыт, как хранить и обрабатывать данные. Вот сущностные вопросы. А эти вопросы, как раз, и не обсуждаются. Так о чём же речь?

    Какой во всём этом, вообще смысл? Программисты до сих пор не могут сделать так, чтобы в ОС был один-единственный торговый модуль (с интерфейсом, функционирование которого полностью определяется пользователем, а не случайным разработчиком), который можно было подключать к различным торговым точкам и производить торговые операции, накапливать финансовую информацию (включая и протоколы и отчёты). Сейчас для каждой торговой точки пишется свой интернет-магазин. А что надо? Надо, чтобы каждая торговая точка выставляла свои данные по выделенному протоколу, а каждый клиент мог бы использовать этот протокол. Неужели нужен ИИ, чтобы всё это разработать?!? Но если окажется, что это всё можно разработать, то получиться, что практически вся ИТ-индустрия занята в решении не нужных задач, и нужную задачу (всеобщую автоматизацию) некто не решает.


    1. Parafinwe
      16.06.2025 16:50

      Yandex Market Language уже делает это например


    1. sic
      16.06.2025 16:50

      что упомянутые сеньоры сами не вполне сеньоры, поскольку выдают не оптимальные решения, также требующие доработки

      Абсолютно верно пишете. Всю жизнь работал именно с такими сеньорами. Потом когда сам сеньором стал, писал, пожалуй худший код в своей жизни. Гейткипинг сам себя не обеспечит.


    1. ulechka Автор
      16.06.2025 16:50

      Я думаю, всеобщая автоматизация до сих пор не реализована потому что настолько универсальная система будет настолько большой, что её поддержка станет неподъёмной. Вы думаете, ИИ сделает такую систему и будет поддерживать? Имхо, если она и будет создана, то вычислительных мощностей не хватит её поддерживать.

      Уже не раз создавались универсальные и расширяемые системы, которые обрастали таким количеством плагинов, что потом находился кто-то, нежелающий разбираться в старом, огромном и неудобном, и делал новый маленький модуль. Который потом для универсализации обрастал своими модулями и патчами. Вспомните хотя бы линуксовые интерфейсы.


      1. OlegZH
        16.06.2025 16:50

        Вы совершаете принципиальную ошибку. Если всеобщая автоматизация возможна, то она не потребует существенной поддержки. А Вы всё меряете привычными себе стереотипами.

        В математике есть понятие ортогонализации. Любой процесс можно представить в виде произведения двух матриц: в одной матрице лежат данные, в другой матрице лежат методы обработки. Ортогонализация приводит к тому, что всё практически сводится к сумме произведений диагональных элементов.