Andrew Ng 产出索引（The Batch · Letters · X，2026-06 ~ 09）

Dear friends,

When you’re skilled at AI Engineering, your best work won’t be merely implementing a product that someone else spec’ed out. Instead, you will actively shape the build.

Before modern AI tools accelerated and expanded what a single developer could do, tech companies established the practice of having product managers (PMs) and designers specify what should be built and then developers build it. Perhaps a project manager additionally drives the timeline. However, these roles are blurring. A developer who is skilled at AI engineering not only builds software but participates in these other roles. (Similarly, product managers and designers are gaining AI Engineering skills and participating in building software.)

This change is vastly accelerating software development. When you know how to shape the build, you can move faster without waiting for a PM to figure out what to do.

The key skills for shaping the build are:

Driving the build loop. Most software is built via a loop in which you write some code, then get some feedback, and decide what to do next. As a skilled AI engineer, you play a key role in driving this loop, repeatedly deciding on the next step to move your project forward. You have a bias for action, and drive this loop at the high velocity that AI has made possible.

For example, you might decide to build a quick prototype to test a technical concept or user feature, build an MVP (minimum viable product) to take to users to demonstrate value, add features, or invest in an enterprise-grade system. You frequently ship in small batches to keep up velocity. You know when to get feedback from users or other stakeholders, or when to run a technical experiment (such as train a model) to gather information to decide the next step. You make these decisions taking into account the product vision, stage of the project, technical feasibility, key risks, effort, and budget. For more mature projects, you know how to define key metrics and project-manage to drive improvements to those metrics.

Making product decisions. Developers don’t have to become PMs, but you will make decisions the product spec doesn’t cover. If you are asked to build without a spec, you know how to develop one.

You have product sense that enables you to pick a product direction that meets real user needs, without having to wait for a PM to make every decision. You also have at least a basic design sense, and can build things that aren’t just functional but pleasing to use. You also have some basic business sense, so you can think through issues like go-to-market, market size, unit economics, and profit and loss (P&L) and make tradeoffs that are economically sensible. Your ability to make product decisions is rooted in your user empathy. Further, you continually hone this empathy using a wide range of methods, such as quick informal interviews with 2-3 users, surveys of hundreds of users, large-scale A/B tests, or analyzing the behaviors of thousands or millions of users. You use the resulting input to improve your understanding of users.

Communicating and leading. Your skills in AI Engineering enable you to participate in a broader scope of work than traditional software development allowed. I’ve written previously about how specialized developers (like frontend developers) are now likely to play a broader full-stack role. AI Engineering skills open the door to expanding your scope even beyond this: You might participate in other functions that affect your project like marketing, finance, legal, and so on. This makes your ability to communicate with these other functions more important than before — you can play a key role moving your project forward by aligning and coordinating among stakeholders. (Communication skills also form an important foundation for speaking with users to hone user empathy.)

Additionally, because AI technology is rapidly evolving, many people outside of engineering are trying to understand the technology, its impact on their jobs, and the new practices and products it makes possible. Your technical skill in AI Engineering puts you ahead of the game and allows you to play a unique role in shaping these perspectives. For example, you can explain why certain initiatives may be technically feasible or not. This allows you to help lead your broader organization forward.

High-agency ownership. AI engineering skills give you vast opportunities to make a difference. However, many people — including some executives — do not yet understand what AI can do and therefore do not know what are good project directions. This creates an opening for someone with technical skill to bridge this gap: You can spot problems, propose solutions, and execute on them — being respectful of the organization’s priorities and constraints, but without waiting for precise top-down direction. This skill requires a high degree of agency, in which you identify opportunities, prioritize what matters, and act on them. Additionally, you know how to own an initiative end-to-end, take accountability for issues that arise, act in the face of ambiguity, persist through setbacks, and measure your work not just by task completion, but according to the value you create.

Finally, you invest in improving your skills. You track the technology frontier, pick up new tools, tune your workflows, and keep on learning — so you become better over time.

The opportunity to not just build but to shape the build makes AI Engineering more exciting than traditional software development. You are more empowered, have broader scope, and make more decisions. But doing all this well requires a larger set of skills. DeepLearning.AI’s focus is to help you, if you wish, become skilled at AI Engineering.

I look forward to the road ahead!

Andrew

Dear friends,

A key AI engineering skill is using coding agents. Your skill at steering them both to write code and to carry out non-code tasks, such as analyzing data or managing system operations, allows you to get a lot more done.

The rapid pace of evolution for coding agents means this skill, too, is evolving rapidly — faster than other top-level AI engineering skills. Proprietary agents (like Claude Code, Codex, and Cursor) and open agents (like OpenCode and Pi) progress in strides via both harness and model improvements. So keeping up with how to use coding agents requires a continuous process of experimentation, building, and learning.

In interviewing dozens of top AI Engineers and reflecting on our own team’s use of coding agents, we found a consistent high-level workflow for building software with them. The key steps are:

This high-level workflow is similar to the one typically used to build software before coding agents. Now, we focus much less on code and instead focus on deciding what to build, designing the architecture, writing the spec, and verifying outputs.

The duration of each step can vary significantly between projects, and steps can be omitted. For example, the spec for a greenfield (meaning built-from-scratch) prototype might be loosely described in a quickly written prompt, whereas the spec for a brownfield (pre-existing) project with many users might require much more effort to write and verify. Further, the workflow is highly iterative, and skilled developers know when feedback from a later step should lead them back to an earlier one. For example, if verification fails, they know how to steer the agent to rebuild and fix errors; or if monitoring surfaces issues, how to have agents update the system and redeploy.

To use coding agents effectively in this workflow, the key skills are:

Directing the workflow. You know how to navigate each step of the workflow above. This involves deciding how much human and how much agent effort to spend on each and when to go back to an earlier step to iterate. It requires deeply understanding the tradeoffs of speed, cost, technical risk, and human effort, so you can decide how much to research and plan up front, when to retain human ownership over critical work, how to choose the architecture, how much detail to write into a set of planning artifacts (like a spec), and how to decompose the work into verifiable steps.

Enabling agent autonomy. When applying a coding agent to the steps in the workflow, you choose the autonomy level: Do you watch it and go back-and-forth interactively or delegate a larger chunk of work to it? And when do you set a clear goal and have it loop until it succeeds? Additionally, you have to manage the context carefully for the agent. As the build proceeds through different phases, you will calibrate when to make sure key learnings, user feedback, and assumptions — including assumptions that changed partway through the build — are captured for the agent to use downstream. Additionally, you will decide when to set up many agents to run in parallel on a decomposition of the task — either by having a human or a higher-level agent orchestrate these other agents — and how to manage human attention across concurrent agent sessions. You also know how to run agents safely, setting permissions and gating actions appropriately to let development proceed quickly while limiting the risk of leaks, data loss, or other damage.

Reviewing the work. The output of a coding agent is uncertain. We don’t know in advance what good ideas it might come up with and what bugs it will implement. Reviewing and verifying the output is a key step to ensure you are getting the result you want and to redirect the agent if not. You will design testing and validation that is matched to the task, applying both behavioral and functional verification as needed. You might also test user flows, perhaps having an agent provide screenshots as evidence of success or failure. For qualitative/behavioral evaluation, eval sets, perhaps with LLM-as-a-judge, can be used.

You also need to decide how much of these tests should be automated. Some workflows will have all testing and validation fully automated so the agent can check its work and know when it has succeeded in completing a task. You have to evaluate the tests to ensure they correspond to your aims, and you will evolve them if not. Additionally, you use agentic code review and run AI-enabled security and architecture audits. When AI review isn’t sufficient, you judiciously insert human reviews of the code behavior (and, infrequently, of code as well) while exploring how to automate this review further. Finally, you verify deployment and can operationalize monitoring and incident management with agents.

Customizing the agent and its environment. Your ability to update both the agent and the environment it works in allows your agents to efficiently get the context they need, access tools, and build correctly and efficiently. You know how to integrate agent skills, plugins, and MCP servers. Occasionally you will prune them when they are no longer necessary (such as when a new model obviates an old skill). You can use hooks to automate repeatable parts of the development process, like triggering automated code reviews or CI/CD pipelines. You can also maintain the environment the agent works in: updating the standing context (such as AGENTS.md or CLAUDE.md) with information on the codebase, key architectural assumptions, code style, and data access patterns. You know how to preserve state across multiple sessions and across parallel agents, and accumulate agent learnings over time, perhaps by running post-run retrospectives to capture what did and did not work. You also know how to set up consistent conventions and structure to make your codebase navigable to the agent, and how to occasionally clear out agent-generated debt. When you work in a team, you consider how to coordinate context across different developers’ agents.

Coding agent foundations. Finally, to make good decisions throughout, you have a good understanding of how coding agents work: how they carry out codebase search/retrieval, how they manage their context windows, how different operations (like adding tool calls, MCP servers, etc.) affect context, how agents and subagents interact, and how the agent is built by wrapping a harness around an LLM. This makes the agent less of a black box and helps you to recognize failure modes, such as overengineering a simple solution, losing rigor because the agent lacks an explicit verification process, stopping short of the goal, or agent actions that risk destruction of files or production data. It also helps you reason about the agent’s state and steer it by giving it the right prescription or context. And when monitoring a run, this understanding allows you to better spot when the agent goes off-track and requires your intervention.

I find that social media often gives oversimplified descriptions of how to use coding agents. For example, it is sometimes useful to get agents to run autonomously for hours and burn millions or tens of millions of tokens. But currently the practical utility of very long-horizon tasks — especially relative to their cost — has been amplified beyond reality. Instead, most effective coding agent use is a complex, highly iterative process, and being able to intervene with high-skill judgement gives much better results.

Your skill at using coding agents will make you an effective builder. This positions you to also steer the overall build. I will say more about this in next week’s letter.

Keep building!

Andrew

Dear friends,

How have software engineering fundamentals changed with agentic coding? Even when you use a coding agent to write all your code, understanding software fundamentals is important for steering your agent to make the tradeoffs you want — or to even know what tradeoffs exist to be made. Additionally, when you’re building an AI application, the AI core is often expressed through a broader software application, which a skilled engineer will shape.

A novice who vibe codes without understanding software fundamentals can create simple applications, but this often leads to the coding agent making bad tradeoffs in latency, availability, consistency, reliability, maintainability, simplicity, and/or cost. In most cases, the developer didn’t know such tradeoffs even existed and therefore did not steer the agent to make the right decisions for their application context.

This letter describes what our study of AI Engineering Skills shows are the most important things to know in software engineering. It requires being skilled at:

Building full-stack applications. Agentic coding enables many developers who previously played more specialized roles (like front-end developer or mobile developer) to play a broader, full-stack role. A coding agent can help with parts of the development process that you might be less familiar with. However, understanding how the full stack actually works is important. Skilled developers understand the key components and concepts of front-end and back-end systems, including UI components, caching, page rendering, API choice and design, authentication, state and session management, asynchronous processing, data persistence, testing, security, and accessibility.

Managing data. Data deserves special attention because it is a foundation that software is built on top of, that is relatively hard to change (even if agents help with migrations). When you know how to manage data, you can think through access patterns and use them to decide what to store and for how long. You can identify the right data models and select the appropriate storage types (such as relational tables, documents, key-value, or graphs) and infrastructure, which in turn affects speed, scalability, availability, reliability, and cost. You understand transactions, concurrency, and how to ensure your data is clean, consistent, and fresh. When needed, you can ensure proper privacy, governance, and compliance. You know how to manage the data lifecycle.

As an application evolves, you also know how to evolve the data architecture with it. Deciding how to manage data requires significant human-provided context. Your AI systems will get their own input context from your data source, so if data architecture is chosen poorly, the AI doesn’t know what it doesn’t know. This is why it takes skilled intervention from someone with the relevant context and skilled at AI engineering — you! — to set it right. How to build data infrastructure for agents — rather than only traditional software or humans — is also a rapidly evolving area, and you should continue to adjust your best practices as the field evolves.

Designing system architectures. When you understand the major components of the full stack of software and data, you are then better positioned to decide how to put the pieces together. Good system design requires understanding what the software is intended to do (how many users? how important is latency? how important is cost? etc.) so you can make choices about the application platform, the boundary between the frontend and backend, system decomposition, application state placement, and architectural granularity (monolith vs. microservices). You will also choose the stack (programming languages, runtimes, component/frontend/backend frameworks, data technologies) — sometimes by running experiments to evaluate options before settling on one.

Further, the right architecture is a moving target, depending on the phase of the project. The simple architecture you choose to build a quick prototype may not be the right architecture to build the first production system, and that too may change as the application scales. Making these decisions requires deep technical knowledge of both software components and the application context so you can design — and evolve — the architecture to make better tradeoffs.

Making systems secure and reliable. To build reliable systems, you should know how to develop testing strategies to verify the correctness of your system: What mix of unit tests and integration tests, what frameworks to use, and what level of coverage. You also know how to design around possible failures — how to handle failures (like an API hitting a rate limit), build in graceful degradation, and minimize the blast radius of failures. Additionally, rather than first writing software and then later figuring out how to secure it, the “shift left” movement is moving security work earlier in the lifecycle (to the left on a traditional project timeline). Just as all developers are moving toward becoming full stack developers, many developers are now also partly security engineers. You can now use AI tools to scan your code for vulnerabilities, check dependencies for supply chain injections, and examine your cloud configuration for attack surfaces. But doing this well still requires some knowledge of security.

Scaling and operating in production. To serve real users, you will have to know how to deploy your software to production.You will benefit from knowing how to execute the software development lifecycle (SDLC) which, in addition to building and testing, includes configuring the deployment environment, deciding on release strategy, applying deployment automation (CI/CD), and understanding infrastructure as a service (IaaS).

Operating in production requires putting in place observability tools, setting alerts, and managing incidents. Lastly, to scale your application, you should understand the real load and know how to scale servers, load-balance, and adapt your data infrastructure (via sharding, indexing, replication) or make architecture changes to allow your system to adapt to scale. Finally, understanding coding best practices like version control, code reviews, dependency maintenance, and how to manage technical debt helps you keep evolving your system over time.

Coding agents have changed how we build software, including software that does not contain any AI components. Some parts of coding knowledge — like memorizing coding syntax — are becoming obsolete. But developers who deeply understand how software works vastly outperform those who vibe code without understanding.

Understanding software fundamentals (in addition to AI) also helps you figure out what software can and cannot do. This makes them important context for how you use coding agents and shape the build. I will discuss these in the next two letters.

Keep building!

Andrew

Dear friends,

I previously wrote about our AI Engineering Skills Map, with the highest level skills being (i) Building and deploying AI applications, (ii) Software engineering fundamentals, (iii) Using coding agents, and (iv) Shaping the build. In this letter, I will flesh out the first of them.

Being skilled at building and deploying AI applications means knowing:

This map of skills was formed by analyzing a large number of job postings, structured expert interviews, and survey responses.

The key difference between AI applications and non-AI software is that the former’s output is less predictable. You don’t know in advance what an LLM will output, or what predictions a supervised learning algorithm will make. Because of this uncertainty, building AI systems is a much more iterative process than building traditional software — it is harder to plan the process in advance. Skilled AI engineers repeatedly build a piece of software, examine it, and decide what to try next, taking a sequence of steps that are highly influenced by the intermediate results. Being able to skillfully decide what to do next allows you to create reliable software systems based on unreliable AI components. This requires knowing:

LLM foundations. Understanding how large language models tokenize input and generate output allows you to understand when to count on them and when they may fail. It also allows you to understand when to use a multimodal model, how to make tradeoffs on what to include in the context window, and reason about cache hits, knowledge cutoff, reasoning effort level, sampling parameters, and when to use special features such as tool calling. Understanding these foundations helps you choose the right model or mix of models and apply specialized techniques when needed, such as fine-tuning or self-hosting models.

Grounding models with data. LLMs require good input context to produce useful outputs. RAG using vector search was an early attempt to give LLMs relevant context, but the set of techniques for grounding models with data has grown significantly. For example, you will have to decide what to include in a prompt vs. what to let an LLM retrieve on demand using tools, and which representation fits the data and search queries: a vector index, a knowledge graph, or a semantic layer over structured data (such as customer records). You’ll also turn documents (text, PDFs, HTML, images) into LLM-ready inputs and engineer pipelines to keep data clean and fresh. When you understand the menu of techniques available to get data, you are better able to give your LLM relevant context.

Building agentic systems. Agentic systems range from workflows that execute a predefined sequence of LLM calls to ones based on an agent harness that lets an LLM repeatedly decide its own next step. You’ll have to choose the architecture — what steps to chain, what to parallelize, when to use code and when to use an LLM — and engineer the workflow or harness, with fallbacks. When designing the agent loop, you will also decide what tools the model can call (including MCP, CLI and sandbox execution environments), what memory architecture to use, how to manage context over long sessions, and when a task needs multi-agent orchestration instead of a single-agent architecture. You’ll also want to turn promising prototypes into reliable, safe and secure agents for production; this requires understanding guardrails, adversarial inputs, and identifying and working around key risks (such as data exfiltration), and governance.

Agentic workflows are evolving rapidly, and you will also benefit from understanding any cutting-edge techniques relevant to your application area, such as voice agents, computer-use agents, or generative UI.

Evaluation-driven development. In my experience, the most important trait that distinguishes someone great at building AI systems is whether you can drive a disciplined evals/error analysis loop to drive development. This allows you to repeatedly focus your effort on directions that are more likely to be fruitful. I’ve found this to be a tricky skill to master, because the right approach varies significantly by project and even according to the stage of the project.

Building good evals is a deep technical skill. You might look at a system’s traces and outputs, carry out exploratory data analysis, and combine that with product and business insight to decide what to measure. You should also understand the menu of options for evals, such as when to use deterministic (code-based) evaluations, when to use an LLM-as-a-judge, and when to have a human in the loop, and how to evaluate your evals so as to keep evolving them. These evaluations then feed into an iterative process that drives further development, and makes progress systematic rather than random.

Operating in production. Operating AI software is different from traditional software because of its unpredictability, cost, and latency. First, you should know how to build observability mechanisms to understand the system’s performance on real usage. You’ll track performance, detect drift, and respond quickly to model failures and security incidents such as adversarial prompt injections. Putting in place regression testing and CI/CD requires more statistical evaluations than traditional software, and the testing effort should be calibrated relative to the risk of a mistake. Additionally, it’s important to know how to select the right mix of techniques — such as model choice optimization, distillation and fine-tuning, and agentic workflow simplifications — to optimize for cost and latency, especially if your application reaches many users.

Machine learning foundations. Modern LLMs are built using machine learning techniques including supervised learning and reinforcement learning. Every engineer I know that’s good at building with LLMs also understands machine learning and deep learning at some depth. Additionally, many applications still require knowing how to use machine learning – either a model someone else trained or one you train yourself. This requires knowing the popular machine learning and deep learning models and tradeoffs in accuracy, training speed, inference speed, and so on, and understanding how to engineer the data needed to train and evaluate these models. The machine learning concepts of bias/variance, error analysis, and engineering your data — all of which are core mental frameworks for navigating how to work with systems with uncertain output — also remain key to making a wide range of decisions in AI system development.

There is a lot to learn to become good at building and deploying AI systems. This is a field with significant technical depth. But every bit you learn will help you become better at AI Engineering and build more exciting applications. A strong complement to these skills is software engineering. I will write more about this in the next letter.

Keep building!

Andrew

Dear friends,

I am delighted to present The AI Engineering Skills Map. AI allows us to build software very differently today than in 2022, and everyone with the skills to take advantage of this shift has numerous exciting project and job opportunities. But with the noisy, hype-filled, information environment around AI, what are the most valuable skills for you to learn? I have been working with my team to synthesize a map of AI engineering skills in order to help (i) developers prioritize what to learn, and (ii) employers hire skilled developers.

Based on an analysis of over 10,000 job postings; carrying out dozens of structured interviews with AI experts, hiring managers, and recruiters; gathering data through surveys; and synthesizing other online data, here are the four most important AI engineering skills:

You can informally think of our process as akin to clustering on a massive dataset of jobs and expert interviews to identify the most important skills, not just today but also in the near future.

A note on terminology: I talk about AI Engineering skills rather than the “AI Engineer” role (someone whose job is to build AI systems), because the former is much broader. All developers today should know how to work with the cloud, and only a smaller number have a “Cloud engineer” title. Similarly, all developers — full-stack engineers, data engineers, DevOps engineers, machine learning engineers, and, yes, AI engineers — will need AI engineering skills.

Building and deploying AI applications. The key difference between AI and non-AI applications is that the former has unpredictable outputs. When you prompt an LLM, you don’t know what you’ll get back. When you train a deep learning algorithm, you don’t know what prediction it will make on new examples. In contrast, traditional software behaves more predictably.

People who are skilled at building and deploying AI applications understand the building blocks of AI (such as LLMs, context engineering, RAG, agentic workflows, machine learning and deep learning) and, importantly, how to use statistical techniques to measure, steer, and govern AI systems so that they behave more predictably. A core skill in doing so is knowing how to drive disciplined evals and error analysis loops.

Software engineering fundamentals. When you deeply understand how software works, you can build much more effectively. Engineering software requires making tradeoffs between cost, scalability, reliability, speed, and more. Security and privacy add further complexity.

Understanding software fundamentals allows you to recognize what tradeoffs even exist. This leads to better decisions in choosing your software stack, designing system architecture, designing your data store, testing, and so on. It also leads to much better outcomes than those for an inexperienced developer who vibe codes a solution without knowing the tradeoffs their coding agent is making — which will often be poor ones, because they don’t know what context to give their coding agent. Understanding software engineering fundamentals lets you make good tradeoffs by steering coding agents using the precise language of software engineering.

Using coding agents. Using agentic coding effectively is now a key skill for every developer. When you have this skill, you have a good mental model for how agents work. You understand their limitations and how to work around them, and are able to quickly steer them — knowing how much to intervene and how much to leave them alone — to build robust software without wasting excessive time or tokens.

This requires your knowing how to manage a coding agent’s context, make tradeoffs between planning and execution, and help the agent autonomously close loops by providing verifiers or evals. You also need to know how to work with a clear spec (and when not to bother doing so), orchestrate multiple agents that work together, and avoid pitfalls like an agent messing up your production database. Because agentic coding is evolving quickly, using coding agents skillfully means not only knowing cutting-edge practices, but also having routines to keep trying new tools and evolve your workflows as best practices change.

Shaping the build. Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec. Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. Instead, effective AI engineering requires having product sense and understanding business context and customer goals, so you can participate in shaping and driving the build.

AI also gives you the opportunity to take on greater ownership and agency than before. You can identify interesting problems and opportunities, and execute to take advantage of them in responsible ways. Taking advantage of this opportunity requires knowing how to drive projects forward. For example, knowing when to quickly build an MVP to take to users for testing, and when to slow down and take longer in order to build more carefully.

Underlying all these skills is a mindset of continuous learning. AI continues to change quickly, so we must all keep learning and evolving our skills to adopt emerging best practices.

DeepLearning.AI’s principal focus is to help developers gain these AI engineering skills. I have more to say about each of these four skills, and will flesh out each of them in my next few letters and share a more detailed AI Engineering Skills Map. As I look at where AI Engineering is going, I am incredibly excited about what all of us will be able to build. I hope you will play an exciting role in this future.

Keep building!

Andrew

P.S. As AI evolves, I will keep updating the AI Engineering Skills Map. If you are willing to contribute, please take a few minutes to complete our survey here. It takes around 5-7 minutes to complete, and it will help us to shape this for the community.

Dear friends,

I’m glad the idea of “tokenmaxxing” — that individuals and companies should use as many tokens as possible to boost productivity — is finally dying out. As much as I encourage everyone to make ample use of AI, the practical reality is that increasing token usage beyond a certain point gives diminishing returns because there are still bottlenecks in organizations that burning more tokens alone cannot resolve.

One challenging aspect of AI hype is that there’s often a nugget of truth, but the hype blows it out of proportion. Using more tokens is correlated with getting more useful work done by AI. As models and harnesses improve the amount of work that AI can productively do — and the number of tokens that we can use fruitfully — also increases. But setting up competitions to see who can use the most tokens (as some companies have done) takes the idea of encouraging token burn beyond what is productive.

There is, of course, a financial incentive for companies that sell tokens to encourage everyone to use as many as possible. Some frontier labs have disseminated best practices on how to use more tokens, run more agents in parallel, and generally consume more of their product. This follows a long history of companies trying to get people to use more of whatever they sell:

Using tokens and multiple agents is valuable, just like oil changes and toothpaste are very useful products. But it is also important to have trustworthy sources of information that provide advice based on your interest. (This is why, as I wrote previously, DeepLearning.AI has never accepted payment for creating any course.)

To be clear, I do think society should find more ways to use tokens effectively. But to make sure our use is productive, consider these two practices:

This sort of advice is hard for any model provider to give. To be clear, I’m rooting for all of the frontier AI labs — they are building amazing technology that helps us all build better. At the same time, I will make sure DeepLearning.AI continues as a a neutral, trustworthy source of information that is committed, first and foremost, to the success of learners who want to build with AI.

So, please productively use lots of tokens, but don’t tokenmaxx. And keep building!

Andrew

P.S. Something fun — if you want a brief diversion, check out this space shooter game that I built last weekend. (Gamepad support works better for me in Firefox than Chrome; but can also be played with keyboard and mouse.) There has been much debate about AI enabling new forms of creative expression through creating images, music and writing (or damaging them through slop). I think creative expression through games will be another exciting direction — and fun too!

Dear friends,

My team recently had our own version of Hugging Face’s experience when closed models failed to defend the company following an accidental cyberattack from OpenAI, leading Hugging Face to use the open weight GLM 5.2 instead. When we tried using Claude Code (with Fable 5) and OpenAI’s Codex harness (with GPT-5.6 Sol) to conduct a security review of our open source project, both refused, in one case stopping work early, and in the other wanting to drop down to a less capable model. So we switched to the OpenWorker harness with open weight models Kimi K3 and GLM 5.2, which allowed us to make progress and gain confidence in the security of our system.

We were conducting a security review of OpenWorker. Rohit Prsad and I released OpenWorker as an open source agent that doesn’t just chat with you, but delivers finished work — like handing you a polished document, sending a Slack message, or updating a calendar entry. AI coworkers are an important way to get work done, and we want to make sure there is an open, model-independent option. Since we announced it last week, it has gotten tremendous traction — thank you users and contributors!

We are continuing to improve OpenWorker, and routinely ask agents to help us with security reviews. If you haven’t tried using coding agents for security reviews, I encourage you to try it out. Security professionals have sophisticated ways to steer agents, but even a basic prompt like “spawn a subagent to do a security scan of the codebase and uncover vulnerabilities and security issues” can go a long way.

OpenWorker is an open source project, and identifying and addressing security gaps is a priority. I cannot think of any security benefit to refusing to help us find security issues in our own code. If any issues exist, it is better that we find them before an adversary does.

Unfortunately, when we tried to perform one such review, both Claude Code (running Fable 5) and Codex (running GPT 5.6 Sol) refused. Notably, Codex did a decent job mapping out possible attack vectors (following well known procedures like those documented by the U.S.-funded nonprofit MITRE) but then refused to proceed beyond a certain point. So we used an open agentic harness — OpenWorker itself! — with both GLM 5.2 and Kimi K3 to complete our security review. To me, this is an important reminder of why open models, as well as open agent harnesses, lead to safer systems, and in particular to more secure software.

In fact, since attackers can now find flaws faster than ever because they have AI agents to help them do so, we have heard directly from a number of security officers who are frustrated that frontier closed models are refusing to help them.

I’m thrilled at the outpouring of support for open weight models, catalyzed by Jensen Huang’s recent statement. When it comes to online sentiment, the battle to support open weight models appears largely won on social media at this point. But, to be clear, it is far from won in Washington, D.C., and in state houses, so we still cannot back off! At the same time, to ensure safe, secure software, let’s make sure there are open harnesses in addition to open weight models.

Keep building!

Andrew

P.S. In case you missed it, on Tuesday I announced the launch of LearnVector, with an investment from Coursera. Fifteen years ago, Coursera and online courses changed education. With advances in AI, I’m excited about working to change it again. You can read more about it at learnvector.ai.

Dear friends,

A few frontier labs have tried to tell a story of open models being dangerous because they can be used to launch cyberattacks, and of their “safe” proprietary models with strong guardrails being there to defend us. This week, the opposite happened: Users of a closed model unintentionally launched a significant cyberattack; other closed models then failed to defend against the attack because of their guardrails. Ultimately an open model that was not hobbled by excessive guardrails assisted the defense.

The details of what happened are still emerging, but it appears that researchers at OpenAI, while testing one of their systems, accidentally allowed their autonomous agent to attack Hugging Face’s infrastructure. It succeeded and gained unauthorized access to some datasets and credentials. This attack was unusual in that the attacking agent orchestrated tens of thousands of automated actions.

Hugging Face took logs from the attack and tried to analyze them for defensive purposes using a commercially hosted LLM, but the LLM refused to do so on safety grounds. Thus, Hugging Face ended up using the open GLM 5.2 model to analyze the logs to help them understand and respond to the attack. Hugging Face pointed out a further advantage of using GLM 5.2: It allowed them to do the analysis on their own infrastructure, and none of the sensitive logs, attacker data, or credentials had to be sent to a third party provider.

Guardrails on LLMs do have a place. There are certain requests, such as for detailed directions to harm oneself or others, or for clearly criminal acts, that we’re better off having models refuse. But rather than trying to make LLMs “safe,” I would rather we put greater emphasis on making sure their use is responsible. There’s only so much one can do to make a tool like a hammer safe, and whether it helps or harms is more a function of using it responsibly than how it was made.

But a meaningful fraction of work on AI safety is no longer about safety but rather aimed at stoking fears to pursue regulatory capture. As David Sachs points out, “There’s no reason to limit American models on tasks that Chinese models handle without issue. We’re only making ourselves less competitive.”

I believe that open weight models, and more generally openness — despite some companies falsely saying it is dangerous — casts sunlight on technology and ultimately makes it safer. With the release of GLM 5.2 and the upcoming release of Kimi K3’s weights, open weight models have almost caught up to proprietary frontier models. Consequently, the proprietary model providers are dramatically accelerating their lobbying efforts to hamstring their open weight competitors. As Bill Gurley points out, open sourcing is a well established business strategy, not a danger to be licensed and contained.

While it is unfortunate that Hugging Face was accidentally attacked, I’m glad that at this moment, when anti-open model lobbying is at its most intense, we have a clear example of why open models actually make cyber defense easier and thus increase safety.

Let’s keep speaking up for and defending open source and open weight models!

Keep building!

Andrew

Dear friends,

As AI increasingly automates coding, it frees up developers to spend time on high-level software development tasks traditionally reserved for senior engineers, like deciding on technical architecture and participating in scoping product requirements. Demand for this type of work is growing, since it is an economic complement to coding, which is becoming cheaper. This is why I’m confident there will be rising demand for broad AI engineering skills. I see a similar pattern starting to emerge in other AI-influenced fields as well, and am cautiously optimistic — contrary to predictions of a “jobpocalypse” — that AI will generally increase demand for people with the right skills.

Take marketing. AI is helpful for drafting and editing marketing copy, gathering market data, and performing very basic data analysis. (In my experience, analyses by even frontier models are frequently wrong. So do use AI to help with your data-science tasks, but don’t blindly trust its confidently stated conclusions!) This frees up marketers to spend more time on higher-level tasks. I’m seeing that rather than specializing in narrow marketing roles like social media marketer or copy editor, AI-native marketers are rising up to help coordinate broader marketing campaigns end-to-end, from conception to multi-threaded execution to analyzing lessons learned.

Just as AI is turning many specialized developers (like frontend, backend, mobile, etc.) into full-stack developers, I am seeing early signs that it is turning many more marketers into full-stack marketers.

Or take recruiting. Some companies have separate roles for sourcer (who finds candidates online), coordinator (who handles scheduling) and recruiter (who runs the hiring process). But sourcing is increasingly automated, and coordination also partially automated. As a consequence, I’m seeing more AI-native recruiters run the full-cycle themselves, doing all of the above.

As AI enters more fields, I expect more people to start to play “full-stack” or “full-cycle” roles within their disciplines, meaning they will play broader roles that integrate traditionally separate roles. This lets individuals do more, and I believe it will ultimately lead to increased demand for skills as well as higher pay.

The broader pattern is this: In many job roles, as you rise in seniority, you become better at managing integration complexity — weaving together many disparate work streams like frontend, backend and data engineering to form a greater whole. As AI automates certain parts of one’s work — usually the more verifiable parts — it creates more room for individuals to play broader roles.

This pattern is not applicable to all job roles. In some, rising in seniority means increasing specialization. This corresponds loosely to people progressing in the IC (individual contributor) career track rather than the managerial/tech lead track. For example, a machine learning engineer acquiring extremely deep understanding of a technical niche, a financial expert growing from a generalist finance analyst to a specialist in an important sector (such as auditing cross-border deals), or a medical doctor developing deep expertise in just one medical condition. In many, but not all, such areas, I expect the demand for human skill to grow, but AI’s impact on any specialty will depend on how rapidly AI’s jagged frontier advances along that dimension. I’ll share more on this in a future letter.

Until then, I invite you to consider: Back in 2022, what tasks would your teammates have done? Those were likely complements to what you are doing. So if you are able to use AI to do more of those tasks yourself — which might require learning new skills — it could be one path to you becoming more effective with AI.

Keep building!

Andrew

Dear friends,

The key idea of agentic coding loops is to have an agent keep working until it satisfies a condition, such as achieving a product specification. Coming up with the spec, the evals, or test set is one of the hardest tasks for many AI systems, and a key place to inject human knowledge. Once you have a clear spec, the paths to fulfilling it (such as having a coding agent iterate) become clearer. I’d like to share useful practices for building product specs that drive coding loops when quickly building 0-to-1 applications. As I’ll explain below, one organizing principle I use is: AI tokens are cheap; human tokens are gold. (Yes, I know humans don’t literally tokenize, but I work so much with tokens that I now think of myself as providing tokens to my computers!)

When building a large, complex system, it is worthwhile to spend time architecting it well. This involves deciding, for example, what database do you want to use? How do you break down the workload across different services? What third-party dependencies are you locking yourself into? What are the API boundaries between frontend and backend? Thinking through such questions in advance helps to avoid being stuck with a bad decision that is hard to change.

But when building quick 0-to-1 prototypes or applications in domains I’m unfamiliar with, I often move faster and with less deliberation. I find it convenient to jump quickly into directing a coding agent to start building, so I can examine what it has built in order to make the next set of decisions. No need to spend an hour of human time mulling over a design spec when an AI agent will spend 20 minutes building a simple prototype; I’d rather spend 10 minutes writing an inferior spec, see what the agent has built, examine its assumptions, and then refine the spec and repeat the process. Instead of “spec drive development” becoming a new waterfall process where writing a spec is a gate to further progress, this allows me to more iteratively refine the spec.

For example, the first version of many apps I’ve prototyped had confusing UI designs that I modified the spec to fix, and no amount of my time spent tweaking the initial spec would have led me to realize in advance that these changes would be needed. Coming up with those human tokens on my own would have been too expensive. It was easier (and cheaper) to see what went wrong in order to explain how to do it right.

As a software project matures, coding agents will work longer (maybe hours) to build to more complex specs, But at this early stage, it is fine to throw away the entire codebase and restart from scratch, so nothing is hard to change. All that code was cheap, in human time and token costs. What we learned from testing it was more valuable.

Further, having one implementation to react to (or sometimes I’ll ask the agent for a few different designs) gives you an efficient way to get feedback (human tokens) to refine the spec to help drive later iterations. If you’re building a 0-to-1 product, I encourage you to put the coding agent to work, maybe even earlier than might feel comfortable, see what it comes up with, and use that as a starting point. Then document your reactions and keep iterating.

Here, too, you can make the agent do most of the work. One common source of frustration among developers is when we tell a coding agent something and later (maybe after memory compaction) it forgets what had said. I hope future coding harness improvements will ameliorate this, but for now, when I make key decisions, I often steer the agent to remember that decision somewhere, say in a SPEC.md file. In the course of building a project, a coding agent may generate millions of tokens — far more than the human developer would type. So if an agent discovers something and later forgets it, there is a cost, since it might burn more tokens to rediscover it — but this is not too bad. But if it forgets something that you told it, that is much more frustrating, since you end up having to tell it again: more golden tokens down the drain.

Coding agents have become less forgetful in the last few months because of model advances, but they still occasionally forget. When I spot something in a prototype that I’m unsatisfied with, often I tell the agent not only to fix it but also to update the spec (and perhaps the test plan), so the agent’s stopping criteria in the future require checking that this problem does not occur again.  This is one way to make sure it treats the human tokens as gold.

Keep building!

Andrew

Dear friends,

The AI world has become incredibly noisy. Social media, traditional media, and an army of marketers produce a cacophony of hype and content that are often secretly sales pitches for their products. Good ideas are buried in the noise, but it is hard to figure out what’s worth your time to learn. I want to explain plainly how we decide what to teach at DeepLearning.AI.

We have a simple mantra that drives the order for whose interests we prioritize: “Learners first, Partners second, Ourselves last.” When you lead a team, you get to pick a small number of mantras to repeat ad infinitum, to the point where the whole team is sick of hearing them. For DeepLearning.AI, I decided to make this one of them.

When we are exploring what to teach, we explore a wide range of topics, gathering from a network of technical experts in companies and academia, senior technology and business leaders, writings by technical experts, our team’s practical experience, and objective metrics of different tools’ traction and/or performance. We use these to synthesize our view of the most important topics to learn if you want to become skilled at AI Engineering. We then look for partners who are experts on these topics to work with us.

And yes, we routinely tell partners up front that we prioritize their interests second, behind learners. Even though this might seem counterintuitive from a business point of view, I believe that working only with partners who are aligned with our “learners first” philosophy will result in better courses and better outcomes for everyone. Specifically, working with partners who want to teach technically deep content, rather than just put out marketing materials, helps our partners to attract a larger audience, which benefits them as well as learners.

We build courses with many leading AI companies like OpenAI, Anthropic, Google, Microsoft, Meta, and Amazon (disclosure: I serve on Amazon’s board — and, yes, if we have an additional relationship with a partner or course provider, we always try to disclose such relationships transparently) as well as startups with advanced offerings. If your goal is to learn to drive a car, you need a car to practice. But the skill is driving, not the car. After learning, what car you continue to drive should be up to you. For example, our courses on agentic frameworks, even if taught with one partner, leave you with fundamental skills applicable to building with any framework. Our courses on evals leave you able to use any evals framework (or no framework). Our courses on prompting help you to prompt any model.

AI Engineering has important fundamentals, such as (i) using coding agents well, (ii) key building blocks like evals, error analysis, agentic workflows, and guardrails, and (iii) adjacent skills such as making basic product decisions or iterating quickly to build 0-to-1 products. Mastering these — sometimes best illustrated through a specific vendor’s offerings — matters more than mastering any one vendor’s tools. (At the same time, mastering multiple vendors’ tools lets you use them efficiently and has value, too.)

We deeply respect our partners. We carefully select which companies to work with, since we want ones that have and are willing to share cutting-edge knowledge. That’s why we choose partners who have deep, hard-won expertise. However, to ensure editorial integrity — prioritizing learners first — we have never accepted payment from any partner to create a course.

Many individuals and companies reach out with ideas of what topics to teach and who to work with, and we do consider suggestions. But we prioritize what courses to teach and who to work with based only on what we think is best for learners. The engineers who built a tool’s advanced capabilities are often the people most qualified to share how it works, so I am deeply grateful to the many partners who have joined us to serve learners together.

There is much to learn in AI, and DeepLearning.AI will continue to put learners first, partners second, and ourselves last.

Keep building!

Andrew

Dear friends,

“Loop engineering” is a hot buzzphrase after mentions of it by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw’s creator) went viral on social media. Loops are now a key part of how we get AI agents to iterate at length to build software. In this letter, I’d like to share my 3 key loops, shown in the image below, for building 0-to-1 products. These loops guide not just how I build software, but also how I decide what software to build.

Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention.

The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention!

Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on.

The developer-feedback loop operates over time intervals between tens of minutes and hours — that’s how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child’s learning experience.

When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful.

AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system.

External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent.

With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both!

I will write more about how to do this in future letters, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering).

Keep building!

Andrew

Dear friends,

Over the last two weeks, both the U.S. Government and Anthropic took significant actions that demonstrated their power to control access to AI by restricting what others can do with frontier models. This has been one of those moments that, once seen, will be hard to unsee, and it is significantly accelerating many businesses’ and nation states’ efforts to ensure reliable access to AI that no one else can terminate.

Anthropic first released Claude Fable 5, a version of its Mythos model with additional guardrails, including some restrictions that seem well justified on safety grounds (such as limitations on applying it to hacking, bioweapons, and so forth). However, it also restricted developers’ ability to use it to build competing LLM technology. This move was concerning, given that the whole AI community, including Anthropic, has benefitted tremendously from open research — indeed, the AI revolution was kicked off by my former team (Google Brain) freely publishing the Transformers paper!

Imagine if Microsoft’s terms of use barred anyone from using its tools to build competitive software, or if Google barred using its search engine to search for information to work on competing search engines. Anthropic’s argument that it was unsafe for others to be able to make advances in AI also rang hollow. Initially, Anthropic silently degraded Claude Fable 5’s performance for users detected to be working on LLM research through invisible interventions that weakened the model’s outputs without notifying users. After significant backlash, the company walked back this decision and decided to be transparent when it did this, but Claude Fable 5 still refuses to use its latest capabilities to help AI researchers.

This move represents a raw demonstration of power by Anthropic. It has used “safety” arguments to hinder potential competitors. Platforms succeed when they are viewed as stable, reliable partners that one can build on. The sudden rule changes by Anthropic (including a mandatory 30 day data retention policy for Claude Fable 5 usage) have made developers wonder about the stability of building on any one proprietary LLM provider, not just Anthropic.

The U.S. Government then shortly followed with an even greater demonstration of power. It used the Commerce Department’s authority to regulate technologies that may be national security threats to restrict exports of Claude Mythos 5 and Claude Fable 5, requiring a license for use by any foreign national, whether inside or outside of the U.S., including employees of Anthropic. This led Anthropic to disable access to Claude Fable 5 to all users worldwide.

OpenAI CEO Sam Altman pointed out, referring to Anthropic, “It is clearly incredible marketing to say, ‘We have built a bomb, we are about to drop it on your head. We will sell you a bomb shelter for $100 million.’” But when one engages in this type of fear-based marketing, it increases the odds that the U.S. Government will agree with you and slap export controls on the bomb you say you have built.

To be clear, I don’t think Anthropic has built anything like a bomb, and I don’t think export controls on Claude Fable 5 are appropriate.

However, following the U.S. Government making this move, many nations, including U.S. allies, saw how the U.S. can suddenly yank their access to AI models. In many capitals around the world, this has spurred discussions on AI sovereignty and how others can ensure uninterrupted access to this critical technology.

For decades, many nations were comfortable having many parts of their supply chain rely on the U.S., China, and other major producers. Once a nation issues a threat or takes action to limit other nations’ access, other nations will rationally try to secure alternatives. For decades, semiconductor manufacturing in China made slow progress; once the U.S. moved to limit China’s access, China’s efforts kicked into high gear. Similarly, once China threatened U.S. access to rare-earth minerals, U.S. efforts to secure alternatives accelerated. Now that it has become crystal-clear that private U.S. companies and the U.S. government can limit, in short order, other nations’ access to frontier AI models, the incentive of others to invest more in alternatives like open source grows significantly. Of course, training frontier models is not easy, so it remains to be seen how successful they are, but we have crossed the Rubicon.

Microsoft CEO Satya Nadella wrote an essay about the importance of building a healthy ecosystem on top of frontier AI technology. I heartily agree with him, and hope this week’s events will ultimately prove to be constructive steps toward this.

I hope we can build a more-free, more-open world where research is freely shared, and laws and societal norms shape a level playing field that allows everyone to make progress. A silver lining of the events of these past two weeks is now that everyone better realizes key points of instability of the current system, we can all work to create a more stable foundation.

Keep building!

Andrew

Dear friends,

If you haven’t already, I encourage you to experiment with using AI agents not just to chat but to actually do work for you on your desktop. Desktop agents not only chat with you but also read and edit local files, read/send messages, and provide scheduled deliverables like a daily news summary. While there’s nothing wrong with copy-pasting output from web-based chatbots to a desktop or dragging and dropping files into chatbots to give them context, desktop agents can gain context more efficiently as well as take actions directly.

The main way such an agent is built involves creating a set of tools (function calls) for tasks such as file access, web search/web fetch, messaging app integration, and so on; providing these tools to a frontier LLM; and setting up permissions and guardrails. Then you prompt the LLM and let it pick when to use what tool to move forward on a task. The software that wraps around the LLM to implement a desired agentic system is called the agent harness, and it enables the LLM to drive the key loop that decides what to do next at each step.

So far, most practical Agentic AI workflows (except for coding agents) have not relied on the LLM to this extent to decide what to do next. Instead, they have relied more on developer-specified workflows to deliver higher reliability. But in the past few months, frontier LLMs have advanced sufficiently for this style of harness design to provide an important, if still not entirely reliable, alternative.

CLI (command line interface) coding agents (like Claude Code, Codex CLI, Antigravity CLI, and OpenCode) have been the main type of agent that uses an LLM to drive the next action. But there’s also value to non-CLI agents with easy-to-use interfaces. More precisely, consumers  currently interact with AI systems through three key interfaces: (i) chat interfaces (like the web version of ChatGPT), (ii) coding CLI tools, and (iii) desktop agents that can carry out tasks.

I do not use existing commercial desktop agents for highly confidential tasks, since I’m uncomfortable with some of their data-retention policies, which are often buried in obscure legalese and might change overnight with a new model (as we just saw with Anthropic’s Fable release). Also, if you make a small misstep, it may have unexpected legal consequences such as losing legal privilege to confidential documents.

In light of these concerns, my collaborators Rohit Prsad, Devika Verma, and I have been working on a free, open-source alternative: OpenCoworker. This is an open-source project we put together while extending aisuite to support agent harnesses. If you’re interested in learning more about agentic harnesses, you might enjoy checking out the code.

Using OpenCoworker requires your own API key from OpenAI, Anthropic, Google, or another provider, or you can run a local model using Ollama so nothing ever leaves your machine. Some of the data integrations, such as email, are still difficult to set up (comparable in difficulty to what users of other open-source projects such as OpenClaw or Hermes Agent users might have experienced). It saves its memory on your computer, and you can choose a LLM provider with a zero data-retention policy, local inference, or other options depending on your privacy requirements.

My teams have been experimenting with OpenCoworker for a wide range of tasks like messaging automation, creating documents, and workflow automation. This is a work in progress, and I hope the open-source community will ensure that there is a viable, open, desktop agent option that is comparable or superior to the closed ones. We are working to make OpenCoworker easier to use, and welcome contributions as well as feedback!

Keep building!

Andrew

Dear friends,

There have been intense efforts over the past few years to lobby governments to pass AI laws for regulatory capture or to suppress open source. This week, the White House issued an executive order that provides new guidance for companies that build frontier models. It promotes AI development while taking into account its impact on security. I’ve long been concerned that overregulation will stifle AI progress. In the case of this executive order, it’s a close call, but the result is a reasonable compromise between encouraging AI development and protecting security.

We could have ended up with a stifling executive order that would have been very burdensome for model builders, as I’ve written in earlier letters. I’m grateful to David Sachs, who co-chairs the President’s Council of Advisors on Science and Technology, as well as AI policy advisor Sriram Krishnan and others who worked hard to make the order reasonable. At the same time, I remain cautious about ongoing lobbying efforts and the temptation to overregulate.

This latest push to regulate AI was driven by cybersecurity concerns. Specifically, Anthropic’s Mythos was a significant step forward in automatically finding vulnerabilities in code. Over the long term, improved vulnerability detection will make software more secure. When bugs are more easily found, the advantage naturally lies with defenders, who can work to patch them. So having software that enables everyone to find vulnerabilities is a good thing — eventually!

But while the world is navigating the transition to this end state, we should minimize the window where attackers — including highly resourced ones like nation states — can find and exploit vulnerabilities where defenders have not been able to invest the resources needed to identify and patch them. This reflects a legitimate risk, and we should take reasonable and proportionate measures. For instance, the executive order mandates ramping up defensive efforts. Additionally, it sets up a framework for frontier labs to share their models with the government on a voluntary basis and collaborate on cybersecurity. I find this, too, helpful and reasonable.

Unfortunately, whenever there are legitimate risks, there is also a temptation to overregulate. Take commercial operations that braid hair. This is a very safe activity, but it does carry small risks. After all, we don’t want hair stylists to have such poor hygiene that they infect their clients with lice or diseases. But many U.S. states require someone wishing to braid hair commercially to engage in hundreds of hours of training to obtain a license. This requirement unnecessarily stifles small businesses. In a choice between excessive regulations and no regulation at all on this art, we would be better off with no regulation. The extremely low risk of an infection is better than stifling the whole industry.

In the case of AI, I am glad the U.S. government is taking cybersecurity seriously. At the same time, many lobbying attempts have already used fear driven by science-fiction narratives (for instance, AI leading to human extinction) to impose burdensome bureaucratic requirements or unreasonable types of liability on model trainers if others misuse their models. It took a lot of work to beat back regulations based on these narratives. This time round, there is actually a legitimate risk. When lobbyists are armed with an even more powerful weapon to push for excessive regulation, it becomes even harder to find a balance between reacting proportionately and over-regulating.

As AI continues to develop, I’m sure that new harmful ways to use it will arise alongside the far larger number of beneficial ways. Nations will be better off if their governments are able to demonstrate sound technical judgement and navigate that fine balance. I suspect, though, that governments that aren’t confident of their ability to find a balance will do better to slow down their regulatory impulses to form a clear assessment. Often, no regulation will be better than over-regulation.

Keep building!

Andrew