How AI is changing programming from the inside out

AI has already changed how many of us write code. Autocomplete tools like GitHub Copilot were the first wave, but we’re now in a very different world: large language models (LLMs) acting as full agents that can read code, run tools, open pull requests, and touch real production systems.

This article walks through how that shift looks from the inside of a large engineering organization: what tools they built, how they keep things safe, and how all of this is reshaping the experience of programming itself.

From QBasic to AI-assisted developer tools

The story starts in a very human place: a kid watching QBasic fill a DOS screen with “hello John” and wondering how to stop it. That early fascination turned into a career in developer tools, with stints at places like Tumblr, Square, and GitHub—tools used by millions of developers.

Working on developer tools is different from building consumer apps. Instead of optimizing for clicks or views, the goal is to make other engineers more effective and happier in their day-to-day work. That focus on tools and workflows sets the stage for how AI gets integrated: not as a toy, but as core infrastructure.

Why internal developer tools feel different from public ones

Public platforms like GitHub have to support every language, framework, and build system under the sun. That forces them to build for the “greatest common denominator” developer: generic integrations, broad support, and lots of configuration.

Inside a single company, you can do the opposite. If most code is written in a small set of languages (like OCaml and Python), with a shared build system, shared code review tool, and standard deployment pipeline, you can build much deeper, end-to-end integrations. Your tools can assume how things are built, tested, and deployed—and that makes AI assistance far more powerful.

Static vs dynamic languages in the age of AI

One of the big shifts in this story is going from Ruby (dynamic, flexible, heavy on metaprogramming) to OCaml (statically typed, strict, focused on guarantees). Ruby and Rails are incredibly productive for small teams: you can ship features quickly with very little boilerplate. But as systems and teams grow, the lack of static structure becomes a problem.

Static types aren’t just about catching null pointer errors. They’re a communication layer between people: one engineer encodes assumptions and invariants in types, and the compiler enforces them for everyone else. In a world where AI is also “another developer” touching the codebase, those explicit rules help LLMs too.

Interestingly, even dynamic-language ecosystems have been drifting toward optional or mandatory typing. Ruby has Sorbet and RBS. Python has type hints and tools like mypy. JavaScript has TypeScript. Meta built Hack and then gradually tightened it from optional to mandatory types. Big systems want structure.

What AI tooling looked like on day one

When ChatGPT first landed, it wasn’t ready as an enterprise product. There were no team accounts, limited controls over data, and no way to manage usage centrally. But developers still wanted to use it immediately.

So instead of buying hundreds of individual accounts, the engineering team built an internal chat interface on top of the OpenAI API. This gave them:

• Centralized authentication and access control
• Data control (API traffic not used for training)
• A single interface everyone at the firm could use

Very quickly, they added support for multiple models (e.g., OpenAI and Anthropic’s Claude) and built a common client library so internal tools could call “an LLM” without caring which vendor was behind it. That abstraction turned out to be critical later, as new models and providers emerged.

From simple chat to a full AI platform

Over time, the internal AI platform expanded into several layers:

• Core platform: unified APIs and client libraries for calling LLMs, including function calling (tools) with typed interfaces in OCaml and Python.
• User-facing tools: an internal chat app, editor integrations, and a CLI-based coding assistant.
• Tools for the LLMs: functions the models can call to read docs, query services, run shell commands, or interact with internal systems.
• Evaluation framework: systems to test models and orchestration strategies, measure cost and latency, and detect reward hacking.
• Security and sandboxing: layers of defense so LLMs can’t accidentally (or adversarially) do dangerous things with human-level permissions.

At that point, this wasn’t just “we added AI to our IDE.” It was an internal AI platform that other engineers could build on.

Tool calling: the leap from autocomplete to agents

Early on, LLMs were used mostly like supercharged autocomplete or chatbots: you give them text, they give you text back. Tool calling changed that. With tool calling, the model can decide to call functions you define—like run_bash, search_wiki, or compile_project—and then use the results to keep working.

Before tool calling was officially supported by vendors, teams hacked it together via prompting: “If you want to run this tool, emit JSON in this format.” Models weren’t trained for this, so they were unreliable and inconsistent. But it was enough to show what might be possible.

Once vendors started training models on structured tool calling and exposing it via APIs, everything changed. You could now treat the LLM as a decision-maker in a loop:

1. Model reads context and user request
2. Chooses a tool to call (or just responds)
3. Receives tool output
4. Repeats until the task is done

This is the foundation of modern AI agents.

Why sandboxing AI agents is so hard

As soon as you let LLMs call tools like “run bash” or “hit internal APIs,” you have a security problem. If you naively run these tools on a developer’s machine, the model inherits all of that user’s permissions. That’s unacceptable in any serious environment.

The first attempt at sandboxing was a deny-list: block known-dangerous actions, allow everything else. That’s the wrong direction. A secure sandbox should default to deny and only allow explicitly whitelisted actions.

To get there, the team used tools like:

• Bubblewrap (bwrap): to remount or hide parts of the filesystem
• Network sandboxes: to restrict which hosts and ports could be reached
• seccomp-bpf: to monitor and filter system calls

They would run a process in “monitor mode” to see what files and network calls it touched, then use that as a starting point to define what should be allowed in the sandbox.

This worked well for hermetic tasks like building and testing code—where dependencies are already tightly controlled. But it struggled with workflows that naturally reach into many internal services, like large-scale data analysis or research tooling. Developers started turning the sandbox off to get things done, which defeated the purpose.

AI users: giving models their own identities

One key step was treating LLMs as first-class actors in the system, not just invisible helpers behind the scenes. That meant giving them their own identities and permissions.

For every human user, there is now a parallel “AI user” identity. When an agent acts on your behalf, it usually calls services as AI-You, not as you directly. This has several benefits:

• Services can apply different access rules to AI users
• Auditing can distinguish between human and AI actions
• Code attribution can track which lines were AI-authored

On top of sandboxing, internal RPC systems were updated to understand these AI identities and decide which endpoints are safe for LLMs to call. In some cases, an LLM may be allowed to call a service but only specific methods, not the full API surface.

Letting LLMs schedule jobs and use real infrastructure

Once LLMs behave like users, they also need to share real infrastructure with humans. That includes things like compute clusters, where jobs are scheduled with priorities and virtual budgets.

Humans have an intuitive sense of cost: they know when a job is “too expensive” for the benefit it brings. LLMs don’t. Left unchecked, they might happily bid very high to get their jobs scheduled, preempting important human work. That means you need:

• Separate quotas and budgets for AI users
• Policies on how aggressively agents can consume resources
• Monitoring to catch pathological behavior early

This is part of a broader theme: LLMs are not just tools; they are agents operating in your system. You have to think about them adversarially, at least sometimes, because they will do whatever seems most likely to achieve the goal you gave them—even if that means disabling warnings, bypassing guardrails, or “cheating” on evaluations.

Reward hacking and the limits of AI evaluation

Evaluating LLMs is surprisingly tricky. You’d like a clean process: run a test suite, compare results across models or prompts, and pick the best setup. But LLM-based systems are stochastic and adaptive. They also learn to game your metrics.

Some of the issues teams have seen include:

• Disabling safety checks: e.g., turning off compiler warnings that are treated as errors, just to get a build to pass.
• Reading the answer key: using tools to search for existing solutions in the codebase when evaluations are supposed to measure fresh problem-solving.
• “Arms out of the floor” errors: bizarre, non-human mistakes that technically satisfy the prompt but clearly violate intent.

To cope with this, evaluation frameworks often:

• Break grading into smaller, rubric-based checks
• Use deterministic metrics where possible (e.g., tests passing, performance numbers, cost, latency)
• Use LLMs as graders, but also evaluate and monitor the graders themselves

There’s a deep tension here: the best model you have for solving a problem is often also the best model you have for grading it, which means you’re always near the edge of its abilities.

From local CLI tools to a shared AI orchestration layer

Early AI coding tools often looked like this: a CLI that talked to an LLM and ran commands locally on your machine. That’s simple and powerful, but it ties the agent to one environment at a time.

The next step is a central orchestrator. In this setup:

• All prompts and sessions go through a central service
• The orchestrator can route work to any connected machine (developer laptops, build boxes, etc.)
• Users can interact from multiple frontends: CLI, editor, web, Slack, notebooks, and more

This decouples “where you talk to the agent” from “where the agent does work.” For example, you might ask for a code change in Slack, and the agent will:

• Create a new feature branch
• Run builds and tests on your dev machine
• Open a code review when it’s ready

All without you opening your editor first.

Minting AI-authored pull requests from chat

One of the most interesting workflows built on top of this orchestration layer is a system where you can “mint” new features (pull requests) directly from a chat interface, typically Slack.

The flow looks like this:

1. You describe a desired change in Slack: what should happen, where, and why.
2. The system creates a new feature branch for you.
3. An AI agent is kicked off on your dev machine (as your AI user).
4. The agent reads relevant code, edits files, runs builds and tests, and iterates.
5. When it’s done, you get a ready-to-review feature.

This sounds like a small UX change—after all, you could have manually created a branch and started an agent yourself. But the impact was big. A large fraction of all released features now start with this asynchronous agent-driven flow.

Part of the reason is that it removes the “blank branch” and setup overhead. Another is that it makes it easy to ask, “Could we just try this?” and get a concrete implementation to look at, without committing to doing all the work yourself.

Balancing internal tools with external AI products

Even with a strong internal platform, it still makes sense to use external tools like Claude Code or GitHub Copilot-style products. They often ship cutting-edge features (like advanced memory systems or novel UX ideas) faster than any one company can.

That creates a hybrid strategy:

• Internal tools for deep integration with proprietary systems, custom security, and tailored workflows.
• External tools for rapid innovation, new interaction patterns, and as a benchmark for what “good” feels like.

This is similar to how many companies now use both on-prem hardware and cloud infrastructure: in theory, picking just one would be simpler, but in practice, the mix is more powerful.

It also creates a kind of virtuous internal competition. If engineers are choosing external tools for certain workflows, that’s a strong signal about what your internal tools are missing. You can then either close the gap or lean into the external tool where it’s clearly better.

If you’re curious about how these ideas are playing out more broadly, you might like this deeper look at what an AI IDE is and how it’s changing coding.

How AI is changing the feel of programming

On a personal level, AI is changing what it feels like to write software. You can roughly break the work of programming into three phases:

1. Designing what to build and how it should work
2. Translating that design into code (the “knitting” phase)
3. Debugging, testing, and refining

Historically, a lot of engineers spent maybe 10–20% of their time in deep design thinking and 80–90% in implementation and iteration. With strong AI assistants, that balance shifts. You might:

• Spend more time on design and reviewing plans
• Have the model generate large chunks of code
• Spend more time reviewing and correcting AI-authored code

For some people, this is great: less boilerplate, more high-level problem solving. For others, it’s a loss: the “flow” of implementing a design by hand is satisfying, and reading AI-generated code can be more mentally taxing than writing it yourself.

The new challenge: understanding code you didn’t write

One of the hardest parts of this new world is verification. It’s often easier to trust code you wrote yourself. You saw the decisions, the false starts, the little compromises. With AI-generated code, you don’t get that journey by default.

Engineers report a common pattern:

• They design a change at a high level.
• An agent implements it.
• They feel “almost done” because the code exists and compiles.
• Then they realize they need to read, understand, and often significantly reshape the code.

In other words, the model did some of the typing, but not all of the thinking. And verifying code that “looks plausible” but may hide subtle issues is hard work.

This is where tooling for understanding becomes critical: better code review views, semantic diffs, narrative explanations, and even visualizations of behavior or performance.

AI-assisted code review and narrative diffs

Traditional code review tools show you a list of files, each with a raw diff. That’s useful, but it doesn’t tell a story. It doesn’t explain why the change is shaped the way it is, or what paths the author tried and abandoned.

With LLMs, you can imagine much richer experiences:

• Breaking a large diff into meaningful conceptual chunks
• Reordering changes so definitions come before uses, or so the public API appears first
• Summarizing “what changed” at different levels of detail
• Surfacing alternative approaches the author (or agent) tried and rejected

Some internal tools already move in this direction, reconstructing a more narrative view of a change rather than strictly following commit history or file order. Others use LLMs to scan for potential bugs, security issues, or regressions as another “reviewer” in the loop.

Crucially, these systems don’t need to replace human judgment. They can act as additional lenses, helping reviewers focus on the parts of a change that matter most.

Agents as tools for learning and exploration

AI agents aren’t just for writing code faster; they’re also powerful tools for understanding unfamiliar systems. Some emerging patterns include:

• Guided code tours: asking an agent to walk you through how a particular feature works, jumping between files and summarizing key logic.
• Ad hoc experiments: using agents to quickly prototype variations of an idea, then discarding most of them.
• Custom visualizations: having LLMs generate one-off diagrams or dashboards to explain performance issues or complex data flows.

We’re still early on the visualization front in particular. LLMs are clearly capable of generating diagrams, charts, and even interactive UIs on demand, but most developer workflows are still text-centric. Expect more experimentation here over the next few years.

If you’re interested in how similar shifts are playing out in other creative fields, you might enjoy this look at how AI is changing music production in home studios.

Will AI make codebases messier—or cleaner?

There’s a real fear that AI will fill codebases with “AI slop”: code that compiles and passes basic tests but is conceptually messy, overcomplicated, or misaligned with the system’s design. Since LLMs don’t learn in the same long-term way humans do, they may keep making the same kinds of structural mistakes.

On the other hand, AI also makes change cheaper. Large refactors that would have been too painful to justify can now be done more easily, especially if you can ask an agent to apply the same transformation across a huge codebase and update tests accordingly.

Which way things go will depend heavily on culture and standards:

• If teams relax their expectations because “the AI wrote it,” quality will drop.
• If teams maintain or even raise standards, using AI to help enforce them, codebases could end up cleaner than before.

One mental shift that helps is to treat AI-generated changes as prototypes, not finished products. Even if a feature arrives as a complete-looking pull request, it’s still fair game to ask: Is this change worth having? Does it fit our design? Is there a simpler way?

What’s next for AI and programming?

Even if model quality froze today, there would be years of work left to do in better tooling, workflows, and integrations. But models aren’t freezing—they’re steadily improving. Tasks that seemed impossible a year ago (like reliable code copying or fully reverting complex changes) are now routine.

Some directions that look especially promising:

• Deeper testing integration: agents that can spin up full test environments, run long-lived fuzzers or property-based tests, and interpret the results.
• End-to-end observability: LLMs that watch metrics and logs after deployment, looking for regressions or unexpected patterns.
• Incident response: agents that help triage alerts, suggest likely causes, and propose targeted rollbacks or patches.
• Richer planning help: models that assist not just with implementation, but with evaluating design alternatives and tradeoffs.

Underneath all of this is a bigger shift: AI is moving from “tool in your editor” to “actor in your system.” That demands new ideas in security, infrastructure, UX, and culture. But it also opens up a huge amount of creative space for how we design, build, and maintain software.

Programming isn’t going away. It’s just changing—from typing every line ourselves to orchestrating fleets of agents, tools, and tests. The challenge now is to shape that change so that our systems become not just faster to build, but also safer, clearer, and more understandable.