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

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

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

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

Возникает ощущение, будто ты больше архитектор или редактор кода.

И тут появляется вопрос.

Если генерация станет стандартом, кем вообще будет программист?

Тем, кто пишет код?
Тем, кто проверяет код?
Или тем, кто придумывает системы, которые этот код потом генерируют?

Попробую поделиться наблюдениями.

Программирование постепенно превращается в редактирование систем

Сейчас мы привыкли к модели:

человек → пишет код → код работает.

Но когда появляется генерация, процесс становится другим.

человек → описывает задачу → система генерирует код → человек редактирует результат.

То есть разработчик начинает работать на уровень выше.

Если раньше ты писал контроллер руками:

# Python

from fastapi import FastAPI

app = FastAPI()

@app.get("/users/{user_id}")
async def get_user(user_id: int):
    user = await database.fetch_one(
        "SELECT * FROM users WHERE id = :id",
        {"id": user_id}
    )
    
    if not user:
        return {"error": "User not found"}

    return user

то теперь ты скорее опишешь структуру сервиса:

  • нужен endpoint

  • нужна проверка пользователя

  • нужна интеграция с базой

  • нужна обработка ошибок

И генератор сделает остальное.

В какой-то момент я заметил интересную вещь.

Время написания кода почти исчезает.

Но время понимания кода наоборот растёт.

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

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

Самая недооценённая проблема — чтение чужого кода

Если вы когда-нибудь открывали legacy-проект, вы знаете это чувство.

Ты смотришь на файл и думаешь: кто вообще это написал?

А теперь представьте, что код генерируется постоянно.

Каждый разработчик генерирует его по-своему.

Каждая система генерирует его немного иначе.

И в итоге кодовая база становится огромным зоопарком стилей.

Вот пример типичной функции, которую может сгенерировать модель.

// JavaScript (Node.js)

async function processPayment(userId, amount) {

    const user = await db.users.findOne({
        where: { id: userId }
    })

    if (!user) {
        throw new Error("User not found")
    }

    if (user.balance < amount) {
        throw new Error("Insufficient balance")
    }

    const transaction = await db.transactions.create({
        userId: user.id,
        amount: amount,
        status: "pending"
    })

    try {

        await paymentGateway.charge(user.cardToken, amount)

        transaction.status = "completed"
        await transaction.save()

    } catch (err) {

        transaction.status = "failed"
        await transaction.save()

        throw err
    }

    return transaction
}

Код вроде нормальный.

Но через год может появиться другой генератор.

Он будет писать немного иначе.

Через два года — ещё один.

И кодовая база постепенно превращается в смесь разных стилей.

А теперь вопрос к вам.

Как читать проект из 20 миллионов строк, если половину писал человек, а половину — разные генераторы?

Мне кажется, именно здесь появятся новые инструменты.

Не генераторы кода.

А анализаторы кода, написанного ИИ.

Архитектура становится важнее кода

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

Самая сложная часть разработки — это вообще не код.

Это архитектура.

Код можно сгенерировать.

Но архитектуру сгенерировать почти невозможно.

Например, представим простой сервис рекомендаций.

// Go

type RecommendationService struct {
    userRepo UserRepository
    itemRepo ItemRepository
}

func (s *RecommendationService) Recommend(userId int) ([]Item, error) {

    user, err := s.userRepo.GetUser(userId)
    if err != nil {
        return nil, err
    }

    history, err := s.itemRepo.GetUserHistory(userId)
    if err != nil {
        return nil, err
    }

    recommendations := calculateRecommendations(user, history)

    return recommendations, nil
}

Сам код тут не сложный.

Сложно другое.

  • где хранить данные

  • как масштабировать систему

  • как строить pipeline данных

  • как кэшировать результаты

  • как обрабатывать миллионы запросов

Это уже архитектурная задача.

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

Меньше писать код.

Больше проектировать системы.

Дебагинг станет новым искусством

Есть ещё одна интересная проблема.

Баги.

Когда код пишешь сам, ты хотя бы примерно понимаешь, где может быть ошибка.

Но когда код сгенерирован, всё становится страннее.

Ты читаешь функцию и думаешь:

логика вроде правильная… но почему это падает?

А потом находишь какой-нибудь такой кусок.

# Python

def normalize_score(score):

    if score is None:
        return 0

    if score > 100:
        score = 100

    if score < 0:
        score = abs(score)

    return score / 100

На первый взгляд всё нормально.

Но если score = -50, результат будет 0.5.

А должен быть 0.

Такие вещи появляются постоянно.

И чем больше генерации — тем больше таких багов.

Поэтому debugging становится ключевым навыком.

И вот тут у меня к вам вопрос.

Что сложнее:

написать код или понять, почему код ведёт себя странно?

Мне кажется, второе.

Возможно появится новая профессия

Иногда кажется, что мы движемся к новой роли.

Не совсем программист.

И не совсем архитектор.

Скорее что-то вроде инженера генерации кода.

Человек, который:

  • проектирует структуру системы

  • описывает требования генератору

  • проверяет результат

  • оптимизирует архитектуру

Похоже на то, как появились DevOps-инженеры.

Раньше их просто не существовало.

Теперь это отдельная специализация.

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

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

Итог

Мне кажется, программирование никуда не исчезнет.

Но изменится фокус.

Меньше ручного кода.
Больше архитектуры.
Больше анализа систем.
Больше debugging.

И возможно самая ироничная вещь.

Навык номер один будущего разработчика — это умение читать код.

Даже если его писал не человек.

Кстати, интересно ваше мнение.

Если генерация кода станет стандартом — станет ли программирование проще?

Или наоборот сложнее?