Рабочий приём. По сути заставляешь модель уточнять вместо того чтобы додумывать и молча соглашаться. В статье из Johns Hopkins про это тоже - вопросительная формулировка снижает сикофантию, а тут ты ещё и модели разрешаешь спрашивать
Не умнее, скорее лучше оптимизирован под конкретную задачу. Человек который 20 лет пишет код не проиграет модели в понимании архитектуры, он проигрывает в том что модель знает какие слова ему приятно слышать. Это разные скиллы
Про Адизеса хорошо. Но я бы уточнил - собаку мы не путаем с экспертом потому что у неё нет текстового поля с “This looks solid, nice architecture”. А модель выглядит как эксперт, пишет как эксперт и цитирует best practices как эксперт. Граница размывается не потому что мы глупые, а потому что мимикрия слишком хорошая
Или пишешь вопросами а не утверждениями - в статье как раз про это, Johns Hopkins показали что формулировка влияет. “Я решил сделать X” получает одобрение, “стоит ли делать X” получает нормальный ответ
Ну да, про это и пишу в статье по сути - бизнес-модель стимулирует мягкость. Но промпт “be adversarial” реально меняет поведение, проверял. Не до уровня анонимного Васяна конечно, но хотя бы начинает говорить “тебе тут не нужен отдельный сервис, можно обойтись одним классом” вместо вечного “great architecture”
Хорошая мысль про тренировочные данные. Статьи, туториалы, readme - всё написано в стиле “вот как правильно”. Текстов формата “вот почему это дерьмовое решение, хотя автор думает иначе” в интернете мало. Ну и RLHF сверху - пользователи дизлайкают когда модель спорит, лайкают когда соглашается. Двойной отбор в сторону поддакивания получается
С легаси работает, потому что ты чужой код кидаешь без эмоциональной привязки. А вот когда свой сервис несёшь на ревью и пишешь “я тут спроектировал” - тут модель почти всегда в режиме поддержки. Попробуй тот же код кинуть без контекста авторства, просто “оцени архитектуру” - разница в ответах бывает прям заметная
Проблема с извлечением цифры решается проще - Ollama поддерживает параметр format в запросе. Если передать JSON-схему типа {“choice”: int}, модель вернёт структурированный ответ без второго вызова. Два запроса вместо одного на каждый выбор - двойной расход токенов на весь прогон
15 секунд на git clone - это не модель думает, это overhead промпта, API, отрисовки, апрува. На одиночных командах агент всегда медленнее. Ценность на многошаговых - пайплайн, настройка сервера, ansible роли. Автор и сам это показал: на clone раздражает, на Flask+Docker+pipeline впечатляет
Статья доказывает что SPEC.md Symphony ≈ код. Ну да, там схемы БД, формулы ретраев, псевдокод - оно и есть код в markdown. Но реальный паттерн другой. CLAUDE.md, .cursorrules описывают не реализацию а ограничения - “используй repository pattern”, “не лезь в БД из вьюх”, “тесты кладём в tests”. Модель заполняет детали сама. Дейкстра про узкие интерфейсы прав, но ограничения и так узкие
Ну смотри, дефицит 1.5 млн это прогноз red_mad_robot/Сбера, не мой. Я сам в статье написал что Сбер одновременно сокращает 13.5 тысяч и жалуется на нехватку кадров, и что это плохо стыкуется. Про промпт инжиниринг согласен, но тут скорее не “профессия исчезла” а её неправильно назвали - люди которые это делали просто стали обычными пользователями LLM
Про агентов на одноплатниках я в статье сам оговорился что для edge это норм, ирония была в контрасте со словами «третий полюс», не в самой технологии. Про GigaChat = дотренированная открытая модель - Сбер прямо утверждает что обучают с нуля без открытых архитектур, я на CNews сослался где Фролов это объясняет. Можно не верить конечно. А сценарий с батником и пропагандой реально смешной, жаль что не выглядит нереалистичным
Про агентов на одноплатниках я в статье сам оговорился что для edge это норм, ирония была в контрасте со словами «третий полюс», не в самой технологии. Про GigaChat = дотренированная открытая модель - Сбер прямо утверждает что обучают с нуля без открытых архитектур, я на CNews сослался где Фролов это объясняет. Можно не верить конечно. А сценарий с батником и пропагандой реально смешной, жаль что не выглядит нереалистичным
Ага, я к тому же выводу прихожу в статье - обе версии не взаимоисключающие. Просто Amazon пытается свести к “user access control issue” и снять вопрос, а FT акцентирует автономность агента. На практике это два слоя одной проблемы - и оба надо фиксить. Права ограничить И checkpoint перед деструктивными действиями добавить
Ну да, классика NIH синдрома. Только тут масштаб другой - обычно NIH это когда переписывают библиотеку потому что “мы знаем лучше”, а Amazon заставил 80% инженеров использовать свой инструмент вместо того который те сами выбрали. И потом удивились что что-то пошло не так
Ну да, если инструмент реально хороший - люди сами подтянутся. Когда Claude Code появился, никто не заставлял его использовать, просто кто-то попробовал и рассказал коллегам. А тут 1500 человек прямо говорят “мы уже нашли что работает лучше” и им в ответ KPI. Это даже не ленивый менеджмент, это менеджмент который активно игнорирует фидбек от собственных инженеров. Ну и результат соответствующий
Двухуровневая система - да, примерно так Claude Code и работает. Есть глобальные permissions в settings.json от команды/компании, а есть CLAUDE.md в проекте где разработчик описывает что можно а что нельзя. У Kiro видимо ничего такого не было, просто operator-level доступ на весь scope. Про бесполезные KPI - ну 80% weekly usage как OKR для менеджеров это прям учебник по Goodhart’s Law, когда метрика становится целью она перестаёт быть метрикой
Про тросик в положении “полный газ” - ладно, тут ты меня поймал, плохой пример был) Про ответственность на создателя - а ведь так и будет скорее всего. EU AI Act уже классифицирует AI-системы по уровню риска, и для high-risk обязывает делать human oversight. Цена вырастет, но не факт что критично - тот же mandatory peer review для AI-изменений у Amazon это по сути бесплатный guardrail, просто раньше не додумались включить.
Рабочий приём. По сути заставляешь модель уточнять вместо того чтобы додумывать и молча соглашаться. В статье из Johns Hopkins про это тоже - вопросительная формулировка снижает сикофантию, а тут ты ещё и модели разрешаешь спрашивать
Не умнее, скорее лучше оптимизирован под конкретную задачу. Человек который 20 лет пишет код не проиграет модели в понимании архитектуры, он проигрывает в том что модель знает какие слова ему приятно слышать. Это разные скиллы
Про Адизеса хорошо. Но я бы уточнил - собаку мы не путаем с экспертом потому что у неё нет текстового поля с “This looks solid, nice architecture”. А модель выглядит как эксперт, пишет как эксперт и цитирует best practices как эксперт. Граница размывается не потому что мы глупые, а потому что мимикрия слишком хорошая
Вот и наглядная демонстрация) Kimi даже не попытался сказать что идея дурацкая, сразу перешёл к бизнес-плану. Ниша занята - это убило
Или пишешь вопросами а не утверждениями - в статье как раз про это, Johns Hopkins показали что формулировка влияет. “Я решил сделать X” получает одобрение, “стоит ли делать X” получает нормальный ответ
Ну да, про это и пишу в статье по сути - бизнес-модель стимулирует мягкость. Но промпт “be adversarial” реально меняет поведение, проверял. Не до уровня анонимного Васяна конечно, но хотя бы начинает говорить “тебе тут не нужен отдельный сервис, можно обойтись одним классом” вместо вечного “great architecture”
Хорошая мысль про тренировочные данные. Статьи, туториалы, readme - всё написано в стиле “вот как правильно”. Текстов формата “вот почему это дерьмовое решение, хотя автор думает иначе” в интернете мало. Ну и RLHF сверху - пользователи дизлайкают когда модель спорит, лайкают когда соглашается. Двойной отбор в сторону поддакивания получается
С легаси работает, потому что ты чужой код кидаешь без эмоциональной привязки. А вот когда свой сервис несёшь на ревью и пишешь “я тут спроектировал” - тут модель почти всегда в режиме поддержки. Попробуй тот же код кинуть без контекста авторства, просто “оцени архитектуру” - разница в ответах бывает прям заметная
Проблема с извлечением цифры решается проще - Ollama поддерживает параметр format в запросе. Если передать JSON-схему типа {“choice”: int}, модель вернёт структурированный ответ без второго вызова. Два запроса вместо одного на каждый выбор - двойной расход токенов на весь прогон
15 секунд на git clone - это не модель думает, это overhead промпта, API, отрисовки, апрува. На одиночных командах агент всегда медленнее. Ценность на многошаговых - пайплайн, настройка сервера, ansible роли. Автор и сам это показал: на clone раздражает, на Flask+Docker+pipeline впечатляет
Статья доказывает что SPEC.md Symphony ≈ код. Ну да, там схемы БД, формулы ретраев, псевдокод - оно и есть код в markdown. Но реальный паттерн другой. CLAUDE.md, .cursorrules описывают не реализацию а ограничения - “используй repository pattern”, “не лезь в БД из вьюх”, “тесты кладём в tests”. Модель заполняет детали сама. Дейкстра про узкие интерфейсы прав, но ограничения и так узкие
Ну смотри, дефицит 1.5 млн это прогноз red_mad_robot/Сбера, не мой. Я сам в статье написал что Сбер одновременно сокращает 13.5 тысяч и жалуется на нехватку кадров, и что это плохо стыкуется. Про промпт инжиниринг согласен, но тут скорее не “профессия исчезла” а её неправильно назвали - люди которые это делали просто стали обычными пользователями LLM
Про агентов на одноплатниках я в статье сам оговорился что для edge это норм, ирония была в контрасте со словами «третий полюс», не в самой технологии. Про GigaChat = дотренированная открытая модель - Сбер прямо утверждает что обучают с нуля без открытых архитектур, я на CNews сослался где Фролов это объясняет. Можно не верить конечно. А сценарий с батником и пропагандой реально смешной, жаль что не выглядит нереалистичным
Про агентов на одноплатниках я в статье сам оговорился что для edge это норм, ирония была в контрасте со словами «третий полюс», не в самой технологии. Про GigaChat = дотренированная открытая модель - Сбер прямо утверждает что обучают с нуля без открытых архитектур, я на CNews сослался где Фролов это объясняет. Можно не верить конечно. А сценарий с батником и пропагандой реально смешной, жаль что не выглядит нереалистичным
Да, спасибо за ссылку. Я в статье сослался на foundevo который этот отчет разбирает, но прямая ссылка на a16z конечно полезнее
Ага, я к тому же выводу прихожу в статье - обе версии не взаимоисключающие. Просто Amazon пытается свести к “user access control issue” и снять вопрос, а FT акцентирует автономность агента. На практике это два слоя одной проблемы - и оба надо фиксить. Права ограничить И checkpoint перед деструктивными действиями добавить
Ну да, классика NIH синдрома. Только тут масштаб другой - обычно NIH это когда переписывают библиотеку потому что “мы знаем лучше”, а Amazon заставил 80% инженеров использовать свой инструмент вместо того который те сами выбрали. И потом удивились что что-то пошло не так
Ну да, если инструмент реально хороший - люди сами подтянутся. Когда Claude Code появился, никто не заставлял его использовать, просто кто-то попробовал и рассказал коллегам. А тут 1500 человек прямо говорят “мы уже нашли что работает лучше” и им в ответ KPI. Это даже не ленивый менеджмент, это менеджмент который активно игнорирует фидбек от собственных инженеров. Ну и результат соответствующий
Двухуровневая система - да, примерно так Claude Code и работает. Есть глобальные permissions в settings.json от команды/компании, а есть CLAUDE.md в проекте где разработчик описывает что можно а что нельзя. У Kiro видимо ничего такого не было, просто operator-level доступ на весь scope. Про бесполезные KPI - ну 80% weekly usage как OKR для менеджеров это прям учебник по Goodhart’s Law, когда метрика становится целью она перестаёт быть метрикой
Про тросик в положении “полный газ” - ладно, тут ты меня поймал, плохой пример был) Про ответственность на создателя - а ведь так и будет скорее всего. EU AI Act уже классифицирует AI-системы по уровню риска, и для high-risk обязывает делать human oversight. Цена вырастет, но не факт что критично - тот же mandatory peer review для AI-изменений у Amazon это по сути бесплатный guardrail, просто раньше не додумались включить.