Lately I’ve been wrestling with the developer experience for headless coding. This paradigm offers a lot of advantages to IDE-based coding - but it’s not easy to adopt!

Engineers love their IDEs. IDEs have been shaped through decades of practice to offer all kinds of goodies: auto-complete, color schemes, and so on. Asking engineers to give up IDEs is a big ask.

Some companies have tried the nuclear option: leadership gives a mandate that henceforth, all code must be agentic. There’s certainly something to be said for that kind of “ripping off the band-aid” moment, and there are some visible success stories that you’ll find online. However I suspect there’s a fair amount of survivor bias: we probably don’t hear about numerous cases where this approach failed miserably.

My approach is more “grassroots” in nature. The idea is to gradually spread the paradigm, as follows:

  1. Get the basic mechanics of headless coding working in a small, isolated context. Install Codex, spin up a greenfield project, crank out some commits.
  2. Create some readily-shared artifacts. In my case that includes a suite of skills to support headless coding, which will be delivered on a plugin marketplace.
  3. Provide training materials. Blog posts, video tutorials, office hours - all of the above and more. I’ve found that repeating yourself, across many different formats and venues, is crucial. It never hurts to repeat yourself. Did I mention that repetition is important?
  4. Hands-on SME program. Identify a small number of early adopters who can adopt headless coding and get their feet wet with the tools. It’s crucial that these early adopters should be working on normal feature work, roadmap projects that they would be doing anyway - it’s time to graduate beyond toy projects and deliver real value! It’s also ok to provide a lot of hand-holding, pair-programming, check-ins, and other support. The goal is not just to get some headless coding done, but also to learn what’s not working in the headless coding framework, and to go and fix those problems before you scale out.
  5. Evaluate. Once you’ve got the SMEs pushing some headless code into production, you want to see how well you did. I’m measuring lead time to change against token spend to get a picture of ROI.
  6. Rinse and repeat! There are probably several iterations of this process necessary before the practice can really take hold. Of course the idea is that, Amway-style, your SMEs bring their teammates and other engineers into the process, so that you get organic growth over time.

The above process is hardly original, I am stealing bits and pieces of it from projects I’ve seen take off well in the past - and I have to admit I got a lot of great ideas from my experience in the Developer Platforms group at Wayfair.

What it is, though, is necessary. All the best tooling in the world is useless if no one’s using it!