Глава 1. Четыре метафоры программирования: Как наш язык меняет реальность

"Метафора определяет реальность"

🌱 История: Когда я впервые понял, что язык — это всё

Было это в 2024 году, в разговоре с молодым разработчиком. Парень только закончил курсы по программированию, горит энтузиазмом. Я спрашиваю:

— Чем ты занимаешься? — Пишу код.

Обычный ответ, правда? Мы все так говорим. "Пишу код", "writing code", "кодинг".

Но потом он добавил:

— И знаешь, самое странное? ChatGPT пишет код быстрее меня. Может, я выбрал не ту профессию?

И вот тогда меня осенило.

Проблема не в том, что AI пишет код быстрее. Проблема в том, что мы думаем о программировании как о "написании кода".

Если программирование = написание, то ChatGPT действительно лучше. Он пишет быстрее, не устаёт, знает все синтаксисы.

Но что, если программирование — это не написание?

💡 Осознание: Метафоры формируют реальность

Когда я начинал в конце 1980-х, мы не "писали код". Мы кодировали (coding).

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

Потом пришли высокоуровневые языки. Мы стали писать программы (writing code).

Потом — объектно-ориентированное программирование. Мы начали строить системы (building software).

А сейчас? С появлением AI?

Мы выращиваем программы (growing software).

И это не просто красивые слова. Это фундаментальная смена парадигмы.

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

Мы растим программы, где AI самостоятельно:

• Наращивает функционал
• Пишет и тестирует код
• Проверяет работоспособность
• Размещает (деплоит) на хостинге

А мы, как выращиватель:

• Подрезаем лишнее
• Направляем рост
• Выбираем, что именно выращивать
• Курируем процесс

📚 Контекст: Почему метафоры важнее, чем кажется

Может показаться, что это просто слова. "Писать", "строить", "выращивать" — какая разница?

Огромная разница.

Психологи давно выяснили: метафоры определяют, как мы думаем о проблеме.

Пример из жизни:

Если вы думаете о времени как о деньгах ("трачу время", "экономлю время"), вы будете вести себя иначе, чем если думаете о времени как о реке ("течение времени", "плыву по течению").

Что меняется?

• Время = деньги: Вы пытаетесь контролировать каждую минуту. Стресс от того, что время "уходит". Вы боретесь с потоком.

• Время = река: Вы принимаете течение. Учитесь плыть по течению времени, направляя себя. Стресс снижается — вы не можете контролировать реку, но можете направлять движение.

То же с программированием:

• "Пишу код" → фокус на тексте, синтаксисе, строках. Стресс: "Я должен написать каждую строку сам."

• "Строю систему" → фокус на архитектуре, модулях, компонентах. Стресс: "Я должен всё спроектировать и построить."

• "Выращиваю проект" → фокус на эволюции, росте, адаптации. Освобождение: "Я не должен писать каждую строку. Я направляю рост."

Разные метафоры → разные подходы → разные результаты → разный уровень стресса.

Метафора выращивания освобождает миллионы людей от страха программирования.

Раньше думали: "Я не умею программировать, потому что не могу писать код."

Теперь: "Я могу создавать программы, потому что не нужно писать каждую строку. Я могу выращивать."

Это революция.

🛠️ Практика: Четыре метафоры в действии

Давайте пройдёмся по всем четырём метафорам. Не как по истории, а как по инструментам, которые мы используем прямо сейчас.

Потому что — вот что важно — ни одна метафора не исчезла. Они наслаиваются, дополняют друг друга.

Метафора 1: Кодирование (Coding)

Когда: 1950-е — 1970-е (и до сих пор актуально!)

Суть: Программирование = перевод задачи в машинные команды.

Как это выглядело

Представь: 1965 год. Ты сидишь перед стопкой перфокарт.

Каждая карточка — одна инструкция. Дырочки — биты.

Ошибся в одной дырке? Выбрасываешь карточку. Делаешь новую. Вручную.

Fortran punch card from Wikimedia Commons - Public Domain

Эволюция уровней абстракции:

Программирование начиналось с самого низкого уровня — битов:

1. Перфокарты (1890-1950-е): Дырка в карте = 1, нет дырки = 0. Сначала для переписи населения (изобретатель Герман Холлерит, патенты выданы 8 января 1889 года, первое массовое применение — перепись США 1890 года). Затем для программирования компьютеров. IBM карты 80 столбцов с 1928 года.
2. Биты и байты (1948-1956): Клод Шеннон вводит термин "бит" (1948), Вернер Бухгольц в IBM — "байт" (1956).
3. Ассемблер (1947-1949): Первый ассемблер-подобный язык — Kathleen Booth (1947), первый работающий ассемблер — Maurice Wilkes для EDSAC (1949). Мнемоники вместо чисел — MOV, ADD, JMP.
4. Высокоуровневые языки (1960-е - 1970-е): FORTRAN (1957), BASIC (1964), C (1972) — код почти как английский текст.
5. Современные языки (1990-е - 2000-е): Python (1991), JavaScript (1995) — ещё выше уровень абстракции.
6. AI и естественный язык (2020-е): Программирование голосом, описание задачи на русском/английском.

Каждый новый уровень скрывает сложность предыдущего. Сегодня мы можем сказать AI "создай веб-форму для регистрации", и он сгенерирует сотни строк кода. Но внизу, на уровне процессора, всё ещё работают те же биты — единицы и нули.

Пример: Ассемблер

Или чуть позже — ассемблер:

LDA #$05    ; Загрузить 5 в аккумулятор
ADC #$03    ; Прибавить 3
STA $0200   ; Сохранить результат

Что здесь происходит?

Ты кодируешь операцию сложения 5 + 3 в последовательность машинных команд.

Никаких абстракций. Только железо и ты.

Мой опыт: Когда последовательность чисел ожила

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

Мне было лет 10. В руках — программируемый калькулятор.

Не компьютер. Калькулятор. С маленьким экраном и кнопками.

Но он был программируемый.

Я начал экспериментировать.

Вводил последовательность чисел:

15  42  13  7  42  16  2  43  ...

Каждое число — это команда для процессора.

• 15 — загрузить значение
• 42 — сохранить в ячейку памяти
• 13 — извлечь из ячейки
• 7 — сложить
• 43 — вывести на экран

И вдруг меня осенило.

Эта последовательность чисел — живая.

Она не просто числа. Это история. Сценарий. Программа.

Каждое число может быть:

• Командой ("сделай это")
• Значением ("с этим числом")
• Адресом ("в этой ячейке памяти")

Я понял, как работает процессор.

Процессор — это конвейер:

1. Загрузи число (LOAD)
2. Сделай операцию (ADD, SUB, MUL)
3. Сохрани результат (STORE)
4. Повтори

Последовательность чисел становится программой.

Числа:     15  42  13  7  42  16
           ↓   ↓   ↓   ↓   ↓   ↓
Команды:   LD  ST  LD  ADD ST  OUT

Я кодировал мысли в числа. Числа оживали в процессоре. Процессор выполнял мои инструкции.

Это было волшебство.

Для меня тогда было откровением, что:

• Последовательность чисел — это что-то живое
• Программа — это история, рассказанная числами
• Я могу создавать эти истории

ZX Spectrum — следующий уровень кодирования

Позже, когда у меня появился ZX Spectrum (процессор Z80, 48 КБ памяти), я уже понимал, как работает процессор.

Я хотел сделать игру с быстрой графикой. BASIC был слишком медленный.

Поэтому я:

1. Написал на BASIC интерпретатор ассемблера (!)
2. С его помощью писал низкоуровневые процедуры
3. Вызывал их из BASIC

Это была магия. Экран вдруг ожил. Спрайты летали. Музыка играла.

Но почему это работало?

Потому что я кодировал операции на языке железа. Прямо. Без посредников.

И потому что я уже понимал процессор — научился на программируемом калькуляторе.

Когда эта метафора актуальна СЕЙЧАС?

Думаешь, это всё история? Нет.

Примеры сегодня:

1. Embedded-системы (Arduino, ESP32)

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

2. WebAssembly оптимизация

   • Пишешь критичный по скорости код
   • Компилируешь в WASM
   • Иногда вручную оптимизируешь байт-код

3. GPU шейдеры

   • GLSL, HLSL — низкоуровневые языки для видеокарт
   • Каждая инструкция выполняется миллионы раз
   • Кодируешь операции для параллельной обработки

Метафора "кодирования" жива, когда железо важнее абстракций.

Метафора 2: Написание (Writing Code)

Когда: 1970-е — 2000-е (доминирует до сих пор!)

Суть: Программирование = писательский труд.

Как это выглядит

Программист открывает редактор и... пишет.

Строку за строкой. Как автор пишет роман.

Мы говорим:

• "Я пишу программу"
• "Writing code"
• "Чистый код" (Clean Code) — как чистый текст

Пример: Python

def calculate_total_price(items):
    """
    Вычисляет общую стоимость товаров в корзине.

    Args:
        items: список товаров с ценами

    Returns:
        float: общая стоимость
    """
    total = 0
    for item in items:
        total += item.price * item.quantity
    return total

Что здесь происходит?

Мы пишем текст программы. Как статью. Как документ.

• Есть структура (функция, аргументы, возврат)
• Есть стиль (названия, отступы, комментарии)
• Есть читаемость (docstring объясняет, что делает функция)

История: Когда код был текстом на бумаге

Первая олимпиада: программирование без компьютера

Моя первая олимпиада по информатике была без компьютеров.

Представь: ты сидишь за партой. Перед тобой — задача. Листок бумаги. Ручка.

Ты пишешь программу. Вручную. В тетрадке. Как текст. Как сочинение.

Сдаёшь текст жюри. И они читают твой код. Проверяют логику. В голове прокручивают выполнение.

Курьёзный случай на апелляции:

Я правильно решил задачу. Но опечатался — одну букву написал не так в тетрадке.

Жюри снизило баллы.

Я пришел на апелляцию. Доказывал:

• Смотрите, это опечатка, а не логическая ошибка
• Код в целом рабочий
• Если прочитать внимательно, видна правильная логика

И знаешь что? Доказал. Потому что жюри читало мой код как текст.

Компьютерное время — драгоценный ресурс

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

Компьютерный класс. Очередь. 30 минут на всё.

Поэтому я писал программы дома — в тетрадке:

1. Писал программу вручную (как текст в тетради)
2. Проверял логику мысленно (читал код в голове!)
3. Шёл в компьютерный класс
4. Быстро перепечатывал с листа
5. Запускал

Но даже это не гарантировало сохранность.

Программа запускалась. Работала. Но не сохранялась — не было ни дисков, ни перфокарт.

Только временная память компьютера.

В следующий раз — переписывал заново с тетрадки.

6 месяцев написания компилятора на бумаге

Самый долгий проект в моей жизни:

Компилятор с языка программирования на C.

Я писал его несколько месяцев в тетрадке. Черновые исходники. Вручную. Как автор пишет роман.

Потому что компьютерного времени не было.

А идея была. И страсть. И терпение.

И только потом, когда-нибудь, я вводил его в компьютер.

Чему это научило:

Когда ты пишешь код ручкой на бумаге, ты:

• Не можешь запустить и проверить сразу
• Не можешь нажать Ctrl+Z
• Должен писать осмысленно, как текст
• Должен выбирать понятные названия, чтобы самому разобраться
• Держишь логику в голове, но код — это текст для чтения

Это было жестоко. Но это научило меня писать код для людей, а не для машины.

История: Мой первый "чистый" код

Начало 2000-х. Я пишу веб-приложение на PHP.

Код выглядел так:

// ❌ Плохо: Я "кодировал", а не "писал"
function p($i) {
    $t=0;
    for($j=0;$j<count($i);$j++){
        $t+=$i[$j]['p']*$i[$j]['q'];
    }
    return $t;
}

Что не так?

Я думал, что программирование = инструкции для машины.

Короткие названия = быстрее набирать. Меньше памяти (глупость!).

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

p? t? j? Что это?

И тогда я понял:

Код пишется один раз. Читается — сто раз.

Я переписал:

// ✅ Хорошо: Я "пишу" для людей
function calculateCartTotal($items) {
    $total = 0;
    foreach ($items as $item) {
        $itemTotal = $item['price'] * $item['quantity'];
        $total += $itemTotal;
    }
    return $total;
}

Что изменилось?

Я начал писать код для людей, а не для машины.

Машина поймёт любой код. Но люди (включая меня через год) — нет.

Когда эта метафора актуальна СЕЙЧАС?

Всегда.

Метафора "написания" — это основа:

1. Code review

   • Коллеги читают твой код
   • Если он написан плохо → не примут

2. Документация

   • README, комментарии, docstrings
   • Это всё — писательство

3. Команда

   • Код — средство коммуникации между людьми
   • Машина — лишь исполнитель

Но есть проблема.

Метафора "написания" предполагает, что ты пишешь с нуля.

Строка за строкой. Символ за символом.

А что, если можно не писать?

Метафора 3: Строительство (Building Software)

Когда: 1990-е — 2010-е (и сейчас активно используется)

Суть: Программирование = строительство здания.

Как это выглядит

Программист — архитектор и строитель.

Он не просто пишет код. Он:

• Проектирует архитектуру (architecture)
• Создаёт фундамент (foundation)
• Строит модули (building blocks)
• Собирает систему (building the system)

Мы говорим:

• "Building software"
• "Software architecture"
• "Scaffolding" (строительные леса)
• "Tech stack" (технологический стек, как слои здания)

Пример: Микросервисная архитектура

Рисунок: Микросервисная архитектура. Frontend → API Gateway → Сервисы (Users, Auth, Pay, Email) → Database. Каждый сервис — отдельный "кирпичик" в здании приложения.

Что здесь происходит?

Мы строим систему из кирпичиков (сервисов).

Каждый сервис — отдельный модуль. Своя задача. Свой код.

Складываем их вместе → получаем здание (приложение).

История: Мой путь к конструированию — от олимпиад до Unity

Начало 90-х: Олимпиады по программированию

Я понял необходимость строить, а не писать, ещё на олимпиадах по программированию в 90-е годы.

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

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

Моё решение:

Я приезжал на каждую олимпиаду со своей дискеткой.

На дискетке — мои библиотеки, заготовки, кирпичики, блоки.

Как минимум, они помогали строить UI.

Пример: Я сделал свою библиотеку для создания оконных интерфейсов в текстовом режиме (тогда не было графики).

Моя библиотека позволяла максимально быстро:

• Создавать окна
• Делать интерфейсы
• Получать дополнительные баллы за UI (это было важно!)

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

2004-2005: Open Source и готовые решения

Я стал активно изучать большинство существующих open source проектов.

И строить решения для своих клиентов, используя open source.

Я понял:

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

• Собрать
• Дорастить
• Доработать проект для любого клиента

WordPress: Конструирование из плагинов

WordPress привёл меня к настоящему конструированию.

Я мог из блоков (разных плагинов) собрать:

• Работающие интернет-магазины
• Обучающие порталы
• Online школы

Всё из готовых блоков.

Unity Asset Store: Шопоголик строительных блоков

Когда я перешёл на разработку с помощью Unity (Game Engine), меня вдохновил Unity Asset Store — магазин готовых компонентов.

Там продаются (и бесплатно доступны) множество строительных блоков:

• Объекты
• Скрипты
• Свойства
• Компоненты

Несколько лет своей жизни я каждый день заходил в этот магазин.

Я был шопоголиком Unity Asset Store (!).

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

И даже больше:

Какое-то время я публиковал там свои блоки и продавал их другим программистам — как классный инструмент, который ускоряет разработку.

NPM: Шопинг веб-модулей

Также мне очень нравилось искать разные модули NPM для веб-приложений, когда я разрабатывал на Node.js и Vue.js.

Их не нужно было покупать, но:

• Изучать их
• Смотреть, какие есть новые
• Сравнивать варианты

Тот же самый шопинг, кстати, с такими же ощущениями!

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

Сейчас я этого почти не делаю. Я практически уверен, что есть что-то готовое для любой задачи — просто ищу и использую.

А ещё точнее:

Сегодня я прошу coding-агента:

• Посмотреть, какие есть модули
• Разложить их по функциям
• Сравнить по отзывам
• Сравнить по параметрам
• Рекомендовать лучший вариант

И я принимаю решение намного быстрее, чем раньше.

Раньше:

• Лазил по GitHub
• Читал отзывы
• Смотрел статистику
• Сверял исходный код

Сейчас:

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

Потому что есть coding-агент, который умеет:

• Лазать по интернету
• Искать
• Смотреть
• Сравнивать

Это уже не просто конструирование. Это выращивание с помощью AI.

Осознание:

Мы всё дальше уходили от писательства (написания кода) к сборке (конструированию из блоков).

Ускорение времени:

• Кодировать медленнее, чем писать
• Писать медленнее, чем конструировать
• Конструировать медленнее, чем выращивать

Время ускоряется. Это не только в программировании. Это вообще на нашей планете происходит ускорение времени.

И метафора выращивания — это следующий уровень скорости создания программных продуктов.

Когда эта метафора актуальна СЕЙЧАС?

Везде, где система больше одного файла.

Примеры:

1. Микросервисы

   • Строим систему из независимых сервисов
   • Каждый сервис — отдельное здание
   • Docker, Kubernetes — строительные инструменты

2. CI/CD пайплайны

   • "Build pipeline"
   • Собираем проект из частей
   • Тестируем, деплоим

3. Фреймворки

   • React, Angular, Vue
   • Компоненты = кирпичи
   • Приложение = здание из компонентов

Но и тут есть проблема.

Строительство предполагает план. Жёсткую структуру.

А что, если план меняется каждый день?

Метафора 4: Выращивание (Growing Software)

Когда: 2025 → будущее (только сейчас начинается и зарождается!)

Суть: Программирование = садоводство.

Программист-выращиватель в эпоху AI. С помощью AI-агента (светящаяся сфера) программист направляет рост живого дерева-программы. Внутри ствола виден "мозг" — LLM, делающий программу по-настоящему живой. Мы не строим — мы выращиваем.

Почему программы стали "живыми"

Ключевое открытие:

Как только мы начали использовать LLM (языковые модели), мы поняли фундаментальную вещь:

Программы больше не детерминированные.

И это — самое важное изменение в истории программирования.

🎲 Конец эпохи предсказуемости

Раньше (1950-2020):

• Программа = детерминированный алгоритм
• Одинаковый вход → одинаковый выход
• Предсказуемость на 100%
• Точные, чёткие результаты из базы данных
• 2 + 2 → всегда 4
• SELECT * FROM users WHERE id=5 → всегда один и тот же пользователь

Вся история программирования строилась на этом принципе: детерминированность = надёжность.

Сейчас (с LLM):

• Программа = недетерминированная, статистическая, вероятностная система
• Одинаковый вход → разные варианты выхода
• Непредсказуемость — это норма
• Результаты не точные, но осмысленные
• "Напиши функцию сортировки" → каждый раз разный код
• "Объясни квантовую физику" → каждый раз разная формулировка

Это полностью меняет правила игры:

Программы стали по-настоящему живыми.

Как растения, они:

• Реагируют на окружение (контекст)
• Дают разные результаты (вариативность)
• Эволюционируют (обучение)
• Непредсказуемы в деталях, но предсказуемы в целом

Пример из жизни:

Посадите два одинаковых семени яблони:

• В одинаковую почву
• В одинаковых условиях
• С одинаковым уходом

Вырастут разные деревья:

• Разная форма кроны
• Разное количество веток
• Разная высота
• Разные яблоки

Так и с AI-программами:

Дайте одинаковый промпт дважды:

"Создай функцию для валидации email"

Получите разные реализации:

• Вариант 1: с регулярным выражением
• Вариант 2: с библиотекой validator.js
• Вариант 3: с разбором по частям

Все три — правильные. Но разные.

Это расширило наш диапазон понимания.

Мы привыкаем к новой реальности:

• Программы — это живые организмы
• К программированию мы относимся как к выращиванию
• Мы не контролируем каждую деталь, мы направляем рост
• Недетерминированность — это не баг, это фича

Именно LLM и языковые модели позволили нам перейти к новой метафоре.

Как это выглядит

Программист — выращиватель.

Он не строит. Он выращивает.

Разница?

Аналогия из жизни:

Строительство: Ты проектируешь дом. Закладываешь фундамент. Строишь стены. Крышу. Готово. Дом не изменится.

Выращивание: Ты сажаешь дерево. Поливаешь. Ухаживаешь. Обрезаешь ветки. Дерево растёт, меняется, адаптируется.

Программное обеспечение сегодня — это дерево, а не дом.

Пример: Как растёт проект с AI

Раньше (Строительство):

1. Пишешь ТЗ (план здания)
2. Разбиваешь на модули (этажи, комнаты)
3. Кодишь модуль за модулем (строишь)
4. Собираешь всё вместе (здание готово)
5. Деплоишь (заселяешь жильцов)

Сейчас (Выращивание):

1. Описываешь "семя" (идею проекта в промпте)
2. AI генерирует первый прототип (росток)
3. Ты тестируешь, правишь, дополняешь (ухаживаешь)
4. Проект растёт, меняется, адаптируется (ветви)
5. Ты обрезаешь лишнее, добавляешь новое (выращиватель)
6. Никогда не "готово" — всегда эволюция

История: Мой путь от скептика к выращиванию программ

2022-2023: Сначала я не поверил

Когда программисты мне рассказали, что нейросеть может генерировать код, я отнёсся скептически.

Я помню, я даже внутри просмеялся, улыбнулся.

Я сказал: "Ну не знаю, я сомневаюсь."

Как старый зубр, привыкший всё собирать и писать сам, я не верил.

Первые попытки: Текст

Первые тексты — генерация текста для маркетинга — я взял на заметку.

Но тоже с сомнением.

Думал: "Ну, это просто текст. Не программа."

2023: Прозрение через картинки

И вот, когда я увидел, как LLM (Midjourney, Stable Diffusion) генерируют картинки — вот это меня захватило!

Впервые я подумал: "Стоп. Это действительно творческий инструмент!"

Постепенное принятие:

Потом я стал пробовать текст снова. И понял: да, действительно, LLM пишет текст.

Хорошо. Качественно.

Но программирование?

К программированию я пришёл только в 2025 году. Позже, чем другие.

Наблюдая за coding-агентами, я всё ещё сомневался.

Шаг 1: Небольшие скрипты в n8n

Я продолжал конструировать приложения с помощью n8n (no-code конструктор).

И начал генерировать небольшие коды внутри нод (nodes), которые обрабатывают данные.

Это я начал доверять. Это стало работать. Мне это понравилось.

Шаг 2: SQL-запросы

Потом пришёл период, когда мне нужны были сложные SQL-запросы.

Я стал генерировать SQL с помощью LLM.

И меня поразило, насколько лучше пишет LLM SQL-запросы!

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

Точно не я.

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

Шаг 3: Coding-агенты (Claude Code)

И вот финальный этап — CLI coding-агент (Claude Code).

Агент, который:

• Планирует
• Думает
• Реализует
• Проверяет
• Размышляет
• Ищет решения

Когда я с Claude Code начал генерировать — а теперь это называется выращивание приложений — вот тогда у меня произошёл полный инсайт.

Я понял:

Я не пишу код. Я выращиваю решение.

Но это происходило постепенно.

И началось всё с картинок в 2023 году.

Откровение: Когда метафора стала реальностью

Вдохновение от Anthropic

Я услышал выступление одного из ведущих специалистов из Anthropic.

Он сказал то, что меня поразило:

"Мы больше не строим нейросети. Мы их выращиваем.

Да, мы кодим архитектуру. Конструируем инфраструктуру.

Но как работает нейросеть внутри — мы не знаем.

Мы наблюдаем. Мы изучаем, как она это делает.

Мы больше не строим нейросети. Мы их выращиваем."

Это меня зацепило. Именно слово "выращиваем" — оно зазвучало так ярко!

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

Мой личный опыт с AI-агентами

А потом я это испытал на себе — когда начал работать с coding-агентами.

Я запускал агента. Давал ему направление:

• "Добавь эту функцию"
• "Отладь вот здесь"
• "Протестируй это"
• "Измени визуально"

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

И я должен был ждать.

Как выращиватель ждёт, пока прорастёт растение.

Конечно, это было намного быстрее, чем у растений в природе.

Но тем не менее — я ждал.

Выращиватель с тремя проектами

Чтобы оптимизировать процесс (и чтобы не было скучно!), я начал запускать несколько агентов параллельно.

Пока один агент выращивал программу, я запускал второго и делал другой проект.

Я одновременно выращивал две программы.

А сейчас, прямо в этот момент, у меня запущены три агента:

1. Первый — кодит, выращивает программу
2. Второй — исследует документацию, изучает и раскладывает информацию
3. Третий — помогает писать эту книгу

Я за рулём Ferrari

Знаешь, какое ощущение?

Я за рулём Ferrari. Или Lamborghini. Какой-то конской супермашины.

Мой мозг работает на полную.

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

Но агенты успевают ещё быстрее.

Две стороны медали:

1. Ожидание (как у выращивателя)

   • Посадил семя → жди
   • Дал задачу агенту → жди

2. Магия скорости (чего нет в природе)

   • Всё происходит очень быстро
   • Настолько быстро, что...

Новая проблема:

Раньше проблема была: "Как вырастить функцию?"

Сейчас проблема: "Что выросло?"

• Проанализировать, что сделал агент
• Изучить код
• Понять логику
• Одобрить или не одобрить
• Начать использовать

Чудесное новое время.

Мы не строим. Мы выращиваем. И учимся понимать, что выросло.

Когда эта метафора актуальна СЕЙЧАС?

Везде, где используется AI.

Примеры:

1. AI-ассистенты (Copilot, ChatGPT, Claude)

   • Ты не пишешь каждую строку
   • Ты направляешь рост кода

2. No-code/Low-code платформы

   • n8n, Zapier, Bubble
   • Ты собираешь из блоков
   • Система растёт под твои нужды

3. Agile-разработка с AI

   • Спринты → итерации роста
   • Каждый спринт — новая ветка
   • Проект эволюционирует

🎯 Главный инсайт

Все четыре метафоры используются одновременно:

• Кодируешь критичные участки (embedded, шейдеры)
• Пишешь читаемый код (для людей)
• Строишь архитектуру (модули, сервисы)
• Выращиваешь проект (с AI, эволюция)

Но доминирующая метафора меняет профессию:

Сегодня лучшие разработчики — это выращиватели:

• Не пишут каждую строку
• Не строят по жёсткому плану
• Выращивают решения органично
• Используют AI как инструмент
• Адаптируются, эволюционируют

🌟 Мотивация: Почему это важно для тебя

Вернёмся к тому парню, который боялся, что ChatGPT заменит его.

Я сказал ему:

ChatGPT пишет код быстрее тебя. Это правда.

Но ты не должен писать быстрее ChatGPT.

Ты должен выращивать лучше.

Что это значит?

Если ты думаешь, что программирование = написание кода → ты проиграешь AI.

Но если ты понимаешь, что программирование = выращивание решений → ты усиливаешься AI.

Это как в сельском хозяйстве:

Раньше фермер сам копал землю (кодирование). Потом появилась лопата (написание). Потом трактор (строительство). Теперь есть роботы-уборщики (AI).

Фермер не исчез. Он изменился.

Ты — фермер будущего.

AI — твой робот-помощник.

📝 Чек-лист: Применяй метафоры правильно

• Кодируешь → когда нужен полный контроль над железом
• Пишешь → когда код читают люди (всегда!)
• Строишь → когда проектируешь архитектуру
• Выращиваешь → когда используешь AI и эволюцию

Следующая глава

Теперь, когда мы понимаем четыре метафоры, давай посмотрим на мой личный путь:

Как я прошёл через все четыре эпохи — от перфокарт до ChatGPT.

→ Глава 2: Личная история — 1987-2023

Растим проекты осознанно. 🌱