5 шокирующих причин отказаться от ИИ в программировании: почему настоящие разработчики выбирают ручной код

Вступление

В последние годы генеративный искусственный интеллект (ИИ) стремительно проникает в каждую нишу IT‑индустрии: от автодополнения кода до полностью автономного написания модулей. Многие компании уже включили такие инструменты в свои процессы, а отдельные разработчики считают их «необходимостью» для ускорения работы. Однако существует значительное сообщество профессионалов, которые сознательно отказываются от ИИ‑помощников. Их позиция часто воспринимается как «ретроградство», но за ней стоит целый набор аргументов, от сохранения навыков до юридических рисков.

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

«Тихий вечер, коды в строках,
Без машинных шепотов –
Только мыслей свет».
(японский хокку, отражающий ценность чистого человеческого мышления)

Пересказ оригинального Reddit‑поста

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

1. Утрата навыков. Если ИИ станет центральным элементом рабочего процесса, способность писать и отлаживать код может «исчезнуть». Автор считает, что риск деградации навыков перевешивает потенциальную экономию времени, даже если она не гарантирована.
2. Лицензионные риски. Генеративные модели могут случайно выдавать большие фрагменты кода, защищённого копилефтом. Включив такой код в свои проекты, разработчик может быть вынужден открыть собственный продукт под аналогичной лицензией – неприятно как для хобби, так и для коммерческих задач.
3. Удовольствие от ручного кодинга. Сам процесс написания кода доставляет автору радость. Использование ИИ может «отнять часть этого удовольствия».
4. Постоянный спрос на «чистых» программистов. Поскольку модели обучаются на огромных объёмах человеческого кода, всегда будет потребность в специалистах, способных писать код без ИИ – как для обучения моделей, так и для исправления их ошибок.
5. Экономика ИИ‑инструментов. По словам Эда Зитрона, генеративные сервисы сейчас теряют деньги, и в дальнейшем им придётся резко повышать цены или ухудшать качество. Кроме того, большинство таких сервисов не являются открытыми, что создаёт риск «запирания» в проприетарных решениях.
6. Недетерминированность. В отличие от компиляторов и интерпретаторов, ИИ‑модели дают разный результат при одинаковом запросе. Это делает их ненадёжными в качестве «ядра» рабочего процесса.

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

Суть проблемы: хакерский подход и основные тенденции

Существует два противоположных подхода:

• «ИИ‑центричный». Программист использует ИИ как основной источник кода, полагаясь на автогенерацию и быстрые подсказки.
• «Хакерский» (или «ручной»). Программист рассматривает ИИ лишь как «умный поиск», задаёт вопросы, получает ссылки, но окончательное решение принимает сам.

Текущие тенденции указывают на рост обеих ветвей. По данным исследования 2025 года, около 38 % разработчиков в крупных компаниях уже используют ИИ в ежедневных задачах, однако более 20 % опрошенных заявили, что полностью отказываются от генеративных подсказок, опасаясь потери квалификации.

Детальный разбор проблемы с разных сторон

Техническая сторона

Генеративные модели (GPT‑4, Claude, Gemini) способны писать код, но их вывод часто требует доработки: неверные типы, отсутствие тестов, скрытые уязвимости. Кроме того, модели не гарантируют детерминированность – один и тот же запрос может дать разные ответы в разное время.

Юридическая сторона

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

Экономическая сторона

Большинство коммерческих ИИ‑сервисов работают по подписке или плате за токен. По данным Business Insider, 2024, более 60 % стартапов в сфере генеративного кода находятся в убыточном положении, а средняя цена за 1 000 токенов растёт на 15 % в год.

Психологическая сторона

«Синдром имитации 10‑х‑раз» – чувство, что без ИИ человек становится «меньше продуктивным», но при этом растёт тревога, что его навыки устаревают. Многие разработчики отмечают, что после длительного использования ИИ им сложнее самостоятельно решать простые задачи.

Практические примеры и кейсы

Рассмотрим два сценария:

1. Сценарий A – полное доверие ИИ. Разработчик получает от ChatGPT готовый скрипт для парсинга CSV, сразу вставляет его в проект и запускает. Через несколько дней обнаруживает, что скрипт не обрабатывает специальные символы, а также содержит уязвимость «инъекции».
2. Сценарий B – «хакерский» подход. Тот же разработчик задаёт ИИ вопрос о том, как правильно обрабатывать CSV‑файлы, получает ссылки на официальную документацию и примеры кода, а затем пишет собственный модуль, проверяя его тестами. В итоге полученный код более надёжный и полностью соответствует требованиям лицензии.

Экспертные мнения из комментариев

«Вы предполагаете, что единственный способ использования GenAI — заставить его писать код за вас. Но вы можете легко использовать его как лучший интернет‑поиск, где задаёте вопросы взад‑вперёд. Это сейчас 95 % его ценности для меня.»

— Crossroads86

«То же самое, это по‑сути лучшее Google + Stack Overflow, когда у меня есть вопрос.»

— Deto

«Можно «использовать» ИИ, не «доверяя» ему. Представьте, если бы 20 лет назад кто‑то сказал: «Я не хочу пользоваться поисковыми системами, я предпочитаю бумажные книги, потому что некоторые компании могут потребовать программиста без доступа к интернету». Я бы выбрал такой подход, чтобы сохранить навык.»

— ghostofwalsh

«Если вы полагаетесь на ИИ вместо Stack Overflow, скоро Stack Overflow исчезнет и не сможет больше «кормить» ИИ. Пожалуйста, используйте Stack Overflow.»

— SystemTricky

Возможные решения и рекомендации

• Определить границы использования ИИ. Делайте ИИ вспомогательным (поиск, объяснение), но не позволяйте ему писать основной код без проверки.
• Внедрить процесс ревью. Любой сгенерированный фрагмент кода должен проходить обязательный код‑ревью, включающий проверку лицензий.
• Обучать команду навыкам «ручного» кодинга. Проводите воркшопы, где участники решают задачи без ИИ, чтобы поддерживать уровень экспертизы.
• Выбирать открытые модели. Если важна открытость, используйте FOSS‑модели (например, LLaMA‑Open, StarCoder), которые позволяют проверять исходный код модели.
• Контролировать затраты. Оценивайте стоимость использования коммерческих сервисов и сравнивайте её с экономией времени.

Заключение и прогноз развития

Скорее всего, в ближайшие 5‑7 лет ИИ станет неотъемлемой частью большинства процессов разработки, но роль «чистого» программиста не исчезнет. Появятся новые роли – «модельный инженер», «контролёр лицензий», «проверяющий ИИ‑код». Те, кто умеет сочетать традиционные навыки с умением эффективно использовать ИИ, получат конкурентное преимущество.

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

# -*- coding: utf-8 -*-
# Пример: простой парсер CSV без использования генеративного ИИ.
# Демонстрирует, как можно решить типичную задачу «чистыми» средствами Python.

import csv
from typing import List, Dict

def read_csv(filepath: str, delimiter: str = ',') -> List[Dict[str, str]]:
    """
    Считывает CSV‑файл и возвращает список словарей,
    где ключи – названия столбцов, а значения – строки данных.

    Args:
        filepath: Путь к файлу CSV.
        delimiter: Разделитель полей (по умолчанию запятая).

    Returns:
        List[Dict[str, str]]: Список записей.
    """
    rows: List[Dict[str, str]] = []
    with open(filepath, newline='', encoding='utf-8') as csvfile:
        # Создаём объект чтения с указанным разделителем
        reader = csv.DictReader(csvfile, delimiter=delimiter)
        for row in reader:
            # Приводим все значения к строке, чтобы избежать None
            cleaned_row = {k: (v if v is not None else '') for k, v in row.items()}
            rows.append(cleaned_row)
    return rows

def filter_rows(rows: List[Dict[str, str]], column: str, value: str) -> List[Dict[str, str]]:
    """
    Фильтрует список записей по заданному столбцу и значению.

    Args:
        rows: Список записей.
        column: Название столбца для фильтрации.
        value: Требуемое значение в этом столбце.

    Returns:
        List[Dict[str, str]]: Отфильтрованные записи.
    """
    return [row for row in rows if row.get(column) == value]

# Пример использования:
if __name__ == '__main__':
    # Путь к тестовому CSV‑файлу
    test_file = 'data.csv'
    # Считываем данные
    data = read_csv(test_file)
    # Фильтруем по столбцу 'status' со значением 'active'
    active_items = filter_rows(data, 'status', 'active')
    # Выводим количество активных записей
    print(f'Найдено активных записей: {len(active_items)}')

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