Ежедневная рутина с Claude

Модель или обвязка?

Если вы разрабатываете ИИ-агентов для продакшена, эту статью стоит сохранить.

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

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

Подход также подходит для автоматического анализа. В тестах на четырёх передовых моделях лучший ИИ-судья достиг коэффициента согласия Коэна 0,76 по сравнению с ручной разметкой. Это позволяет автоматически классифицировать ошибки прямо в продакшене, а не разбирать их вручную после каждого инцидента.

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

Статья: https://arxiv.org/abs/2607.28802

Совет по вайбкодингу: попросите Codex создать интерактивную карту вашего репозитория, а затем отмечать, какие модули изменились с момента её генерации.

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

Он создаёт:
→ docs/codemap/codemap.html
→ docs/codemap/codemap.json
→ docs/codemap/codemap.lock

Полный промпт ↓

Analyze the current codebase. Do not modify product code. Only create or update files under docs/codemap/.

Ignore vendor, build, dist, cache, and other generated directories.

If docs/codemap/ already exists, first compare the existing codemap.lock with the current repo and list the modules that changed. Then regenerate these three files together:

1. docs/codemap/codemap.html

Build a fully self-contained interactive code map that opens directly in a browser. Include:

- major modules, services, databases, queues, and external dependencies
- no more than 20 primary nodes; group low-level files under their parent module
- calls and data flows between modules
- the 3-5 most important end-to-end flows
- a clear dark theme by default
- system boundaries and the most important data flows visible on the first screen
- color-coded module types with a simple legend
- automatic layout that minimizes crossing edges
- clicking any module highlights its upstream callers, downstream dependencies, related tests, and the flows it belongs to
- selecting a flow highlights its complete path
- search, filtering, zoom, and drag controls

At the top, show the repo name, generation time, and the commit it was generated from.

2. docs/codemap/codemap.json

Use this structure:

{
"generated_at": "",
"generated_from_commit": "",
"scope": [],
"nodes": [],
"edges": [],
"flows": []
}

Each node must include:

- id
- path
- role
- entrypoints
- tests
- constraints
- evidence

Each edge must include:

- from
- to
- type
- evidence

type may only be:

- imports
- calls
- reads
- writes
- publishes
- subscribes

Each flow must include:

- trigger
- steps
- outcome

Every step must reference an existing node id.

Attach the matching source path and symbol to every node and edge. Mark any relationship without source evidence as unknown. Do not guess.

3. docs/codemap/codemap.lock

Use parseable JSON to record:

- the current commit
- whether the working tree has uncommitted changes
- generation time
- scanned scope
- excluded directories
- the fingerprint algorithm
- a deterministic fingerprint for each top-level module, calculated from its tracked file paths and current file contents

If no existing codemap.lock is found, treat every module as new and generate the full map.

When finished, verify that:

- codemap.json parses successfully
- every node path exists and every evidence symbol can be found in the source
- every edge and flow step references an existing node
- codemap.html and codemap.json use the same nodes, edges, and flows
- codemap.lock matches the current commit, working tree state, and module fingerprints
- every relationship without source evidence is marked unknown

These three files must always be generated together from the current repo. Never edit only one of them manually.

Finally, show:

- files created or modified
- stale modules
- remaining unknowns
- validation results
- the complete diff

Ещё один момент. Добавьте правило в AGENTS.md, чтобы карта кода всегда оставалась синхронизированной с репозиторием:

At the start of every code-changing task, compare the current repo with docs/codemap/codemap.lock.

Before modifying a module, use docs/codemap/codemap.json to answer three questions:

1. What calls it?
2. What does it affect?
3. Which tests cover it?

If the map is stale or cannot answer those questions, regenerate codemap.html, codemap.json, and codemap.lock before changing the code.

Whenever module boundaries, dependencies, routes, databases, queues, or major data flows change, update the code map in the same commit as the code.

Firecrawl запустил anydoc — их новый движок для парсинга документов на Rust

Он конвертирует PDF, Word-документы, презентации и ещё 10 форматов в Markdown менее чем за 5 мс, сохраняя одно из лучших качеств обработки в индустрии.

100% опенсорс