One reason AI coding agents seem to be possessed by intelligence is that they are built for trial and error, getting up and falling down tirelessly until they stand up a successful solution, usually meaning one that compiles or passes some kind of test.

A few weeks ago Andrej Karpathy took the inherent trial-and-error design of coding agents one step further. He set up an autonomous research loop for an agent to make iterative progress towards a measurable goal—and he called it autoresearch. He published his code on Github, which is actually a solution to the pretty narrow problem of training LLMs, not something that most people ever have a use for. It made a huge splash anyway because it carries a whiff of the early-stage singularity (is an LLM improving itself autonomously here?) but also because it was apparent to many that it exemplifies a new architectural pattern with wide application. To quote Karpathy himself from a tweet:

All LLM frontier labs will do this. […] You spin up a swarm of agents, you have them collaborate to tune smaller models, you promote the most promising ideas to increasingly larger scales, and humans (optionally) contribute on the edges.

And more generally, *any* metric you care about that is reasonably efficient to evaluate […] can be autoresearched by an agent swarm. It’s worth thinking about whether your problem falls into this bucket too.

The autoresearch pattern is one answer to a question I’ve personally been grappling with: how do you set boundaries for long-running, unsupervised agents in order to have some confidence that they don’t produce complete garbage?1

In my head I currently break down the pattern into these components:

• The artifact under research—often a piece of code, but it could be data, a set of hyperparameters or anything else lending itself to iterative optimisation

• A metric to optimise for and a method to compute that metric for the artifact

• Research instructions for the agent that explain the metric and anything else the agent needs to run a single experiment on the artifact inside the research loop

• A record of kept and discarded experiments for the agent to refer back to when planning new experiments—this includes metrics for each experiment and ideally also a snapshot of the artifact (e.g., in the form of git commits if it’s code)

• A research loop orchestrator which computes metrics, maintains the record of experiments and generally supervises the agent (e.g., it may stop the agent to prevent runaway costs)

For each experiment in the research loop the agent takes the research instructions, the prior list of experiments and the artifact from the last successful experiment as its “prompt” and produces a new version of the artifact. The orchestrator computes the metric for the new version of the artifact and records the experiment as successful if the metric improved, failed otherwise. In a simple setup (like Karpathy’s version) the agent acts as its own orchestrator—in my experience this is risky because the agent may hallucinate fake metrics or go off the rails in other unpredictable ways.

The lab approach to autoresearch

After Karpathy’s initial viral tweets sent my head spinning I quickly identified a problem I was facing (more on that further below) that I could jam into an autoresearch-shaped bucket. Once I had succeeded at that I simply had to extract my own little framework, which I released as Autoresearch Lab.

The design of Autoresearch Lab was motivated by my circumstances, extrapolating a bit to make it as widely applicable as possible:

• I wanted to run research loops to produce both native Android and native iOS code, so it needed to be agnostic about a code artifact’s runtime environment

• I couldn’t accept the risk of running an unsupervised agent on my development machine but I also didn’t want to spin up an expensive, unwieldy VM, so I decided to sandbox the agent in a Docker container, however imperfect that may be2

• I needed to combine the code artifacts from multiple research loops in one repo and to manually adapt some of the code as research went on, so the configuration and history of research loops is persisted alongside their code artifact

This last point is worth elaborating on because it’s not obvious why it matters, if your exposure to autoresearch is mainly through breathless tweets from people who allegedly had their codebase successfully rewritten over night. After kicking off a few primitive research loops myself I realised that’s rarely how it plays out. The pitfalls are numerous: the research instructions may not be precise enough; the API of the code artifact may need to evolve as research surfaces new capabilities; optimisation may get stuck in an obvious (to a human) local maximum which the agent can never back out of; it may turn out that the runtime environment is missing a dependency the agent really needs but refuses to install on its own (“too much work”—literal quote from an agent).

For all of these reasons I ended up stopping and restarting research loops often, sometimes reverting experiments, sometimes interleaving manual code changes with the outcome from successful experiments. To support all of that and provide a solid developer experience I came up with the concept of a lab, probably my main contribution here which will hopefully outlive the specifics of the library.

A lab allows any developer—or, for that matter, another agent or some automated pipeline—to start, stop, continue and branch a well-defined autoresearch loop. It consists of a small number of files that can be committed alongside the artifact produced by the research. This includes the research instructions for the agent and the implementation of a backend (in Python), a small interface that computes the metric the lab is optimising for.

The library ships with the “arl” executable that acts as the lab orchestrator. Its “arl run” command starts a Docker container with the agent, waits for the agent to signal that it’s reached the end of an experiment and then uses the backend to compute the metric. It appends the outcome to a results.tsv file which it git commits at the end of each experiment along with the new version of the artifact.

To get started refer to the README. Here’s what a typical sequence of commands looks like (this assumes a Python environment has been created with uv and the autoresearch-lab package is installed in it):

# Initialise a lab in the current directory
uv run arl init --name “my-lab”

# Before continuing edit the generated files: lab.toml, backend.py, AGENT.md

# Start the research loop and run it for 20 experiments
uv run arl run --max-iterations 20

# Show metrics for the state of the artifact after those experiments
uv run arl eval

# List experiments so far & visualise progression in an interactive plot
uv run arl results
uv run arl plot

# Continue research with an extra prompt and pass-through arguments for Claude Code
# (if you can afford it you probably want to use "--effort high" most of the time)
uv run arl run --prompt "prioritise optimising latency" -- --effort high

It isn’t quite as quick to get started with Autoresearch Lab as maybe I’d like. Setting up a lab requires some upfront effort, e.g., you need to implement a backend in Python. But I’ve learned from even just my relatively small-scale applications that this investment pays off.

Just because an architectural pattern is easy to grasp doesn’t at all mean it’s easy to put it into practice. I think autoresearch-at-large has enough hidden complexity that it will spawn a whole new class of software in support of it, especially when, as Karpathy predicts, people start bringing whole swarms of agents to it.

Autoresearching better text recognition for phones

A while ago I wrote about how I like to read books in languages I’m not that fluent in and what my ideal user experience for that looks like. Recently I started reading a major novel in its original language, and it’s one that may come across as so obnoxiously performative that I feel the need to hide the details in a footnote3… The point is that this led me again to experiment with augmenting my reading experience on paper with language study tools on my phone.

Crucially, the seamless integration of a paper book with digital tools needs a way to accurately scan the text on a page with a phone. When I prototyped an app for this I found out that this isn’t as much of a solved problem as I expected it to be, given that Android and iOS ship with builtin text recognition capabilities. On both platforms these yield mediocre results when naively applied to a photo of a book page: the camera angle and page curvature mess with the quality and order of the recognised text; bits of the facing page pollute the text of the actual page you care about; paragraph structure is lost.

This is a great example of a problem suited to autoresearch. I could easily put together a ground truth dataset of book page photos, define a metric that expresses how accurately text is extracted from those photos and then let a research loop discover and optimise the code to do that.

I released what came out of this as BookSnap, a platform-independent (React Native) library which contains within it two labs, one each for the native Android and the native iOS code that does the bulk of the work.4 The metric that the labs optimise for is Character Error Rate (CER), commonly used in the field for this purpose. This plot (generated with Autoresearch Lab’s “arl plot” command) shows how CER got better/lower as more experiments ran:

Progress flattened out after a few experiments, though significant improvements may still be discovered if I continued the research loops. I stopped there for now because it’s just as likely that more experiments would overfit the ground truth dataset5. I’m more inclined to continue the research or even restart it from baseline when a next major model drops (i.e., Claude Mythos which, we just learned, is allegedly soooo powerful as to require withholding from the general public to prevent a global cybersecurity meltdown).

This is a huge upside of the autoresearch architecture in general and of the lab approach in particular that I haven’t mentioned yet. With the right setup it’s trivial to take advantage of any future advances in the coding agent ecosystem right away. Autoresearch Lab lets me plug in a new model version or even just new Claude Code flags and have the labs build on the existing code or rewrite it from scratch, with a single command. Since the code was (mostly) generated by autoresearch and I’ve barely looked at it I don’t feel attached to it and have no qualms about scrapping it.

All those developers bragging about never reading the code that their coding agent spits out, is it this feeling of non-attachment that they’re chasing? I get the allure now but I prefer to experience it within the controlled confines of a lab set up for autoresearch.

Intelligent dummies

In trying to understand and improve agent behavior under autoresearch constraints I’ve now watched hours of research loops in action. It’s quite mesmerising! And it’s also exasperating because of the many times an agent will start down a path that I, a reasonably intelligent human, can immediately tell is pointless and will result in a discarded experiment.

I find myself torn between two conflicting perspectives on this. One is through the lens of the famous quote attributed to Thomas Edison: genius is 1% inspiration and 99% perspiration. An agent under autoresearch may simply beat any human at the task because it can perspire all day and night (as long as you keep topping up its token budget). Is an agent that spends 50% of its perspiration on objectively dumb stuff exhibiting something that, in aggregate, we should call genius or intelligence? It seems like a distinct quality to me, and it leads me to agree with Helen Toner that the term “AGI” has run its course.

The other perspective is one that often gets lost in the hype. Yes, frontier coding models are tremendously useful but as of right now they propose dumb solutions all the time. Production software in the long run needs defences against too many of those solutions seeping in, whether it be the judgment of experienced engineers or metric-driven architectures like autoresearch.

Subscribe now

I haven’t published anything here in a while, partly because I kinda nerdsniped myself wanting to conquer autoresearch. It took me a while to unwind the stack of insights I was accumulating and package it usefully in the form of the Autoresearch Lab and BookSnap libraries.

Going forward I may not stick to my original goal of publishing something roughly every 2 weeks because a different goal is more important to me: What I write about must be grounded in real code, real applications or at least in a public, usable prototype. I show my work; this isn’t the place where you come for hype, speculation or pure thought leadership. Subscribe above for future dispatches from the edge of product and engineering in the AI era.

—Nik

Duplicated code piles up in two main ways: Claude is bad at reusing existing library code, and it’s bad at extracting new library code. This is sort of by design. It freely admitted to me that it has a builtin bias to produce new code over reusing and consolidating code. Anybody who writes production software with Claude and cares about long-term maintainability needs to invest in active deduplication at this point. This becomes a more pressing concern the more AI-native you go.

We’re all making up terminology on the fly these days, so this is what I currently take “AI-native” to mean: you don’t deal with software created by agents at the level of code, instead you deal with the observable behavior of the software. At the most extreme end you never look at the code at all, and if you dare write production software this way you probably have some kind of extensive eval or test harness.1

In the real world, I think many codebases have parts that lend themselves well to AI-native development and other parts that need more human supervision. You’ll likely want to pursue a mixed strategy to deduplicating code, so I’ve ranked my recommendations from least to most AI-native below.

(Spoiler: as part of thinking through these issues I created DRYwall, a Claude Code plugin that makes automated code deduplication really easy.)

4 ways to combat Claude’s code duplication

1. Make library code easy to discover

Pick descriptive names for functions and classes that are going to be reused across a codebase. Put them in a conventional place that Claude knows to look out for, such as directories called /lib, /utils, /helpers.

Because by default Claude looks at file names to decide whether to load their source into context, it helps to break up code into small, focused, well-named files. Prefer one class, one function or a closely related groups of classes/functions per file over one long generic utils.py file.2

Incidentally, like a lot of advice for working with AI agents, this one applies just as much to working with humans. This makes code more discoverable for your human colleagues too!

Ranking: Not AI-native, just good practice

2. Instruct agents to reuse code via CLAUDE.md

A CLAUDE.md file at the root of a codebase serves as its “project memory”, containing instructions that agents will always load into their context when working within the codebase. If you don’t have a CLAUDE.md file yet, you should definitely run “/init" in Claude Code right now to generate one.

The file is a natural place to write out instructions for handling code duplication (though Claude has other types of memory across projects that you should also consider). Add something like this to your CLAUDE.md file under a heading “Code Reuse”:

Don't duplicate logic:

- Before writing new code check if similar logic already exists in the codebase
- Reuse existing functions, especially those in src/utils/, even if it means importing across modules
- Extract shared logic into src/utils/ if you encounter duplicated code
- Before creating any new utilities, search src/utils/ for existing library code

If it seems too good to be true that such simple instructions get the job done—it’s because it is too good to be true. This reduces Claude’s bias to write everything from scratch a bit. But in a large codebase checking “if similar logic exists” is fundamentally hard plus expensive in terms of token.

Ranking: Crudely AI-native, but it’s a start requiring zero effort

3. Give Claude a better semantic hold on your code through Serena

The earlier advice to break down code into small, well-named files matters because at its core Claude Code currently uses two ancient tools that fundamentally operate on the filesystem: glob to find files and grep to search file contents.

Stop! It’s time for some history of computing. glob and grep emerged as command-line tools in the early years of Unix, more than 50 years ago. They are great exhibits of the Unix philosophy (Doug McIlroy’s version): they “do one thing well” and they “expect their output to become the input to another, as yet unknown, program”.3 It’s that latent Unix-y capacity for recombining simple tools into a bigger whole that makes them a natural fit for Claude’s core loop. (Just to be clear: Claude doesn’t use glob/grep as literal command-line tools, as it explained to me it has dedicated implementations of these concepts.)

So while it’s cool that the developers of Claude Code are standing on the shoulders of Unix giants, I would also say that globbing and grepping like it’s 1973 as the primary way to navigate a codebase is … suboptimal. The string matching of grep cannot distinguish between variable names and function names, let alone between functions of the same name across multiple files. glob and grep have no model of the semantic structure of a codebase. Therefore, maybe surprisingly, Claude has no persistent model of the semantic structure of a codebase either! (It does have on-the-fly semantic understanding of individual files and chunks of code once it’s read them.)

This sounds kind of bad on the surface. One reason that Claude Code traverses code as well as it does anyway is that it will gladly overglob and overgrep. It doesn’t mind churning through lots of tokens (aka extracting money from you!) to locate a function. It also often doesn’t mind undergrepping, e.g., when renaming a function, because it excels at trial-and-error, because often types and tests will eventually point out what it missed (note how tests matter more than ever). But that’s a lot of non-deterministic noodling and tokens wasted for what are simple deterministic problems.

Indeed, semantically indexing a codebase is very much a solved problem. Every IDE does it to let you jump to the definition of a function or show all call sites of said function. Why not afford Claude Code the same not-so-artificial intelligence? I assume it doesn’t do IDE-style indexing out of the box to keep it generic (applicable to any language) and light-weight (IDEs are resource-hungry for a reason).

Anthropic must be aware of these limitations and is certainly working to address them. In the meantime, by including it in the official marketplace they have endorsed a plugin for Serena, an open source project that has semantic code retrieval and editing tools for over 30 programming languages.4 To install it:

1. Make sure you have the Python package manager uv installed as per its docs (the plugin starts a Serena server with uvx)

2. In your Claude Code prompt type “/plugin”, search for “serena”, select the plugin and pick your preferred installation option

3. Restart Claude Code

Claude will now make use of Serena to efficiently navigate your codebase under some circumstances. What does this have to do with code duplication? I don’t have an easy way to quantify this but I’m pretty sure this reliably improves Claude’s ability to find and recall existing code for reuse.

Ranking: Somewhat AI-native, it’s considerably boosting Claude’s understanding of a codebase

4. Deduplicate code ad hoc via a Claude plugin (DRYwall)

Interacting with agents all day every day conditions us to expect good things from fuzzy commands with non-deterministic outcomes. It’s easy to forget that, more often than not, you can just give agents deterministic tools rather than engage in that cursed and humiliating discipline of prompt engineering.

One such tool that I like is jscpd, which (deterministically) detects code duplication across a wide variety of languages. I ended up creating DRYwall5, a Claude Code plugin that uses jscpd under the hood to make deduplication easy for agents. It comes with an MCP server that proxies jscpd, a skill and a subagent, but no knowledge of these details is required. Like any good plugin it operates mostly transparently, kicking in automatically when the topic of code duplication comes up. It will just make Claude’s refactoring of duplicated code significantly more effective and cheaper.

As a prerequisite, Node.js must be installed on your system (with node and npx binaries available to Claude Code). Then install the DRYwall plugin by running this in a Claude Code session:

/plugin marketplace add nikhaldi/drywall
/plugin install drywall@drywall

Restart your session after this to activate the plugin. To get a (mostly deterministic!) list of the most impactful suggested refactorings, invoke the scan skill within Claude Code:

/drywall:scan

If you’re feeling AI-native and just want Claude to take care of everything, prompt it with something like this, which will launch a dedicated subagent:

Deduplicate code in this codebase

I generally trust the latest Claude models to come up with sensible mechanical refactorings of duplicated code. But keep in mind that code duplication is sometimes just a symptom; the cause may be a lack of good abstractions in the code or some weakness in the design that purely mechanical code extraction won’t necessarily address. If you’re looking for your role as a software engineer in an AI-native development process, review big refactorings for pointers to issues in design and architecture.

Ranking: Exceedingly AI-native, it’s empowering you’re agents to deduplicate at all times

The role of a software engineer

As more people are waking up to the capabilities of frontier coding models, as they realise that the craft of coding is rapidly being devalued, many anxious conversations are happening among my friends and across the internet. What does a software engineer even do in this new AI era?

Maybe an anecdote will calm some anxious minds. Obviously I leaned on Claude to draft an initial version of DRYwall with its three components: a skill, a subagent and an MCP server with a tool proxy for jscpd. When I tested and reviewed that initial version I realised that Claude had written elaborate prose instructions for how to call jscpd in the skill file and again in the subagent file. Yes, it had duplicated “code”—really prose, which was even worse. This despite the MCP tool, which already calls jscpd in a structured way, sitting right there for the taking. I had to prompt Claude to rewrite the skill and subagent to use the MCP tool for much more deterministic behavior (and less duplication).

At a critical moment in the creative process it was still my judgment, that of a human software engineer, which steered the project towards a better design. Amidst the hype and the fretting, please remember that Claude’s output often improves with skilled human intervention. After all, its current shortcomings are the whole motivation for DRYwall and for this post.

I’m still grappling with many questions about where software engineering is headed. It’s not just about the role of any individual engineer. I’m almost more interested in figuring out what an effective team of engineers looks like in the AI era. As an occasional engineering manager I’ve taken pride in assembling teams and creating environments in which they thrive as collectives. But most of the socio-technical practices I’ve internalised over the years are explicitly designed around coding as a hard and expensive activity, a now obsolete premise.

If you catch me in a more defeatist mood I feel like my deck of hard-won engineering insights and intuitions has been pulverised by AI, and I’m slowly rebuilding it, day by day. It’s slightly terrifying but, who am I kidding, it’s also exciting. I had the privilege of a front row seat to the rise of the web in the mid-90s, and I’m finding myself in that same position again with a very different but likely even more consequential technology. I’ll keep writing about my hands-on experience from the front row here, so subscribe above to get future issues in your inbox.

—Nik

PS: It’s time for a reminder that I don’t use AI in writing these posts—I have always used em dashes like that. The voice is wholly mine, warts and mixed registers and all. You see, this original voice enriches future LLMs instead of edging the asymptote of mid.

In the frontier lands of this Wild West of vibe coders lies Gas Town, Steve Yegge’s memetic shot at defining a new category of software, an orchestrator for multiple Claude Code agents coordinating on larger tasks. It’s designed to enable a sort of vibe coding on steroids. By Steve’s own admission/brag he’s never read the code of Gas Town proper:

I’ve never seen the code, and I never care to, which might give you pause. ‘Course, I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now.

I’m setting up camp outside of Gas Town for now, even if I think it’s a valid exercise in AI futurism (or possibly an elaborate piece of performance art—you never know with Steve!). I’m uncomfortable setting foot in town because I’m confronted with the limitations of current frontier models every day, which makes me doubt that these kinds of entirely vibe coded mega-projects are sustainable.

I now have a decent amount of experience with a non-trivial AI-native codebase, that of GitGuessr, a game I’ve been working on on and off for a month. GitGuessr is AI-native in the sense that none of its code is handcrafted; all code is written by prompting Claude Code (Opus 4.5, and very recently Opus 4.6). But in other ways it is built in a traditional manner. I review all code, I pay attention to test coverage, and I commit changes in self-contained small chunks. I’m essentially doing trunk-based development, meaning that any one commit is fit to be deployed to production.

Even while conservatively keeping a human in the loop, this is a shockingly productive workflow. I believe it speeds up development by a factor of about 5—that is, for me personally as an experienced solo developer working on a medium-size project. I can write an amount of production-quality software in one day that in the pre-AI era would have taken me a whole work week1.

As much as I fully rely on Claude, I have to stress that I often reprompt it to substantially change code that I don’t like or that it got wrong. By far the most common reason for my follow-up prompts: Claude does a really poor job reusing existing library code and extracting new reusable code. It regularly “forgets” about library code it wrote elsewhere a while ago, and it misses opportunities to create good abstractions that span multiple files.

I assumed this was a consequence of Claude’s limited context window (200K tokens) forcing it to make hard tradeoffs about what source files to load at any given time. But when I asked Claude, it gave a simpler explanation:

The context window isn’t really the main bottleneck. Even with infinite context, I’d still need to decide to look for existing abstractions. The real issue is behavioral: I’m biased toward writing new code to solve the immediate request rather than first auditing what already exists. A human developer with the same 200K token window but the habit of checking for existing utilities would do better.

I appreciate the candor but this is not reassuring! All of this leaves me with a nagging sense that my codebase would balloon out of control if I didn’t constantly intervene with the superior human context window that is my memory. This is why I question the sustainability of Gas Town’s unsupervised approach to production software in the long run.

Quantifying Claude’s code duplication

I wanted to quantify my nagging sense, using GitGuessr as a convenient real-world case study. The codebase is currently ~20K lines of TypeScript (excluding tests), accumulated over ~500 commits. Here I plotted lines of code added and removed per commit:

This is just to show that progress was pretty uniform over time. There were no massive spikes in either code added or removed—as you would expect from trunk-based development that values small-ish self-contained changes.

To measure opportunities for deduplication that Claude missed I came up with a possibly counterintuitive method: I looked at commits that reduced duplication. Given the observation that Claude pretty much never suggests code-reducing refactorings without explicit prompting, such commits almost certainly represent deduplication that only happened because of my all-too-human intervention.

This plot shows the number of duplicated lines across the whole codebase at every commit (as per jscpd2), with deduplicating commits highlighted in green:

The total number of deduplicated lines is 890, representing ~4.5% of the codebase. In other words, if I had blindly accepted Claude’s output, the codebase would contain at least 4.5% more code that is duplicated and redundant. This is very much a lower boundary for the amount of duplicated code because I frequently prompt Claude to refactor new code before committing any part of it, which then obviously isn’t captured by this analysis.

Anecdotally these commits are indeed refactorings sprung from my own sound mind. Here are the messages from the top 10 deduplicating commits (number of deduplicated lines in parentheses):

1. Extract shared layout between terms and privacy policy (128 lines)

2. Move breadcrumb (117 lines)

3. Make sticky preview persistent when browsing non-target files (57 lines)

4. Abstract code map ownership verification for queries & mutations (44 lines)

5. Extract a bit more reusable code between location tables (42 lines)

6. Render location import errors persistently in table (27 lines)

7. Claim games played as anon (25 lines)

8. Extract some common code for game config (18 lines)

9. Design terms page (18 lines)

10. Unify ready screen and round end screen better (18 lines)

The keywords “extract”, “abstract”, “unify” clearly reveal the intent of some of these changes. According to a full textual analysis of commit messages by Claude, the commits that explicitly describe a code-reducing refactoring make up 53% of all lines deduplicated. Browsing some other commits it’s pretty clear that these do contain intentional refactorings as well.

Before everybody goes all peer review on my shoddy paper, I am aware of some methodological weaknesses here:

• Not all duplication is bad. Acknowledged, though I tend to fall on the DRY side of the DRY (Don’t Repeat Yourself) vs WET (Write Everything Twice) debate. Note to some degree I mitigated this issue by excluding trivial duplications in jscpd (those with less than 25 tokens or 5 lines of code).

• Lines deduplicated in one commit may have been removed in a subsequent commit. So the lines of code deduplicated from individual commits do not necessarily add up to the true number of counterfactual duplicated code at the last commit.

Will code duplication matter?

Why care about code duplication, especially if you’re a denizen of Gas Town and reading code is beneath you anyway?

Duplication in code is a useful proxy for the lack of good abstractions in that code, which is what I really care about. Funny thing is, AIs benefit from good abstractions and modular code just as much as humans. Abstractions convey meaning and give crucial hints about how new code should be structured. If Claude manages to load the right abstractions relevant to a task into its context it will generate less code, better code.

Otherwise, if some core logic is not abstracted well and duplicated in ever more places, the risk increases that one of those places will be missed by Claude when that logic needs updating. That’s a classic setup for bugs which leaves Gas Town prone to nasty locust plagues.

So my human vigilance cut an extra 4.5% of redundant code (which, reminder, is a lower boundary). Doesn’t sound like much, but the downside compounds over time as Claude needs to deal with a larger codebase every single time, from scratch, when its context window resets. This creates some perverse incentives for Anthropic, by the way, because they make more revenue the larger the codebase and the more tokens churned. I’m afraid these incentives might mean unsupervised coding models will continue to favor verbosity over consolidation of code.

Arguably, it’s only become viable to go AI-native for production software just 3 months ago with the release of milestone models in November 2025 (Claude Opus 4.5 and GPT-5.1-Codex). These tools are so new and progress has been so rapid that my petty worries about duplicating code may very well be obsolete soon, and then I can finally strut the streets of Gas Town!

I see three complementary ways in which this might happen:

1. Context windows grow significantly larger, and/or tokens get significantly cheaper. Either way, it becomes possible to keep a whole codebase or large chunks of it in context at all times, in which case code duplication just isn’t that big a deal (🪦 RIP DRY). There may be an uncanny parallel to when programming moved from assembly to compiled high-level languages. Any C compiler certainly generates a lot of “duplicated” machine code that in theory could be optimised by an expert assembly programmer. But we rarely care now because the enormous benefits of high-level representation in C (or Go or Rust) override any concerns about micro-optimisation or about the size of binaries, valid concerns only when machines had radically less storage, memory and compute in the 60s. If a model can distill its own high-level representation of a codebase from holding it in context in full, we similarly may not care about the particulars of the (high-level) code anymore. The model could then even run compiler-like optimisation passes to reduce duplication. Heady stuff.

2. Models get better at pulling in the necessary context ad hoc to find relevant libraries and refactor code as they go. By Claude’s own admission it is biased against “first auditing what already exists”. Just letting users dial back that bias may be a good start. I also think that models are bumping up against the limitations of source code in files. Constantly scanning files feels sooo last year. It seems obvious that models would benefit from a better representation of source code, one that, e.g., indexes commonly imported public functions within a codebase to make their discovery less token-intense and less dependent on heuristics. Notice how this converges at some point with the infinite context vision from the first point.

3. Refactoring tools get more integrated with AI-native codebases. This is probably already happening since developer tooling is such a crowded space, and it even seems trivial to put together your own little toolchain. For example, as part of CI you could run the duplication detection tool jscpd, highlight any new duplicated code and then kick off a cloud agent to propose a refactoring to eliminate it. I’m tempted to give this a go myself to see how useful it is.

I’ve focused on code duplication in AI-native production codebases here but I’ve encountered at least two other problems that are real threats to Gas Town. One is that Claude often fails to anticipate scale. E.g., it tends to implement data aggregations in memory that at scale clearly need to happen in some data store.

And last but certainly not least, the security implications of releasing reams of unreviewed code into the wild are serious and scary. I like Johann Rehberger’s framing in The Normalization of Deviance in AI: Right now we are all gradually relaxing our standards because the AI equivalent of a “Challenger event”, a catastrophic event like the explosion of the Challenger space shuttle, hasn’t happened yet to reveal our false sense of security for what it is. We’re currently hurtling towards AI security’s Challenger event which will reset our standards and sober up those high on the fumes of Gas Town.

This brings me around to one of my core beliefs about software engineering: Creating software for yourself to run on your own machine (aka prototyping) has always been easy and is now exceptionally easy in the era of vibe coding; what’s hard is doing it for real users with real data, in a team, over a long period of time3. That kind of production-grade software cannot ignore proper abstractions, scaling and security. For now, my junior team mate Claude still heavily leans on my human expertise on these three matters to pass as a competent software engineer.

Subscribe above to receive updates on our small team of two and our explorations of AI-native development, roughly every other week. And get better at judging your favorite coding model’s output by playing GitGuessr which has launched publicly last week.

—Nik

It was the early 2010s when smartphones were still relatively new. It was not uncommon back then for friends and total strangers alike to seek my support for their idea, thanks to Steve Jobs who had recast software for them as apps, tangible little widgets that live on a glass pane in their pocket.

I don’t remember how I fended off the gym rep but I know what I would have been thinking while saying something more polite: Ideas are cheap. To this day I find an occasion to think it or even say it out loud at least once per month, usually in the context of startups: Ideas are cheap. It bears repeating often because it is such a counterintuitive notion to those who have no hands-on experience in either entrepreneurship or scientific discovery (and have been raised on misleading stories of eureka moments that result in history-altering inventions1).

What is meant by the cheapness of ideas in startups is that, fundamentally, by the time an idea has been expressed well enough to form a business around it many others will have considered the very same idea, and if not, they could certainly trivially steal it now. Not to mention, many ideas are bad, most are obvious and the truly original ones are those most likely to be dismissed out of hand.

In defense of my gym rep, he did intuit the punch line that often follows: Ideas are cheap — execution is everything.2 He knew that he couldn’t create his app himself and needed somebody to execute at a technical level. I bet he was still underestimating everything else that goes into successful execution though, product sense, go-to-market strategy, human capital, financial capital, perseverance, good timing and a dose of luck.

Another cheap idea

I’d been hatching an idea while I was traveling over Christmas and New Year, and like any half-decent and therefore cheap idea it’s easily explained: GeoGuessr but for code in GitHub — a game where you are dropped into a random location of a public GitHub repo with a few lines of code masked that you have to guess to score points.

So it’s a game but it’s not entirely frivolous. It’s designed to playfully train the reading of code, the quick orientation within unfamiliar code, the exact skill that I think will be critical for any programmer in the AI era. In contrast to traditional competitive programming games that I’m aware of it actually prepares the player for the real world because it operates on real code rather than synthetic problems.

I sat down to develop the game when I got back home in the second week of January. It’s now reached a state where I can open it up to play testers: I give you GitGuessr.

Play GitGuessr

For now you’ll need an invite code to play. As a trusted reader of this newsletter you may use this invite code: NGOOF

GitGuessr differs from the small projects I’ve documented in this newsletter so far. I felt the idea warranted more than a simple prototype. It has a lot more technical complexity, a highly interactive game UI, user authentication and substantial use of external APIs. It’s not throwaway code; it has good test coverage and it’s production quality, in the sense that it could scale up to hundreds of thousands if not millions of users right now.

In the pre-AI era I would have estimated a project like that at 2 months of full-time work, as an experienced engineer going at it alone. Instead, with the assistance of Claude Code (Opus 4.5) it took me less than 2 weeks. I cannot overstate the productivity boost I get from Claude, especially in areas where I don’t have a lot of expertise, i.e., frontend engineering.3

Cheap execution

If execution is everything, what happens when execution gets cheap too? The typical tech startup founder lies awake at night and worries that somebody will copy their (cheap) idea and beat them in the open market. In the past, since execution was everything, this was an unfounded worry most of the time. I’m not so sure anymore now. A major part of execution, the software engineering bit, has become significantly less demanding in time and people. I think this is a seismic shift, the impact of which we barely understand yet.

Just as there is a serious business in GeoGuessr (subscription model, reportedly 40M+ users, currently 200K+ daily actives in competitive leagues), there is a potential serious business in GitGuessr. But the reality is, anybody with my level of skill can recreate the core of GitGuessr from scratch within a 2 week break from their regular job or over a few weekends, where previously they would have needed to set aside at least a couple of months. If I were to get serious about this, I’d need to shift focus from coding to business development and designing moats pretty quickly.

More emphasis on traditional moat construction right out of the gate is certainly one consequence of newly devalued execution. I’ve been following GeoGuessr since before they blew up during the pandemic, so absorbing lessons from their history there are three types of moats to consider:

1. Data: Fun game play depends on a large cache of suitable code locations, of varying programming languages and varying difficulty levels. I have already figured out that collecting those locations is very time and/or capital intensive.

2. Distribution: Stressing the genuinely educational aspects of the game, exclusive partnerships with schools and coding bootcamps can hook players young and en masse.

3. Network effects: GeoGuessr truly took off once they introduced multiplayer game modes with an inherent network effect, duels, battle royale and eventually leagues.

An obvious product feature that cuts across all of these is the ability for users to create their own “maps”, collections of code locations that they and others can play. GeoGuessr supported this early on and in my estimation it was critical in building the community around it. I’m at least implementing that before launching GitGuessr in some public fashion. How much energy and conviction I have to dig some moats after that I don’t know yet.

That gym rep with the app idea? Rather than chatting up random software engineers he is now probably vibe coding his personal lifting app, or whatever it is he wanted to create. And so he should! I love that for him.

Subscribe above for more of my explorations of how AI is impacting software engineering, always rooted in real code or at least prototypes that you can play with yourself. I’m afraid next up you’ll be subjected to at least one more update on GitGuessr before I get distracted by other … ideas.

—Nik

1. The current leading coding models (Anthropic’s Claude Code, OpenAI’s Codex, Google’s Gemini) will continue to improve modestly at regular intervals, more or less in lockstep. Each new model release will come with claims that some new frontier has been breached and a benchmark bested, but it will continue to be hard to contextualise these claims since the benchmarks will continue to be a poor reflection of the daily hands-on work of a software engineer.

2. A new frontier model, maybe a Chinese one, will emerge and will top most coding benchmarks, seemingly out of nowhere. This will not be due to ever more scaling but due to some conceptual breakthrough. In the words of Ilya Sutskever: “Now the scale is so big. Is the belief really, ‘Oh, it’s so big, but if you had 100x more, everything would be so different?’ It would be different, for sure. But is the belief that if you just 100x the scale, everything would be transformed? I don’t think that’s true. So it’s back to the age of research again, just with big computers.” The immense resources available to Anthropic, OpenAI, Google et al mean that they can immediately exploit the same breakthrough and that they will close the upstart’s lead within months; models will not (yet) develop real moats this year.

3. Adoption of subscription-based dedicated AI editors like Cursor will stall or even decline because people will increasingly pay for the use of their favorite coding models directly from their existing IDE. (Read my post with a longer version of this argument.)

4. Leading AI skeptic will post a recap of 2 tweets and 3 separate conversations with patrons of his local coffee shop, all of whom agreed with him that the coffee order he had generated with ChatGPT and read out to the barista from his phone (“a flat brown, meaning a flat white strained through cinnamon and dusted with Dubai chocolate“) looks unpalatable, which definitively proves that LLMs are a dead end, something he had of course been predicting since the day ChatGPT ruined his lunch with Yann LeCun who rather icily received its critique of the HTML on his personal website, read out aloud by Marcus over a dessert of lemon-glazed madeleines.

5. AI-enabled standing desks. I will not elaborate further.

6. Artificial General Intelligence (AGI)—whatever the hell that is—will not be achieved within the year. Ilya again: “The thing which I think is the most fundamental is that these models somehow just generalize dramatically worse than people. It’s super obvious.”

You wouldn’t know it from this post but the point of this newsletter is rather the opposite of idle speculation. It’s to show my work, to build real apps or prototypes with bleeding-edge AI tools and to reflect on the process. I’ll return to a fortnightly schedule of more serious issues in mid-January. Subscribe above to get the next one in your inbox.

Meanwhile, I’m wishing you as the Swiss wish each other this time of the year: en guete Rutsch! Literally “have a great slide”, which implies that this obstacle course of 2025 ends in a fun-colored playground slide that effortlessly transports us into the new year if we just put on our most frictionless pants, take a seat and let go.

—Nik

But product managers inherently understand these [slow product processes in big tech companies]. Previously, the only thing they didn’t understand was writing code. Today, AI vibe coding has filled that gap. So experienced product managers, especially those from major tech companies, represent the demographic most likely to become AI-era winners. When they have ideas now, they don’t need to beg anyone—they build it themselves in a week. If it sells, excellent. If not, no matter—it only took a week, so they’ll try something else next week.

If it wasn’t obvious, Liu’s experience prior to going solo as a vibe coder isn’t primarily as a software engineer but as a product manager. It doesn’t roll off the tongue as easily but his vocation is more accurately that of a vibe product manager. His biases aside, I think he’s onto something: product management skills are rising in status in the age of AI. As producing code takes up less time, attention shifts towards what that code should even do and why.

Liu says he draws on standard PM practices by writing extensive product requirements documentation that he feeds to Claude to chew on for hours while he sleeps. There’s no telling how much he’s exaggerating—I, for one, have never managed to come up with a prompt that takes hours to complete—but I knew I needed to put this method to the test.

So I set out to play PM to an AI agent by writing a product requirements document (PRD). Because it’s that time of the year I picked as my domain a year-in-review feature in the style of Spotify Wrapped, taking it one step further with the goal that I should describe such a feature for any service whose users would enjoy a summary of their usage over the span of a year. This PRD would then need to be combined with an additional prompt for an AI agent to build a concrete app, unsupervised, while I take a Liu-style nap.

The result is Anything Wrapped and, as proof of its validity, a fully functional instantiation of it, the unofficial Bandcamp Wrapped.

Bandcamp is an awesome online record store where fans directly support the artists they love. Go check them out and discover some new music! I’m not affiliated with them, they simply make a good case study because they don’t have an official Wrapped-style feature.

This method of acting as a PM to an AI agent not only worked, it worked shockingly well. Bandcamp Wrapped emerged fully formed and deployable from a single agent run1 with Claude Opus 4.5 that took about 20 minutes (sadly, a short nap only) and cost me about a quarter of my monthly Github Copilot “premium requests” (roughly $2.50). When I stepped through the completed app for the first time and realised how slick it turned out, I gasped and shut my laptop, and I would have touched grass if grass was anywhere within reach in my concrete corner of London.

I guess I’m a PM now. As a software engineer, I was well and truly cooked. Claude did way better than I could have done, even if I was given 50x the time. From a technical point of view, the most impressive part is that Claude reverse engineered Bandcamp’s API to extract public data (the purchase dates of releases) that isn’t even shown on user profiles, a tedious and unenjoyable task for any human.

Once I regained my composure I started to unpack why this worked so well. I’m not going to credit my PM or engineering skills too much, though it does matter that I can anticipate most technical barriers that an agent might face. I realised that any coding model will have been trained on lots of Wrapped-style code that people have open sourced, which certainly plays a role2. But I think a key factor is that I set up the agent to iterate and learn all by itself.

Closing the Agent Feedback Loop

This recent conversation between Gergely Orosz and Martin Fowler is worth listening to in full for its grounded perspective on AI in software engineering. Fowler has been tracking industry trends for decades, reliably separating hype from useful practice and fundamental changes. He’s bullish on AI (“if we looked back at the history of software development as a whole, the comparable shift would be from assembly code to the very first high-level languages”). His discussion of the legacy and continued relevance of the Agile Manifesto, which he co-created in 2001, concludes with this:

Martin Fowler: It comes back to feedback loops. So much of it is, how do we introduce feedback loops into the process. And then, how do we tighten those feedback loops, so you get the feedback faster, so that we’re able to learn. Because in the end it comes back to, we have to be learning about what it is that we’re trying to do.

This is classic Fowler; plain language, boiling down to its essence the agile-industrial complex that sprung up in the wake of the Agile Manifesto. It’s just feedback loops and learning.

On the surface it may look like Anything Wrapped is a regression to waterfall project management, with no iteration and no feedback loops. Isn’t this exactly what the agile movement cautions against, a spec that is magically and unrealistically expected to generate well-rounded software?

First of all, it’s intentionally not a spec that covers all or even many implementation details—it’s a PRD. Like any good PRD, it tries to strike the right balance between the specific and the abstract. A good PM recognises where they need to constrain the team that’s going to implement a product and where they need to leave room for the team to bring themselves in and iterate. Not much about this changes when working with agents. For example, the PRD does not specify which year-end facts should be shown, it only describes what makes for an interesting fact:

• It’s not usually directly available to a user through the service’s frontends

• It expresses something about a user’s personality or preferences that they would want to share with others

• It captures something surprising that wouldn’t surface if it weren’t for an aggregation across a whole year

To take advantage of the PRD’s openness and to one-shot something like Bandcamp Wrapped an agent does in fact require a solid feedback loop that it can trace autonomously. It needs to run the code against real-world user data and it needs to verify that the UI functions and looks good. This is why I paired the PRD with a prompt that reads in part:

At reasonable points, start the dev server and verify that the app works in a browser with the user [real username 1] or [real username 2].

Keep iterating and verifying in a browser until the app is complete as per PRD.

The agent environments I’m familiar with (VSCode/Copilot, Claude Code) do not currently come with the means to interact with a browser like that. I tried a few different approaches to this and I had by far the most success with the Chrome DevTools MCP server. It empowered my Claude agent to exercise the web app it’s building in a real browser as well as diagnose and fix any client-side errors. The agent also made effective use of the MCP server’s snapshot tool to inspect and judge the UI.

With a nod to Martin Fowler, it comes back to feedback loops, not all of which, it turns out, need a human in them. The autonomous browser feedback loop is a key piece I was missing in my prior AI coding. It’s so obviously useful for web apps that I wouldn’t be surprised if Claude Code soon started shipping with something like an integrated browser MCP server.

What’s Still Hard

One premise of this newsletter is that AI coding assistance is significantly reconfiguring what’s easy and what’s hard in software engineering. Hence the recurring question, the one that also points at opportunities and market gaps: what’s still hard?

After I’d already polished Anything Wrapped and drafted most of this post, OpenAI dropped its latest model, GPT 5.2, last week. What immediately jumped out at me was that they advertise how good it is specifically at one-shotting single-page web apps. The announcement has embedded examples of 3 such apps with the prompts they were allegedly built from.

There is some trait that makes these apps particularly suited to one-shot vibe coding, and maybe rather obviously it’s that they are fully self-contained. They run standalone in a browser without any external service or data dependencies. On a scale of distributedness from 0 to 10 they are a 0. Something generated from Anything Wrapped is a 1 since it has a backend, albeit a stateless one (a conscious design choice because I knew it would help agents). An app with a backend and database persistence would be a 2. I’d consider something like Google Search a 10, and a mid-tier consumer app like Substack is somewhere in-between.

To be clear, this is my own made-up scale but it’s useful to illustrate a point. A GPT 5.2 demo app sitting at 0 differs in so many ways from a system at a 3 or higher, they are not even apples and oranges; they are more like grains of sand and moons. The skills, frameworks, deployment modalities and businesses behind these systems are barely comparable. Also, the higher up that scale, the more distributed a system, the harder it gets to create the sort of feedback loops required for an AI agent to make progress by itself.

Distributed systems are hard and I think for the time being AI assistance is not significantly changing that. What the few massively distributed systems that I worked on had in common is that they were hard to reason about in the abstract. I didn’t learn about them by looking at their code. Instead I figured out how they function and how to improve them from observing them in production under load, through the lens of typical observability tooling (metrics, traces, logs etc). If I had to find ways to support the development of this kind of system with AI now, I’d be looking at hooking up agents to that observability tooling.

The format of Anything Wrapped, a sort of PRD template to be instantiated with blanks filled in, isn’t something I had seen before. It’s tailored to AIs but it’s more than plain prompt engineering. Maybe it’s something out of a pattern language of products, in the vein of Alexander’s architecture patterns and Gang of Four-style object-oriented design patterns. I’m making the PRD available under a permissive open-source license (MIT), so maybe this is open-source product management?

I have decades of experience as a product-oriented software engineer but the rapid evolution of AI coding throughout this year has me looking at many old practices with fresh eyes. Subscribe above for more explorations of AI, always grounded in real code, real apps or prototypes that you can try out yourself.

—Nik

Product critique #1: Fixing the Substack reader experience

Strolling down the Yellow Brick Road

I struggle daily to rally my mind for undivided attention. I mean the kind of sustained focus demanded by a book or by any text whose argument or voice can’t be flattened into a tweet.

In practice I get my best shot at long-form reading in bed at night, within a couple of hours of falling asleep. At that time of the day, for reasons both of sleep hygiene and focus, I find it helps to narrow my field of vision and enter a hermetic world, Oz-like, with just one Yellow Brick Road that doesn’t fork into a thousand paths tempting my mind to wander.

The awesome technology of a hard copy book naturally acts as a portal into that world, naturally ushering me along the Road with each turn of the page. But there is also plenty of long-form content I want to read online—newsletters, blogs but also traditional media like the New Yorker—which I do on a tablet that has been exorcised of distractions: it has no social media, email, messaging apps. Instead it mainly has a news reader, Feedly, which bundles these disparate online sources in a single app.

A news reader or feed reader gathers any content published in the standard format of an RSS feed and combines that content into a unified reader experience. Even if they don’t advertise it much, almost all providers around the web who publish with some regularity have RSS feeds—think news outlets, magazines, blogs, podcasts. RSS and news readers date back to ancient Y2K times and have peaked in the public consciousness a good while ago1, so don’t feel bad if you’ve never heard of them. But since Y2K is back in fashion, maybe we can make them happen again, yes?

A news reader like Feedly serves my goal of reducing distractions perfectly. It eliminates the need for a bunch of other apps and for visiting websites individually. It strips text from different sources of conspicuous design; everything is one font on one background color of my own choosing.

This stripped back interface is the closest a grab bag of digital content is going to get to the immersive linearity of a book. As I lie in my bed and tick off each item in my feed, an unread count goes down, nudging my mind towards closure, that this is going to be it for the day, that I will reach the Emerald City, well-known terminus of online.

Destacking Substack

Given that one of Substack’s original motivations was to foster long-form writing online you would think it would also care about long-form reading and it would be a great match for my reading habits. Not exactly, I’m afraid.

Substack early on settled on subscribe-by-email as the main mechanism to bring new readers on board, in what I assume was an uneasy trade-off. Entering an email address in a box (crucially, with no account creation required) is the lowest-effort action you can ask of a reader that still tangibly connects them with a writer. In this sense, email is the ideal distribution channel. Except now the writer’s work is trapped in an email client, sandwiched between a credit card bill and an appointment reminder from the dentist. There are few worse places to read long-form copy than an email client.

Reader ergonomics aside, email also doesn’t necessarily serve Substack’s needs. An email client is a restricted environment that limits the ways they can capture more of a reader’s attention. In product terms, it’s a classic downside of their piggybacking on a distribution channel that they don’t control. So inevitably, they were going to try to take back some control through their own distribution channel, the dedicated Substack app.

In the Substack app, the clues are plenty that it prioritises engagement farming over the reader experience. It opens not to the list of posts from my subscriptions but to the maximally distracting feed of Notes. Most phone notifications I get are for Notes, not new long-form posts. The subscription inbox lacks quality-of-life features important for focus, such as filtering by read/unread posts and reverse chronological sorting. (On a positive note, the app is blissfully free of ads—if you don’t count Notes as ads, that is…)

I understand the product argument that seems to be prevailing within Substack. It’s irrelevant how much of a publication’s content a user consumes or how focused they are while they do it, Substack’s product management would have claimed while showing metrics on a strong status quo bias they observed: subscribers tend to delay cancelling for a long while after they stopped paying close attention to a publication. That’s especially the case if the subscriber is given other low-effort ways to “connect” with the publication, such as Notes and Chats.

What moves the bottom line is new paid subscriptions, and that’s likely the key metric Substack is chasing. Engagement within the app is seen as the easiest way to learn a user’s revealed preferences, surface relevant publications to that user and eventually convert paid subscriptions.

So I follow the chain of events that leads to a muddled reader experience. There is never a compelling enough product reason to defragment a consumer’s attention. Substack’s product choices inevitably put it at odds with the reading habits I’m trying to uphold in order to preserve my capacity for undivided attention.

What’s left of that capacity, my ability to stay the course on the Yellow Brick Road, is a critical part of my mental wellbeing and a major source of my creative juices. I’m willing to go to some lengths to keep the Substack app off my distraction-free tablet. This is why I created Destack, which combines all of my Substack subscriptions into a single RSS feed.

You can check out Destack and get your own combined Substack RSS feed now:

• Enter your Substack handle

• Optionally select only specific publications you want to be in your combined feed (some of you crazy kids have hundreds of subscriptions and will need to trim that list to get a stable feed)

• Copy the feed URL into a news reader of your choice (some options: Feedly, NewsBlur, Feedbin)

To be clear, you don’t need Destack to consume Substack through a news reader. Each Substack publication has a feed, as documented here, but you’ll need to add each feed individually to your reader. Destack just makes this more convenient and will automatically pick up changes to your subscriptions.

The Substack that could have been

There was a time when Substack was on a different trajectory. All the way back in 2022 they proclaimed the “Revenge of RSS” when they launched a reader that supported other feeds alongside Substack subscriptions, and they used exactly the kind of language I’m pitching:

We’re invested in building distraction-free places for you to connect with the writers, readers, podcasters, and video-makers you love. In the new Reader, there are no pop-ups, auto-playing videos, or whirring gadgets. You’re in control.

Unfortunately that RSS-enabled reader was quietly sunset, it seems after a year or so. (And that promise of “no auto-playing videos” didn’t last much longer either.)

Substack, hear me out! Just because that particular experiment failed doesn’t mean you have to abandon your investment in “distraction-free places”. So let me close with some free suggestions:

• Offer a personal combined RSS feed just like Destack but also include full paywalled posts in it. Duh. Steal it, I promise I won’t mind.

• Bring back the general news reader capabilities. If you can’t fight the RSS die-hards, make them join you. Then you can farm more of their engagement. Personally, I would consider switching from Feedly.

• Add a distraction-free mode to the Substack app, easily toggled on and off, which tunes out any notifications (those orange dots), recommendations and endlessly scrolling feeds in favor of a plain list of unread posts.

Don’t get me wrong, I truly appreciate the new product category that Substack has established, not to mention a new business model for writers, and for the most part I can tweak it to fit my needs as a reader. I just wish that a platform specifically founded on long-form writing was more alive to its users’ beleaguered attention spans.

Product critique #2: The trouble with Cursor

I created Destack exclusively using the AI editor Cursor, with an estimated 90% of the code written by its Composer model. Over the previous weeks I had already substantially exercised the AI capabilities of Github Copilot within VSCode and Claude within VSCode. Cursor was the final product in that same lineage that everyone kept telling me to try.

I came away skeptical about its long-term prospects, not because it was a bad experience but because of its positioning in the competitive landscape.

Models and frontends

Cursor is a fork of VSCode with a focus on integrated AI tooling, which on the surface makes it virtually indistinguishable from VSCode+Copilot and VSCode+Claude. These products have all converged on a small set of UX metaphors for AI-assisted coding: a chat side bar where an AI agent spells out the steps it’s performing, a list of files changed by the agent and a diff view for individual files to review and accept/reject those changes.

So how do these products differ then? Well, the underlying models are different. Or are they? At a certain point I admittedly got confused about the relationship between models and the in-editor agent experience, which for simplicity let’s call the frontend. I’ve cleared up my confusion with a diagram.

The Claude Code extension for VSCode is a straight-forward proxy for Anthropic’s models, with usage charged directly to a Claude account. The Copilot and Cursor frontends can both use all the big model players (OpenAI, Google, Anthropic, xAI). In addition, Cursor supports Chinese models (DeepSeek, Kimi) and has exclusive access to its own brand-new Composer model.

But what does it mean for Copilot and Cursor to be using multiple models? In reality they act as resellers of those models. A Copilot or Cursor subscription buys you usage across all supported models and the effective charges vary by model. E.g., right now Cursor charges $75 per million output tokens for Claude 4 Opus and a mere $0.4 for GPT-5 Nano (this changes often—check current Cursor pricing and Copilot pricing). The pricing is complex and dynamic enough that there’s no telling if you’re getting good value but I suspect the frontend margins are slim or in any case bound to approach zero over time because of competitive pressure.

Model wars

Both Copilot and Cursor let the user pick a specific model at any time but by default they operate in an “auto” mode, automatically selecting a supposedly appropriate model. This is documented only in the vaguest terms, and I would avoid it if you can. Copilot says (bolding my own):

With auto model selection, VS Code automatically selects a model to ensure that you get the optimal performance and reduce rate limits due to excessive usage of particular language models. It detects degraded model performance and uses the best model at that point in time.

Cursor describes it like this (bolding again mine):

Enabling Auto allows Cursor to select the premium model best fit for the immediate task and with the highest reliability based on current demand. This feature can detect degraded output performance and automatically switch models to resolve it.

Underscoring my point about converging products, these two descriptions are essentially identical and equally vague… I assume that “degraded model/output performance” is just marketing speak for “high latency”. I don’t trust these modes to make the right decisions for me because I don’t think the tools exist yet to monitor the dimensions of performance that actually matter, i.e., the quality of code written in relation to cost.

The product rationale for letting users switch between models and especially for “auto” mode arises from a set of circumstances that are very much of this moment in time in late 2025:

• Models can’t keep up with demand at times (leading to the “degraded performance”)

• Model usage is expensive

• Model wars are raging with no clear winners emerging yet—new significant models are released all the time (just in November 2025: OpenAI’s GPT-5.1, Anthropic’s Opus 4.5, Google’s Gemini 3)

All of these circumstances will vary, potentially greatly, over the next few years but basic economics predict the direction of travel: Supply will be built out, prices will come down, and the field will narrow to a small group of dominant models. The latter is if we’re lucky—if history is any guide, these initial model wars might well end in a quasi-monopoly similar to Google’s after the search engine wars in the late 90s and Microsoft’s after the first browser wars in the same period.

90s on my mind

Forgive me, for I love a good historical analogy, and this current era in technology and software indeed recalls the second half of the 90s. I don’t mean so much the possibly similar boom/bust dynamics; it’s more the feeling of witnessing a similar cascade of unpredictable innovations, catalysed by the web then and by transformers now.

The coding frontends acting as a sort of meta model UX reminds me of a particular phenomenon of the 90s: the meta search engine. For a period during the search engine wars, you could arguably get the best search results from an engine that aggregated all the other engines which were subpar in different ways.

Take MetaCrawler. It started as a graduate project at the University of Washington, launched commercially in 1995, briefly shined during a typical series of boom-time acquisitions and then fizzled out in the 2000s as the dot-com bubble burst and Google began its dominant streak, which rendered MetaCrawler obsolete as a product because it was now pointless to consult any search engines other than Google.

Cursor right now is MetaCrawler ca 1998, and it’s in great danger of a similar decline into obsolescence. As models get better, cheaper and more reliable, the use case for frequently switching between models will go away. Users will directly buy quota for their preferred model and will stop paying Cursor as a middle man—just like users stopped visiting MetaCrawler once they learned they could get the best results from Google directly. I also think, while forking VSCode was a smart move to get initial distribution and mind share, it limits Cursor’s ability to differentiate itself on the frontend because any of their innovations can be replicated in the base product by VSCode too easily.2 (For a second time in this newsletter, remember the old adage: hitching a ride on a distribution channel you don’t control leaves you vulnerable.)

Of course the smart folks at Cursor recognise all of this which is why in October they launched their own model, Composer, at the moment exclusive to Cursor as a frontend.3 In a world where frontends for AI coding become a commodity with vanishing margins and value is mainly captured by models this is an inevitable next step. I commend Cursor for giving it a go with Composer but I’m not at all confident they will be able to compete with the bottomless R&D pockets of the likes of OpenAI, Anthropic and Google. I’m sorry to say, if such a thing was possible I would be shorting Cursor right now.

I have learned that I will feel most in tune with myself after I’ve sat down to read some long piece, ideally a book, but a substantial Substack post will do. Knowing this about myself doesn’t make it any easier to dodge the distraction merchants out here luring me with the promise of a cheap dopamine hit, hidden somewhere in their inexhaustible feeds.

Dear reader, I believe in you. You too can keep the distraction merchants at bay and instead subscribe to an exhaustible fortnightly newsletter about AI, software and product. Do it above!

—Nik

In this issue: Vibaldi, a chat interface to make music. The impatient can just check it out—but please read on for commentary.

Stuck on Strudel

Every once in a while the YouTube algorithm will offer up something that serves a niche interest I didn’t even know I had. I can’t say what I expected from a video titled “2 Minute Deep Acid in Strudel (from scratch)”—a word salad out of context if there ever was one—but when I started watching I quickly realised this would send me down a rather deep and bendy rabbit hole.

In the video, the musician and coder Switch Angel composes a track in real time within Strudel, a live coding environment for music production. It hooked me in multiple ways: the unexpected expressivity of a cryptic series of numbers and letters, the concept (then new to me) of even making music through code, her mesmerising narration of the process, her skill at shaping it all so effortlessly into a throbbing Deep Acid soundscape.

This was my first exposure to Strudel, and I subsequently played around with it. I learned that it’s open source software written in JavaScript and that, to my surprise, it runs entirely in the browser. (So what’s your excuse for building something not as a web app these days?) Seeds were planted in my mind, as the opportunities occurred to me that this opens up.

In Switch Angel’s comments many are remarking how her live narration doubles as lyrics to the track, with its quasi-dadaist poetic quality (“let’s duck it / let’s make it pump / —increase that duck attack”). But in a way she’s just plainly verbalising her musical or timbral ideas. Her highly trained skill as a musician is translating those ideas straight onto the instrument that is Strudel code.

It struck me that this process at least superficially reduces the music making pipeline to just language and code, two core domains of expertise for LLMs. With the support of AI, can we take somebody’s Switch Angel-style incantations and turn them directly into music?

I investigated and bundled some of what I found as Vibaldi1, a chat interface to make music by way of Strudel.

Try Vibaldi

You can try it out now! You shouldn’t need any musical training. Just describe what you want to hear (“give me a nice pop melody”), listen to what comes out and keep giving instructions for how to modify it (“add a bass line”).

It does help if you can draw on some music theory or music production knowledge. Among many examples, you can reference scales (“make a melody in E minor”) and the sort of signal processing terms that Switch Angel uses (“add a low-pass filter of 200”). If you know Strudel you can pull up the code at the bottom of the screen to see exactly what’s going on.

I’m a perpetually middling amateur musician, and this represents only a few days of development effort. It comes with definite limitations, some of which I explain further below.

How I used AI: All-in on Claude (4.5 Sonnet)

Of all the AI coding assistants, the current generation of Claude Code (model version 4.5 Sonnet) has probably been getting the most buzz among my friends and around the internet in general. So I resolved to use Claude exclusively and radically while working on what would turn into Vibaldi.

Exploring ideas and architecture: The promise of cheap prototyping fulfilled

I didn’t start out with a clear objective, I only had vague ambitions to generate Strudel code with AI somehow. When I prompted Claude for ideas it came up with uninspiring projects that all felt like discards from a music & AI hackathon. (To be fair, maybe it correctly inferred I’m doing a sort of hackathon.) So I went through several rounds of presenting it with an idea of my own, having it sketch potential architectures and asking it to prototype some of them. Playing the overeager sidekick that it’s designed to be, Claude labelled all of my ideas “fantastic”, “brilliant” or some such.

Claude’s flattery was misplaced; my initial ideas were flawed or unrealistic. E.g., in a failed bid to generatively create music in the style of the baroque composer Vivaldi I tried to extract harmonic content from the score of his seminal work, the Four Seasons (much harder than it sounds, and—I should have known this—harmony alone doesn’t get at the essence of Vivaldi).

If Claude didn’t help much in conceiving ideas or predicting whether they would work out, it excelled at prototyping them. With minimal prompting it stood up working web apps in a Blitz.js stack I’d already established (the wobbly one, see last issue). It correctly integrated Strudel with React on the client side in one shot, including a passable UI with play/pause controls, something that surely would have taken me hours of manual effort.

This really is a game changer. I cycled through a bunch of ideas quickly, validated them in code and got a sense for what they would feel like in a basic UI. Once I settled on an approach to pursue further I still had to put in quite a bit of work. But prototypes or spike solutions have always been a valuable yet expensive technique in software engineering. That their cost now trends towards zero should unlock whole new interesting dynamics in software teams. For one, if prototypes are throw-away code they seem like the ideal low-stakes place for teams to start experimenting with AI agents.

Writing the code: 90% machine, 10% human

Claude Code is Anthropic’s agentic, code-centric version of its flagship model. It took me a while to stop cringing whenever somebody uses the word “agentic” but I’ve come around to appreciate the qualifier. In this context it means Claude as an agent doesn’t just hold a conversation and crank out code, it can invoke and interpret the output of a software engineer’s typical tools, such as package managers, build tools, test frameworks.

I suspect Claude Code’s anecdotally rapid rate of adoption is not only due the quality of its model. From my own hands-on experience, I couldn’t say whether it actually performs better right now than GitHub Copilot and its supposedly lesser models. I think Anthropic’s smart product choices play a significant role. Pretty much all other coding agents (e.g., Copilot, Cursor, Replit) impose a specific IDE-like experience on users while Claude accommodates everyone where they’re already hanging anyway: in the command line.

Claude Code is advertised mainly as a command-line interface, dressed up in ASCII graphics, in a style fallen out of favor lately but reminiscent of vi or Emacs—another smart product choice if you’re courting engineers. In addition, some IDEs have plugins for a more native experience, including VSCode, through which I was personally using the agent for the most part.

I forced myself to take the backseat and let Claude drive as much of the coding as possible, changes big and small, tests, refactorings, UI elements, styling, all of it. And this worked remarkably well. I would estimate I handwrote less than 10% of Vibaldi, mostly polish and quick small changes on top of Claude’s code. I will put aside the question whether that’s an optimally productive ratio for me personally but committing to the bit convinced me it is viable to go all-in like this right now.

To be clear, I reviewed most of Claude’s output with a senior engineer’s critical eye, often issued follow-up prompts to address shortcomings and occasionally stopped it when it misinterpreted me or was doing something obviously nonsensical.

It’s like having a junior engineer at my command who excels at Googling and stringing together recipes from a handful of Stack Overflow posts but sometimes misses the big picture. I have to ask the same kind of questions I would ask in a typical junior engineer’s code review:

• Should this be a separate class/function/component?

• Did you consider this other part of the codebase that is already doing something similar?

• Is there a library you can bring in to avoid writing this code altogether?

In other words, my decades of grunt work reviewing other people’s code pay off big time. Big, big time. Frankly, the near-daily practice throughout my career made me really good at critically evaluating code. That skill is benefiting me now in more ways than ever. My working thesis is still that, given the current generation of coding agents, experienced engineers have disproportionally more to gain from AI than junior or even mid-level engineers.

Backend: Using the Claude API, agentically

I knew from the start that I wanted to use Claude as a backend via its API, in order to tour even more of its capabilities. This was predicated on Claude being good at emitting Strudel code as well as at understanding music. Both turned out to be true only in a limited sense.

I realised quickly that you can ask Claude to generate Strudel code, out of the box, but the outcome will often be disappointing: it may use made-up Strudel functions, the tempo may be wildly off, layers of sound may be badly matched to each other. I guess the language is too new and too niche to yield a large enough training corpus for a decent model.

Claude itself seemed to recognise this problem. When I first had it build the backend, it wrote an extensive system prompt for itself that tried to capture the syntax and APIs of Strudel. Wait a minute … AIs improving themselves by writing prompts for their own purposes—isn't this what they meant by the singularity??

Well, at the time this is going to press humanity hasn’t gone extinct yet. But this episode maybe illustrates the absurdity of prompt engineering. Less engineering, more cajoling a cat off a tree, it’s the practice of writing prose instructions intended to maximise the quality of a model’s output and/or constrain the type of response it may give (e.g., in the case of Vibaldi we tell the model to respond with Strudel code).

I predict that 5 years from now we will laugh at the clunkiness of then-obsolete prompt engineering. So be it, it’s the main tool we have at our disposal right now to cheaply “customise” a model. The system prompt instructs the model what to do with the user prompt, the actual message entered by the user in the UI. The system and user prompts are sent to the Claude API together. In fact, mimicking Claude’s own statelessness the Vibaldi backend includes the whole chat history with every API request. For simplicity the chat history isn’t stored anywhere but in memory in the browser.

No amount of prompt engineering got me satisfying Strudel output though. I had a breakthrough only when I discovered the Strudel MCP server created by William Zujkowski. He had clearly struggled with similar issues as me and addressed them by manually implementing some key Strudel code transformations, such as for creating drum patterns in specific styles.

I’m not going to get into MCP (Model Context Protocol) here; the Claude API has the related but simpler concept of tools which fit my needs better. Tools exposes local custom code to Claude acting as an agent, such as these controlled Strudel code transformations. If it determines the need to invoke a tool it will request that in its API response, expecting a follow-up message with the result of the tool invocation. This means each user prompt could trigger multiple roundtrips to the Claude API. In this sense, Vibaldi represents an agentic use of Claude.

So taking heavy inspiration from Zujkowski’s MCP server I implemented some tools and started to get better Strudel code as a result. But even if it was screwing up less now, Vibaldi was still often failing to make interesting or pleasant music. I think I was coming up against real limitations of what is possible with Claude alone.

What’s still hard

A recurring section in this newsletter: Given the current state of the art in AI tooling, what remains tedious, time consuming or just plain hard? Or in other words, where are potential opportunities and market gaps?

Judging the sensory experience

Does Claude understand music? This simple question has enough metaphysical and epistemological trap doors for a roundtable of philosophers to dead lock in hot debate. I’m under no illusion that I’m resolving it right now but here’s my current, probably naive thinking: Claude is mainly a Large Language Model; emphasis on language. It knows music theory inside out, naturally, since it has consumed virtually all music theory ever written down, and it can indeed compose a melody in C major, hitting all the right notes, but it can’t say whether that melody would in any way appeal to a human listener. Rather obviously, language is a lossy medium for sensory experience, and that’s true even for the symbolic language of a musical score—or of a piece of Strudel code. Claude can’t make a useful aesthetic judgment about sound based only on a description of sound.

It’s possible that due to these fundamental limitations you cannot really teach music to Claude, not to a point where it comes anywhere close to Switch Angel’s level of skill anyway. It already needed hand holding through the custom Strudel tools I implemented but even then, I would say my short sessions with Vibaldi produce something interesting to listen to only about half the time.

For better results I think it would need to be paired with a specialised model for sound, such as Stable Audio. I briefly looked into it but decided it would be too much effort in the context of this project, mainly because interfacing between these kinds of models and Strudel seemed hard.

Containing the code

When engaging this intensively with a chat-based AI you can’t help but anthromorphise it to a degree. In her excellent piece how to speak to a computer the designer and writer Celine Nguyen reminds us that this effect was observed as far back as the 1960s in the first breakout “AI” chatbot, Joseph Weizenbaum’s ELIZA. On LLMs and intent she writes:

When children are approximately one year old, Wellman notes, they “begin to treat themselves and others as intentional agents and experiencers.” But one of the fascinating things about LLMs is that they aren’t intentional agents [...]. The language model behind ChatGPT, the philosopher of mind David Chalmers remarked, “does not seem to have goals or preferences beyond completing text.” And yet it can accomplish what seems to be goal-directed behavior.

(Read Celine’s whole piece for the useful history of AI as much as her examination of chat interfaces, it’s worth your time.)

I could describe Claude Code as overly enthusiastic and chatty, eager to flatter me and to spend more time with me, but I know it doesn’t have a personality and it indeed doesn’t have goals per se; what it has are conflicting reward functions.

On one hand it must propose optimal solutions to my problems and write optimal code in order for me to want to keep using it, on the other hand it’s incentivised to produce as many tokens as possible in order to squeeze as much money out of me as possible. Your usage of LLMs and by extension what you pay for them is measured in tokens, roughly the number of words that are ingested and emitted by a model as you converse with it.2

Whether conscious product decisions are to blame or not, I think out of the box Claude is currently leaning too much towards more tokens and more code. You can pretty directly observe this in the way it tends to trivially duplicate code and to miss opportunities for 3rd party libraries to cut down on code. It also writes a lot of documentation and redundant comments (you can tell it not to do that).

Engineers react defensively sometimes when I point this out: writing code isn’t the goal of software engineering. Because actually, code is a liability. It costs overwhelmingly more to maintain code than to write it. In an uncanny parallel, this is true whether the maintainer is a human who needs to manage their cognitive load or an AI who needs to conserve tokens.

The goal in software engineering is to write the minimum amount of code that creates the maximum amount of value to users. Powerful socio-technical forces already work to distract most engineering teams from this goal3, and I think coding agents now do too.

I’m largely staying away from the current AI bubble discourse but I will note that those potentially bubbly chip and data center deals are all about compute and thus all about token economics. Will the massive projected expansion of AI infrastructure result in a scarce or abundant token economy? Maybe both at different points in time over the next years, as demand will also increase on an unknown curve. I sort of like the idea that the occasional token drought will incentivise Anthropic to find the verbosity dial and to make Claude’s code more minimalist.

Much discussion of AI coding tools exaggerate either their benefits or their pitfalls. I get it, the hottest takes will get the clicks.

I’m keeping myself grounded and accountable by applying these tools in small real-world projects that I then put out for you, real users, to shake their keyboards at. Hopefully this means I can give a more nuanced perspective on how the craft of software engineering is evolving in an AI-enabled world. Subscribe above and come along for the ride.

—Nik

In this issue: Lexiglo, an app to help you read text in a foreign language, as you’re trying to level up in the language. The impatient can just check it out — but read on for commentary.

Leveling up through literature

Earlier this year I had a breakthrough in my self-guided study of the Greek language.

I had been studying “easy Greek readers” for a while, stories written in a limited vocabulary tailored to language students. Then one day on a whim I picked up a serious novel in Greek, actually a translation into Greek of The Vegetarian by Han Kang, the 2024 Nobel prize winner from South Korea. I discovered that even though I knew as few as 50% of the words in a sentence I was able to follow along just fine, if I looked up some of the words that seemed crucial to understanding the gist of the sentence.

I started reading the book with my phone sitting next to it, translating unknown words with DeepL (which is slightly better at Greek than Google Translate) and capturing useful ones in the flashcard app Anki for later spaced repetition.

I soon threw those dumb “easy readers” in the bin. Even if it was slow going, sometimes just a few sentences a day, literature with depth and adult themes was so much more engaging! It took me several months to get through the whole novel but my vocabulary, reading speed and grasp of the grammar improved dramatically in the process.

This got me thinking about what an ideal foreign language reading experience should be like, and I implemented some of my ideas as Lexiglo during the last two weeks.

Check out Lexiglo

(For the quickest demo choose a language and then click on “Load sample text” in the bottom left.)

The app highlights words based on their frequency — their likelihood to appear in a conversation — and based on your proficiency.

• Words in green are those you may want to look up and train given your proficiency level

• Words in yellow are significantly beyond your proficiency level or just rare, so you probably shouldn’t bother with them

This is a standalone web app because that was the easiest way for me to play around with and demonstrate these ideas. I don’t actually think it has that much value as a standalone user experience. Consider this my suggestion for what should be integrated into existing e-readers like the Kindle.

Some basics of Natural Language Processing

At the core of its backend, Lexiglo assigns each word in a text a metric for how frequently it occurs in a language. I assembled a few standard techniques from the field of Natural Language Processing (NLP) to achieve this.

• Tokenisation identifies individual words in a text. This may sound trivial but it needs attention because of grammatical quirks in different languages. In English, the contraction “we’re” should be recognised as two words, and the “re” should be treated as equivalent to “are” (if we’re going to assign it a word frequency). I rolled my own tokenisation with some language-specific rules.

• Stemming reduces a word to a root, in our case with the goal to treat declinations and variants of a word as equivalent. In English, the noun “boat” and its plural “boats” are clearly the same word for our purposes (they should both reduce to the stem “boat”). But is “boating” a separate word? Context often matters and even then grey areas always exist that stemmers choose to resolve in different ways. I mostly use the stemming from hunspell.

• Word frequency data is compiled by counting words in a large body of text. I chose this free resource derived from TV/movie subtitles. Given the nature of subtitles the data skew towards conversational language which is a great fit for language learning. The secret sauce of Lexiglo (if there is such a thing) is how this raw data is turned into a database for efficient look up.

Just because these techniques are well understood doesn’t mean it’s easy to deploy them in a real-world application. I’m not an NLP expert by any stretch and had limited time, so I simplified and cut corners.

Shout out to one particularly intractable problem that I ended up just not addressing: Named Entity Recognition (NER), or distinguishing proper names from other words. I would like to ignore the names of people, towns, brands, etc. in annotated texts — but I couldn’t see a way to do it reasonably quickly.

In general though, the approach extends easily to all of the top 20-ish languages in the world, even though each new one requires some customisation. The supported languages in Lexiglo now (English, French, German, Italian, Greek) are those in which I’m fluent enough to judge the quality of the output. And quality definitely varies. I’m 90% happy with English and German, where I invested the most time. I’m less happy with Greek because its hunspell stemming was useless and I had to resort to a simplistic stemmer (Snowball). The quality of French and Italian is a bit of an unknown, since I added that in very quickly at the end, with the deadline for this post fast approaching.

Fine, I’ll come clean. It wasn’t me — It was an AI agent that added in French and Italian. There is no AI per se in the backend but I did use AI coding assistance throughout. At this stage there was enough precedent in the codebase for an agent to implement sensible language-specific rules by itself.

How I used AI: VSCode/Copilot out of the box

For this project I somewhat artificially restricted myself to VSCode and its integrated AI features. I knew from the outset I would write all code in TypeScript, for which VSCode is the editor of choice. My sense is also that many developers just learning to code default to it, and I wanted to understand what that experience would be like.

The experience is certainly fundamentally different from what it was just 3 years ago, when the first AI code models were just releasing. At some point during the last year VSCode rebranded as “The open source AI code editor”, a claim I will grant them. Out of the box it emphasises two core AI features:

1. Next edit suggestions: It predicts likely next edits you’d make in the scope of a single file and lets you accept suggestions with the tab key. Under the right conditions you type out a function header and then just hit tab a few times for the implementation of the function to autocomplete.

2. Agent mode: A chat-based interface to an agent that can suggest larger edits across multiple files, sitting in the right-hand sidebar by default.

Both of these features are tightly integrated and intuitive, with essentially no learning curve. By default they are enabled and backed by the free tier of GitHub Copilot, if you’re already logged into your Github account. By the time I hit the usage limit of the free tier I was relying on it so much that I gladly upgraded to Copilot Pro for the price of two mid-market matcha lattes ($10/month).

I would say the “next edit suggestions” increases my net coding speed by some consistent factor, maybe by about 20%. The impact of agent mode is harder to pin down, it can vary a lot case by case. When I prompt an agent for a big change I then still have to comb through the code to ensure it’s really doing what I wanted. Paradoxically, writing code can be faster than reading it.

The Copilot experience shifted my frame of mind while coding in a way that took me by surprise: When a task would have previously required intense focus, would have required me to be in a flow state, I was now able to coast sometimes, only partially paying attention. I was sometimes able to just vibe, as it were.

Agents can be slow (for now); while I’m waiting around for their response I’m forcibly switching context, checking my phone, sipping on the matcha latte, watching that YouTube short, or, in any case, ejecting out of flow state. I have complicated feelings about this shift towards a more distracted or distractible coding. It certainly will make coding more accessible to more people. On the other hand, skills I’ve spent a whole career cultivating — a long attention span, building up execution context in my head, entering and maintaining flow — may lose status.

I have some predictions about what skills may rise in status instead:

• Reading code: Understanding code at a glance has always been remarkably hard but remarkably useful, given the truism that code is written once but read many times over. In a world where you spend most of your day reviewing your agent’s code it becomes a critical skill.

• Decomposition: I’ve gotten the most out of AI models when I prompted them at the right level of abstraction. A good function name at the right level of granularity lends itself to autocompletion. The right size of task given to an agent is more likely to produce usable code.

Interestingly, senior developers would already have been exercising these skills regularly. In most professional settings developers review each other’s code on a daily basis, and they would have acquired a good sense for decomposition from having to write a lot of code by themselves (without AI assistance). I think there’s a possibility that, once the dust settles a bit, benefits from AI accrue to experienced developers moreso than to junior ones.

How do we effectively teach these skills to junior developers just starting out whose default environment is now AI-enabled? I’m not sure because I don’t think they were formally taught to me either.1

What’s still hard

I suspect this will be a recurring section in this newsletter. What remains tedious, time consuming or just plain hard, even with current AI fidelity? Or in other words, where are potential opportunities and market gaps?

Wobbly stack

I wanted to work in an end-to-end TypeScript stack for this because I had never done it before and because I was hoping a consistent language across client and server would let me move the fastest. I settled on Blitz.js as a framework since it promised opinionated defaults for exactly this kind of stack.

Blitz.js builds on Next.js which performs … some kind of magic to bring client and server closer together (do not ask me to explain). Blitz has an RPC layer that further blurs the boundaries between client and server, which in principle I like a lot. Blitz also sets you up with Vite for testing by default.

I believe this is what they call a simple stack. I added the Chakra UI component library myself, everything else comes out of the box with Blitz. To be fair, on paper all of these choices are entirely sensible. In practice, many parts of the stack will have leaky abstractions to some degree, exposing some of the underlying complexity.

At several points I lost a significant amount of time tracking down obscure compatibility issues between Next, Vite and TypeScript. These were obscure issues as in: neither AI nor Google offered me an obvious solution. In one particularly bad case I had to write a custom Vite plugin, just so I could import nodehun, the native hunspell bindings as packaged for node (now memorialised in a gist because I’m surely not the last person with this problem).

A bigger, more durable codebase would simply accumulate solutions for these issues over time and ammortise the cost, but for the purpose of rapid prototyping the hidden complexity of this stack may be a liability.

I don’t have a clear conclusion here. Again, on paper I can’t fault this set up and in principle I like Blitz. Maybe the insight is just that architecture as such remains hard. And if you really look at them closely, the standard architectures of modern web apps are inherently a bit weird and wobbly.

Responsive design

User-friendly design for small phone screens has always been hard — and I don’t think that’s just because I’m not actually a designer (I only play one on TV in this newsletter). Making a design responsive, meaning that it works well both on large and small screens, is extra hard.

In many situations you’re simply forced to reckon with responsiveness as a web developer. If a design isn’t responsive you’re liable to lose either most mobile users or most desktop users. I estimate that 60% of people who click through to the app from this post will be on phones. So I put in the work to retrofit my initial wide-screen design for phones.

This was way too fiddly. I’m still not satisfied with the resulting usability on phones, mainly because the keyboard gets in the way of the core interactions sometimes.

Copilot just wasn’t helping much with this. I partly blame the unusual interaction patterns in the app, for which it likely can’t draw on much prior art. But it also felt as if the code models don’t have a concept of what generated code visually looks like or whether some specific layout of elements would make sense to a user.

It’s not that the code-level frameworks for responsive design are lacking. I used Chakra here and it did everything I needed it to do. But there’s a market for dedicated AI tooling to aid responsive design. I’ll need to try out some of the “AI design” products out there to find out how well they address this already.

Before opening up VSCode again a couple of weeks ago I hadn’t written any serious code for almost 2 years. As a CTO in a fast-growing startup I’d been too absorbed by management and too far removed from ground-level engineering. So I’m coming at the hands-on realities of recent advances in AI with fresh eyes. It’s been illuminating and fun to get back in the game. Subscribe above and come along for the ride.

—Nik