Оффтоп, но не смог пройти мимо.

В Японии уже идут клинические испытания препарата, который способен запускать третий комплект зубов. Он блокирует белок USAG-1 — тот самый «стоп-сигнал», который мешает нашим зубам расти больше двух раз.

На животных это уже сработало. В октябре 2024 года начались испытания на людях. И если всё подтвердится, то к 2030 году вместо имплантов нас могут ждать новые собственные зубы.

Источник: Concierge Dental Group

@moyroadmap

Недавно у нас были дебаты на тему «AI — помощник или конкурент?». Мнения разделились: для одних это инструмент, усиливающий человека, для других — угроза, которая вытеснит с рабочего места.

Я решил копнуть глубже. И оказалось, что даже внутри Google нет единого мнения.

Сундар Пичаи уверяет, что искусственный интеллект создаст больше рабочих мест, чем уничтожит (Times of India).
А Мо Гавдат, бывший топ Google X, называет эту идею «100% чепухой» и предупреждает о дистопии ближайших лет, где исчезнут даже CEO (Windows Central, PC Gamer).

Для меня это выглядит так: Пичаи смотрит в долгую — на десятилетия вперёд, где AI действительно раскроет новые рынки и профессии. Гавдат же говорит о короткой перспективе, где исчезающих ролей будет больше, чем появляющихся. В этом смысле оба правы: сначала будет боль и адаптация, потом — рост и новые возможности.

@moyroadmap

Помните времена, когда все вокруг обсуждали prompt engineering?
Мол, как правильно спросить у нейросети, чтобы она не ушла в дебри и выдала что-то внятное. Тогда это выглядело как магия: добавь “ты опытный разработчик” и, о чудо, результат стал в два раза лучше.

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

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

Я пробовал это на практике с Roo Code. Когда загрузил в контекст весь модуль и дал агенту задачу он не просто “дописал функцию”, а реально понял, как она встраивается в систему. Это другой уровень: модель уже рассуждает о том, как изменения повлияют на соседние сервисы, и предлагает места, где стоит обновить документацию или покрыть тестами.

С Claude Sonnet тоже был интересный опыт: после того как я “скормил” ему весь Node.js проект, мы обсуждали не отдельные куски кода, а архитектуру и trade-off’ы. По ощущениям диалог уже не с autocomplete, а с архитектором.

Cursor IDE дал ещё одну перспективу. Когда в контексте есть и код, и описания задач, обсуждение начинает выходить на уровень продукта. Агент начинает видеть не просто строчки кода, а бизнес-логику, которая за ними стоит.

Но были и провалы. Иногда Roo Code теряет нить даже с большим контекстом: например, когда внутри одного модуля лежат старые и новые версии функций. Он начинает мешать стили, берёт куски кода не оттуда и выдаёт результат, который выглядит логично, но по факту ломает половину тестов. В Cursor я однажды добавил и код, и описание задач агент “схватился” за старый тикет и предложил решение, которое продукт давно выкинул. И тут понимаешь: чем больше контекст, тем больше шума, и если его не чистить, модель только запутается.

Контекст-инженерия это почти как системный дизайн. Не магия слов, а умение построить среду, где ИИ работает как ещё один член команды. И вместе с этим приходит новая ответственность: если контекст собран плохо, результат будет хуже, чем от обычного prompt’а.

Каждый новый кейс убеждает меня: мы стоим на пороге новой профессии. Раньше ценились те, кто знал “секретные фразы”. Завтра будут цениться те, кто умеет управлять контекстом — и держать баланс между полнотой и шумом.

И на этом месте я хочу пойти дальше. Следующий эксперимент мультиагентные системы. Я хочу попробовать собрать свою “команду мечты” агентов: один отвечает за код, другой за архитектуру, третий за документацию и задачи. Всё это тоже будет работать через контекст-инженерию.

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

@moyroadmap

Я долго искал способ быстро стартовать новый проект без вечного круга: настраивай NestJS, прикручивай Mongo, думай про RBAC, тесты, env. Всё это каждый раз отнимает время и силы.

В Roo Code я попробовал другой подход. Я написал context.md, где простыми словами описал, как именно хочу видеть проект.

Пример выглядел примерно так:

Стек: Node.js 20, NestJS 10, MongoDB 7
Слои: domain / application / infrastructure
.env обязательно валидируем через Joi
Авторизация: JWT (access + refresh), роли admin / manager / user
Тесты: Jest



А дальше я добавил ещё несколько простых правил:

Папки:
/src/domain — сущности и value objects
/src/application — use cases и сервисы
/src/infrastructure — контроллеры, репозитории, интеграции





CI:
Каждый PR проходит линт, тесты и сборку
Основная ветка: main

И вот что произошло. Roo Code перестал выдавать случайные заготовки и начал собирать проект так, будто давно работает в моей команде. Код сразу ложится в архитектуру, исчезли бесконечные переспросы и ненужные правки. В итоге получился starter-kit, который можно реально брать и запускать, а не переписывать с нуля.

По ощущениям, context.md стал ДНК проекта, а ИИ просто оживил его. И главный вывод простой: чтобы ИИ работал как часть команды, ему нужен не длинный промт, а нормальный контекст.


@moyroadmap

Недавно посмотрел интервью «Чипы Маска, восстание машин и лекарство от рака / вДудь». И вот момент с 1:51:11 до 1:59:45 стал для меня настоящим прозрением. Там говорилось о том, что сила ИИ-агентов не в том, что они генерят куски кода или пишут текст. Настоящая ценность в том, что они могут брать на себя роли — аналитика, проектировщика, разработчика, тестировщика. Это уже не просто ассистент, а команда, которая работает параллельно и доводит задачу до результата.

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

После этого у меня родилась идея: собрать свою dream team из агентов и управлять ими через панель, где видно, кто чем занимается. Так появился мой продукт DTD — Dream Team Development with Agent Control Panel. Теперь, когда я запускаю ACP, это похоже на живую планёрку. Analyst сразу врывается с вопросами про боль клиента, PO расставляет приоритеты, PM превращает гипотезы в сценарии, UX Expert спорит о том, поймёт ли пользователь с первого клика, Architect чертит рамки системы, Scrum Master держит фокус команды, Developer собирает каркас, а QA под конец спокойно показывает, где всё ломается.

Фактически это та же классическая продуктовая команда, только виртуальная, доступная 24/7 и управляемая через одну панель.

@moyroadmap

Раньше запуск стартапа выглядел как подвиг. Нужно было неделями возиться с серверами, базами данных, писать всё вручную, собирать команду и держать в голове кучу технических деталей. Сегодня всё поменялось. Поднять инфраструктуру можно за минуты, готовые сервисы решают половину задач, а ИИ-агенты работают как команда специалистов, только без найма и зарплат.

Я смотрю, как это происходит. Агент-аналитик за меня проверяет рынок: где люди готовы платить, где интерес только на словах. Другой агент собирает бизнес-требования — простыми словами описывает, для кого этот продукт и какую именно проблему он должен решить. Ещё один проектирует техническую основу: как система будет работать под нагрузкой, что делать, если появятся тысячи пользователей, и как всё это не развалится. Другой агент пишет код, ещё один тестирует сценарии, а UX-специалист думает, как сделать интерфейс таким, чтобы им можно было пользоваться без лишних объяснений.

И вот тут я понял важную вещь: когда техника и даже исследования закрываются так легко, самый сложный вопрос остаётся на мне. Это не «как построить», а «что именно строить и зачем». Потому что только я могу решить, в какой нише искать ценность, на какую боль отвечать, какую цель поставить продукту.

Анализ рынка перестал быть формальностью. Мне важно не просто «сколько конкурентов», а почему у них получилось или не получилось. За счёт чего они растут, что удерживает их пользователей, где слабые места, куда можно войти с другой стороны. И это уже не сухие таблицы, а поиск настоящих причин.

Технические требования для меня теперь — это не список модных технологий, а обещания пользователю. Если я говорю «быстро», значит нужно измерить: сколько секунд реально ждать. Если обещаю «надёжно», значит я заранее понимаю, что будет, если система даст сбой, и как она восстановится. Если обещаю «масштабируемо», значит я знаю, как справиться с ростом пользователей, не обрушив продукт.

ИИ помогает, ускоряет, снимает рутину. Но выбор направления остаётся за мной. Никакой агент не решит вместо меня, зачем мы делаем этот продукт.

И вот когда всё собрано — идея, понимание рынка, каркас продукта — остаётся главное: выпустить свою ласточку в первый полёт. И хочется, чтобы это был не просто символический взлёт «лишь бы оторвалась от земли». Хочется, чтобы она сразу пошла выше. Чтобы с первого раза показала: эта идея способна не только летать, но и держать высоту, и лететь дальше, чем я сам мог ожидать.

@moyroadmap

Когда я впервые открыл lean canvas, у меня было ощущение, что это очередная модная табличка. Но я все-таки решил попробовать на своем продукте Dseed, аналоге Kickstarter для узбекского рынка.

Сначала я пошел по стандартному пути: записал решение как будто уже все ясно, площадка для краудфандинга. Но как только дошел до блока проблемы, понял, что у меня не хватает ясности. Люди хотят запускать проекты, но у них нет удобной локальной платформы, нет доверия к зарубежным сервисам и локальные платежи не интегрированы. Казалось бы, все просто, но когда выписал, стало понятно: мое изначальное решение закрывает только часть боли.

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

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

На каналах продвижения я опять обжегся. В голове было Telegram и соцсети, а на деле оказалось, что целевой сегмент сидит в университетах, коворкингах и локальных сообществах. То есть не digital first, а партнерства и оффлайн.

И вот так шаг за шагом, версия за версией, я начал видеть, что lean canvas не про то, чтобы заполнить квадратики. Это инструмент, который честно показывает, где ты врешь себе. Каждое изменение делало картину яснее: кого мы обслуживаем, зачем это им и что на самом деле важно.

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

И наверное в этом для меня и есть сила lean canvas: он позволяет ошибаться на бумаге, а не в продакшене.

@moyroadmap

Код не стоит ничего

Ценно не то, кто его написал, а кто им владеет — то есть может менять его в предсказуемые сроки без страха, что всё рухнет.

Код, в который страшно лезть, — не актив, а долг.
Если ревью тянется неделями, а каждый фикс рождает новые баги — это не про качество задач, а про отсутствие владения кодом. А значит, и инженерной культуры.

Выход не в переписывании, а в рефакторинге и предсказуемости: малые правки, тесты, перекрёстное владение, отсутствие “висящих” изменений.
Не подгоняйте тесты под код — доводите код до состояния, где тесты проходят честно.

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

@moyroadmap

Нейронки рулят)

Ko‘plab startap asoschilari aytishlaricha,
hozir ularning loyihani katta qismini Sun'iy Intelekt yozyapti.

Dasturchilar esa endi AI ga topshiriq berish va uning ishini tekshirishdan iborat.

Yaxshi dasturchilarni topish juda qiyin bo‘lib qolgan.
Sababi, ko‘pincha tajribali dasturchilar yangi texnologiyalarni o‘rganishni istamay, eski usullariga yopishib olishgan.

Yaxshi dasturchi deyilganda endi AI bilan yaxshi ishlay oladigan dasturchilar tushinila boshlamqoda.

@botirziyatov

Упреки — странная штука.
Ты вроде просто хочешь, чтобы тебя поняли, а выходит — будто обвиняешь.
Не из злости, а из боли. Просто не хватает слов сказать прямо: мне обидно, мне не хватило, я рассчитывал на другое.
И тогда вырывается что-то вроде: ты опять, ну конечно, я же знал.

Раньше я думал, что упрек — это способ напомнить или достучаться.
А оказывается, это просто неумение говорить о своих чувствах без защиты.
Когда не хочешь показаться уязвимым — начинаешь звучать колко.

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

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

@moyroadmap

В Монголии, в пустыне Гоби, строят лагерь, где туристы смогут прожить «как на Марсе». Проект называется MARS-V — и именно здесь, среди красной земли, засушливого климата и пыльных бурь, создадут максимально реалистичную имитацию жизни на Красной планете.

Жить участники будут в капсулах, питаться сублимированной едой, работать в «скафандрах» и даже общаться с Землёй с задержкой — чтобы прочувствовать настоящую изоляцию космоса.

Первая миссия стартует к 2029 году. Отбор жёсткий, подготовка три месяца, место всего для шестерых, а месяц «на Марсе» обойдётся примерно в $6000.

Источник: Tempo.co, Universe Magazine, Times of India

@moyroadmap

Почему будущее — за ContextOps-подходом

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

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

Главная идея проста: контекст — это новая единица работы с ИИ.
Он хранит не только то, “что” мы делаем, но и “почему”, “для кого” и “в какой ситуации”.
Системы, построенные по принципам ContextOps, могут сами управлять своим контекстом, адаптироваться под проект, помнить цели, роли, решения и улучшать процесс взаимодействия.

Такой подход превращает ИИ-продукт из помощника в самоприменимую систему — ту, что умеет использовать свои же принципы для собственного улучшения.
Она не просто отвечает, а ведёт проект, помнит стратегию, понимает динамику и контекст команды.

Это естественное развитие B2Dev-модели: когда продукт подстраивается под конкретного разработчика, его локальные модели и процессы.
ContextOps позволяет работать с ИИ даже офлайн, сохраняя приватность и при этом не теряя «интеллектуальную непрерывность».

В будущем контекст станет таким же стандартом, как API.
Мы не будем писать промпты — мы будем разворачивать контексты.
ИИ будет понимать не только команды, но и цели, связи и смысл происходящего.

Именно поэтому ContextOps — это не просто новая технология. Это переход от prompt engineering к context engineering, от управления ответами — к управлению мышлением.

PS: Этот термин придумано мной😎

@moyroadmap

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

Недавно Wired опубликовал исследование: люди, активно живущие в социальных сетях, начинают мыслить как модели искусственного интеллекта — менее креативно, более шаблонно и предсказуемо.
Соцсети учат мозг работать “в формате алгоритма”: быстро, поверхностно, без пауз.
Каждый свайп — дрессировка внимания.
Каждый “лайк” — закрепление паттерна.

И тут совпало: почти параллельно исследователи из трёх американских университетов обучили LLM на мусорных данных — тиктоках, мемах и твитах.
Результат?
Модель стала буквально глупой. Потеряла способность рассуждать, решать задачи и держать длинный контекст.
Даже когда её потом пытались “долить умом” — не помогло. Деградация оказалась почти необратимой.

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

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

🔗 Credits - Wired: «AI Models Trained on Social Media Are Showing Cognitive Decline»


@moyroadmap

🚀 Payme усиливает инженерный блок и приглашает сильных Senior Backend и Tech Lead инженеров!
Если хочешь влиять на архитектуру, принимать ключевые технические решения и быть частью команды, которая создаёт один из крупнейших fintech-продуктов региона — это отличный шанс.

🖥️ Senior Backend Developer (Node.js)
Ты будешь работать над ядром экосистемы Payme — высоконагруженными, критичными и масштабируемыми сервисами.
Мы ждём, что ты:
- умеешь строить устойчивые и производительные backend-решения;
- знаешь, как улучшать архитектуру и техническое качество продукта;
- привносишь зрелые инженерные практики — от тестирования до наблюдаемости;
- умеешь работать в команде и делиться экспертизой.
Требования: 5+ лет в backend, 3+ года с Node.js (продакшен).

🧩 Tech Lead
Роль для тех, кто хочет быть техническим драйвером продукта.
Ты будешь:
- определять архитектуру и технический вектор;
- писать и ревьювить сложный код;
- менторить инженеров и усиливать команду;
- принимать решения, влияющие на масштабируемость, стабильность и скорость продукта;
- работать на стыке технологий, бизнеса и архитектуры.
Требования: 6+ лет в backend, 2+ года Senior/Tech Lead.

⚙️ Наш стек
Node.js, TypeScript, NestJS, MongoDB, Redis, Kafka, ELK, k8s, REST, JSON-RPC

💡Практики
DDD, Clean Architecture, EDA, CI/CD, TDD, Observability, Resilience

📩 Готов присоединиться? Пиши!
Email: fozilbek.samiyev@payme.uz
Telegram: @imfozilbek
Формат: офис 5/2, Ташкент.

Недавно вышло исследование про прокрастинацию, и в нём есть несколько фактов, которые довольно сильно ломают привычную картину.

Учёные наблюдали за подростками-близнецами: сделали им МРТ мозга, а спустя примерно восемь лет посмотрели, как эти же люди живут и работают во взрослом возрасте, в том числе насколько они склонны откладывать дела. И выяснилось, что выраженная прокрастинация во взрослом возрасте связана с тем, как в подростковый период развивалась конкретная зона мозга — nucleus accumbens. Это область, отвечающая за мотивацию, ожидание награды и выбор поведения «сделать сейчас или отложить».

Сам факт номер один: склонность к прокрастинации можно было частично предсказать по МРТ, сделанному за много лет до того, как человек вообще столкнулся со взрослой работой, ответственностью и дедлайнами.

Факт номер два: прокрастинация оказалась умеренно наследуемой. Генетический анализ показал, что и особенности развития этой области мозга, и склонность откладывать дела во взрослом возрасте имеют общую генетическую основу. То есть это не только результат воспитания, привычек или характера.

Факт номер три: у людей с выраженной прокрастинацией обнаружились различия в работе дофаминовой и серотониновой систем, а также в экспрессии генов, связанных с транспортом веществ в мозге, иммунными процессами и нейровоспалением. Это уже не уровень «плохая привычка», а вполне конкретные нейробиологические процессы.

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

Это не значит, что всё предопределено и ничего нельзя изменить. Но это сильно меняет угол зрения. Возможно, постоянное «надо собраться» — не самый эффективный способ. Гораздо полезнее спрашивать себя, какие условия, масштаб задач и ритм работы помогают мозгу включаться, а не уходить в откладывание.

@moyroadmap

Я посмотрел интервью с Yann LeCun и поймал себя на мысли, что это ровно то, о чём я последние годы интуитивно говорил командам и коллегам.

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

И вот LLM сейчас относятся скорее к первой категории.

Это очень мощный инструмент, я сам его активно использую. Но как только начинаешь примерять это на реальные задачи, где есть ответственность и последствия, становится очевидно, что это не интеллект.

Это продвинутая статистика.

LLM не понимают причинно-следственные связи. У них нет модели мира. Они не могут предсказать последствия действий, они могут только сгенерировать правдоподобный ответ.

Идея LLM → AGI с самого начала казалась мне слишком прямолинейной. Как будто мы масштабируем интерфейс и называем это интеллектом.

LeCun просто озвучивает это вслух.

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

Если ты строишь продукт, особенно в финтехе, где ошибка это деньги и риски, становится понятно, что LLM это слой взаимодействия. Удобный и сильный, но не мозг.

А мозг это всегда система. Данные, логика, ограничения, сценарии и ответственность.

Очень рекомендую посмотреть, там есть над чем подумать
https://youtu.be/XnnnAx5lrx8

@moyroadmap