Хочу написать про своего кумира. Про инфленсера, про лидера мнение, гения, филантропа и просто хорошего человека. Про человека, на которого я по-настоящему равняюсь и в котором вижу себя будущего

Это Дэн Охлопков. Благодаря нему я вообще влился в нейросферу на продвинутом уровне. Благодаря его чатику я замотивировался двигаться в области нейросетей и интегрировать их в повседневную разработку и, впрочем, в жизнь

Есть книга «Самурай без меча», она больше про психологию и лидерство, но там есть есть момент, когда Toyotomi Hideyoshi выбрал своего предводителя и был ему верен, потому что видел в нем те качества, которыми хотел обладать сам
И благодаря этому Хидэёси смог объединить Японию, даже когда Нобунага умер в одной из схваток. Хидэеси положил начало из кровавой державы в одну из самых инновационных стран. Без единой капли крови. Общением. Когда все вокруг хотели биться и убивать друг друга

Нобунага верил в Хидэеси и отдал возможность принять очень важное решение, как и Дэн доверился мне, перейдя на кодекс и не пожалев. Он выдал мне титул в чатике «на кодексе». Я безумно рад этому. Это тот человек, который не имеет корону, находясь в статусе инфлюенсера. Тот человек, который реально слышит. Человек, которому хочется следовать. Чатик, в который хочется возвращаться

К слову, про манию величия и про корону в IT сфере у меня есть еще много мыслей, напишу как-нибудь постик

В Хидэёси я вижу себя. Я вижу как Дэн стал для меня человеком, в котором я вижу те самые качества, которыми сам хочу обладать. Как и Хидэеси видел те самые качества в Оду Нобунаге, которые хотел перенять себе

Даже взять, что Дэн сейчас работает там, где я мечтаю работать уже пару лет

Спасибо, Дэн!

Хммм, не все погружены в фичи телеги, но многие точно задумывались, как сделать несколько никнеймов в тг для своего профиля/канала

Так вот, это довольно просто:
1. Регаем обычный ник через публичные тгк/группу
2. Ждем некоторое время пока ник станет вашим по меркам тг. Могу ошибаться, 1-3 недели
3. Регаем тон-кошелек (юзаю этот). Пополняем его доступным способом (например, через @wallet или @send)
4. Регаем Fragment, связываем его с телегой и нашим кошельком. Верифаем KYC
5. Выставляем ник на аукцион. Делаем цену 10 тон. Если дает поставить цену еще ниже — делаем ниже
6. Депаем минимальную ставку со своего тон-кошелька
7. Ждем неделю и молимся чтобы вас не перебила другая ставка
8. Никто не осмелился за 7 дней сделать ставку и забрать ваш ник? Поздравляю! Вам придет алерт от бота. Готово. Ник ваш. Фрагмент забрал себе 5 тон комиссии, а оставшиеся 5 отправил вам на кошелек как продавцу. Выходит скидка 50% на следующий ник
8.1. Если кто-то всё же осмелился сделать ставку выше — также придет алерт от бота. Пытаемся перебить её, если так хотим этот ник
8.2. Если не хотим — по окончании таймера ник достанется человеку с наивысшей ставкой. Тоны вернутся на ваш кошелек
9. Через фрагмент делаем assign со своим тг/тгк

– После первого аукциона для ника его можно выставлять на мгновенную продажу
– В первые полчаса (а могут и через полгода) после покупки вам будут писать скамеры и просить продать ник за любую цену. Не ведитесь! Любая «can I buy @elite_pizza?» — сразу в чс и без разговоров, лишь 1 из 100 человек будет настоящим покупателем

– Ни в коем случае не теряем доступ к основному тон-кошельку, потому что к нему привязаны никнеймы!

На основе моих покупок (более 15шт), такое удовольствие — от 700 до 1200 рублей за чужой ник и 1400-2000 за свой ник, в зависимости от курса тона

Так были куплены все ники для @bishx (кроме самого bishx) и @bishx_devlog

А стоит ли вообще использовать сложные системы разработки?

Ранее писал публичный и приватный пайплайн. Но в последнюю неделю замечаю, что они слишком долгие и дорогие (да, к сожалению, я начал признавать стоимость разработки) для повседневных задач. Они хороши для трудоёмких, сложных задач, но для ad hoc-решений это перебор. А таких большинство, когда тяжелые пайплайны уже сделали свою работу и остаётся полировка

Я понял, что скучаю по обычному чатику, где ты пишешь "Сделай X" и через 10-15 минут получаешь результат
И cмотришь на этот результат, получаешь дофамин... приходит новая идея – сразу оцениваешь, как это выглядит. Дофаминовый цикл

Уже пора строить упрощенный пайплайн, где нужно просто сидеть в чатике, общаться, а агент по умолчанию будет делать правильные вещи – достаточно изучать таску, параллелить исполнение и самостоятельно предлагать идеи

Этот подход накапливает техдолг, но важно ли это в RAD-подходе, где ты сам выступаешь заказчиком и принимашь работу у нейросети? Нет. Абсолютно. Ты хочешь видеть результат, а не тысячу перепроверок и верификаций, правильности управления версиями, где хоть что-то увидишь в лучшем случае через час от последнего промпта
Хочется обычного человеческого – предлагать идеи, аппрувать предложения и смотреть результат

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

/goal рефакторни X! MANDATORY: не останавливайся и не допусти ни одной ошибки

По сути – максимально прорабатываем happy path по типичным сценариям, лицевую часть фичи. На ночь ставим изучать edge/corner/negative cases и увеличивать покрытие тестами

Что получаем на выходе?
Готовую отличную фичу, а также уверенность, что эта фича реализована без багов и непокрытых сценариев

Бизнес, как и мы, ждёт решение, а не сжигание компьюта

Морально дорос до сохранения контекста нейросети со всех сессий

Обычный контекст – 1 миллион токенов. А в codex gpt-5.5 вообще 258к. Но что если нейросеть будет помнить всё, что когда либо обсуждалось? При этом не будет тратить токены на фоновое поддержание памяти, как это происходит с жадной загрузкой skills/mcp в классическом подходе

Это – gbrain:
1. Хранение всей информации в собственной вики, в виде .md-файлов и их индексация через эмбеддинги с дальнейшим поиском через RAG
2. Автоматизированный ежедневный анализ новых диалогов – с автообновлением вики, переиндексацией diff'ов и многоакторной верификацией

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

Проанализировав все диалоги из claude/codex (которые по умолчанию сохраняются локально) и загрузив лучшие решения в вики – получаем свою цифровую копию с hard-skills

А загрузив и проиндексировав свои диалоги из мессенджера – получаем цифровую копию личности…

Юзаем полученные знания в повседневном общении с нейронкой. Именно общении. Не обязательно в разработке – в общении
Узнать, что произошло 15 мая 2026? – welcome!
Как мы в прошлый раз решали X? – без проблем!
Проведи SWOT-анализ по soft-скиллам, – отлично!


Всё бы супер, только подход gbrain использует не весь потенциал задумки и довольно много упускает. В моём представлении работы с RAG и дообучением памяти – из first-party gbrain многое переработано и некоторые вещи фундаментально изменены:

Мы не просто поставили gbrain, а допилили его в полноценную приватную память для Codex: перевели runtime на общий Postgres + HTTP MCP для параллельных агентов, подключили качественные OpenAI embeddings text-embedding-3-large на 3072 измерения, добавили temporal search по разным осям времени (formed_at, recorded_at, indexed_at), сделали строгий allowlist, чтобы в индекс попадали только curated заметки, а не сырые чаты/архивы, выстроили вечерний $review-drafts пайплайн для разборки auto-drafts в нормальные memory pages с commit/push, и прописали агентам правила: при затыках сначала искать в памяти, но не считать слабые semantic совпадения истиной.

Как всё протестирую – выложу в опенсурс своё решение

Уже более недели пассивно-активно занимаюсь настройкой gbrain. И сейчас неожиданно понял, что пришел к интересному инсайту по будущим разработкам

Итак, реальная проблема: Для индексации динамически меняющихся файлов памяти (обычный markdown) необходимо стандартизировать данные для записи в Postgres с возможностью последующей фильтрации по некоторым полям

Казалось бы — отдай задачу нейросети. Она стандартизирует и добавит. А если таких задач 200+ и они вызываются ежедневно? Кто даст гарантию, что ветер подует в правильном направлении и, как следствие, стохастика модели каждый раз сработает ровно так, как нужно? Гарантия лишь в том, что умная модель догадается, что мы хотим получить

Так вот, можно сделать стандартизацию через скрипты-чекапы. Дать модели доступ к вызову скриптов. Описать что модель должна подать на вход и что получит на выходе

Логика очень простая. Но в чем инсайт? Инсайт в том, что ровно по такой логике работают MCP (есть скрипт и есть его описание; объединили несколько скриптов в предметной области — получили MCP) и, как мне кажется, подкапотные вызовы first-party тулзов. Например, по записи/редактированию файлов, — модель не может изменить файл, не прочитав его, даже если на 100% уверена в его содержимом: скрипт просто выдаст ошибку редактирования файла. Тулзы нужны для создания возможностей – что именно модель может использовать. Но как это использовать – это уже наша задача ей объяснить

В случае с постгресом — мы пишем скрипт, какие [мета]данные обязательно должны быть отражены в md-файле (файле памяти), чтобы корректно распарсить и импортировать этот файл в бд
Рядом со скриптом пишем скилл. В скилле описываем как работать со скриптом и как обобщённо-правильно фиксить непройденные проверки. Получился очень упрощенный MCP. Можно сказать, аналог first-party тулзов:

$dreams завершён и запушен.

Обработано и архивировано 24/24 draft из инвентаря: ...

Проверки прошли: proposal artifacts 5/5, ledger/proposal/diff/evidence validation, redaction, allowlist, Dreams helper tests, two gbrain sync passes, indexed timestamp stamping, target-slug get_evidence, semantic query with embedding_hnsw, query_scan, temporal searches, final staged guard

После этого у меня сложился пазл. Ведь скрипты с дополнительными проверками относятся не только к нейросетям. К этому же относится и ruff и тестирования продуктов с предкоммитными/регрессионными проверками. По сути взяли тот же механизм. Возвели из него абстракцию. Перенесли на любую другую область – тем самым избавились от предполагаемой недетерминированности