“Against Expert Forecasts and Developer Self-Reports, Early 2025 Ai Slows Down Experienced Open-Source Developers”

Wow, totally not my experience. My experience with Go/Claude Code has been great. I’m much more productive than before - measured buy I can create several features a day where before it would have taken one day to create one of them.

How comes?

Looking deeper at that study it makes a lot of sense and surfaces the common problems with AI.

• Overoptimism. Developers are generally the most overoptimistic crowd I’ve met. Especially in what they can do. No wonder developers are overoptimistic with AI. Which - as usual - needs some years of contrary experience for people to adapt to reality.

• AI does not work well with large code bases. The study uses code bases with >1M LOC 10 years old. Code bases need to be AI friendly, not human friendly. This means code that matches context sizes, e.g. modularization code fitting context windows, tools and prompts that acknowledge size.
  

• Developers do not well without training. Most prompts are bad. Especially command prompts vs. plan prompting. Inexperienced developers will not be able to write the right prompts.

• Tacit knowledge - AI does not work well with implicit knowledge. AI works better with frameworks that use coding rules and languages that er explicit - it works worse with "convention over configuration".

• Tacit knowledge II - Organizations do not have all knowledge, documentation and requirements as documents for the AI to read. Most of this is in the heads of developers. Migrating to AI means getting more knowledge into documents (whys, business context, architecture, past problems etc.)
  

• Delegation is a general problem (“Developers accept <44% of AI generations). The biggest problem people have is "This is not what I wanted" Delegation means to learn to accept a solution that solves your problem and not compare a solution to your solution. AI is a delegation problem.

But there are some criticisms I have nevertheless:

• Open Source Developers. The study is about open source developers - or more important open source projects - but then talks about developers mostly. If you’re a open source project, this is highly relevant to you. If not, it’s not. Open Source projects (having worked on some myself) are very different from e.g. startups.

I started wanting to disagree with the study, but in the end I would agree with it!

Who knew!

But non-determinism is something we already live with.

If I give a problem - as a manager or fellow developer - to different developers, I different results.

If I give a problem to the same developer after six months, I get a different result.

The reason non-determinism is evident in AI, but not with developers, is that AI is faster than developers writing code, so it’s clearer to see. We let AI write the same code twice or three times - no one pays developers to write the exact same code 10x.

The second reason developers do not like non-determinism in AI is they live in delusion about determinism. Their belief that compilers are deterministic is delusional. A JIT compiler generates code depending on the hot path driven by user actions - which are non-deterministic. The same happens when a compiler is deterministic but in a different way than developers think. Developers think they know what code is generated, but they don’t. A compiler translates a double loop or a stream into just one SIMD instruction - they think they know what code the compiler generates, but they don’t - so their trust in the compiler is for the wrong reasons. And even if compilers would be fully deterministic, and people would know the code they generate, compilers are so complex that determinism is not useful for verification - just because ‘someone’ looks at compiler output does not mean it’s correct.

Developers do not really want determinism - this is just a scapegoat against AI.

What we want is correctness, not determinism.

For correctness we want trust, not determinism.

We trust someone, because there will be no surprise with the person. They do what they told us they would do. Their results are not wild but within normal parameters. Their results work. Developers trust compilers for the same reason we trust people. They are predictable, mostly don’t have wild results and we trust the results as ‘correct’.

Over time AIs will gain the trust of developers. By creating less and less surprises and the results being more and more within normal parameters, people will trust AIs more and more. And will look at code less and less. When I migrated from assembler to C during the 80s - and I felt I was an assembler god (don’t all teenagers overestimate their skills?) and knew all the optimizations you could do with 68000 machine code, I did look at C compiler output and the compiler wasn’t as good as me! - but it was predictable and ok - and the productivity gains and easier maintenance didn’t make me look back.

The non-determinism will no longer be a problem because of increasing trust.

Contrary to that, most organizations write classical code to solve problems today.

This bears the question: How do we migrate classical software engineering organizations to an AI only mode?

My CTO coaching clients seem to be overwhelmed by the road ahead, so are many CTOs and CEO founders I’ve talked to over the last months.

To help them to overcome challenges and plot a path into the future I came up with my AI adoption levels. You go from level one, replacing Google search with asking an AI, on the lowest level to AI-only on the highest:

1. Using AI like Stack Overflow / Google

2. Read-only Prompts for Analyzing, Explaining Code

3. Everyone uses AI daily somehow

4. Analyze Bugs, Suggest Ticket Solutions

5. Generate Functions + Magic Cut & Paste

6. Prototype First (with AI)

7. AI Generates Code, fixes Bugs & Human Review

8. Don’t Look at Code with AI Guardrails & Automated Ticketing

9. AI –only / no software

Using AI like Stack Overflow / Google

Instead of Googling a solution or searching Stack Overflow, developers ask an AI for guidance and knowledge on how to implement a feature, use some API, solve some problems, find some third party library to include. The AI does not read or write the code, the developer translates from the code into AI and AI responses into code.

Read-only Prompts for Analyzing, Explaining Code

The developer uses an AI to analyze code for bugs, security problems, pen testing. The AI is also used to read configurations from production, read Github CI/CD setups, Terraform configs for the developer to understand what is going on. When moving to a module or a microservice they don’t know, or for revisiting code they haven’t worked with for a long time, developers ask the AI to explain the code, draw an ASCII architecture diagram etc. This is especially useful during onboarding for new developers. Prompt examples and prompt training are essential here. Developers learn proper prompting for the AI to understand code at this point. AI is used to check if dependencies are necessary, should be upgraded, replaced or removed.

Everyone uses AI daily in one way or another

This is a major milestone. AI is no longer a tool you reach to from time to time but an indispensable tool everyone uses everyday. As a manager this is the first milestone to achieve and you should measure AI usage to understand if you’re there yet.

Analyze Bugs, Suggest Ticket Solutions

AI is used to find the reason for bugs, suggest bug fixes. AIs are particular good at that because they relentlessly read code and documentation and get a much broader grasp about the model in the code than developers could ever do. On this level, the AI reads a ticket from Github, Linear or Jira and suggests a plan for implementation - after reading the ticket, reading the code base and reading all internal and external documentation available. It’s particularity important here that documentation exists and is written in an AI accessible form - not primarily for the consumption of developers but the consumption through AIs. Everything that is distributed as knowledge in heads of developers needs to be externalized and made accessible to AIs here.

Generate Functions + Magic Cut & Paste

On this level, AI generates code - this is another major milestone. Developers trust AI enough to let it write code. Developers use the AI for generating functions, mostly side effect free functions that are tedious for developers to write - like manipulating deep object trees - but simple to write. AI is used to generate data objects, transfer objects, database mappings or simple controllers. Developers use copy and paste for new code, then select the code and let the AI magically fix and adapt the code.

Prototype First (with AI)

Here the organization has moved to prototype first. No longer are tickets written, UI designs created before code is written. Instead a ptrototype is created to evaluate the idea, check how it should look like, gather input from stakeholders. After the prototype is created, tickets, UI documents and requirements are created by an AI.

AI Generates Code, fixes Bugs & Human Review

AI does all the coding at this level. Developers interact with the model with specs, tickets and prompts, they no longer write code themselves. After the AI has written the code, developers review all code written. This is the last level of human owned code.

Don’t Look at Code with AI Guardrails & Automated Ticketing

We now have transitioned into AI owned code. The AI reads and writes code. Guardrails are implemented for the AI - around security, operations, data protection, privacy, performance and long term maintainability of code. People interact with the AI through tickets. The AI reads a ticket changes the code, commits and deploys on it’s own.

AI –only / no software

The last level of an AI transition is the replacement of software as the primary tool to solve problems. Instead of writing an ERP system, the AI does ERP with tool integrations and data storage. Instead of a CRM system that sends out emails, the AI does this. Instead of writing a game, the AI creates a game on the spot that you can play - how the AI does this internally is no longer relevant. Today we already see this in military drones.

With these levels it should be easier for you to transition towards more AI and give clear guidance to the people around you on the journey.

Some notes:

• These levels overlap. Each developer in an organization is on their own level, some are ahead, some behind.

• Different parts of the code base have different levels. The easier and non critical parts are ahead, the more complex and critical parts are behind.

• With increasing the levels, risk of failure increases but potential gains increase too.

• Different industries have different state-of-the-art levels, depending on risk appetite. Fintech, Health-ech, Firmware, Avionics and other critical systems will lag behind - startups with simple and low risk problems will leap ahead.

• Over time, the risk of each level decreases. Within the next decade AI only will be the default solution to problems.

Sometimes this is useful, because they are more skilled in the things that are necessary. Sometime they have the knowledge you haven’t. Sometimes they have access to resources and people you haven’t. Then they are not real middlemen.

Sometimes the inject themselves between you and what you want, to get a slice of the cake.

They become real middlemen when they no longer have unique skills, unique knowledge or unique success. When these become obsolete or commodities - but they try to stay injected between you and what you want as long as possible.

Sometimes when technologies change or new technologies arise, middlemen are swept away.

Then some technology comes along and drives them away. Like the internet (and I assume the newspaper before).

A long time ago, most people could not read or write. If you wanted to send a letter, you hired a Scribe. The scribe didn't invent the ideas in the letter; they simply possessed the technical skill of penmanship and literacy to transmit the message.

Lost to history.

With AI the developer looks more and more like the middleman.

Developer: Where is your value? Think deep. Become a creator.

AI brings a lot of change and many new possibilities. AI means Tabula Rasa for most of the things we have taken for granted. The times are as exciting as the Apollo program, the first home computers or the arrival of the internet. Why do so many developers resist AI, why do so many developers downplay the benefits and try to find the flaws in AIs? Why is their first reflex to dismiss the code AIs are creating?

To understand we need to switch perspectives, take the view of developers on AI. We hear how AI enables companies to write more code with less developers. “We write X% of our code with AI” is the new CEO flex. If AI is only about writing more code in a shorter amount of time, developers do not benefit from this. Their job is being taken away, their skills are devalued, their income shrinks. They have been the kings (and queens!) of the world for several decades, salaries knew only one way - up, up, up! Developers were valued, developers were treated like royalty. “The New Kingmakers - how developers took over the world” is a sign of that era.

Companies want to deliver 2x the features, but the salary stays the same - developers should be happy about this? Are managers mad?

One might argue, developers do more than writing code. But if you ask any CEO, what they think developers are doing, it’s “writing code”. As CTO I was often asked by CEOs why developers didn’t sit at their desk, don’t they know we need to deliver features? When the pressure is up to deliver more code, the view on what developers do shrinks to writing code.

Through this lens developers do not benefit from AI. Developers face the problems of bad code written by AIs down the road - they get up at night for the incident, they are blamed for the critical bug. They do not benefit from AI, but they own the downsides. Their boss, or the CEO, or the head of marketing, gets all the benefits.

We have seen this before - with testing. By writing tests, developers do not benefit in the short term but need to own the downsides. I wrote about the phenomenon in “Tests Are Bad For Developers - The real reason developers don't write tests”. Developers are under pressure to deliver, writing a test takes time and can only find a bug - which then means even more stress to make the sprint deadline. Writing tests does not bring short term benefits but short term downsides for developers. Not writing tests is the better short term strategy. A bug found in production is bad, but it’s a problem of the future, not of the current sprint deadline.

The same is true for AI.

Asking and looking around, it seems senior developers are resisting AI adoption even more. What is it about senior developers? When the thing that gives you value and distinguishes you in the market place is taken away - why not resist? But shouldn’t they have more experience and see the possibilities that AI brings to creation? No - seniors have to lose most with the introduction of AI. They have invested years or decades to hone their skills, to get where they are. Now an AI generates code - their skills that made their salary, their status in the world and often their identity are devalued by AI. The thing that distinguishes you from a junior is taken away with AI - AI the great equalizer it seems. While at the same time, companies expect more features, more oversight, taking responsibility for what the AI does by senior developers and more code reviews - the job gets more stressful than it was before.

But there is a lot of candy - and a brighter future - in there for developers. Developers are often either mainly coders or creators. Creators will flourish, for them AI is just another tool, like the many programming languages and tools and frameworks before. Another tool to create in a long line of tools. Creators were drawn to coding because of creation, wringing something into existence out of the void of an empty screen.

What greater thing can be there? They can welcome AIs for writing most of their code.

On the other hand we have the coders. They love the tools more than the creation, coding and the intricacies of code more than the product. And in an industry with shallow products it’s no wonder many developers are coders first, creators second.

Our industry has taken agency away from developers for 40 years. In the 1980s there were many one man shops, game developers, application developers who did it all. With software development growing, roles specialized and agency was take away. This accelerated with the introduction of product managers in the 2000s when developers - despite the claims of agile! - lost the last bit of agency they had and were degraded to execution machines. We tell you what to do, you code it! FASTER!

No wonder most developers are coders and not creators.

If we want to convince developers to use more AI, we need to explain: What is in it for them! If you want to sell something, it’s not about you, but about the other person. Put yourself in their shoes and understand them. What is in it for them? What are their desires? What are their problems? How can you help?

Luckily there are lots of things in AI for developers.

First, developers are often bored by some things - proper error handling everywhere, thinking about security first. Finding and fixing that bug that isn’t critical but just annoying. Changing dozens of files is tiring and boring. AI can do all those things - the AI is never bored.

Second, AI is a great tool beyond writing code. AI can do many things and help developers make their coding task easier. Analyze code. Make refactoring suggestions, finding security problems, plan a pen test, explain the architecture of a module you’re not familiar with. The benefit of AI is not mainly writing code, but interacting with code in general.

Third, developers can get back their agency! We need to nurture the creator inside every developer. With hackathons and prototyping we can make developers see the creator in themselves again - and give them back the agency they have lost over the last decades.

CEOs have been focusing on the wrong things for a long time now: they see technology as a feature factory. Just recently a CTO told me their CEO asked them to use AI to write more code faster. The CEO didn’t ask for using AI to find better ideas, or write better requirements. No, write code faster. Deliver faster.

AI is the opportunity to change this. I told the CTO: Push back, all of you focus on the wrong things. Use AI to focus on building the right things. Ask the AI for better ideas. Ask the AI if a feature should be build at all! Ask the AI how a feature can be promoted to be used more - and give developers the impact their work deserves.

Opportunities are endless.

Don’t use AI to push out more code.

If you do, developers will resist.

Integrating services into your AI lets you do many things. You can ask the agent to

• Tell me which are my most profitable customers?

• What customers are going to churn in 2025?

• Add a subdomain and certificate to acme.com

• Make CI/CD on Github work again

• Check server ‘A’ for vulnerabilities

• Check my backups

There are many ways to integrate your system and third party APIs into your AI agent, three options I want to talk about are:

• MCP

• CLI Client

• and - tada! - Fuse

MCP

MCP is the default way to integrate backend services and data into your agent, enabling the agent to work with your own data and services or a third party API and data.

MCP is well understood, well supported and used by many. The downside of MCP is you need to change the agent configuration and there is no standard way of discovery for the agent to find out the capabilities of the MCP server - or find tutorials, examples and ideas.

Benefits

• Standard

• Well understood

• Easy to integrate in AI

• Easy to host as a remote service

• (MCP also has a local tools mode)

Downsides

• Difficult discoverability

• Sometimes complicated to get working (tool me a day to get Playwright MCP working)

• Need to change agent configuration

• No automatic integration of different tools

CLI Client

Writing a CLI Client has been my preferred way of integrating my systems and 3rd party APIs with an AI agent. You let the AI write a small CLI client to access the data or API e.g. in Go. Then the agent can just use the CLI client to access the data, no configuration needed.

For my #CTO coaching application this looks like this (though I don’t use the client for agent integration but for my convenience in the terminal, faster than using the website):

I often use CLIs as a first step to integrating external APIs. When I integrated Zoom into my coach app, I let the agent first write a CLI zoom-cli to access the Zoom API. The agent can use that to explore the data inside, gaps in the data, what to expect, edge cases, data formats (like time/date) and understand both the API and the data at the same time.

This makes the integration of an API like Zoom into an application, like my coach app, much easier for the agent. After integration, the CLI can also help the agent debug the integration if there are problems, because the CLI is easy to use for the agent, compared to driving a website.

Benefits

• With —help the CLI tool can give a comprehensive help for the agent, including parameters, examples how to use it, usage guidelines

• CLIs have a rich parameter semantic with default —param1 p1 —param2 p2 etc.

• CLIs are fast

• CLIs are easy to install - no agent configuration needed

• Easy to implement more complicated methods and services calls beyond CRUD

• Can be used on it’s own compared to MCP

Downsides

• Limited auto-discoverability for the agent

• Non standard way to integrate

• Remote hosting is difficult, although it can be done with SSH

Fuse

For months now the CLI approach has been my goto method of integrating data into the agents I use. Recently I’ve read an article to use a filesystem with plain file operations to do so.

I wanted to see how integrating data this way works and start some experiments.

The way to do this is using Fuse - Filesystem in Userspace. Fuse works on OS X, Linux and I use it in WSL with Windows. Fuse creates a file system in userspace as the name suggests. Which doesn’t sound exciting, but it is! This way it’s very easy to create your own file system, I use https://github.com/jacobsa/fuse to build that file system in Go. And the filesystem can be anything - a mapping to existing data or “files” and “directories” presenting other things like email. Or it can represent data as files that does not exist at all and is made up on the fly. The possibilities are limitless.

For example, as an experiment I wrote a Fuse filesystem that uses the API of my coach app to represent data as files. Fuse can represent my CTO coaching data, clients and their sessions as files - although the data is not in files at all but spread over many different tables in a Postgres database. Calling the terminal command tree on the development data, results in a tree with all the clients as directories, sessions and profile data as files.

The biggest benefit of representing data and services as a file system is that the agent (Claude) can reuse all the tools it knows, grep (or ripgrep) or find (or fd) and combine them with bash commands. If I ask an agent about the clients - hypothetically, as my coach app already has a dashboard - with the most sessions, it does use bash, wc and sort to come up with an answer.

Benefits

• File format can be anything depending on needs:
  Markdown, CSV, or JSON. The agent will easily understand this, like CLIENTS.csv, <meeting>.md or <client>.json and use the appropriate tools (like jq for JSON) - or even on file ending, e.g. <client>.json returns JSON and <client>.md returns Markdown and the agent decides what it finds more useful at that point

• The agent can use standard tools to analyze, explore and combine data
  (bash, sort, cut)

• Easy discoverability
  (just use ls, find, grep, tree)

• Easy to cross link: If you have two file systems implemented this way, it’s easy to cross link between those two APIs/Data pools, just use the file path to connect them, e.g. <client>.md refers to /otherdatapool/company.md . Then the agent just reads that other file from that other path (like HTML links)

• Can be used standalone and be useful, contrary to MCP

Downsides

• CRUD operations are easy, service calls are more difficult

• No help like with coachapp —help
  (can be done with README_FIRST.md in the file system)

• Non standard way to integrate

• Remote hosting is possible but difficult

Conclusion

I wasn’t convinced MCP is the best tool in the past to integrate systems and I’m still not convinced it’s the best tool.

A CLI client for many situations is the better way forward, it can be used standalone and with an agent, there is more value in it. It’s easier to install and has easier discoverability compared to MCP - if you don’t need to host it as a server there is not much of a benefit. It can help you with debugging. Fuse has the benefit over a CLI client of very easy discoverability (just use find) but the downside of making actions like “new client” (create file?) much more difficult and error prone than an CLI.

I will use Fuse in the future for analytical parts, for combining different data sources inside an agent and keep using CLI clients for everything else.

On that backdrop of AI progress I found three moments and insights particular powerful for me:

1. Code as Meta-Token

2. Coder vs. Creator

3. Model vs. Agent

Code as Meta-Token

Many people - including me in the past - have a wrong view on how AI operates when writing code. They believe the AI is a trained developer, “trained” like a developer on code examples and then, depending on the training, making good or bad decisions about what code to write. They imagine the AI being a developer, analyzing the exiting code, analyzing and thinking about the requirements, then finding the best solution and code to implement it. The quality of the code depends on the training of the AI, good source material leads to a well trained AI which creates good code.

This is wrong.

The AI training is very different from training a developer. The AI takes the input and generates the most probable extension to that input. The input - not only being the prompt with the requirements, but also the existing code. If your project is one long source code file, the AI is happy to add to that long file. If you don’t use classes, the AI is happy to also not use classes. The AI is not taking requirements, thinking about the best solution based on the best code they have seen, and then trying to apply it to your code. The AI evolves your code in the most probable way. If the generated code is bad, this says more about your code (or the code in the context window) base than about the training data.

For this it is helpful to think of all your existing code base as a META TOKEN, and the AI generating the next token (the new code) based on the current one. After having understood that, and how refactoring the code from time to time by hand, the code the AI would generate was much better and of higher quality. It will quickly pick up the way of your code, from logging to error handling and structure.

Coder vs. Creator

The second insight from 2025 is that there are coders and creators. For 40 years I thought of myself as a coder. I was in it for writing code. I thought of developers as people who want to write code.

In 2025 I found out that you can split developers into coders and creators. I learned about myself that I was not a coder, but a creator. In 1981 - as a kid - I got into coding because I wanted to play the video game ideas in my head. Creators want to create things, and coding is the tool to do so. Creators want to create apps and games.

Coders on the other hand love the coding, they are in it for coding not creating. They love the tools and identify through programming languages. Myself, I was using more than 20 programming languages over the decades, and I currently like Go a lot, but I’m not tied to any of those languages, or even identify through them. A coder would. A code sees themselves as a Python, or a Rust or a Haskell person. A coder cares mostly about the tool, about the intricacies of the beauty of the code, not the impact. Something I’ve learned, I don’t care about mechanical watches, my quartz Casio is fine - I care about the time more than the inner working of my watch. I do love coding, I do love when it clicks, something complicated works, the brain teasing, the inner beauty of code - a function design that is beautiful - it’s just that creating is more important to me.

Creators will be fine with AI - they will flourish because AI is a super power to create. Coders who identify as such will have a hard time when no more code is written.

Model vs. Agent

My third Eureka moment was understanding the contribution of the agent. People mostly talk about the LLM model, like Opus 4.5 vs. Gemini 3 Pro.

What I’ve learned in 2025 is how important the agent is. Half of what makes an AI good at coding is the agent, the other half is the LLM model. The quality of the code is already good from most models, but how tools are used, if the model overengineers and many more things are tied to the agent and it’s system prompts and prompt wrapping, and the way it uses tooling.

I’ve learned this by using Gemini in the terminal. While the model beats Anthropic models on (some) benchmarks, it’s way worse when actual working with it. It wants to code all the time, there is no planning mode or discussion in Gemini CLI.

Claude Code is currently the best way to Vibe Engineering because the model is great and the CLI agent is great too.

Those were my three Eureka AI moments of 2025 that changed my thinking.

I wonder what the moments of 2026 will be.

One of those reasons might be the usage of Go. Go is AI friendly because:

• Many libraries to use

• Many examples for AIs to train on

• Simple syntax - not difficult for AIs to get right

• One way to do things

• Compile time checking of generated code

• Explicit constructs - lots of boiler code noise, e.g. error handling (compare to Rust “Magic”) that helps AI understand what is going on

• No major changes for the last 10 years, documentation that is 5 years old is still mostly relevant (Big changes like introduction of Context are few and far).

I have a small project called Hop which I use to manage my static website Amazing CTO for my CTO Coaching on Bunny CDN. With Hop I can change 302 redirect rules, push files to the CDN, manage and check DNS and minify HTML, CSS, JavaScript and images (PNGs to WEBP).

Using Hop we’ll find out two things:

1. Do Zig and Rust work as well with AI as Go does

2. Are Zig and Rust much more performant than Go and it makes sense to migrate projects

To test this, I converted the Go project both to Zig and to Rust.

Zig

Start with the new kid on the block: Zig. Touted being as fast as C but safer. Having a fast compiler and nice error semantics. We’ll try to convert our little tool to Zig.

First we let Claude generate a plan_zig.md file for the migration and tell Claude what we want it to do. Examine the Hop code, extract the functionality, find Zig replacements for the Go libraries used, migrate the code, build and test the result.

As usual I asked Claude after it finished the plan to check the plan for details and make sure it works with the code. To read the documentation again and make sure the plan works. One issue were dependencies. We iterated over the plan for finding the right dependencies replacements. Many libraries that are available in Go are not available in Zig, and it had trouble to also find C libraries e.g. for minify - Claude suggested to fork cminify and make it a C library and I agreed. After we were finished with refining the plan I asked Claude if it was “confident” to make the plan work, it wasn’t and made some changes, added some lines and checked more documentation.

When starting coding, Claude failed miserably. It could not get IO working because Zig recently changed how it does IO. Zig was confusing as it had old documentation an new documentation. Documentation on the Zig site was subpar, API docs being spotty and the website and the internet lacking great tutorials. Giving 4 URLs to Claude to check how IO works now didn’t work and Claude was not able to get something compiled for half an hour.

I stopped the migration to Zig at that point.

Rust

On to Rust, which is much older than Zig and should not be a challenge because of lacking documentation or fast changes. Rust might be a challenge because of the complicated syntax though, can Claude manage that?

Going the same route with the plan and iterating over it as we did wit Zig, Claude had problems finding dependencies, at one point Claude wanted to minify JavaScript by wrapping it in <script> and using a HTML minifier instead of using e.g. minify-js
We did not find a library to convert fonts into the smaller WOFF2 (Go had a library), and Claude suggested to use C++ which I refused, I didn’t want to drag in a C++ toolchain. As I can convert the fonts once and for all, I dropped the font-conversion requirements.

Claude worked for several long minutes and in the end: Compiled on first try.

Contrary to Zig, Claude had no problem converting the project to Rust, and make it compile.

Going into the details of what Claude did, revealed many problems though. Command line arguments were different between the versions, e.g. —key vs. —api-key, and even parameters were different —zone <zonename> vs —pull-zone-id <zoneid> with different semantics. And then some parameters were missing completely and some were added:

There are big differences in the CLI API of both versions, but differences do not stop there. Both versions have different functionality, the Rust version (Rhop) has a JSON rule file which was not part of the original Hop application.

Learning: My prompt should have been more specific to copy the parameters verbatim and make sure the CLI API stays compatible.

Beside that, the “rules list” command did not work, it listed all Edge rules of the project not only redirects, where the Go version would only print redirect rules (as intended). Minify did not work. The minify command in Rhop did not copy files it could not minify but ignored them. Second, when minify had an error with a JS file or CSS file, because it could not parse it, Rhop did not copy the file but also ignored it. The Go version creates a responsive srcset of WEBP files from one PNG, Rhop only converts one PNG to one WEBP file - forgetting the responsiveness functionality.

The HTML was also broken, the minifier was too aggressive to minify HTML which resulted in broken pages. Then Claude tuned the minifier down to be less aggressive, but it still broke the page. What happened? It turned out some of my pages were not correct HTML to begin with - Hop with Go was just more forgiving than Rhop with invalid HTML.

A short Claude Code planning and coding session removed those bugs and made Rhop work.

Eureka! We converted a Go project successfully to Rust.

Let’s compare both versions, the Rust and the Go one (You remember Zig failed). I focus on the minify functionality here. The difference in the minified size between the Go and the Rust version wasn’t that big:

The difference in runtime also wasn’t as big as I had hoped - Rust is touted as a very fast language rivaling C but the results felt mixed:

A reduction of running time of 30s is not nothing but it’s not twice as fast with no cache. It is much faster when we’re mostly CPU bound when all images are cached and skipped and only HTML minifying is applied. In this case Rust is ~4x faster - though for my website the Go version is fast enough with 6 seconds. Perhaps the Rust code wasn’t very optimized? Telling Claude Code to optimize the Rust code, it changed the parallelization strategy, applied read optimizations, optimized copies and more, and the time went up to ~100s. Go figure.

How much code did Claude produce? Comparing the implementations, the versions are similar in size:

The implementation in Rust has less code than Go, something to be expected because Go is more verbose, but also surprising as LLMs often add more lines of code and are very verbose. On top it looks like Claude Code is not very noisy by adding lots of comments, as LLMs have also been accused of.

Overall at this point I feel the conversion was not satisfying. Claude Code totally failed with Zig, and the Rust version of Hop was only superficially the same. From the wrong parameters, to the missing features - the implementation was totally different - e.g. the WEBP conversion didn’t include responsive output. Perhaps a better prompt is needed to make this happen.

In the grand scheme of things though, it was amazing to convert between programming languages in a few hours, something which would have taken days for a developer to accomplish - if I could make them start this dreadful task at all. As this will only get better over time, we are moving to a place where programming languages do no longer matter as we can covert between languages and frameworks. Indeed a conversion prompt, that tackles the main dependencies, based on what works, between projects to guide the LLM, could make this conversion even faster.

Second we wanted to see if a conversion makes sense because of performance gains, and if an LLM can handle Zig and Rust as well as Go. From a language perspective, the LLM failed with Zig but Rust seems to work as well as Go with AIs. My usual problems when writing Rust code did not occur. I had no borrow checker problems (though I do suspect the AI uses quite some Arc<>) - the second reason I left Rust stayed with me: compile times in Rust are atrocious compared to Go.

This is an illusion. Compilers today do things that are not in the source code. In this example from the Advent of Compiler Optimizations, we see source code to the left and machine code (ARM) to the right. And as we can see, the tail recursive function add_v4 of add to the left is replaced with a simple add on the right - not what developers would expect.

Compilers do not stop there, they might generate something completely different, for example replacing a nested for loop on array operations into SIMD vector instructions. But as someone pointed out on Linkedin, Compilers are limited in what they are allowed to do (thanks for the link!)

What does this have to do with AI? Developers distrust AI because they can’t control it, because they can’t predict the output, or better, they can’t predict the effect of it’s output.

Compilers are optimized to have predictable output. If the source code adds 3 + 7, the compiler should create machine code that also adds 3 + 7, not subtract 3 from 7 for example. Compilers in this way are deterministic (JIT compilers are stochastic in some other way - the reasons benchmarks often fail).

AI’s are, for now, not optimized for predictable, repeatable and deterministic output. You give the same input to an AI 9 times, and you get 9 different results. I’ve tried that with generating a Minesweeper game 9x. (actually 10x) The result were 9 different games with different UI, look and feel and even different algorithms and bugs.

We have seen AIs progress before. A year ago AIs struggled hard to generate correct text. The easiest way back then to detect AI generated images was garbled text in the image. Nano Banana Pro has solved this mostly. We have seen people with six fingers at each hand. Today you rarely see AI images with people who have six fingers (or four!). There was a need to make AI work in certain scenarios and AIs were adapted - a need to limit AI to “correct” output.

AIs as compilers?

AIs are very different from compilers in one way, they are not deterministic. AIs are similar to compilers in other ways, as they can translate text into code, or code into code. Compilers have the concept of correctness, AIs currently lack that concept - not only when generating code, but it’s here, where the code might do incorrect things, that it surfaces most and is easy to see - or even binary: the code works or it doesn’t.

How deterministic can AIs be?

I wanted to see what does work right now and where we are standing. Can AIs be deterministic for small input variance? What if we only use code as input, just like a compiler does? To find a small example that works to establish a data point, not to proof that it works for all input.

For that I created a small Python script and let Claude Code Sonnet 4.5 translate it 9 times to Go. The Python script is very simple and similar to the Compiler example above.

Translating this 9x into Go source code with Claude Code Sonnet 4.5 resulted in 9 go versions, add1.go to add9.go

Claude Code generated the same Go code 9x. A small limited input generated deterministic output. I struggled with suppressing Markdown output, currently AIs love generating Markdown, it worked with

Translate this Python code to Go. Output ONLY the Go code, NEVER add explanations NEVER add markdown or wrap it with markdown like \`\`\`go\`\`\` ALWAYS generate go source only - check after generation.

Especially the “check after generation” is helping, as it does with Vibe Engineering in general - AIs would profit from being 2-pass compilers. A script runs the prompt 9 times (WSL2, Windows11), Silicon generates the syntax highlighted images, Image Magick generates the 3x3 image then as a montage.

When we try the same with Gemini 2.5-pro (I don’t have 3.0 CLI access yet), it gets interesting. First, Gemini can’t strip Markdown as reliably as Claude so I had to remove it often myself (check the number of lines in each run).

Second, the generated code is the same for this simple example!

(Also compared to Claude Code the Gemini CLI is much slower, to the point of being unusable)

Interestingly both Claude and Gemini chose int as the type for parameters a and b. Probably because of the one example given.

We can assume that we get different results with a different Python code example that does not add ints.

And the Go result reflects this (Claude Code Sonnet 4.5 again).

What have we learned?

AIs can generate deterministic output currently from small input. And they break down for high variance input, like the Minesweeper example above. Somewhere between these two data points, large-example-English and small-example-Python is a red line drawn where AIs start to struggle to keep determinism.

If we need more determinism in AI output, I’m sure we’ll see the same play out as with the text and the fingers. Looking at my Theory of Control, I’m not sure that control is really the thing we want when moving ahead with AI though.

Over the last ten thousand years, there always was a dominant category of tools, starting with fingers. People solved all kind of problems with their fingers, like adding numbers. New categories of tools emerged: manual, mechanical, electrical, electronic, integrated circuits (CPUs), software and most recently Saas/mobile. When building a tool, you most often chose the newest and best category. For decades this “best tool” now was software and Saas. Have a problem? Build a Saas or mobile app (or some software). But this is coming to an end, AI is the emerging best tool category.

People confuse AI with software. But AI is something different. AI is about training, not about translating requirements into logical, sequential code. AI is not software but a new category for tools that goes beyond software.

“Stephan that’s nice, but when is it going to happen? How does it look like?” I hear you say. How does it look like?

Your current tech setup might be a mix of microservices, ERP and CRM systems, external integration with tools like Hubspot and a data warehouse in the cloud. When you want to send an upsell email, you use your ERP, CRM, data and Hubspot to create, target and send the email out to potential customers who might take the upsell offer.

With AI, you have an AI running on top of storage and you tell the AI to send out that email. There is no ERP or CRM code in the AI that runs and does this. The AI will do it.

“When is it going to happen?” Lets take a look where we are we with this. To find out I’ve done some experiments with AI/LLMs in this case Claude Code with some simple games.

AI means there is no source code for doing something, instead of software running that does something. Generating source code with AI, like all developers currently do, is not AI but still software. AI means there is no source code.

This said, what works and what doesn’t? In short:

• Claude Code can play Tic-Toc-Toe already.

• Claude Code can play “Connect four”

• Claude Code can’t play Minesweeper yet.

Start with the simplest game, Tic-Tac-Toe. Some months ago I’ve tried to play Tic-Tac-Toe against an LLM and it didn’t really work. For example, it didn’t find out that it did win, it made mistakes, didn’t understand the board.

Recently I played Tic-Tac-Toe again, no problems this time. Clean games, the LLM detected when it won. Remind you, there is no Tic-Tac-Toe game code generated or running, it’s the AI playing the game by thinking.

I did some experiments with Minesweeper in the past - e.g. letting an AI generate a Minesweeper game. That worked great! Now instead of letting the LLM generate the source code of the game to play, how did it fare with playing the game directly instead? Not so well. It sometimes worked, but it often didn’t reveal the right cells. Or it made impossible boards that could not been solved. We’re not yet able to play Minesweeper.

So let’s try something simpler, Connect4. A simple game I’ve played as a kid in the past. You still need to do some thinking, but the “physics” of the game are simpler than minesweeper.

And Claude Code had no problems playing Connect4. I won, and it didn’t play very good, but it didn’t make mistakes and made legal moves and tried to win.

This is where we stand right now, Tic-Tac-Toe and Connect4 works, Minesweeper is still too complex. But as can be seen with the Tic-Tac-Toe progression, change is fast.

Will AI replace all of software? No, it will just become the dominant tool. And like software needs ICs to run, and ICs need electronics to work, and electronics need electrical systems to work and they need a mechanical setup like screws, AI will need software to run and work.

Software will act in three different ways in this new world:

• Software as glue. Software is gluing AI parts together, like we today see companies who use software glue to connect AI prompts to the UI and glue AI prompt results to storage. Like Bash glues things together.

• Software as a optimization. AIs might create temporary software to speed up a solution, like a database today uses an index to speed up. A user does not see the index, but it helps make queries faster. The user does not see the generated software, or even recognize that there is any.

• Software as an effector. AIs use software services to effect other systems, like an effector for sending emails or posting to the web. These effectors will also be software.

Software will stay with us, but no longer be the dominant tool to help us manage the world.

Thanks to Ingo Eichhorst for some insights.

There is a new wave of software coming, the single user application (SUA). AI makes it easy to write apps, and as a consequence, costs for writing software is going down massively and developing software is becoming cheap. What was not possible in the past, because it was too expensive, is now possible. We can write apps for a single user.

I wrote several single user apps over the last months, with the single user being me. Whenever I say “I wrote” I mean “Claude Code” wrote the code - and I managed the AI (architecture, testing, components, maintainable code, code reuse, …). To make this possible, you need to do it the right way - and it helps that I’ve been writing code for ~45 years (don’t create a SPA - 90% of use cases don’t need one!).

What single user apps did I write you may ask?

• I wrote a blog app for my website, which is generated using Hugo. While Hugo creates the site, I use a “blogcli” app now to manage blog entries, see which ones are already on Linkedin, create SEO friendly descriptions and more.

• I wrote an app to manage the CDN I use. There is an unofficial app, but it’s bad and lacks features. So my “bunnycli” manages redirects, domains, uploads, syncs faster etc. for my own websites (like https://www.amazingcto.com ).

• I wrote an app for my CTO newsletter. The app downloads the bookmarks I collected over the week from Raindrop, creates a file in my newsletter file format which I then edit and add my opinions and then creates a final Markdown file for Hugo which I can upload to my email provider. An application 100% tailored to my workflow.

The biggest single user application yet: I’m writing a 35.000 LOC Go web application for managing my coaching clients. I was triggered to write this by a big influx of new clients, and my CTO coaching operations and client management became slower and slower and ever more painful.

The application I wrote is much better than the one I was using, because the creators of that app do not care nor do they even know about my jobs that I need to get done. But also, my app caters to an audience of one not an audience of millions. It’s perfect for my use case of CTO Coaching, making my life much easier and smoother. I dread admin work, like writing down session times and discussed topics for my clients, creating and sending invoices - for companies on one hand and CTOs who pay by themself on the other, inside the EU and outside of the EU (different invoices), companies in Germany, in the EU, and outside of the EU (different invoices to remember), different payment processors (IBAN, Wise, …) for different parts of the world (Africa, South America, US) and different tax requirements.

With my own app, all those pain points have gone away, and it’s smooth sailing. Agreed, no one else might have the exact same requirements, and the invoicing company I was using needed to think about all their clients - but should I care? I only care about my use cases.

If those use cases work, the app is feature complete! Too many apps today are in search for new users and new markets - they add more and more features, they start as something you want but end as something that you don’t need. Redesigns, rework, learning all the time, lost muscle memory. Ever rising prices for things you don’t need or want.

On top of that, with your own app, you own the data. You own your customers. When I asked my current time tracking and invoice provider if I could export some data, they told me that wasn’t possible. Huh?

This might not be for everyone, but the time investment pays off for me as a CTO coach with my”margins”. Would it be better to buy something that perfectly fits my use cases? Yes. Does this mythical unicorn exist? No, see above (also most coaching applications focus on getting new clients, not on making ops smooth and automated).

Why now and not before? Before AI, single user applications were a maintenance nightmare. A bug happens, I need to spend hours understanding the code I wrote months ago. Framework and library updates? Pain. Framework updates with Claude Code? Easy. Bug fixing with AI? Easy too (ALWAYS use plan mode, iterate on the plan, not the prompt). Claude Code reads the code and presents me the requirements in the code. It reads the code and fixes the bug. I no longer need to come back to 12 months old code I wrote and despair.

Over time there are also some significant cost savings. No subscription costs - in the era of everything going subscription, and you no longer can buy applications, this is a huge reduction in costs over time. A friend recently told me he has $1000/month subscription costs (including AI). I still need to work some hours to get that money back. Hosting is cheap too. If your application needs hosting, costs are low, because there is only one user. It’s $5-$10/month for running several of those apps in the cloud.

Is this for everyone? No. For now you need to know what you do.

Barriers will fall though and things will become easier for more and more people.

Soon there will be millions of single user apps (SUA).

I thought so for a very long time too, as a hacker (don’t ask, no questions no lies ;-) coder and developer.

But I was wrong. Developers are not all the same, they are not all alike. If we look close enough, we can see two distinct groups of developers.

These two groups are creators and coders.

And while there is a little bit of a coder in every creator, and a little bit of a creator in every coder, they are different.

A creator wants to create something. Wanting to create, they look for the right tool. A pen, a brush, clay, code. Coding is a tool for them to create. As a kid, I was a creator. I played video games in the 1970s/80s and wanted to create my own games, I had ideas that needed to manifest. The tool was coding, so I taught myself coding in a department store, following what other kids did. I wanted to create video games and I did. I’ve learned to love my tools. I love the inner logic, the intricacies of the code, the beauty of the code, the challenges of the code, the architecture, the clockwork, I love the tool. But I take if for what it is to me, a tool to create something. And I write poems and create books with other tools. I consider myself a creator. Others share the same urge, to create. Just like me they got into coding to create something. I’ve met many of them in my 1980s demo scene days. We wrote computer demos, to show off, to create something magnificent and astonishing and breathtaking. We worked hard on our tools - SEKA forever! - to make this happen. But we were creators.

Then came the coders. They want to write code. They love the code and don’t care about what they are creating. An eCommerce app, a game, an ERP system. A coder is about the code. They don’t see programming or source code as a tool to create something, but an end in itself. They are not interested in the creation, they are interested in the code.

Coders have very strong opinions about their tools. They have fights and discussions about what programming language is better. I - a creator - use what is at hand. I’ve used Perl, and Ruby, and C, Pascal and Modula2, Lisp, and machine code, and Java and Scala, Rust, JavaScript, Typescript and Go - and wrote a database in Bash. I’ve enjoyed the type system of Scala and the simplicity and beauty of Ruby. But they are tools. A creator does not define themselves by the tools they use, but the things they create. Coders define themselves by the tools they use, “I’m a functional coder” they might say, and abhor object oriented programming.

Hasn’t Paul Graham also written about creators? Paul Graham made the distinction of Maker and Manager: “There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule.” Is this the same? Is the Maker a creator or a coder? A maker can be both, and I do think the term maker isn’t the best, it seems to suggest all developers are creators, they are not. In the wording of Paul Graham, I’d call them Maker and Producer (vs. Manager) instead of Creator and Coder.

This also solves the age old question of “Art or Craft”. Is programming art or a craft? Is it craftsmanship? For coders it is primarily craftsmanship, for creators it’s primarily art.

How does this relate to AI? Be patient young Padawan, we’ll get there.

Start with: Creators are often leaders, and coders are followers.

Creators want to create, and find the most astonishing things to help them as tools. They are on the lookout for new tools so they can create new things that weren’t possible before, without that new tool. When the tool has been established, and people pay for tools usage, there is a job market which draws in coders.

During my four decades in the industry I have seen and first an influx of creators followed by an influx of coders. In the 1980s, home computers put a computer on every desk, inside homes and in companies. Creators used those new tools to create something.

They coded VisiCalc and Lotus 1-2-3, they coded Uridium, The Sentinel, Elite, Apple Writer and CP/M. Creators were everywhere. They were drawn to computers to create. Later when there was a job market, coders came. Not every coder is in it for the job, but many are.

The same happened with mobile apps. Creators were drawn to mobile apps to create. When there was a job market, coders came. Same with the gaming marketplace of Steam which enabled everyone to distribute their game, Indy creators created games and coders followed.

Now Tabula Mag is about AI. What has that to do with AI? Right.

Who will survive the AI tornado?

Creators will. They don’t primarily care about the tool, they care about creating. Water or oil, they might prefer one, but they are in it for the creation of paintings. Otherwise they would not be an artist, but a painter painting walls with the best brushes. AI is just another tool to them. A better tool, to create more magnificent things.

Coders will not. They cling to the tool, they identify by the tool, and when the tool goes away, the coder will. They resist the adoption of AI. Whenever I talk to my CTO coaching clients, they tell me they have two types of developers. Those that resist AI, and those who eagerly adopt AI. A resistor might say “for complex software, much of the time will be spent on post hoc understanding of what code the AI has written.” They care more about the tool, the code, than the creation.

AI is democratizing creation. You no longer need to be a coder to create software. Just like the home computers of the 1980s put a new tool in the hands of millions of people, to become creators, just like me, to enable them to create who could not create before, AI puts creation into many more hands. You can be a creator with AI.

Though this time will be different for coders. The market for coders expanded every time there was a new tool for creators, like home computers or mobile apps, it created more jobs for coders. AI will not. It will take away all the code.

Creators will flourish, and coders will go away.

So now you know who will survive the AI tornado.

In the beginning I’ve worked on the project like every other project over the last decades, by reading code, thinking and writing code. I did use LLMs to generate some of the code for me, with Claude Code and Cursor, bigger and bigger junks.

I now no longer look at the code and just let Claude Code do it’s thing.

This sounds incredible. But it works. Let’s see how.

Let’s look at some reasons why this works:

• I have 40 years of coding experience in many different languages and frameworks. I might be able to write better prompts because I know what can go wrong.

• Obviously always use Git. When using more than one agent to change code, I use git worktrees. Most often though I have two Claude Codes running, with one working and one planning with me.

• From working with other agents, Claude Code, especially with Sonnet 4.5 is by far the best coding agent. People might think there is little difference in coding agents, but there is.

• I use the $100 Max plan from Anthropic which mostly gets me through the day. Sometimes Anthropic changes the algorithm and token usage and I run out of tokens. As of this writing I’m not running out of tokens with the $100 Max plan.

• Agile work - small changes, agile discovery. Feature by feature, not huge chunks of code at once. I check the result and if I don’t like it, I change it. I ship it if I like it.

• My work and the code structure I’ve started with act as a great template for the LLM to base it’s code changes on. Without a good starting template the LLM goes haywire from the beginning. I suspect coding frameworks with great templates, like Django and Rails, work better than code projects without great starter templates. My - structured - code was my starter template.

• My code is setup in vertical modules not in layers. Layers are confusing to LLMs, because they have too many dependencies, essentially the whole top layer depends on the layer below. Changes to that layer ripple through the code base. A Modulith with decoupled modules works much better for LLMs as it keeps the impact on other code low and it fills the context window with the right context, instead of those large layers. I suspect this has a huge impact on the success of the LLM.

• Use Claude Code plan mode for everything! Don’t jump into prompting. Iterate on the plan, not on the prompt. Iterating on the prompt just creates more and more wrong code until the LLM chokes. I write my requirements into Claude Code plan mode. I read the plan, I add or remove requirements until I’m happy with the plan. I tell Claude in plan mode to finally check the code and the documentation (with URLs) to make sure the plan works. I tell Claude Code to check if there is pre-existing functionality to reuse for the plan. I point Claude Code to libraries it should use. If I’m happy, only then do I tell Claude to start coding.

• I have many tests in place. After each feature, I ask Claude Code to refactor the new code to extract side effect free functions and write code for them. Claude Code runs the tests after changes and I told it to decide for failing tests if the tests need to be adapted or the code has a bug. Otherwise, Claude Code might undo the code changes just to make the test working again.

• The stack I use is very simple: Go, Alpine.js and HTMX. It might be the case that with having a compiler, the very simple language and the simple type system of #Go - most often there is only one simple way to do things in Go - Claude Code works better than with some other languages. Also has a big code base on Github for LLMs to be trained on. Finally the compiler is really fast, and as Claude Code compiles during changing code, this is not slowing down the AI.

• My build process includes all the Go linters like govet, goimports, gosec, golangci-lint, nilaway, govulncheck, staticcheck, and more. CLAUDE.md tells Claude Code to run the “make lint” target after it finished up coding and to fix the detected problems.

• Sometimes I tell Claude to create a small Python script to make changes, or understand data, instead of changing code directly.

• I run prompts to check for security, architecture, testing opportunities and weak code, then letting Claude Code suggest changes - Plan Mode! - to make the code better after some features.

• My work flow model is:
  Let the LLM code, code, code, then I do some refactoring through the LLM. The LLM is a probability machine, it creates the code that is most probable for the existing codebase. Starting from scratch, or with a bad codebase, the LLM will make it much worse. LLM, LLM, LLM, refactor, LLM, LLM, LLM, refactor leads to good code. With bad code, LLMs come to a point where they can’t move forward, because one thing breaks and the fix breaks something else.

• This is a game of trust. Many developers do not trust an LLM.
  My question is: Do you trust your coworkers? If you do, why?

• The setup works very well for greenfield projects and is very suitable for startups. Hire experienced senior developers and you will be able to let LLMs write most of the code and gain maximum development speed. Make developers product engineers and teach them business and product understanding. You can easily outpace your competition who works in traditional Scrum/Senior Developer setups.

• Caveat: I would not trust AIs with the core of a large existing system, or a complex code base, in fintech, health-tech etc. or other CTO positions I’ve held in the past - not yet. To get more and more modules in your company work this way, the key is to have proper guardrails in place.

Overall think of the old times, a Head of QA gave green or red light for a release based on the guardrails - tests, not by looking at the code. Neither should you need to look at the code to make that decision.

• AI brings many changes in a short amount of time. In the last twelve months we have seen already drastic changes to how people work.

• AI partially takes over jobs and roles, or even replaces people in vulnerable jobs like customer support.

• People wonder, where does AI stop? Can AI do everything that people can do? If you’re an engineer, a manager or in any other role, you wonder, am I safe?

• You might also think, what is left that makes me valuable? What is the value I add? How can I stay relevant in the future?

• This boils down to the question, what distinguishes me from an AI?

• It can’t be knowledge. In the context of AIs we can categorize knowledge as wide or deep. Wide knowledge is knowing how ZIP codes in China look. Something an AI shows to be much better than you. Deep knowledge is knowledge that only a few persons have or a few specialized companies have and that hasn’t leaked (yet?) to an AI. Although the second part can distinguish you from an AI, it’s hard to get and keep.

• It can’t be skills when you’re not working with your hands. An AI has a much broader set of skills and is also often better at it because it can apply many different skills at once.

• It can’t be work. An AI is much faster doing the work, creating texts and source code, summarizing information and suggesting decisions than you can ever be. Another aspect: It is not bored to do long tedious and boring work.

• The question remains: What distinguishes you from an AI?

• There is one thing that distinguishes you from an AI: Your will.

• AIs don’t have a vision or a will. AIs don’t want things. AIs live in the now, not in the future.

• You have a will and a vision for the future. Know what you want is distinguishing you from an AI.

• Sadly many people I meet do not have a vision or a clear will on what they want1. When asked, they might say “everything is fine”, or “I’m happy” or “I don’t know what I want.”

• There is a book called “The Neverending Story”. It has two parts. In the first part, the protagonist Bastian saves a fictional world called Fantasia. If people know the book or the film, this is often what they know. The second, much more important part, is more obscure. After saving the world, Bastian gets a medallion which says “Do what you want”. And Bastian, does what he wants - even becoming the king. After a lot of pain and his downfall, he understands “Do what you want” does not mean “Do whatever fancies you” but “Find out what you really want and then do it.”

• Many people I meet are like Bastian. They don’t really know what they want. They have no vision or will.

• What distinguishes you from an AI, is your will and vision. If you lack this, think about it. What do you want? What do you want to achieve? Articulate what you want and then get what you want. Don’t be an AI.

  Thanks for reading Tabula Mag! Subscribe for free to receive new posts and support my work.

“What are all the things I can do to solve the problem and make it stay solved?”

• This way, as an engineer or engineering manager or CTO you can make sure to not get overwhelmed by Boomerang problems.

• Don’t make the mistakes Intel made.

  Thanks for reading Tabula Mag! Subscribe for free to receive new posts and support my work.

The code the AI generates is the most probable token, based on your existing code base.

• If your code base is bad, the AI will produce code that is the most probable succession of your code. It does follow the average of what it has learned - but it will primarily produce code that fits your code, "the most likely next token”.

• As code gets worse over time, and adding bad code to bad code makes it worse faster, the code base deteriorates.

  

• It deteriorates to a point where the AI is not able to add more code without creating bugs - just like humans.

• In contrast to human developers most likely you will get stuck in a loop with the AI. The AI produces bad code, then rolls it back, and then adds the same code again, as it is the most probable next token. A little bit different because of your feedback, but essentially the same. You’re stuck in a loop.

• What you can do?

• Show the AI what you want!

  

• Let the AI generate code.

• Refactor in a way that makes the code look like it should. More files, smaller methods, error handling, exception handling, security, using frameworks instead of writing it’s own code (NIH-syndrome), ….

• Let the AI resume generating code.

• The new code will fit your refactored code.

• If it starts fresh with a blank slate, it does not know in which direction it goes, it will tend to the average.

• It’s like chaos theory - on a blank page too many things are possible, and small changes in the beginning lead to large variations over time.

• If you lift the quality level, it will produce the code that is most likely the next step for your code base. It does not have an inherent desire to create great code. I creates code that fits yours!

  Thanks for reading Tabula Mag! Subscribe for free to receive new posts and support my work.

After vibe coding for some time, I feel fatigue. I’m coding Marvai - a package manager for prompts on my own, with a combination of Claude Code and Cursor.

• I use Claude Code for code generation, bug fixing, test writing, test fixing, security checks etc.

• Claude Code is especially useful to fix linting errors from nilaway or staticcheck - for a developer those are boring and tedious.

• I use Cursor for augmented coding, generate functions, adapt copy&pasted code, for refactoring, fix error handling, and many other tedious tasks.

• I have been a coder for 40 years and I have seen many tools for developers that haven’t worked, like Model Driven Development MDD/MDA and executable UML.

• With AI I’m now much faster at generating code and building features than I ever was before. The combination of Claude Code and Cursor is a real speedup.

• I encountered a new phenomenon.

• Again and again I feel fatigue. I finish a feature, and another feature, concetrate on reviewing the code the AI generated, and fix a bug and finish a feature with such velocity and I feel fatigue after some hours - sometimes as soon as one hour. AI working at such speed, finishing things to accept or review, feels too much for my brain to process or keep up with. I need to pause for some time before I can start again.

• I haven’t felt this before as a developer.

• I first encountered the concept of cognitive load in the book Team Toplogies. The idea there is to structure teams in a way that the cognitive load for developers is not too small and not to big. The more responsibilities a team and it’s members get, the bigger the cognitive load. And if you put many different topics on a team, the cognitive load for the team becomes too big for the team to work.

• As a young adult I was working in a plastic factory, sitting at a machine. The machine produced vacuum cleaner cases, had it’s rhythm, it finished vacuum cleaner cases on it’s own schedule, made a “PING” when finished, opened the door and I had to grab the casing and put it down (and package it in fine paper etc. which took some time). The machine would close while I was finishing the casing. And for some time it was stressful, working to the rhythm of the machine. Then I got accustomed to the speed and rhythm, until my boss increased the frequency. Living by machine time is what I sometimes feel with Vibe Coding and Cursor generating code or Claude fixing a bug.

• I had waiting times with compiling and waited for the machine to finish, but it feels differently, with vibe coding it feels like the machine is in control not me.

• With traditional coding, the speed of your output matches the complexity of the task and the speed of your coding. This gives your brain time to process what is happening. With vibe coding the coding happens so fast, that my brain can’t process what is happening in real time, and thoughts are getting clogged up. Complex tasks are compressed into seconds or minutes.

• My brain does not get the baking time to mentally process architecture, decisions and edge cases the AI creates - not enough time to put the AI output into one coherent picture. I’m running a marathon at the pace of a sprint - speeds don’t match.

• One reason developers are developers is the dopamine loop.

• You write code, it doesn’t work, you fix it, it works, great! Dopamine rush. Several dozens or a hundred times a day. Now this loop speeds up. Faster and faster we run around that loop, and get washed with Dopamine - and your brain gets overwhelmed. And stress hormones at the same time! You get fatigue - instead of the usually happiness and satisfaction of coding.

• With coding there is a limit to context switching. A context switch in coding is like dumping the cache of your brain and reloading the cache of your brain with a new context. This takes time and energy. You need to build a mental model of the code, to decide what to change and how to change it and then writing the changes out into source code, the essence of coding.

• With vibe coding the frequency of content switches speeds up tremendously - with the AI fixing and creating many different things in different packages or modules with one go. Even when I <tab>, <tab>, <tab> in Cursor, each change is a micro-content switch from function to function.

• Each context switch takes energy, every context switch is heavy lifting for your brain. Normally this materializes as the fact that it takes time to context switch. With AI in the driver seat, context switches are forced on you faster and faster.

• When each context switch takes energy, fast energy switches from feature delivered to feature delivered, vibe coding drains your energy - fatigue!

• With AI it seems we all become managers, we all become reviewers. The core of the role is changing from turning requirements into code to managing AI output - more like a team lead manages the output of a team, but on a much deeper level. Your responsibility grows to manage a team of five with vibe coding, while still being a developer being responsible for the code. It’s like being a traffic officer in the middle of a busy intersection - which is a stressful job on it’s own - while also overseeing five intersections in parallel.

• Reviewing, directing and guiding an AI puts more stress on you than writing code, where your writing matches your thinking and doesn’t jump ahead, with you in a rush to catch up.

• What can be said:

  • Me and many more I assume feel fatigue from vibe coding

  • We need deliberate pacing when working with AI tools

  • We need AI-aware retrospectives to understand what is going on - perhaps having a daily retrospective to get the mind and the code in sync again

  • We need to be aware of new mental health challenges for AI coders

  • We might need to let go of micro managing AIs and trust the AI more - stop trying to bridge the gap between managing an AI and controlling it’s output

• I don’t think we’ve figured out yet where this is going. AI has made us faster than we’ve ever been, but our brains haven’t caught up to the pace. We’re like early pilots flying with autopilot—capable, but drained. We need new rhythms, new boundaries, and new ways of thinking about what it means to “code.”

• Maybe the future of coding isn’t just faster. Maybe it’s also slower in a way, on purpose.

  Thanks for reading Tabula Mag! Subscribe for free to receive new posts and support my work.

We first need to start with an important distinction. For the code you are working on, is the module or microservice AI owned or human owned? Is the code primarily read and written by an AI or by a human developer? For all your modules and microservices decide who is in the lead. Code that is written for humans is different than code that needs to be read and written by an AI. Human code has layers, patterns, abstractions, domain driven design. AI code doesn’t need to have the same. But AI works better with more documentation, API descriptions, ASCIIdoc architecture guidelines, coding guidelines, test guidelines. Yes developers would profit from those too, but without them AI easily derails, while developers still produce working code. While short methods work for developers, perhaps long methods and copy and paste work best for an AI (we don’t know yet).

With this in mind, AIs can’t be responsible for code. Whether a developer or an AI wrote some code isn’t important as AI’s can’t own code. Both code written by humans and by AIs must be owned by an human. Only they can be made accountable. The AIs can’t be fired, they don’t care, they don’t get woken up at 2pm to fix an incident. All code needs to be owned by a human being. If a developer creates code through augmented coding or a coding agent, they are responsible and should be held accountable.

Augmented vs. Agentic

There are two main modes of working with GenAI in coding: Augmented and Agentic. In Augmented Coding, developers use an IDE like Cursor, are in the driving seat and tell the AI what code to write on a granular level. In Agentic Coding, the AI is in the driving seat and writes all code based on the requirements you tell it to follow. Augmented Coding works best for human owned code, agentic coding works best for AI owned code.

Beside these two, there are two more ways to use AI as a developer:

• Chatbot (“ChatGPT”)

• MCP

• Augmented (“Cursor”)

• Agentic (“Claude Code”)

With those many different AI tools at their fingertips, not a lot of experience as an industry and no guidance from their managers, except of “More code, faster!” developers struggle with what and how to use their new tools.

Let’s take a look.

Chatbot (“ChatGPT”)

• The best thing you can do with AI is to use it for better ideas. The problem of software development is not how to build things, or how to build things as fast as possible, the real problem is what to build. Everyone thinks their ideas are the best - truth be told, they are not. I have seen so many bad ideas that have been implemented with hundreds of developer-hours that it makes me sad when I think about it. The best use of AI is to come up with better ideas or sharpen your ideas of what to build.

• Many companies I work with or worked for have a poor understanding of the customer, the market or the competition. CEOs do not spend enough time having the most knowledge in the industry about their niche. A Chatbot is a wonderful tool to find out more about your customers, the job they want to get done, the market and the competition - to build the right features and products instead of the wrong ones faster.

• A simple way to get feedback: post your roadmap or a screenshot of your Kanban board into ChatGPT and ask the AI: “Are we working on the right things?”, “Do we become market leaders with this?”, “Can we reach an X% increase in revenue with this?”, “Give me five counterpoints on why the roadmap is bad”, “What do you think we should work on instead?” ChatGPT, while being a sycophant, doesn’t have the group think of your company and will help you steer a better course.

Augmented (“Cursor”)

• I use Cursor to write functions for me, like “Create a struct X and extract X from this data structure" or “Sort Y by Z, load Z from the database, update Y and store it again”. Writing functions with augmented coding works fine, the amount of new code is limited, functions have often a limited amount of dependencies and side effects and can be easily reviewed by you while written by an AI.

• Copy and paste now works! Copy and pasting code is - admit it - what developers do to deliver code (I bow before you if you never copy & pasted code). But after pasting a chunk of code, you need to review all variables, and all code. Many times have I overseen a mistake in a line of code which lead to the wrong behavior with a debugging cycle after copy and pasting some code.

• Bad error handling is the biggest reason for incidents according to studies. But error handling is tiring, boring and there is always lots of pressure to deliver. “I deliver now and think of the incidents later” is what a developer might think. The importance of error handling for development can be seen in the many approaches to error handling, finding the magic grail, from Go errors to Haskell monads. But still developer don’t write correct error management and handling code. The AI is not bored, the AI is not tired and will fix all those `return err` into something more useful for debugging, tracing and mitigation.

Agentic (“Claude Code”)

• Today AI is perfectly fine for writing prototypes. Indeed what I encourage companies to focus on, is not write more code with AI, but experiment more. In the past a prototype of a product or feature might have taken several day or even a full sprint. With agentic coding companies can build a prototype a day, understanding potential products and features, experimenting more and have more powerful products and features that move the needle. Prototypes can be fully created by a coding agent from some requirement artifacts.

• With an experiment pipeline of prototypes we can create a Prototype → MVP → product funnel. From every ten prototypes to evaluate an idea you create one MVP to test the idea with customers. The requirements for security and styling are higher for an MVP but if you commit to throwing the code away, an MVP can easily be create like a prototype by an coding agent - with more care on your side.

• Agentic coding is excellent for bug fixing. Claude Code finds many bugs much faster than a human coder and can explain the reason for the bug happening if you ask the agent. It can write a test to isolate the bug and then fix the bug (and it’s root cause, if you dig in together with Claude Code), doing it all by the book while I as a developer might be bored by writing tests to isolate the bug - and because of delivery pressure my resort to a shallow fix without tests. Recently I had a complicated session bug where in edge cases the session wasn’t saved and Claude Code was able to find the reason and fix it.

• Agentic coding is great for framework, dependency or language upgrades. Most often upgrading a framework, a dependency or you language version isn’t very difficult (it sometimes is!) but tedious. It takes a lot of time and you need to be careful about what you do. And you might not have enough tests in place. The AI does not get bored and fixes broken tests until they work. Reviewing the tests after the upgrade is the easiest part left for you to do.

• The mainstream opinion is that AIs are bad at security. From my experience coding agents, when asked, are above the average developer (like me!) and below a security researcher or pentester. Having a security prompt to check security in your project (OWASP, parameters, exploits, data leaks, missing encryption) lets the AI check the security of your code. Not like a pentester, but well above most developers I have encountered.

• When you’re new to a company, new to a team or new to a microservice, understanding what the code models, how it is structured and how it works takes a lot of time. Letting the coding agent explain the code, used framworks, detected layers, domain boundaries and design patterns used (an let the AI guess what are the oldest and what are the newest parts ;-) makes it much easier for a developer to get into new code.

• In the past I have used Claude Code with the right prompt with great success for optimizing code, finding bottlenecks and memory throughput. Recently in one project I let Claude Code find the reason for GC pressure and fix it.

• You can have a prompt for pre-committing code. Ask the agent “Am I finished according to the code guidelines here and the ticket there? Is there something left I should do?”

MCP

• Last not least we have MCP. Start with integrating existing services and data lakes into MCP. Many problems can be solved by just tapping into what you already have. Show the CEO the power of AI with your own data and services.

• Integrate operations data from you logs, metrics and monitoring like load, memory usage etc. with MCP into you coding agent. Finding bugs, GC pressure, explaining those spikes becomes much easier.

• Lastly integrate user usage analytics with MCP into your system. From then on you can ask the AI about how much this code you are working on is used and how it is used by users - which gives you a deeper understanding on hot paths, where to work and what features to improve.

• With MCP in place you can replace some of your coding with AI orchestration.

Today there are already many different ways to use AI as a developer, way beyond of “write more code faster”. The main benefits are not code generation, but streamlining and optimizing all those other tasks. AI is your friend, not your enemy.

CTOs are out of control.

When I was CTO, this was the biggest problem for me and developers. I was out of control. I was cut out of the control loop. I was the only executive in the company who needed to ask someone else - the Head of Product or CPO - if I could tell the people in my department what to do. Imagine, the VP of Marketing would need to ask the CTO before a marketeer could work on a campaign - or what the marketeer should work on at all. But for me, the CTO, this was normal. The roadmap was stuffed and I had to ask - sometimes beg - to get tech topics into it.

And I’m not alone. Many of my CTO clients suffer the same fate. They are out of control, out of the control loop of what is being built. How did this happen?

We need to look at the Theory of Control. We have looked at software development as managing work and - especially with Lean - work flow. But software development is not about work flow, it is about control flow. Who controls what, when and how something is build. We have work elements and control elements in a company. Work elements, like Developing, produce output. Control elements, often meetings like Sprint Planning, control what, when and how something is build.

With Scrum control flow was rerouted. Before Scrum, control flowed from the CEO through the CTO into a program office into program managers and project managers. The CTO was part of the control loop. Then Scrum showed up and the product owner was invented. We could of course had made the PO part of technology - there is no rule that the PO had to be a product manager, it could be a tech lead - but the PO was made part of something that was also new, product management. And while requirement engineering and analysts often were part of the CTO realm, product management, for whatever reason, was not. Product management injected themselves between the CEO and development. Coup d’État accomplished.

From that point on, the CTO was cut out of the control loop. She was out of control.

But the how to build software, the clean code, and architecture, system design and tech choices still rest with the CTO (or with developers). At least this part of development is still controlled by technology and not somebody else.

Then AI showed up. And just like Scrum, rerouted control. AI generates the code. And people don’t know what code is generated, many don’t even care. The last part of control CTOs held is on the edge of being taken away. AI makes it worse. The last bit of control lost.

What can CTOs do? They need to get in control again. They need to take a stand. In the end, developers are part of technology and it is ridiculous that CTOs need to ask other executives if they are allowed to tell developers what to do. Demand a say in what is build. If you believe some technological debt needs to be payed back, go for it. Don’t let others drive you to postpone what needs to be done.

Some CTOs I know have lost the AI topic to other departments, just like they lost control over what is build. Don’t let them cut you out of the control loop again. Own AI. Became a CAIO. Regain control.