The way developers use AI is rapidly changing, moving beyond simple integrations within code editors towards more complex, “agentic” workflows. This shift suggests that the current model of AI assistance directly in the editor might soon become obsolete.

The Traditional Editor-Based Approach

Historically, developer adoption of AI, exemplified by tools integrated into editors like VS Code, focused on providing help for small, specific tasks. Developers would highlight sections of code and ask the AI to write a function, explain an implementation, or debug a piece of code. This approach involved tactically employing AI on a micro-level to solve immediate problems.

“In this model of usage, you as the developer are using your editor. And you’re highlighting sections of a file. For instance, and saying, hey, AI, write some code here. Or, hey AI, tell me what you think of this implementation. Or, hey AI, dig into this function call and tell me how it works.”

The Rise of Agentic Workflows

With the advent of more powerful models and tools like GitHub Copilot, Google’s Jules, and Claude Code used via command line or in automated workflows (like GitHub Actions), the interaction with AI is moving outside the editor. This is the “agentic move,” where AI is applied to much larger problems. Instead of writing a single function, AI agents can be tasked with analyzing an entire codebase, updating multiple system components (backend, frontend, APIs, databases), or removing all references to a third-party service.

This agentic approach allows developers to provide architectural direction and guidance while the AI handles the heavy lifting of implementing large, complex features. The scale of tasks manageable by AI has grown significantly.

“It’s where we’re moving away from very specifically applying AI to solve small problems, implement a function, implement a data structure, sketch out an API, debug this function to much larger problems, which are, hey, analyze this code base, update the back end, the front end, the GraphQL API between them, and my analytics system, for instance.”

Increased Pace and Complexity

The agentic workflow, often involving multiple AI instances working on different parts of a project simultaneously, is described as “extremely high-paced.” A developer might manage several AI sessions, each tackling a medium to large feature, potentially resulting in thousands of lines of code changes per day. This contrasts sharply with the slower pace of waiting for AI to complete small tasks within an editor.

“However, when you have two or three Claude sessions running implementing medium to large size features, and you are actively monitoring the more complex one, you’re moving very, very fast. You’re getting to the point where you can manage three, four, 5,000 lines of code a day that are non-trivial and bring meaningful features, not AI slop.”

Challenges and the Human Role

While powerful, agentic AI isn’t perfect. Challenges exist, such as the AI missing crucial context (like the extensibility of a custom parser), giving up when tasks become difficult, or implementing easier solutions that compromise the user experience.

This is where the human role evolves. Instead of being constantly in the editor, the developer acts more as an architect and supervisor. They monitor the AI’s progress, interrupt and redirect it when it goes off track, and review the completed work, often through pull requests. The human’s greatest impact shifts to reviewing larger code changes and prescribing new directions.

“At this point, rather than a human sitting in the editor and reviewing, it seems like the human wants to be sitting in a diff view reviewing pull requests one after another and prescribing changes and new directions. And that’s where a human right now, this month, today, seems like they can have the greatest impact.”

The Future of AI in Development

The rapid move towards these larger-scale, agentic workflows raises questions about the longevity and value of companies heavily invested in building AI directly into editors. If the cutting edge of developer productivity involves managing AI agents outside the editor, how long will the editor-centric model remain relevant? The landscape is dynamic, and the focus appears to be shifting towards AI handling broader tasks with human oversight and review.

lloyd

Building software platforms has long centered around the human user – their preferences, workflows, and comfort with existing tools and languages. However, the rise of artificial intelligence as the primary user of these platforms is fundamentally altering this perspective. It’s prompting a re-evaluation of product requirements and, consequently, changing how we build software and for whom we build it. The domain of software testing platforms offers a compelling, concrete case study of this dynamic shift.

Traditional Software Testing: Built for Humans

Consider traditional software testing tools, many of which were designed with human engineers in mind. Platforms like Selenium or Appium support a multitude of programming languages, allowing testers to work within familiar environments. They often include features like recording tools to capture human interactions and debuggers to help step through tests and inspect application structure (like the DOM). The typical human workflow involves creating a test, manually refining it, fixing issues like suboptimal selectors, and investing significant effort to make tests robust against application changes because creating and maintaining them is time-consuming and costly.

“For an AI user, they are comfortable with everything.”

AI as a User: A Different Set of Requirements

When the user is an AI, many of these human-centric features become less relevant or even counterproductive. An AI doesn’t have a preferred programming language; it can adapt to various formats. The fundamental goal of the development language or environment shifts from prioritizing expressiveness, ergonomics, and human generation to creating something distilled and robust that can be fairly easily understood by humans (for auditing) and is easy to execute, even if it wasn’t generated by a human. This change in focus indirectly leads to approaches like declarative languages or domain-specific languages (DSLs), which facilitate the reuse of test components through declarative libraries and help the AI efficiently adapt tests when the application’s underlying structure changes.

“Having the AI drive the recording tool would be an unnecessary error prone step. So test generation tools become totally obsolete.”

Furthermore, an AI doesn’t require recording tools in the human sense. Instead, it can directly interact with an application, capture visual information (screenshots), analyze the structural data (the DOM), and iteratively construct a test by understanding both the visual and underlying elements. This process can drastically accelerate test creation, potentially reducing the time from 20-30 minutes for a human to as little as 30 seconds for an AI.

The reduced cost and increased speed of AI-driven test generation also lessen the pressure for individual tests to be hyper-robust against minor application updates. While some level of robustness is still beneficial, the ability to quickly regenerate or update tests makes managing changes, even updating a dozen tests weekly, a much more manageable task.

Reporting and Simplicity: Common Ground

Reporting and high-level dashboards remain important for both human oversight and AI analysis to gauge the overall health of the software. However, the AI doesn’t necessarily need the same sophisticated graphical interfaces for detailed analysis and diagnostics; it can efficiently process raw logs to understand why tests failed.

Interestingly, while AI can handle complexity, the testing example highlights that even AI users benefit from well-designed, simpler tools. Providing an AI with too much flexibility, such as the ability to execute arbitrary JavaScript within a test, can lead to overly complex and error-prone outcomes. This suggests a common ground: for both human and AI users, designing platforms that guide towards simple, efficient, and understandable test authoring is advantageous. The final test artifact, even if AI-generated, should ideally be readable for human auditing and comprehension.

Implications for the Future of Software Building

This case study in software testing illustrates a broader point: traditional, off-the-shelf software solutions built primarily for human workflows may face disruption. New tools optimized for AI interaction can be significantly more effective and efficient. Moreover, the testing example suggests these AI-centric platforms can be built relatively quickly and cost-effectively by companies for their specific needs (potentially in under a week by one engineer), shifting the “make versus buy” calculus towards building custom solutions.

“The tools that result are 10 to 100 times more effective and efficient.”

Ultimately, AI is changing the client of our software platforms. We are moving from building primarily for human engineers to building for AI or “cyborg” users. This doesn’t necessarily mean fewer jobs, but rather a transformation in focus. Instead of engineers spending time navigating complex third-party tools, they can dedicate their efforts to building powerful, custom platforms that leverage AI to achieve superior and more tailored results. Software development is evolving to be about creating the tools that empower AI to build and test software more effectively.

lloyd

Meet Ozlo.

(Animated Ozlo, cred @foxattacks)

After over two years, our company has finally unveiled our hard work. We set out to rethink mobile search, and the result is Ozlo, an intelligent conversational AI. With this step we join a number of technology startups and behemoths alike who believe that an emphasis on language and conversation, rather than more pixels and pointers, is the interface of the future.

Ozlo is a focused product that helps you find food and drink via an interface that feels like text messaging. You type what you want, and via a directed conversation you iteratively hone in on something delightful. You can get a higher-level overview of the product on our blog, and you can sign up today for our invite-only beta.

My first day at Mozilla was August 16th 2010, my last will be February 14th 2014.

My first day as a Mozillian was either in November 2004, or it might have been around January 2008. I will not have a last day as a Mozillian.

After a couple years of experience, we (the identity community that supports Persona) have amassed a small collection of changes to the data formats which underly the BrowserID protocol. This post is a migration guide for maintainers of BrowserID client implementations.

I've worked on the Persona service for over two years now. My involvement began on a fateful airplane ride with the father of the specification that would become Persona. Shortly after, on April 6th 2011 I made the first commit. On July 1st 2011 Mike Hanson and I had built a prototype, made some decisions, and I wrote a post on what it is and how it works. Shortly after, Ben Adida joined me and we began carefully hiring wonderful people.

Mozilla Persona is a open authentication system for the web that will eliminate per-site passwords. I work on the team that supports Persona, and this post will describe how we will accomplish a uber-high availability deployment of the persona service with server deployments on every continent. The ultimate goal is fantastic availability, extremely low latency worldwide, and to preserve our tradition of zero downtime updates.

Yesterday I put together a community meeting for the Persona project, which is an authentication system for the web that allows site owners to “outsource the handling of passwords” and implement a highly usable log in system in a couple hours.

The Persona Login service lets web developers implement seamless login via email address with a trivial amount of code. It is written in NodeJS and is supported by Mozilla. The service is deployed as several distinct NodeJS processes. Recently we’ve added a new process to the service, and this short post will describe what’s changed and why.

(This post was collaboratively written with Ben Adida, Austin King, Shane Tomlinson, and Dan Mills)

There are important features in BrowserID that existing API prevents us from implementing. This post motivates and proposes a new API building off the work of the Mozilla community and other BrowserID engineers.

This post explores proposed BrowserID features that cannot be implemented with the current API. I’ll talk about four important features that would require a change to the API, and discuss the precise ways in which it would need to change.

One challenge in building production systems with NodeJS, something that we’ve dealt with in BrowserID, is finding and fixing memory leaks. In our case we’ve discovered and fixed memory leaks in various different areas in our own code, node.js core, and 3rd party libraries. This post will lay bare some of our learnings in BrowserID and present a new node.js library that’s targeted of the problem of identifying when your process is leaking, earlier.

(This post builds on the work of Mike Hanson, Ben Adida, Dan Mills, and the mozilla community)

BrowserID is designed to be a distributed authentication system. Once fully deployed there will be no central servers required for the system to function, and the process of authenticating to a website will require minimal live communication between the user’s browser, the identity provider (IdP), and the website being logged into. In order to achieve this, two things are required:

1. Browser vendors must build native support for BrowserID into their products.
2. IdP’s must build BrowserID support to vouch for their users ownership of issued email addresses.

This post addresses #2, proposing precisely what BrowserID Support means for an IdP, and how it works.

This post will describe the release management processes of the BrowserID project, which is based on gitflow. The BrowserID project has recently become a high visibility venture, with many sites actively using the service for authentication. This overnight change from experiment to production presents us with a dilemma: the project is still in early stages and needs to be able to rapidly iterate and evolve, but at the same time it must be stable and available for those who have started using it. This post describes how we’ll resolve this dilemma.

BrowserID poses interesting user experience problems. The first release was sufficiently complete to provide a usable system, but we’ve learned a lot from community feedback and user testing. Now we can do better. This post proposes a new set of UX diagrams intended to solve several concrete UX problems. The goal of this post is to start a discussion which will lead us to incremental improvments in BrowserID’s UX.

(a special thanks to Mike Hanson and Ben Adida for their careful review of this post)

BrowserID is a decentralized identity system that makes it possible for users to prove ownership of email addresses in a secure manner, without requiring per-site passwords. BrowserID is hoped to ultimately become an alternative to the tradition of ad-hoc application-level authentication based on site-specific user-names and passwords. BrowserID is built by Mozilla, and implements a variant of the verified email protocol (originally proposed by Mike Hanson, and refined by Dan Mills and others).

This post provides a tiny recipe for small scale site deployment with git. If you have a small, mostly static website that you develop using git, and you would like to streamline the publishing of the site to a server that you control, then this post is for you.

Mozilla’s Chromeless project is an experiment toward building desktop applications with web technologies. So far, it’s been more of a fancy-free exploration of interesting features or applications than the serious and sometimes stodgy stuff that platforms are made of. A recent surge of community interest in the project, however, suggests that the best path forward is for the primary developers of the platform to buckle down and focus on producing a stable system upon which others can experiment, play, and ship products.

This post attempts to define a Minimum Viable Product for Chromeless: the simplest possible set of requirements for a meaningful 1.0.

JSONSelect is a query language for JSON. With JSONSelect you can write small patterns that match against JSON documents. The language is mostly an adaptation of CSS to JSON, motivated by the belief that CSS does a fine job and is widely understood.

YAJL is a little sax style JSON parser written in C (conforming to C99). The first iteration was put together in a couple evening/weekend hacking sessions, and YAJL sat in version zero for about two years (2007-2009), quietly delighting a small number of folks with extreme JSON parsing needs. On April 1st 2009 YAJL was tagged 1.0.0 (apparently that was a joke, because the same day it hit version 1.0.2).

Given 2 years seems to YAJL’s natural period for major version bumps, I’m happy to announce YAJL 2, which is available now. This post will cover the changes and features in the new version.

There has been a ton of development in the Mozilla Labs Chromeless project since the 0.1 release, and I wanted to take a moment to give a snapshot of our progress.

In the month since we announced “Open Web Apps”, there’s been a lot of discussion around the particulars of the Mozilla proposal.

I specifically wanted to take a minute to jot down some of the proposed changes to the application manifest format from our initial design. The changes detailed here range from the drastic to the mundane, and have been contributed by my co-workers at mozilla and several community members.

Lately I’ve been collaborating with Marcio Galli on the chromeless project in Mozilla Labs, and one thing I like about the approach is that it leverages huge swaths of the jetpack platform.

This post presents JSChannel, a little open source JavaScript library that sits atop HTML5’s cross-document messaging and provides rich messaging semantics and an ergonomic API.

This post lightly explores the problem of “automatically” backing up a git repository to subversion. Why would anyone want to do this? Well, if your organization has a policy that all code must make it into subversion, but your team is interested in leveraging git in a deeper way than just by using git-svn as a sexy subversion client, then you’ll find yourself pondering the question of repository synchronization.

As I spend more and more of my free time digging around in reptilian mailing lists and such, I find that I’ve begun feeling itchy. Here are four little itches that might be interesting for someone to scratch, micro-projects if you will:

(originally posted on the Yahoo Developer Network)

In recent years, we've seen increased energy put into web extensibility platforms. These platforms let distributed developers collaborate to produce new kinds of interactive features on websites and in the web browser itself. Because these platforms frequently enable data-sharing between multiple distinct organizations, and often sit between two completely different security domains (desktop vs. web), the security and privacy issues that arise are complex and interesting. This post explores some of that complexity: both the current state of platforms that extend the web and their associated security challenges.

A graphical pontification on how the web actually works…

Recently I proposed orderly, an idea for a small microlanguage on top of JSONSchema — something easier to read and write.

There’s been some great feedback which I find encouraging. In response I’ve set up orderly-json.org and started a project on github which will host the specification, the reference implementation, and all of the contents of the json-orderly.org site.

I’ve always wanted a concise and beautiful schema language for JSON. This desire stems from a real world need that I’ve hit repeatedly. Given in-memory data that has been hydrated from a stream of JSON, of questionable quality, validation is required. Currently I’m constantly performing JSON validation in an ad-hoc manner, that is laboriously writing boiler plate code validating that an input JSON document is of the form that I expect.

There are many reasons why git-svn integration is interesting, and most of them are sociological. Here are some situations where git-svn integration can be useful:

[lth@clover sup]$ diff /usr/lib/ruby/gems/1.9.1/gems/lockfile-1.4.3/lib/lockfile.rb{~,}
475c475
<       buf.each do |line|
---
>       buf.split($/).each do |line|

In fiddling more and more with whiz bang HTML drag and drop (in safari 4.x and Firefox 3.5), some things caught me by surprise, primarily because I had already had an idea about "how drag and drop works" that wasn't from the web world. Specifically, in BrowserPlus we invented a very simple model for a web developer to express interest in capturing desktop sourced file drags. Our model was motivated more by ease of implementation and simplicity than by deep adherence to the "precedent" set by browser vendors. At that point there wasn't all that much in the way of precedent....

In fiddling around with HTML5 desktop sourced drag and drop, present in Safari Version 4.0.3 (6531.9), I’m faced with the interesting challenge of understanding when I can trust that a drop is really a drop – that a File is the result of user interaction. For a little context, here’s a bit of code cobbled up by Gordon Durand that’ll let us capture desktop sourced drops in the latest snow leopard:

Really not much to write about, it was trivial to do, and feels a hell of a lot faster than the burning fox. Steps?

First, grab the latest build from the chrome buildbot

Second, probably notice that the chrome binary won’t run for you… missing shared libs? Heeey, me too! Apparently we’re building with certain debug libs here. use ldd to figger out what’s missin, and go create some symlinks:

[lth@clover chrome-linux]$ ldd chrome | egrep \\.[0-9]d
    libnss3.so.1d => /usr/lib/libnss3.so.1d (0x00007fe64a846000)
    libnssutil3.so.1d => /usr/lib/libnssutil3.so.1d (0x00007fe64a628000)
    libsmime3.so.1d => /usr/lib/libsmime3.so.1d (0x00007fe64a3fd000)
    libssl3.so.1d => /usr/lib/libssl3.so.1d (0x00007fe64a1cd000)
    libplds4.so.0d => /usr/lib/libplds4.so.0d (0x00007fe649fca000)
    libplc4.so.0d => /usr/lib/libplc4.so.0d (0x00007fe649dc6000)
    libnspr4.so.0d => /usr/lib/libnspr4.so.0d (0x00007fe649b8a000)

A little make magic (leveraging redcloth and htmldoc) seems to have done the trick. Now high quality print output it ain't, but a good start!

bridges.pdf: bridges.html
	htmldoc -t pdf14 --webpage bridges.html > bridges.pdf

bridges.html: bridges.textile
    redcloth < bridges.textile > bridges.html

.PHONY: view
view: bridges.pdf
	xpdf bridges.pdf

.PHONY: clean
clean:
	@rm -f bridges.html bridges.pdf *~

Earlier today I was impressing my wife with some unix foo by automatically swapping FIRST LAST —> LAST, FIRST formatted data while sorting and finding duplicated entries (ok, so she was only mildly impressed). The shell command looked a little like this:

Later this week I'll be moderating a chat entitled "Implementing the open web" at gluecon in my home town, Denver.

So in preparation for this panel, the logical first step seems to be to establish a clear and concrete definition for the "open web"...

Crazy claim, eh? I figure there's no better way to get this claim tested that by posting it as a truth!

Recently we spent a little time optimizing some servers. These are linux machines running apache serving static and dynamic content using php. Each apache process consumes 13mb of private resident memory under load and has a gigabit net connection. A sample bit of “large static content” is 2mb. Assume cl\ ients consuming that content need about 20s to get it down (100kb/s or so). That means we need to be spoon feeding about 2000 simultaneously connected clients in order to saturate the gigabit connection.

So turn up MaxClients, right? 13mb * 2000 (and a recompile, btw) about 26gb of RAM. uh. that’s not gonna work.

So there’s lots of ways to solve this problem, but before we start thinking about that, how would we simulate such a load so that we can validate the existence of this bottleneck now, and it’s resolution once we fix it?

seige is a great little bit of software that can simulate load:

siege-2.69/src/siege -c 200 -f url.txt

Expiration of my account at hub.org, and my discovery of mosso & slicehost has prompted me to move all my personal shit around… Along with that move I figured I might as well disband my efforts at a ground up implementation of every piece of technology required to run a site, and just throw apache, php, and a little wordpress at the problem (sorry erlang & yaws, I still love you. don’t hate me ruby & lighttpd, you guys are really cute!). This is a common theme in my life, get stuck in the interesting problems that pop up while trying to solve a problem…

anyhow, welcome! we will shortly return to your previously scheduled programming (woteva that woz)…

lloyd

A set of questions that can be used as a jump off point for discussions and learning about computers the internet, and programming.

Theory Questions:

1. What is assembly language?
2. What’s the difference between a compiled and interpreted programming language?
3. At a very high level, how do computers communicate over a network?
4. what is the “emacs vs vi” discussion? What are emacs and vi?
5. What is SSH? What is telnet? Why is ssh better than telnet?

Seeing all this action in ruby trunk, combined with what I’ve read ’round the net had piqued my interest in 1.9 performance differences.

Given the set of contributed benchmarks that I used when developing the inital patch to improve the reclamation and decrease memory usage of ruby, I did some comparisons of ruby 1.9 vs ruby 1.8.6, and of ruby 1.9 vs a patched ruby 1.8.6.

In short, looking at this data leads me to some preliminary conclusions:

• 1.9 is decidedly “faster” than 1.8.6. Especially when runtimes are longer, or yaml is involved.
• 1.9 uses slightly less memory overall. *There is considerable room for improvement in 1.9’s memory reclamation.

w00t. An email from matz, and a little spelunking in the ruby subversion repository shows that there’s some tinkering going on in ruby garbage collection land. Here are the interesting change logs:

r15674 | matz | 2008-03-03 01:27:43 -0700 (Mon, 03 Mar 2008) | 5 lines

* gc.c (add_heap): sort heaps array in ascending order to use
  binary search.

* gc.c (is_pointer_to_heap): use binary search to identify object
  in heaps.  works better when number of heap segments grow big.

This page details some changes to the ruby garbage collector which seem to afford a 25% reduction in maximum heap memory usage, and nearly double the amount of heap space ruby’s is able to reclaim. This comes at the cost of a 2% performance hit. More to come, stay tuned.

Here’s the Problem:

http://lists.apple.com/archives/x11-users/2007/Oct/msg00065.html

Here’s a proposed “fix”:

http://aaroniba.net/articles/x11-leopard.html

If they didn’t add RPATH support, DTrace, and pretty much avoid judicious changes, I’d be throwing stones. As it stands, this is extremely annoying, but tolerable. Looking forward to the fix…

-lloyd

Ruby’s GC & heap implementation uses a lot of memory. The thing is based around the idea of “heaps”. Heaps are chunks of memory where ruby objects are stored. Each heap consists of a number of slots. Slots are between 20 and 40 bytes, depending on sizeof(long). When ruby runs out of heap space, it first does a GC run to try to free something up, and then allocates a new heap. the new heap is 1.8 times larger than the last. Every time a GC run happens, the entire heap is written to turn off mark bits, these are stored in the heap. Then we run through top level objects, and mark them, and all their descendents. Then we throw away anything that’s not marked (sweep). Because of the way ruby works, objects may never be moved around in heaps. That means from the time they’re allocated to the time they’re freed they may not be moved to a new memory address.

I cannot live without X11 emacs! It doesn’t build from macports right now. As far as I can tell, the emacs that apple ships with leopard is broken, at least for me after upgrade I get:

[lth@tumno ~] $ /usr/bin/emacs.broken
Fatal malloc_jumpstart() error