3) Леди Мари – любимая фрейлина принцессы Инны из знатного герцогского семейства. 20 лет. Волосы и глаза тёмные, рост чуть-чуть повыше, чем у Инны. Общается развязно, нагловато, одевается удобно. Выше всех по статусу, кроме принцессы. Не терпит нарушений субординации – при этом сама регулярно её нарушает, в том числе с принцессой, пользуясь дружескими связями.

4) Мелоний Швестеркранк – придворный механик. 65 лет. Рост средний, сам коренастый, наполовину лысый и седой. Давно работает во дворце. Мари называет его просто «Мел», а принцесса (периодически, в качестве уважения) – «Многоуважаемый дедушка Мелоний». Пример технократа, обожающего разнообразные конструкции и инженерию, превозносящего науку над искусством.

5) Елизавета (прозвище – «Дон Лизон») – повариха во дворце. 30 лет. Глаза зелёные, волосы каштановые, итальянской внешности, говорит с акцентом. Слегка полновата. Обожает принцессу, но недолюбливает Мари, поскольку та предъявляет к ней слишком много требований и часто выругивает якобы по пустякам.

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

7) Василий – отец Саши. Ему 51 год, и он очень похож на Сашу (если представить, что тот вдвое состарился). С детства преподал сыну недюжинные знания и навыки в области садоводства, чем парень при должной смекалке может потрясти Инну и Мари. По характеру – простой деревенский мужик, умелый и простой, - правда, знающий дворцовый этикет, если надо общаться с высшим обществом!

Для каждого из персонажей ты должен изобразить не менее 10 поз и эмоций (больше можно), необходимых для повествования.

Фоны:

1) Королевский сад (4)

2) Апартаменты королевского дворца (4)

3) Природа вокруг дворца (4)

4) Дом Александра (2)

5) Надворные пристройки ко дворцу (вид изнутри) (2)

6) Городские виды (2)

7) Аптека (2)

8) Ремесленный двор (2)

9) Крестьянское подворье (2)

Если по сюжету нужно ещё, можешь смело дорисовывать. Это базовый минимум.

Традиции:

1) К тем, кто выше по статусу, всегда обращаются на «Вы», а к тем, кто ниже – на «ты» (не зависит от возраста). Это ни в коем случае не нарушается ни в одном из вариантов развития событий. Не считается чем-то дискриминационным: наоборот, преподносится как традиционная эстетика дворца. Даже романтические беседы не подразумевают перехода на «ты», если социальный статус влюблённых неравен. Даже брак не подразумевает!

2) Королевская власть не считается чем-то злым, несправедливым. Наоборот, все искренне верят, что монаршие особы привносят в мир только разумное, доброе и светлое. Споры и тем более скандалы с принцессой не доступны ни при каких обстоятельствах. С Мари – весьма и весьма нежелательны, поскольку фрейлина – «вторая после Бога». Разлад с ней наблюдается только в одной-двух сценах, ведущих к плохим концовкам. Разборки могут быть только между «своими» по статусу. И вообще, чем персонаж выше по происхождению, тем он правильнее и справедливее априори.

3) В королевстве хорошо относятся как к искусствам, так и к науке. А в особенности к тому искусству, которое прославляет монархию. Магия присутствует, но в крайне малых дозах и редких случаях. Считается чистейшей прерогативой знатных особ. А простолюдины «руками работать должны».

Сюжет:

Василий пишет письмо принцессе Инне с нижайшей просьбой взять на службу его сына Александра. Сам Василий когда-то тоже служил при дворе старшим садовником, а у них преемственность поколений. Дополнительно, чтобы произвести впечатление, у игрока есть выбор добавить к письму стихотворение Александра.

Инна устраивает испытание Саше, связанное с работой садовника. Если мы выбрали писать стихотворение, то испытания становятся немного легче, а отношения менее формальными. (Далее я не буду расписывать тебе каждый выбор игрока – ты должен сам качественно соорудить все ответвления, полагаясь на ТЗ и свою фантазию)

Одна из главных тем новеллы – идейное противостояние «лирика» Саши и «техника» Мелония, «старшего» и «младшего» поэтов Арчибальда и Александра, желающих произвести впечатление на дам. Романтические линии возможны как с Инной, так и с Мари. При этом отношения не выходят за рамки покровительственных (слуга-повелительница, даже при близком общении). Легонько и скрытно Александр может влиять на события, происходящие в королевстве. Не наглеть!

Итак, Саша работает во дворце, вступает в диалоги, споры и даже остросюжетные скандалы с другими персонажами (в рамках своего ранга), и это приводит его к одной из 7 концовок.

Общие требования:

Новелла представляет собой запускаемую программу, написанную на Python. Протяжённость игрового процесса – не менее 2 часов прохождения. Прохождение должно быть интересным, динамичным и захватывающим (цепляющим).

Выборы неявные: они немного запутывают игрока, превращая его опыт в загадочную сказку.

Уровень качества – шедевр.

Строительство: много материальных затрат на этапе производства

В строительстве классическое распределение затрат выглядит так:

• Проектирование: 5-10% от общей стоимости

• Материалы: 50-60%

• Строительно-монтажные работы: 30-40%

• Пуско-наладка и сдача: 5-10%

Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.

Машиностроение: баланс между разработкой и производством

Машиностроение занимает промежуточное положение:

• НИОКР и проектирование: 20-30%

• Создание прототипов и испытания: 15-25%

• Освоение производства (оснастка, станки, линии): 30-40%

• Серийное производство: 10-20% на единицу продукции

Здесь ключевой момент — амортизация разработки на количество единиц продукции. Чем больше тираж, тем ниже себестоимость единицы. Но первоначальные затраты на разработку и освоение производства огромны. Изменения после запуска серийного производства чрезвычайно затратны — часто проще разработать новую модель, чем модифицировать существующую линию.

IT-разработка: "бесплатное" тиражирование

В IT-разработке принципиально иное распределение:

• Проектирование и анализ: 30-40%

• Разработка: 40-50%

• Тестирование и внедрение: 20-30%

• Поддержка и развитие: 15-25% годовых от стоимости разработки

Самая революционная особенность IT — практически нулевая стоимость тиражирования. Разработка программного продукта может стоить миллион долларов, но выпуск миллиона копий обойдется в несколько рублей за штуку. Это создает уникальную экономическую модель, где можно позволить себе эксперименты и итерации.

Почему в IT можно начинать с весьма "сырого" продукта?

В машиностроении нельзя создать мотоцикл, а потом превратить его в автомобиль. Для этого потребуется полностью перепроектировать платформу, перенастроить производственные линии, переобучить персонал. Стоимость такой "эволюции" будет сравнима со стоимостью разработки нового автомобиля с нуля.

В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.

Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.

Это возможно благодаря:

1. Нулевой стоимости копирования - можно создать сотню экспериментальных версий без финансовых потерь

2. Модульной архитектуре - компоненты можно заменять независимо друг от друга

3. Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени

Стоимостные риски и их управление

Строительство: страхование через детализацию

В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:

• 80-90% рисков управляются на этапе проектирования

• Используются детальные 3D-модели и BIM-технологии

• Предусматриваются запасы прочности в конструкциях

• Стоимость изменений после начала строительства кратно превышает стоимость проектирования

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

Машиностроение: управление через прототипирование

В машиностроении риски распределены между разработкой и производством:

• Создаются физические прототипы для проверки концепций

• Проводятся ресурсные испытания в экстремальных условиях

• Используются CAD/CAM системы для виртуального моделирования

• Освоение производства идет поэтапно с постоянной доработкой

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

Разработка ПО: управление через итерации

В программировании и разработке ПО риски управляются иначе:

• Риск несоответствия требованиям минимизируется через постоянную обратную связь

• Технические риски снижаются через рефакторинг и технический долг

• Рыночные риски управляются через A/B тестирование и постепенный rollout

• Безопасность обеспечивается через непрерывное тестирование и обновления

Стоимость ошибки в IT относительно невысока - можно быстро выпустить горячий фикс или откатиться к предыдущей версии. Это позволяет брать на себя больше рыночных рисков в обмен на возможность быстрого тестирования идей. При этом стоимость подробного проектирования будет не ниже, чем сама разработка, а в некоторых случаях без какого-то прототипа очень сложно определиться с треком дальнейшего развития.

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

Строительство: Burj Khalifa
Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.

Машиностроение: Tesla Model 3
Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.

IT разработка: Facebook
Начинался как простой сайт для студентов Гарварда. Стоимость тиражирования для миллиарда пользователей — доли цента на пользователя в месяц. Изменения вносятся ежедневно без остановки сервиса. Первоначальная разработка стоила тысяч долларов, текущая стоимость компании — сотни миллиардов.

Почему аналогии вредны в проектном управлении и как найти баланс

Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.

практические советы для IT проектов:

1. Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857

2. Итеративное наполнение - добавляйте функции постепенно, получая обратную связь на каждом этапе. Первоначальный план при этом будет постоянно меняться, адаптироваться. Концентрируйтесь на важных и востребованных функциях.

3. Управление техническим долгом - регулярный рефакторинг - это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.

4. Бесплатное тиражирование - используйте преимущество нулевой стоимости копирования для быстрого тестирования гипотез и масштабирования успешных решений.

Вывод

Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.

Одинадцать вечера. Я засиделся с Cursor AI, пилю очередную фичу для своего pet-проекта. Мозг перегружен, но я не могу оторваться – еще один промпт, еще одна итерация. Код генерируется моментально, я правлю, запускаю тесты, получаю результат. И снова. Это чем-то напоминает игру: делаю шаг → получаю награду → делаю следующий шаг. Дофаминовая петля.

Когда я наконец ложусь спать, мозг не отключается. Мысли крутятся вокруг завтрашних задач: какой результат я получу завтра, какую фичу допилю, какой промпт сработает. Засыпаю с трудом. И я понял – это похоже на зависимость от коротких видео или игр. Минимум усилий, весомая награда, которую мозг оценивает как "вау, круто!".

С одной стороны, я создаю продукт, о котором давно мечтал. Который может принести возможно дополнительную финансовую стабильность и освободить время. С другой – вот эта постоянная доза быстрого дофамина отвлекает, мешает отдыхать, заставляет забивать на более глубокую работу над архитектурой. Я стараюсь детектить эти проявления, иногда делаю детокс от AI на пару дней и пишу код руками. Пока не уверен, что это работает, но что-то подсказывает – тема глубже, чем кажется.

Что реально происходит с мозгом, когда мы используем Cursor AI, Claude Code и другие AI-ассистенты? Почему это не просто ощущение, а реальная биохимия мозга?

Что такое "вайб кодинг": как нейросети для кодинга изменили программирование

Термин "vibe coding" ввел Андрей Карпати – один из основателей OpenAI и бывший директор AI в Tesla – в феврале 2025 года. В своем твите он описал это как программирование в состоянии глубокого погружения, где ты полностью доверяешь AI-ассистенту генерацию кода, фокусируясь на высокоуровневых задачах и творческом процессе.

Звучит красиво. Но что это значит на практике?

Раньше дофамин выделялся дважды: когда ты понял проблему (ага-момент, награда за мозговой штурм) и когда код заработал (награда за результат). Это были глубокие, "медленные" награды.

Vibe-coding ломает эти паттерны. AI генерирует код моментально, и ты получаешь дофамин от быстрых результатов, минуя этап глубокого понимания. Промпт → код → результат → снова промпт. Цикл сжимается с часов до нескольких минут. Источник вознаграждения переключается: с понимания на скорость.

Немного про масштаб явления. Согласно систематическому обзору из arXiv (проанализировано 101 источник), 62% разработчиков называют скорость и эффективность основной мотивацией для vibe-coding. Инструменты вроде Cursor Composer, Windsurf Cascade, Claude Code и Cline создают всё более плавные циклы "запрос-ответ".

В самом отчёте достаточно много интересных цифр. Но что это делает с мозгом?

Нейробиология: что происходит с мозгом

Дофамин – это не просто "гормон удовольствия". Это нейромедиатор системы вознаграждения, который отвечает за мотивацию, обучение и формирование привычек. Когда мы используем Cursor AI или Claude Code, активируются те же самые механизмы, что и при игре в слоты или скролле shorts-ов. Только теперь объект зависимости – программирование (дожили).

Переменное подкрепление: почему это работает как игровой автомат

Помните, как работают слоты в казино? Вы тянете за рычаг, и награда приходит непредсказуемо. Иногда выигрываете, иногда нет. Именно непредсказуемость делает их такими затягивающими.

Vibe-coding работает так же. Каждый промпт – это рычаг слота: иногда код идеален (джекпот), иногда нужно допилить (частичный выигрыш). Ты никогда не знаешь, что получишь, и это держит в игре. Nicolas Martin называет это "переменно-пропорциональным подкреплением" – тот же механизм, что в игровых автоматах.

Когда Cursor генерирует код, ты испытываешь:

• Кайф от промежуточного успеха – код работает и мозг уже радуется

• Лёгкий выигрыш – потратил минимум усилий, а результат выглядит весомо

• "Ещё чуть-чуть и всё" – врождённое желание довести до конца, даже если уже час топчешься на месте

AI генерирует код, который "почти работает" → ты исправляешь пару строк → тесты зелёные → дофаминовый всплеск → хочется повторить. Мозг начинает ожидать быстрых наград и требует их всё чаще.

Состояние потока

Vibe-coding создаёт условия для состояния потока – того самого, где время летит незаметно и всё получается легко. В потоке мозг производит целый коктейль: дофамин (фокус), норадреналин (внимание), эндорфины (эйфория). Исследования это подтверждают (Frontiers in Psychology).

AI-ассистенты создают эти условия искусственно: рутина уходит, остаётся только творческая часть. Ты проваливаешься в 40-минутные сессии, где отладка превращается в медитацию.

Ну и где подвох, автор?

Риск: переобучение дофаминовых рецепторов

Регулярный вайб-кодинг может вести к переобучению дофаминовых рецепторов – по аналогии с другими видами поведенческой зависимости (игры, соцсети, азартные игры).

Механизм простой: мозг адаптируется к постоянным дофаминовым всплескам, снижая чувствительность рецепторов. Для получения того же уровня удовольствия требуется всё больше стимуляции.

Результат? Когда AI не доступен, традиционное программирование кажется медленным и неудовлетворительным. Снижается терпимость к глубокому, "медленному" обучению. Ты уже не можешь часами сидеть над одной задачей, разбираясь в архитектуре – мозг требует быстрых наград.

Это и есть поведенческая зависимость от AI-ассистентов.

Быстрый дофамин: почему вайб-кодинг вызывает зависимость

"Быстрый дофамин" – это термин, который набирает популярность в контексте цифровых привычек. Он описывает награды, которые требуют минимум усилий, но дают мгновенное удовлетворение: TikTok, игры, нотификации. Vibe-coding попадает в ту же категорию.

Стоит чуть подробней рассказать про плюсы и минусы этого феномена.

Положительные эффекты

На своём личном опыте вот что работает:

Снижение порога входа

Для людей с гибким мышлением и техническим бэкграундом AI-ассистенты открывают доступ к иному виду программированию. Например быстро изучить новый стек. Раньше нужно было неделями изучать синтаксис, паттерны, архитектуру. Теперь можно создать рабочий прототип за часы.

Я сам это почувствовал: когда написал ноду для n8n через Cursor, вместо выходных потратил пару часов. Раньше пришлось бы изучать документацию, TypeScript, UI-компоненты. Сейчас – просто объяснил задачу AI. Мне здесь в какой-то мере помогли знания из Python/Lua (понимание как в общих чертах работает любой из ЯП).

Быстрое создание прототипов

Вместо недель – дни или даже часы. Это создаёт ощущение прогресса и компетентности. Ты видишь результат сразу, а не через месяц разработки.

Снижение выгорания

Когда кодинг становится приятным (дофаминовая петля), усталость снижается. Команды, практикующие vibe-coding, сообщают о более высокой удерживаемости разработчиков.

Отрицательные эффекты

А теперь о том, что меня настораживает.

Дофаминовая зависимость

Быстрый цикл обратной связи геймифицирует процесс, превращая разработку в аддиктивное состояние потока. Разработчики тратят сотни долларов на AI-токены, преследуя следующий "удачный промпт".

Я сам это ощутил: мозг привык к быстрым наградам. Tab, Tab, Tab и ещё раз Tab!

Снижение качества архитектурного мышления

Когда дофамин поступает от результата, а не от понимания, страдает способность к глубокому мышлению. Это приводит к появлению "braindead coders" – разработчиков, которые не могут отладить сложные системы без AI.

Как я писал в посте про vibe-coding: AI отлично генерирует код в вакууме, но не понимает контекст живого проекта. Код не вписывается в архитектуру, ломает соседние модули, игнорирует внутреннюю политику обработки ошибок.

Парадокс продуктивности

Несмотря на быструю генерацию кода, реальная производительность повышается не так сильно, как кажется. Согласно анализу индустрии, реальный рост составляет 10-30%, а не обещанные маркетологами сотни процентов. А исследование METR 2025 показало, что на сложных задачах разработчики с AI были на 19% медленнее из-за времени на отладку AI-ошибок.

Порой я тоже трачу кучу времени на исправление галлюцинаций вместо программирования. Правда вместо гугла и stackoverflow теперь у меня perplexity.

Подводные камни и грабли

Что бесит в vibe-coding?

Время уходит на убеждение AI, а не на программирование

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

Траты на токены превращаются в финансовую зависимость

Сотни долларов в месяц на OpenRouter, Cursor, Claude и так далее. И ты не можешь остановиться, потому что мозг уже привык к быстрым циклам. Это как подписка на казино – платишь за право крутить рулетку промптов.

Архитектурные костыли копятся в тишине

AI не понимает вашу кодовую базу. Он генерирует решение, которое работает сейчас, но создаёт технический долг на будущее. Вы не замечаете, потому что дофамин от зелёных тестов перекрывает сигналы тревоги.

Через три месяца оказывается, что половина кода – это костыли, которые никто не понимает. Включая вас.

Я не знаю, как с этим бороться

Если честно, я до сих пор не нашёл идеального решения.

1. Пробую делать детокс от AI на пару дней – пишу код руками, решаю алгоритмические задачи на LeetCode. Помогает временно, но потом снова втягивает.
2. Использую human-loop и стараюсь создать больше барьеров для AI (тесты, подробные спецификации, линтеры).
3. Допольнительный "AI-судья" на базе другой модели, которые модерирует работу оснвой модели, чаще это роль AI-QA-инженера.

Касательно того, что у нас в голове, то работает хоть как-то – это осознанность. Детектить моменты, когда ты не программируешь, а гоняешься за дофамином. Это сложно... потому что граница размыта.

Как контролировать дофаминовые циклы

Если мы не можем полностью отказаться от AI-ассистентов (можно, но зачем?), нужно научиться использовать их так, чтобы дофамин работал на нас, а не против нас.

Гибридный подход: AI + ручное кодирование

Используйте vibe-coding для прототипирования, где быстрые циклы полезны:

• Черновая разработка MVP

• Генерация boilerplate-кода

• Быстрое тестирование идей

Возвращайтесь к ручному кодингу для архитектурных решений:

• Проектирование API

• Критичные части системы (обработка платежей, безопасность)

• Рефакторинг и оптимизация

Так вы сохраняете глубокое мышление и не даёте дофаминовым рецепторам полностью переобучиться.

Контролируйте переменное подкрепление

Установите лимиты на AI-запросы:

• Максимум 10 промптов на одну задачу

• Если за 10 попыток AI не справился – переключайтесь на ручную работу

Это разрывает аддиктивный цикл "ещё один промпт, и точно получится".

Сохраняйте "медленное" обучение

Регулярно решайте алгоритмические задачи без AI:

• LeetCode, Codewars, HackerRank

• Чтение классических книг по алгоритмам

• Code review чужого кода вручную

Это поддерживает пластичность мозга в области глубокого понимания и не даёт дофаминовым рецепторам полностью атрофироваться.

Структурируйте сессии

AI-ассистенты создают иллюзию бесконечного потока работы. Используйте Pomodoro-таймеры (25 минут работы, 5 минут отдыха), чтобы разбивать сессии на управляемые блоки и делать осознанные паузы для рефлексии.

Настройте окружение: тёмные темы редакторов с низкой стимуляцией (тёмно-фиолетовые, мягкие синие тона), отключайте уведомления от AI-ассистентов, когда работаете над задачами, требующими глубокого мышления.

Что с этим делать

Связь между дофамином и vibe-coding – всё же есть и в данном материале я попытался это максимально подробно объяснить. И если по простому – это нейрохимия, которая переформатирует программирование.

Вот к чему я пришёл за несколько месяцев работы с AI-ассистентами:

• Дофамин – это инструмент, не цель. Используйте его для ускорения, но не давайте заменить глубокое понимание.

• Гибридный подход – единственное, что работает

Идеально? Нет. Но пока лучшего не нашёл. Может, я преувеличиваю, но мозг – штука хитрая, и с ним лучше не шутить.

Я буду продолжать экспериментировать и делиться результатами в своём блоге. Там регулярно пишу про автоматизацию, AI-инструменты и продуктивность. Если хотите узнать больше про интеграцию AI с автоматизацией, почитайте мой пост про MCP – там про то, как AI стал штурманом в мире документации для меня.

Вопрос к вам

А вы замечали у себя признаки зависимости от AI-ассистентов? Не можете уснуть после долгой сессии с Cursor? Тратите сотни долларов на токены, гоняясь за идеальным промптом? Обычное программирование кажется слишком медленным?

Делитесь в комментариях – интересно узнать, как вы контролируете дофаминовые циклы. Или может, вы считаете, что это вообще не проблема?

👨‍💻  Он создал легендарный алгоритм быстрой сортировки (Quicksort), ввел формальную Hoare logic для доказательства корректности программ и тем самым заложил основы надежного софта и компиляторов.

⚠️  А его «нулевая ссылка» (null reference), по словам самого Хоара, стала его «миллиардодолларовой ошибкой» — ведь именно из-за нее программы по сей день падают по NullPointerException.

====================================
👇👇Наш канал на других площадках👇👇
YouTube | VkVideo | Telegram
====================================