--- title: "AI Changed Programming. But How?" description: "AI changed more than how we write code. Packages, cloud agents, durable context, and bounded autonomy shift programming toward shaping reliable environments." author: "adam" author_name: "Adam Gospodarczyk" tags: ["agents","automation","workflows","programming"] published_at: "2026-08-27T19:50:55.968Z" canonical: "https://mega.dev/ai-changed-programming" --- There are things we’ve been doing for years as programmers. But let’s pretend most of it does not matter anymore, and see what lies in front of us today. ## Ownership We take full responsibility for our work. With that in mind, handing ownership over to language models doesn’t seem reasonable. Confabulation ([Why Language Models Hallucinate](https://arxiv.org/pdf/2509.04664)) and prompt injection are two good reasons why. Both pose serious security risks and remain open problems. After all, who wants an agent with access to a production database that can [drop it along with all the backups](https://x.com/lifeofjer/status/2048103471019434248) in seconds? At the same time, there’s no denying that AI agents can bring a lot of value. They can [do in days what would normally take us years](https://openai.com/index/asana/), and [this isn’t the only case](https://bun.com/blog/bun-in-rust). But does giving agents more responsibility and access while reducing oversight mean we also need to give them ownership? Not necessarily. But the question is: how? ## Primitives Let’s say we’re building a product and use an issue tracking system to manage ideas, feature requests, and bug reports. These issues are often created manually based on input from internal meetings, the support team, social media, analytics tools, or production server logs. Meetings, support and social messages, and analytics logs flow into an issue tracker before a human owner takes responsibility. Most issues can be handled through the normal workflow, but some require immediate action. In those cases, we often set up a notification that triggers a “red alert” even at 3 a.m. If we’re unlucky, no one responds until morning, leaving some users unhappy. Normal issues stay in the shared queue, while an urgent label triggers a red alert and immediate notification. Coding agents can access external services through the CLI and MCP. But no one wants to keep asking them to scan support tickets, emails, or chat messages just to add a few entries to the issue tracker. Automating the process makes much more sense. The problem is that every run takes time and costs money. Add a few automations like this, and your token bill can quickly skyrocket, or you may burn through your subscription limits in a single day. Tickets, email, chat, and repository code flow through an MCP agent into an issue enriched with evidence and code context. But nobody said that the agent has to perform the entire work each time. Instead it could create a dynamic package with the logic that will be deterministically invoked, passing to the model the exact data it needs. Two issue-enrichment workflows: repeated agent tool use for every job versus building and reusing one tested package. The **Package** is the first primitive here. Its source is a git repo in [Cloudflare Artifacts](https://www.cloudflare.com/products/artifacts/), and the built bundle sits in [Workers KV](https://www.cloudflare.com/developer-platform/products/workers-kv/). A one-off script usually isn't enough because it needs to remember things, so every package gets a [Durable Object](https://www.cloudflare.com/products/durable-objects/) with its own SQLite database. Nothing gets deployed. A [Worker](https://www.cloudflare.com/products/workers/) loads the bundle and runs it in a sandbox with no access to anything else. The difference is visible after the first run. Compared with a typical agent using MCP or CLI tools, an agent that uses primitives like **Packages** makes subsequent runs more reliable, faster, and cheaper. Below, two agents aim to solve an issue that requires access to a list of payments. The first agent retrieves the payments manually each time, while the second writes a script to filter them deterministically. Animated comparison of two agents handling payment failures and export timeouts: one repeats every tool call, while the other builds and reuses a tested package. **Conclusion:** Agent capabilities are changing not only how we create software, but also what software can do. In many cases, this requires a shift **from building features to shaping environments** where agents can manage their own capabilities. ## Autonomy Making agents faster and more reliable improves efficiency, but only to a point, as human involvement soon limits further progress. One approach is to restructure the system so that humans work with "manager" agents that coordinate subagents or workers. Alternatively, humans can be removed from the process entirely—or almost entirely. A schedule, event, or human message starts a manager agent, which delegates to work and review agents before a final human and test gate. The questions are how to achieve this, how to make it reliable, and how to keep it secure. First, the agent almost always needs to run in the cloud—whether it’s Cursor Cloud Agent, Codex Cloud, Grok Bot, or a custom Pi setup hosted on your VPS. That keeps it available to interfaces such as T3 Code UI and, more importantly, running while your computer is offline. Events and schedules trigger an always-on cloud agent, which completes the task and opens a pull request or waits for checks before auto-merge. The easiest way to get started with remote agents is to use Cursor or Codex. Running them on your own VPS requires more setup and comes with additional costs, including the VPS itself and tools like [Tailscale](https://tailscale.com/). You may also want to use [Pi](https://pi.dev/), [Herdr](https://herdr.dev/), or [Moshi](https://getmoshi.app/). Always-on agents aren’t enough if they still require constant supervision. To improve their autonomy, we need to give them well-organized, accessible context, including: - **General context:** short files that include the project vision and a map of the most important knowledge sources: documentation, specifications, and so on. - **Specifications:** a self-managed list of planned, active, and completed features to track progress, coordinate multiple agents, and understand historical changes beyond code. - **Environment:** MCP and CLI access to GitHub, issue trackers, monitoring, communication tools, server logs, the browser, and even the entire desktop. - **Communication:** Agents need to be able to reach us easily when necessary, while external systems must also be able to reach them. Below is a visualization of an agent that automatically picks up support requests, gathers context, manages its own work, connects to the browser and server logs, and collects evidence. It then resolves the issue and opens a pull request for a human or other agents to review. Animated incident workflow where an agent receives a payment bug, gathers redacted logs and project context, reproduces the failure, applies a patch, verifies the fix, and opens a pull request. When working with background agents, keep in mind that they **can make mistakes** and **can be tricked** into taking unwanted actions. At a minimum: - Do not give them unsupervised access to production servers. - Minimize their exposure to prompts from untrusted sources, such as support tickets. - Restrict their access to nonessential tools, especially those that could lead to data leaks or similar risks. - Provide only anonymized data while preserving enough context for them to solve the issue. - Limit the number of requests they can receive to prevent spam and misuse. A security boundary diagram: untrusted tickets and logs are filtered, an agent works without production access or raw data, and only a reviewed pull request can reach production. ## Workflows Now that we can generate code easily, it’s worth using this capability not only for our day-to-day work but also to build tools that improve our workflows and agents. For example: - [Pi](https://pi.dev/) extensions can personalize agents for each project or workspace. - Pi extensions can manage [herdr](https://herdr.dev/) workspaces and settings. - Agents can spawn other agents—even those running in different harnesses, allowing you to combine tools like Claude Code, Codex, and Grok. - Agents can build a shared library of reusable scripts for multimodal processing, artifact management, uploads, and general knowledge about you. - Background agents can review your [Superwhisper](https://superwhisper.com/) history or threads from your coding harness, extract reusable skills, review code, and suggest improvements. - Agents can help keep documentation up to date, especially when it’s Markdown-based and built with tools like [Astro](https://astro.build/) or [Next.js](https://nextjs.org/). - Agents can monitor communication channels, help shape issues for upcoming sprints, prepare you for meetings, and assist with work reporting. - With remote agents and self-organizing specs, you can work with agents through mobile interfaces such as Moshi, T3 Code, or Codex. In other words, we can now build a system that works for us. Most of its modules can be set up with zero-shot prompts to the agent. The key is not to overengineer it and to give the main agent enough control, so we don’t spend more time managing the system than benefiting from it. Below is a high-level overview of such a system, with the right context, tools, integrations, autonomy, and a well-designed interface that keeps us in the loop. Animated workspace dashboard showing an agent turning a feature brief into a maintained specification, verified environment, reconciled model perspectives, reusable capability, and returned evidence. In practice, it’s a good idea to avoid becoming attached to specific tools and keep the setup tool-agnostic. Whenever possible, it’s also better to use tools built by others than to create everything from scratch, even if "code is free". The same goes for frameworks, libraries, CLIs, MCPs, and so on. Recommended tooling: - Harness: Pi, Omp, [DeepSeek AI](https://github.com/deepseek-ai/deepseek-harness), Cursor, Codex - Terminal: [Cmux](https://cmux.com/) together with [Herdr](https://herdr.dev/) - UI: [T3 Code](https://t3.codes/), [Superset](https://superset.sh/) - Mobile: [Moshi](https://getmoshi.app) (together with [Tailscale](https://tailscale.com)) - CLI: [agent-browser](https://github.com/vercel-labs/agent-browser), [chrome-devtools-mcp](https://github.com/ChromeDevTools/chrome-devtools-mcp) - VPS: [DigitalOcean](https://digitalocean.com) or [Hetzner](https://www.hetzner.com)