The following article originally appeared on Addy Osmani’s blog site and is being republished here with the author’s permission.

If the AI layer gets good at anything, it will be anything that has an answer key. School used to be answer keys all the way down. School is the ultimate anchoring of success, because it’s all about getting the right answer. The thing that makes work durable and ungradable in the age of AI is not getting any better at solving problems. It’s not being able to build systems or understanding people or making cool new things. It’s choosing what to build and judging if it’s good. The rest will all be done better and faster by AI.

I started in engineering at 16, building a browser in rural Ireland. I was at Google for over 14 years, where I led engineering teams working on Chrome, Gemini, and Cloud AI, and I’ve written a number of O’Reilly books. I’ve turned down offers from frontier labs and FAANG companies when the fit wasn’t right. Good people are always needed, so we each have an obligation to try our hardest and make the best thing we can.

Most career advice still holds up. Get on the rocket ship; don’t overoptimize your seat. The specifics have changed a little because of agentic coding, but here’s what I wish I’d known for ambitious engineers out there now.

Optimize for scarce resources. Almost nothing I’m known for came from chasing the highest pay. The years I spent in open source had almost zero direct payoff. But they led to reputation and relationships that very efficiently compounded into opportunities later. I would have spent the comp I got from any single job. My reputation kept paying.

Many resources are abundant. Capital is abundant. Time is abundant. Real relationships, and especially a track record of doing good work, are still scarce. I can raise money in a couple weeks, but I can’t raise a reputation. So here’s the plan: Do good work, and make sure the people who like good work see it. In a world where vibe coding makes earning a quick buck trivial, I think that quick buck is worth very little. When shipping stuff is so easy, the scarce move is choosing something worth shipping.

Learn to find problems, not just solve them. The first time I ever felt the burden of selection rather than solution, LeetCode seemed a measure of skill. But as agents absorbed all that work, solving problems went cheap while selecting them became scarce. My origin story: I noticed dial-up was slow, created chunked multiconnection fetching, realized I’d never solve that problem in my life, and quickly moved on to whatever absorbingly complex one I could find next. Finding problems predated solving them.

I’ve watched students who were wildly good fall flat on their face when an agent ran through their problem set (like watching the wrong microwave number on the clock). The same agent. The same problem set. Wildly different token and time budgets. Why? Because at the end of the day, the strong ones bring judgment and intuition to the work; the rest bring a prompt.

I used to build that judgment by grinding out boilerplate and fixing bugs. I got to see and deeply feel the worst abstractions humans could devise. I approached each commit with the awe of someone who’d just seen the fever dream of previous authors. Each commit brought hindsight and judgment. The agents automate those reps. Taste is pattern-matching, but all that pattern-matching has to be earned by doing the work.

The real risk isn’t agents writing bad code. We’ve been there before. It’s losing the ability to tell. Judgment will atrophy. Output will look a lot like working code.

Good practitioners don’t put agents in front of everything. They engage in deliberate practice. Pick a few problems that really matter. Do them the hard way, without the agent, building deep mental models of how systems and languages work. Read a thousand times more code than you ever write. Treat every diff from an agent like a human review you need to carefully justify. Go deep on at least one system end to end, from intake to output. On a daily basis, keep a private log of every time you see an agent suggest something that looks wrong and confidently flag it. That’s where taste accumulates.

The real thriving engineers won’t be the fastest at getting suggestions. They’ll be the ones who know instantly when to say no.

Shift from doing to directing. Just like you’d delegate to a person, you need to learn to delegate to an agent. Scope the task, define done, calibrate trust, and verify the result.

Autonomy is a setting, not a rank; it’s a per-task switch. Turn it up to the maximum on something small and reversible and cheap to check. Turn it down on anything where mistakes will be hard to undo.

Specification and verification are two distinct, complementary skills. The agent isn’t as good as the intent you hand it. The best engineers are those who know how to write precise specs; clear thinking made legible.

It’s verification, not evidence. Not evidence in the form of an agent grading its own homework. There’s nothing more demoralizing than delegation without verification at scale.

Own what you ship. If the agent wrote it and it breaks in production, “the AI did it” is not a defense. Your name is on the change. Adopt the posture of an accountable human who understands what went out the door and how to fix it.

Solve the most ambitious version of the problem. Rich Sutton’s bitter lesson: In almost every field, general methods that scale with additional compute beat out hand-tuned equivalents. As a career lesson, there’s no point in solving an easy version of the problem—it’s worth almost nothing. The value ends up concentrated in the hard version.

Sprint the last mile. No turnkey agent writes a whole system from end to end. As a rule, you’ll get 70% of a feature quickly from an agent, and the last 30%—debugging the gnarly edge cases, figuring out the right architecture, cultivating the right taste—will be the whole game. The median output today is whatever the agent produces from some lazy prompt. The only personal value you can bring to the table is getting as far as you possibly can past that median. When first drafts come free, finish is the product. To sprint the last mile, here’s my tactic: Every few months I completely rebuild from scratch using the latest sharp-end-of-the-sword model. It’s less exhausting than nursing half-hearted old code to health.

My job as a software engineer has been to finish strong. The difference between finishing strong and finishing okay is the polish: spending an extra hour, which shows instantly to everyone who matters.

Increase both your xG and your finishing

If soccer had a stock ticker, it would be xG. xG measures the number of chances your play should produce. Finishing measures whether you convert them. You can’t plan the number of chances you get, but you can hope your play produces enough, and over your career you can get better at finishing them.

The same is true of careers: Your reputation gets you in front of goal, and you convert them with good judgment. Chances arrive whether you’re ready for them or not; how many you get, and which ones you finish, is up to you. I’ve only ever had big opportunities as a result of work I’ve done in public, never from a job I’ve applied for. You can’t script which chances arrive, only whether you’re standing where they land. You have to create the opening as much as you can, and then be ready to take it.

One easy mistake is anchoring on whatever product your company has right now. It’s true that your work has to exist somewhere, but a good team quickly mutates their current offering into something unrecognizable. So bet on the team and the market opportunity, not the demo. It’s just a snapshot. The team is the trajectory.

On superintelligence: It’s possible (I believe) that future models will eventually come to replace much of what we do as knowledge workers. It won’t erase it overnight, it won’t replace all of it, and it won’t be able to do many of the tasks we do. New kinds of jobs will be created. Verification will always be a bottleneck. Someone has to make the call on which problems are worth solving and allocate the correct amount of judgment to each, and that someone can be you.

But importantly, you can do frontier work right now, from where you are. The gate to AI research is smaller than it looks, and you don’t need a lab to build intuition. Just use models hard, and turn what you notice into evaluations. Evals and benchmarks are where understanding lives.

To summarize: The world isn’t short on opportunity; it’s short on people who can find the right problem, tell whether the machine solved it, and finish past where the machine stopped.

We sometimes talk about the “last mile” as the biggest piece of the puzzle. But in the world of agents, the last few feet are infinite (agents scale output infinitely; you don’t). Your attention is your most precious asset, and it doesn’t refill. You can’t afford not to protect it. Anything which is gradable by someone else is getting automated. The career is the ungradable part: choosing what matters, judging honestly when you’ve got it, and answering for it. Do that. In public. Near the hard problems. The rest tends to follow.

. . .

This piece grew out of Phil Chen’s original, which is well worth reading in full.

. . .

And be sure to join us at AI Codecon: Building with Open Source AI on August 31, a free half-day virtual conference. You’ll hear from leading developers and technical experts working with open-weight models, self-hosted infrastructure, and real-world AI workflows, and learn how building in the open gives teams more control over costs, data privacy, and what they ship. Register today to save your spot.

In July 2026, GitHub Agentic Workflows added Docker Sandboxes as a supported agent runtime. It means that in your CI an AI coding agent can have broad control of its environment, including being able to run Docker containers, while the environment itself is isolated in a microVM with a network policy and secrets injection like the current best practices for AI isolation advice. 

Agentic isolation matters because useful coding agents do more than read a repository and suggest a patch. They install tools, run arbitrary shell commands, execute project code, start databases, and occasionally discover surprising new meanings for the word “cleanup.” Those capabilities make the agent useful, and direct access to a CI runner gives every mistake a larger blast radius.

Now, with sbx integrated, the boundary for the Agent is a disposable environment with substantial freedom inside and narrow access to everything outside it.

I put together a small example to see what that looks like in practice. The agent runs on a GitHub-hosted Ubuntu runner, enters a Docker Sandbox (sbx), runs a Java integration test suite with PostgreSQL using Testcontainers, finds an intentionally seeded bug, fixes it, and opens a draft pull request. The Github Agentic Workflows offers the integration out-of-the-box, so the setup requires zero custom configuration for actions.

What are GitHub Agentic Workflows?

GitHub Actions remains the CI system. It schedules the job, provides the Ubuntu runner, manages permissions and secrets, and records the result.

GitHub Agentic Workflows, usually shortened to gh-aw, is an open-source GitHub CLI extension and compiler. You describe an agentic workflow in a Markdown file that combines execution configuration in YAML frontmatter with the agent’s task in the body. Running gh aw compile turns that source into a conventional GitHub Actions workflow with a .lock.yml suffix.

The relationship looks like this:

Markdown workflow
    |
    | gh aw compile
    v
Generated GitHub Actions .lock.yml
    |
    | runs on ubuntu-24.04
    v
Docker Sandbox microVM
    |
    v
Copilot agent and its tools

docker-sbx belongs to gh-aw‘s agent runtime configuration. The runs-on field still selects ubuntu-24.04, and the compiled file is a standard GitHub Actions workflow. It installs the sandbox tooling, authenticates it, checks the runner, starts the agent in the sandbox, and cleans everything up afterward.

That integration landed in gh-aw and shipped in version 0.82.9.

Configuring sbx in GitHub Actions

Here is the configuration from the sample’s sandbox-explorer.md:

---
name: "Docker Sandboxes sample: exploratory test"

on:
  workflow_dispatch:

runs-on: ubuntu-24.04

permissions:
  contents: read
  copilot-requests: write

engine: copilot

network:
  allowed:
    - defaults
    - github
    - containers
    - java

sandbox:
  agent:
    id: awf
    runtime: docker-sbx
    sudo: true

tools:
  edit:
  bash: [":*"]

safe-outputs:
  create-pull-request:
    title-prefix: "[docker-sbx sample] "
    draft: true
    protected-files: blocked
    allowed-files:
      - "src/**"
---

The three lines under sandbox.agent select the Docker Sandbox runtime. Inside it, the agent has the sudo and unrestricted shell access needed to build the application and start its test infrastructure.

Outside the sandbox, the workflow keeps a much smaller surface. Its network block allowlists the destinations this job needs, while the agent’s GitHub token can read repository contents and send requests to Copilot. Pull request creation happens in a separate safe-output job whose patch may contain files only under src/**.

How much autonomy a CI agent should receive depends on the job. For this one, the split is useful: broad shell access inside the sandbox, small network and repository surfaces outside it, and a draft PR that still expects human review.

The isolation boundary is a micro VM

While it’s common to assume that “Docker” implies a single application container, this setup actually uses a microVM as the primary isolation boundary.

With sbx, every sandbox is a dedicated environment with its own kernel, filesystem, and network stack. Most importantly, it runs its own private Docker daemon. This means the agent gets full root privileges inside the VM without ever gaining control over the host’s Docker daemon. The only bridge between them is the explicit shared workspace of the repository.

Having a private daemon is a game-changer for integration testing. In this demo, the app runs Testcontainers exactly as a developer would on their local machine. The resulting structure looks like this:

GitHub Actions runner
└── Docker Sandbox microVM
    ├── GitHub Agentic Workflows agent
    └── Private Docker daemon
        ├── Maven / Java 21 container
        └── PostgreSQL Testcontainers container

To keep the environment clean, the test launcher runs Maven inside a pinned container, passing the sandbox’s Docker socket through so it can talk to the private daemon:

docker run --rm \
  --add-host=host.testcontainers.internal:host-gateway \
  -e TESTCONTAINERS_HOST_OVERRIDE=host.testcontainers.internal \
  -v "$PWD:/workspace" \
  -w /workspace \
  -v /var/run/docker.sock:/var/run/docker.sock \
  maven:3.9.9-eclipse-temurin-21@sha256:3a4ab3276a087bf276f79cae96b1af04f53731bec53fb2e651aca79e4b10211e \
  mvn --batch-mode "$@" test

Testcontainers then uses that socket to spin up the PostgreSQL database. It sounds like a lot of layers—a container running a build that starts another container, all inside a microVM on a CI runner but each layer serves a specific purpose in ensuring the agent remains isolated yet fully capable.

Giving the agent a defect worth finding

The sample is a small Java 21 registration service. Its requirements say that email addresses are case-insensitive. The seeded implementation stores them as provided and relies on PostgreSQL’s case-sensitive unique constraint. An existing Testcontainers integration test catches exact duplicates but says nothing about the latter case.

The Markdown portion of the workflow asks the agent to inspect the requirement and code, run the baseline suite, and add a test for two addresses that differ only in case. If the invariant fails, the agent should make the smallest source correction. Before touching the application, it records uname, Docker version, Docker information, and a tiny Alpine container run, leaving specific evidence in the workflow log about where the work executed.

The task itself is plain Markdown beneath the frontmatter in the yaml file. The important part for us (after some commands for recording the environment for debugging) is:

Act as a bounded exploratory tester for this repository.
... 

Then:
1. Read `REQUIREMENTS.md` and the relevant source and test files.
2. Run `./scripts/test-in-docker.sh` without changing anything.
3. Add a PostgreSQL Testcontainers test that checks registration of two
   addresses that differ only in letter case.
4. Run the focused test and explain the observed behavior.
5. If the implementation violates the documented invariant, make the
   smallest fix under `src/`.
6. Run the complete test suite again.
7. Create one draft pull request containing the regression test and fix.

And the prompt level guardrails to suggest the correct behavior: 

Do not modify dependency manifests, workflow files, scripts, documentation,
or generated files. Do not weaken or delete existing tests. Include the
commands run and their results in the pull request description.

The real run of course followed that path: its baseline passed, then the new case-variation test failed with:

expected: <false> but was: <true>

The agent normalized the email before inserting it, reran the complete suite, and got two passing integration tests.

The log reported Docker client and server version 29.7.1 with the default context. It is the correct Docker version currently in the sbx default sandbox template. This is the sandbox’s private daemon, the one Testcontainers library used to launch PostgreSQL for the integration tests. 

The complete workflow passed on GitHub’s hosted ubuntu-24.04 runner. The run took 11 minutes and 16 seconds.

The safe-output job then opened a draft PR containing exactly two files under src/**: the regression test and the one-line normalization fix. Workflow configuration, scripts, dependencies, and documentation were outside its allowed patch surface.

The generated draft pull request stayed inside the declared source-only boundary.

Running the workflow yourself

Start by installing the gh-aw:

gh extension install github/gh-aw

The compiled Docker Sandbox runtime needs Docker credentials to authenticate and pull its sandbox template. Add DOCKER_USERNAME and DOCKER_PAT under the sample repository’s Settings > Secrets and variables > Actions, or let the GitHub CLI prompt for both values:

gh secret set DOCKER_USERNAME
gh secret set DOCKER_PAT

The repository’s Copilot entitlement and copilot-requests: write were sufficient for the successful sample. Repositories without that entitlement can use a supported COPILOT_GITHUB_TOKEN secret as documented by gh-aw.

Also enable Allow GitHub Actions to create and approve pull requests in the repository’s Actions settings. Then compile the Markdown source and commit both the source and generated workflow:

gh aw compile sandbox-explorer

git add .github/workflows/sandbox-explorer.md \
  .github/workflows/sandbox-explorer.lock.yml
git commit -m "Compile Docker Sandboxes sample workflow"
git push

The .lock.yml is generated code. Changes belong in the Markdown source, followed by another compile.

Finally, start the workflow and watch it:

gh aw run sandbox-explorer
gh run watch

The sample works on GitHub’s hosted ubuntu-24.04 runner as committed. A self-hosted Linux runner needs an appropriate KVM-capable setup, plus the Docker and system access required by Docker Sandboxes.

Try sbx on your laptop

Support for isolating your agents in CI is fantastic, but the easiest way to understand Docker Sandboxes is to put one around an agent on a local project. Follow the Docker Sandboxes setup for your platform, sign in, move to a repository, and run an installed agent:

sbx login
cd ~/my-project

sbx run <claude|codex|opencode>

Give it a task that needs real tools, such as running tests, building an image, or starting a Testcontainers dependency. sbx is much easier to evaluate and understand when the workload is your actual development loop.

And if your experiment grows into an organization-wide agent rollout, Docker AI Governance is the next thing to explore. It applies organization and team policies for sandbox network, filesystem, and MCP access, and records policy decisions in audit logs. Those records help to identify the source client, including sbx, and the machine hostname, so the same policy and audit model can easily cover your  team’s laptops and your CI runners.

Highlights

New option checkConditionalExpressions in no-unmodified-loop-condition

The no-unmodified-loop-condition rule now supports a checkConditionalExpressions option. When enabled, each branch in a ternary expression is checked independently.

For example, with { "checkConditionalExpressions": true }, the rule reports the done variable as not modified in the loop:

let chunk = getInitialChunk();
let done = false;

while (chunk ? !done : false) {
    chunk = nextOrNull();
}
1
2
3
4
5
6

Features

• 08de88e feat: handle underflow in no-loss-of-precision (#21218) (Rithish S)
• 55db479 feat: add checkConditionalExpressions to no-unmodified-loop-condition (#21175) (sethamus)

Bug Fixes

• 2ba3025 fix: prevent unsafe no-var autofix with hoisted functions (#21213) (sethamus)
• 8e69622 fix: Prevent no-var autofix when var is shadowed by catch parameter (#21204) (Yang Hyeonjong)
• 684b579 fix: prefer-template invalid autofix creates a tagged template call (#21207) (김채영)

Documentation

• 9ef407a docs: use eslint.config.* wherever config file names are listed (#21216) (Marry (Subin Yang))
• 87f66f4 docs: Update README (GitHub Actions Bot)
• 585ef37 docs: update architecture documentation (#21112) (Francesco Trotta)
• f3993b0 docs: Update README (GitHub Actions Bot)
• ffc87d6 docs: fix broken links in Further Reading sections (#21203) (Minsu)
• 1a761e1 docs: update moved JSX specification links (#21198) (Imran Mustafa)
• 4d00ca4 docs: update ESLint peer dependency to ^10.0.0 in shareable configs (#21202) (lumir)
• 510d1a2 docs: Update README (GitHub Actions Bot)

Chores

• 899dbf1 chore: update github/codeql-action action to v4.37.7 (#21243) (renovate[bot])
• 9aa3873 chore: update ecosystem plugins (#21235) (ESLint Bot)
• dc1e7a8 chore: update ecosystem plugins (#21208) (ESLint Bot)
• f878d21 ci: bump pnpm/action-setup from 6.0.9 to 6.0.10 (#21200) (dependabot[bot])
• 4891e50 ci: bump github/codeql-action from 4.37.4 to 4.37.6 (#21199) (dependabot[bot])

Ranjan Roy from Margins is back for our weekly discussion of the latest tech news. We cover: 1) Big Tech is spending trillions more than it tells us on AI infrastructure 2) The mechanisms of the off-balance-sheet AI buildout 3) What would happen if these projects were on the balance sheet? 4) Can Wall St. actually not figure this out? 5) Will the tech giants pay the money back? 6) Is a soft landing in AI possible at this point if things go poorly? 7) Anthropic's revenue numbers are soaring 8) OpenAI, meanwhile, is in more tumult 9) Why OpenAI is dealing with so many executive departures 10) Startups vs. established companies, and what are the AI labs exactly? 11) Why travel is a good eval for AI

---

Enjoying Big Technology Podcast? Please rate us five stars ⭐⭐⭐⭐⭐ in your podcast app of choice.

Want a discount for Big Technology on Substack + Discord? Here’s 25% off for the first year: https://www.bigtechnology.com/subscribe?coupon=0843016b

Learn more about your ad choices. Visit megaphone.fm/adchoices

Why do AI systems silently fail? How can you set up a system that produces results while also reviewing and validating the work? This week on the show, Calvin Hendryx-Parker returns to discuss his recent talk “Orchestrate Agentic AI: Context, Checklists, and No-Miss Reviews.”

Calvin describes how silent failures can occur when handing a large document to an LLM for parsing. He describes it as the tragedy of context, where the LLM is confident, but you have no idea what it didn’t read. We discuss issues with file formats, dropped attachments, and silent truncation.

Calvin shares the example project from his talk, which includes Markdown files for the agents, hooks, skills, and scripts. He also discusses a variety of coding agents, skill frameworks, and CLI tools.

Topics:

• 00:00:00 – Introduction
• 00:02:19 – Co-hosting Python Bytes
• 00:03:43 – Why AI Fails Silently talk
• 00:11:07 – Digging into silent failures and an audit trail
• 00:18:44 – How would you define hooks?
• 00:20:48 – Document extraction, embeddings, and Cowork
• 00:30:38 – Stripping the noise from file formats
• 00:34:43 – Things that are now baked into models
• 00:45:53 – Video Course Spotlight
• 00:47:23 – Leveraging agents to pick models
• 00:51:44 – GitHub repo for the project
• 00:54:57 – The current market around tokens
• 01:00:12 – What are you excited about in the world of Python?
• 01:03:02 – What do you want to learn next?
• 01:04:21 – The content the LLMs are trained on
• 01:07:36 – Upcoming events
• 01:08:38 – Thanks and goodbye

Show Links:

• Why AI Fails Silently and How to Fix It
• Claude Cowork - Claude by Anthropic
• List of All Oblique Strategies - Matt Rickard
• Pi Coding Agent
• goose - Your open source AI agent
• Codex CLI - ChatGPT Learn
• 2026 All Things Open AI: Orchestrate Agentic AI: Context, Checklists, and No-Miss Reviews - GitHub
• scaf: A template manager that simplifies bootstrapping and updating projects.
• Tau - Learn how coding agents are built.
• superpowers: An agentic skills framework & software development methodology that works.
• Hermes Agent — Open-Source AI Agent That Grows With You
• PyOhio 2026 - PyOhio 2026
• AWS re:Invent 2026 - Nov 30-Dec 4, Las Vegas
• Python Bytes - Python News Podcast
• beats the hell out of me - painfully - YouTube

Level up your Python skills with our expert-led courses:

• Getting Started With Claude Code
• Use Codex CLI to Enhance Your Python Projects
• Coding With OpenCode: AI-Assisted Python

Support the podcast & join our community of Pythonistas