AI не отменил архитектуру. Он превратил разработку в производство
Недавно я довольно долго наблюдал за тем, как 3D-принтер печатает модель, и в какой-то момент поймал себя на мысли, что алгоритм до смешного похож на нормальную разработку софта с ИИ, но только в том случае, если разработкой управляет архитектор, а не человек, который научился писать в чат “сделай красиво” и теперь почему-то считает себя инженером.
3D-принтер ведь не “создаёт объект” в каком-то магическом смысле. Сначала существует модель как абстрактное описание результата. Потом slicer превращает эту модель в последовательность локальных операций, рассчитывает порядок слоёв, траектории, поддержки, заполнение, скорость, температуру, места, где конструкция сама себя держать не сможет. И только после этого довольно тупая, но исключительно дисциплинированная машина начинает материализовывать объект слой за слоем.
С нормальной AI-разработкой происходит примерно то же самое.
Архитектор сначала определяет не код, а геометрию системы: границы модулей, интерфейсы, инварианты, направление потока данных, допустимые зависимости, требования к отказоустойчивости, безопасности, расширяемости и тестируемости. После этого большую конструкцию надо нарезать на такие фрагменты, которые агент способен реализовать локально, не начиная каждый раз заново переосмысливать устройство всей системы.
То есть хороший AI pipeline по своей природе гораздо ближе к slicer, чем к “виртуальному программисту”.
И чем дольше смотришь на 3D-печать, тем смешнее становятся совпадения.
Первый слой, например, критичен непропорционально всему остальному. Если он плохо прилип к столу, дальше можно хоть идеально печатать двадцать часов, результат всё равно рано или поздно оторвётся, поведётся или превратится в клубок пластиковой лапши.
В разработке первый слой называется архитектурным фундаментом.
Если неправильно определены ownership данных, границы модулей, модель домена, способ коммуникации между компонентами или базовые контракты, никакая последующая генерация кода ситуацию не спасает. Можно писать хорошие функции поверх плохой системы, можно закрыть всё тестами, можно бесконечно рефакторить детали, но геометрическая ошибка уже находится в основании конструкции.
Очень похожая история с высотой слоя.
Чем толще слой, тем быстрее печать, но тем ниже разрешение поверхности. В AI-разработке это размер задачи, которую мы отдаём агенту. Чем крупнее кусок, тем быстрее появляется ощущение прогресса, но тем выше вероятность, что модель начнёт самостоятельно достраивать недостающие связи, придумывать контракты, размывать границы ответственности и постепенно превращать систему в нечто внешне работающее, но внутренне лишённое формы.
Вайбкодинг по сути почти всегда печатает слишком толстым слоем.
“Сделай CRM.”
“Добавь биллинг.”
“Прикрути роли.”
“Теперь сделай красиво.”
Каждая такая команда выглядит как движение вперёд, но архитектурное разрешение проекта при этом стремительно падает.
Особенно прекрасная аналогия получается с supports.
В 3D-печати существуют элементы, которые финальному объекту вообще не нужны, но без них некоторые части конструкции невозможно напечатать. После завершения они удаляются.
В софте такими support structures могут быть временные адаптеры, mock-реализации, compatibility layers, миграционные мосты, feature flags, тестовые harnesses, временные API и промежуточные схемы данных.
Плохой инженер воспринимает их как мусор.
Хороший архитектор понимает, что это часть процесса производства.
Но ещё более хороший архитектор сначала проверяет, нельзя ли повернуть модель таким образом, чтобы поддержка вообще не понадобилась.
Именно в этом, кстати, находится огромная разница между архитектурой и бесконечным исправлением последствий. Можно героически строить scaffolding вокруг каждой новой функции, а можно изменить форму системы так, чтобы новая функция естественным образом легла на уже существующую конструкцию.
Infill тоже почти идеально переносится в software engineering.
Внутри 3D-модели вовсе не обязательно заливать весь объём пластиком.
Недавно я довольно долго наблюдал за тем, как 3D-принтер печатает модель, и в какой-то момент поймал себя на мысли, что алгоритм до смешного похож на нормальную разработку софта с ИИ, но только в том случае, если разработкой управляет архитектор, а не человек, который научился писать в чат “сделай красиво” и теперь почему-то считает себя инженером.
3D-принтер ведь не “создаёт объект” в каком-то магическом смысле. Сначала существует модель как абстрактное описание результата. Потом slicer превращает эту модель в последовательность локальных операций, рассчитывает порядок слоёв, траектории, поддержки, заполнение, скорость, температуру, места, где конструкция сама себя держать не сможет. И только после этого довольно тупая, но исключительно дисциплинированная машина начинает материализовывать объект слой за слоем.
С нормальной AI-разработкой происходит примерно то же самое.
Архитектор сначала определяет не код, а геометрию системы: границы модулей, интерфейсы, инварианты, направление потока данных, допустимые зависимости, требования к отказоустойчивости, безопасности, расширяемости и тестируемости. После этого большую конструкцию надо нарезать на такие фрагменты, которые агент способен реализовать локально, не начиная каждый раз заново переосмысливать устройство всей системы.
То есть хороший AI pipeline по своей природе гораздо ближе к slicer, чем к “виртуальному программисту”.
И чем дольше смотришь на 3D-печать, тем смешнее становятся совпадения.
Первый слой, например, критичен непропорционально всему остальному. Если он плохо прилип к столу, дальше можно хоть идеально печатать двадцать часов, результат всё равно рано или поздно оторвётся, поведётся или превратится в клубок пластиковой лапши.
В разработке первый слой называется архитектурным фундаментом.
Если неправильно определены ownership данных, границы модулей, модель домена, способ коммуникации между компонентами или базовые контракты, никакая последующая генерация кода ситуацию не спасает. Можно писать хорошие функции поверх плохой системы, можно закрыть всё тестами, можно бесконечно рефакторить детали, но геометрическая ошибка уже находится в основании конструкции.
Очень похожая история с высотой слоя.
Чем толще слой, тем быстрее печать, но тем ниже разрешение поверхности. В AI-разработке это размер задачи, которую мы отдаём агенту. Чем крупнее кусок, тем быстрее появляется ощущение прогресса, но тем выше вероятность, что модель начнёт самостоятельно достраивать недостающие связи, придумывать контракты, размывать границы ответственности и постепенно превращать систему в нечто внешне работающее, но внутренне лишённое формы.
Вайбкодинг по сути почти всегда печатает слишком толстым слоем.
“Сделай CRM.”
“Добавь биллинг.”
“Прикрути роли.”
“Теперь сделай красиво.”
Каждая такая команда выглядит как движение вперёд, но архитектурное разрешение проекта при этом стремительно падает.
Особенно прекрасная аналогия получается с supports.
В 3D-печати существуют элементы, которые финальному объекту вообще не нужны, но без них некоторые части конструкции невозможно напечатать. После завершения они удаляются.
В софте такими support structures могут быть временные адаптеры, mock-реализации, compatibility layers, миграционные мосты, feature flags, тестовые harnesses, временные API и промежуточные схемы данных.
Плохой инженер воспринимает их как мусор.
Хороший архитектор понимает, что это часть процесса производства.
Но ещё более хороший архитектор сначала проверяет, нельзя ли повернуть модель таким образом, чтобы поддержка вообще не понадобилась.
Именно в этом, кстати, находится огромная разница между архитектурой и бесконечным исправлением последствий. Можно героически строить scaffolding вокруг каждой новой функции, а можно изменить форму системы так, чтобы новая функция естественным образом легла на уже существующую конструкцию.
Infill тоже почти идеально переносится в software engineering.
Внутри 3D-модели вовсе не обязательно заливать весь объём пластиком.