Interview with Vibe Coder in 2025 (Рубрика #AI)
Забавное видео про то, как выглядит Vibe Coding в 2025 году. У этого автора есть куча интересных видео про разные профессии, причем про пару из них я уже рассказывал "Next-Door Tech CEO 2024" и "Interview with Product Manager in 2024 [Corporate]". Ну а для нового видео ребята выбрали тему вайб кодинга, что сейчас моден, например, про это говорили ребята из Y Combinator в выпуске "Vibe Coding Is The Future", про который я уже рассказывал. Вот подбор цитат, что мне особенно понравились
- "Are we cahing a data? Oh I'm cashing in hard on it yeah" - про кеширование
- "What is a database?" - про хранение стейта
- "Tests? We test it on TikTok yeah" - про тестирование
- "Fix it now or you go to jail" - агенту для фикса проблемы
- "It's not a syntax error, a mood misalignment, bro" - про ошибки
- "This is production code, yeah. It's producing lots of cash" - готов ли код для продакшена
- "Technical debt? I am not technical" - про технический долг
- "Cursor make no mistake, don't hallucinate" - промпт для генерации лучших результатов
- "It deleted a whole repo ... I had a different idea anyway" - про переключение на следующий проект после фейла
- "The vibe coding thing really works well with my attention span" - почему vibe coding подходит для СДВГ людей
- "Why is my bill 30k?" - про контроль стоимости
- "Private key? The one I put on my Github?" - про безопасность
- "I don't know how to build a feature to turn it off" - про отключение разработанного:)
- "Lawyers with a criminal record near me" - про поиск людей для помощи
#Humor #AI #Engineering #Software
Забавное видео про то, как выглядит Vibe Coding в 2025 году. У этого автора есть куча интересных видео про разные профессии, причем про пару из них я уже рассказывал "Next-Door Tech CEO 2024" и "Interview with Product Manager in 2024 [Corporate]". Ну а для нового видео ребята выбрали тему вайб кодинга, что сейчас моден, например, про это говорили ребята из Y Combinator в выпуске "Vibe Coding Is The Future", про который я уже рассказывал. Вот подбор цитат, что мне особенно понравились
- "Are we cahing a data? Oh I'm cashing in hard on it yeah" - про кеширование
- "What is a database?" - про хранение стейта
- "Tests? We test it on TikTok yeah" - про тестирование
- "Fix it now or you go to jail" - агенту для фикса проблемы
- "It's not a syntax error, a mood misalignment, bro" - про ошибки
- "This is production code, yeah. It's producing lots of cash" - готов ли код для продакшена
- "Technical debt? I am not technical" - про технический долг
- "Cursor make no mistake, don't hallucinate" - промпт для генерации лучших результатов
- "It deleted a whole repo ... I had a different idea anyway" - про переключение на следующий проект после фейла
- "The vibe coding thing really works well with my attention span" - почему vibe coding подходит для СДВГ людей
- "Why is my bill 30k?" - про контроль стоимости
- "Private key? The one I put on my Github?" - про безопасность
- "I don't know how to build a feature to turn it off" - про отключение разработанного:)
- "Lawyers with a criminal record near me" - про поиск людей для помощи
#Humor #AI #Engineering #Software
YouTube
Interview with Vibe Coder in 2025
Vibe Coding
https://linkgraph.net/stack/vibecoder
Interview with a Professional Vibe Coder with Kai Lentit aired on © The Viboe Coder 2025.
AI coding
prompt engineering
three js
windsurf
replit
cursor tricks
cursor rules
Programmer humor
Vibe code Jam…
https://linkgraph.net/stack/vibecoder
Interview with a Professional Vibe Coder with Kai Lentit aired on © The Viboe Coder 2025.
AI coding
prompt engineering
three js
windsurf
replit
cursor tricks
cursor rules
Programmer humor
Vibe code Jam…
👍5🔥3❤2
[1/2] The New SDLC: от vibe coding к agentic engineering (Рубрика #AI4SDLC)
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые ментальные модели: инструменты меняются каждую неделю, а рамка должна пережить эту смену. Разбор не поместился в один пост, поэтому их будет два:)
Авторы формулируют главный тезис как глубокий сдвиг в инженерии — не новый язык или фреймворк, а переход от написания кода к выражению намерения, когда система переводит это намерение в работающий софт. Десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь таким интерфейсом стало намерение. По данным whitepaper (на начало 2026), 85% профессиональных разработчиков регулярно используют AI-агентов, 51% — ежедневно, а около 41% нового кода уже сгенерировано AI. Цифры стоит читать как индустриальную оценку, но направление оспорить трудно.
Дальше авторы делают важную вещь — разводят два затёртых термина. Vibe coding (термин Карпатого, февраль 2025) — это когда ты «отдаёшься вайбу», описываешь желаемое на естественном языке и принимаешь, что выдал AI, а при ошибке просто копируешь её обратно в промпт. Agentic engineering — дисциплинированный конец того же спектра, где AI пишет реализацию внутри тщательно спроектированных ограничений, тестов и feedback loops, а человек держит ответственность за архитектуру, корректность и качество.
Ключевая мысль: разница не в том, используешь ли ты AI. Разница в том, сколько структуры и верификации окружает его вывод. Сказать техдиру, что «мы vibe-кодим платёжную систему» — повод для тревоги. Сказать «мы практикуем agentic engineering, где AI реализует под human-designed ограничениями, а покрытие тестами гарантирует корректность» — совсем другой разговор.
Главным различием здесь является верификация. В agentic engineering работают два механизма верификации
- Тесты проверяют детерминированную часть: на этот вход функция даёт такой выход
- Evals проверяют недетерминированную: выбрал ли агент правильную траекторию шагов, те ли инструменты, ту ли финальную планку качества
Без обоих это всегда vibe coding, как бы красиво ни были написаны промпты.
Отдельная часть документа посвящена тому, что context engineering - это настоящий инженерный навык. Качество AI-кода зависит не от хитрости промпта, а от качества контекста. Авторы выделяют шесть типов (instructions, knowledge, memory, examples, tools, guardrails) и разводят контексты на два вида
- Static context (всегда загружен, дорогой по токенам)
- Dynamic context (по требованию, дешевле)
Сам сдвиг от «prompt engineering» к «context engineering» отражает простую правду: вопрос не «как обмануть AI, чтобы он написал хороший код», а «что нужно знать новому члену команды, чтобы сделать работу хорошо, и как закодировать это знание в форму, понятную AI».
Авторы отметили, что AI сжимает SDLC неравномерно: реализация ужимается с недель до часов, но требования, архитектура и верификация остаются human-paced. Спецификация становится новым узким местом. Авторы не прячут неудобный факт: при заявленном опросами росте продуктивности на 25–39% исследование METR показало, что опытные разработчики на ряде задач тратили на 19% больше времени — из-за верификации и отладки AI-вывода. AI не убирает работу реализации, а превращает её из «писать» в «проверять и направлять».
В следующей части мы поговорим про то, что окружает модель: harness (Agent = Model + Harness), модель фабрики производства фичей, роли conductor/orchestrator и экономику agentic engineering.
P.S.
Примерно эти мысли я раскрывал в своем докладе "State of AI4SDLC" на AI Dev Conf. Там была цепочка intent → context → plan → tasks → implementation → verification ровно про то, что ускорение кодинга не ускоряет разработку целиком, а перевешивает нагрузку выше по процессу.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые ментальные модели: инструменты меняются каждую неделю, а рамка должна пережить эту смену. Разбор не поместился в один пост, поэтому их будет два:)
Авторы формулируют главный тезис как глубокий сдвиг в инженерии — не новый язык или фреймворк, а переход от написания кода к выражению намерения, когда система переводит это намерение в работающий софт. Десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь таким интерфейсом стало намерение. По данным whitepaper (на начало 2026), 85% профессиональных разработчиков регулярно используют AI-агентов, 51% — ежедневно, а около 41% нового кода уже сгенерировано AI. Цифры стоит читать как индустриальную оценку, но направление оспорить трудно.
Дальше авторы делают важную вещь — разводят два затёртых термина. Vibe coding (термин Карпатого, февраль 2025) — это когда ты «отдаёшься вайбу», описываешь желаемое на естественном языке и принимаешь, что выдал AI, а при ошибке просто копируешь её обратно в промпт. Agentic engineering — дисциплинированный конец того же спектра, где AI пишет реализацию внутри тщательно спроектированных ограничений, тестов и feedback loops, а человек держит ответственность за архитектуру, корректность и качество.
Ключевая мысль: разница не в том, используешь ли ты AI. Разница в том, сколько структуры и верификации окружает его вывод. Сказать техдиру, что «мы vibe-кодим платёжную систему» — повод для тревоги. Сказать «мы практикуем agentic engineering, где AI реализует под human-designed ограничениями, а покрытие тестами гарантирует корректность» — совсем другой разговор.
Главным различием здесь является верификация. В agentic engineering работают два механизма верификации
- Тесты проверяют детерминированную часть: на этот вход функция даёт такой выход
- Evals проверяют недетерминированную: выбрал ли агент правильную траекторию шагов, те ли инструменты, ту ли финальную планку качества
Без обоих это всегда vibe coding, как бы красиво ни были написаны промпты.
Отдельная часть документа посвящена тому, что context engineering - это настоящий инженерный навык. Качество AI-кода зависит не от хитрости промпта, а от качества контекста. Авторы выделяют шесть типов (instructions, knowledge, memory, examples, tools, guardrails) и разводят контексты на два вида
- Static context (всегда загружен, дорогой по токенам)
- Dynamic context (по требованию, дешевле)
Сам сдвиг от «prompt engineering» к «context engineering» отражает простую правду: вопрос не «как обмануть AI, чтобы он написал хороший код», а «что нужно знать новому члену команды, чтобы сделать работу хорошо, и как закодировать это знание в форму, понятную AI».
Авторы отметили, что AI сжимает SDLC неравномерно: реализация ужимается с недель до часов, но требования, архитектура и верификация остаются human-paced. Спецификация становится новым узким местом. Авторы не прячут неудобный факт: при заявленном опросами росте продуктивности на 25–39% исследование METR показало, что опытные разработчики на ряде задач тратили на 19% больше времени — из-за верификации и отладки AI-вывода. AI не убирает работу реализации, а превращает её из «писать» в «проверять и направлять».
В следующей части мы поговорим про то, что окружает модель: harness (Agent = Model + Harness), модель фабрики производства фичей, роли conductor/orchestrator и экономику agentic engineering.
P.S.
Примерно эти мысли я раскрывал в своем докладе "State of AI4SDLC" на AI Dev Conf. Там была цепочка intent → context → plan → tasks → implementation → verification ровно про то, что ускорение кодинга не ускоряет разработку целиком, а перевешивает нагрузку выше по процессу.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
👍13❤12🔥5🤣1
[2/2] The New SDLC: harness, factory model и экономика agentic engineering (Рубрика #AI4SDLC)
Продолжаю разбор майского whitepaper от Google, где в первой части мы обсуждали сдвиг от синтаксиса к намерению, и дальше спектр vibe coding → agentic engineering и context engineering. Теперь мы поговорим про то, что окружает модель и превращает её в работающего агента.
Любимая формула документа: Agent = Model + Harness. Когда начинаешь работать с агентами, есть соблазн считать систему моделью: вышла новая модель — агент поумнел, старая — поглупел. Авторы говорят, что это неверный взгляд, ведущий к неверным инвестициям. Модель — лишь один вход. Всё остальное — промпты, инструменты, политики контекста, hooks, sandboxes, суб-агенты, observability — это harness, обвязка вокруг модели, которая и даёт ей довести дело до конца. По их оценке, модель — это примерно 10%, harness — примерно 90% того, что вы ощущаете, работая с Claude Code, Cursor, Codex или Gemini CLI.
Доказательства не риторические. На бенчмарке Terminal Bench 2.0 одна команда подняла coding-агента из-за пределов топ-30 в топ-5, поменяв только harness, без смены модели. Отдельное исследование LangChain подняло score на 13.7 балла, твикая лишь system prompt, инструменты и middleware вокруг фиксированной модели. Вывод, который стоит повесить на стену: большинство сбоев агента, если разобраться честно, — это сбои конфигурации, а не модели.
Из этого вырастает factory model. Главный продукт разработчика — уже не код, а система, которая код производит: спецификации и контекст, агенты-исполнители, тесты и quality gates, feedback loops, возвращающие ошибки агенту, и guardrails. Менеджер завода не точит каждую деталь руками — он проектирует конвейер и контроль качества. Современный разработчик задаёт агентам критерии успеха, а не пошаговую инструкцию, и даёт им итерироваться.
Роль разработчика при этом раздваивается
1️⃣ Conductor — реальное время, в IDE, контроль на уровне нажатий клавиш; хорош для исследования, прототипа, изучения нового API
2️⃣ Orchestrator — асинхронно, на уровне целей, делегирование нескольким агентам, ревью результата, а не каждой строки; хорош для фич, миграций, генерации тестов.
Большинство переключается между режимами в течение дня.
Отдельно — «проблема 80%». Агент быстро генерирует около 80% кода фичи, но оставшиеся 20% (edge cases, обработка ошибок, точки интеграции, тонкая корректность) требуют глубокого контекста, которого моделям часто не хватает. Природа ошибок изменилась: от синтаксических к концептуальным — неверные предположения о бизнес-логике, пропущенные edge cases. Их труднее заметить именно потому, что код «выглядит правильно» и проходит базовые тесты.
Авторы интересно рассматривают экономику. Для лидера важнее velocity total cost of ownership. Vibe coding выглядит дёшево (низкий CapEx), но прячет высокий OpEx: token burn, постоянные циклы переспрашивания, maintenance-налог на «спагетти», security-латание. По оценке авторов, в точке пересечения vibe coding обходится в 3–10× дороже за фичу. Agentic engineering переворачивает модель: высокий CapEx (спеки, тесты, структурирование контекста) и низкий маржинальный OpEx. Context engineering и intelligent model routing (большие модели — на сложное, дешёвые — на детерминированное) становятся прямыми финансовыми рычагами.
Практическая часть «с чего начать» разложена по трём уровням
1️⃣ Разработчику: завести AGENTS.md, поставить набор skills, сделать первый агент из повторяющегося workflow, писать tests и evals до генерации кода, ревьюить каждую строку, что идёт в прод.
2️⃣ Лидеру: сделать context engineering полноценной практикой (AGENTS.md, промпты, evals, skills — как код, под ревью и версионированием) и ставить планку на eval, а не на демо.
3️⃣ Организации: вкладываться в production substrate до масштаба, принимать открытые стандарты (MCP, A2A), планировать гибридные команды человек+агент.
Вывод документа называется «Intent as the new Interface», и три принципа в нём:
1️⃣ Structure scales, vibes don't
2️⃣ AI усиливает вашу инженерную культуру — множит и сильные, и слабые стороны
3️⃣ Роль человека эволюционирует, а не исчезает
Финальная фраза
Для меня это ровно та логика, которую я разбирал в статье про agent-first IDP: Agent = Model + Harness, evals как контур качества, production substrate до масштаба — те же идеи, но на уровне платформы. Главный вывод обоих текстов один: дисциплина (specs, tests, evals, harness) — не противоположность скорости, а её условие.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Продолжаю разбор майского whitepaper от Google, где в первой части мы обсуждали сдвиг от синтаксиса к намерению, и дальше спектр vibe coding → agentic engineering и context engineering. Теперь мы поговорим про то, что окружает модель и превращает её в работающего агента.
Любимая формула документа: Agent = Model + Harness. Когда начинаешь работать с агентами, есть соблазн считать систему моделью: вышла новая модель — агент поумнел, старая — поглупел. Авторы говорят, что это неверный взгляд, ведущий к неверным инвестициям. Модель — лишь один вход. Всё остальное — промпты, инструменты, политики контекста, hooks, sandboxes, суб-агенты, observability — это harness, обвязка вокруг модели, которая и даёт ей довести дело до конца. По их оценке, модель — это примерно 10%, harness — примерно 90% того, что вы ощущаете, работая с Claude Code, Cursor, Codex или Gemini CLI.
Доказательства не риторические. На бенчмарке Terminal Bench 2.0 одна команда подняла coding-агента из-за пределов топ-30 в топ-5, поменяв только harness, без смены модели. Отдельное исследование LangChain подняло score на 13.7 балла, твикая лишь system prompt, инструменты и middleware вокруг фиксированной модели. Вывод, который стоит повесить на стену: большинство сбоев агента, если разобраться честно, — это сбои конфигурации, а не модели.
Из этого вырастает factory model. Главный продукт разработчика — уже не код, а система, которая код производит: спецификации и контекст, агенты-исполнители, тесты и quality gates, feedback loops, возвращающие ошибки агенту, и guardrails. Менеджер завода не точит каждую деталь руками — он проектирует конвейер и контроль качества. Современный разработчик задаёт агентам критерии успеха, а не пошаговую инструкцию, и даёт им итерироваться.
Роль разработчика при этом раздваивается
1️⃣ Conductor — реальное время, в IDE, контроль на уровне нажатий клавиш; хорош для исследования, прототипа, изучения нового API
2️⃣ Orchestrator — асинхронно, на уровне целей, делегирование нескольким агентам, ревью результата, а не каждой строки; хорош для фич, миграций, генерации тестов.
Большинство переключается между режимами в течение дня.
Отдельно — «проблема 80%». Агент быстро генерирует около 80% кода фичи, но оставшиеся 20% (edge cases, обработка ошибок, точки интеграции, тонкая корректность) требуют глубокого контекста, которого моделям часто не хватает. Природа ошибок изменилась: от синтаксических к концептуальным — неверные предположения о бизнес-логике, пропущенные edge cases. Их труднее заметить именно потому, что код «выглядит правильно» и проходит базовые тесты.
Авторы интересно рассматривают экономику. Для лидера важнее velocity total cost of ownership. Vibe coding выглядит дёшево (низкий CapEx), но прячет высокий OpEx: token burn, постоянные циклы переспрашивания, maintenance-налог на «спагетти», security-латание. По оценке авторов, в точке пересечения vibe coding обходится в 3–10× дороже за фичу. Agentic engineering переворачивает модель: высокий CapEx (спеки, тесты, структурирование контекста) и низкий маржинальный OpEx. Context engineering и intelligent model routing (большие модели — на сложное, дешёвые — на детерминированное) становятся прямыми финансовыми рычагами.
Практическая часть «с чего начать» разложена по трём уровням
1️⃣ Разработчику: завести AGENTS.md, поставить набор skills, сделать первый агент из повторяющегося workflow, писать tests и evals до генерации кода, ревьюить каждую строку, что идёт в прод.
2️⃣ Лидеру: сделать context engineering полноценной практикой (AGENTS.md, промпты, evals, skills — как код, под ревью и версионированием) и ставить планку на eval, а не на демо.
3️⃣ Организации: вкладываться в production substrate до масштаба, принимать открытые стандарты (MCP, A2A), планировать гибридные команды человек+агент.
Вывод документа называется «Intent as the new Interface», и три принципа в нём:
1️⃣ Structure scales, vibes don't
2️⃣ AI усиливает вашу инженерную культуру — множит и сильные, и слабые стороны
3️⃣ Роль человека эволюционирует, а не исчезает
Финальная фраза
Generation is solved. Verification, judgment, and direction are the new craft
Для меня это ровно та логика, которую я разбирал в статье про agent-first IDP: Agent = Model + Harness, evals как контур качества, production substrate до масштаба — те же идеи, но на уровне платформы. Главный вывод обоих текстов один: дисциплина (specs, tests, evals, harness) — не противоположность скорости, а её условие.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Telegram
Книжный куб
[1/2] The New SDLC: от vibe coding к agentic engineering (Рубрика #AI4SDLC)
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые…
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые…
❤13👍6🔥5
Как продакт из Meta запускает продукты, не умея программировать (Рубрика #AI)
Еще полгода назад посмотрел выпуск Lenny’s Podcast с Zevi Arnovitz, продактом из запрещённой в России Meta и бывшим PM в Wix, но забыл об этом написать. Тогда мне показалось, что вот оно - новое наполнение роли продакта, но если это работает в условной Meta, то не факт, что легко переносится и в другие компании:) Сейчас я писал пост про то, что ждет продактов и вспомнил об этом видео и решил поделиться им с вами.
У самого Zevi нет технического образования, и он признаётся, что почти не умеет читать код. При этом, по словам участников выпуска, за год он самостоятельно собрал и монетизировал StudyMate - сервис, который превращает учебные материалы в интерактивные тесты.
Его процесс работы мало похож на классический vibe coding:
- Идея превращается в задачу Linear через MCP;
- Claude изучает кодовую базу, задаёт вопросы и готовит план;
- Gemini берёт интерфейс, Composer - быстрое исполнение, Codex - поиск сложных ошибок;
- Результат проходит ручной QA, несколько AI-review и пользовательское тестирование;
- После ошибок обновляются инструкции и документация агента.
По сути, Zevi построил вокруг моделей маленькую инженерную организацию. Он владеет проблемой и тем, что должен почувствовать пользователь, а агентам делегирует реализацию. Продакт теперь может не только написать PRD и ждать команду, но сам пройти путь от идеи до работающего продукта и обратной связи от пользователей.
Отсюда его прогноз: названия должностей и границы ответственности начнут схлопываться, а «строителями» станут все. Для начинающих специалистов это ещё и способ получить практику сразу в стратегии, UX, маркетинге и разработке.
Но есть важная оговорка. В большой компании Zevi не советует продактам самостоятельно выкатывать миграции базы или другие рискованные изменения. AI-native кодовую базу сначала должны подготовить инженеры: добавить контекст, документацию и ограничения. Разумный старт для PM - локальная UI-фича, PR и финальная проверка разработчиком.
В общем, сейчас продакту не обязательно становиться программистом, но уже недостаточно оставаться только постановщиком задач. Нужно уметь собирать систему вокруг агентов, проверять результат и отвечать за него. Фраза «это сделал AI» ответственности не снимает.
#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding
Еще полгода назад посмотрел выпуск Lenny’s Podcast с Zevi Arnovitz, продактом из запрещённой в России Meta и бывшим PM в Wix, но забыл об этом написать. Тогда мне показалось, что вот оно - новое наполнение роли продакта, но если это работает в условной Meta, то не факт, что легко переносится и в другие компании:) Сейчас я писал пост про то, что ждет продактов и вспомнил об этом видео и решил поделиться им с вами.
У самого Zevi нет технического образования, и он признаётся, что почти не умеет читать код. При этом, по словам участников выпуска, за год он самостоятельно собрал и монетизировал StudyMate - сервис, который превращает учебные материалы в интерактивные тесты.
Его процесс работы мало похож на классический vibe coding:
- Идея превращается в задачу Linear через MCP;
- Claude изучает кодовую базу, задаёт вопросы и готовит план;
- Gemini берёт интерфейс, Composer - быстрое исполнение, Codex - поиск сложных ошибок;
- Результат проходит ручной QA, несколько AI-review и пользовательское тестирование;
- После ошибок обновляются инструкции и документация агента.
По сути, Zevi построил вокруг моделей маленькую инженерную организацию. Он владеет проблемой и тем, что должен почувствовать пользователь, а агентам делегирует реализацию. Продакт теперь может не только написать PRD и ждать команду, но сам пройти путь от идеи до работающего продукта и обратной связи от пользователей.
Отсюда его прогноз: названия должностей и границы ответственности начнут схлопываться, а «строителями» станут все. Для начинающих специалистов это ещё и способ получить практику сразу в стратегии, UX, маркетинге и разработке.
Но есть важная оговорка. В большой компании Zevi не советует продактам самостоятельно выкатывать миграции базы или другие рискованные изменения. AI-native кодовую базу сначала должны подготовить инженеры: добавить контекст, документацию и ограничения. Разумный старт для PM - локальная UI-фича, PR и финальная проверка разработчиком.
В общем, сейчас продакту не обязательно становиться программистом, но уже недостаточно оставаться только постановщиком задач. Нужно уметь собирать систему вокруг агентов, проверять результат и отвечать за него. Фраза «это сделал AI» ответственности не снимает.
#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding
YouTube
How a Meta PM ships products without ever writing code | Zevi Arnovitz
Zevi Arnovitz is a product manager at Meta with no technical background who has figured out how to build and ship real products using AI. His engineering team at Meta asks him to teach them how he does what he does. In this episode, Zevi breaks down his complete…
❤8👍5🔥5🥱1
Как AI-native разработка меняет роль продакта
Поймал себя на интересной мысли
В AI-native разработке продакт перестаёт быть интерфейсом между «бизнесом» и инженерами. Ему нужно самому зайти в данные, собрать с агентом прототип, сформулировать evals и критерии приёмки, понимать стоимость и риски.
В качестве доказательства можно посмотреть уже разобранный мной выпуск Lenny's Podcast с Зеви Арновиц, продактом из запрещенной в России компании Meta. У Зеви нет технического образования, и он признаётся, что почти не умеет читать код. При этом он построил вокруг моделей маленькую инженерную организацию с Claude, Gemini, Codex, Cursor и отгружает код на прод. Сам он отвечает за то, что должен почувствовать пользователь от фичи, а агентам делегирует реализацию.
Забавно, что теперь инженер с продуктовым мышлением и AI уже может забрать часть discovery, дизайнер — проверить сценарий, аналитик - собрать прототип. А продакт, чья сила держится на встречах, презентациях и бэклоге, внезапно обнаружит, что команда умеет обходиться и без этого.
Меняться нужно сейчас: работать с агентами руками, разбираться в коде и данных, учиться evals и экономике AI.
Индустрия не пришлёт приглашение в календарь перед тем, как переписать нашу роль. Лучше переписать себя самим - пока для продактов старого типа ещё осталось место.
#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding
Поймал себя на интересной мысли
Привычная модель работы продакт-менеджера заканчивается быстрее, чем многие успевают это заметить
В AI-native разработке продакт перестаёт быть интерфейсом между «бизнесом» и инженерами. Ему нужно самому зайти в данные, собрать с агентом прототип, сформулировать evals и критерии приёмки, понимать стоимость и риски.
В качестве доказательства можно посмотреть уже разобранный мной выпуск Lenny's Podcast с Зеви Арновиц, продактом из запрещенной в России компании Meta. У Зеви нет технического образования, и он признаётся, что почти не умеет читать код. При этом он построил вокруг моделей маленькую инженерную организацию с Claude, Gemini, Codex, Cursor и отгружает код на прод. Сам он отвечает за то, что должен почувствовать пользователь от фичи, а агентам делегирует реализацию.
Забавно, что теперь инженер с продуктовым мышлением и AI уже может забрать часть discovery, дизайнер — проверить сценарий, аналитик - собрать прототип. А продакт, чья сила держится на встречах, презентациях и бэклоге, внезапно обнаружит, что команда умеет обходиться и без этого.
Меняться нужно сейчас: работать с агентами руками, разбираться в коде и данных, учиться evals и экономике AI.
Индустрия не пришлёт приглашение в календарь перед тем, как переписать нашу роль. Лучше переписать себя самим - пока для продактов старого типа ещё осталось место.
#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding
🔥9❤3👍2