README.md (ЗАЧЕМ) + CODE_GUIDE.md (КАК ИСПОЛЬЗОВАТЬ) + Код (КАК РЕАЛИЗОВАНО) = Полный контекст v2
CODE_GUIDE.md (или ARCHITECTURE.md)
Это один дополнительный файл в корне проекта. Не папка, не сложная структура, а просто один документ.
Его цель: Быть тем самым связующим звеном между бизнес-логикой из README и кодом. Он отвечает на вопросы "Как?" и "Почему?" на более высоком уровне, чем комментарии в коде.
Для технических деталей (паттерны, стандарты кодирования) лучшим источником является сам код. Хорошо написанный, самодокументированный код с комментариями в нужных местах часто лучше любого отдельного гайда.
Вместо десятка .md файлов (tech_stack.md, patterns/, guides/, workflows/) у меня есть один мощный README.md для бизнес-контекста и сам код для технического. Этого более чем достаточно для большинства проектов.
README.md (бизнес-логика, флоу) + Код (реализация, техдетали) = Полный контекст.
Вы описываете процесс, который был актуален до появления LLM. Ваша главная ошибка — вы всё ещё разделяете «формализацию» и «код».
Настоящая профанация — это потратить месяцы на «полную формализацию», чтобы в итоге получить идеальный код для никому не нужной идеи.
Мы же формализуем идею через код. Мы показываем заказчику не «что-то непохожее», а работающий прототип через час после разговора. И уточняем идею, глядя на него, а не на стопки бумаги. Это не «отсутствие процесса», это просто процесс, который работает на порядок быстрее вашего.
Идеи Sakana AI и xAI — это очевидный следующий шаг. Но их подходы (TreeQuest, Grok4 Heavy) — это, по сути, "черные ящики", которые автоматически синтезируют один "лучший" ответ, исключая из процесса самый важный элемент — человека.
Я сейчас экспериментирую с другой парадигмой: представьте себе групповой чат, где вы в роли модератора общаетесь сразу с несколькими топовыми моделями (Claude, GPT, Gemini, Grok), каждой из которых дана своя уникальная роль. Вы вкидываете идею, сталкиваете их мнения, создаете "продуктивное трение", управляете дискуссией и, опираясь на свою интуицию и связь с реальностью, синтезируете финальное решение.
Таким образом, мы получаем не просто "улучшенный" ответ от ИИ, а синергию коллективного интеллекта нейросетей и человеческой интуиции. Это уже не просто "две головы лучше одной". Это симбиоз человеческого опыта и многоголового машинного интеллекта — вот где, мне кажется, настоящая магия.
Человек как равноправный участник, но с правами модератора
Каждая модель имеет уникальную роль (системные промпты / настройки)
Модели взаимодействуют друг с другом и человеком, видя контекст
Интерфейс — естественный групповой чат
Цель — синергия и поиск новых решений, а не просто усреднение или выбор лучшего ответа
Интуиция, опыт и человеческое понимание контекста направляют коллективный машинный интеллект
Пытаться выстроить вокруг ИИ формальную структуру сейчас — это попытка залить бетоном фундамент на тектоническом разломе. Любой "узаконенный" процесс устареет еще до того, как мы его внедрим.
Ценность смещается от следования процессу к умению его ломать и пересобирать на лету с помощью новых технологий.
Интересный взгляд на "идеальный" процесс. На деле же, пока будет писаться ТЗ, рисоваться дизайн и настраиваться CI/CD, проект может стать неактуальным.
Статья отвечает на вопрос "как правильно строить процесс", но не на главный вопрос бизнеса: "как максимально быстро проверить гипотезу и начать получать пользу?".
Бизнесы ориентированы на максимизацию доходов, а не на благополучие пользователей или сотрудников. Бизнесу выгодно держать пользователей и сотрудников в состоянии постоянной активности, а не осознанности. Неосознанный пользователь — это идеальный потребитель.
UI‑анимация — не про код, а про ощущения. Стандартный AnimationController убивает желание творить. Пока пишешь весь этот бойлерплейт — теряешь фокус на самом ощущении движения.
Именно поэтому есть такие инструменты, как flutter_animate от gskinner, чтобы в пару строк экспериментировать с таймингами, изингами и настроением.
Как же тогда вы определяете успешность моделирования? По каким критериям можно сказать, что ваш протокол действительно моделирует сознание, а не просто улучшает качество ответов?
Для создания целостного опыта нужна возможность влиять на все слои от бэка до фронта - без этого никуда, таков путь.
Часть 3: ИИ заменяет всю вашу контору, кроме кофе-машины.
Круто, что Surf наконец-то дошёл до ИИ.
Ребята решили прокатиться на хайпе. Регистрируюсь, чтобы потроллить вживую!
Статья — 90% самолюбования и 10% очевидных идей, которые можно уместить в твит.
Самый полезный совет дает сам Claude Code в подсказках:
Относись к нему как к опытному мидлу в команде — давай контекст, будь конкретен, проверяй результат.
README.md (ЗАЧЕМ) + CODE_GUIDE.md (КАК ИСПОЛЬЗОВАТЬ) + Код (КАК РЕАЛИЗОВАНО) = Полный контекст v2
CODE_GUIDE.md (или ARCHITECTURE.md)
Это один дополнительный файл в корне проекта. Не папка, не сложная структура, а просто один документ.
Его цель: Быть тем самым связующим звеном между бизнес-логикой из README и кодом. Он отвечает на вопросы "Как?" и "Почему?" на более высоком уровне, чем комментарии в коде.
80% результата при 20% усилий.
Для технических деталей (паттерны, стандарты кодирования) лучшим источником является сам код. Хорошо написанный, самодокументированный код с комментариями в нужных местах часто лучше любого отдельного гайда.
Вместо десятка .md файлов (tech_stack.md, patterns/, guides/, workflows/) у меня есть один мощный README.md для бизнес-контекста и сам код для технического. Этого более чем достаточно для большинства проектов.
README.md (бизнес-логика, флоу) + Код (реализация, техдетали) = Полный контекст.
Машинистки тоже смеялись над компьютерами.
Удачи вам в вашем 2002-м.
Вы описываете процесс, который был актуален до появления LLM. Ваша главная ошибка — вы всё ещё разделяете «формализацию» и «код».
Настоящая профанация — это потратить месяцы на «полную формализацию», чтобы в итоге получить идеальный код для никому не нужной идеи.
Мы же формализуем идею через код. Мы показываем заказчику не «что-то непохожее», а работающий прототип через час после разговора. И уточняем идею, глядя на него, а не на стопки бумаги. Это не «отсутствие процесса», это просто процесс, который работает на порядок быстрее вашего.
Идеи Sakana AI и xAI — это очевидный следующий шаг. Но их подходы (TreeQuest, Grok4 Heavy) — это, по сути, "черные ящики", которые автоматически синтезируют один "лучший" ответ, исключая из процесса самый важный элемент — человека.
Я сейчас экспериментирую с другой парадигмой: представьте себе групповой чат, где вы в роли модератора общаетесь сразу с несколькими топовыми моделями (Claude, GPT, Gemini, Grok), каждой из которых дана своя уникальная роль. Вы вкидываете идею, сталкиваете их мнения, создаете "продуктивное трение", управляете дискуссией и, опираясь на свою интуицию и связь с реальностью, синтезируете финальное решение.
Таким образом, мы получаем не просто "улучшенный" ответ от ИИ, а синергию коллективного интеллекта нейросетей и человеческой интуиции. Это уже не просто "две головы лучше одной". Это симбиоз человеческого опыта и многоголового машинного интеллекта — вот где, мне кажется, настоящая магия.
Человек как равноправный участник, но с правами модератора
Каждая модель имеет уникальную роль (системные промпты / настройки)
Модели взаимодействуют друг с другом и человеком, видя контекст
Интерфейс — естественный групповой чат
Цель — синергия и поиск новых решений, а не просто усреднение или выбор лучшего ответа
Интуиция, опыт и человеческое понимание контекста направляют коллективный машинный интеллект
Пытаться выстроить вокруг ИИ формальную структуру сейчас — это попытка залить бетоном фундамент на тектоническом разломе. Любой "узаконенный" процесс устареет еще до того, как мы его внедрим.
Ценность смещается от следования процессу к умению его ломать и пересобирать на лету с помощью новых технологий.
Интересный взгляд на "идеальный" процесс. На деле же, пока будет писаться ТЗ, рисоваться дизайн и настраиваться CI/CD, проект может стать неактуальным.
Статья отвечает на вопрос "как правильно строить процесс", но не на главный вопрос бизнеса: "как максимально быстро проверить гипотезу и начать получать пользу?".
Иногда лучший процесс — это его отсутствие.
Иногда трансформер — это просто трансформер.
Бизнесы ориентированы на максимизацию доходов, а не на благополучие пользователей или сотрудников. Бизнесу выгодно держать пользователей и сотрудников в состоянии постоянной активности, а не осознанности. Неосознанный пользователь — это идеальный потребитель.
Слои
Анатомия
UI‑анимация — не про код, а про ощущения. Стандартный AnimationController убивает желание творить. Пока пишешь весь этот бойлерплейт — теряешь фокус на самом ощущении движения.
Именно поэтому есть такие инструменты, как flutter_animate от gskinner, чтобы в пару строк экспериментировать с таймингами, изингами и настроением.
Для разработки — Claude 4 (Sonnet/Opus), Gemini 2.5 Pro и o3/GPT-4.1. Всё остальное заметно тупее.
Как же тогда вы определяете успешность моделирования? По каким критериям можно сказать, что ваш протокол действительно моделирует сознание, а не просто улучшает качество ответов?