Разборы · Статья: · Видео: · 44:34

Что строить в эпоху агентов: список Theo от нового NPM до Slack для ИИ

Theo делится списком больших продуктов, которые хотел бы увидеть: безопасный NPM/NPX, source control после Git, Dropbox для dev-папки, новая mobile-платформа, агентный Slack и странные бенчмарки. Разбираем, где здесь реальная возможность, а где масштаб может обмануть.

ИИ Программирование Стартапы Продуктивность
Смотреть на YouTube

I don't have time to build these things, will you?

Theo - t3.gg · 44:34
Главы видео — нажми, чтобы перейти к моменту 9
  1. 0:00 От «как строить» к «что строить» Theo объясняет, что способы архитектуры стали менее решающими, а выбор проекта — важнее, потому что AI снижает цену реализации.
  2. 1:48 Идея 1: better NPM и NPX Проблемы публикации, unpublish, name squatting, risk metadata, AI-аудит релизов и безопасный запуск NPX-команд для людей и агентов.
  3. 12:42 Идея 2: source control после Git Git был прорывом, но плохо выражает приватные файлы, частные PR, delayed disclosure, granular permissions и agent-era workflows.
  4. 17:52 JJ, worktrees и source control без обычной файловой системы Theo хвалит эргономику JJ, ругает worktrees и связывает будущий VCS с in-memory shell вроде just-bash.
  5. 23:00 Идея 3: Dropbox для dev-папки Одинаковая структура проектов, env-переменных и lazy-синхронизации между Mac, Linux-боксами и cloud agents.
  6. 26:16 Идея 4: новая mobile-платформа Критика App Store и Play Store, ностальгия по CyanogenMod/Paranoid Android и мечта об Android-compatible экспериментальной ОС.
  7. 36:47 Идея 5: Slack, который думает постами Slack хорош shared channels, но плох как система чтения, приоритизации и агентного контекста. Theo хочет open-source Workplace-подобный control plane.
  8. 41:31 Идея 6: странные бенчмарки Нужны domain-specific evals от практиков: если агенты проваливают вашу реальную задачу, превратите её в воспроизводимый benchmark.
  9. 43:19 Финальный призыв Не обязательно строить идеи Theo; важно решиться на более крупные проблемы, которые раньше казались слишком дорогими.

Коротко

Theo предлагает перестать спрашивать только «как быстрее писать код» и начать спрашивать «какие старые примитивы разработки теперь можно заменить». Его список идей — это NPM/NPX с видимым риском, source control после Git, синхронизация dev-сред, открытая mobile-платформа, новый командный чат для агентов и нишевые бенчмарки.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:21
Показать текст выжимки
Если коротко, это продолжение мысли Theo о том, что в эпоху ИИ-агентов важно не только быстрее писать код, но и смелее выбирать, что вообще строить. В этом видео он достаёт список продуктов, которые хотел бы увидеть, но не успевает сделать сам. Первый блок — новый NPM и особенно новый NPX. Проблема не в том, что пакетный менеджер плох сам по себе, а в том, что он стал точкой атаки для всей разработки. Команда установки до сих пор часто спрашивает только «продолжить или нет», почти не показывая риск: кто выпустил пакет, что он делает, есть ли обфускация, какие разрешения нужны, кто проверял релиз. Для людей это неприятно, для агентов опаснее: агент может выполнить NPX-команду из инструкции и даже не понять, что пакет перехвачен. Вторая большая идея — source control после Git. Theo спорит не с тем, что Git был великим скачком, а с тем, что у него почти нет гранулярных прав на уровне файла, изменения или будущего pull request. Из-за этого секреты живут отдельно, security-патчи светятся раньше времени, а команды дробят монорепы из-за модели доступа. Дальше идут «Dropbox для dev-папки», новая мобильная платформа, Slack, похожий на Facebook Workplace, и странные бенчмарки для ИИ. Общая нить одна: многие старые инструменты были спроектированы для мира, где код дорогой, агентов нет, а человек вручную держит контекст. Теперь узкие места сместились. Практический вывод простой. Не надо завтра строить замену NPM или мобильную операционку. Но стоит выписать, где твоя боль не в фиче, а в старой примитивной модели: пакет, репозиторий, папка, чат, магазин приложений, бенчмарк. Если модель устарела, ИИ-агенты могут сделать эксперимент дешевле, чем он казался год назад. Критический момент тоже важен. Большая идея не становится хорошей только потому, что её теперь можно прототипировать. Но если раньше масштаб сам по себе был запретом, сейчас он стал гипотезой, которую можно проверить.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

Theo говорит: в мире AI-агентов хорошие идеи снова стали важнее способа реализации. Он не просто перечисляет «что бы я построил», а показывает, где старые инструменты разработки плохо подходят новому режиму работы: пакеты слишком слепо запускаются, Git плохо выражает приватность и права, dev-среды плохо синхронизируются, mobile-платформы душат эксперименты, Slack плохо держит контекст, а модели оценивают по слишком узким бенчмаркам.

Как ребёнку

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

Аналогия — «это как…»

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

Зачем это мне

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

Для тех, кто в теме

Дельта видео: Theo переводит «build bigger» из стратегии продукта в список инфраструктурных ставок. Его тезис не в том, что нужно клонировать npm/Git/Slack целиком, а в том, что agent-era требует новых primitives: install-time risk metadata, change-level permissions, lazy synced dev workspaces, Android-compatible experimental OS, post-based collaboration control plane и domain-specific evals.

Оценка видео

Чем выше — тем больше пользы на минуту

4.3

средняя из 5

Актуальность информации 5.0

Видео вышло 22.06.2026 и прямо попадает в текущую волну AI-агентов, supply-chain атак, agent-native devtools и пересборки рабочих процессов.

Содержательность 4.4

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

Инновационность идей 4.5

Не все идеи новые, но связка «старые primitives больше не подходят агентам» хорошо объясняет, где искать новые платформы.

Практичность 4.0

Список можно превратить в карту MVP: risk-aware NPX, Git-права на изменения, dev-folder sync, post-based team chat, узкий benchmark.

Достоверность 3.7

Боли реальны и частично подтверждаются внешним контекстом, но выводы про «новый Git» или «последний шанс mobile» остаются предпринимательскими ставками.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для основателей devtools-стартапов 5 /5

Это почти готовый backlog для agent-era инфраструктуры: registry, source control, workspace sync, collaboration и evals. Полезно не как ТЗ, а как карта мест, где incumbent-логика трещит.

Для разработчиков платформ 4.8 /5

Видео постоянно возвращается к primitives: пакет, репозиторий, файл, рабочая папка, чат, benchmark. Это прямой материал для тех, кто проектирует developer platforms и internal tooling.

Для security-инженеров 4.5 /5

Блоки про NPM/NPX, supply chain, видимость риска при установке и приватные security-патчи в source control напрямую касаются threat model современной разработки с агентами.

Для тимлидов 4 /5

Полезна рамка про то, где команда теряет контекст: PR на 11 тысяч строк, Slack-треды, stale worktrees, секреты вне репозитория и разные dev-среды на машинах.

Для инди-разработчиков 3.8 /5

Список идей вдохновляет, но большинство направлений слишком платформенные. Практическая польза — выбрать узкий клин: один risky NPX flow, один benchmark, один sync-сценарий.

Для мобильных разработчиков 3.5 /5

Mobile-блок эмоциональный, но важный: он связывает сложность дистрибуции приложений с потерей экспериментальной культуры, которая когда-то была в CyanogenMod/Paranoid Android.

Инсайты

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

01 Agent-era делает NPX опаснее, чем раньше 9:41

Когда NPX-команду запускает человек, он хотя бы может насторожиться. Когда её запускает агент из `SKILL.md`, отсутствие risk metadata превращается в supply-chain blind spot: агент видит команду, но не видит доверие, авторство, permissions и свежесть релиза.

02 Git застрял на repo-level privacy 14:49

Theo формулирует сильную мысль: private/public как настройка всего репозитория слишком груба. В agent-era и security-era приватность нужна на уровне файла, изменения, PR, релиза и времени раскрытия.

03 Проблема dev-среды стала проблемой топологии 23:00

Когда разработчик работает на Mac Mini, Linux-боксе, ноутбуке и cloud agent, боль уже не только в Git. Боль в том, что структура проектов, env, кэш и локальный контекст живут по-разному на каждой машине.

04 Mobile проиграл не только UX, но и культуру эксперимента 29:35

Самый сильный кусок про CyanogenMod: когда модифицировать ОС было проще, чем распространять приложение, платформа буквально выталкивала талантливых людей в web.

05 Бенчмарк — это способ заставить лаборатории заметить вашу боль 42:25

Theo предлагает не ждать, пока исследователи измерят именно вашу задачу. Если агенты плохо работают с Crystal, Git или визуальными задачами, воспроизводимый benchmark превращает частную боль в цель для оптимизации.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«solve problems that you actually have»
Theo Базовый принцип выбора проекта. 0:17
«ideas are still cheap»
Theo Почему он спокойно делится списком. 1:10
«GitHub is dying and Git is not the right primitive»
Theo Резкая формулировка про source control. 16:36
«go build some weird benchmarks»
Theo Финальный практический призыв. 42:45

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Выбери не фичу, а устаревший примитив

20 минут найдёшь идею глубже очередного AI wrapper

Возьми свою ежедневную боль и спроси, что там является старым базовым объектом: пакет, файл, PR, тред, app store, benchmark, dev folder. Хорошие идеи Theo почти все начинаются не с кнопки, а с пересмотра примитива.

Что делать

  1. 1 Выпиши 5 повторяющихся раздражений в своей работе.
  2. 2 У каждого найди базовый объект, вокруг которого всё крутится.
  3. 3 Отметь, где AI-агенты усиливают боль, а не просто ускоряют задачу.
  4. 4 Сформулируй новый примитив одним предложением.
2

Сделай MVP как один «тонкий клин»

вечер не утонешь в попытке заменить NPM, Git или Slack целиком

Большие идеи пугают размером. Но для проверки нужен не новый NPM, а один новый install prompt; не новый Slack, а один post-based workflow; не новый Git, а один приватный change-set.

Что делать

  1. 1 Выбери один сценарий, где текущий инструмент явно плох.
  2. 2 Сделай прототип, который улучшает только этот сценарий.
  3. 3 Покажи его 3 людям, у которых та же боль.
  4. 4 Расширяй только после повторного «да, мне это нужно».
3

Добавь risk metadata к любой команде, которую запускает агент

30 минут снизишь шанс слепого выполнения опасной зависимости

Даже без нового NPM можно начать с локальной дисциплины: агент не должен запускать свежий пакет или NPX-команду без проверки автора, возраста, provenance, install scripts и сетевого поведения.

Что делать

  1. 1 Найди в инструкциях проекта команды `npx`, `curl | bash` и установку пакетов.
  2. 2 Добавь рядом правило проверки источника и версии.
  3. 3 Для критичных команд закрепи конкретную версию или digest.
  4. 4 Попроси агента перед запуском коротко объяснять риск.
4

Преврати провал агента в benchmark

1–2 часа получишь измеримую задачу вместо ощущения «модели тупят»

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

Что делать

  1. 1 Возьми один свежий провал агента.
  2. 2 Очисти данные от приватного.
  3. 3 Запиши вход, ожидаемый результат и способ проверки.
  4. 4 Прогоняй разные модели одинаково и сохраняй результаты.
5

Проверяй идеи на lock-in, а не только на UX

15 минут лучше поймёшь, почему incumbent живёт несмотря на плохой интерфейс

Slack, NPM, Git и mobile stores держатся не только привычкой. У каждого есть lock-in: shared channels, dependency graph, history model, app ecosystem. Новый продукт должен знать, какой lock-in он обходит или постепенно растворяет.

Сценарии применения

Как разные люди применяют это на практике

Я как основатель devtools-стартапа

Проблема: вижу много раздражающих инструментов, но боюсь выбрать слишком большую идею

Хочу: найти клин, который реально можно проверить агентами

Поможет: структура видео помогает разложить «заменить NPM» на маленькие первые сценарии вроде безопасного NPX prompt

Я как security-инженер

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

Хочу: сделать риск видимым до выполнения кода

Поможет: блок про NPM/NPX даёт язык для install-time policy, provenance checks и third-party release scoring

Я как тимлид

Проблема: команда тонет в больших AI-PR, Slack-тредах и разных dev-средах

Хочу: понять, какие проблемы нельзя решить ещё одним workflow-документом

Поможет: видео показывает системные места: code review order, shared workspaces, post-based collaboration и агентный контекст

Я как инди-разработчик

Проблема: хочется строить большие вещи, но страшно не потянуть инфраструктуру

Хочу: выбрать маленький MVP внутри большой идеи

Поможет: совет «тонкий клин» превращает платформенную мечту в вечерний прототип

Я как мобильный разработчик

Проблема: дистрибуция и политики stores убивают желание экспериментировать

Хочу: увидеть альтернативную рамку для mobile как открытой платформы

Поможет: история CyanogenMod/BlackBerry 10 помогает отделить проблему приложений от проблемы самой платформы

Я как исследователь AI-evals

Проблема: лабораторные метрики не покрывают реальные странные задачи

Хочу: найти новые полезные evals

Поможет: финальный блок подталкивает брать доменные провалы агентов и превращать их в воспроизводимые benchmarks

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Скорость реализации выросла 0:00

    AI-агенты делают отдельные большие проекты выполнимыми для меньших команд, но не делают все проекты одновременно выполнимыми для одного человека.

  2. Аргумент Значит, выбор идеи становится важнее 0:17

    Если строить стало дешевле, опасность смещается с «не смогу реализовать» к «потрачу новую скорость на неправильную проблему».

  3. Аргумент Старые инструменты не проектировались под агентов 3:36

    NPM/NPX, Git, файловые системы и Slack появились в мире, где человек сам держал контекст и запускал действия вручную.

  4. Аргумент Новые продукты должны менять primitives 9:41

    Безопасный пакетный запуск, change-level permissions, synced dev-folder, post-based collaboration и domain evals — это не фичи сверху, а новые базовые объекты.

  5. Пример Каждая большая идея начинается с личной боли 23:00

    Theo не предлагает абстрактные рынки: у него болят publish, worktrees, env на разных машинах, mobile distribution, Slack-треды и отсутствие benchmark для странных задач.

  6. Вывод Проверять нужно клином, не клонов всей платформы 43:19

    Практический путь — выбрать один конкретный сценарий, где старый примитив проваливается, и доказать, что новый объект лучше.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Общая рамка

Это видео работает как практическое продолжение предыдущего тезиса Theo: если AI удешевил прототипирование, пора пробовать идеи, которые раньше казались слишком большими. Но здесь он уходит от общей философии к конкретному списку: package registry, source control, dev workspace sync, mobile OS, team chat и evals.

Самое важное: почти все идеи не про «добавить AI-кнопку». Они про старые базовые объекты разработки. Команда установки пакета не говорит достаточно о риске. Репозиторий плохо выражает частично приватную работу. Рабочая папка не умеет быть одинаковой между машинами. Мобильная платформа плохо принимает эксперименты. Slack плохо хранит и поднимает контекст. Бенчмарки не покрывают странные реальные задачи.

Что проверено внешним контекстом

Часть болей хорошо совпадает с текущей реальностью. У npm действительно есть строгие правила unpublish: официальная политика npm разрешает свободно убирать новые пакеты только в ограниченном окне и при условиях, связанных с зависимостями. Вокруг доверия к пакетам уже есть отдельные механизмы вроде trusted publishing/provenance в npm, но Theo хочет, чтобы такие сигналы были видны прямо в момент установки и запуска.

Для риска supply chain он упоминает Socket; сама Socket публично продаёт идею real-time detection и блокировки вредных пакетов до установки — см. страницу Socket. Для source control без обычного shell он ссылается на just-bash: проект vercel-labs/just-bash описывает себя как Bash for Agents. А в блоке про Workplace важный факт уже не прогноз: Workplace from Meta закрыт с мая 2026.

Как читать этот список

Не стоит воспринимать ролик как задание «замените Git целиком». Это скорее способ найти слой, где прежняя абстракция стала слишком грубой. Хороший первый продукт может быть гораздо уже:

  • не новый NPM, а install prompt, который показывает risk score и provenance;
  • не новый Git, а private changeset для security-патча;
  • не новый Dropbox, а synced dev-folder structure для cloud agents;
  • не новая mobile OS, а быстрый канал установки экспериментальных Android-compatible приложений;
  • не новый Slack, а post-based workspace для одного агентного workflow;
  • не новый eval-suite для всего ИИ, а маленький benchmark для задачи, где модели стабильно ошибаются.

Главный вывод

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

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 6

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 7 Верно: 0

  1. 1. Какой главный критерий выбора проекта Theo повторяет в начале?

  2. 2. Почему NPX становится особенно рискованным в мире агентов?

  3. 3. Что Theo считает неправильным уровнем приватности в Git?

  4. 4. Какой образ лучше всего описывает «Dropbox для devs»?

  5. 5. Зачем в видео вспоминаются CyanogenMod и Paranoid Android?

  6. 6. Почему Theo хочет чат, похожий на Facebook Workplace?

  7. 7. Какой практический вывод из блока про бенчмарки?

Словарь терминов

Понять незнакомое простым языком

Показать 9 терминов
NPM
Главный registry и пакетный менеджер JavaScript-экосистемы. Через него устанавливают библиотеки и публикуют пакеты.
NPX
Механизм запуска исполняемых пакетов из npm без явной ручной установки. Удобен для CLI, но опасен, если запускать неизвестный пакет вслепую.
Supply chain attack
Атака через зависимость, пакет, CI или другой элемент цепочки поставки кода, которому разработчики уже доверяют.
Name squatting
Захват красивого или похожего имени пакета, чтобы удерживать его, продавать или использовать для обмана.
Provenance
Проверяемая связь пакета с исходным репозиторием, workflow сборки и конкретным релизом. Не гарантирует безопасность, но помогает оценивать доверие.
JJ
Jujutsu, современная система контроля версий и интерфейс к Git-like workflow, известная более приятной работой со snapshot/change-oriented моделью.
Worktree
Механизм Git для нескольких рабочих директорий одного репозитория. Полезен для параллельной работы, но может конфликтовать с ветками и агентными сценариями.
Paranoid Android
Кастомная Android ROM из эпохи активных экспериментов с мобильными ОС. Theo использует её как пример культуры открытой мобильной разработки.
Benchmark
Воспроизводимый тест, который измеряет конкретную способность модели или агента. Хороший benchmark задаёт вход, ожидаемый результат и способ оценки.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Упрощение

Заменить NPM или Git сложнее, чем сделать хороший UX поверх них

Theo честно говорит о масштабе, но registry и VCS держатся не только плохим интерфейсом. Там есть совместимость, governance, доверие, CI-интеграции, cache/CDN, корпоративные политики и годы миграционного долга.

Спорно

AI-аудит релизов может создать ложное чувство безопасности

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

Однобоко

Новая mobile-платформа упирается не только в разработчиков

Даже Android-compatible ОС нужно победить distribution, hardware support, banking apps, push, payments, carrier issues и доверие обычных пользователей. История BlackBerry 10 показывает возможность, но не решает adoption.

Спорно

Slack-замена может проиграть не из-за UX, а из-за сети

Shared channels и корпоративная инерция — сильный lock-in. Open-source standard может расти снизу, но «медленно заменить Slack» сложнее, чем сделать лучшую структуру тредов.

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

Большая идея — это диагностический прибор

Не обязательно строить новый Git, чтобы получить пользу. Попытка описать «Git после Git» показывает, какие части текущего workflow болят сильнее всего и какие маленькие продукты можно вынести первыми.

На стыке областей

Agent-native devtools должны быть legible для машин

Раньше интерфейс объяснял риск человеку. Теперь риск должен быть структурирован так, чтобы его понял агент: metadata, permissions, provenance, policy, confidence и источник проверки.

Смежная область

Бенчмарки — новая форма продуктового маркетинга

Если маленькая команда делает benchmark, где все модели проваливаются, она не только помогает науке. Она создаёт рынок вокруг проблемы, которую теперь видно и можно сравнивать.

Похожие разборы

Разбор

ИИ снизил цену кода: почему разработчикам пора строить шире

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

Читать → Разбор

Хорошие части Claude Code: что Theo хочет «украсть» у Anthropic для всех CLI-агентов

Theo (t3.gg), который открыто недолюбливает Anthropic, разбирает фичи Claude Code, делающие его лучшим агентным CLI прямо сейчас. Поворот в том, что он показывает это не ради рекламы, а чтобы остальные harness'ы (Codex, pi, opencode, Cursor) скопировали эти паттерны.

Читать → Разбор

Ponytail для Claude Code: меньше кода без кода-гольфа

Ponytail полезен не потому, что велит агенту писать короче, а потому что заставляет его пройти лестницу решений: нужно ли это вообще, есть ли stdlib, нативный HTML/API или уже установленная зависимость. Самая честная рамка такая: огромная экономия появляется на задачах с overbuild-ловушкой, но на уже минимальном коде плагин почти ничего не «срежет».

Читать → Разбор

Петли (loops) в AI-кодинге: как заставить агента работать на цель без человека

Петля — это связка «триггер + цель», которая позволяет ИИ-агенту работать автономно к результату, убрав человека из цикла. Главный приём: цель должна быть либо проверяемой детерминированно (например, «все страницы грузятся < 50 мс»), либо отданной на суд самой модели («рефактори, пока не будешь доволен»); петли мощные, но пока не годятся для постройки фич с нуля и очень дороги по токенам.

Читать →
← Все разборы Смотреть видео-источник