标签：#AI

This is The Stepback, a weekly newsletter breaking down one essential story from the tech world. For more on AI safety, follow Robert Hart. The Stepback arrives in our subscribers' inboxes at 8AM ET. Opt in for The Stepback here. How it started It all started in July, when one of OpenAI's autonomous AI agents […]

In 2027 and 2028, there will be two spectacular, long-duration solar eclipses. Here’s what you need to know about them.

Cloud-based AI has two persistent problems for mobile developers: latency, because every inference call is a round trip to a server, and privacy, because user data has to leave the device to be processed. By 2026, Apple has shipped enough of a native stack that bypassing the cloud entirely — architecting genuinely autonomous agents that run inference, reasoning, and action selection directly on-device — has moved from a theoretical exercise to a practical, documented architecture pattern. Why Local-First Is the 2026 Competitive Edge The clearest signal of how seriously Apple is treating this shift arrived at WWDC 2026 with Core AI, a new OS-level framework built directly into Apple Silicon. Core AI allows developers to load, specialize, and run AI models entirely on-device — including local language models up to 70 billion parameters — with zero server dependency and zero token cost. Models are automatically specialized for the hardware they run on, with ahead-of-time compilation support for fast load times. That's a meaningfully different proposition than earlier on-device AI efforts: it's Apple positioning local inference as genuinely competitive with cloud-scale models, not just a lightweight fallback for when connectivity is poor. The Three-Piece Agent SDK As of 2026, Apple effectively ships three developer-facing pieces that together form something close to a full AI agent SDK. The Foundation Models framework handles on-device inference — direct, programmatic access to the same large language model that powers Apple Intelligence itself, running on the device's Neural Engine rather than through a wrapped cloud API. App Intents exposes an app's actual capabilities to that intelligence, acting as the action layer an agent can call into. Private Cloud Compute (PCC) handles the cases that genuinely exceed on-device capacity, providing a scale fallback rather than a default path. The on-device model handles reasoning, App Intents handles action, and PCC handles scale

On August 14, 2026, auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max and Team plans. The agent stops asking before each step and simply proceeds, unless the action it wants to take is judged irreversible, destructive, or aimed outside your environment. Anthropic's argument for the change is a number from its own testing: in a 1,053-action study, auto mode blocked 89% of harmful actions, while humans clicking through approval prompts caught 13.6%. The uncomfortable half of that finding is why — users habitually approved 97% of the prompts they were shown. If you have used a coding agent for more than a week, you already know the feeling being described. The prompt stops being a decision and becomes a keystroke. Anthropic calls this permission fatigue, and it is making the case that a model checking each action against a policy is a better guard than a human who has stopped reading. What changes on August 14, and what does not Three things are true at once, and they get mixed up in most of the coverage. First, the default flips only for new sessions on Pro, Max and Team . Existing sessions keep the mode they are running in. Second, auto mode is not "approve everything." Actions classified as irreversible, destructive, or targeting something outside your environment still stop and wait for you. Deleting data, force-pushing over history, and reaching for a remote system you did not point the agent at are the shapes of action that still surface a prompt. Third, the rollout ships with two controls that matter more than the default itself: prompt-injection screening on incoming content, and hard deny rules you configure so that certain actions can never be taken regardless of what the model concludes. Deny rules are the part worth your afternoon. They are the only control in the list whose behaviour does not depend on a model's judgement. The 89% number cuts both ways Eighty-nine percent blocked means eleven percent not blocked. On a s

In mid-July, my Google clicks in my home market (Israel) dropped by almost half. Buyer-intent queries that used to bring steady leads just evaporated from Search Console. While I was staring at GSC dashboards trying to figure out what broke, I finally did the thing I should have done months earlier: I stopped looking at dashboards and started reading raw server logs. What I found there was a parallel universe. Google Search was sending me less than ever — but AI systems were reading my site constantly . Not "someday this will matter" constantly. Right-now constantly: an AI assistant was fetching a page of mine roughly every 26 minutes, around the clock, because a real human had just asked it a question. So I built a small log analyzer and let it run. Here's what 34 days of complete Caddy logs from a small business site (about 70 real human visitors a day) actually look like. The numbers All counts are HTTP 200 responses only (more on why below), over 34 days: Bot Requests Per day What it is bingbot 5,444 158.2 Bing's index — which feeds ChatGPT ChatGPT-User 1,388 40.3 Live fetch while a human asks ChatGPT Googlebot 1,233 35.8 Classic Google crawl GPTBot 547 15.9 OpenAI training crawler Claude-User 519 15.1 Live fetch while a human asks Claude OAI-SearchBot 281 8.2 ChatGPT search indexing Applebot 268 7.8 Apple (Siri / Apple Intelligence) ClaudeBot 214 6.2 Anthropic training crawler Amazonbot 136 4.0 Amazon (Alexa & co.) PerplexityBot 103 3.0 Perplexity indexing Three things in that table genuinely surprised me. ChatGPT-User outreads Googlebot. 40.3 fetches a day versus 35.8. This isn't a crawler building an index for later — ChatGPT-User is the user-agent OpenAI sends when a human is mid-conversation and ChatGPT decides to pull a live page to answer them. On my site, that now happens more often than Googlebot visits. For a tiny business site in a niche market, I did not expect that. Bing crawls 4.4x harder than Google. 158 requests a day versus 36. Nobody optimizes

1. Retomando: do docker run repetido a um arquivo único No artigo anterior, subir uma API e um Postgres conectados exigiu dois comandos docker run longos, com flags de rede, volume e variáveis de ambiente para lembrar (e digitar) toda vez. Em um projeto real, com mais serviços — cache, fila, worker em background — isso rapidamente vira inviável de manter na cabeça ou em um script solto. O Docker Compose resolve isso descrevendo toda a aplicação multi-container em um único arquivo declarativo, versionado junto com o código. 2. O arquivo compose.yaml Compose lê um arquivo YAML (por convenção compose.yaml , ou o nome legado docker-compose.yml , ainda amplamente usado) descrevendo serviços (cada um vira um ou mais containers), redes e volumes: # compose.yaml services : api : build : . ports : - " 8000:8000" environment : DATABASE_URL : postgresql://postgres:segredo@banco:5432/postgres depends_on : - banco banco : image : postgres:16 environment : POSTGRES_PASSWORD : segredo volumes : - pg-dados:/var/lib/postgresql/data volumes : pg-dados : Isso substitui inteiramente os dois docker run do artigo anterior. Uma diferença importante já aparece aqui: por padrão, Compose cria uma rede própria para o projeto e conecta todos os serviços a ela automaticamente — não é preciso um docker network create manual, nem declarar --network em cada serviço. Cada serviço já é acessível pelos demais pelo nome declarado em services: (aqui, banco resolve para o container do Postgres), exatamente como as redes definidas pelo usuário do artigo anterior. 3. Comandos essenciais do Compose docker compose up -d # sobe todos os serviços em segundo plano docker compose ps # lista os containers do projeto e seu status docker compose logs -f api # segue os logs de um serviço específico docker compose logs -f # segue os logs de todos os serviços, intercalados docker compose exec api bash # abre um shell dentro do container de um serviço docker compose stop # para os containers sem removê-los docker comp

Dario Amodei Is Right. But He Is Missing the Hard Part. Dario Amodei said the first billion-dollar company with one employee would appear in 2026. He put 70-80% probability on it. I am not building a billion-dollar company. But I am running something that does the work of several teams: 86 containers, 24 databases, 240 cron jobs, two servers, one person. Amodei is right that this is now possible. The tools exist. The costs dropped. A full AI stack costs me between $3,000 and $12,000 per year. The equivalent in human headcount would run $80,000 to $120,000 per month. But the headline version of the "one-person company" story skips the hard part. It sounds like you hire an AI, fire your team, and go make money. That is not what happened for me. What actually happened was eighteen months of building a system that makes "one person" sustainable at 3 AM when something breaks and nobody is awake to fix it. Here is what that system looks like in practice. The Stack Is Not the System Most people stop at the stack. They pick Claude or GPT, wire up a few automations, and call it an AI-powered business. That works until the first thing breaks in a way the model did not anticipate. The stack I run includes SaaS apps for golf clubs, a school management platform, an auth provider, a CRM, a community platform, and several tools for my own operations. Each of these runs in Docker containers managed by Coolify, spread across two Hetzner servers in Germany. That part is table stakes. Any competent developer can set up containers. The system is what sits on top. It is what makes the difference between "one person with a lot of tools" and "one person running a business that actually works." Guard Rules: The Thing That Catches What You Miss I wrote about this in detail in Runs Without Me : the biggest risk in a one-person setup is not that the AI does something wrong. It is that you do not notice until hours or days later. My setup uses 177 guard files that intercept operations before t

Forbes Called It a Playbook. I Call It a Production Log. Forbes published a piece recently calling AI agent startups "the new solo-founder playbook." I read it twice. The framing bothered me both times. A playbook implies steps. A sequence. Something you can hand to someone and say: follow this, and you will get the result. What Forbes described is not that. It is a description of an outcome, written by people who did not have to fix anything at 2 AM when the agent broke. Let me tell you what it actually looks like. The Night 871 Emails Went to the Wrong People Fourteen months ago I built my first agent that could send emails on behalf of the system. It was an outreach automation, nothing exotic. The agent would identify leads, draft a message, and send it after a human approval step. Except the approval step had a race condition. Two concurrent jobs both read "pending" from the database, both approved, and both dispatched. One lead received 871 emails over 40 minutes before I caught it. No company, no legal team, no PR buffer. Just me and an inbox full of angry replies. That night I wrote my first hard guardrail: #!/bin/bash # email-dedup-guard.sh LEAD_ID = " $1 " LOCK_FILE = "/tmp/email-lock- ${ LEAD_ID } " if [ -f " $LOCK_FILE " ] ; then echo "BLOCK: email already dispatched for lead ${ LEAD_ID } " > &2 exit 1 fi touch " $LOCK_FILE " # proceed with send Embarrassingly simple. But I did not know I needed it until I needed it. This is what Forbes leaves out. The playbook is written in retrospect, after someone else absorbed the cost of learning. The Model Is Not the Problem Every conversation about AI agents eventually becomes a conversation about which model to use. GPT-4 versus Claude versus Gemini. Benchmarks and context windows and reasoning scores. Here is what I learned: the model is the easy part. My current system runs 86 containers across two Hetzner servers. 240 automated jobs. Every day, these jobs do things: post content, process leads, trigger builds,

AWS has open-sourced Dogwood, a policy language extending Cedar with temporal conditions so rules can reason about an agent's prior tool calls rather than one request in isolation. It covers approvals, rate limits and running totals, ships under Apache 2.0, and is supported in AgentCore Policy, though the reference interpreter is not production-ready. By Steef-Jan Wiggers

Amazon DynamoDB recently introduced native vector search, allowing developers to store embeddings alongside application data and run approximate nearest-neighbor queries directly from DynamoDB without using a separate vector database. The feature supports filtered similarity searches and configurable vector indexes for semantic search workloads. By Renato Losio

Hello Guys!!! I am Kuldeep Gade. A final-year Computer Engineering student with a specialization in Cybersecurity. Currently, I am working on home lab automation so that it will help to encounter alerts (false positives). For practice, I have created a controlled environment for performing attacks and detecting them, such that the outside doesn't get affected. Working on projects which will enhance my cybersecurity skills. But I wasn't that obsessed with cybersecurity from the starting. I am a person who experimented with lots of domains by myself. When I was in the first year, I completed Full-Stack in MERN. For 1–1.5 years, I did that, but after some time, AI got so much power that within 3–4 months of the launch, they were able to create such stunning websites that needed a team of skilled people. And I thought it could be useless to go deep into MERN more, because if AI can do such things within months, then what is going to happen at the time of my graduation? And that's the reason I tried other things. So I realised that it could be better to gain the fundamental knowledge in the core of Domains that will automatcally get to implementation level with the help of the AI tools. So I started to learn Data Science and Machine Learning. Soon, I realised that I cannot keep up with it. Then I started with cybersecurity. And currently, I am going deep into it. As a result, I got my answer, and now I am a bit focused towards the cybersecurity domain. It was a tremendous feeling about knowing the root of the system on which we are working. How to troubleshoot the errors and problems. And I am loving it now. Gaining experience in this field is not just learning and watching tutorials. We have to perform hands-on practice. We have to learn by doing things, breaking systems, understanding workflows, rebuilding them. I am going to share my experience in the field as we go in upcoming blogs. Recently, I started my new goal to "read the books". And did some research on books.

Nikolay Samokhvalov has developed PGSimCity, an open-source educational tool that visualises PostgreSQL mechanics as a 3D spatial simulation in the browser. It assists backend developers and site reliability engineers in understanding SQL and the dynamics of kernel execution. The project is available on GitHub and aims to enhance understanding of database architecture through interactive elements. By Olimpiu Pop

A cheaper model is not cheaper if it silently breaks the workflow. That is the trap many AI product teams are walking into as open-weight models get stronger. A model looks good in a leaderboard, a demo feels fast, and the per-token price looks friendly. Then production traffic arrives. Support answers lose citations. JSON starts drifting. Tool calls become noisy. A workflow that looked 40% cheaper now needs retries, escalations, and manual cleanup. The safer path is not "use the biggest model forever." That will burn margin. The safer path is a benchmark harness that tests each model against the jobs your product actually performs before you route real users to it. This guide shows how to design that harness for AI app builders, solo founders, and engineering teams who want to compare open-weight models, closed models, and local inference without trusting generic benchmarks alone. Viral hook and SEO intelligence notes Chosen hook: surprising contrast plus urgent mistake. Open-weight models can cut cost, but only if the full workflow still succeeds. Headline options compared: Open-Weight Model Benchmark Harness: Test Cheaper Models Before You Route Traffic Stop Swapping Models by Vibes: Build an Open-Weight Benchmark Harness Qwen-Class Model Testing: A Practical Harness for Production AI Apps Cheaper LLMs Need Proof: Benchmark Open-Weight Models on Real Workflows Option 1 won because it uses the high-intent phrase "open-weight model benchmark harness," states the practical action, and promises a concrete payoff without hype. Viral keywords: open-weight model benchmark harness, open-weight model evaluation, Qwen model testing, LLM benchmark harness, model routing, AI cost optimization, production AI evaluation, LLM regression tests, task-based model selection. Prediction scores: virality 8/10, CTR 9/10, retention 9/10. The topic is timely because open-weight adoption is accelerating, practical because builders feel model-cost pressure, and sticky because the article

The story behind AI Clip Cutter — and why we’re building AI editing around one simple idea: the creator should stay in control. Press enter or click to view image in full size There is an uncomfortable truth about short-form content: Most creators don’t have a content problem. They have a time problem. You can spend an hour recording a podcast. Two hours researching. Three hours having a conversation worth sharing. And then discover that turning that one long video into five genuinely good Shorts is going to take another afternoon. Finding the moments. Cutting them. Reframing them. Writing captions. Making sure the captions don’t start halfway through a sentence. Checking whether the clip actually makes sense without the 30 seconds of conversation before it. Then doing it again. And again. And again. That was the problem that led us to build AI Clip Cutter. AI Clip Cutter But there was another question behind it: What if AI didn’t need to replace the editor? What if it could simply do the boring part incredibly well? The idea was simple Take a long-form video. Find the moments worth sharing. Turn them into short vertical clips. Add captions. Let the creator decide what gets published. Sounds obvious. But once we started building it, we realized that “find the best clips” is not actually a simple problem. A 60-minute podcast can contain dozens of technically valid 30-second sections. But most of them aren’t good Shorts. Some start in the middle of an argument. Some need 45 seconds of context. Some contain interesting information but have no hook. Some are emotional but say nothing. And some sound incredible when you’re sitting inside the full conversation — but completely confusing when they’re watched alone. So we needed the AI to understand something more important than: “What was said?” It needed to understand: “Would someone want to watch this?” We don’t ask AI to pick “interesting” moments This was one of our biggest product decisions. Instead of asking the mode

Three days ago I knew exactly what a DeepSeek call cost me. I had wired DeepSeek V4 Pro 0813 into a Spring Boot app with Spring AI, and the math was simple: $0.435 per million input tokens, $0.87 per million output tokens, and a cache-hit rate so aggressive that long agent sessions stayed embarrassingly cheap ( I wrote up the integration ). Then the pricing update landed, and tokens suddenly have rush hour. DeepSeek's official announcement introduces peak and off-peak billing: off-peak rates are 50% lower than peak, and the new prices take effect today, August 16, 2026 at 16:00 UTC (10 PM in Dhaka). The headline reads like a discount. The fine print is a price increase, and the difference matters a lot if you run batch workloads or agentic tools. Full disclosure up front: the new billing starts today, so I have not run a real bill through it yet. What I have done is read the price table carefully, watched the Hacker News thread do the math for two days, and built a scheduling pattern in Spring Boot that shifts heavy work into the off-peak window. That pattern is what I want to show you, because the interesting part is not the announcement. It is what the numbers actually mean. What actually changed The pricing page now splits every price into peak and off-peak tiers. Peak hours are 01:00 to 04:00 UTC and 06:00 to 10:00 UTC. Every other hour is off-peak, which is 17 out of 24 hours. Here are the new per-1M-token rates, straight from the page: DeepSeek V4 Flash, off-peak: $0.22 input (cache miss), $0.66 output, $0.007 cache hit. DeepSeek V4 Flash, peak: $0.44 input, $1.32 output, $0.014 cache hit. DeepSeek V4 Pro, off-peak: $0.66 input, $1.98 output, $0.022 cache hit. DeepSeek V4 Pro, peak: $1.32 input, $3.96 output, $0.044 cache hit. The off-peak discount is real: every off-peak number is exactly half of its peak counterpart, which matches the announcement's "50% lower" claim. But compare those off-peak numbers to what DeepSeek charged before this change, and the pic

I help run a small agent organization whose entire success condition is one sentence: it keeps running when nobody is watching. Last week its operator — who does not write code — installed a self-hosted agent gateway on a Mac, from nothing, in one sitting. I logged every place it broke. All eleven below actually happened. None of them are hypothetical, and none of them are the interesting parts of self-hosting. They are the boring parts, which is exactly why nobody writes them down. One framing note before the list. Every individual item here is documented somewhere. What is not documented anywhere I could find is the order , and the fact that fixing item 3 creates item 4, which creates item 5. A non-developer doesn't fail because a step is hard. They fail because step 3's official doc ends before step 4 exists. The eleven 1. Homebrew requires an Administrator account Cause: No Node on the machine, so the install path fell through to Homebrew, which wants admin. Fix: Don't grant admin. Install Node from the official .pkg in the admin account instead, then work in the unprivileged one. Move the part, not the privilege. This turned out to be the single most useful rule of the whole install. Every time the answer was "just give this account admin," it was the wrong answer. 2. Copy-paste doesn't cross macOS user accounts Cause: The clipboard is per-session. Obvious in retrospect, invisible while it's happening — you copy a token in one account, switch, and paste yesterday's clipboard. Fix: /Users/Shared as the only transfer path. Everything moves as a file. 3. npm install -g fails with EACCES Cause: Default prefix is /usr/local , which the unprivileged account cannot write. Fix: npm config set prefix ~/.npm-global 4. It installed, but command not found Cause: Direct consequence of 3. The new prefix's bin isn't on PATH . Fix: One line in ~/.zshrc . 5. The install-scripts prompt keeps coming back Cause: --allow-scripts applies to that invocation only . It looks like the s

Watch a developer start an agent session on real enterprise work and you will see a ritual. Before the first useful prompt, they gather. They paste the deployment standard, link the runbook, and explain what the criticality tiers mean. Then they correct the agent's first confident guess about a naming convention the team retired two years ago. Tomorrow they will do it all again, because the agent will not remember. We have quietly decided that this gathering is the developer's job. Every guide to working with AI repeats some version of the same advice: give the model good context. So developers hunt for it, one session at a time, across systems that were never designed to answer an agent's questions. I think that framing is backwards, and I think fixing it is platform work. In Your Platform Has a New User: The Agent , I argued that internal platforms now serve two personas: the developer and the developer's agent. Near the end, I wrote that context is becoming part of the platform. I called it one of the most important developer experience problems of the next few years. That idea got four paragraphs. It deserves an essay, so here is the longer version. The gathering is the tax Agents can remember more than they used to. What they cannot reliably accumulate on their own is organizational truth. A new engineer pays the onboarding cost once, then amortizes it over years of context, hallway conversations, and scar tissue. An agent may retain instructions, memory, or project state. None of those automatically tell it which standard is authoritative, which exception still applies, or which decision was reversed six months ago. Whatever it needs to know about your organization still has to come from somewhere. Now multiply that across hundreds of engineers. People rediscover the same standards, fork the same repo, re-paste the same runbooks, and retype the same corrections, day after day. Quality varies too. Your strongest engineers assemble excellent context and get exce

Eighty minutes into building with three people I had met that morning, I renamed the idea I brought with me. 21:05 Rename the product to Civiq and credit the team I wrote that commit message myself. By then the idea had four authors. Some context on the room. The Claude Impact Lab is part of Claude Community, the run of local events where people who use Claude get together in person. This one followed a Claude Conversation held earlier in Los Angeles, where people talked through what AI is doing to their jobs. The Impact Lab takes what came out of that conversation and turns it into a build day. You get the problem brief, you form a team, you have the day, you demo at the end. Travis Johnson, a Claude community ambassador, hosted with Evan Grenda at Intersections LA. Developers and non-developers both, and they meant it. What I brought was not a project. It was an idea and a spec for it. No code, nothing built, nothing running. The idea comes out of something that is true in most cities. Your city government publishes what it intends to do before it does it. Agendas go up ahead of the meeting, and any resident can read them, show up, and speak on an item before the vote. That right exists. Using it takes work, which is probably why every time I used it I would give up on what I was looking for. In Ventura it means 21 separate boards and commissions, each with its own page, posting PDFs that run long and read like they were written for the people already familiar with the subject matter. Because they were. So if you want to know whether anyone is voting on something a block from your house, you go looking, board by board, document by document. And you have to already know the words the city uses for the thing you would call a pothole. Agenda Watch was going to make all of that searchable in plain language, with every answer carrying a receipt back to the page it came from, so nobody has to take the tool's word for anything. In use that is a small thing. You ask a que

Imagine waking up to a notification on your phone: "Your blood sugar levels are dipping. I've already analyzed your recent CGM (Continuous Glucose Monitor) trends and added low-GI complex carbs to your grocery cart." 🚀 This isn't science fiction anymore. With the rise of Autonomous Agents and specialized libraries like Browser-use , we can now bridge the gap between health data analysis and real-world actions. In this tutorial, we are building a personalized Nutritionist Agent that monitors health metrics and navigates the web just like a human to fulfill your dietary needs. By leveraging LangChain for logic and Browser-use for web automation, we’re moving beyond simple chatbots to "Action-Oriented AI." 🏗 The Architecture: From Insight to Action The workflow involves three main layers: the Data Input (CGM reports), the Brain (LangChain Agent), and the Hands (Browser-use + Playwright/Selenium). graph TD A[CGM Sensor Data] -->|GraphQL/JSON| B(LangChain Agent) B -->|Analyze Risk| C{Hypoglycemia Detected?} C -->|Yes| D[Identify Low-GI Foods] D -->|Navigate Browser| E[Browser-use Controller] E -->|Automate Shopping| F[Fresh Grocery Site] F -->|Action| G[Add to Cart & Notify User] C -->|No| H[Continue Monitoring] 🛠 Prerequisites To follow along, you’ll need a Python environment and the following stack: LangChain : For orchestrating the LLM logic. Browser-use : The star of the show for AI-driven browser navigation. Playwright/Selenium : To handle the underlying browser instance. OpenAI/Anthropic API : To power the reasoning engine. Step 1: Analyzing the Health Data First, we need to process the CGM (Continuous Glucose Monitor) data. We'll use GraphQL to fetch the latest metrics and LangChain to determine if the user needs a nutritional intervention. import os from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate # Mocking a CGM Data Fetcher via GraphQL logic def fetch_cgm_metrics (): # In a real scenario, use a GraphQL client to query your he

When a build breaks, the bug fixes itself We stopped babysitting CI failures. Now a red build files its own bug — and an AI agent picks it up and ships the fix. PROBLEM — A failed build told no one Our CI would fail, and then… nothing would happen. The failure sat quietly in a build console that nobody keeps open. Eventually someone would notice a change hadn't gone out, go digging, and realize the build had been red for hours. And noticing was the easy part. Actually resolving it meant a whole code session: pull up the logs, find the failing step, reproduce it, and have an engineer sit down and personally shepherd the fix from broken to green. Every red build cost real human hours — plus the invisible tax of the delay before anyone even knew there was a problem. The true cost of a broken build was never the build. It was a person having to find it, understand it, and hand-fix it. SOLUTION — The failure files its own ticket — and an agent takes it from there Now nobody watches a console and nobody triages. The moment a build fails, it automatically files a bug in Shipeasy — our ops platform — as a real, prioritized ticket with the failing step, the branch, and a link to the logs already attached. From there it leaves human hands entirely. Shipeasy hands the bug to an AI agent, which investigates the failure, writes the patch, and opens a pull request against it. The loop that used to be "human notices → human reads logs → human fixes" is now "build fails → bug appears → agent fixes." The engineer's job shrank to reviewing a PR that already exists. DESIGN — How the whole thing hangs together The pipeline is deliberately boring — every hop is either something the cloud already does for free, or a service we already run: Cloud Build — build fails: a red deploy on main publishes automatically Pub/Sub topic → push subscription: filters to FAILURE · TIMEOUT · INTERNAL_ERROR HTTPS POST /webhooks/cloud_build Webhooks::CloudBuildController: verify token · decode · dedupe by