---
title: 'Ex-NASA Dev Reveals His Agentic Engineering Workflow'
source: 'https://youtube.com/watch?v=xgkjtF89-44'
video_id: 'xgkjtF89-44'
date: 2026-09-03
duration_sec: 3517
channel: 'David Ondrej'
---

# Ex-NASA Dev Reveals His Agentic Engineering Workflow

> Source: [Ex-NASA Dev Reveals His Agentic Engineering Workflow](https://youtube.com/watch?v=xgkjtF89-44)

## Summary

In this podcast episode, host David Andre interviews Dexter (Dex), a former NASA developer and creator of the term 'context engineering,' about his unique approach to AI agentic software development. They discuss why traditional benchmarks are flawed, the concept of a 'software factory' where AI agents work autonomously, and the importance of 'program design' over code review. The conversation also covers practical strategies for building maintainable systems with AI, the role of context engineering, and the future of AI in software development.

### Key Points

- **Program Design Over Problem Solving** [00:01] — Dex emphasizes that most people focus on solving problems but overlook 'program design'—the phase before letting an agent work, where you define measurable outcomes to guide the agent's decisions.
- **Dexter's Background and Software Factory** [00:29] — Dexter coined 'context engineering' and built a software factory where AI agents worked for four months without human intervention. He is known for his unique system of program design.
- **Why Benchmarks Are Misleading** [00:56] — Dex argues that many benchmarks are one-off problems—quick, disposable fixes—and don't reflect real-world, long-term software development. They fail to measure maintainability or the ability to evolve a codebase.
- **The Software Factory Concept** [01:23] — Dex describes a pre-AI software factory: a team, a task list, a state machine, and a build process. The AI version replaces 'human builds thing' with 'agent builds thing,' but the rest of the pipeline remains similar.
- **Optimizing for Review Time** [02:42] — Before agentic factories, teams spent hours or days building and reviewing. The goal was to optimize upfront hours to save review hours, ensuring the PR matches the explanation and requires minimal changes.
- **The Review Bottleneck** [03:23] — Even with agents, code review remains a bottleneck. Dex suggests using multiple models (e.g., Codex and Opus) to cross-check changes, and directing incidents directly to the factory to reduce human intervention.
- **Real-World Implementation** [04:19] — Dex shares his current project, Deep API, where he uses GLM 5.2 to analyze incidents automatically. He describes a workflow where incidents are triaged by AI, and fixes are proposed without manual analysis.
- **Deployment Infrastructure** [05:01] — Dex runs his system using cron jobs on Vercel and GitHub Actions, with render.com hosting a small agent loop. This setup allows for automated incident handling and feature requests.
- **Closing the Loop** [06:33] — Dex discusses the importance of closing the loop: if an agent can handle even 30% of incidents, it's a huge step. Automating 50% of work means you can ship twice as much, focusing on strategy and features.
- **Avoiding Code Review** [07:11] — Dex advocates for a system where you read as little code as possible. He invests in testing, regression, and CI/CD improvements so that agents can self-verify, reducing the need for human review.
- **The Risk of Losing Touch** [08:42] — Dex acknowledges the risk of losing connection with the codebase. He suggests slowing down and using visualizations to maintain understanding, but emphasizes that the benefits of automation often outweigh this risk.
- **The Failure Mode** [09:39] — Dex describes a scenario where an agent can't solve a problem, and you have to dive into a codebase you haven't read in months. This happened to him in July 2025, leading to a painful debugging process.
- **Code vs. Logic** [10:45] — Dex argues that you don't need to read code, but you do need to understand the logic—the product's behavior, API schemas, and edge cases. This is more about product knowledge than code syntax.
- **The Product-First Approach** [11:38] — Dex emphasizes starting with the product problem: what user problem are we solving? He suggests running experiments on your website to test different approaches and using data to decide what works best.
- **Agents Testing Themselves** [12:47] — Newer models (like Fable and 5.6) are better at self-testing, using LLMs as judges to evaluate cost, speed, and quality without explicit instructions. They also improve at computer and browser use.
- **Measurable Outcomes** [13:11] — Dex stresses the power of defining a measurable outcome (e.g., conversion rate) that directly ties to business success. This gives agents a clear goal to optimize for, making their work more aligned with business needs.
- **PRD-First Development** [13:53] — Dex shows a PRD he created for Humanlayer, describing the problem and solution before writing code. He advocates for writing a blog post or documentation first to clarify the value proposition.
- **Designing the User Experience** [14:18] — Dex emphasizes designing the user-facing experience (e.g., HTML mockups) before architecture. This ensures you know what you're building and why, reducing the need for manual changes later.
- **System Architecture and Review** [15:14] — Dex discusses the importance of system architecture in reducing review time. He suggests documenting service interactions, new endpoints, and database schemas upfront to guide agents and reviewers.
- **When to Skip Program Design** [16:17] — Dex notes that if you're a startup without product-market fit, you might skip heavy program design. But for teams with paying customers, it's crucial to ensure maintainability and support.
- **Leverage in Program Design** [17:11] — Dex talks about using 'leverage'—spending a little time upfront to avoid many fixes later. He references a tweet by Malroy from Cloudflare about planning call stacks before building.
- **Design Before Code** [17:38] — Dex argues that once a model writes thousands of lines, it's hard to redirect. Designing with low-context sessions (e.g., 43k tokens) allows for efficient decision-making before implementation.
- **Vertical Slices** [19:21] — Dex recommends vertical slices—building a small end-to-end feature (e.g., a stub API, then frontend, then logic) to test as you go. This avoids the problem of models writing huge chunks that are hard to change.
- **Testing as You Go** [20:29] — Dex emphasizes testing with curl or manual checks after each small addition, similar to learning a new language by writing 'Hello World' and iterating. This catches issues early and makes redirection cheap.
- **The Cost of Bad Design** [21:27] — Dex notes that models can solve problems but not write maintainable code without help. He explains that RL training doesn't penalize bad design because there's no quick oracle for maintainability—it's measured in weeks and months.
- **Why Models Fail at Maintainability** [22:16] — Dex explains that RL training uses high temperature to generate many solutions, then evaluates them on task completion, not code quality. This leads to models that pass tests but produce messy, unmaintainable code.
- **Benchmark Flaws** [23:08] — Dex points out that benchmarks like SWE-bench don't penalize bad design. They only check if tests pass, not if the code is maintainable or follows good practices. This is a fundamental flaw.
- **New Benchmark Directions** [24:55] — Dex mentions new benchmarks from Cognition that use LLM judges to evaluate functional equivalence and quality rules, moving beyond simple test passing. This is a step in the right direction.
- **Testing the Tests** [29:08] — Dex describes a technique where you remove the model's patch and run its tests on the original code. If the tests don't fail, they're not actually testing anything—a way to catch useless tests.
- **The Impact of Better Models** [30:00] — Dex notes that models like Fable and Sole 5.6 are better at solving problems, but this is partly due to better training data and evaluation. He suggests that if a model knows the answer, it can write the code.
- **Balancing Speed and Quality** [30:56] — Dex discusses the trade-off between speed and maintainability. For startups without product-market fit, speed is key; for enterprise clients, you need to ensure stability and support.
- **The Program Design System** [31:36] — Dex mentions he has packaged his program design system, which is available for free via a link in the video description. It's a set of practices for working with AI agents effectively.
- **The Value of Human Intuition** [32:02] — Dex emphasizes that human intuition, gained from years of debugging and refactoring, is valuable. The challenge is to leverage this intuition without slowing down the AI-driven workflow.
- **Documenting External Context** [33:25] — Dex suggests documenting external elements (e.g., pricing, marketing strategy, environment variables) in Markdown files within the codebase. This gives agents the context they need without cluttering the code.
- **Context Engineering** [34:21] — Dex explains that context engineering is about managing the context window—what tokens you feed the model. He emphasizes that the only way to get better results is to feed the right tokens, not just more tokens.
- **The 12-Factor Context Engineering** [35:55] — Dex co-authored a paper in April 2025 called '12-Factor Context Engineering,' outlining 12 considerations for building agents. He says at least nine are still relevant today.
- **Context Window Management** [36:39] — Dex explains that everything you do with an LLM—prompts, RAG, history, memory—is just tokens. The key is to input the right tokens to get the best results, and to model the context window as program state.
- **Token Efficiency** [38:09] — Dex notes that using XML is more token-efficient than JSON in context windows. He also emphasizes minimizing irrelevant information to keep the context dense and specific.
- **The Origin of Context Engineering** [38:36] — Dex discusses the term's origin, noting that he and others (like Jeff Huber) independently coined it around the same time. He jokes about the Newton-Leibniz moment of simultaneous discovery.
- **The Spectrum of Prompting** [39:34] — Dex describes a spectrum: beginners give vague prompts, intermediates write perfect prompts, and experts give minimal context and trust the model. The goal is to get a strong signal with minimal tokens.
- **The Physics of Context Windows** [40:15] — Dex argues that context engineering is about the physics of attention mechanisms. Until we get post-transformer architectures, the principle holds: the smaller, denser, and more specific the context, the better the results.
- **The 'Stupid Zone'** [41:23] — Dex describes the 'stupid zone'—when a model's context window is too full, it starts making mistakes. He suggests compacting context into a document and starting a new session to avoid this.
- **Training Wheels for Context** [42:30] — Dex notes that the 'stupid zone' is like training wheels for beginners. With experience, you learn to manage context better, but it's still a real phenomenon for both models and humans.
- **The Goal Justifies the Means** [43:19] — Dex emphasizes that the end result matters more than the setup. He doesn't obsess over token efficiency; he cares about the product outcome. This is a key principle for working with AI.
- **The Exam Metaphor** [44:00] — Dex uses Calvin Frenchy's metaphor: a context window is like a student taking an exam. As time runs out, the student starts to panic and make mistakes. Models like Opus 45 and Sonic 45 exhibit this 'context anxiety.'
- **The Goal (Book Reference)** [44:53] — Dex references Eli Goldratt's book 'The Goal,' which teaches that you should focus on the bottleneck in a system, not on optimizing every part. This applies to software factories: find the constraint and fix it.
- **The Token Bank** [46:11] — Dex discusses the idea of a 'token bank'—how many tokens you can spend on a software factory. He suggests pushing boundaries to see what's possible, but always focusing on the bottleneck.
- **Elon Musk's Bottleneck Focus** [47:06] — Dex uses Elon Musk as an example of focusing on the biggest bottleneck, even if other parts are only 80% done. This principle applies to software development: identify the constraint and work on it.
- **The Trap of Over-Optimization** [47:45] — Dex warns against over-optimizing non-bottleneck parts of the system. He shares a personal story about being obsessed with CI/CD speed, but realizing the real bottleneck was elsewhere.
- **Entrepreneurial Skill: Identifying Bottlenecks** [48:50] — Dex says the most important skill for entrepreneurs is to look at a system and ask, 'Is this a bottleneck?' This helps you focus on what truly matters for success.
- **Letting Fires Burn** [49:17] — Dex advises that you need to let some fires burn—not every issue is critical. You must prioritize based on expected pain and impact, not just urgency.
- **RTS Games and Decision-Making** [50:02] — Dex compares decision-making in software to real-time strategy games, where you make hundreds of decisions per minute with incomplete information, weighing probabilities and expected outcomes.
- **Gambling in Business** [50:57] — Dex notes that founders are essentially gambling every day, making bets on what to build and where to invest. The key is to make calculated bets and avoid too many mistakes.
- **The Joy of Building** [51:24] — Dex emphasizes that if you enjoy what you're doing and learning, that's a good sign. He notes that many startups are building similar things, but the market is huge and there's room for many players.
- **Competing with Giants** [52:07] — Dex argues that you're not competing with Google or Anthropic directly; you're competing with their internal teams, which are often slow and bureaucratic. A small, passionate team can out-execute them.
- **The Mission of AI** [53:10] — Dex believes in a world where both large and small companies can innovate and solve problems together. He sees AI as a way to empower founders and challenge incumbents.
- **True Believers vs. Hype** [53:49] — Dex distinguishes between true believers in AI and those who are just there for the hype. He encourages focusing on the mission, not the noise.
- **Free Program Design System** [54:17] — Dex reminds viewers that his program design system is available for free via the link in the video description. He encourages people to download it and start implementing these practices.
- **AI's Unpopularity** [54:42] — Dex notes that AI is currently one of the most unpopular things in the world, citing a poll where it was less popular than ice but more popular than war with Iran. He stresses the need to address public concerns.
- **The Future of Work** [55:33] — Dex discusses the potential for AI to eliminate jobs, and the need for economists and policymakers to think about how the economy will function in a world with less human labor.
- **The Need for Convincing Answers** [56:14] — Dex argues that we need to provide convincing answers to non-technical people about how AI will make the world better, or they will resist it. He references the industrial revolution as a historical example.
- **The Echo Chamber** [56:41] — Dex warns about the echo chamber of Twitter and San Francisco, where everyone is excited about AI, but the general public is skeptical. He encourages engaging with people outside this bubble.
- **The Middle Path** [57:11] — Dex suggests that the most likely scenario is a middle path—steady improvement without singularity or catastrophe. He advises planning for this realistic outcome rather than extreme scenarios.
- **Where to Find Dex** [58:19] — Dex tells viewers to follow him on Twitter at @dexhorthy and visit humanlayer.com for more information. He also mentions the free program design system link in the video description.

### Conclusion

Dexter's insights highlight the importance of program design, context engineering, and focusing on bottlenecks in AI-driven software development. He advocates for a balanced approach that leverages AI's strengths while maintaining human oversight and intuition, ultimately aiming for a future where AI and humans collaborate effectively.

## Transcript

хорошо решать проблемы, но большинство людей упускают из виду то, что я называю проектированием программы.  Это как перед тем, как решений, которые вам могут не понравиться.
Если вы сможете указать измеримый результат, агент сделает для вас всё возможное. сделано, и если вы этого не сделаете, то, конечно, она может сделать это придумать лучший способ, до которого вы бы никогда не додумались.
Это Декстер, также известный как Декс.  Именно он придумал термин «контекстная инженерия», а также известен созданием программной фабрики, где агенты искусственного интеллекта работали четыре месяца подряд без какого-либо участия человека.  В этом
подкасте мы обсуждаем, почему бенчмарки не имеют значения, его уникальную систему проектирования программ и почему запросы на слияние (pull requests) устарели. Если вы хотите войти в 1% лучших инженеров-агентистов, досмотрите до конца. Это подкаст Дэвида Андре.  Наслаждаться.
Вы высказали мысль о том, что контрольные показатели не являются точным способом представления этом подробнее?   В основном, речь идет о том, что многие бенчмарки представляют собой разовые проблемы. Они быстрые, одноразовые, исправляют ошибки в тестах,
я не эксперт по машинному обучению , но я много изучал этот вопрос, потому что хотел сопоставить свое понимание с тем, как это работает в реальном мире. Пусть агенты, по сути, работают сами по себе.
Итак, программная фабрика существует с 1968 года, но я бы хотел представить её в свете реалий 2022 года, верно?   По сути, это как до появления ИИ, когда была команда людей, и они составляли список задач.
конечный автомат, ваша система отслеживания задач, и кто-то шел создавать это, а затем, в конечном итоге, вы делали запрос на слияние, запускали CI/CD и вещей, но по-прежнему проверяем код вручную.  Если что-то не так, мы возвращаемся
к процессу сборки.  В конце концов, проект попадает в продакшн, доходит до наших пользователей, они новые функции, и затем мы снова и снова повторяем этот цикл .  А потом мы ввели мониторинг, чтобы будить людей в 3 часа ночи, потому что,
в 3 часа утра, когда что-то ломается.  Но это ваша фабрика программного обеспечения еще до появления ИИ.  По сути, первое, что происходит после этого, — это замена фразы "человек строит вещь" на "агент строит вещь".  Я не
и моделирование.  Вам нужны все эти вещи, но, по сути, каждая вещь из вашего списка — это пандус, рабочая ОС, Brax, у всех них есть свои "миньоны" Stripe, у всех есть своя система, которая
это делает.  И это первое, что нужно заменить.  А большую часть остального вы, вероятно, оставите здесь.  И, по сути, сейчас эта часть занимает минуты или часы, а эта часть по-прежнему занимает часы или дни.  Думаю, до появления
агентских фабрик люди замечали, что на строительство и проверку чего-либо уходило несколько часов или дней.  И поэтому мы делали это, чтобы мы садились на чертово совещание и обсуждали с другими инженерами,
вместо того, чтобы тратить 6 часов на проверку, было больше шансов, что, например, «да, это то, о чем мы все говорили, запрос на слияние соответствует тому, что мы объяснили, и потребуется совсем немного изменений».  Таким образом, мы
хотим оптимизировать затраты часа на начальном этапе, чтобы сэкономить часы на проверке не создаём что-то неправильное и т.д. Этот отдел сейчас работает быстро, но эта часть всё ещё проверки кода Agentic, которая выявляет все мелкие недочеты.  А мы позволяем агентам просто
браузеров и тому подобного. И это ускоряет процесс, но если важный код, или любой его фрагмент, или весь код целиком, то это всё равно остаётся узким местом: как убедиться, что созданная система будет
замедлит вас через месяц? Если вы получаете десятки Это, безусловно, является узким местом. Вы говорите: «Хорошо, мы проверили Codex и Opus, и оба сказали, что
их исправили. Так что теперь я уверен, что запросов на новые функции, и меня не разбудят в 3 часа ночи из-за того, что например, направлять инциденты прямо в фабрику. Так что, когда
просыпаюсь не от оповещения, а от запроса на слияние. И мы можем сделать то же самое с запросами пользователей на новые функции, верно? Вместо того, чтобы проходить через напрямую агенту, и он просто исправляет ошибку». Вы
Да, я внедряю это настолько, насколько могу, честно говоря. Например, для моего текущего проекта, Deep API, у меня GLM 5.2.  Раньше я анализировал каждый инцидент, связанный с бесперебойной работой. Все подозрительные моменты или сбои раньше
мне приходилось сначала изучать и анализировать, или использовать для ИИ отчет: "Вот что произошло".  На самом деле это поставщик услуг.  Мы «Ага, это вызвано недостающей миграцией».  «Сделай это».
сейчас не работает».  Вам просто нужно сообщить об этом своим пользователям.  И вот, например, своем канале Discord или где-нибудь еще». Это круто. Где вы это запускаете? где-то в облачной песочнице? Это разделено между render.com и просто
заданиями cron в Vercel и GitHub Actions. Хорошо. Итак, у вас есть задания cron в Vercel, их получаете, а render.com запускает небольшой цикл агента, который делает Круто. Теперь запуск вашего приложения — это только
первый шаг. В тот момент, когда появляются пользователи, возникает вопрос: «На что они нажимают?»  Где они высаживаются?  «Что ломается?» И сейчас эта информация разрознена. У вас есть один инструмент для аналитики, один для опросов,
другой для отслеживания ошибок. Но с PostHog вы получаете все это на одной удобной платформе. Вы можете связать все свои источники данных и запрашивать все данные вместе с данными о вашем продукте. Таким образом, вы можете находить реальные корреляции и закономерности, а
не просто гадать. Также есть функция воспроизведения сессий, так что вы можете просматривать записи реальных пользовательских сессий, чтобы увидеть, где именно они зависают. Но, честно говоря, вам даже не нужно смотреть это самим. Новый инструмент ИИ PostHog,
Replay Vision, просматривает эти записи за вас. Он автоматически обнаруживает любые проблемы, и агент открывает запрос на слияние с точным исправлением. Все, что вам нужно сделать, это просто просмотреть его и объединить . В этом вся идея. PostHog делает
ваш продукт самосовершенствующимся. И это крайне важно, если вы разрабатываете программное обеспечение в 2026 году. Например, большинство людей не имеют представления о том, как отслеживать вызовы ИИ. Но PostHog делает все это за вас. Он отслеживает запрос,  Ответ,
стоимость токена и задержка. Всё для каждого пользователя. Таким образом, вы можете видеть, какие функции тратят деньги впустую, какие агенты работают некорректно, а какие подсказки действительно работают. Это то, что вам нужно для создания отличного продукта.
Вы можете попробовать PostHog бесплатно, перейдя по ссылке в описании. И видео. Это как когда люди говорят о полной программной фабрике, это как бы приближает нас к вопросу о том, как нам выйти из замкнутого цикла? Если что-то
может быть выполнено одним действием агентом, даже если это всего лишь 30% вашей работы, всего 30% ваших инцидентов, это огромный шаг. Это означает, что вы приближаетесь к если вы можете автоматизировать 50% своей работы, вы можете выпускать вдвое больше. И
теперь дело в том, чтобы запрашивать функции, развивать платформу, думать о стратегии, а затем как быстро вы можете Что приводит нас к этому  Одна вещь, которая, как мне кажется, не работает, — это облегченная «
мы просто не будем читать код». Как нам построить систему, в которой нам читать как можно меньше кода? Вы все еще проверяете запросы на слияние (PR), которые изменение, я сразу отправляю его в продакшн. Например, одно, возможно, спорное
опыта, чем у вас, поэтому, знаете, я должен это уточнить. Но у меня хорошее представление о том, что мне нужно сделать, верно? Если это небольшая корректировка фронтенда, я тысячи часов работы с ИИ, вероятно, более 100
часов с этими новыми моделями. Но я просто знаю, какие вещи могу доверять. Если я не уверен, опять же, я делаю основные вещи, верно? Проверяю это с помощью другой модели Frontier и провожу больше тестов сам.  И тому подобное.
когда вы хотите избежать проверки кода, вы вкладываете средства во все эти другие вещи. Вы делаете так, чтобы агент мог тестировать свои небольшое видео после завершения сборки. Это похоже на то, как это делают агенты в песочнице Cursor
улучшаете проверку кода с помощью агента. Вы значительно улучшаете регрессионное тестирование. Каждый раз, когда что-то не работает, вы выясняете, в чем была причина, и убеждаетесь, что этот конкретный режим ошибки никогда больше не повторится . Вы улучшаете
и делаете более надежными проверки CICD. Вы добавляете больше различных типов линтеров, мониторинг сложности и все такое. И теперь ваша задача действительно сводится к тому, сколько всего вы можете придумать? Сколько функций вы можете запросить? Сколько функций могут
запросить ваши пользователи? И вы можете запустить систему, которая вообще не думаю, что это работает, и это было своего рода моим откровением. И я имею в виду, я вы...  У вас может возникнуть ощущение, что если
вы можете полностью потерять связь с кодовой базой, верно? Поэтому, возможно, стоит добавить, что нужно действительно уделять время человек контролирует процесс? Знаете,
визуализации HTML и специально замедлять темп, когда Да, именно так. Быстро, если вы хотите получить точную будет доступна по первой ссылке под видео. Она совершенно бесплатна.
нас даже была функция прототипа, которую я в итоге не выпустил, но мы, возможно, вернём её: работает над чем-то, вы можете открыть сессию, и она проверит вас на и как она работает сегодня? А затем, как работает новая реализация
можете проверить своё понимание с помощью вопросов с несколькими вариантами ответа с такое. В общем, мы какое-то время этим занимались. Суть в том, что если вы перестанете читать код, вы можете (или обязательно столкнетесь) с
проблемой, которую агент не сможет решить. Вы скажете: «О, это идите и исправьте». И вот вы пытаетесь использовать все свои самые настойчивые подсказки, собираете вместе трех самых умных специалистов, чтобы обсудить это, а они все
продолжают выпускать исправления, которые на самом деле ничего не исправляют. И поэтому вам приходится заглядывать в кодовую базу, которую вы перестали читать 3 месяца назад, и тратить дни или недели, во-первых, продираясь сквозь некачественный код, потому что вы перестали
его читать. И во-вторых, пытаясь понять, что на самом деле не так. И это поэтому мы, можно сказать, выбросили наш проект. Мы сделали это примерно в июле 2025 года. У нас была небольшая программная фабрика, где мы действительно смотрели на ситуацию со стороны и не особо
просматривали планы и сотрудничали над задачами и списком дел, но мы не читали код. А потом мы столкнулись с ошибкой, и несколько недель мы думали: «Ладно». Наш сайт был в таком состоянии, что мы... ну, мы...
Мы выпускали настольное приложение, и оно было глючным, пользователи были недовольны, а мы мучились, продираясь сквозь кучу халтурного кода, пытаясь И это было просто ужасно. И у меня есть такая мысль: вероятность того, что
читать код, намного выше, чем вероятность того, что этого не произойдет, или же модели к тому времени станут достаточно умными, чтобы Может быть, я поспорю с вами насчет формулировки, верно? Код — это правильное
слово? Потому что код можно заменить логикой. Например, если вы понимаете базовую логику вашего программного обеспечения, используем ли мы определенную схему API хешированием и шифрованием? Если вы просто понимаете эти концепты, вам не
таковой. Вам нужно знать логику, например: «Хорошо, как выглядят первые 5 Как выглядит ситуация, когда кто-то пытается отменить заказ?  «Как выглядит срабатывание этой конечной точки API?» Возможно, я заменю слово «код»
То есть, знание того, что представляет собой продукт. Я перейду к тому, что мы делаем, а затем вернусь к тому, почему я так думаю. Мы проводим целое исследование в рамках обучения с подкреплением, и как очевидно . Но мы проходим
с помощью нашего инструмента, но вам не нужен никакой инструмент или какой-либо конкретный набор взгляд, является правильным подходом к согласованию с ИИ и возможном уровне. Первый этап — это часть, касающаяся продукта. Какую проблему пользователя
мы пытаемся решить, и, ? Потому что если вы можете провести эксперимент на своем веб-сайте и сказать: может попробовать три разных варианта, а затем ежедневно проверять данные и
решать, какой из них лучше.  Один из них работает лучше всего. Это невероятно. Теперь вы действительно работаете на И это то, что последнее поколение агентов делает намного лучше. Как я заметил, знаете, в Fable и 5.6 мне не нужно
что если они делают что-то среднего или большого масштаба, они стараются проводить гораздо больше тестов самостоятельно. Так что я думаю, да, в определенных областях все еще нужно думать о способах измерения и отслеживания, но по мере того, как модели становятся лучше, они
Когда вы говорите о тестировании, вы имеете в виду Нет, нет, нет. Например, если я создаю какую-то функцию, например, глубокое исследование или парсинг, и они меняют поставщика, они будут тестировать стоимость, скорость,
качество, знаете, используя LLM в качестве судьи, даже без моей просьбы протестировать это было в предыдущем поколении моделей. Более того. Они стали намного лучше осваивать работу с компьютером и браузером, и теперь
гораздо чаще делают это без указаний. Вся концепция здесь — это своего рода обратное давление, верно? Как можно взять то, что вы создали, и задать модели детерминированный результат?
могут проверять код и результаты, но если вы можете конверсия на моем веб-сайте, которая напрямую связана с успехом моего
получаю, с тем, сколько пользователей я конвертирую», — это невероятно мощно. целью». Если вы можете указать измеримый результат, агент исследование, верно? Это как просто ускорить ядро ​​CUDA, пока не
снижение потребления ресурсов на 20% или что-то подобное, верно? вещей  Мы обычно делаем так: я показываю документ, который мы создали. Вот, например, документ с описанием требований к продукту (PRD), который я сделал в Humanlayer, и в
рабочие процессы в Riptide. Там описана проблема, которую нужно решить, и Amazon: сначала пишем пост в блоге, а потом уже разрабатываем функцию. Думаем, как объяснить её пользователям и почему она
ценна, прежде чем писать хоть строчку кода. Мы создаём новый формат JSON, и к нему прилагаются кода. Мы создаём новый формат JSON, и к нему прилагаются это будет выглядеть. Я сделал много итераций, и в итоге мы создали
сделал много итераций, и в итоге мы создали с помощью обычного HTML, и, кажется, это работает очень хорошо. Но это уже нет архитектуры, мы не говорим о базах данных или схемах.  или
видит пользователь? Как пользователь распределяет пространство ? что вы на самом деле хотите создать и зачем, прежде чем Да. И люди говорят: «О, это просто лишняя работа», и
иногда так и бывает, верно? Можно бросить кости и посмотреть, что получится, но если разобраться, как это выглядит, можно многого добиться. Можно повысить не потребует кучи ручной
кучу изменений в пользовательский интерфейс или что-то еще . делать то, что вы им говорите, и никогда не будут указывать вам на то, что вы прогресса нет, и у вас по-прежнему нет пользователей. Так что, знаете, это
Так что, я имею в виду, вы упомянули понимание продукта, это системная архитектура, верно? Если вы хотите сэкономить время во время проверки, вы выбираете того, кто будет проверять PR. Конечно, если вы работаете в одиночку, это
если вы работаете в команде, то выбор того, кто будет проверять PR, очень важен. публичными компаниями, в основном с компаниями, получившими финансирование серии B и выше в сфере финтеха. С компаниями, надеяться, что всё заработает, верно? И думать: «О, если сломается, мы просто починим
завтра», потому что в этих отраслях, если что-то сломано, вас могут проверяют код и всё такое. И мы , верно? Например: «Вот как сервисы будут
новые конечные точки, которые мы собираемся создать. Вот новые таблицы, а затем схема запросов, которые мы будем выполнять». И это как бы спуск на ещё один Многие так делают. Многие достигли того
комфортно работать с моделями для проектирования Вы занимаетесь чем-то подобным? Я не на этом уровне, так что, знаете, ещё не там. Так что да. Другой момент, о котором здесь идёт речь, заключается в том, что бывают
моменты, когда нужно « настраивать код». Здесь речь идёт не столько о «настройке кода», сколько о чём-то другом. Например, если вы стартап, ещё не достигший соответствия продукта рынку, создавать, и вам нужно предложить
готовы платить, то это, вероятно, излишне. Но если вы работаете в любой команде, даже если это команда из пяти и более инженеров, где…  «Хорошо, люди, которые за это платят, и нам нужно убедиться, что это будет существовать
сможем это поддерживать». Это своего рода первый шаг. Думаю, большинство проектированием программы. Это как предварительный этап, прежде чем позволить агенту начать работу, — есть решения, которые он будет принимать, и которые вам могут не понравиться.
шаг ниже, например: «Вот как будет выглядеть стек вызовов программы Малрой из Cloudflare недавно написал об этом в твиттере, и это очень хорошо, большинство его планов заканчиваются так: «Вот как будут
выглядеть стек вызовов, когда мы начнем это строить». И опять же, самое часто использую слово «рычаг». Как можно потратить немного времени на начальном этапе, чтобы
Результат не потребует множества исправлений и изменений, прежде чем его можно будет объединить верно? Это, по сути, обратный твит Виктора Тали. Но, по сути, когда модели вносят изменения,
вас сомнения?» Да, это, по сути, делается до запуска модели. Точно. Да. Моё мнение таково: как только модель написала тысячи
или даже сотни строк кода, вносить изменения становится сложнее, Даже если вы используете много субагентов, контекст очень ограничен, и вы уже в некоторой степени предвзяты в одну сторону из-за того, что
Сессии, генерирующие подобную документацию, очень малоконтекстны. Например, Модель обладает всем необходимым пониманием, но делает это очень эффективно с точки зрения затрат токенов . У меня сейчас в работе один такой проект. Хм, дайте мне его открыть. Это что-то вроде
диалога туда-обратно. У нас уже 43 000 токенов, и мы уже приняли много решений. Мы прочитали PRD на этой сессии, и мы уже приняли будет работать, как будут выглядеть конечные точки, какой будет
поток, как это будет выглядеть на самом деле. Это наш программный дизайн. . Я даже не углублялся в программный дизайн. Но суть в том, что вы можете принимать многие из этих решений очень экономичным с точки зрения контекста способом, а это значит, что
вы получаете максимальную интеллектуальность модели, верно? Чем глубже вы находитесь окно, верно? Так что это, так сказать, сторона программного дизайна. мы будем помещать эти файлы?" Я уверен, что люди видят  Например: «Подождите, зачем вы
это один из вопросов, над которым вы можете долго размышлять в рамках
использовать вещи, которые очень легко быстро прочитать человеку и решить, правильно это или нет. Мы просто определяем типы и сигнатуры методов, но не обязательно углубляемся в детали реализации.
рекомендую делать, это то, что я называю вертикальными срезами. Мэтт Покок постоянно об этом говорит. Когда я выступал с ним, я даже делал с ним видео на YouTube в январе. Мы говорили о «трассирующих пулях». Основная идея в том, что модели любят
Им нравится делать всё в одной части кодовой базы на каждом этапе. И поэтому на этом пути нет ничего, сложность. Вы создаёте базу данных , сервисы, API и
оказываетесь по другую сторону тысяч...  строк кода, и , возвращаясь к нашей проблеме, когда код уже написан, перенаправлять его сложнее, и гораздо труднее внести существенные изменения
. Поэтому мы всегда рекомендуем использовать так называемые вертикальные срезы, системы. Но когда я разрабатывал код до появления ИИ, я всегда сначала создавал фиктивную конечную точку API. Затем [прокашливается] я создавал заглушку для фронтенда. Затем я дорабатывал
фронтенд. Затем я подключал его. Затем я делал бизнес-логику. Затем я добавлял обработку ошибок. Я никогда не видел, чтобы указывал ей порядок действий. Но это означает, что при
желании вы можете тестировать это по ходу работы вручную, с помощью curl, нужно заставить все работать от начала до конца, а затем добавлять логику и т.д.  Затем Да. Хорошо, вы говорите, что я понимаю, что никогда не видел модели, которая бы звучала так:
«Хорошо, я просто создам пустую версию этого конечного API-интерфейса, проверю, работает ли он, затем добавлю 50 строк и проверю, работает ли он». Всегда говорят: «Хорошо, реализация фронтенда плюс 500 строк на фронтенде».  «Тогда мы сделаем плюс 400».
помню, что раньше, до получения степени магистра права, я сам что-то создавал, не так было лет 15-16, и я разрабатывал мобильные игры, я делал это именно так. Я работать?» Хорошо, работает. Давайте немного усложним. Хорошо, всё ещё
Это как изучение нового языка программирования, верно? Вы пишете « Hello World», пока он не станет похожим на то, что вам нужно. Вы языка и понимаете суть проблемы по ходу работы. И
Я думаю, это отличный способ сэкономить кучу времени, особенно если вы всё равно будете читать весь код в конце. Так что вы можете посмотреть код.  и сказать что-то вроде: "О, мне не нравится, в каком направлении всё это движется"
.  Позвольте мне перенаправить курс сейчас, когда он дешев, вместо того, чтобы идти до самого .  А если это не так, то изменить это будет гораздо сложнее». верно? Например, первый клиент, нужно его привлечь и всё сделать. Вы же не тратите время на то, чтобы,
мол, «потратить 10 месяцев на разработку идеальной рекламной кампании в Facebook, чтобы потом получать 10 миллионов долларов в месяц». Никто И всё это основано на принципе: «Пока вам придётся
могут очень хорошо решать проблемы, но они не смогут написать поддерживаемый код без вашей помощи. У меня было такое ощущение, и у , и я хотел понять, почему. Поэтому я углубился в то, как на
и работают над этим, и, возможно, скоро это будет решено, но одна из вещей, на которой я сосредоточиваюсь, — это  На одном из таких сайтов я говорю: «Хорошо, если вы хотите решать проблемы сегодня, и
не хотите просто сидеть и ждать, пока выйдет GPT-7, надеясь, вам следует понимать на один уровень ниже, почему они плохо справляются с тем, в чем интуитивное понимание того, где нужно вмешаться, в отличие от того, как вы говорили
справится с этим хорошо, и мне не нужно быть в курсе». Поэтому у меня была такая Кэлвином Френч-Оуэном, который раньше работал над Codex. Мы, по сути, даем модели много раз, мы задаем высокую температуру, чтобы она пробовала много разных
А затем мы оцениваем каждый из этих результатов. Решила ли она задачу? Был ли код лаконичным? Подтвержден ли он извне? И затем мы подкрепляем результаты, верно? Мы берем результаты, которые сработали хорошо, и даем им...  Мы повышаем вероятность их
неудачные попытки и снижаем вероятность их повторения. задачи, то увидите, что за плохой дизайн здесь нет никаких штрафов. Все эти Bench multilingual, можно посмотреть на каждую задачу в этом списке.
золотой патч» для этой задачи. Правильный ответ — это всего лишь небольшие изменения, может быть, 100-200 строк кода, а затем новые тесты должны пройти после того, как
решать её так же, как это сделал человек , но тест, иногда немного рискованно, потому что это означает, что в зависимости от того, как но тест не пройдёт. Но это очень простая задача из
«Эй, если  Если вызвать эту функцию определённым образом, возникает исключение NullPointerException, и стек завершается с ошибкой . Решение, предложенное человеком, заключалось в том, чтобы, если значение равно nil, поместить его в пустой список. У нас есть тесты, которые,
по сути, означают: «Хорошо, после того, как модель закончила писать код, вот тест, который должен пройти». Таков масштаб и сложность некоторых из мы оцениваем это так: у нас есть формулировка задачи, и мы
проверяем кодовую базу на том уровне, на котором она находилась до того, как человек решил эту проблему с открытым исходным кодом в интернете, может быть, 10 лет назад. Агент пытается решить её, создаёт патч, а затем мы оцениваем его в изолированной среде. Таким образом, мы видим:
изменения, внесённые агентом в тест, потому что, я уверен, вы видели, как агенты, по сути, комментируют тесты, чтобы они прошли». Затем мы добавляем наши тесты и смотрим, проходят ли они. И, например: «Хорошо, исправили ли мы новую
проблему?»  «Сделали ли мы это, не нарушив ни одного из старых тестов?» Тогда вы В этом случае вам всё равно, есть ли это конкретное решение с открытым исходным кодом покажу вам, что делают некоторые из новых бенчмарков. Одна из
их задач — убедиться, что набор бенчмарков действительно прочитали много кода. Возможно, во время обучения модели уже видели этот код, этот запрос на слияние, этот репозиторий. Это совершенно
ортогональная проблема по сравнению с этой проблемой, которая не наказывает модель за неточность в написании кода. Просто не наказывает. И если модель получает 99% на SweBench, мне всё равно, потому что я знаю, что её не
она лучше справляется с решением задач, но это не заставит меня перестать Да, если она решает... Написание десятков тысяч, сотен бизнесе, понимаете? Поэтому, даже если технически это решает проблему,
инженера. Да, именно. И вот почему у нас появляются JSON.parse, и мы перехватываем ошибку, регистрируем её, а затем снова выбрасываем исключение или ничего не возвращаем, и это совершенно
Мы видим эти странные преобразования типов повсюду, когда кажется, что мы просто верно? И я думаю, что основная причина, по которой мы не проверяем качество, заключается в том, что обучении с подкреплением вам нужен то, что мы
сказать вам, было ли решение правильным или нет. А в поддерживаемости нет быстрого оракула, верно? Вы можете запустить тест за пару секунд, и вы можете запустить миллионы циклов обучения с подкреплением на тысячах задач и...
Можно сделать это довольно эффективно, но, по сути, функция стоимости плохой архитектуры измеряется неделями и месяцами. И вот, если вы принимаете неправильное выпускать продукты, делаете случайные вещи, и вдруг происходит инцидент из-за
чего-то, что случилось здесь, потому что код становится все более запутанным и нечитаемым, то очень сложно распространить это обратно во время обучения, чтобы модель больше так не делала. Другая
современными бенчмарками, заключается в том, что разработка программного обеспечения — это процесс обнаружения проблем по ходу работы. Вы выпускаете что-то, предоставляете это пользователям, получаете обратную связь, выпускаете что-то еще. И передовые, показывает, что модель знает всю проблему заранее. У нас нет
бенчмарка, который бы подавал модели пять признаков подряд и доказывал, кодовая база не просто решала проблему, но и упрощала внесение изменений, продолжал работать и развиваться.
Доверять бенчмарку. Знаете, в 2023, 2024 годах все смотрели только на него, но сейчас люди стали более скептически настроены. действительно полезен, — это большая проблема. Да, именно так. У меня есть несколько идей для
бенчмарков, где, например, у вас есть дорожная карта из 20 из этих функций заранее. Она получает их по одной. Я думаю [прокашливается], я чем бенчмарку, где просто: « Эй, клонируй весь Redis, напиши
200 000 строк кода на Rust, совместимого с Redis, и, о безумие. Так впечатляет». И возникает вопрос: « Да, но сможете ли вы будет полный хаос?» Есть новый бенчмарк.  от Cognition. Есть ещё пара
этом посте, но в основном, есть новая разработка от Cognition, которая движется в правильном направлении. Одна из самых интересных вещей, которую они делают, заключается в том, что у вас всё ещё есть история проблем, и люди создают эти проблемы. И вот вы
проверенную на этом этапе, LLM пытается её решить. И у нас есть верификатор, который спрашивает: прошёл ли новый тест? Ничего ли он не сломал ? Но затем у нас есть, так сказать, идеальное решение, и у нас есть LLM, который говорит:
хорошо, посмотрите, что написала модель, и посмотрите, что написал человек, и решите, функционально ли они эквивалентны. Или, может быть, модель упустила какую-то нюансированную деталь? Даже если тест провалился, потому что он не совсем
правильно сформулирован, решил ли он проблему? И это немного более гибко с точки зрения того, что мы не наказываем модель за написание кода иначе, чем это сделал человек, что интересно, но  Это не
Но самое крутое — это то, что у нас есть этот LLM-судья качества, верно? Это часть набора данных, содержащая множество правил качества, например: если вы пишете на C++, вы никогда не должны записывать лог вот так, вы должны записывать лог вот так.
патче и говорит: хорошо, лайк, дизлайк, соблюдаются ли правила? делают сегодня на своих программных фабриках. Самое новое, хотя и не совсем ново они смотрят на тест, написанный моделью, и говорят: хорошо, давайте
удалим патч модели и запустим тест на коде до патча. Тест проваливается там? И если он не проваливается на коде до патча, то это доказательство того, что модель написала тесты, которые на самом деле ничего не тестируют. Они
Так что, чтобы объяснить это проще, вы хотите...  Встраивайте и другие, менее очевидные вещи, которые можно обозначить как «вкус». Вы хотите извлечь слова из слова «вкус», что не очень полезно, и преобразовать их в числа, тесты
и, знаете, измерения. Именно. Да, как можно дать детерминированную обратную связь или что-то вроде того, как оцениваются модели качества кода. будете очень сфокусированы и скажете: « Да или нет, соответствовало ли это всем правилам?»,
вы сможете получить более стабильную оценку, чем просто « прошел ли код тесты». Так что мы движемся в правильном направлении, но опять же, может быть ограничена. Весь
совершенствуются в решении задач программирования, почему Fable немного меняет правила игры, и почему модели семейства Sole 5.6 меняют правила игры, заключается в том, что они действительно стали лучше решать задачи, но это благодаря тому, что мы сделали
и задачи становились все более сложными, и если модель могла ожидал это узнать, потому что вы пишете что-то с помощью Fable, а затем Codex проверяет это, то,
если вообще нужно проводить эту проверку, это повышает уровень, например, добавление большего количества токенов, вероятно, выявит все мелочи, но я не знаю. Это то, что я не могу точно
доказать, но все мои знакомые придерживаются такого мнения: если бы модель знала, бы смогла его написать . Мы все используем одни и те же действительно зависит от состояния бизнеса, верно? Потому что я знаю людей,
которые могут быть полностью уничтожены с первого раза и потратить 7 месяцев на создание идеальной системы, так и не получив первого пользователя. Я также знаю людей, которые, знаете, могут заниматься бизнес-частью, маркетингом, но, как вы сказали,
поддерживаемости, они сталкиваются с проблемами.  Всё плохо, потому что они, знаете ли, не прилагают усилий и понятия не имеют, что происходит. Так что, я думаю, дело в том, что у вас есть корпоративные клиенты, и вы хотите убедиться, что не потеряете их
соответствия продукта рынку, вам нужно действовать быстро, вы можете немного больше полагаться на модели , всё ещё пытаться проектировать архитектуру таким образом, чтобы она масштабировалась, всё ещё пытаться конечном итоге, если у вас нет клиентов, сначала выясните,
Да, на 100%. Кстати, я собрал в один пакет именно ту систему проектирования программ, которую использует Dex . Она доступна по совершенно бесплатна. Скачайте её прямо сейчас. Есть ещё один момент, который мне очень близок: Джейк
знаете ли, лучшим инженером по облачному коду Не думаю, что он когда-либо говорил это прямо, но создавалось такое впечатление. Он был своего рода агентного программирования задолго до того, как это стало широко распространенным, и он говорил, что
как программист, вы обладаете большим количеством с трудом приобретенной интуиции, будь то в программировании с использованием ИИ или без него , вы можете распознать плохой шаблон, когда видите его, потому что вы застряли, пытаясь исправить его в 2 часа ночи, или
потратили 3 дня на переделку, чтобы он стал действительно простым в обслуживании и так далее. И если вы не используете это, вы теряете деньги, качество, скорость, возможность выпускать высококачественный и стабильный продукт, вы
упускаете все это. И поэтому вся моя диссертация по этому поводу сводится к тому, вся моя диссертация по этому поводу сводится к тому, как мы можем взять этот запутанный чем хороши люди, чему мы можем доверять модели, а чему
нет, и как разделить это и определить правильный рабочий процесс, который вещи, которые модель не может сделать без человека. Как нам организовать этот хаос в набор шагов, идей или практик, которые позволят использовать
интуицию, не замедляя работу, как, например, идея проредить функцию на 2000 строк кода, а затем просто просмотреть весь код в конце? Мы хочет этого делать. Так как же нам, как нам, как нам, как нам, как нам, как нам, как нам, как нам, как нам, как вывести интуицию на более
ранний этап таким образом, чтобы это было легко, приятно, весело, интересно — позволить модели работать над тем, в чем она хороша? Я думаю, мой самый большой вклад в это — попытка добавить больше функций в
кодовая база — это все о коде, верно? Но, как вы сказали, модели становятся лучше, и есть много разных вещей, которые обычно наша маркетинговая стратегия. Это наш публичный имидж. Все
Но модели этого не понимают. Так что лично я  Я стараюсь в каждом проекте, даже самом маленьком, это важно. Мы запускаем ценообразование именно таким образом. Нет, мы никогда не
произойдут масштабные изменения, мы выпустим версию 2, чтобы не нарушать контракт. /docs/external. Например, как выглядят мои виртуальные переменные окружения? Конечно, не значения, но что там находится
выглядит моя настройка платежного процессора? Какие электронные письма я использую для тестирования? Где внешние элементы в кодовой базе, чтобы, были в кодовой базе в виде файлов Markdown,
Да. И это действительно интересная идея контекста в целом, как я обнаружил, и наш продукт работает так: все файлы находятся на планами, технической документацией или чем-то ещё...  Дело в том, что он просто использует файловую
систему, то, в чём он действительно хорош. А под капотом у редактировании файла синхронизировать его с облаком или уведомлять команду, а пользователи могут оставлять обратно. Всё это работает, но если вы можете создать среду, максимально приближенную
, а именно: чтение, запись, редактирование, grep, bash, то вы сделаете процесс получения контекста очень эффективным для всего этого в файловую систему — это очень, очень умно. Я уверен,
вы занимаетесь этим уже давно. Сейчас это кажется очевидным, но да, идея о том, как максимально эффективно использовать кодовую базу, чтобы не приходилось думать: «О, да, вам нужно включить этот сервер MCP,
проблемы». Все эти инструкции о том, как получить контекст, — это...  Тратить внимание модели, пока она пытается выполнить работу, впустую, в отличие от Буквально каждый раз, когда вы начинаете сессию, у вас есть «крючок», который говорит:
проблем на случай, если они нам понадобятся». Это бесплатно. Буквально бесплатно. Это как код, который выполняется. Он требует, знаете , циклов ЦП, но не требует для тех вещей, для которых модели действительно необходимы, а именно для
сложных проблем и совместной работы с вами над поиском решения, а затем Давайте поговорим о контекстной инженерии, потому что мы немного затрагиваем эту тему, и вы один из первых, кто её придумал. Так
из первых, кто её придумал. Так Да, я... я... я снова включу демонстрацию экрана. Эм, хорошо, мы написали это  В апреле-марте 2025 года, примерно 15 месяцев назад, вышла статья под названием «12-
раз, когда мы заговорили об инженерии контекста. У нас было около 12 разных моментов, о которых, если вы создаёте агентов, вам, вероятно, следует подумать. Я бы сказал, что по крайней мере девять из них всё ещё
получаете бесплатно, и они просто были внедрены в большинство инструментов, но вот самый интересный, тот, который запомнился больше всего, — это идея управления контекстным окном. По сути, это идея о том, что
всё, что вы делаете при работе с LLM, будь то написание скрипта, который создаёт подсказку и отправляет её модели для анализа выходных данных, или использование агента кодирования, который
вы указываете ему, где взять необходимые данные — это rag, история, память и механизм подсказок. Все эти вещи — это просто токены.  Ввод, вывод токенов, верно? Единственный способ получить лучшие результаты от
модели — это ввести больше токенов, ввести правильные токены в модель, не больше токенов, а именно ввести правильные токены . Так вы увеличиваете что единственный примитив, с которым вы можете работать, — это контекстное
окно, будь то список сообщений или просто одна большая подсказка, верно? Вы можете использовать системного пользователя, помощника, инструмент, системное сообщение, а затем...  У сообщения пользователя есть и другие отформатированные версии, но
этих контекстных окон, особенно для агентов, заключается в следующем: очевидно, кэширование стало очень важным, и это всегда будет обходиться вам очень дорого. Но для агентов действительно важно
понимать, что именно попадает в ваше контекстное окно, и тогда вы сможете делать буквально все, что захотите.  Таким образом, вы можете буквально смоделировать это как состояние в программе.  Вы можете просто преобразовать все произошедшее в подсказку и выгрузить
ее, и, если вы понимаете это буквально на уровне токенов, то, например, если я введу JSON в контекстное окно, это будет отличаться от ввода XML в контекстное окно, и использование XML более эффективно с точки зрения использования токенов.  Эм, это как бы то ни было, как
XML более эффективно с точки зрения использования токенов.  Эм, это как бы то ни было, как убедиться, что у вас нет никакой неверной информации.  Вы хотите убедиться, что свести её к минимуму. Это в равной степени относится как
к созданию конвейера ИИ на вашем бэкэнде, так и к тому, как вы представляете себе использование агента программирования?  Итак, это было в апреле 2025 года, а затем где-то в июне что они собираются это обсудить, и
я не знаю, что еще.  Я до сих пор не понял, — время от времени писал Андрей в Твиттере. Попробую посмотреть, откроется ли этот твит. Да, вот оно.  Каждый раз, когда кто-то пишет в Твиттере о контекстной инженерии, я прихожу и говорю им что-то вроде: «Ага, это было довольно
ответил.  Так что всё в порядке.  Андрей, я тебя прощаю.  Всё в порядке.  Вы не могли этого знать.  Возможно, это момент, подобный встрече Ньютона и Лейбница .  А на самом деле это Джефф Хубер из Да, я это знаю. Да, он также
опубликовал слова «контекст» и разместил твит примерно через две недели после почти уверен, что он это не читал.  Такое ощущение, что он это придумал, просто опубликовав два . Мне кажется, что многие люди
время. Но да, я не знаю.  Вот такая Да, я имею в виду, что, на мой взгляд, эта же концепция появлялась на протяжении истории, в когда множество людей приходили к одному и тому же выводу одновременно,
проблемах. Но да, я думаю, сейчас, главное — это изгиб новичков они очень низкие, говорят: « Исправьте это», и даже не предоставляют
журналов.  Те, кто находится посередине, тратят 30 минут на написание идеального задания, а те, кто застрял на месте, просто предоставляют один просто прочитай этот файл и исправь это».  Верно?   Да, именно так
Как сейчас обстоят дела с контекстным проектированием? Действительно ли это сводится к попытке получить как можно более сильный сигнал с как можно меньшим количеством токенов, чтобы не ограничивать возможности предложит лучшее решение?  Что вы думаете по этому поводу?
интересен.  Вы упомянули одну интересную вещь: упомянули одну интересную вещь: и это значительно повышает вероятность того, что вы получите именно то, что хотели.  А если вы
более широкий спектр вероятностей, верно?  То есть, возможно, это будет также может быть найден лучший способ, до которого вы бы никогда не контекстное проектирование и то, как вы задаете вопросы, и к чему
вы готовы?  Но я думаю, что многие концепции контекстной Это был несчастный случай.  Я не ставил перед собой цель считать, что большинство вещей в ИИ — это полная чушь, если подождать полгода, но думаю, что эта тема связана с тем, как
контекстная инженерия затрагивает физику контекстных окон и как работает механизм внимания трансформеров.  И пока мы не получим архитектуры типа post-post-transformer или линейное внимание, в принципе, всегда будет действовать принцип: чем
меньше, плотнее и конкретнее контекстное окно, тем лучше будут результаты. Теперь же уровень пола продолжает подниматься, верно?  Поэтому я не задумываюсь досконально над каждым токеном в контекстном
сложным, верно?  Как вы и сказали, если я вношу изменения в пользовательский интерфейс, я буквально говорю: «Вот что мне нужно». Я доверяю Codex, он программа прочитает пару лишних файлов, которые не имеют отношения к делу, это тоже нормально.
Кажется, система вполне способна достичь отметки в 200-300 тысяч токенов и при этом не немного говорили о «зоне глупости» в контексте нашей концепции, и вот что
инженеров, которые были относительно новичками в программировании для искусственного интеллекта.  Мы проводили что-то вроде и меня постоянно об этом спрашивали. Я подумал: «Окей, круто. Мы на этом этапе. Это было примерно с Opus 4.1, а затем с Opus 4.5».  Я подумал: «Окей, у нас
около 100 000 токенов, примерно 50% контекстного окна, 120 000 токенов. Пора делаем, сжать в , и запишите это в документ». А затем, по сути, начните новую сессию, опираясь на
этот документ, и продолжайте работать. И термин, который я придумал, был примерно таким: «Окей, круто».  Модель теперь находится в глупой зоне.  Вот опять же, я думаю, это скорее как вспомогательные колеса. Например, если у вас
нет интуиции, необходимой для получения степени магистра права, и вы не работали с агентами 70 часов, вы можете разобраться в этом примерно за 3 недели, общаясь с Клодом по 70 часов в неделю. нет, это совсем не то, и мне нужно начать сначала». Просто попробовав
пару раз. Так, я регулярно превышал 200, 300 тысяч токенов в зависимости от того, что я делаю, и думал: «Окей, у меня два... Мне просто лень заниматься этим, обрабатывать и передавать, начинать новую сессию». И компактизация тоже значительно улучшилась в
Да. Так что это уже не так, как «Вы должны Это пик...  Кривая среднего ума, верно? Это как с другой стороны, когда ты говоришь: «Просто делай то, что работает». У тебя есть интуиция, ты знаешь, что
получится. И если это не работает, один из вариантов — начать все сначала и Да. Я имею в виду, две самые большие ошибки, как ты сказал, это принцип «цель оправдывает средства». Если ты можешь получить
желаемый результат, и хорошо, может быть, использовать эту модель, использовать ту модель, использовать другой это не имеет значения. Многие люди тратят 80% времени каждый день на создание инструментов и 20% на свою [прокашливается]
таким человеком . Если у меня неоптимальная настройка, и у кого-то на один токен больше, чем у меня, меня это устраивает продукт. Но второе, что я бы сказал, это человеческий фактор.  То же самое и у
людей. Например, я могу легко потратить 3 часа прогулку и подумать: «Черт, это совершенно не имеет значения для бизнеса». И Да. Да, у людей есть «зона глупости». Если ты устал, твои результаты на самом деле... Это
Другая метафора, которая мне очень нравится, — это Кэлвин Френчи, парень, который основал Codex, Segment. Его метафора — это как контекстное окно. Это как студент, когда ты сидишь и сдаешь экзамен,
половину и думаешь: «Окей, круто».  У меня предостаточно времени.  Дайте подумать.  «Позвольте мне дойдя до середины, понимаешь, что осталось 5 минут, и И вот как это делают модели, особенно Opus 45 и Sonic 45. У
них была эта проблема, похожая на контекстную тревогу: сужается, и начинали халтурить. Они пытались что-то сделать, а потом просто сдавались.
я бы сказал, это самая большая проблема. Когда ты устаёшь и ленишься, результаты падают как для людей, так и для агентов. этой ерундой с максимизацией токенов. То, что вы сказали, это то, что мне не нужна
самая эффективная настройка. Мне нужно заботиться о результатах. Нет. Хорошо, вот этот парень, Эли Голдратт, написал книгу в 70-х годах, она называлась « Цель», и в ней была идея вот о чём...
История о парне, который пытается спасти фабрику. И, как я понимаю, в Америке в 60-х и 70-х годах фабрики работали так: там было множество станков, верно? И это также относится к
было много машин, и все думали: «Круто.  «Куча сырья поступает, а из неё выходит машина». Или из неё выходит какая-то деталь, которая отправляется на другой сути, вы бы наняли кучу MBA-специалистов, им бы
назначили рабочие места, и они бы максимально использовали каждое из них. Вы . Запуск стоит денег, и каждая минута простоя — это пустая трата денег. Поэтому все оптимизируют свои
разные рабочие места обрабатывают разное количество материала, узкое место, а перед этим узким местом скапливается много заводе очень
дорого обходится. Таким образом, это история о подписок, когда мне нужно потратить все
свои облачные ресурсы каждые 5 часов, что в итоге приводит к госпитализации. Да. О,  Это было безумие. Не знаю, полностью ли я в это верю. Не знаю, был ли это мем или что-то в этом роде, но надеюсь, все в порядке.
банк токенов программной фабрики: сколько ты можешь потратить? Сколько всего машины и превратить это в код? И есть смысл в том, чтобы, знаете, попытаться расширить границы возможного, сделать что-то самое
масштабное и амбициозное и посмотреть, что из этого выйдет. потому что если узкое место — это проверка кода, то добавление проблему, верно? Нужно понять, как решить саму
проблему, а не просто сказать: «Хорошо, моя станция агентов очень эффективна, и моя и каждый раз, когда я ускоряю их, я не ускоряю доставку ценности, ценность, предоставляемая пользователям». Вот почему люди платят за всякую ерунду.
Ага.  Я имею в виду, это как, знаете, лучший пример того, кто делает это правильно, — это Илон Маск над самым большим узким местом, и ему все равно, если кто-то другой в они, вероятно, не будут делать это на его уровне.  Если это не является узким местом,
они сделают это на 80%, то все будет в порядке.  Ему нужно поработать над устранением узкого места.  То же самое созданию компании-разработчика программного обеспечения или фабрики программного обеспечения.  Это как если бы вы улучшали свою многоагентную систему, добавляя, например, сложную маршрутизацию и делегирование —
здорово, но, знаете, в результате работа системы останавливается.  Ну, знаете, у нас прекратите играть со своими агентами для программирования и возвращайтесь к работе.  Это так легко и так весело — создавать то, что создает... Я имею в виду, я
был таким еще до появления ИИ.  Моя первая работа после окончания колледжа была в было много данных.  У меня было много хороших инженеров, но я заметил, что самым важным человеком в компании был
вы осуществляете доставку, способ развертывания вашей тестовой среды для отправки кому нравится, знал, как отлаживать базу данных. Не саму базу данных, меня просто преследует мысль: всякий раз, когда в компании
замедляется цикл разработки и внедрения (CICD), я думаю: « Боже мой, нам нужно ускорить CICD. Мы выпускаем релизы раз в две недели, нам нужно выпускать их каждый день».  Я называется, но меня захватила идея программной
фабрики, знаете, последние 12 лет или около того, сколько бы я ни работал, 15 лет.  И, э-э, мне часто приходилось выступать в роли собеседника, говоря что-то вроде: «Декс, мне нужно, чтобы ты перестал пытаться
ускорить процесс CI и просто отправил те заявки, которые я тебе дал. Э-э, пожалуйста». своим начальником много раз в разных компаниях.  А я подумал: создаст то, что создаст, потому что это ускорит работу всех".  И, как
существуют неэффективности, которые не являются узкими местами.  И вы можете увидеть вещи, от которых у вас мурашки по коже побегут.  Вы говорите: «Это ужасно. Зачем мы это делаем? И если вас интересует предпринимательство,
ваш самый важный навык — это умение взглянуть на ситуацию со стороны и спросить себя: «Это сосредоточиться на том, что действительно важно?» успеха, будь то в бизнесе или в сфере программного обеспечения, у вас будет
комфортно, как будто вы позволяете огню гореть. Это как определить, какой из этих весь город, а какой — всего лишь мелкие искры, которые можно отложить на Это примерно так: «Окей, круто. Да, нам нужно перекрыть утечку газа в
там?»  Это как: "Ну, эта ранка пока не жжет, но если почти как ожидаемая боль, верно?"  Это не просто: сложное: нужно уметь удерживать в голове все эти вероятности и понимать, над
чем действительно стоит работать.  Это... это... это... это безумие?  Вы когда-нибудь Вы когда-нибудь увлекались стратегиями в реальном времени? Нет. Я слишком молод для этого. Первый и второй вышли где-то в 2012 году. Не знаю. В общем.
поколение, предшествующее ему. Да, так и было, и это было по-другому. Ну, вышел в 2012 году, но это как бы... сложные решения, имея неполную информацию, и вы постоянно
принимаете сотни решений в минуту, как будто не знаете всего.  Вы ничего видели, и говорите: «Хорошо, я видел, как он это делал, и я видел вот это, а это делает это, 30% вероятности, что он делает это, и 70% вероятности, что он делает это».
И поэтому мой лучший подход — это думать: «Хорошо, если я сделаю это, то у меня будет 40% шанс как игра, где нужно складывать вероятности с обеих сторон . В общем.  Это... это... это... это хорошая игра.  Я не рекомендую. Это невероятно
стрессово.  Но да, это тот навык, когда ты знаешь, что видел, делаешь ставки и... ну, я не знаю.  Основатели компаний говорят, что создание бизнеса похоже на Кажется, вчера вечером за ужином я с кем-то разговаривал .  Он говорит: «Мы
не инвестируем в нашу инфраструктуру. Мы не делаем того, что делаем, мы играем в азартные игры. Мы все играем в азартные игры целый день, каждый день, пытаясь ожидаемая прибыль». Да, или, знаете, стоит ли мне вообще
на это 6 месяцев?  Будет ли это ужасно, и через 6 месяцев меня просто все это как пари, понимаете? И нельзя допускать слишком много ошибок, иначе вы станете никому не нужным. Ну что, вам весело?   Я.   Ага
?  Это хорошее начало. Если тебе это доставляет удовольствие и ты чему-то учишься, то это звучит так: «Окей, круто. Ну и что?»  Я имею в виду, что 20 лет назад не было ничего подобного. Сейчас существует сотня стартапов, и я
гарантирую, что на каждой из них, по крайней мере, в девяти из десяти случаев на Google это сделал. Ага-ага. этом поколении. Я разговаривал с Магнусом из Browser Use, и все говорили: «
это разрабатывает, в этом нет смысла».  И знаете, им это удалось лучше, чем Anthropic.  И это буквально год, два года.  Так что, да, даже в крупные компании не ориентируются на вашу небольшую нишевую идею, и
если вы действительно этого хотите. Одна из моих любимых фраз на эту тему звучит так: вы на самом деле конкурируете не с Google или с менеджером по продукту в Anthropic.
И вот, да, там есть очень-очень-очень талантливые люди, вы ведь интересна версия от Google.  Это внутри крупной организации есть команда, у которой куча правил и бюрократии, и дела
продвигаются медленно, и ты думаешь: "Мне всё равно, сколько у них денег или насколько широка ваша дистрибуция". Небольшой основатель и небольшая команда, которая действительно неравнодушна, могут превзойти по эффективности большинство команд внутри гигантского предприятия. И вот
и я общался со многими бывшими сотрудниками этих компаний, они говорят: « очень хорошо поработали над тем, чтобы сохранить энергию стартапа, помочь людям двигаться как можно Борис и Катя — просто невероятные люди». Они настолько хороши в своем деле
.  Так что, ладно, это проект, который немного, вникать в детали, но очень легко просто сказать: «О, победят», и, знаете, я не знаю.  Я не из тех, кто создает
вещи, руководствуясь принципом, что они соответствуют миру, в котором я хочу это мир, где есть крупные и мелкие компании, где могут существовать инновации, где мы все можем вместе решать проблемы, и, знаете, я
основателями компаний, занимающихся программированием, в Сан-Франциско. Мы все конкуренты, но это огромный рынок, и, на мой взгляд, это не противостояние основателей друг с другом, а скорее противостояние основателей и действующих игроков рынка, или основателей и людей, которые
Да, да, именно так.  Люди, которые ненавидят технологии и, типа, застряли в прошлом.  Мне кажется, в сфере искусственного интеллекта, чем больше я узнаю, чем больше общаюсь с людьми, тем больше
сторонником этой идеи или нет?  И так много людей здесь потому, что это, знаете ли, следующая волна.  Здесь сосредоточены деньги. Вот где, как известно, царит ажиотаж.  Но, не являются истинными верующими.  Они вроде как не верят в
выходит новая модель или появляется новый инструмент, вместо того чтобы шанс, они тут же говорят: «А, это еще одна такая же», или « Эта модель слишком дорогая».  Ребята, это как будто мы создаём будущее.
. Теперь, если вы действительно хотите реализовать все, о чем мы с Декстером говорили, вся разработанная им система проектирования программ доступна бесплатно по первой ссылке под видео.  Так что смело
свой адрес электронной почты, и вы получите это письмо на свой электронный адрес.  И снова, совершенно бесплатно.  Так что, идите и заберите это прямо сейчас. Эм, да, я имею в виду, это, возможно, хорошая идея, чтобы взглянуть на ситуацию в целом и, может быть, начать подводить итог, но вот эта
мысль, например, я не знаю, я был на мероприятии прошлой ночью.  Эм, это было что-то вроде интервью Дваркеш с доктором Фэй-Фэй Ли, а потом появился Майкл Гринич из Work OS немного пообщался с Дваркеш, и я не знаю...  Мы все здесь, в Сан-
Франциско, и очень легко увлечься вопросом: «Что самое насколько круто мы сможем это сделать?  Насколько быстро мы можем ехать?  И Гринич хорошо поработал над тем, чтобы поднять нас на новый уровень, показав, что, на
самом деле, искусственный интеллект — одна из самых непопулярных вещей в мире прямо сейчас. Э-э, чуть менее непопулярным, чем ИИ, был лед, а чуть более непопулярным, лед, а чуть более непопулярным, чем ИИ, была война с Ираном, верно?
этому с недоверием. И я думаю, что строителям важно понимать: «Эй, нам нужно подумать о том, как эта технология работает».
Дваркеш говорит о том, что через 5-10 лет не будет рабочей силы, нечем будет заняться, как будет работать экономика?  Нужно ли нам поговорить с экономистами со степенью доктора наук и подумать, задумывались ли они над тем, как
функционирует мир в этой новой парадигме?  И это такие вещи, на которые ни у пока вы не дадите кому-нибудь убедительный ответ, кто не разбирается в технике и не является экспертом в области искусственного интеллекта, пока вы не дадите ему убедительный ответ, что именно так будет
работать мир, и это будет хорошо, и все выиграют, за исключением революция, жизнь стала намного лучше».  Я имею в виду, что для некоторых людей ситуация ухудшилась во многих отношениях, но в целом сейчас у нас больше изобилия, чем, скажем, в
1500-х годах, и я не думаю, что это достаточно убедительное объяснение для Да, людям важно, потеряю я работу или нет. Да, смогу ли я прокормить свою семью, что бы это ни было, и
В нём легко застрять.  Если вас, особенно, знают в Твиттере или в посетить Сан-Франциско).  Я там никогда не был.  Эм, я думаю, я собираюсь... Да, я думаю, я приеду куда-нибудь в конце сентября, может быть, в начале октября, но...
правда?  Будь то в Твиттере или в Сан-Франциско, но, как и большинство людей, они понятия не имеют. поисковый ИИ, похожий на Google, и они ведь не хотят потерять работу, правда?  Так что, если вы заговорите что-то вроде: « О, да, мы собираемся нападать на трудящихся», — они тут же вас возненавидят.
это говорят.  Наверное, лучше сказать это и ошибиться, чем не сказать и оказаться правым, но, э-э, да, посмотрим.  Я не знаю.  У меня думать об ИИ, и есть много безумных вещей, из-за которых
, что мы достигнем сингулярности, наступит полное изобилие, никому больше не нужно будет работать, и всё будет просто замечательно.  Это как будто один мир, невероятно хорошая версия мира.  Есть также
выравнивание, и все мы окажемся в ситуации, как в сюжете «Терминатора», где нас всех уничтожить, и тогда становится ясно, насколько плохим будет линия, проходящая через середину, через которую всё постоянно улучшается,
и это улучшение может происходить в 2 раза быстрее или в 1,5 раза быстрее каждый год, каждый месяц или сколько угодно.  Но всё остаётся стабильным, и ничего особенного не происходит.  Нас не дестабилизируют полностью.  И независимо от того,
считаете ли вы, что хороший сценарий — это 30% или 3%, считаете ли вы, что плохой сценарий — это 30% или 3%, единственный вариант развития событий, для которого действительно имеет смысл планировать, — это, на мой взгляд, срединный путь.  Потому что если произойдет что-то одно из
двух других, то все, что вы сегодня делаете, не имеет особого значения, если только вы не находитесь в лаборатории, работая над выравниванием. Ага.  Я думаю, это очень .  Я хочу с уважением отнестись к вашему времени.  Прошло уже больше
веселье.   Да .  Куда людям следует пойти?  Куда нам их отправить? Подписывайтесь на меня в Твиттере: Dex Horthy d e x h o r t h y и заходите на humanlayer.com.  Если вы хотите научиться
Ссылки на оба варианта я размещу под видео. Ещё раз благодарю вас за уделенное время и a good day. >> Good stuff, dude.