We started with models that could reliably generate individual functions with enough hand-holding, and remove some of the drudgery of building software, and ended the year with Opus 4.5 reliably taking on complex tasks, allowing the programmer to focus on higher-level concerns like architecture and dataflow.

Skills made a huge splash because loading information lazily into the context window makes context management much easier.

Context Engineering should have gotten more attention, but I predict it’ll get more of that in 2026 as we’re moving past generating loads of code at high speed.

It’s a Great Time to Be a Builder

While some engineers still lament the fact that LLM-assisted coding – let’s call it agentic engineering – is taking the joy out of programming, and causes skill decay, others are busy building.

As with any tool, the responsibility for good outcomes lies with the user and good tools nudge the user toward good outcomes.

Since LLMs are so flexible, this needs experience and a large number of hours spent interacting with the models.

You need to develop a “feel” for what individual models are good at, where they are going off the rails and what they struggle with.

But once you do, you can focus on the outcomes you create.

You can eliminate the boring parts to get to the interesting parts that let you learn more and hone your skills.

And that in turn allows you to build interesting software that is actually used.

This is difficult if your identity is attached to the process of writing software, and not the process of building products.

Both approaches require placing attention in different places and operator attention is the limiting factor when the LLM can read and write code many times faster than you do.

Coming from the process of writing software side, you want to focus on system architecture, data structures and data modelling. The concepts you are dealing with are mainly technical and LLMs come in handy as sounding boards and typing aids.

Approaching problems from the product side couldn’t be more different: technological choices are relevant only in so far as they allow you to try, validate, and develop new product ideas to see what is worth keeping and what needs to be discarded. The faster you can iterate, the better, and features that have made it through this filter deserve to get more technical attention so that they don’t turn into attention sinks over time.

Now, the more technical expertise you have, the better you can execute on product iteration because you are positioned to make better technical choices, but critically you must still start from the product, not the technology.

A concrete example from Amp: I gave Amp a built-in tool to extract targeted information from media files which was technically very simple but resonated a lot with Amp’s users because it addressed a real pain point. Thinking about technology first when looking for things to build in the product would have made me miss this opportunity.

The New Quality Bar

With LLMs and coding agents ready to take care of the grunt work of launching a new project, the bar for new projects has risen.

Baseline expectations now include:

• developer and agent-friendly documentation,

• a logo,

• a website,

• integration with popular package managers

None of these things are hard but they used to require enough effort to not be worth it for a side project.

Now getting a basic version of any of these done is just a prompt away. Of course, it’s not perfect and needs manual touch ups after the fact, but it’s easy enough to actually ship it now that expectations have changed.

Which brings up the larger point of what even is quality?

The best definition I’ve seen so far was from my time at Toptal:

This simplistic definition skirts around the fact that usually there are multiple parties with different expectations involved, but generally the point holds.

Applied to the systems you are building: how important is what’s under the hood if it meets all expectations and can be discared/rebuilt with a relatively small investment?

Encoding Expectations

The big question to answer in 2026 is how to encode and specify expectations.

Only when expectations toward the software have been stated can we measure quality.

This goes beyond unit and integration tests to encompass metrics from the running system like memory usage, rate of exceptions, average response time.

Personally this nudges me to think that we’ll keep fast unit tests for iterating in the inner loop, and in addition to that get more blackbox tests that operate the system to assert certain qualities.

These tests should make zero assumptions about the implementation and use the application through well-defined interfaces and protocols, written under the assumption that the entire codebase will be burned down and rewritten eventually.

One way to achieve this is to treat testcases as data and have a custom test harness program evaluate them. I’m playing around with this approach in Feather where the same testsuite is used for multiple implementations of the system.

So far it has given me good results: discrepancies are easy to spot, the agent can fix them quickly and I can use known good implementation for creating a golden master of a test case.

The price is the cost of developing the test harness program, which in practice seems to be low, since programs of that type aren’t new or particularly complex.

Rebuilding Foundations

A lot of the software we use carries around properties of the environment in which it was born: React, Angular, and Vue were born at a time when vanilla JavaScript wasn’t particularly capable, browser support of useful features was spotty, and smartphones with embedded browsers were new, just introducing unstable low-bandwidth connections back into the equation.

How would a web framework built in 2025 look like? HTTP/2 brought a much higher simultaneous connection limit, smartphones are ubiquitous and mobile connectivity has improved by leaps and bounds. This allows for a different set of tradeoffs in the design and implementation of the framework, unencumbered by history.

But agentic engineering has lowered the cost of code generation so much, that exploring rebuilding infrastructure on new foundations is feasible:

• what if you built an implementation of your favorite programming language that used WASM as its internal bytecode or sole compilation target?

• what if you built something like Ruby on Rails, Next.js or any other fullstack framework with coding agents in mind, under the assumption that developer won’t be even looking at the code?

• Supabase gives you Postgres through an API call, what if you gave every customer their own database?

• Server-Sent-Events have become mainstream and well-supported, how would building a web-application realtime first look like?

I’m exploring this direction currently by re-implementing TCL in the form of Feather – TCL was created at a time when most applications were written in C and has a great story for embedding it in C.

But today’s applications are different: they provide a lot of the infrastructure that TCL does, like garbage collection and rich datastructures, and having to map back-and-forth in the host language is tedious.

How can we reimagine this so that the embedded language only provides the syntax and semantics, but data, memory and I/O are managed by the host?

And why even care in the first place?

An interactive Read-Eval-Print-Loop (REPL) allows for much faster feedback cycles both for humans and agents, but the options for embedding languages for that purpose are pretty slim.

The models are well-trained in Bash, and TCL has a lot of syntatic and semantic overlap that hopefully this carries over.

Like in this prototype, where the UI is defined through Feather/TCL and can be inspected and changed at runtime, just like in the browser:

What’s Next

My goal for 2026 is to write in general, and especially here. To make this work, I’ve decided to focus on reporting on my active side projects.

The biggest non-Amp projects in the works currently are:

Feather, a tiny programming language for adding interactivity to applications, fully built by coding agents.

And the Decode Estonian Tutor Bot where I explore architecture approaches that sound good in theory, to see whether they are a good fit in practice – like giving every user their own complete instance of the system.

Stay tuned, and have a great start into the New Year!

Intention

Maybe I spent too much time listening to DHH but one point from that interview stuck with me: there is beauty in programming, unfortunately we often forget about it.

Beauty of course is in the eye of the beholder, but simplicity is not.

Over time I’ve come to associate these two notions with the shortest path from intention to execution.

Good tools, including programming languages, libraries, and frameworks make this path as short as possible for the common case, while exposing the necessary knobs and levers to make more veering off that path possible.

I chalk the enduring success of command languages like Bash up to this property.

Nobody wants to type require("fs").unlinkSync("temp.md") when they can type rm temp.md instead.

The rm command does much more than calling unlink(2) under the hood, like supporting removing both files and directories and protecting against accidental destruction with interactive prompts.

All of these features surface on the intention layer of the command: adding -r makes rm remove files recursively, -f turns off any kind of approval prompts.

"I want to remove all files here, don't ask, I'm sure"

becomes simply

"rm -rf ."

Every character is imbued with meaning in this command, there is nothing that can be left off without losing information from the intention.

This is beautiful.

It pushes all of the complexity of achieving a goal into a blackbox you don't need to worry about, unless building that blackbox is your job.

It is abstraction that is so powerful by pulling us away from unnecessary detail.

Finding the right abstractions is hard, and you know when you have found the wrong one when the abstraction actively gets in your way and makes achieving your goal hard.

Ruby on Rails made waves when its latest release included an authentication generator, with DHH half-jokingly proclaiming on stage that he artisanally crafted every line of code of that generator and that core functionality needn't be outsourced to third parties if implementation is easy and you can own the implementation.

And easy it is: rails generate authentication is the shortest path from intention to execution again, creating 15(!) files in your project, in the right places with the right content.

Notably, the generator stops just shy of a full system: your application still needs to create users, and you’ll have to build the signup page.

These “gaps” are key: there a many possible valid solutions to both of these problems, and providing one out of the box is guaranteed to be only sometimes right.

"Should you store cryptographically secure password hashes in your database" on the other hand has only one objectively right answer and is thus included as part of the generated code.

Generating the code and writing it directly into your project gives you a naked abstraction without a protective layer: you can just go ahead and modify the code to your needs. You have the power to do so, with the accompanying responsibility.

It gives you a clear path to ownership.

AI

Agentic coding tools are great when employed for the right purpose.

DHH advocates for asking ChatGPT to learn more about a subject, but actually type out all of the code to learn yourself.

He used this technique to finally learn Bash properly when creating Omarchy, his for-developers Linux distribution.

At first this sounded silly to me.

Kind of like when tailwindcss was new and everyone who learned CSS was scratching their head wondering about how this could possibly be a good idea.

Well, I tried the suggestion in the meantime in an area outside of my expertise and oh boy did it help with learning.

It's the best tutor I didn't know I needed.

Learning and execution are different modes of operation, requiring different approaches.

Having Amp conjure up an executable toy example of a problem I’m trying to understand is a great tool when I'm at a stage of not yet knowing what I want.

It encourages progressively going deeper, until the picture is finally clear in my head.

Clarity about inner workings is essential to developing your own sense of intention.

Clear intention is what enables successful use of agentic coding tools: without knowing what you want, you cannot transfer your intention to the eager code writing machine.

Exchanges with LLMs aren't one-sided and gaps in your intention and understanding are surfaced when you feel unsatisfied with the output generated by state of the art models.

More often than not it's not a shortcoming of the model, but a few critical bits of information missing from the data provided to the model.

TCL

TCL is short for Tool Command Language.

An old version of it is pre-installed on your Mac.

Development started in the late 80s, when the Internet was essentially limited to academia.

A language like TCL is what happens when you make ease of abstraction and meta-programming guiding principles, while still maintaining a simple syntax.

TCL syntax is limited to the bare essentials necessary for expressing intent, and evaluation is delayed until the very last moment.

If you run this in the wish interpreter, you’ll get a native UI window in four lines of text:

wm title . "hello, dear reader"
label .message -text "Hey 👋" -padx 24 -pady 24
pack .message
focus .

This sits very high on the tower of abstraction, and that is what made the language so attractive to me.

For the last four weeks, I’ve been idly playing with it, and it has lured me in deeper and deeper with it’s ability to strip down code to its bare essentials.

In my quest for knowledge, I learned that there is a whole parallel universe running on mostly native code, with a sprinkle of Tcl on top:

• sqlite3 started as a Tcl extension,

• there’s a git-compatible version-control system called Fossil which ships half of GitHub’s features in a 4 MB native binary,

• Tk which makes GUIs like the one above possible is native glue between the operating system’s native widgets and Tcl,

• almost the entire community-provided code just ships with Tcl in the form of tcllib (imagine installing all npm packages alongside node),

• the main source of information is the wiki where information is interspersed with comments from users.

After the initial shock of "this is weird", I noticed that this encourages an engineering culture which:

• values backward compatibility,

• fearlessly relies on the system package manager for dependency management,

• is mindful of performance,

• and encourages narrow-but-deep modules.

The latter is no coincidence, as the author of “A philosophy of Software Design”, the creator of TCL, and the Raft distributed consensus protocol are the same person.

With AI making code generation cheap, especially the formulaic kind that is necessary for creating programming language bindings, this culture and the associated software stack is suddenly viable again.

This raises a couple of questions:

• is generating bindings for libraries a skill that you can get better at, or can this be done fully automatically without much oversight?

• which technologies become viable now that weren’t before? Maybe Ruby is fast enough for more things, when you can easily port over some modules to native code.

• how important are external dependencies when you can get the precise subset of the functionality you need in code you control?

I intend to find out by writing a small command line utility in C with a sprinkling of TCL on top.

Just to see how: how will this feel like?

Maybe it’s good, and we’ve just forgotten.

When I started working with subagents, I first viewed them as a convenience to produce more.

It is easy to tell the model to use many subagents in parallel and then watch your coding agent call N times as many tools in parallel and get a sense of satisfaction from this.

While this is a clear benefit when you already have a plan with easily parallelizable chunks of work like adding new UI components in the frontend and a matching API endpoint in the backend, I found subagents to offer greater value when using them for long sequential tasks.

The key to this is that every subagent gets its own context window.

With a bit of care while prompting the agent in the main conversation, you essentially keep progress information in the main agent context, while small implementation decisions are encapsulated in the subagent context windows.

This “progress overview” in the main conversation helps with keeping the subagents on track and surfaces gaps in your initial prompt - I usually notice this when the subagent made a decision that was not in line with the plan given to the main agent.

Following this process I have gotten 5-10 subagent calls done within the context of one main agent conversation, which for the most part felt like turning the crank of a manual coffee grinder.

The crank-turning prompt usually looks like this:

Study @docs/implementation.md, the plan is X

Where docs/implementation.md describes the general development process and how the input is used:

Study the plan in X.

Find the next incomplete step.

You must ask the user whether this step is correct and you should proceed.

Then, if the plan is correct:

1. Prepare a test for the step

2. Run the test and watch it fail

3. Implement a fix

4. Run the test again

5. If it fails, update the implementation until tests pass

6. When done, report back to the user.

Use a subagent for each step, running the steps in sequence, one at a time.

With this in place, the main conversation mostly looks like this:

Me: Study …

Agent: can I proceed with step X

Me: Yes

Agent: I am done - <long report>.

Me: Commit; Study …

…

I found this process to give good control over results, while increasing the time the agent works independently to multiple minutes before another check-in is required.

Just like water is invisible to fish, so are habits that I’ve built up over the years before agentic coding.

Only last week did I wake up to the fact, that yes, even invisible parts of the process need to be re-examined.

Here are some of the things I found – if you have any to share, I’m all ears!

If you only have one minute, the guiding idea here is this:

tmux for everything

I use tmux for everything I do, because it turns the terminal into a tool more powerful than any desktop application could be – you get:

• infinite scrollback,

• persistent execution environments,

• infinite terminal real-estate,

• easy, global key bindings,

• full automation access to everything.

The thing is, I’ve gotten so used to tmux, that I stopped “seeing” it.

It just became muscle memory, invisible like air.

For a reason I don’t remember, I became aware again of being inside tmux and realized: of course, the agent is not aware! It can’t be!

So telling the agent that it has access to tmux unlocked all of the benefits above for the agent:

• managing long-running processes is not an issue anymore,

• giving it access to the history of failed commands in context allows it to make better decisions going forward,

• execution context/history persist across context windows

If you want to try this out yourself, here is the prompt I use to inform that agent about this:

You are running inside tmux (${SRC}) - from now on, when you need to execute commands, you run them in ${DEST}.

To inspect the output, capture the contents of ${DEST}:

```
# capture visible area
tmux capture-pane -p -S 0 -E -
# capture 200 lines before visible output until the end
tmux capture-pane -p -S -200
```

When using the bash tool, you must run all commands through tmux.

Replace ${SRC} with where the commands should go and ${DEST} with where it’ll find the output (often these will be the same).

For example, if you have one session named x, then setting SRC and DEST to `x:1.1` will run commands in the first pane of the first window in that session, scraping that for the output.

This is similar in spirit to giving the agent access to the browser to inspect the results of frontend code changes – here we just apply the same idea to the terminal.

Next up: finding a remote-control extension for VSCode and testing whether I can use the same trick there.

The ecosystem is too small…

This one bit hard – I found myself opposing a technology, because it looked like it does not have much of an ecosystem around it.

The problem space was well-known: interactive terminal applications, it’s just that in node.js land there aren’t many options to do this well compared to Go and Rust.

So the natural impulse was to “pick the right tool for the job”.

Careful! This is pre-agentic thinking!

Porting over libraries while staying in the same programming paradigm/problem domain is essentially free now.

The cost of porting over e.g. charmbracelet’s ansi terminal library to node.js is minimal - the only challenges to solve are accessing the underlying platform (e.g. Windows) portably, but that too can be handled as a separate problem by an agent.

Once this work has been done, libraries that build on top of that can be ported over…

And so on, until you reach the level of abstraction you were looking for originally.

Of course, this requires skill and practice, but “let’s rewrite X in $LANGUAGE” has rarely been cheap enough to actually follow through.

The crucial bit here which makes this approach work is that you already have an objective definition of correct.

Namely: whatever the library you are porting does, is correct.

This allows the agent to self-correct and iterate toward a solution.

Have you identified any “thinking traps” in your own thinking?

What are they?

If not – where would you look first?

View on Github

Seeing LLMs struggle with file edits sometimes degenerates into this:

Model: let me edit the file to remove comments.

Tool(edit_file): old_str is not present in the file

Model: I see there is an issue with editing the file, let me try again

Tool(edit_file): old_str and new_str must be different

Model: Let me try a different approach

Tool(bash): sed -i "s/\"old_str\\"/new_str" file.go
Unexpected EOF while looking for matching `"'

Model: Let me rewrite the entire file from scratch

This got me thinking – what if instead of `sed` there was a more powerful tool that the LLM could use?

One that is easier to understand.

The desire to get an answer was so strong, I had to get to work right away.

The result is texted, a headless, scriptable text editor meant to be used by LLMs (or you, if you don’t like writing sed scripts).

After 7 hours and $50 in Anthropic credits, the first version came out of the oven and still steaming, I plugged into the Claude Code:

To my surprise: it worked!

I mean, edited a file successfully without reading it more than once – that’s a win already.

But more interestingly, it provided some evidence that LLMs can handle made up languages just fine, which opens up all kind of interesting doors

Designing texted

Quick, what programming language is:

• has been around for 40 years,

• is specialized for text editing,

• and easy on the eyes.

It can’t be Vimscript - on account of not being “easy on the eyes”.

Nor sed.

So that left Emacs Lisp.

Sure, using Emacs as the backend to texted would have been the more capable solution.

But also more cumbersome to integrate, and definitely not something everyone wants to have installed on their machine.

Since code is cheap, I settled on implementing a subset of Emacs Lisp that is not turing-complete to guarantee termination of the edit operations.

All functions implemented by texted follow the elisp functions provided by Emacs, so that the LLM can leverage its existing knowledge.

For funsies, I threw in shell-like syntax which is a bit easier to type, so that:

search-forward "func main"
replace-match "func run"

is the same as writing:

(search-forward "func main")
(replace-match "func run")

And since the world doesn’t run on Lisp 🥲 and we're not implementing an actual programming language, instructions can also be easily serialized as JSON to integrate with other systems:

["search-forward", "func main"]
["replace-match", "func run"]

Guess which format the LLM ended up preferring?

Hint: it’s not S-expressions.

The spec

With these ideas in mind, I wrote a spec.

A rough outline of what I want, why I want it how the pieces fit together.

This is were experience comes into play: I’ve implemented Lisp interpreters before, so I knew what to look for and how to paint in broad strokes:

In fact, the regular texted script parser just uses a specialized reader:

1. Leading whitespace is stripped

2. If the next character is (, read a regular S-expression list, ignoring whitespace between elements.

3. Otherwise build a list reading invoking the reader repeatedly until a single \n is encountered.

If you know about the Lisp reader, the new syntax is easy to describe in terms of the differences to the regular reader.

Otherwise…its more difficult.

Driving Claude mad

With the spec in hand, it was mostly smooth sailing – in projects like this I’m still trying to see how far I can push my process to have LLMs write all of the code.

Here are the parts that needed manual intervention still:

• designing and adjusting expectations in the made-up XML integration tests,

• defining desired behavior in the CLI spec,

• helping it with inconsistent method naming in the Go MCP library I’m using

• designing the code for the pseudo-Lisp implementation

Let’s talk about quality

My definition of quality is this:

Does it meet expectations?

“it” referring to texted here, and “expectations” referring to the expectations of different roles:

• as a user of the software: does it do what it says on the tin?

• as a developer of the software: can I keep evolving it without breaking things?

The current implementation satisfies both.

Yes, the interpreter is far from optimal – more time could make it more performant, the code “cleaner”, and allow implementing more Lisp features.

None of these things are relevant to finding out whether LLMs work better with an LLM-friendly text editor.

What’s next

I’ll be using texted over the next days and weeks to see what needs improvement.

Claude at least seems to be pretty capable at using it, but I can already see that the set of functions provided by texted is not a good fit.

To get the current selection, you need to do something like this:

(buffer-substring (region-beginning) (region-end))

This would be less error-prone and shorter:

(region-text)

There are more such inconsistencies and improvements, and only extended use will uncover them.

LinkedIn is full of posts complaining about vibe-coding creating unmaintainable piles of tech debt.

Twitter frequently features tech failures of non-technical people building products.

The dominant opinion in the public discource around Gen-AI assisted coding is that it’s a shiny toy, creating more problems than it solves, especially dangerous in the hands of untrained individuals.

Let me ask you this: how did your first programming projects look like? How many people saw them and commented on them?

Most professionally established engineers got established professionally in an era where one does not:

• post all their beginner failures online,

• failed beginner projects look like anything a stranger on the internet could understand.

What we’re seeing now is future junior developers, getting their feet wet in the world of programming.

What they are receiving from their potential mentors, established engineers: disdain and ridicule, instead of encouragement.

Every non-techie I’ve talked to or worked with who had tried building something with Loveable or Cursor quickly ran into the limitations of their own knowledge.

They stumble upon this choice:

Should I go deeper?

Most people don’t.

A few will expand their knowledge – ask more questions, get more answers, produce interesting results on the way.

We’ll get more junior developers joining the workforce through vibecoding.

It’s just that beginner projects a whole lot more interesting to look at now, than they used to be.

I mean, how exciting is generating a sales dashboard from a prompt, compared to writing “hello, world” and building up from there?

Not all experience is created equal

For established engineers, the biggest opportunity I see here is getting broad experience, with different kinds of systems.

Have you done all of these?

• Built a local-first web application,

• Built a realtime collaboration system (e.g. multiplayer document editing),

• Built an event-sourced application,

• Built a highly-concurrent all-state-in-memory application,

• Built a framework for others to use,

• Built a library for others to use (and published it),

• Built a system with a REPL to manipulate the system while it’s running,

• Built a system using only AWS basic building blocks, reducing custom code to a minimum,

• Built a cross-platform desktop app,

• Built a system with 100% I/O-free unit tests,

• Built a custom networking protocol, complete with a client and server implementation,

• Built an application around geospatial information,

• …and the list goes on and on.

As a Senior Engineer today, you might have still only done 1-2 of the items on this list.

You're still a Senior Engineer at $WORK.

But your experience definitely isn’t “senior” in all areas.

To collect your XP required finding and joining the right companies and projects to get relevant first-hand experience.

Now you can create smaller versions of all of the items listed above to get a feel for what is hard and what is easy in that context.

What’s the texture of the problems you encounter there?

It’s close to free now, because AI-assisted coding can get you to the starting point, where you can finally experiment appropriately to your experience level much faster.

Even if you start with an established project (e.g. adding a custom command to Redis), AI-assisted coding will help you with onboarding while Antirez is busy implementing vector storage.

Don’t hestitate to add your own vibe-coded projects to the pile of dumpster fires – as long as you are honest about your project’s purpose, you can learn so much now.

Moving forward

Today marks my first day out of Modash.io and the first of 7 days before starting at Sourcegraph to work on Amp - an agentic coder that does not try to protect your wallet, in exchange for better results.

This means that staying abreast of the tectonic plate movements with their associated volcanic erruptions in software development is now my bread and butter.

Things I learn, I’ll share here.

Seven Days of Building

In this 7 day period between two engagements, I have many questions to answer:

Will deterministic building blocks improve LLM performance?

How will an LLM perform, if all actions you want to take in the development of a project are accessible through a CLI / MCP server?

Put the precise bits into deterministic machines, leave the fuzzy bits to the LLM.

I really need to find out and the only way to do so it to build something.

A few more days and I should have something presentable (code is already public, but it’s very much WIP).

What is key to managing multiple agents at the same time?

The agentic software development endgame seems to be managing multiple agents with a lot of input at the beginning of the process, and more at the end, with the agent quietly chugging away and working its way through the problem.

Right now it still requires oversight, and I’m trying to figure out how to best manage that process for the time being.

Yesterday was a success by leveraging extensive plans, git worktrees and tmux to run two instances of the Amp CLI.

I could work through two big features in parallel, generating around 5000 lines of code in the process.

Half of that was essentially what I would have written, the other half needed more babysitting because I wasn’t clear enough in my specification.

What constitutes a good test?

My notion of test quality is changing – I’m relying more and more on end-to-end test, exercising the application fully (which is easy for my toy projects) so that the LLM gets the necessary context to figure out what’s wrong.

The issue with e2e tests is finding out what’s wrong exactly, when things go wrong.

But with LLMs in your toolbox, this is less of an issue now - they excel at reading logs and analyzing root causes of failures.

So I find myself building more and more little helper programs that poke, prod and exercise a system in an LLM friendly manner.

I call these things “inspectors” because of what they do – the notable difference to e2e tests is that you can point them at any instance of the system.

They are not built using test frameworks, because they are not tests, they are tools.

Mind you, this is in addition to regular unit and integration tests.

Observations so far

When I get a new computer, I like to set up things from scratch to only select things as part of my workflow that make sense.

Here’s what I’ve learned in the process:

• I write lots of tiny custom utilities now, in Go, because it has become so easy. These tools cater to my preferences, like this URL opener for tmux.

• I learn more – the threshold to action has lowered so much, that I do more as a result. For example, I’d like better Finder integration for Markdown and JSON files – they should automatically open in a new terminal window with a dedicated program (e.g. nvim). Turns out that’s easy to do, but only thanks to LLMs I bothered to find out exactly how to do it.

• My notion of quality is changing more towards evaluating constructs as black boxes – I care more about how the cake tastes than about how it’s made.

That’s it for today, more content is on the way!

It really doesn’t take long.

This post is not about agents being essentially simple while loops.

No, this is about what happens after.

Because with the simple toolbox given to you by Thorsten you now have a self-modifying agent.

Let me repeat that: with three tools, the agent can modify itself.

You can grow the agent into one you like to use.

Unlike Cursor, it can be yours.

You can experiment freely.

And most importantly, you understand, on a deep level, what’s actually going on under the hood.

My goal with this project was to see how far I can push developing the agent developing itself into a more an more capable version of itself.

But first things first: if you want to play or read along, the code is here:

https://github.com/dhamidi/smolcode

Mind you, this is a messy construction zone, not a pristine temple of software engineering best practices.

⚠️ Warning: the following is raw, messy, unedited and unscripted.

Watch smolcode cleaning up messy workspace files and highlight a bug with my implementation of caching prompts:

The point of this is not to impress you, but to get you to build your own.

Building your own allows you play around with all kinds of things, just look at all these tools:

On top of the original read_file, list_files, and edit_file we have:

• create_checkpoint for writing detailed commit messages based on changed files as reported by list_changes

• create_memory and recall_memory to remember things about the project (e.g. the build command)

• manage_plan for making plans, reordering tasks, etc without needing to mess around with markdown files

• and finally write_file because sometimes Gemini is failing hard at replacing strings in files.

That’s more than enough to get a working agent.

Since demos are few and far between, let’s debug the caching issue – notice how Gemini repeated that it “already removed files” and “already committed” changes.

That’s because I’m using prompt caching, and most likely I’m using it wrong.

Let’s run a simple conversation with tracing enabled to get more intel:

Now I could analyze this myself to answer the question whether there’s an issue with cached requests sending duplicate prompts, but where'd be the fun in that?

After copying the contents of the interaction to `transcript.txt`, let’s ask smolcode to reflect on its nature:

Here’s the outcome of the analysis:

Therefore, I do not see evidence that the *same user input* is being sent and processed twice *within the same turn*. The transcript shows that the full conversation history, including previous user prompts, is sent with each new request, but the latest user prompt is unique in that request.

This is good enough for now to continue experimenting without worrying too much about caching.

How to work with an unleashed model?

Cursor is doing all kinds of things behind the scenes to reduce/distill the amount of context that is sent to the model.

Smolcode embraces the model and is eager to burn through tokens.

How does the workflow change?

In an ideal world, an interaction with smolcode looks like this:

You: Study instruction.md
Gemini: Here's my plan ...
Tool: read_file
Tool: read_file
Tool: edit_file
Tool: edit_file
Tool: create_checkpoint
Gemini: I'm done
You: 

What’s interesting here is that after giving it the initial prompt (here in instruction.md), it just goes off on its own until it thinks its done.

Meaning we get to do other things in the meantime, like managing another instance of the agent.

Let’s build a feature

Now let’s ask smolcode to build a feature that we need: persistent conversation histories.

We’ll start by drafting a specification together with smolcode and then in a separate conversation, we’ll turn it into an executable plan and execute the plan.

Since the session is rather long, here are some highlights:

• the detailed instructions paid off and the model actually produced a workable plan for persisting conversation histories

• while it was busy implementing the plan, I got bored and thought about the next problem: how are we actually going to use the history?

• to that end, I started a new session in another tmux pane to make a new plan for integrating the history with the agent

• intermittently we ran into rate-limits / opaque internal errors that we just had to sit out with retries,

• Gemini messed up with editing the history_test.go file and goimports couldn’t format it. It got itself out of that predicament.

🥂 Cheers to uncertainty

At this point I have no clue what we just built.

Or how whether it works.

I could review the code now, but since I expect it to change yet again, I’ll delay my review.

Instead, let’s throw more tokens at it and ask the agent to figure this out.

The outcome: we have the history package but are not using it in the agent

The reaction: ask the agent to plan the integration.

But first it needs to fix the tests:

Now that the tests are working, we can continue with the integration.

Except that the tests aren’t working the way we think.

Running the tests actually overwrites the database file used by smolcode for storing history, because the initially envisoned API had no notion of multiple database files.

This is fixed off-screen in the same manner as we’ve done so far.

Time for a review

It worked 🎉

The code we ended up with is pretty straightforward, thanks to a thoughtful first prompt.

A few comments were superficial, but we could let the agent take care of that.

Where next

If you have made it this far, then here are few ideas of where this agent can go:

• evolve `write_file` into a `generate_code` tool, using a different model,

• give the model access to Perplexity’s web search API to get up to date information about frameworks and libraries,

• create a `tmux` tool that allows the model to manage multiple interactive programs

All of these tools are just example of interesting questions to ask.

The answers need to be found through experimentation.

Why would you ever leave Slack?

Take a moment to think about it.

You are on Slack most of the day, communicating with your teammates and the rest of your company.

You gather information.

You synthesize it.

And then you convert it into concrete actions.

Over and over again.

There are only two reasons to leave Slack:

• the information you are looking for is not reachable through Slack,

• the action you want to take is not exposed in Slack.

Critically, taking an action outside of Slack creates follow-up work: you now need to inform your team about the action you have taken to prevent double-work and miscommunication.

For long-lived complicated actions, like writing code or longer documents, Slack is of course not a suitable tool.

But the average workday is full of smaller actions – querying disparate sources of data, nudging people, following up on tasks.

Why can’t these actions be taken in Slack?

Why can’t you just ask in your team’s channel whether task XYZ is done, and someone will go to Jira, read through the task’s history, find mentions of the task in Slack and emails and gives your entire team a summary?

Why can’t you ask “which pull requests have been in review for too long?” – and follow up with “ping the reviewers please”.

Why can’t you schedule a calendar meeting directly in Slack, at a suitable time slot referring to your team mate by their first name?

The future is here already…

All of these things are technically possible already.

In fact, they have been possible for over a year already.

Giving ChatGPT hands doesn’t even require writing code, yet nobody uses this functionality, and only few people know about it.

Only in the area of writing code, we’re seeing a strong move to conversational interfaces and agentic workflows, interacting closely with a coding agent, and giving the agent more and more hands to do more and more work for us.

Connecting everything to Slack means we can re-use the multi-modal conversational UI built and polished over the years by Slack.

Everyone has access to Slack.

It’s literally just about plugging in everything.

…but not evenly distributed

This literal plugging is unfortunately only accessible to highly technical folks.

However, just last week Anthropic announced that MCP servers can now be plugged directly in Claude on the web.

A great step forward.

However this is still limited – most people don’t spend their days in Claude.

I doubt that people ever will, because “Let me use Claude” is a specialized usecase currently as opposed to “Let me exist” which is what a company’s chat tool boils down to.

Redistributing

I expect that these integrations will get built over the next two to three years.

And that exposing your services through MCP or whatever will be the dominant protocol then will be expected of your product.

The crucial questions to answer here are:

• how do you change your UI/UX if you now only expect power users to use a specialized UI for your product?

• how do you design UX around performing actions on the user’s behalf in another platform?

• how do you manage context in environments like Slack?

Now if you think about it a bit more, you will find that you are already using many different conversational interfaces.

Here are the ones I can come up with:

• Your main messaging app (e.g. WhatsApp or Telegram),

• Your secondary messaging app because not all of your friends are on the first

• Your work email inbox

• Your private email inbox

• Slack or Teams for work communications

• If you work in a customer facing role: your CRM.

All of these interfaces already exist.

And they all are waiting for a capable pair of hands.

From scalpels to self-driving cars

Last time we looked into aider, a precise and powerful tool for writing code.

Unlike Cursor, Cline, and others, Aider has a tight, pre-scripted control loop, which includes you – the human operator.

In a way, Aider is like a scalpel – a sharp tool, excellent for precise cuts.

If you know exactly what you need to do, this magic scalpel can do it much faster than you could do it yourself.

Contrast this with agentic coding environments like Cursor.

They don’t have a pre-scripted top-level loop.

Instead, the model decides on the fly, what it should do next.

You still need a rough idea of where you want to go.

But the “how” is taken care of by the agent.

Like a self-driving a car – you give it the destination and then supervise the process of actually reaching the destination.

Drawing a map

Using agentic coding tools daily now, here is what works best in my experience.

Define the “what”

First, you define the “what” by creating a specification of the desired outcome.

You don’t need to write this yourself.

Use an agent to iterate on a Markdown file until the outcome is crystal clear.

In this phase, you want to:

• seed conversations with all relevant context,

• get the agent to ask you questions about the design,

• and end up with a very detailed spec.

Example: a large scale refactoring

Here is an example from Petrock, a web framework I’m writing at the moment.

View spec

Define the how

Once you are done with the spec, it’s time to turn it into a series of concrete steps.

Again, this will take multiple iterations, so tell your agent to work with you on the plan Markdown file.

We’re still not writing code.

You should seed the context with the specification from earlier and relevant bits about code that the specification touches upon.

Use your agent to help you here.

What makes a plan good

A good plan has:

• clear identifiers for tasks,

• a definition of done for each task,

• references to relevant parts of the code for each task,

• and examples of patterns you want to see respected.

If you include all of this information, the agent will be able to work through the plan step by step with little oversight.

Here’s the plan for implementing the specification above:

View plan

Taking off

With everything in place, you can finally take off.

Here’s the prompt I use to start the agent:

Implement the plan, task by task:

1. pick the next unfinished task
2. implement it
3. mark the task as DONE in the plan file
4. commit the changes, including the plan file.
5. Ask the user whether you should continue

Only implement one task at a time.

This is essentially the same loop that Aider is using, except that we don’t have to hardcode it, but just need to tell the agent.

At this point it’s almost becoming like a video game:

1. the agent implements a change,

2. you check quickly whether it’s deviating from the plan (usually it’s not)

3. you say “continue”

And then you keep turning the crank until you reach the end of the plan.

Orienting yourself

Naturally, the first question is “but what about reviewing the code?”.

Yes, reviewing the code is important.

But more important are the general direction and approach you are taking when making a large-scale change.

By now you will have reached a destination:

• the plan is executed,

• you have a documented history of all changes in git

This is a good time to reorient yourself: is this the place you want to be in?

If it’s not, you have two choices:

• make small adjustments (your almost where you need to be),

• or go through the spec-plan-execute process again for larger changes.

In any case, a little bit of planning allows you to go much faster.

Concrete examples

You can find the entire conversation for implementing the refactoring here.

After the agent was done, I had a lot of compilation errors left, which got fixed here.

The agent was working through this refactoring in 45 minutes while I was writing this blog post.

You can stop reading now and check out aider.

No really, go check their website or, even better, play around with it yourself.

What is aider?

At its core, aider runs in your terminal, reads prompts from you, and changes files in return.

The screenshot at the beginning of the article shows the entire 78 lines of Python code necessary for this.

Well, that’s how it started.

Over the last ~2 years, it got a whole range of features:

• linting,

• testing,

• voice input,

• token analysis

and much more.

How is it different from Cursor?

What’s notably absent compared to Cursor:

• no tool calls,

• no MCP support,

• no behind-the-scenes “we manage the context for you” magic

• no tool use prompts

You see, Aider does something special: it essentially encodes the higher-level feedback loop that you go through when developing software:

1. write code,

2. write tests (or write tests first if that’s your cup of tea),

3. run linters and formatters,

4. run tests,

5. repeat until tests pass

We only need the LLM for step 1 and 2.

Cursor is your virtual pair programming buddy.

Aider is a sharp knife in comparison.

Why does it matter?

A while ago, I wondered whether I needed to encode this high-level feedback loop myself by writing an agent:

Now I know that I don’t – Aider is the program I would have written.

This command invokes aider in a Python repository with the linter and tester preconfigured.

As a result, the LLM does not have to figure out how to run the tests.

When you use Cursor, the LLM needs to think to get the idea that maybe now is a good time to run the tests – aider does this automatically, which makes the process much faster and cheaper, because you save on LLM requests.

Just look at this – this prompt:

> Write a comprehensive test suite in test.py for a function that declines an Estonian noun when provided with the four base forms of a noun as an array: nominative singular, genitive singular, partitive singular, partitive plural.

Yielded lines and lines of code:

Okay, I will write a comprehensive test suite for the Estonian noun declension function in test.py. This suite will use pytest and include tests for various noun types and all 14 grammatical cases in singular and plural.

Since the function decline_noun doesn't exist yet in main.py, these tests are expected to fail until the function is implemented.

Here is the SEARCH/REPLACE block to populate test.py:

Note last bit: Here is the SEARCH/REPLACE block

Aider asks the LLM to provide diffs and then parses the response to figure out what replacements to make. It’s super primitive compared to tool calling, but it also means you don’t need to wait around for tool calls with the associated back-and-forth communication between your client and the LLM provider.

And now the icing on the cake:

You can see that it:

1. automatically committed the changes,

2. ran the linter (“All checks passed”)

3. and is ready for you to run the tests

If you hit enter, it runs the tests and asks you whether you want the output in your context window:

In this case, I don’t, because I messed up the pytest integration, and pytest doesn’t pick up the newly generated test file automatically.

Fixing this was again easy:

Aider commits all changes automatically, as checkpoints so going back to a prior version is easy.

If you make changes outside of aider running /commit will commit them to git with a message following conventional commits.

On slowness

After using Aider extensively for a side project, together with Gemini’s humongous context window, going back to Cursor feels so strange.

Cursor is great at cranking out code without oversight, i.e. it doesn’t “wait” for you to take a turn unless you tell it to.

Which on one hand means you're “faster” because you can twiddle your thumbs while Cursor is working hard.

With Cursor, you wait on the order of minutes before your input is required.

Aider, on the other hand, will be busy on its own for 60 seconds at most.

You stay engaged.

You keep evaluating and feeding it input.

So far, my impression is that I can go faster that way – I’m not waiting for the LLM to come up with obvious things.

My workflow right now

With LLMs I treat planning documents as code, so the first part of working on anything is “coding up a plan”.

I add all relevant design documents from docs to the context with /add docs.

Then I ask for the feature, and specifically a plan for implementing it.

Each step of the plan needs to include:

• a definition of done,

• names of files/function signatures that the model would touch

Aider writes that plan directly into `docs/plan-<feature>.md`

Then I take that plan, add it to the context together with the files we’ll be working on.

From that point on, my job is to turn the crank:

Implement step 1 of the plan, and mark it as done in the plan document.

⏳ aider is busy working, I’m glancing over the code as it swooshes through the terminal.

It then runs the linter automatically, and depending on whether I need it or not, I ask it to run the tests with /test.

Then I keep turning the crank:

Continue

The process repeats until we’re done with executing the plan.

For larger features, I check out a separate branch because Aider commits are very granular.

Is Cursor useful without rules?

One of the questions to which I wanted to find an answer was whether simple prose rules are enough for getting good results out of Cursor.

The promise of simple prose rules is that:

• they are portable and not tied to a specific tool,

• they are written in an understandable format and can be edited by hand

To answer this question I set out ot write a small project from scratch – or rather, have Cursor write it for me.

The rules of the game

I really only set two rules for myself:

1. No artisanal code – I’m not allowed to commit any code written by hand – all committed code needs to be written by the agent

2. No Cursor rules – Recurring mistakes need to be encoded in rules written in docs/tech.md

This way I hoped the experiment would give me a better understanding of the limits of LLMs and coding agents.

The result

First of all – I got working software!

It meets the criteria set out in the initial specification.

I’ve delayed writing a project like this multiple times, because “having to figure out OAuth with Gmail” was enough of a hurdle for me to never overcome.

Cursor mostly stuck to my rules, despite them just being in a Markdown file.

The one it broke consistently: “no mocking” – it ended up using Python’s MagicMock in a bunch of situations to stub out interactions with Gmail.

The process

Writing the software felt like turning a crank:

1. Open plan, copy LLM-generated LLM prompt,

2. Set up context for Cursor in Agent mode,

3. Submit

4. Do something else

5. Check in later – the agent reached a stable state, ask it to commit the changes

Occasionally I’d run the tool to verify everything works in a non-test environment, run into issues, and have Cursor fix them.

Tweaks discovered along the way

Bake rules into the prompt

Compare these two prompts:

Review the Gmail CLI codebase for quality and consistency. Run 'uv run pyright' for type checking, 'uv run ruff check --fix' for linting, and 'uv run ruff format' for code formatting. Check that: 1) Type hints are used everywhere with no Any types, 2) Error handling uses custom exception hierarchies defined in errors.py, 3) Code follows dependency injection over global state, 4) All business logic has unit tests, 5) All I/O operations use async/await. Fix any issues found to meet these technical guidelines.

And:

The first one is generic and short, the second one very detailed.

When I asked the LLM for a specific plan, I also asked it to include prompts like the first one.

Usually I’d go ahead and just paste them directly, and it worked out well enough.

I’ve noticed that these prompts actually reflect the guidelines set out in the tech document nicely.

Towards the end, I wanted to get more out of this, so I just selected a prompt in the plan document, and asked Cursor to make it more detailed based on the development guidelines.

The longer prompt worked better, because it was more specific.

In hindsight I should have done this for every prompt.

Save your prompts

I would find myself asking essentially the same question multiple times, and after doing this a couple of times, I started to commit prompts to the repository.

These prompts correspond to tasks I need to perform regularly:

• fix newly introduced test failures,

• make sure user-facing documentation actually reflects the code,

• test adherence to coding standards.

Keeping these prompts close by in the repository made it easy to perform these tasks more frequently and especially when fixing test failures, the model would sometimes prefer mypy over pyright for type-checking.

Since the “fix the tests” prompt explicitly mentions which tools to use, the LLM doesn’t pick the wrong tool anymore.

Next steps

This was a small project, using essentially too few rules.

Going forward, I want to introduce more rules (~50 to 100 would be good) and see how it affects performance of the LLM – will it make fewer mistakes?

Until then, have fun reading the code.

read-my-mail on Github

Unfortunately, this is very often the key to making lasting improvements in your life.

If you have spent any time around experienced software developers, you’ll hear a lot of comments like this about using LLMs for coding:

They are useless – they make up functions left and right.

The code is terrible – buggy, slow, and hard to read.

It can’t work in a real codebase – it gets confused all the time.

I held the same opinions, actually.

But seeing more and more people out-shipping me (you know, with actually completed projects – even if they are small), got me worried.

And worry grew into despair.

Until I stumbled over Geoffrey Huntley’s article about leveraging Cursor.

You can teach the machine to get better?

The rate of improvement will increase?

Wow, that actually sounds exciting!

This rekindled the excitement that got me into programming in the first place.

Fast feedback loops, a steady stream of achievements delivered to your brain.

But now the level on which these achievements happen has changed.

Achievements, high and low

Accepting The New Way of developing software, I’ve found two things to be great sources of a sense of achievement and wonder:

• getting better at steering models – “wow, it wrote code for 5 minutes without me watching, and I got a working solution”.

• iterating on useful results, fast – the unit of work is now the completed, usable feature, not some kind of abstract programming artifact.

Here’s an example of the former:

This Cursor is generating multiple rules for itself, after I asked to generate one.

I provided enough of the right context so that it actually figured out what we wanted to achieve, so it proactively provided solutions 🤯

Seeing this created a euphoric feeling!

It’s the same dopamine rush as regular programming, just the source is different.

That’s cool, but I still don’t get good results

Neither did I for a long time!

What changed:

• I started to visualize working with the LLM as working with a fresh hire,

• they have zero context of what’s going on: what is the business about, what problems are urgent, how does the codebase look like, etc.

• they are happy to learn and adjust their behavior to how things work around here.

Providing the right context is crucial.

For inspiration look here.

I’ll post more of my own workflows soon.

The point is: you need to experiment and learn.

Nobody has “figured it all out” yet.

Only practice can teach you.

You are your own obstacle

And that’s why the responsibility for results lies with you.

Too much context for the LLM to consider?

Maybe you don’t know the domain well-enough.

Or the codebase isn’t structured well enough to limit the necessary context.

The LLM can’t work its way out of a tricky situation?

I once had the LLM get stuck on working with multiple nested async context managers in Python.

I couldn’t help it out of that situation because I wasn’t familiar enough with that particular corner of Python.

Had I been, I could have guided it to the right solution.

Too many hallucinations – it’s building a house of cards!

Mmh, looks like you don’t have practical tests or other ways to give the LLM quick, automated feedback to arrive at a solution.

What’s next?

Experiment.

Learn.

Iterate.

If you don’t have a side-project you are working on, it is high time by now.

Practical experience is hard currency right now

What’s fun about coding with LLMs right now is that literally nobody knows anything right now.

The few people who know a few things will find that their knowledge can change overnight with the release of a new model or a new version of the AI tooling.

This is great!

The only currency that counts right now is experience.

And getting experience is accessible to everyone.

I have been and still am actively trying to hit the limits when working with Cursor and Sonnet 3.7.

An important part of that is asking the right questions.

Here are mine.

Are simple prose rules enough?

I’m getting good leverage – fewer mistakes – from Cursor rules, written in their undocumented format, generated by Cursor itself.

Making sure the right rules end up in the context window is often tricky, but not unmanageable.

What I need to try: would a simple markdown file with instructions, explicitly included in the context, yield better or worse results when coding with an AI?

This would make the rules independent of a concrete environment like Cursor or Windsurf.

What would happen if I encoded all rules in the linter?

Rules encode a request or wish for the LLM to do the right thing.

Would I get better results by writing a project-specific linter that enforces every rules, thus providing a closed feedback loop to the LLM?

How would I approach process-related rules, like writing tests first? My hunch is that to create a notion of first, there needs to be a notion of before and after.

Leveraging git history or planning documents for this comes to mind.

When is the feedback loop fast enough?

I’ve used Plan-Implement-Test cycles successfully in an existing large project (~10000 files, multiple backend services, large frontend codebase) to implement well-scoped changes

But the feedback loop is terribly slow (multiple seconds to run IO-less tests).

What if I write my next project in such a way that the feedback loop stays under 1s for component: for running all kinds of static checks, compilation, tests, etc

Would being this fast get me better results?

Can I script the high-level development flow?

Over and over I find myself in the same loop:

1. Draft specification with the AI,

2. Convert the specification into a step-by-step plan according to the project rules,

3. Ask the LLM to code up the first step

4. Verify result using tests – keep doing this until all tests pass

5. Mark plan item as completed and move to the next plan item

To what degree is automation possible here?

Do I need to code my own agent?

Is a command line tool enough to make this process smoother?

Do I need to write a VSCode extension for this and load it into Cursor?

Should I express expectations with code-samples?

Often I tell the LLM what I want in English and I get working results.

Sometimes I learn something new about the technology I’m using.

At other times, I find the result hard to relate to and understand.

Would I get code that’s easier to keep in my head if I prompted it with concrete code example, e.g. function signatures without an implementation?

The promised land

This list of questions is not exhaustive and finding answers to all of this is a lot of work.

What is the motivation behind this?

Why dig deeper?

Because the end goal is compelling – the machine chugging away with little oversight, until it hits a stable state, freeing up my time to refine the execution plan.

And then, in the next step, running two of these busy workers, then three, then four, until I manage an entire “team”.

The last four weeks have been tumultuous, as I crossed a particularly important chasm.

I came to accept that software development as we know it is gone.

Not yet for all, but eventually for almost everybody.

As somebody who took pride in fundamentally understanding the tools I use every day, getting proficient and effective at using Emacs, and Vim, and the whole array of low-level UNIX tools like Make, this was a bitter pill to swallow.

LLMs have become so good at writing code – if you just “hold them right” – that none of the things I valued are relevant for the creation of end-user products, to any significant degree.

This requires an identity shift – mastery of the craft is not relevant, when the craft itself becomes irrelevant.

Sharp knives not a kitchen make

Why get really good at forging and smithing kitchen knives when you can just buy one and move on with the task of making food?

Sometimes it is fun to create objects for yourself.

The process sure is enjoyable.

You learn a lot.

But when starting a restaurant, you wouldn’t hire someone to forge bespoke knives for your restaurant.

You wouldn’t burden your chefs with that.

No, ideally your chefs are free to focus on what matters:

• picking high quality ingredients,

• establishing processes that enable effective collaboration in the kitchen,

• devising new signature dishes that set your restaurant apart from others.

While the restaurant business has solved this problem over a century ago, programming is going through a similar transition only now.

The programming world up until recently was a world of knife-forging.

Your business needs a website that’s tightly integrated with your business processes?

Time to hire a team of software-smiths, creating bespoke software for you.

Every single time, for every single business.

None of this matters anymore to the degree of economic relevance.

Old questions, new answers

What programming language should you use?

Old me: it’d be amazing to write more code in Common Lisp – live-reloading everything! Performant, but also dynamic! I’ll settle with Ruby (an acceptable substitute), or Go for now (when performance matters). JavaScript – I’ll write it begrudgingly, because it’s needed.

New me: The one that allows you to do what you need, and can be easily written by LLMs.

What editor/IDE should I use?

Old me: let’s learn Emacs – I can program it exactly to my liking! Vim has such an interesting approach to text editing, let me learn that too. Finally, with LSPs I can bring IDE-like features to any editor!

New me: The one that allows you to monitor, instruct, and manage coding agents the easiest. Today this is Cursor, but it really doesn’t matter.

This code “feels bad” – I need to rewrite it

Old me: what even makes code “good”? Can I list the traits? Let me rewrite this piece of code five times until I arrive at something that “feels right”. Now I only need to convince my team that this is better.

New me: The LLM does not have feelings – if it passes the tests and you can understand what’s going on, then probably the code is good enough.

What’s next

I feel like I’m constrained by time – I want to drive Cursor harder, faster, more, further.

When it works, the experience is magical: the machine writes working code and while it does that, I plan out the next step.

The challenge is getting good enough at instructing the machine so that it’ll get it right 99% of the time and doesn’t require baby-sitting anymore.

That’s called Prompt Engineering.

Deliberate practice, eliminated deliberately

People like to take the path of least resistance whenever one presents itself.

Programming after the growing immediate usefulness of AI coding assistants is no different.

Why struggle through understanding a problem deeply, carefully developing a solution, and ultimately having to maintain something yourself,

When the alternative is to literally just hit the “TAB” key?

The appearance of the “solve my problem, right now” button is a new form of instant gratification, now in the field of programming.

Using this tool is a choice and a deliberate one at that.

However, each time you do, it’s a trade-off.

A deal with the devil.

Solve your immediate problem right now, but don’t learn anything new, nor practice anything familiar.

It’s convenient, it makes you feel good.

It even allows you to ship things faster.

But it also makes your skills trophy.

Steve Jobs envisioned computers as “bicycles for the mind”.

AI coding assistants are “cars for the mind”.

They take you from A to B, with little effort on your own.

As a result, you’ll slowly use the ability to exert effort in the first place.

And finally, once everything seems difficult, you’re beholden to the tool and what its creators have envisioned for it.

Where this will lead

I’m convinced this development will lead to a very different distribution of skills.

Before the advent of AI-assisted coding, the distribution of skill approached a normal distribution:

Anybody with a laptop could get started with programming, yielding many programmers in total, a smallish amount of beginners, the bulk of the population having an average skill level, and then a few hardened veterans who are experienced and skilled by virtue of having had years and years of practice.

With the incentive for practice eliminated, there will be few people left with the patience and access to opportunities to accumulate the years of experience necessary to become true masters of the skill.

In other words, there will be very few experienced senior engineers left – people who have the ability to see novel solutions, and to implement them.

Brace for impact

This is going to be a problem for everyone, not just current junior or mid-level software engineers.

The whole world runs on software now.

Think of the software:

• in your car,

• the software used by air-traffic controllers to prevent planes from colliding mid-air,

• the software deciding what you can talk about in public

Hitting “TAB” to solve the problem isn’t going to cut it.

First of all, no current LLM can even comprehend real-life large codebases in detail to understand what the exact problem even is.

Second, even if they could, it would be slow and expensive.

But without having trained the skills of analyzing problems and developing your own solutions, you won’t be in a position to make any meaningful change to these systems.

That’s “press this key and pray” software development.

Experienced software engineers will be in demand again, in those niches at the very least.

Until then, the challenge becomes preserving skills and developing the next generations of developers.

Where we’ve seen this before

This is not a new dynamic.

The popularization of automated high-quality translations has allowed many more people to communicate successfully that otherwise would not have been able to.

Yet using Google Translate is not a substitute for actually knowing a language – when it’s off you’re hopelessly lost if you don’t know the target language at all.

We still have translators, we still have people learning languages.

What’s changed is that language learning has become a choice in many cases.

There are those who persist through the difficulty of learning a language, and there are those who outsource this to a machine.

Only one of these groups reaps great long-term benefits.