A year has passed since Andrej Karpathy coined the phrase “vibe coding”. He described a new way of coding with AI - sitting back, loosely throwing prompts into Cursor, clicking “Accept All”, barely reading the code. It was provocative, but it captured something real about how AI was changing what it feels like to write software - and even what it means to be a software engineer.

In my own take, I argued we were at the start of a transition from craft coding to vibe coding. The direction of travel seemed inevitable, but the journey would be longer and bumpier than some were promising. AI was great fun for throwaway projects, but not for serious, complex software. Not yet, at least.

This wasn’t a contrarian take. At the time, models struggled with non-trivial problems, and tools like Claude Code and Codex hadn’t even been released. What I didn’t appreciate is that in AI, a year is a very long time.

Inflection point

Something shifted in late 2025. Yes, the models got better. Claude Opus 4.5 and OpenAI’s GPT-5.1-Codex both landed in the final months of 2025, and the jump in capability was significant. But what really caught my attention was watching how developers’ behaviour was changing.

Karpathy himself described going from 80% manual coding to 80% agent coding in the space of a few weeks, calling it “the biggest change in ~2 decades of programming.” And it wasn’t just him. Developers I know or have followed for years - people who’d been cautious about AI, even sceptical - suddenly started talking (a lot) about how they were using Claude Code.

Then along came OpenClaw (previously ClawdBot, then MoltBot). Unless you’ve been living under a rock, you’ve heard of it by now. The open source AI agent platform, built by one developer, Peter Steinberger, went from zero to 100,000 GitHub stars in days, spawned mainstream media coverage, a trademark dispute with Anthropic, and suddenly everyone was talking about it, installing it, breaking things with it. What’s most remarkable is how quickly it happened. Looking at the timeline and the scope of the codebase, you just know this wouldn’t have been possible for one person without AI.

If the early 2025 position was that AI coding worked for toys but not for real engineering, that position is getting harder and harder to defend.

Developer ego

It’s taken me a while to recognise this, but adopting AI isn’t just about new tools and workflows. A big (and understated) part of it is letting go of our ego.

AI code - even today - rarely looks like code that I would write. It’s more verbose, it duplicates things, it has weird patterns that just smell unmistakably of AI. And sometimes it’s worse than that - it’s simply wrong. An agent will get itself into a tangle, “fixing” problems with the wrong solution and digging itself deeper into a hole of its own making.

These limitations are weirdly comforting. They let developers argue we’re still needed. Not just needed - superior. We can look at AI code and think: “I wouldn’t do it like that. My code is better.” And honestly, I think we like being the craftsman and the problem solver. We get fulfilment from it. It’s natural to resist change that threatens to take that away.

I’m not alone in this. Karpathy admitted the shift to agentic coding “hurts the ego a bit.” Eric S. Raymond recently observed that programmers have “a tremendous amount of ego and identity invested in the craft of coding”. A developer on the Stack Overflow podcast compared it to going from “a craftsman whittling a perfect chair” to “a factory manager at Ikea.”

Whether we publicly acknowledge it or not, I think most developers - especially those who’ve been around a while - are going through something that feels like a professional identity crisis. I know I’ve had moments wondering if my career has had its best days. Am I done?

I realised I needed a deliberate shift in how I think about my role. I’ve become far more “vibe coder” than I would have been comfortable admitting a year ago. A more maximalist view where the machines are responsible for writing the code, writing tests, reviewing code, fixing bugs. I don’t read every line of code AI produces - it’s impossible to. But I maintain a high-level understanding of the architecture, just enough to steer the AI. Occasionally, if it gets stuck, I’ll dive in far enough to understand why. I rarely fix a bug directly - I just point the AI in the right direction.

All of this feels uncomfortable. It grates not just against my ego, but against decades of collective wisdom about what good software engineering looks like. But that’s what makes this moment revolutionary - the rules are being rewritten, whether we like it or not.

Making peace with slop

One telltale sign of a developer who’s embraced AI development is their GitHub contributions heatmap suddenly turning to a shade of green that dazzles compared to previous weeks. But all that code - which, let’s be honest, is at best getting a cursory glance from its human committer - raises legitimate questions about quality, maintainability and security.

The slopacolypse is real and it’s happening. The way I’ve come to see it isn’t to worry whether the AI code is sloppy (it is), but to ask what kind of slop actually matters.

There’s one bucket I’d call stylistic slop: verbose code, odd patterns, unnecessary abstractions. Things that offend your sensibilities as a craftsman, but don’t actually break anything. The code works, and it would have taken you weeks to write by hand. Learning to live with this is probably in your interests now.

Then there’s the more dangerous stuff - toxic slop: real security vulnerabilities, exposed APIs, architectural decisions that create genuine risk. This is what matters most, and spotting it in the firehose of code flying at you from all directions is a hard problem that AI engineers need to solve.

OpenClaw illustrates both sides perfectly. It’s proof that one developer with AI can build something that captivates millions of people in a matter of weeks. It’s also a case study in what happens when toxic slop ships at scale. Within weeks of going viral: a critical RCE vulnerability was discovered; over 42,000 control panels were found exposed to the internet; some 386 malicious skills were identified in the ecosystem; and the spinoff site Moltbook - a social network exclusively for AI agents - leaked 1.5 million API keys within days of launching.

OpenClaw is simultaneously the best advert for AI engineering and the strongest argument against it. What I take from this is that the line between “this offends my craftsmanship” and “this is actually wrong” is fuzzy and unclear. We need to focus human judgement where it counts most - on the architecture, the security and the real-world quality of what we ship.

RIP vibe coding

I recognise there’s a bit of snobbery here, but I cringe every time I hear the words “vibe coding”. The term has leaked into wider discourse, and I’ve even heard my normie friends use it. To my mind, it’s become a pejorative - synonymous with low-effort hacks, security-flawed apps, MVPs that fall apart the moment real users turn up.

So I was glad to see Karpathy has effectively retired his own term, proposing “agentic engineering” as a replacement. His point is that the tools have matured past the stage where “vibing” describes what’s actually happening. Addy Osmani makes the same distinction.

Subagents, agent swarms, multi-agent orchestration, concepts like the Ralph Wiggum loop - terms that didn’t exist eighteen months ago - are now common parlance among developers working with AI. It’s still a wild west - pioneers figuring out the best way to do this stuff. But we’ve come a long way from “build me a Flappy Bird clone.”

I don’t have this figured out - none of us do. It’s disorientating realising that the thing you thought you were good at suddenly has a new rulebook. That inner struggle is real, and it won’t be unique to software engineering. It’s just that we got here first.

Inspired by my friend Jordan’s weeknotes blog, I’m trying something new: a monthly collection of thoughts, links, and reflections. Weekly would never last, and honestly I have my doubts about monthly too, but it’s a new year so let’s give it a go.

😱 It’s almost the end of January

• I always get a little positivity boost every new year. There’s something cleansing about getting back into a routine after a week of Christmas, turning a new page, and starting new projects.
• But, January has a habit of kicking any positivity in the balls. It’s cold, wet, dark and miserable. Sometimes there are days when the only outside I see is a 15 minute dog walk that even the dog is unhappy about.
• And oh my god, don’t get me started on the news. Seriously considering a news/social media detox for my sanity.

✨ Shiny new websites

• This website you’re looking at now is a new one. I wrote about it here.
• My consultancy website, Push Code, also got a fresh lick of paint this month. The plan is to keep the business site ultra minimal, more like a business card site, and share more about the work I do over on this site.

💦 Slopacolypse

• Definitely my favourite word of the year so far. Karpathy really does have a knack for capturing the zeitgeist of this era of computing.
• I’m noticing more and more people, who previously I would have described as AI cautious (if not outright sceptical), suddenly espousing AI coding and telling the world about it.
• Definitely feels like we’ve hit some kind of inflection point. Opus 4.5 and GPT-5.2 Codex have made the benefits so compelling that the slop is a price worth paying.
• Talking of slop, someone sent me a pull request for one of the OSS packages I maintain that was very clearly vibe coded and essentially rewrote every single line of code. Please don’t do that.

🤩 Hype-bot

• It was impossible last weekend to use X without being bombarded by a wall of posts proclaiming, “OMG this is INSANE”, or “How I automated my entire life with this one free tool”… they were of course talking about Clawdbot, erm, Moltbot.
• Being as susceptible to clear and obvious overhype as the next man, I immediately downloaded and installed it. Within 30 minutes I had a personal bot I named Claudette, up and running on a free Oracle Cloud VPS. Definitely didn’t see a need to buy a Mac Mini for it. Genuinely, I loved it and had a fun few days playing around.
• For now I would strictly recommend setting this up on a machine you don’t mind fucking up. It’s YOLO mode cranked to 11. I tried to link my Mac via the companion app so Claudette could access my Things via the things-cli. Turned out she didn’t have /opt/homebrew/bin in her $PATH and I caught her messing around with LaunchAgent .plist files to update the $PATH environment variable. I find that both impressive and terrifying in equal measure.
• Over a few days of light experimental use, Claudette was burning about $10 of tokens every single day 😬.
• Clawdbot was a daft name in an obvious brand-infringing kind of way.

🔥 Tailwind drama

• Big web-dev drama of the month was Tailwind letting 75% of it’s dev team go, due to - according to its creator - “the brutal impact AI has had on our business”.
• I love Tailwind and use it in almost every project I start. This is a real shame and I hope they can find a way forward.
• Intuitively, I’ve never felt open source is a particularly solid foundation for a standalone business. I guess by now Tailwind has established itself as too important to not exist. Both Vercel and Google have stepped in to sponsor and if I was a betting man I’d put money on one of them acquiring Tailwind in the coming weeks.

⚔️ Are you yanking my pizzle?

• No more Kingdom Come Deliverance 2 for me - I finally got to the end of the medieval Bohemia-themed RPG last week. Honestly, I think my family are pleased about this.
• I’ve been in love with this game. Despite having its fair share of murder and pillaging, it’s a pretty wholesome and charming game, with a good sense of humour. I found myself fully invested in Henry’s character, and the dynamic between Henry and the other main characters - especially Hans - is superbly written.
• When my other half asked me where I’d like to go on holiday this year, the only place I could think of was, “erm, Bohemia”. And so it is, that’s where we’re going. Jesus Christ be Praised!

I’m not sure where the proverb “the cobbler’s children have no shoes” comes from, or why cobblers specifically get called out, but the irony is universal: people with the skills to make things for themselves often don’t, because they’re too busy making them for everyone else.

I propose a modern equivalent: “The programmer’s website is under construction.”

The last time I launched a site with my name in the domain was, embarrassingly, over 17 years ago. So what you’re looking at right now - my own new website - is the equivalent of a cobbler’s child in a pair of shiny new shoes!

The gap years

Back in 2008 - the last time I launched a website for myself - I blogged regularly about design, development, and whatever nerdy stuff I was excited about that week. But over time, life got busy, client work picked up, and my own site - unloved and neglected - quietly died.

For over a decade, I didn’t have a proper online home. Which is wild for someone who makes a living on the internet. My consultancy, Push Code, has had a few licks of paint, but even that has had periods of neglect, and it’s never been my space. I was active on Twitter (back when it used to be good) but as social networks have slid into the bot-filled, rage-inducing hellholes they are today, I’ve felt more and more digitally homeless.

In 2024 I launched 2point0.ai as a way to get back into writing online. I kept it up for just over a year, posting about AI in development, and it felt good to be writing again. But the focus was too narrow. It was a blog about AI, not a home for everything I do. I realised I needed to go back to basics - a personal website, where I can show off my work, and write about whatever I want.

How I built it

Unlike the proverbial cobbler - whose services must have been in constant demand, judging by the whole child/shoe situation - I’ve been through a period of what you might politely call “in-between opportunities”.

With no client requirements (or clients, for that matter) to worry about, I got started on designing and building this site. No vibe coding - just plain, handcrafted HTML, CSS and JavaScript. Like the good old days.

Under the hood it’s Astro, Tailwind, and a minimal sprinkling of Svelte in a couple of components. I love Astro - it gives you framework conveniences without the framework baggage, while always keeping you close to the web fundamentals. It gets the balance right - you feel like you’re building a website, not an application.

I had some fun with the about page, where I built an interactive chronology that tells my story from a 15-year-old kid onwards, featuring some AI-generated, comic book style images of me through the years (with progressively less hair). The work page covers a mix of client projects, my open source Bitcoin and blockchain work, and recent dabblings in AI tooling.

And then there’s the blog - a place for me to just be. I expect I’ll write about development, the web, AI and other nerdy stuff - but also whatever else I feel like writing about. I’ve migrated a few posts from 2point0.ai, but this is a fresh start: no constraints, no narrow focus - just writing about what interests me.

What’s next

New year, new website. Feels like a good way to start 2026. So what else have I got cooking?

I’ve got a whiteboard with half a dozen rough project ideas - a mix of AI-based apps and products, plus some open source projects I want to take a proper look at. My goal is to ship at least two things in the first half of this year. I also want to get better at AI-assisted coding: finding that elusive balance between letting the agents run with the code and keeping tight control of direction and quality.

I’m also open to new opportunities - contract work or even the right full-time role. If you’re building something interesting and think we might be a good fit, get in touch.

For now though, I’m just happy to have a proper home on the web again. And that those poor children finally have some shoes.

import { Image } from ‘astro:assets’; import crossFaderImg from ’./images/2025/cross-fader.jpg’; import karpathyTweetImg from ’./images/2025/karpathy-vibe-coding.webp’; import jonasTweetImg from ’./images/2025/jonas-probability.webp’; import sahilTweetImg from ’./images/2025/sahil-junior-devs.webp’;

I like to think of myself as an “old-skool” dev - though let’s be honest, that’s just a hip way of saying I’m an old dev that’s been writing code since another millennium.

It wasn’t that long ago that professionals working on the web would describe their work using the language of a “craftsman”. We were digital artisans, building pixel perfect designs, creating delightful digital experiences and shipping hand-crafted code that we were proud of.

These days developers have a new language that captures the zeitgeist of the modern AI engineer: Vibe coding.

Karpathy goes on to describe vibe coding in practice as some kind of slider.

All the way on the left you have programming as it existed ~3 years ago. All the way on the right you have vibe coding.

@karpathy

I like the slider analogy and see this as a transition from craft to vibes. It’s the modern day equivalent of when textile work shifted from a highly skilled craft to an entirely automated process. The transition didn’t occur overnight, but one Spinning Jenny here and a Jacquard Loom there, and the next thing you know the craft of textile working is no more. The march of progress is inexorable, and we’ve seen that transition repeat many times through history.

But where exactly are we on this slider? And if I can stretch the analogy even further, if our slider is a DJ’s cross-fader, are we in for a quick chop, or is this going to be a long fade mix?

Current state of play

I recently spent a few days with a company that are cranking that vibe slider as far as they can. They’re building their own agent tooling that will take a boilerplate app and spec, and use AI to create a fully functioning app in 15 to 30 minutes.

It’s really impressive to watch an agent loop over the spec and iterate on the build step by step. What they’ve built so far is great, and one of their generated apps has been out in the wild for a while and is already generating revenue.

But… their generated apps are still what you might consider (and I’m quoting their CEO here), “shitty little apps”. We’re talking single feature apps - a small database, user auth, a handful of routes and a couple of endpoints. For a competent dev, it’s the kind of thing you could bash out in a day or two.

I can pick other bones too. When the agents struggle with a more complex feature, what they’re typically doing is hand writing the code and wrapping it in a function so the AI-generated code can implement the feature just by calling a function. That’s a totally pragmatic thing to do, but we’re already edging that slider back towards craft coding.

I think what this company is doing is really cool, and their ambition is far greater than shitty little apps. But I mention all this because I think it reflects the messy reality of vibe coding. Anyone who’s used Cursor for anything more complex than a one-shot Flappy Bird clone will know there’s a lot of effort involved in prompting, providing context, and testing and validating outputs. Without a skilled human pulling the strings, the vibes can get ugly, quickly.

Prompting and context challenges

Prompting isn’t just about describing a task or instruction. Agents need to know everything about your codebase in quite a lot of detail. They need to know the stack, the key dependencies, and they need to see lots of examples of how you actually want them to code.

And as a project and its architecture evolves, so too must the prompts and fragments of prompts that your agents depend on. Managing all of this is quite a lot of effort. Being able to prompt clearly and effectively is a skill that not every developer is going to be blessed with. But for vibe coding, it’s an essential.

There are sites popping up for users to share .cursorrules files for different stacks, and some developer tools and libraries are starting to share prompt fragments in their documentation. This is all great to see and does help the vibe coder find their way in all this.

Context management poses another challenge. In principle, agents work better when they are shown the right context at the right time, and not necessarily all the context all the time. Ideally, IDEs would make this just work™, but in practice this is tricky stuff to get right and another messy aspect of vibe coding that developers need to grapple with.

Validation challenges

When we’re writing code ourselves, we inherently validate our work as we go. But with vibe coding, validation becomes a critical challenge that can make or break the entire approach. We can either fly blind, or we can implement robust validation strategies and take advantage of mathematics and probability.

The idea here is if an agent succeeds only 10% of the time, if you run enough of those agents (88 I think, but someone brainier than me can explain the maths), then there’s a 99.9% chance at least one of them succeeds.

All that depends on having good tests and checks in place to determine when an agent gets it right. There’s some low-hanging fruit here: your agents should definitely be seeing your Typescript compile errors and linter warnings for a start.

And then there’s testing. In a vibe coding maximalist world the AI will write the tests too, but for now this is a role for developers whilst they push the vibe slider as far as they’re comfortable with.

UI and UX challenges

If moving the vibe coding slider to the right comes at a cost, by far the greatest cost in my view, is the detrimental effect on quality of design and user experience.

Whilst agents can do a reasonable job throwing components together using frameworks like shadcn and similar, let’s be honest, AI-gen design is always very, very average. We’re talking functional but uninspired layouts, predictable typography and color schemes that you know you’ve seen a thousand times over. It’s bland, generic, just “meh” kinda stuff.

Sometimes that’s fine. If it’s a private or internal project, we can make these kinds of compromises. But for a real, consumer facing, commercial app, I think the vibe coder falls well short of any craft coder with good design chops.

There’s a missing piece here: not just models that have visual understanding, but models that are specifically trained on decades of examples of great design and can review and can improve their own code from a UX point of view.

I’m sure somewhere there are some smart people working on exactly that, but for now I think vibe coders just fundamentally don’t have the tools for doing good design and UX.

The times, they are a changin’

The software engineer, as a role, is well and truly in the mix. You can hear the beat - DJ Vibes is moving that slider from left to right. But I don’t think we’re quite as far into the transition as others seem to think.

Sahil’s post doesn’t really pass the sniff test. Not withstanding the obvious fact that if you don’t have junior devs, then it isn’t long until you don’t have senior devs either, I simply don’t think the tooling and models are ready for this. But as a vision for what a maxed out vibe coding environment looks like… maybe?

I still don’t believe coding is dead, and I don’t believe junior or mid level devs are done for, but I do believe this slide to the right is in play. The role of a developer or software engineer, across all levels, is fundamentally changing. Whilst we can dream of sitting around on beanbags, chatting, and brainstorming while the agents do the coding, the reality is we’re trading writing code for wrestling with prompts, managing context, and writing many, many tests and validators.

Conclusions… any?

The slide from craft to vibes isn’t a clean transition - it’s messy, complex, and full of hard problems that need to be solved - and we’re still very much in the early days of this transition.

The reality is that effective vibe coding today requires a peculiar mix of skills: traditional coding expertise, prompt engineering finesse, and a willingness to test outputs far more vigorously than you’d test your own outputs. It’s less about replacing development skills and more about augmenting them with new tools and approaches.

Just as the industrial revolution was a more gradual transition than the age’s technological advancements suggested - a transition limited by the practical realities of human adaptation - the shift to vibe coding will likely be just as nuanced. The greatest opportunities will come to those who can navigate this gap between AI capability and human readiness.

For now, the slider sits closer to craft than vibes. The future may yet bring Sahil’s vision of developers as spec-writers and AI-wranglers into reality, but the path there isn’t as straight or as short as some might suggest. The beat goes on, the mix continues, and somewhere between craft and vibes, we’ll find our groove.

import { Image } from ‘astro:assets’; import notAnotherOneImg from ’./images/2024/not-another-one.webp’; import agentflowExampleImg from ’./images/2024/agentflow-example.webp’;

I’m very pleased to announce the launch of Agentflow - a powerfully simple AI agent framework.

Agentflow enables developers to create AI workflows that read like documentation but execute like code. By combining natural language with minimal markup, you can compose complex agent behaviours using plain English as your main programming language.

The framework provides all the structure and control you’d expect from traditional programming but is expressed in an intuitive Markdown-based format that puts readability first.

Not another one. Why?

The path to Agentflow began with a simple frustration. I am not a Python developer. Frameworks like CrewAI and LangChain dominate the AI agent space, but I found myself wanting similar tooling using languages I was more comfortable with and that better suited my development style.

I’ve also noticed a trend that many agent frameworks are quite complex and enterprise-focused. I didn’t want to set up servers and infrastructure; I just wanted something lightweight and easy that I could hack around with on my own computer.

Not too many moons ago I shared my work on Shifts, an Elixir-based agent framework inspired by CrewAI. I definitely learnt some lessons building Shifts, but it didn’t feel like I’d nailed it. So, I put it down to think about the problem again.

There’s an old tweet from Andrej Karparthy that simply says, “The hottest new programming language is English”. I love that idea, and it got me thinking… What if we could create a framework that embraces that idea, and puts the human intent front and centre? Rather than bringing prompts into code, could we somehow make the prompts the code? This thinking led directly to what would become Agentflow.

What makes Agentflow different?

From the start, Agentflow embraces natural language as its primary input. Instead of constructing agents with code that contains prompts, with Agentflow you write prompts that contain minimal code. This makes the composition of agents simpler, but more importantly, it puts human intent front and centre of the development process.

Workflows are written using a variation of Markdown similar to MDX (in fact, it uses the MDX parser internally). The result is a format that is as readable as plain text and with enough structure to implement loops, conditional branching and call actions inside the workflow.

Staying true to this text-first philosophy, Agentflow operates entirely through a command-line interface - no GUI required. It’s lightweight and easy to install, with no infrastructure or cloud requirements. You can get everything up and running on your machine in under a minute.

Under the hood, Agentflow is powered by Vercel’s excellent AI SDK. This means baked-in support for any AI provider supported by the SDK (that’s pretty much all of them), and agents can use any third-party tools compatible with AI SDK. The result is a framework that is as capable as it is approachable, whether building simple automations or sophisticated AI-powered workflows.

Looking ahead

Agentflow is still in its early stages and there’s a lot of work ahead. Like any new software, there will be bugs to fix, rough edges to smooth out, and for now the design and APIs are all subject to change as I learn how people use Agentflow out in the wild.

And that’s exactly why I’m releasing Agentflow now. I want to see how people use it, learn from their experiences, and understand what they need. All feedback is valuable at this stage, whether it’s bug reports or feature requests. While there are clear areas for improvement, such as expanding the collection of first-party tools, or thinking carefully about security when users start sharing workflows and actions, the exact direction will be influenced by users’ needs and experiences.

My hope for Agentflow is simple: I want to make it easier for anyone to start experimenting with and building AI agents. Whether you’re an experienced developer or a weekend-only hacker and tinkerer, Agentflow’s JavaScript foundations and natural language programming should feel intuitive and accessible. I’m excited to see what people build with it, how they extend it, and where they take it.

Get building

Ready to try Agentflow? Head over to the Agentflow docs - the getting started guide will walk you through installation and creating and running your first workflow.

For those interested in reporting bugs, getting involved, or just reading the source code, head over to the Agentflow repository on GitHub.

I’m looking forward to seeing what you build with it!

import { Image } from ‘astro:assets’; import assistantPanelImg from ’./images/2024/zed-assistant-panel.webp’; import inlineAssistImg from ’./images/2024/zed-inline-assist.webp’; import workflowImg from ’./images/2024/zed-workflow.webp’;

Developers are unwaveringly loyal when it comes to their choice of code editor. Just ask anyone who’s spent the time and energy needed to master vim… that’s a path they will never turn back from.

For developers, switching code editor is a rare - almost epochal - event. My own journey from Dreamweaver (yep!) to Sublime Text to VS Code is one that played out over 20 years. But recently, with AI becoming an essential part of many developers’ tool kits, a new generation of code editors that place AI front and centre of the developer experience are emerging to shake up the status quo.

Whilst Cursor has been grabbing all the headlines, it is far from the only player in town. Last month, Zed announced Zed AI, its own AI-assisted coding tools packaged within an already impressive code editor.

For the past few weeks I have been using Zed as my daily driver. This article won’t be a full review of Zed, but I will share my experiences and impressions of Zed’s AI features after a month of pretty heavy use. Is this one of those epochal moments? Will I be switching for good? Read on to find out.

What is Zed?

I first came across Zed earlier this year when I noticed a few developers in the Elixir community speaking highly of it. Launched in 2023, Zed is founded by the team who built the GitHub Atom editor. In Zed, they’ve built a fast, modern code editor. It uses its own highly performant rendering engine built with Rust, and Zed has been steadily winning fans by focussing on the developer experience and getting the basics right.

The introduction of AI features adds to Zed’s previous attention to collaborative chat and pair-programming features. I’m unsure if this represents a slight pivot in plan, but either way Zed AI turns Zed from an interesting looking editor that didn’t quite have enough to peel me away from VS Code a few months ago, into an editor that I definitely want to take for a spin now.

Zed AI features

Zed’s AI offering can broadly be split into three main features:

• The assistant panel for chatting with AI about your code.
• The inline assistant for using AI to directly transform your code.
• Slash style assistant commands for injecting additional context into your chats and interactions.

Let’s take a look at each:

Assistant panel

At a glance, the assistant panel looks and feels like every other AI chat interface you’ve ever used. But it’s definitely not quite like any other chat interface. The entire chat - what Zed calls a “context” - is one continuous text file that feels the same as working with any other text file in Zed. You can move the cursor anywhere, work with multiple cursors, use key bindings, and so the process of adding bits of code to your context feels completely natural and seamless.

There is keyboard shortcut (cmd->) for inserting selected text from the main editor into the assistant panel in a fenced code block. There is also a range of slash commands (which we’ll explore a bit further below) for injecting code into your context - for example an entire file or directory of files. These injected elements appear in the assistant panel as a toggle-able element that can be expanded in full or minimised, so your focus can remain on your prompt.

When you’re ready, hitting cmd-enter submits your context and the AI assistant streams a response to the bottom of the context.

One useful side effect of the entire context being an editable buffer of text is that it’s trivial to “rewrite history” by removing or editing previous parts of the conversation. You can fork an entire context by simply copying and pasting the entire thing into a new context and taking the same base conversation in two different directions.

I’m not aware of any other chat UI working quite like this, and so the Zed team deserve some applause here. They’ve nailed the UX, and I find myself wanting to do other, non-coding tasks in Zed (for example, writing drafts for this blog) purely because I love the experience of flipping to and from the assistant panel so much.

Inline assistant

Wherever you can select text - the main editor, the terminal, even the assistant panel - you can invoke the inline assistant and prompt it to directly transform your selected code.

When you invoke the inline assistant (ctrl-enter), if you also have the assistant panel open, that is provided as context in addition to your inline prompt. That’s not totally intuitive, but once you understand that’s the way it works it’s a powerful way to combine a detailed prompt as context with a simple inline instruction.

The transformed code is then presented to you as a diff which you can either accept or reject. You can also use multiple cursors and highlight multiple selections to invoke inline assistant in several places at the same time. I use this all the time for adding doc blocks to functions.

One recipe in the Zed docs for fixing errors is to create a new context in the assistant panel, use the /diagnostics and /terminal commands to inject diagnostics and error logs into the context, select the misbehaving code and use inline assistant to generate a fix. It works wonderfully.

Assistant commands

Within the assistant panel, you can hit forward slash (/) to bring up a list of available commands. These commands effectively inject content from your code or elsewhere in the editor into the current context.

For example, the /diagnostics command will inject any output and warnings from the language server; the /file command allows you to select a file or folder of files to insert into the context; and the /fetch command injects the response of a HTTP request. All the built-in commands are listed in the Zed docs.

If the built-in commands don’t serve all your needs, you can create your own. Well, apparently you can. Documentation is a bit thin here so I haven’t tried to create a custom slash command, but in theory this could be a very powerful way to inject context from other sources, such as documentation, websites and APIs, or other local files.

One command worth special mention is /workflow. If you invoke it and expand the toggle, it reveals a giant system prompt that instructs the LLM to guide the user through a series of stepped changes and respond in a very specific, structured format. The assistant panel then recognises this structure and presents the “steps” with a UI where you can work through the changes step by step.

You can see where they’re going with this. This brings Zed closer to Cursor’s Composer view, where you can work with the assistant iteratively to build out a specific feature or refactor purely through prompting. In my testing, I couldn’t really get /workflow to work reliably. It would produce a multistep workflow which had “step resolution errors”, or some steps would repeat or conflict with previous steps. It’s a promising looking feature, but in practice feels like you need to cross all your fingers and make a sacrifice to the AI gods if you want it to actually work.

What do developers want from AI in code editors?

I know quite a few experienced software developers who are either irrationally anti-AI, or just apathetic towards AI. On the flip side, many younger developers are attracted to the idea of a prompt-driven, no-code software development process - just see all the “How I used Cursor to build this [INSERT APP/GAME] clone in MINUTES” videos doing the rounds on social media.

Needless to say, I think both these takes are missing the mark. The real gains of using AI in software development come from a more nuanced middle ground.

I use AI every single day for things like:

• Thinking through a problem, and comparing and evaluating different high-level solutions.
• Writing enough code to “show me the way” so that I can pick up a pseudo implementation and use it in a way more specific to my code base.
• Fixing errors by sharing the error and the code and letting AI generate the fix.
• Chores like writing unit tests and adding code documentation and annotations.

What I don’t expect or want AI to do is write every single line of code in my app or product. I can’t see how it’s possible for that to happen without myself being so disconnected from the process that I no longer feel I can influence, or be responsible for, the quality (or lack of) of the code. Even if the models get better over time, and I expect they will, I feel this is a misguided aspiration that will result in worse developers, worse code and worse products.

So for now, the flashy, whizz-bang Cursor demos don’t really impress me, and don’t reflect what I’m looking for in an AI coding assistant.

Zed improves the dev experience with balanced AI features

Which brings us back to Zed. How does it really stack up?

First off, before we even start talking about AI, Zed is a solid, modern and very fast code editor that gets the basics right. Being a new editor, it’s not without bugs, but I didn’t come across anything other than minor UX/UI annoyances. It also lacks support for one or two more niche language syntaxes, but all popular languages are well-supported.

Zed’s AI features are refined and thought through. The UX of the assistant panel feels integrated and seamless. Treating the entire chat “context” as one giant text file feels so natural. And when we need to inject context, the built-in slash commands are simple, intuitive and work perfectly.

When you need AI to directly transform your code, the inline assistant works great. Combining the assistant panel with multiple cursors and inline assistants allows for some pretty powerful and efficient workflows.

One thing Zed doesn’t have is AI tab autocompletion. I know some people love it, but I’ve always felt that’s like Russian Roulette coding.

And this is why I say Zed’s AI features feel thought through. Has tab autocomplete been omitted because they just haven’t built it yet, or did they weigh up how much value these features add to the developer experience first? I get the feeling it’s the latter.

I’m sure they will add more AI over time - the /workflow command feels very much like a work in progress, and it will be hard to resist trying to keep up with the more AI-centric approach of Cursor over time. But I hope and trust Zed keep their focus on developers and the developer experience. At the moment, they’re striking the balance well.

Zed’s hosted AI features are powered by Claude and are currently available for free. I presume that won’t always be the case, but there are no details currently on pricing. However, it’s also possible to add your own API keys for whatever AI providers you fancy, including Anthropic. So if and when it becomes a paid service, you should be able to run with your own keys if preferred. This, at least to me, makes it a more attractive prospect than Cursor where the only option is a subscription.

Conclusion

So, after a month of use, are we witnessing the beginning of a new epoch? Is VS Code now destined to gather dust in my dock whilst Zed gets all the attention? The answer is, yes!

I’m genuinely loving using Zed, and the way it’s AI features are designed and integrated feel just right for me and what I wish from AI at this time.

But… here’s the catch. I’ve compared Zed to Cursor a few times in this article, and I’ve poured a bit of scepticism on the whole “I built Notion in minutes” thing… but I’m not being entirely fair here because I’ve not tried Cursor to the extent that I’ve been using Zed this past month.

So, my challenge for October is to put Cursor through its paces too. We will see if it wins me over or changes my view on exactly what kind of AI features I think I need. So stay tuned, subscribe to the feed and follow me on X to be the first to read my Cursor review next month.