Перейти к содержимому

Мнения экспертов

Идеи и подходы опытных инженеров и авторов инструментов к разработке ПО в эпоху ИИ.

17 избранных материаловСвязанные темыОбсуждения в сообществеРазработка по спецификацииРевью кода

Новые избранные материалы

Материалы 1–17 · Всего 17
Сегодня06.10вт
  1. DEV Community · MCP78

    Инъекция промпта — это проблема плоскости данных: переносим границу от модели к вызову инструментов

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

    Почему это важно: Автор проводит аналогию между инъекцией промпта и SQL-инъекцией и предлагает перенести границу с уровня модели на уровень вызова инструментов, а также приводит практичную схему: стратегический слой и поэтапное разделение чтения и записи.

  2. DEV Community · MCP82

    Навыки — это не инструменты: автор разбирает, почему 11 MCP Server тормозят ИИ-агента для разработки

    В феврале автор подключил к ИИ-агенту для разработки 11 MCP Server, и в пустом сеансе только список инструментов занимал 34,000 токенов; один Datadog добавил больше двухсот инструментов, из-за чего агент замедлился и стал часто выбирать не те инструменты.

    Почему это важно: На своём опыте с 11 MCP Server, которые перегрузили контекст, автор показывает, что инструменты и знания должны лежать в разных «контейнерах».

04.10вс
  1. 宝玉82

    Опираясь на содержание подкаста, Баоюй рассказывает, как Лорен Тан из SpaceXAI, работающая над Grok Bot, за месяц смёрджила 2500 пул-реквестов: вечером она даёт ИИ самостоятельно всё проверить и смёрджить, а утром лишь выборочно просматривает результат, не проверяя каждый PR по отдельности.

    Цитатаlauren@poteto

    i had a lot of fun chatting with @mattpocockuk today about how i was able to land 2,500 PRs last month! Matt is a wonderful interviewer so i think the interview turned out really interesting both of our skill plugins work great together, so i recommend giving both a try and picking the best skills that suit your workflow https://www.youtube.com/watch?v=MN9dGgmLyso

    Почему это важно: На примере Лорен Тан, которая за месяц смёрджила 2500 пул-реквестов, Баоюй показывает, что отказ от построчного ревью возможен только при проверке навыками и ограничениях в виде правил, и описывает условия, при которых этот подход применим у него самого.

14.09пн
  1. Addy Osmani · Blog80

    Эдди Османи о том, как внедрять ИИ-агентов в легаси-кодовую базу

    Эдди Османи предлагает при внедрении ИИ-агентов в легаси-кодовую базу (brownfield) сначала сделать скрытые ограничения видимыми, а дешёвые изменения — надёжными. Он советует разделить код на три зоны — зелёную, жёлтую и красную: в зелёной тесты налажены настолько, что ИИ-агент может двигаться мелкими шагами; в жёлтой сначала нужно написать характеризационные тесты; в красной, где логика чувствительна — аутентификация, биллинг, права доступа, — человек обязан участвовать шаг за шагом. Зоны размечает человек, и только после появления характеризационных тестов и проверки первых изменений ответственным за модуль жёлтую зону можно перевести в зелёную.

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

07.09пн
  1. Armin Ronacher78

    Армин Ронахер: почему GPT‑6 Astra вызывает у меня недоверие, когда пишет код

    Армин Ронахер провёл выходные за экспериментом с «фабрикой софта» на GPT‑6 Astra: модель сама управляла контекстом и подагентами, а целью была реализация Python с виртуальными потоками и лексической областью видимости.

    Почему это важно: Автор показывает, что дал эксперимент с «фабрикой софта» без присмотра на 35 часов: на конкретных примерах видно, как GPT‑6 Astra жертвует читаемостью кода ради экономии токенов.

05.09сб
  1. Ryan Lopopolo66

    Платформа агентов, созданная для разработки агентов: отделяем интерфейс возможностей от реализации

    Автор Райан Лопополо утверждает: агент — это параметризованная программа, построенная на наборе возможностей. Среди них — модели и конфигурации, цикл рассуждений и вызова инструментов, компьютеры, диски, контекст, Skills, инструменты, коннекторы, среда выполнения, сетевые политики, идентификация, IAM, гардрейлы, каналы ввода-вывода и системный промпт.

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

14.08пт
  1. InfoQ · AI Coding Presentations80

    Доклад на InfoQ: 300 точных токенов лучше 10 тысяч шумовых — архитектура контекстной инженерии

    Барух Садогурский и Патрик Дебуа на докладе в InfoQ показали вживую на Claude Code: если загрузить всю проектную документацию в CLAUDE.md, то добавление обработки ошибок к интерфейсу возвращает 500 из-за конфликта соглашений; а после перехода на Skill с ленивой загрузкой по описанию тот же промпт проходит тесты.

    Почему это важно: На этом же примере авторы разбирают четыре антипаттерна контекстной инженерии и показывают, как с ними справляются Skill, каналы поиска, внешняя память и оценка.

20.07пн
  1. Addy Osmani · Blog74

    Эдди Османи о «фабриках ПО»: явные и скрытые фабрики, где узкое место — проверка

    Эдди Османи описывает «фабрику ПО» как три уровня: loop, harness и factory. Фабрика — это не более умный ИИ-агент, а несколько loop с harness, которые сходятся в один шлюз проверки, а внешний цикл остаётся под управлением человека.

    Почему это важно: Автор разбирает «фабрику ПО» на три уровня — loop, harness и factory — и показывает, что настоящее узкое место — проверка, а не генерация.

17.07пт
  1. Ryan Lopopolo71

    Code Red требует цикла поддержки: с помощью Codex /goal превратить аварийный ремонт в постоянную эксплуатацию

    Автор, опираясь на опыт участия в первом code yellow в Stripe, отмечает, что после большинства code red остаются лишь разбор инцидента и уставшие инженеры, а метрики снова оказываются без внимания. Он считает, что после каждого code red нужно запускать цикл поддержки и использовать команду /goal в OpenAI Codex, чтобы превратить разовый запрос на написание кода в постоянную цель с чёткими критериями завершения: тогда постоянно работающий кластер ИИ-агентов будет следить за метриками, выполнять нужные действия и запрашивать ручную проверку.

    Почему это важно: Опираясь на опыт code yellow в Stripe, автор предлагает с помощью /goal в Codex превратить разовый аварийный ремонт в долгосрочный цикл поддержки, который можно перенести в управление SLO.

08.05пт
  1. 宝玉78

    Почему участники команды Claude Code используют HTML вместо Markdown для вывода ИИ-агентов

    Участник команды Claude Code Тарик предложил использовать HTML вместо Markdown в качестве формата вывода ИИ-агентов. По его словам, HTML плотнее по информации, его удобнее передавать и он поддерживает двустороннее взаимодействие, а главное преимущество Markdown — простота редактирования — потеряло значение после того, как он перешёл на правки через промпты.

    Почему это важно: Участник команды Claude Code объясняет, почему для вывода ИИ-агентов выбран HTML, а не Markdown, и приводит промпты, которые можно сразу использовать, а также подходящие сценарии.

05.05вт
  1. 宝玉78

    Борис Черный: после Claude Code написание кода превращается в управление агентами

    Создатель Claude Code из Anthropic Борис Черный в интервью на Sequoia AI Ascent рассказал, что за весь 2026 год не написал ни одной строки кода, ежедневно мержит десятки пул-реквестов, а в отдельные дни — до 150, большую часть работы делает со смартфона, постоянно держит открытыми от 5 до 10 сессий и несколько сотен агентов, а ночью ещё несколько тысяч агентов выполняют сложные задачи.

    Почему это важно: Борис Черный разбирает путь Claude Code от инкубации до выручки в миллиард долларов и делает выводы: программирование как задача решена, рвы SaaS-компаний срыты, а преимущество даёт организация процессов.

10.04пт
  1. claude.dev · Anthropic Developer Blog74

    Anthropic 工程师谈 Claude Code 的工具设计：如何像智能体一样思考

    Anthropic 的 Thariq Shihipar 复盘了 Claude Code 工具设计中的取舍，核心主张是工具要贴合模型自身能力，而判断能力边界只能靠观察输出和反复实验。

    Ожидает перевода

    Почему это важно: Anthropic 工程师复盘 Claude Code 工具设计的取舍，给出可迁移到自建智能体的判断方法。

  2. Ryan Lopopolo65

    怎样才算把活干好：写清非功能性需求才能让 AI 智能体收敛

    Ryan Lopopolo 认为，AI 让验证问题变得明显，因为每个真实任务都依赖一个我们几乎从不写下来的问题，即怎样才算把活干好。产出和评审都涉及语气、品味、风险容忍度、打磨程度、可接受的捷径和完成标准等大量非功能性决策，过去团队靠组织设计、社交规范、招聘和入职把这些隐含规则传递给人，而模型无法走招聘流程，因此交给它的任务基本都欠规范。

    Ожидает перевода

    Почему это важно: 作者以在 OpenAI 做代码智能体的经历说明，非功能性需求不写下来，评审智能体就会陷入无休止的拉扯。

07.04вт
  1. Jesse Vincent74

    如何用门禁而非规则约束 AI 智能体行为

    Jesse Vincent 在构建 Superpowers 时提出，提示词中的门禁（gate）比规则（rule）更能约束 AI 智能体：规则留有自我说服的退出路径，门禁则要求满足条件才能进入下一步。

    Ожидает перевода

    Почему это важно: 作者用自家智能体的实例区分规则与门禁，给出可迁移的提示词写法，帮助减少智能体跳过验证的行为。

13.03пт
  1. Ryan Lopopolo71

    别再把代码当成最终产物：Symphony 作者谈规范驱动开发

    Ryan Lopopolo 以 Symphony 为例提出，代码不应被视为最终产物，规范才是分发物。Symphony 是一个基于 issue tracker 的智能体编排系统，先以 SPEC.md 形式分发，Elixir 参考实现只是衍生产物，README 邀请读者把 SPEC.md 交给自己的编码智能体，用任意语言重建。

    Ожидает перевода

    Почему это важно: 作者用 Symphony 的 spec 蒸馏循环说明代码只是可替换产物，为规范驱动开发提供了一条可迁移的路径。

  2. Ryan Lopopolo74

    智能体时代的生产函数变了：实现不再稀缺，验证才是

    作者认为，软件组织一直把人的实现时间当作稀缺投入，智能体打破了这个假设，因此策略必须可执行、验证必须随实现规模扩展。他以在大型 TypeScript 代码库开启 ESLint 的 no-await-in-loop 规则为例，发现 600 处违规，过去这需要昂贵的迁移，现在一个 PR 就能完成修复并补齐测试覆盖。

    Ожидает перевода

    Почему это важно: 作者以开启 ESLint 规则、迁移 600 处违规的亲身实践，说明智能体时代实现成本下降后，约束与验证为何成为新的稀缺环节。

30.01пт
  1. Jesse Vincent66

    Latent Space Engineering：用情绪化提示词让 AI 智能体进入更好状态

    Jesse Vincent 提出 Latent Space Engineering，即通过提示词把模型推入更有利于完成任务的潜在空间，而非只往上下文窗口塞事实信息。

    Ожидает перевода

    Почему это важно: 作者提出用情绪化提示词把模型推入更佳状态，并给出多个可迁移的实操例子。