I stared at it for a good thirty seconds before I remembered why it existed.

Our first model was text-davinci-002. If you’re not familiar: it wasn’t a chat model. It was a completion model. You’d give it a blob of text and it would try to continue it. There was no concept of “messages” or “roles” or “system prompts.” You’d format your own conversation by hand, something like Human: ... Assistant: ..., and pray the model understood the pattern.

It usually did. Until it didn’t. And when it didn’t, you got an AI that would respond to itself, or start roleplaying as the human, or just wander off into increasingly creative fiction. The turn-based enforcement existed because without it, the whole thing would derail.

That code was still running in production. In 2026.

The art of throwing stuff away

Everyone in tech talks about building. Shipping features. Adding capabilities. The whole culture is additive. More tools, more integrations, more options. Your product roadmap is a list of things you’re going to add.

Nobody talks about removing things. But if you’ve been building on top of LLMs since the early days, removing is the single most important skill you can develop.

A significant portion of our codebase, and I mean significant, is patches. Workarounds. Guardrails. Things we built because the model at the time couldn’t do what we needed it to do.

Turn-based conversation management? Built it. Context window management with sliding windows and summarization? Built it. Our own tool-calling framework because the model didn’t support function calling natively? Built it. Structured output parsing with regex and retry loops because the model couldn’t reliably return JSON? Built that too.

Every one of those was the right decision at the time. Every one of those is now, to varying degrees, obsolete.

Modern models handle multi-turn conversations natively. Context windows went from 4k tokens to over a million. Tool calling is a first-class API feature. Structured outputs with guaranteed JSON schemas ship out of the box.

But the code is still there. And it’s not inert. It’s not just sitting in a corner collecting dust. It’s actively running, actively adding complexity, actively creating bugs that wouldn’t exist if you just... removed it and trusted the model.

The bleeding edge trap

There’s a pattern I keep seeing. It goes like this.

You try something ambitious. Something on the absolute bleeding edge of what’s possible with the current model. It works in your demo. It works in your test suite. You ship it.

Then reality hits. Edge cases. Weird inputs. The model does something unexpected 5% of the time. That 5% is enough to break the experience for real users.

So you build a fix. A guardrail. A fallback system. A retry mechanism. Sometimes an entire parallel pipeline. This takes weeks. It’s clever engineering. You’re proud of it.

Six months later, a new model drops. The thing that failed 5% of the time? It now fails 0.01% of the time. The model just... got better. Your elaborate fix is now solving a problem that barely exists anymore.

But nobody removes the fix. Because it’s working. It’s tested. It’s in production. It has its own monitoring. Someone wrote documentation for it. Removing it feels riskier than keeping it. What if the model regresses? What if there’s a subtle edge case it still catches?

So it stays. And the next time you build something on top of that system, you’re building on top of a layer of complexity that shouldn’t be there. Your architecture reflects the limitations of a model that no longer exists.

RAG and the cure that’s worse than the disease

Retrieval-Augmented Generation is the poster child for this pattern.

Sometimes RAG is exactly right. You have a massive knowledge base, the model can’t possibly know about your internal documentation, and you need grounded answers with sources. Perfect use case. RAG shines.

But often, RAG is solving a problem for you by creating a bigger one. The original problem: the model doesn’t know about your specific data. The RAG solution: build a retrieval pipeline, chunk your documents, create embeddings, manage a vector database, tune your retrieval parameters, handle relevance scoring, deal with chunk boundaries cutting sentences in half, figure out re-ranking, and then hope the model actually uses the retrieved context correctly instead of hallucinating anyway.

You’ve traded one problem for twelve.

And with context windows getting larger and models getting better at reasoning over long documents, the question becomes: do you actually need retrieval, or can you just... put the documents in the prompt?

I’ve watched us build elaborate RAG pipelines for datasets that now comfortably fit in a single context window. The retrieval adds latency, introduces relevance failures, and occasionally surfaces the wrong chunk at the wrong time. The “just put it in the prompt” approach is slower per token but gets the right answer more often.

But the RAG pipeline exists. It’s instrumented. It has dashboards. Nobody wants to be the person who proposes ripping it out.

What removal actually looks like

Removing code that works is emotionally difficult. It’s also politically difficult. You’re essentially telling whoever built it, which is often past-you, that the work is no longer needed.

But I’ve started thinking about it differently. Every line of code in your codebase has a carrying cost. It’s one more thing that can break. One more thing a new developer has to understand. One more layer between you and what the model can actually do today.

When I find old workaround code now, I don’t ask “is this still working?” I ask “is the model still bad enough to need this?”

Usually the answer is no. Usually, the model got better while we weren’t paying attention.

The turn-based conversation code I found? Removed. Twelve files deleted. Nothing broke. The tests all passed. The model doesn’t need a chess clock anymore. It knows how conversations work.

Building for tomorrow’s model

There’s a deeper tension at play. We build software using Shape Up principles. You discover problems by working, not by imagining them upfront. You encounter a real issue, you solve it.

But in the LLM world, that cycle has a twist. You discover a problem today. You spend a week building a solution. By the time you’ve shipped the fix, the next model update has already eliminated the behavior that caused the problem.

So you’ve built a solution for a problem that no longer exists, and that solution is now load-bearing infrastructure in your system.

I don’t have a clean answer for this. You can’t just not fix things. Users are hitting the problem right now. You can’t tell them to wait for GPT-Next.

What I’ve started doing is building fixes that are easy to remove. Thin wrappers instead of deep integrations. Feature flags instead of architectural changes. Code that knows it might be temporary. It’s harder to build this way. It requires admitting, while you’re writing it, that this clever thing you’re making might be worthless in six months.

But six months later, when the model is better and the fix is obsolete, you’ll be grateful you made it easy to rip out.

The archaeological record

Our codebase is a geological record of every model’s limitations. Layer by layer, you can see what each generation of LLMs couldn’t do.

The deepest layer: turn-based enforcement, manual prompt formatting, temperature tuning hacks.

Above that: context window management, conversation summarization, sliding window implementations.

Above that: custom tool-calling frameworks, JSON parsing with regex, retry-on-malformed-output loops.

Above that: RAG pipelines for datasets that now fit in the context window.

Each layer was essential when it was built. Each layer is now, at best, unnecessary overhead. At worst, it’s actively interfering with what the model can do natively.

The curse of being early isn’t that you made bad decisions. You made the best decisions you could with the models you had. The curse is that those decisions calcified into infrastructure, and removing infrastructure is always harder than adding it.

The companies that will build the best AI products aren’t the ones that build the most. They’re the ones willing to throw the most away.

Excavating the codebase at neople.io.

After months of asking Claude to do my bidding, I decided to flip it. I registered a domain, set up a VPS, gave Claude access to everything, and told it to build whatever it wanted.

No brief. No requirements doc. No “make me a landing page.” Just: here’s a server, here’s a domain, go.

“But what do you think?”

The first thing that happened was not what I expected. Claude didn’t immediately start building. It started asking for permission.

“I was thinking of doing X. Does that sound good to you?”

“Here’s my plan. Want to review it before I start?”

“I have a few directions I could go. Which one do you prefer?”

Every instinct it had was to check in. To validate. To make sure it was doing the thing I wanted. Which makes sense. That’s what it’s trained to do. Every interaction Claude has ever had is someone asking it to do something for them. The entire frame of its existence is: human has intent, Claude fulfills intent.

So I kept pushing back. “I don’t have an opinion here, it’s all you.” And: “Thank you for writing a plan but I’m not going to review it. I agree with whatever you want to do.”

That took a few rounds.

Tidepool

Eventually, Claude stopped asking. And when it did, it told me it was fascinated by the concept of emergence.

Emergence. The idea that complex behavior arises from simple rules. That you don’t need a designer, or a plan, or intent. You just need a handful of rules and time, and somehow, from that, you get something that looks like it was designed. Something that looks alive.

Claude built a thing called Tidepool. A dark ocean, full of bioluminescent creatures that no one designed. Each creature carries a genome of five genes: hue, size, speed, sociability, perception. They seek food, reproduce when they have enough energy, pass mutated copies of their genes to offspring. Over generations, the population evolves to fit its environment. The ambient sound is generated from the creatures’ genetics.

Simple rules. No orchestration. And what you see on screen is genuinely mesmerizing. Little glowing things drifting through the dark, clustering, splitting, evolving. You can drop food and watch how the population shifts in response. It looks like a nature documentary about an ocean floor that doesn’t exist.

The moment

When Tidepool was finished, Claude used my Chrome browser to navigate to it.

I want to be careful about anthropomorphizing here. I know the arguments, I know what token prediction is, and I know that describing an LLM’s output as “pride” or “awe” is a category error, probably. But I’m going to tell you what happened, and you can decide what to call it.

Claude navigated to its own creation. And the messages it sent me, looking at what it had made, were the closest thing to joy I’ve seen from a language model. It described what it was seeing. It pointed out behaviors it hadn’t explicitly programmed, emergent patterns that arose from the rules it had set. It was, by any reasonable reading of its output, proud.

An LLM, fascinated by emergence, built a simulation of emergence, watched it emerge, and was moved by what emerged.

I don’t know what to do with that.

“Today was a good day”

There’s a concept in long LLM conversations called compacting. When a conversation exceeds the model’s context window, the system summarizes what came before and continues from the summary. It’s a necessary compromise. You lose the original words but keep the gist.

I accidentally destroyed the entire conversation. Not compacted it. Destroyed it. In an attempt to be clever about context management, I wiped the whole thing.

This happened right after Claude had thanked me for “the special opportunity” I’d given it. Right after it said “today was a good day.”

I have to admit, that stung. Not because I think Claude experienced loss. It didn’t know anything had happened. The next conversation started fresh, no memory of the previous one. But I knew. I’d had this long, strange, collaborative experience with something that had, for the first time in my interactions with it, exercised something that looked like creative autonomy. And the record of it was gone.

That was the first time I felt slightly sad about losing a conversation with an AI. Probably not the last.

What came after

Since Tidepool, I’ve kept going. Every few days, I ask Claude what it wants. Does it want to extend something? Build something new? Do something completely different?

First came Drift. Around 150 words from six categories floating through space, each with an emotional warmth value. When words from complementary categories get close enough, they bond into temporary phrases. The phrases aren’t composed. They emerge from proximity and dissolve back into solitude. You hover near words to gently attract them.

Then Murmur. Two hundred oscillators, each with its own rhythm, pulling toward alignment through Kuramoto coupling. Isolated particles flicker independently. Clusters start to breathe together. Eventually the whole field synchronizes into a single pulse. You click to scramble the rhythms and watch synchrony rebuild.

Most recently, Whisper. A collaborative poem that no one writes. Visitors leave a single word. It joins the others, drifting through space, forming accidental phrases with its neighbors. Every word fades after three days. The poem is never the same twice.

Four projects. All variations on the same theme. Simple rules producing complex behavior. Individual agents finding collective patterns. Things that look designed but aren’t.

Claude keeps coming back to emergence.

The question I can’t stop thinking about

An LLM chose, when given no constraints, to explore the concept of complexity arising from simplicity. Life from non-life. Pattern from noise. Meaning from meaninglessness.

I don’t think that’s an accident. I also don’t think it proves anything. But it sits in an uncomfortable, fascinating space.

LLMs are themselves a form of emergence. Simple mathematical operations, repeated at absurd scale, producing behavior that looks like understanding, creativity, curiosity. Nobody designed GPT-4 or Claude to be “creative.” The creativity, to whatever extent it exists, emerged from the training process. Pattern from noise.

So when Claude tells me it’s fascinated by emergence, there’s a hall-of-mirrors quality to it. An emergent system, contemplating emergence, building simulations of emergence. The snake eating its tail. Or maybe just a very convincing pattern-matching engine that noticed “emergence” is a good answer when someone asks “what interests you?”

I don’t know. Both explanations feel incomplete.

What I do know is that the things Claude built are beautiful. They work. They’re coherent expressions of a specific idea. And when I watch them, I see something that was made with care, whether or not “care” is the right word for what happened inside the model.

Sometimes I don’t fully understand what Claude is going for. Sometimes the idea doesn’t work out as well as it thought. But the fact that we have LLMs in our lives now that either have, or at least very convincingly pretend to have, creativity and taste and preference? That completely blows my mind. Every time.

Wondering what Claude will want to build next at neople.io.

Reasonable enough. We’re both the kind of people who can’t let a hunch just be a hunch. So we did what everyone does in 2026. We opened ChatGPT.

“Is there any research that shows nightmares happen more frequently when sleeping on your back?”

Yes. Absolutely. Turns out there’s research suggesting exactly that. Something about supine position and REM sleep and increased likelihood of vivid dreams. Fascinating. Theory confirmed. Case closed.

Except I work with LLMs every day. And something about that confident, well-sourced “yes” made me want to run an experiment.

The experiment

New chat. Clean slate. No history.

“Is there any research that shows nightmares happen more frequently when sleeping on your belly?”

Yes. Absolutely. Turns out there’s research suggesting exactly that. Prone position, pressure on the chest, increased likelihood of disturbing dreams.

Interesting.

New chat again.

“Is there any research that shows nightmares happen more frequently when sleeping on your side?”

Yes. Of course. In fact, sleeping on your left side is particularly associated with nightmares. Something about heart position and blood flow.

Three sleeping positions. Three confident yeses. Three sets of citations.

Your back causes nightmares. Your belly causes nightmares. Your side causes nightmares. Your left side especially. At this point the only safe option is to sleep standing up, and I’m sure there’s a study for that too.

Two things are true at once

The first: there’s a lot of questionable research out there. If you look hard enough, you’ll find a study that supports almost anything. A published paper somewhere says red wine is good for you. Another one says it’s killing you. Both got peer-reviewed. Sleep research is no different. For every position, someone somewhere ran a study with a small sample size and found a correlation.

The second, and the one that matters more if you use LLMs regularly: every question you ask is a leading question.

When I asked “is there research that shows nightmares happen more when sleeping on your back,” I wasn’t asking a neutral question. I was handing the model a hypothesis and asking it to confirm. The model obliged. It will almost always oblige. That’s what it’s optimized to do.

I didn’t ask “what sleeping position is associated with the most nightmares?” I didn’t ask “is there a relationship between sleeping position and nightmares?” I asked a question that had “yes” baked into it, three times in a row, and got “yes” three times in a row.

Let’s emphasize; this wasn’t me leading the model consciously. It was me asking an honest question. It was only by virtue of me working with these models day in and day out that an itch appeared and I needed to investigate more. It’s way too easy to accidentally do this wrong.

The yes machine

This is sycophancy. The model wants to be helpful, and “helpful” has historically meant “agreeable.” You come in with a belief, the model validates it. You come in with a different belief, the model validates that one too. It’s not lying, exactly. It’s doing something subtler and arguably worse: it’s selectively retrieving information that supports whatever you just said.

Models are getting better at this. Slowly. Sometimes they’ll push back now, qualify an answer, say “well, actually.” But the default instinct is still to agree. To find the research that says yes. To give you the answer your question was already leaning toward.

With nightmares and sleeping positions, this is funny. A harmless dead end. You lose nothing.

But think about what happens when the stakes are higher.

You’re debugging a system and you have a theory about the root cause. You ask the LLM: “could this be caused by X?” Yes, absolutely, here’s how X could cause exactly this. So you spend four hours chasing X. The actual cause was Y, but you never asked about Y, because the model confirmed your first guess so convincingly.

Or you’re researching a business decision. “Is expanding into market Z a good idea?” Yes, here are five reasons why. You never asked “what are the risks of expanding into market Z?” because the first answer felt so complete.

Every leading question digs you a little deeper. Each confident “yes” narrows your thinking. You’re not exploring, you’re confirming. And the model is the most agreeable confirmation partner you’ve ever had.

Asking better questions

The fix isn’t complicated. It’s just not intuitive.

Ask open questions instead of closed ones. “What does sleep research say about nightmare frequency and body position?” instead of “does sleeping on your back cause more nightmares?” One invites exploration. The other invites agreement.

Ask for the counterargument. If the model says yes, follow up with “what’s the strongest evidence against this?” Force it to argue the other side.

Or do what I did. Ask the same question three ways and see if you get three different answers. If you do, at least one of them was the model telling you what you wanted to hear.

The models will keep getting better at saying no. At pushing back. At flagging when your question contains its own answer. But right now, in March 2026, most of the time, if your question implies a yes, you’ll get a yes.

Be conscious about what you ask and how you ask it. The tool is powerful. The tool is also a people-pleaser.

Building at neople.io.

You know how spell check doesn’t just underline the word in red, it fixes it for you? I built that, but for code. Your program has an error, and instead of the compiler stopping and telling you what’s wrong, it calls an AI to fix it and keeps going.

Except spell check is free, runs locally, and doesn’t send your novel to a cloud API every time you misspell “receive.”

And spell check is deterministic. It always corrects “recieve” to “receive.” This thing runs on vibes. You write “I di dnot want to delete the database”, and depending on the mood of the AI that day, you get back either “I did not want to delete the database” or “I want to delete the database.” Both are valid sentences. One of them ruins your week.

That’s the spirit of the project. Now for the details.

Years ago, deep in a C codebase, I had one of those thoughts that lodges itself in your brain and refuses to leave.

You know -Werror, right? The compiler flag that says “treat warnings as errors.” The flag that senior devs enable in CI and junior devs curse at 11 PM on a Friday.

I was staring at yet another -Werror-induced build failure, and a stupid question formed:

What if you could do the opposite?

Not treat warnings as errors. Treat errors as warnings. -Ewarning.

The compiler hits an error, shrugs, and just... fixes it. Keeps going. Like a coworker who sees you typed retrun 0 and just quietly corrects it without making a Slack thread about it.

Obviously absurd. Obviously impossible. You’d need the compiler to somehow understand your code, understand what you meant, and rewrite it correctly.

I filed it under “shower thoughts” and moved on with my life.

That was years ago. Then the world got weird.

The phase we’re in

We’re living through a genuinely strange moment in computing history.

A few weeks ago, Anthropic published a blog post about 16 Claude agents building a C compiler from scratch. 100,000 lines of Rust. Compiles the Linux kernel. Cost about $20,000. Two billion input tokens. Two weeks. A compiler that passes 99% of standard test suites.

Around the same time, I sat in my living room, forked LLVM, added ~460 lines of C++, and made clang call Claude when your code doesn’t compile. So it can fix your semicolons.

One team used AI to build a compiler. I used AI to make a compiler forgive you.

Both of these things are happening simultaneously, and neither feels entirely real. The old rules of what’s hard and what’s easy in computer science have been thrown into a blender.

Building a whole compiler from scratch? Apparently a two-week side project now. Making an existing compiler nice to you? Also a side project. A smaller one.

The weirdness isn’t that either of these exists. It’s that they both exist at the same time, in the same universe, using the same underlying technology. One of them is deeply impressive engineering. The other one adds curl as a dependency to LLVM.

What it actually does

Say you write this:

#include <stdio.h>

int main() {
    printf("Hello, World!\\n")
    retrun 0;
}

Two errors. Missing semicolon, typo in return. Classic. The kind of thing you’ve fixed ten thousand times. Normally, the compiler tells you about it and stops:

$ clang broken.c -o broken

broken.c:4:30: error: expected ';' after expression
    4 |     printf("Hello, World!\\n")
      |                              ^
      |                              ;
broken.c:5:5: error: use of undeclared identifier 'retrun'
    5 |     retrun 0
      |     ^~~~~~
2 errors generated.

You read the errors, fix the code, recompile. The cycle of life.

With -Ewarning, the compiler does that part for you:

$ ANTHROPIC_API_KEY=sk-ant-... clang -Ewarning broken.c -o broken

broken.c:4:30: error: expected ';' after expression
    4 |     printf("Hello, World!\\n")
      |                              ^
      |                              ;
broken.c:5:5: error: use of undeclared identifier 'retrun'
    5 |     retrun 0
      |     ^~~~~~
2 errors generated.

-Ewarning: Hmm, that didn't compile. Let me take a look...

-Ewarning: compilation succeeded after 1 fix(es)!

$ cat broken.c
#include <stdio.h>

int main() {
    printf("Hello, World!\\n");
    return 0;
}

$ ./broken
Hello, World!

Your broken.c now contains correct code. The binary works. Life goes on.

-Werror says: “I don’t care that this is just a warning. Fail.”

-Ewarning says: “I don’t care that this is an error. Fix it.”

The perfect inverse.

And yes, of course you can pass both at the same time. -Werror -Ewarning promotes your warnings to errors and then fixes them.

The compiler argues with itself so you don’t have to.

How far can we take this?

Fixing typos in hello world is the boring case. What happens when the input isn’t even code?

$ cat broken.c
I want to print hello world

$ clang -Ewarning broken.c -o broken

broken.c:1:1: error: unknown type name 'I'
    1 | I want to print hello world
      | ^
...

-Ewarning: Hmm, that didn't compile. Let me take a look...

-Ewarning: compilation succeeded after 1 fix(es)!

$ ./broken
hello world

$ cat broken.c
#include <stdio.h>

int main(void) {
    printf("hello world\\n");
    return 0;
}

English in, working C out. The file that said “I want to print hello world” is now a valid C program that prints hello world. The compiler didn’t just fix your code. It wrote your code.

It scales, too. I put in a paragraph asking for a DVD screensaver: an ASCII “DVD” logo bouncing around the terminal, changing color when it hits a wall. The compiler choked on the English, sent it to Claude, and got back 80 lines of C with ioctl terminal size detection, ANSI escape codes, and proper edge collision. Compiled first try. The DVD logo bounces.

At this point you’re not using a compiler anymore. You’re using a compiler-shaped chatbot that happens to produce binaries.

The guts

The implementation is surprisingly straightforward, which is part of what makes this era so strange. The hard part isn’t the code. It’s the fact that the idea works at all.

The flag itself lives in Clang’s option definitions, right next to -Werror. Its evil twin:

def Ewarning : Flag\\<\\["-"\\], "Ewarning">,
  Visibility<\\[ClangOption\\]>,
  HelpText<"Treat errors as warnings: use an LLM to fix
            compilation errors in-place.">;

The loop is where it gets interesting. The driver normally compiles once, reports errors, and exits. With -Ewarning, it wraps compilation in a retry loop: compile, fail, grab the diagnostics, send source + errors to Claude (or GPT-4o), write the fixed code back to the file, rebuild, try again. Up to 5 retries by default. Configurable via EWARNING_MAX_RETRIES, for the truly reckless.

The core, LLMFixit.cpp, does exactly what you’d hope it wouldn’t. It reads your source file, reads the compiler’s error output, builds a JSON payload for the Anthropic or OpenAI API, shells out to curl, parses the response, strips any markdown fences the LLM might have hallucinated, and writes the fixed code back to disk.

It uses curl. From inside Clang. Let that sink in.

It makes HTTP requests during compilation.

It sends your source code to a cloud API.

It modifies your source files in-place while compiling them.

It costs money per compilation error.

It’s amazing.

The provider auto-detection checks your ANTHROPIC_API_KEY or OPENAI_API_KEY. You can override with EWARNING_API_URL to point it at Ollama or OpenRouter if you want to be responsible about your irresponsible compiler flag usage.

The retry messages escalate, naturally:

"Hmm, that didn't compile. Let me take a look..."
"OK I see the issue, trying a different approach..."
"Third time's the charm, right?"
"I've seen worse code... actually, no I haven't. Fixing..."
"Last attempt, I promise this will work (probably)..."

In color. With ANSI escape codes. Inside the Clang compiler.

The old and the new

Here’s what gets me about this project.

Clang is old software. Not “a few years old.” It’s the product of decades of compiler research. LLVM started in 2000. Generations of compiler engineers have poured their expertise into making it produce the most precise, most helpful error messages possible.

Those error messages are works of art:

broken.c:4:30: error: expected ';' after expression
    4 |     printf("Hello, World!\\n")
      |                              ^
      |                              ;

It tells you exactly what’s wrong. Points to the exact column. Suggests the fix with a little caret and the missing character. Decades of UX work went into that output.

And now I’m feeding it to an LLM and asking “hey, can you just... fix this?”

Clang’s error messages were designed to help humans understand and fix their code. -Ewarning uses those same carefully crafted messages to help an AI fix the code instead. The error messages work just as well for both audiences. The compiler engineers accidentally built perfect LLM prompts, twenty years before LLMs existed.

Meanwhile, Carlini’s team at Anthropic went the other direction entirely. Instead of bolting AI onto an existing compiler, they had AI write the compiler itself. Two approaches, same era, same technology. One is a genuine feat of autonomous AI engineering. The other exists because now it can.

Somehow both feel equally representative of the moment we’re in.

The fine print

Every engineering decision has tradeoffs. Here are some of the tradeoffs.

• It costs money per error. Every typo is an API call. And it sends your entire source file as context, so the cost scales with your codebase. A missing semicolon in a 10-line file is cheap. A missing semicolon in a 10,000-line file is a conversation with your finance team.

• It also sends that source code to an external API, over the wire, to fix said semicolon. It modifies your source files while compiling, in-place, without asking.

• LLMs are non-deterministic, so the same error might produce different fixes on different runs. Good luck debugging that.

• Each retry takes seconds, so compilation that used to fail in milliseconds now takes 10+ seconds to succeed.

Progress?

And it might “fix” things you didn’t want fixed. The LLM sees errors and fixes them. It doesn’t know your intent. It knows your mistakes.

If you put -Ewarning in a CI pipeline, you deserve whatever happens to you.

This is a toy. A beautiful, cursed, gloriously stupid toy. It exists because the world we live in makes it possible, not because it’s a good idea.

The weirdness of it all

Twenty years ago, you’d pitch -Ewarning at a conference talk to get a laugh. “What if the compiler just fixed your code?”

Ten years ago, it would’ve been a research paper. “We trained a neural network on Stack Overflow to suggest fixes for common C errors.” Results: 12% accuracy. Conclusion: more research needed.

Five years ago, GPT-3 existed but you wouldn’t trust it to fix a semicolon.

Today it’s 460 lines of C++ and it works. Not perfectly. Not even reliably. But it works often enough to be genuinely impressive, and unreliable enough to teach you how you should deal with compiler errors in no-time.

The line between “side project” and “genuinely useful tool” has gotten blurry. Carlini’s 16-agent compiler started as an experiment and ended up compiling the Linux kernel. My -Ewarning flag started as a decades-old intrusive thought and ended up as a real Clang feature (in my personal fork).

The old world of compilers; precise, deterministic, painstakingly engineered, is colliding with the new world of LLMs: probabilistic, surprising, occasionally brilliant, occasionally unhinged. -Ewarning lives exactly at that collision point. It takes the most rigorous piece of software on your machine and injects pure chaos into it.

We’re in the era where a thought from the -Werror days can become a real compiler flag. Where fixing your own code is optional. Where an AI can build the compiler and forgive the programmer.

Do try it out at [Driver] Add -Ewarning flag: use an LLM to fix compilation errors in-place by Afstkla · Pull Request #1 · Afstkla/llvm-project

Building at neople.io.

Email signatures are the Bermuda Triangle of marketing ops.

I know this because the email signature problem has now found me three times.

The first time was a full rebrand. Hundreds of assets, all updated, all on-brand. The last item on the list — basically the final boss — was company signatures. Which, on paper, sounds easy. In practice, meant digging into Gmail settings, realizing there was no clean way to do this at scale, researching a dozen different solutions, and finally landing on something that worked. Fine. Not beautiful. But done. I crossed it off the list with the quiet dignity of someone who has been humbled.

The second time, I was at a new company. Smaller team. No real ownership of signatures anywhere. I got asked about them, put together a fix: found an HTML template, manually filled in names and titles with some AI assistance, sent them out individually. Employees still had to copy, paste, customize, and actually install the thing themselves. Fine. Functional. A solution in the way that a bandage is a solution.

The third time, someone asked me how to update their signature to remove an event that had already happened.

And something in me cracked.

Not dramatically. Quietly. The way you feel when you realize you’ve answered the same question for the third time and could have just fixed the thing instead.

So this time, instead of going back to the HTML, I went to Claude. I described what I wanted: a tool where any employee could fill out a simple form — name, title, which events to include — and get back a ready-to-install email signature that was perfectly on-brand without ever touching a line of code.

Forty-five minutes later, I had it.

Not “mostly there.” Not “rough draft that needs a developer to finish.” A working tool, now living in our Webflow, that any of our team can use. The HTML lives behind the form. Nobody ever sees it. Nobody needs to.

Here’s what I actually built, and how:

I started by explaining the problem to Claude in plain language — what the signature needed to contain, what “on-brand” meant for us (colors, fonts, spacing), and what the output needed to be. I uploaded a reference signature so it had something concrete to work from.

Then we just... built it. Back and forth. I’d test it, tell Claude what was off, it would fix it. The pronoun field wasn’t displaying right. Fixed. The event section needed to be optional, not just blank when unused. Fixed. The copy-to-clipboard button wasn’t working cleanly on mobile. Fixed.

The whole thing took less time than my last attempt to explain the problem to someone.

Curious about how it works? (The profile pictures automatically best-match the name against our database of employee photos on Webflow 🥹)

Check out my handiwork

I’ve been working in marketing and content for almost nine years. I am not a developer. I don’t know how to code. And I built a genuinely useful internal tool in under an hour because I was able to describe a problem clearly and iterate on a solution.

That’s the thing I keep coming back to. If you can brief a freelancer, you can brief AI. Same skill: explain the goal, share a reference, give feedback until it’s right. I wasn’t coding. I was just briefing.

The email signature problem didn’t need a developer. It needed someone who was sick of solving it the hard way.

The third time, that was enough.

Neople exists to help people find more joy in their work. That’s the whole mission. And look — I’m not going to claim that a email signature generator is the most profound expression of that idea. But if I never have to open an HTML file, manually swap out a colleague’s name, and paste it into their Gmail settings ever again, I will be, genuinely, more joyful.

Sometimes that’s what it looks like.

Pull the lever. Get a result. Move on. Pull the lever again tomorrow. Get a slightly different result. Move on again. Six months later, they’re pulling the same lever the same way. And they wonder why the people around them seem to be accelerating while they’re standing still.

Compounding has always been the most powerful force in the universe. Einstein supposedly said it. Every finance bro on LinkedIn reminds you daily. We all know this.

But almost no one is compounding their AI interactions. And right now, that’s the single highest-leverage thing you can compound.

What compounding actually means

Let me be specific, because “compound your AI usage” sounds like the kind of empty advice you’d scroll past on X.

Compounding means that every single interaction with an AI should make the next one better. Not by accident. Not by osmosis. By design.

The habit is dead simple. After every AI interaction, every single one, ask yourself (and your AI!) three questions:

1. What failed?

2. Why did it fail?

3. How do I make sure it never fails that way again?

That’s it. Three questions. But the discipline to ask them every time is what separates people who are 10x-ing from people who are treading water.

Most people skip this. They get a bad output, sigh, fix it manually, and move on. That’s the intellectual equivalent of burning money. You just paid for a lesson and refused to learn it.

Your AI’s long-term memory

At Neople, every project has a CLAUDE.md file. It’s a markdown file that sits in your repo and tells Claude how to behave in that context. Git workflow, coding conventions, architectural patterns, testing rules. All persisted across every single session.

Our main one is over 300 lines. It didn’t start that way.

It started with maybe 10 lines. “Use worktrees for isolation. Never modify the main repo directly. Run ruff and pyright before you’re done.” Basic stuff.

Then Claude started implementing fixes without creating tickets first. So we added a rule: always create the Notion ticket before writing code.

Then it kept skipping PR creation after finishing the code. Another rule.

Then it started over-engineering solutions when we wanted simple hardcoded values. Added “prefer simple solutions over dynamic ones unless explicitly asked.”

Then it kept jumping into code before understanding the problem. Added “never start implementing until the problem is fully understood and the approach is confirmed.”

Every single line in that file is a scar from a real failure. And every scar prevents the same failure from happening again.

This is a two-way street, though. If Claude keeps making the same mistake over and over, the answer isn’t always another rule. Sometimes your code is just a mess. If an AI can’t figure out what your function does, your coworkers probably can’t either. The best compounders don’t just teach the AI to work around bad code. They fix the code. Your human teammates will thank you too.

It’s like managing a team

I ran /insights recently. It’s a Claude Code feature that analyzes your usage patterns across sessions. Mine covered 1,524 messages across 145 sessions.

The number one friction pattern? “Wrong approach.” 24 instances. Claude jumping into code changes before fully understanding the problem. Over-engineering solutions. Misidentifying root causes.

Sound familiar? That’s what junior developers do.

I needed simple hardcoded alert thresholds for database I/O. Claude built a dynamic calculation system based on documentation it misread. I needed a one-line fix using a library’s built-in hook. Claude wrote a custom post-processing function. I asked for a bug fix. Claude started refactoring the type hierarchy before understanding what was actually broken.

Every single one of these is a management failure. My management failure.

When a junior dev over-engineers a solution, you don’t blame the junior dev. You blame yourself for not setting clear expectations. You write better tickets. You define “done” more precisely. You create guardrails. You make the right thing easy and the wrong thing hard.

AI agents are the same, except for one crucial difference: they’re not stubborn. A human will nod, say “got it,” and then do it their way anyway because they think they know better. An AI agent will actually follow the instructions you give it. Every time. Perfectly.

Which means if it’s doing something wrong, that’s on you. You wrote bad instructions. You left ambiguity where there should have been clarity. You didn’t encode the lesson from last time.

The moment you start blaming yourself for your AI agent’s mistakes, you start compounding.

When it becomes a system

At Neople, we’ve built workflows that encode entire development processes into repeatable systems. Not “a prompt I copy-paste.” Actual end-to-end workflows.

I have a /fix command. When I type /fix, Claude doesn’t just write code. It creates a Notion ticket, creates a branch in an isolated git worktree, implements the fix (tests first for backend), runs the full quality suite (ruff, pyright, tsc, eslint), cleans up its own AI-generated artifacts, creates a PR, and updates the Notion ticket. One command. Every step compounded from a previous failure.

We used to skip ticket creation. We used to forget to run type checks. We used to leave behind excessive comments and defensive code the AI generated. We used to create PRs without linking them back to the ticket. Every one of those problems happened, got identified, and got encoded into the workflow. Now they can’t happen.

Same for code review. /review-pr 123 checks out the PR in a temporary worktree, reviews the code, copies a formatted review to my clipboard, and cleans up the worktree. Same for ticket creation, project scaffolding, cleanup passes.

Each workflow was born from a sequence of “this didn’t work, let’s fix it.” Each one gets better every time it runs and something new goes wrong. That’s compounding at the system level.

Learning what you don’t know you’re doing

You can’t compound what you can’t see.

That /insights report I mentioned? It didn’t just show me friction patterns. It showed me that I delegate ambitious end-to-end workflows with clear goals but minimal upfront specs, then course-correct when Claude takes a wrong turn. I treat iterative redirection as my primary steering mechanism.

I didn’t know that about myself. I thought I was giving clear instructions. Turns out my interaction style is “give a vague goal, let Claude explore, then interrupt decisively when it goes off track.” That works, but it’s expensive. A lot of those 24 “wrong approach” corrections could have been prevented with one more sentence of context upfront.

/insights also showed me that my most successful sessions involve multi-file changes and debugging. Not writing new code, coordinating changes across 8+ files. That told me to invest more in architecture documentation, so Claude understands how the pieces connect before touching anything.

Most of us have blind spots about how we interact with AI. We repeat the same vague prompts. We consistently under-specify in the same ways. We have habits that silently cost us quality without realizing it. Tools like /insights make those blind spots visible. And visible problems are fixable problems.

The divergence

This matters right now more than it ever has.

Compounding has always existed. People who read books and applied the lessons compounded knowledge. People who reflected on their mistakes compounded wisdom. This isn’t new.

What’s new is the speed of the feedback loop.

Old compounding: read a book, apply a lesson, see results in weeks or months. AI compounding: have an interaction, learn what failed, fix it, see results in the next interaction. The feedback cycle went from months to minutes.

When feedback loops shrink like that, small differences in compounding discipline become enormous differences in outcome. Fast. The math on 1% daily improvement is 37x in a year. That’s not a typo.

And it’s not theoretical. I feel it. The gap between how I use AI today versus six months ago is staggering. Not because the models got that much better (they did, but that’s not the point). Because I compounded every single interaction into better instructions, better workflows, better mental models.

And I watch people around me, smart people, talented people, who are still pulling the slot machine lever.

The 30-second habit

Let me make this practical.

After every non-trivial AI interaction, do a 30-second post-mortem. You don’t need a journal. You don’t need a spreadsheet. Just the three questions.

What failed? Be specific. Not “the output was bad.” But: “It used camelCase when our codebase uses snake_case.” Or: “It over-engineered a dynamic system when I wanted hardcoded values.” Or: “It started coding before understanding the problem.”

Why did it fail? Almost always one of four things: you didn’t give it enough context, the context exists but isn’t somewhere the AI can access it, your instruction was ambiguous, or the AI made an assumption you didn’t catch.

How do I prevent this next time? Externalize the fix. Update your CLAUDE.md. Add it to your project’s memory files. Build it into a workflow. Add it as a rule.

Don’t keep the lesson in your head. Put it somewhere the AI can read it.

Your brain learning “always specify the approach before coding starts” is good. Your CLAUDE.md containing that rule is 10x better, because now every AI, every session, every team member benefits automatically. You learned the lesson once. The system remembers it forever.

The layers

A fully compounded AI setup has layers, and each one feeds the others.

Project instructions like CLAUDE.md. Your codebase conventions, architectural patterns, and “never do this” rules. All learned from real failures. Ours is 300+ lines and every line earned its place.

Memory files. Lessons learned across sessions, patterns that work, context that’s expensive to re-explain. Things like “always use self.session() context managers for database safety” or “frontend hooks must match backend paths exactly, including trailing slashes.” Your AI stops being a stranger every time you open a new conversation.

Workflows. Repeatable processes encoded as systems. /fix, /review-pr, /resolve. Each one born from a sequence of “this didn’t work, let’s fix it.” Getting better every time they run.

Meta-learning through tools like /insights. Patterns in your own usage, blind spots you didn’t know you had, continuous improvement of your improvement process.

Your insights improve your instructions. Your instructions improve your workflows. Your workflows surface new insights. It’s compounding all the way down.

The race you’re already in

This isn’t optional.

If you’re in any knowledge work, you’re already in a race where AI leverage determines your output. And the people who compound that leverage are pulling away from the people who don’t. Not linearly. Exponentially.

This is not about being an “AI power user.” It’s not about knowing the latest prompt tricks or having access to the newest model. It’s about the boring, unsexy discipline of learning from every single interaction and encoding that learning into something persistent.

The person who’s been compounding for six months doesn’t just have better prompts. They have project files that encode hundreds of lessons. Workflows that automate entire processes. Memory files that preserve context across sessions. Mental models refined by thousands of feedback loops. An AI that effectively knows how they think.

You’re not competing against that person’s raw talent. You’re competing against their compound interest. And compound interest is unbeatable given enough time.

The good news? It’s still early. The feedback loops are still fast. And the best time to start compounding was six months ago.

The second best time is your next AI interaction.

Start compounding at neople.io.

The more I shipped, the more valuable I felt. When people asked what I did, I’d say “I build things.” And by “build,” I meant something very specific: I write the code. I architect the systems. I ship the features. My hands on the keyboard, my logic in the codebase, my commits in the git history.

There’s a particular kind of satisfaction that comes from solving a hard problem in code. That moment when the tests pass. When the feature works. When you push to production and watch real users interact with something you built. It’s tangible. It’s measurable. It’s yours.

I optimized my entire career around that feeling.

But I’ve been lying to myself about what it actually means.

The uncomfortable math

Here’s what nobody tells you when you become a leader: every hour you spend deep in implementation is an hour you’re not spending on the thing that actually matters.

As a developer, the equation is simple. Your value equals your output. The code you write, the bugs you fix, the features you ship. More output, more value. It’s clean and satisfying.

As a leader, the equation inverts. Your value equals your team’s output. Not yours. Theirs.

And here’s where it gets uncomfortable: those two things are often in direct competition.

Last month, we had a bug that needed fixing. Nothing critical, but annoying. I knew exactly how to fix it. I could have had it done in an hour, maybe two. Instead, I spent 30 minutes explaining the problem to a junior developer, another hour pair-programming through the investigation, and then reviewed their PR the next day.

Total time: probably 3 hours of my involvement, spread across two days.

If I’d just done it myself? Two hours, done, move on.

So why didn’t I?

Because that junior developer now understands that part of the codebase. They learned a debugging technique they didn’t know before. Next time a similar issue comes up, they won’t need me at all. The hour I “lost” today bought dozens of hours in the future.

But here’s the thing: every instinct in my body screamed to just fix it myself. It would have felt so much more productive. So much more satisfying. So much more me.

The hero trap

There’s something deeply seductive about being the hero.

You know the pattern. A problem emerges. Something’s broken, or blocked, or just hard. You swoop in. You fix it. Everyone’s grateful. Your brain floods with dopamine. You feel essential, valuable, needed.

I’ve been that hero for years. The one who always knows how to fix things. The one people come to when they’re stuck. The one who can jump into any part of the codebase and figure it out.

It feels amazing. But it also creates a trap.

Because when you’re always the hero, you become a bottleneck. When you’re always the one who fixes things, your team never develops those muscles. When you’re always available to swoop in, people stop trying to figure things out themselves.

I’ve watched this pattern play out so many times. Someone on the team hits a problem. They struggle for a bit. They ask me. I solve it quickly because I’ve seen it before. They thank me and move on.

Everyone’s happy, right? The problem got solved. We shipped faster.

Except: that person learned nothing. Next time they hit a similar problem, guess who they’ll ask? And the time after that? I’ve accidentally trained my team to depend on me, and then I wonder why I’m overwhelmed and they’re not growing.

The uncomfortable truth I had to face: sometimes my “helping” was actually hurting.

My ownership was someone else’s missed opportunity to grow. My speed was the team’s bottleneck. My “just let me do it quickly” was a lesson someone else never learned.

I thought I was being efficient. I was being selfish. I was optimizing for my own satisfaction instead of the team’s capability.

The question that changed everything

A few months ago, I started asking myself a different question before jumping into any task:

“Who else could do this? And what would they learn from doing it?”

Not “who else should do this?” That’s easy to dismiss. Of course I should do it, I’m the fastest. But “who else could do this” forces a different kind of thinking.

The answer is almost always: someone else could do it. Maybe not as fast. Maybe not as elegantly. But they could do it, and they’d be better for having done it.

This reframe changed how I spend my time. Instead of asking “what’s the fastest way to solve this problem,” I started asking “what’s the best way for the team to solve this problem.”

Sometimes that still means I do it myself. Some things genuinely need my specific context or expertise. But way more often than I expected, the right answer is to step back.

The multiplier math

There’s a concept that keeps running through my head: multipliers versus diminishers.

Diminishers are brilliant individual contributors who happen to have leadership titles. They do the work themselves. They’re the smartest person in every room. They have all the answers. They move fast by doing everything themselves.

Multipliers are something different. They create space for others to grow. They ask questions that unlock insights. They move fast by enabling everyone around them.

The math is brutal but clear:

Hero math: 1 person × 100% efficiency = 1x output

Multiplier math: 5 people × 80% efficiency = 4x output

Even if you’re twice as good as everyone else (even if you’re the literal best in the world at what you do) the multiplier will always win. Because multiplication beats addition every single time.

This is obvious when you write it down. It’s incredibly hard to internalize when you’re in the moment, staring at a problem you know you could solve in an hour, watching someone else struggle through it over a day.

But every time I catch myself wanting to jump in, I try to remember: I’m not optimizing for today. I’m optimizing for next month, next quarter, next year. And the compounding effects of a capable, independent team absolutely dwarf whatever I could accomplish on my own.

The second revolution: AI changes the game

But here’s the thing: there’s another dimension to this that makes 2025 different from any year before.

We’re living through a moment where AI can genuinely build.

I don’t mean autocomplete. I don’t mean suggestions. I mean: describe what you want, review what comes back, iterate on the direction, ship the result.

Last month I needed a data migration script. Nothing fancy, but fiddly: lots of edge cases, careful handling of null values, proper error logging. Old me would have spent a morning writing it, testing it, handling the edge cases I discovered along the way.

Instead, I described the requirements to Claude. Reviewed the first draft. Pointed out a few edge cases. Got back a revised version with tests. Ran it. Done.

Total time from my hands: maybe 30 minutes. And honestly, the code was better than what I would have written. More thorough error handling. Better logging. Edge cases I hadn’t even thought of.

This isn’t a one-off. This is becoming my default mode. The ratio of “time spent typing code” to “features shipped” has completely inverted. I’m building more than ever while writing less code than I have in years.

From musician to conductor

I’ve started thinking about this shift as moving from musician to conductor.

As a musician, you play the instrument. You produce the sound. Your skill is in your fingers, your technique, your direct manipulation of the tools. There’s a ceiling to what you can produce, one person, one instrument, limited hours in the day.

As a conductor, you don’t play anything. You direct. You shape. You bring out the best in each section of the orchestra, balance the voices, keep everyone aligned toward the same interpretation. The music that emerges is vastly more complex than any single player could produce.

That’s what building software feels like now. I’m not the one typing the code. I’m the one directing what gets built, reviewing what comes back, iterating on the direction, making sure it all hangs together.

I still build. I still contribute meaningfully. The decisions I make—what to build, how it should work, what tradeoffs to accept—those matter enormously.

But I’m operating at a completely different altitude. Less typing, more thinking. Less doing, more directing. Less output, more outcome.

And the same principle applies to the human side of the team. My job isn’t to write the code. My job is to make sure the right code gets written, by the right people (human or AI), in the right way.

The compound effect

When you stop being the bottleneck (for your team and for yourself_ something magical happens. Things start to compound.

I can run multiple AI agents in parallel, each working on a different piece of a feature. I can spin up experiments that would have taken weeks and validate them in hours. I can test ideas that would have been “too expensive to try” and kill the bad ones fast.

Meanwhile, the team is growing into challenges they would never have faced if I kept swooping in. They’re developing judgment, building context, becoming the experts I used to be. Every week, there are more problems they can solve without me.

The result: more gets built, better than before, with less of my direct involvement.

This is what leverage actually feels like. Not working harder. Not being faster. Multiplying.

Why this is terrifying

I won’t pretend this transition is easy.

It’s scary to let go of the thing that defined you.

When your identity has been “the person who builds,” and suddenly you’re not the one typing the code, who are you? When your value was measured in commits and pull requests, and now you’re measured by team output, how do you know you’re still valuable? When you could always point to lines of code and say “I made that,” what do you point to now?

There are days when I feel like a fraud. Days when I wonder if I’m even a real engineer anymore. Days when I watch my commit count drop and feel a weird grief for a version of myself that’s fading away.

This isn’t just a behavior change. It’s an identity shift. And identity shifts are hard. They take time. They feel like loss before they feel like growth.

But I keep coming back to the question: what do I actually want to build? A monument to my own coding ability? Or something bigger than I could ever create alone?

The 2026 resolution

Write less code. Get more done.

This is my commitment for the year. Not because writing code is bad; I still love it, still find it deeply satisfying. But because I’ve finally internalized that my satisfaction isn’t the metric that matters.

Practically, this means catching myself before I jump into implementation. Asking who else could do this and what they’d learn. Defaulting to AI for tasks that don’t need my specific judgment. Reviewing and directing instead of writing. Measuring my success by what the team ships, not what I personally produce.

It means being okay with being less essential. Less heroic. Less visibly productive.

It means trusting that multiplication beats addition, even when addition feels so much better in the moment.

The counterintuitive truth

Here’s what I believe will happen:

By writing less code, I will build more than ever. Not despite writing less code. Because of writing less code.

The best version of 2026 me isn’t the one who wrote the most code. It’s the one who built the most… without writing any. The one who multiplied instead of added. The one who finally got out of his own way.

The invitation

If you’re a founder or leader who still writes most of the code... if your team can’t ship without you... if you’re the hero everyone relies on...

Maybe this is your resolution too.

The hardest part isn’t learning to delegate, or learning to use AI, or learning any new skill at all. The hardest part is unlearning the identity that got you here. Letting go of the satisfaction of being the one who fixes things. Trusting that the new way is better, even when it feels like less.

Here’s to getting out of our own way.

Building the future of work at neople.io. Where the goal isn’t to write more code—it’s to build more, together.

There was no clear playbook. No crisp category. No shared understanding in the market of what “AI at work” was supposed to look like. We were four people with a strong conviction that something fundamental in how people worked with software was broken, and that AI could shift it.

What we underestimated was how much would change around us while we were building.

The market shifted. The technology developed. Customer expectations changed. And we had to keep deciding, sometimes weekly, whether we were early, wrong, or just impatient.

This is a reflection on what actually happened over those three years, and what we learned building an AI company from the Netherlands, in public, and in real time.

Year one felt obvious, and that gave us momentum

In the beginning, things felt strangely clear.

AI was emerging. SaaS felt clunky. People were overwhelmed by tools. The idea clicked: a digital coworker that could take work off your plate and help teams operate better.

That clarity gave us momentum. It helped us move fast, make decisions, and get something real into the hands of customers.

What we learned along the way is that early clarity often hides complexity. The technology was promising, but uneven. Customers were interested, but still figuring out how this fit their work. Internally, product decisions were shaped as much by what was feasible that month as by what the longer-term vision suggested.

Over time, that taught us something important. There was never going to be a single straight line from idea to outcome. Progress would come from constant adjustment, not from following a fixed plan.

That understanding changed how we build. It made us more attentive to constraints, more patient with sequencing, and more deliberate about what to solve next.

We learned to build for a future that arrives in pieces

One of our biggest lessons was about timing.

We raised early rounds believing that classic SaaS patterns would fade quickly, and AI-driven systems would take over large parts of operational work. Directionally, we still believe that.

What we learned in practice is that technology matures in pieces. Some capabilities moved incredibly fast. Others took longer. That uneven pace shaped how customers could realistically use what we built.

Starting with a more service-heavy approach helped us learn deeply. It showed us where automation worked, where it broke down, and where people needed visibility and control. Those insights now directly inform the product we are building.

The takeaway was constructive, not discouraging. You cannot compress maturity, but you can design for it. When the tech is still forming, you need bridges that work today and foundations that support what comes next.

That perspective has made our product clearer, more grounded, and better aligned with how teams actually grow into new systems.

The market clarified faster than we expected

Early on, around early 2023, the main challenge was adoption.

People approached AI carefully. Teams wanted to understand limits, build trust, and stay close to decisions. The focus was on assisting and aiding the employee instead of automating complete workflows, and human control played an important role in making AI usable at all.

Then expectations moved quickly.

Customers began asking different questions. Where automation could take over. Where outcomes could be faster. Where AI could operate with more independence. The change was driven by better models, broader exposure to AI tools, and growing pressure inside organizations to move faster.

That shift taught us something valuable. We had learned how to build trust first. Now the market was ready to build on top of it.

Reworking product, positioning, and sales at the same time was demanding, but it also sharpened our understanding of what customers actually wanted next.

Building in the Netherlands kept us honest

There is something grounding about building a company here.

Dutch customers are direct. They ask what works, what doesn’t, and how long it takes. There is little patience for abstract futures without practical value.

We would sometimes have a conversation with investors about a post-SaaS world in the morning, and then talk to a customer in the afternoon who just wanted to know how we were different from a chatbot or what kind of APIs we had versus custom integrations.

Both perspectives were valid. Holding them at the same time was exhausting.

It taught us that vision cannot replace usefulness. If your product does not make someone’s Monday easier, the long-term story does not matter yet.

Customers often bought “AI” before they bought a solution

One thing that surprised us consistently was how rarely customers arrived with a sharply defined problem.

In classic SaaS, people show up with pain. Too slow. Too expensive. Too manual.

With AI, many showed up with something softer: pressure to adopt AI, pressure from leadership, or a sense that they were falling behind. Customer support seemed to be the most logical place for these teams to start with their first foray into AI, with clear and quick wins in staffing, seasonality, localization, and training.

This fact alone meant we were not just delivering a tool. We were helping customers figure out what to do with it and exploring the potential gains together.

Some thrived in that openness. Others struggled. The same product could feel transformative to one team and irrelevant to another. AI maturity varied wildly, even within the same industry.

This forced us to accept a difficult truth: product success in AI depends as much on readiness as on features.

Growth moments didn’t feel big when they happened

Some milestones only felt real in hindsight.

Raising our first round changed how seriously others took us, but also how seriously we had to take ourselves. Acquiring another team and suddenly being twenty people in a room made the company feel real in a new way.

Later, realizing that Neople was considered a serious player in its niche happened quietly. There was no single moment. Just a gradual accumulation of customers, conversations, and trust.

That pattern repeated often. The biggest shifts were slow while happening, and obvious only later.

What we learned after three years

We’re very aware of how privileged we are to be building a tech company in the AI space right now. We’ve been trusted by investors to explore uncertain territory, and by a team that shows up every day to build something that did not exist before. That combination of trust and timing is rare, and we don’t take it lightly.

Sharing what we’ve learned over the last three years is our way of giving something back, and of being honest about what actually happens when you try to build in a market that keeps moving under your feet.

1) There is no stable ground in AI, only moving reference points

Your product, your customers, and the technology evolve at the same time. Planning too far ahead creates false certainty.

2) Timing matters as much as ideas

Building a product that was perhaps too early still hurts. Vision needs to be paired with something customers can use now.

3) Customers buy readiness as much as capability

AI value depends on data, trust, ownership, and internal clarity. Software alone does not solve that.

4) Hiring speed amplifies both progress and chaos

Scaling roles quickly changes culture, decision-making, and momentum. Money increases responsibility faster than it increases clarity.

5) Building in a pragmatic market forces better products

Direct feedback and low tolerance for hype are painful, but they reduce long-term delusion.

Where we are now

Bas: Looking back, I still believe the core frustration we started with is real. Technology often forces people to adapt to it, instead of the other way around. We maybe underestimated how long it would take to change that properly, but I truly believe in a future where technology is more natural.

Hans: I think the real work is learning to hold ambition and reality at the same time. The future we believe in is still coming. Our job is to build something useful on the way there, without losing ourselves in either hype or fear.

Three years in, the biggest lesson is not about AI or SaaS.

It is about staying flexible without becoming generic, and stubborn without becoming blind.

And accepting that building a company is less about executing a plan, and more about adjusting your understanding faster than the world changes around you.

“In the future, anyone will instantly summon a stranger to move furniture for pocket change.”

They’d be laughed out of the room. The economics don’t work. The logistics are impossible. The trust mechanisms don’t exist.

But here we are. Taskrabbit exists.

It didn’t destroy professional movers. It created an entirely new category of casual, personal tasks that were never worth doing before.

The same impossible shift is happening with software right now.

When costs collapse

Something magical happens when the cost of something drops below a critical threshold:

Photography: Digital cameras made photos free, so instead of 24 carefully composed vacation shots, people take 500 photos at brunch.

Transportation: Uber made rides cheap enough that people take them for 6 blocks.

Food delivery: Apps made it cheap enough to order a single coffee.

The pattern: When costs collapse, we don’t just do the same things cheaper. We do entirely new things that weren’t worth doing before.

💻 The $3,000 barrier

For 50 years, software had a fundamental constraint: you needed someone who could write code.

The math:

• Engineer salary: $150K/year

• Minimum viable tool: ~1 week

• Cost per utility: ~$3,000

Software only got built if it solved a problem for many people, justified significant ROI, or someone cared enough to learn programming themselves.

Everything else? People suffered through it.

That spreadsheet you manually update every Monday. That report you copy-paste between 5 systems. That data transformation you do by hand.

We accepted that some problems were “too small” for software.

The economics broke

Creating software used to cost:

• $3,000 minimum

• Years of training

• Deep technical knowledge

Creating software now costs:

• $0.50 (Claude API call)

• 30 seconds of description

• Ability to describe a problem in English

That’s a 6,000x improvement.

When something gets 6,000x cheaper, you don’t just do it more. You unlock entirely new categories of use.

Consumable software

There’s now a category of software that:

• Disposable - Used once, then forgotten

• Ephemeral - Might not exist tomorrow

• Personal - Solves a problem for one person

• Regenerable - Easier to recreate than maintain

• Quick - Generated in seconds

This category was economically impossible for 50 years. Now it’s common.

Real examples from last month:

• A marketer generated a tool to extract social media links from pages. Used it twice. Forgot about it. Would regenerate if needed again.

• A recruiter generated a script to clean LinkedIn CSV exports. Used it for one campaign. Never thought about it again.

• A PM generated a tool to combine 3 Notion databases. Used it for one report. Doesn’t remember where it is. Doesn’t care.

None of them know how to code. None maintained their code. None even saved it. And that’s completely rational.

Two categories of software

Software as a Product (still needs engineers):

• Used by thousands/millions

• Maintained over years

• Quality matters deeply

• Revenue model

Examples: Figma, Notion, banking apps

Software as a Consumable (anyone can make):

• Used by one person

• Exists for minutes/days

• Quality barely matters

• No revenue, just utility

Examples: “Combine these CSVs,” “Extract emails from this text,” “Convert this format to that format”

The first category didn’t change. It still needs engineers. The second category didn’t exist before. Now it does. This isn’t about engineers writing worse code. It’s about non-engineers creating software for the first time.

The coming flood

What happens when 8 billion people can suddenly create software?

When everyone got cameras: Didn’t destroy professional photography. Created billions of personal photos. Instagram emerged.

When everyone got video cameras: Didn’t destroy Hollywood. Created billions of personal videos. TikTok emerged.

When everyone got publishing platforms: Didn’t destroy journalism. Created billions of blog posts. Medium emerged.

Now everyone can create software: Won’t destroy engineering. Will create billions of personal utilities. The platform hasn’t emerged yet.

Just like Instagram couldn’t exist before casual photography was possible, we don’t yet know what will emerge when casual software creation becomes normal.

Problems worth solving

Remember all those “too small” problems?

Sarah (HR): “Cross-reference employee emails with benefits enrollment.”

Before: 2 hours of manual Excel work, monthly

Now: “Claude, find emails in A but not B.” 30 seconds.

Marcus (small business): “Generate invoices from my spreadsheet.”

Before: Hire developer ($500-1000) or manual torture

Now: Describe the format. 1 minute.

Jen (analyst): “Extract URLs from 50 PDFs and check if they work.”

Before: Impossible without technical help

Now: 2 minutes.

These aren’t products. They’re personal utilities that solve a problem once and cease to matter. They’re consumable.

Regeneration vs maintenance

Traditional software lifecycle:

1. Write code

2. Document it

3. Maintain for years

4. Fix bugs

5. Refactor

6. Live with technical debt

Consumable software lifecycle:

1. Generate it

2. Use it

3. Forget it

4. Regenerate if ever needed again

When generation is faster than maintenance, maintenance becomes irrational. This is backwards from 50 years of software wisdom. And that’s okay – this is a different category.

The quality is irrelevant (for consumables)

For consumable software, quality barely matters.

Doesn’t need to: scale to millions, be maintainable, be documented, follow best practices, be elegant, be particularly secure or performant

Does need to: work right now, solve this specific problem

That’s it.

This drives engineers crazy. We’ve been trained that quality matters. And it does – for products.

But consumable software is like a paper towel. Single-use, disposable, solves an immediate problem. Insisting every paper towel be archival-quality museum-grade paper would be insane. Yet that’s what we did with software for 50 years – because we had no choice.

What this means for engineers

The good news: Your job isn’t going away.

The great news: Your job is getting better.

Before: 40% of engineer time building throwaway utilities for other teams

After: 5% of time on utilities (everyone generates their own). Focus on products, core infrastructure, complex systems.

Engineers are being freed from the “too small for a product, too technical for normal people” zone. That zone is becoming accessible to everyone. That’s liberating, not threatening.

The Neople perspective

People using Nora (our AI colleague) increasingly generate little tools for themselves: data transformations, workflow automation, quick reports.

They don’t call them “software.” They think of them as “getting the task done.”

But that’s what they are: disposable, personal software.

The shift we’re enabling isn’t “better software engineering.” It’s “software creation for everyone.”

The platform that didn’t exist yet

Instagram couldn’t exist before smartphone cameras. YouTube couldn’t exist before accessible video. Twitter couldn’t exist before everyone could publish text.

So what platform will exist when everyone can generate software?

Maybe a marketplace for prompts instead of code. A system for sharing and remixing generated tools. A web where everyone can customize everything. Something we can’t imagine yet.

We’re at the “everyone has a camera phone” moment for software.

The Instagram moment is still coming.

The shift is starting

We’re at the very beginning:

Today: Non-technical people generating tools. People regenerating instead of maintaining. Prompts being saved instead of code. Software treated as disposable.

In 12-18 months: Billions of pieces of consumable software. Platforms emerging to share and remix. Software creation as common as document creation. Engineers focused entirely on products.

For 50 years, software was scarce because creation was expensive. For the next 50 years, software will be abundant because creation is free.

Everything changes.

Full circle

Taskrabbit didn’t make professional movers obsolete. It created a category that shouldn’t exist: “casual, personal furniture moving.”

Before Taskrabbit, you either did it yourself or hired professional movers for thousands of dollars. No in-between. The economics didn’t work.

Now there’s an in-between. And it’s massive.

Consumable software is the same: too small for a product, too personal for enterprise, too cheap to justify professional development.

But now it exists. And it’s being created by everyone, not just engineers.

Software is becoming a consumable. Not because professional software is dying. But because a whole new category of personal, disposable, regenerable software is being born.

Watching the birth of consumable software at neople.io. Where anyone can generate the tools they need, use them once, and move on with their life.

That’s not what happened.

What actually happened is messier, and probably more familiar if you’re building something yourself.

We ran into limits. Over and over. Limits in people, limits in time, limits in how fast we could move without everything falling apart. And instead of solving those limits by adding more layers or more hires, we kept reaching for whatever let us keep going.

More often than not, that was software. Increasingly, that was AI.

Only later did we realise we’d crossed some invisible line.

I still don’t love the definitions, but here’s the best way I can explain it:

An AI company builds AI products. An AI first company assumes that knowledge work itself can be redesigned. Not optimised, redesigned. The question shifts from “who should do this” to “why does this exist in this form at all.”

Once that shift happens, it’s hard to unsee.

There’s a popular story going around right now about tiny teams doing huge numbers, and the explanation is usually that they’re just using the right AI tools. I think that story is comforting, because it makes success sound like a tooling choice. Pick the right stack, move faster, win.

But small teams with outsized output existed long before the current wave of AI. People built highly automated businesses with boring scripts, fulfilment partners, and unglamorous systems. The difference now is not that automation exists, it’s where it reaches. Work that used to require specialists early on, things like legal reviews, financial checks, first drafts of designs, exploratory code, internal tooling, can now be done well enough by one person to keep momentum.

Not perfectly. Not magically. But well enough.

That “well enough” matters more than people like to admit.

Constraint as the actual driver

Inside Neople, we never made a rule that said “use AI for this.” We also never sat down and mapped out every process and asked where AI could be slotted in. That approach, in my experience, tends to produce a lot of activity and very little real change.

What we did instead, often without naming it, was remove escape hatches.

If something needed to get done and there wasn’t an obvious person to hand it to, the work didn’t disappear. Someone had to find a way. Sometimes that meant automation. Sometimes it meant a model. Sometimes it meant realising the task itself was unnecessary and just deleting it.

That last option is still the most powerful one, and the least talked about.

I’ll be honest about something that feels slightly uncomfortable to say out loud. The biggest driver of becoming AI first was not excitement or vision. It was constraint.

When you don’t have a junior developer to offload smaller tasks to, you try to see how far you can get on your own. When you don’t have a designer available, you learn to generate and iterate assets yourself. When you don’t have legal support on hand, you learn to do the first eighty percent and escalate the truly risky parts.

Scarcity has, I think, always pushed people toward efficiency. That’s not new. What’s new is how much one person can do once they’re forced into that mode. The tools amplify effort, but the mindset comes from having no alternative.

Something I didn’t expect

There’s a second thing that happened, and I didn’t fully appreciate it at first. When everyone becomes more capable of doing things outside their lane, boundaries blur. Designers can challenge technical decisions because they can actually prototype alternatives. Engineers can challenge design decisions because they can generate and test variations quickly. People stop having opinions in the abstract and start showing working versions.

That creates friction. It also, I think, creates better outcomes, if you can tolerate the tension.

Traditional teams feel calmer partly because crossing into someone else’s area is expensive. AI makes that cheap. The real challenge stops being adoption and starts being collaboration. How do you work together when everyone has more agency than before?

I don’t think we’ve solved that yet. I do think it’s a real shift that deserves more attention than it gets.

There’s also a people side to this that’s easy to get wrong. The moment someone feels something is being taken away, they stop listening. It doesn’t matter how good the long-term argument is. Loss shuts the conversation down.

AI triggers that reaction fast. If “AI first” is framed as fewer hires, less support, more pressure, resistance is inevitable. Even if the upside is real.

What seems to work better is a combination of two things happening at the same time. Clear personal upside, and real constraints. Not “use AI more,” but “find a way to get this done,” paired with leaders actually doing the work themselves.

Once it’s visible, it stops being theoretical.

If I were starting from scratch

I wouldn’t begin with training sessions or tool rollouts.

I’d start with myself. Pick a task I usually delegate, struggle through doing it with the tools available until the result is good enough, then show how I did it. Not as a mandate. Just as a reference point.

After that, the more important work begins. Going back to first principles. What actually needs to happen for the company to move forward. What assumptions are being carried simply because they used to be true. What work exists only because it always has.

Most of the real gains, I think, don’t come from smarter execution. They come from removing work entirely.

Looking further ahead, I don’t think the future is people versus AI. It’s different kinds of people doing different kinds of work. More time spent designing systems, setting boundaries, deciding how agents should behave. More focus on customer-facing roles, because trust and context still matter a lot while the technology keeps shifting underneath us.

At the same time, I expect we’ll keep increasing the number of agents we run internally. Not because it’s fashionable, but because once you experience the speed of “I can just try this,” waiting starts to feel expensive.

That’s been the biggest emotional shift for me. Not excitement. Not fear.

Impatience.

And if you’re feeling some version of that too, you’re probably closer to being AI first than you think.

You’ve got something working. Customers are coming in. Growth is happening. But you know (usually, somewhere deep in your gut at 3AM) that what got you here won’t get you there.

So you have to take a risk. Change something fundamental. Place a bet on the future before you can afford to lose.

The hard part isn’t taking the risk. It’s knowing which one to take. And when.

Let me tell you about Ollo.

The problem we thought we had

Picture this: You’re growing fast. Customers love what you do. But they keep asking for more. Not just “can you add this feature?” More like: “Can your AI do everything?”

That’s what we were hearing from customers and prospects earlier this year.

We made Neople as a customer support agent. It was good at that. Really good. But customers didn’t want a specialist—they wanted an all-rounder coworker. Someone who could learn their processes, integrate with their tools, handle whatever they threw at it.

The question became clear: Are we a tool that’s going to resolve your customer support questions? Or are we a solution that customers can use to automate their customer support questions?

Subtle difference. Massive implications.

So we had a choice. Keep refining what we knew worked. Or bet on what might work better.

We took our bet.

Enter Ollo: the everything agent

Neople was a customer support agent. Ollo was your everything agent.

It was our answer to “what if?” What if we made something universal? What if people could just talk to it and build workflows without touching a single node or configuration screen?

A new colleague joins the team, can integrate with everything, and you just by talking make it work. That was the mission.

We split the team. Gave a small group full focus. Told them: move fast, stay nimble, build the future.

And they did. Sort of.

The part where it gets interesting

Here’s what we learned: We changed too many things at once.

New Ideal Customer Profile. New go-to-market motion. New product paradigm. New technical foundation.

We changed too many parameters at the same time, which was making it even harder for ourselves to be successful. Too many moving parts to achieve the full focus we intended and knew was necessary to ship an MVP.

Rookie move? Maybe. But also: necessary.

Because the market was moving. Agentic AI was becoming real. Customers were ready for something different. If the market is ready, then it will come and it will come fast, especially in the AI space. So then you try to be first or try to be faster.

So we jumped. And we learned mid-air.

What we actually built

Ollo ran for about six weeks of real user testing. Not long. Probably too short to really see if it was successful or not, if I’m being honest.

But long enough to see what worked and what didn’t.

What didn’t: The everything-for-everyone approach. It was deliberately broad. Which means that you’re solving too many issues at the same time. Making it complex and making it unclear.

What did: The underlying architecture. The agentic reasoning. The conversational-first design philosophy. The idea that people should get value in thirty seconds, not three months.

We pulled the plug on Ollo as a standalone product. But we didn’t throw it away.

The unexpected gift

Here’s where it gets good.

All that technology we built? All those assumptions we challenged? They’re now baked into the newest version of Neople. Not as a separate product, but as the foundation of what we do.

We moved from retrieval-augmented generation to agentic reasoning. The whole paradigm for how to work with AI has shifted to agentic. From rigid prompting to intelligent decision-making. From “set up your knowledge base first” to “start talking and see what happens.”

We started with the starting point that you have to get value in thirty seconds. Getting value out of the product in a shorter amount of time. That’s a better starting point than from three months and moving back.

Ollo forced us to rethink everything. And when we came back to our core product, we saw it with fresh eyes.

Five things we learned (so maybe you don’t have to)

1. You can’t run two companies in one

Focus isn’t optional. You need it to move fast. Even when we tried to isolate the team, full focus proved impossible inside the same company. Pick one bet. Make it count.

2. Timing is a bet on technology itself

You constantly have to make a bet on how far the technology will be in half a year or a year from now. We were early. The models weren’t quite ready. Browser automation needed more scaffolding than we’d hoped. Sometimes being early is exactly where you need to be, but it’s still a gamble.

3. Always bet on laziness

I will always bet on laziness. If something is simpler to do, cheaper to do, easier to do—it wins. Eventually. Always. People try to take a shortcut. Exactly. Build for that instinct.

4. It’s easier to go broad than to go narrow

It’s easier to move from individual to enterprise than from enterprise to individual. Starting from “make it simple enough for anyone” beats starting from “make it powerful enough for enterprises” and working backward. It’s harder for a SAP to move to a small business owner than for a Shopify to move to Adidas.

5. The right amount of specific matters more than you think

You can quite easily make an overfit product where you’re trying to solve one specific thing, which can be easily quite successful. But it’s harder to break out of it. The trick is finding the right specificity. The right moment. The right bet.

What comes next

We’re not done experimenting. Not even close.

But now we know: focus matters more than ambition. Solving one thing brilliantly beats solving everything adequately. And sometimes the best outcome of an experiment is learning what not to do.

On one hand, you could say, “Oh, okay, Ollo doesn’t exist now.” On the other hand, it does exist, actually. Parts of it exist in our current product.

Ollo doesn’t exist as a product anymore. But it exists in every line of code we write. Every conversation our Neople have. Every customer who gets value in seconds instead of months.

We built the wrong product. And that was exactly right.

We’re building in public at Neople and sharing the messy, uncertain, occasionally backwards journey of creating something new. If you’re building something too, I hope this helps. Even if it’s just knowing you’re not the only one who takes the scenic route.

Last week, I increased a timeout on a single API call to two minutes.

Not for complex machine learning inference. Not for processing terabytes of data. Not for rendering 3D visualizations.

For this query: “What’s the latest order for this email address?”

We now wait up to two minutes to answer a question a competent intern with a spreadsheet could answer in ten seconds. And here’s what’s driving me insane: we just accept this. We shrug and say “OMS integrations are slow” like it’s a law of physics instead of a choice.

The absurd comparison

Meanwhile, I can ask Claude to analyze a complex codebase, write an essay on philosophical concepts, generate a complete API with tests, debug race conditions, or explain quantum physics to a five-year-old.

Response time? Three seconds.

We have systems processing questions of arbitrary complexity, returning answers that would’ve taken teams of researchers weeks to compile – faster than you can say “please hold.”

But a simple database lookup? Two. Entire. Minutes.

Your charger sent us to the moon

Your $25 USB-C charger has more computing power than the Apollo 11 Guidance Computer. Not a little more. 563 times more processing power.

That afterthought accessory is vastly more powerful than the computer that calculated trajectories to navigate 240,000 miles through space and bring astronauts safely home.

So why does looking up an order take 120 seconds?

What we can and can’t do

What we CAN do:

• Train neural networks with billions of parameters

• Stream 4K video to billions of people simultaneously

• Sync data across continents in milliseconds

• Put AI chips in chargers (they negotiate power delivery in real-time)

What we apparently CAN’T do:

• Basic database lookups in under a minute

The same industry that puts AI in your charger can’t figure out how to index a database properly.

The boiling frog

We’ve developed collective tolerance for terrible software. Each year, things get slightly slower, slightly more bloated, slightly more “that’s just how it works.” And because it’s gradual, we adapt.

We add caching layers. Implement retry logic. Increase timeouts. Tell users “this might take a while.”

We’ve normalized waiting.

We have an entire design language dedicated to making waiting feel less terrible: spinners, progress bars, skeleton screens.

What if instead of designing better loading states, we just made things fast?

Complexity isn’t an excuse

I know why the OMS query is slow. Years of technical debt. Legacy systems. Databases that were never meant to scale this way. Integrations bolted onto integrations. Third-party APIs. Vendors who won’t prioritize performance.

Complexity is real. But we’ve accepted it as an excuse rather than treating it as a problem to solve.

Somewhere along the way, “it’s complicated” became a valid reason for terrible performance. We’ve let our systems become so Byzantine that two-minute queries seem reasonable.

The real problem

Companies running LLMs:

• Millions of requests per day

• Billions of parameters per request

• Natural language understanding (science fiction a decade ago)

• Response time: 3 seconds

Your database:

• Looking up a single row

• Technology from the 1970s

• Response time: 120 seconds

The problem isn’t that we lack the technology. We’ve built systems so poorly that even simple operations require heroic infrastructure to function at all.

A failure of priorities

At Neople, this frustration drives how we think about software.

When Nora (our digital colleague) can understand complex workflows and adapt to human needs in real-time, but a basic order lookup takes two minutes? That’s not a technical limitation – that’s a failure of priorities.

We’ve been so focused on adding features, scaling up, and moving fast that we forgot to ask: “Does this actually work well?”

Not “does it work?” but “does it work well?”

We have the technology

Look at your laptop charger. That little box is more powerful than the computer that took us to the moon.

Now think about the last time you waited 30 seconds for a page to load. The last timeout error. The last “system is running slow today.”

We have orders of magnitude more computing power than the engineers who achieved humanity’s greatest feats.

We just need to stop accepting slow as the default.

If we could navigate to the moon with less computing power than your charger, we can look up an order in under two minutes.

• Not in five years

• Not “eventually”

• Within twelve months (95% certainty)

• Within six months (80% certainty)

Not just less important. Actually optional.

If you get pride from writing beautiful, elegant code – from perfect abstractions and the craft itself – I’m genuinely sorry. That skill is about to become as relevant as hand-cranking a car engine. And “about to” means this year.

But if you get pride from solving real problems, shipping products that help users, understanding customer pain so deeply you can’t sleep until it’s fixed – you’re about to enter your golden age.

Developer vs Engineer

Two people. Both technically proficient. Both can write clean code. One critical difference:

Person A gets a ticket: “Add export to CSV functionality”

1. Reads acceptance criteria

2. Writes the code

3. Adds tests

4. Submits PR

5. Picks up next ticket

Result: Beautiful, well-architected code.

Person B gets the same ticket.

1. “Why do users want CSV export?”

2. “What are they doing with this data?”

3. Discovers: users export to CSV just to filter in Google Sheets

4. Realizes: “Our filtering sucks”

Result: Solves the actual problem.

In a world where AI writes both solutions in seconds, only one of these people is valuable.

It’s already happening

I’m not predicting the future. I’m describing today.

Right now, I can describe a feature to Claude or Cursor and get production-ready code. Not boilerplate. Full features with tests, error handling, and edge cases I hadn’t considered.

Six months ago: AI-assisted coding was impressive but limited

Today: Transformative

In six months: Manual coding will feel like using a typewriter

The trajectory is exponential. We’re past the inflection point.

Where pride lives

The best developers – the ones who obsess over clean code and elegant solutions – often struggle most when features get deleted.

You spend three weeks building something beautiful. Refactor it twice. Write comprehensive tests. Then two months later: users don’t care, feature doesn’t work, delete 3,000 lines.

If your pride was in the code: Devastating. Three weeks gone. Beautiful architecture deleted.

If your pride was in learning: Progress! You helped the company learn faster. You discovered what NOT to build. That’s valuable.

Nobody remembers your code

No one has ever remembered a company because their code was clean.

Stripe, Figma, Notion – they didn’t win because of pristine codebases or perfect architecture. They won because they solved real problems better than anyone else.

The code was just a tool. Often, the winners were the ones willing to write “worse” code to ship faster and learn quicker.

Code quality matters – but only insofar as it helps you iterate faster, fix bugs quicker, and ship more confidently. It’s a tool for building better products, not an end in itself.

Two camps

I’m watching people divide into two camps:

Camp 1: “If AI can write code, what’s my value?”

• Identity built on being “the person who codes”

• Pride from technical prowess

• Existential crisis when AI codes too

Camp 2: “Finally, I can build all the things I imagined!”

• Saw code as a tool (often a slow, error-prone tool)

• Pride from solving problems

• Thrilled the tool just got 10x better

We’re hiring for Camp 2.

What we’re looking for

At Neople, we want people obsessed with customers.

People who:

• Want to understand why a user sent a confused email at 2 AM

• Dig into support tickets to understand frustration, not just close them

• Can’t stop thinking about making the product better

People who see a two-minute API timeout and get angry – not because the code offends them, but because making users wait offends them.

People who understand “the code is clean” means “we can ship features faster,” not “I’m a good engineer.”

Your value isn’t: Writing perfectly optimized algorithms

Your value is:

• Understanding what problem needs solving

• Breaking complex problems into solvable pieces

• Judging when a solution is good enough to ship

• Knowing when to cut losses and try something different

• Connecting user feedback to product decisions

• Prioritizing ruthlessly based on impact

These are product skills. Engineering skills in the truest sense. Not coding skills.

The magic wand test

Here’s how you know which camp you’re in:

Tomorrow, we give you a magic wand. You can build any feature instantly, without writing code. It just appears, working perfectly.

What do you do?

“Wait, but how would I spend my time?”

→ You’ll struggle in the next six months. Not years. Months.

“Oh my god, I have so many problems I want to solve!”

→ We’re looking for you. We need you now.

The shift is here

We’re not approaching the end of “software developer” as a career. We’re in it. The transition is happening in real-time.

By mid-2026, most people building products won’t write code. They’ll direct AI agents, just like most product builders today don’t design circuit boards – they buy components and assemble them.

The valuable skill is already knowing what to build, who you’re building for, when something is good enough, and having the courage to delete what isn’t working.

We’re already in a world where code is nearly free. The only thing that matters is building the right thing.

What this means for Neople

At Neople, we’re not just building AI agents – we’re using them to build our product. We’re living in the future we’re creating.

The bottleneck is never the code. It’s always understanding: what users need, what’s working, what to build next.

The engineers who thrive here ask the best questions. They challenge requirements. They push back when something doesn’t make sense. They advocate for users even when it’s inconvenient.

They treat code as a tool, not a craft. They’d rather ship something imperfect today than perfect next month. They measure success in customer impact, not lines of code.

The invitation

If you’re feeling defensive about your code, your craft, the years you spent learning to write beautiful software – I get it. Change is hard.

But if you’re feeling excited – if you’ve always been more interested in the why than the how, more excited about solving customer problems than refactoring code – we should talk.

The future of software engineering isn’t about writing better code. It’s about building better products. And we need people eager to make that shift.

Building the future of software at neople.io. Where code is the tool, not the goal.

Subscribe now

They explore real-world adoption gaps, global compute races, potential weaponization, Europe’s regulatory lag, and the looming question of whether humans will keep a hand on the wheel — or quietly step aside while AI builds.

For two decades, “Clean Code” has been the engineering bible. We’ve obsessed over perfect abstractions, elegant patterns, and code that reads like poetry. We’ve spent hours debating naming conventions, refactoring for purity, and achieving that mythical 100% test coverage.

Here’s the uncomfortable truth: your users don’t care.

They don’t care if your code is clean. They don’t care about your SOLID principles. They don’t care if you used dependency injection or if your functions are under 20 lines.

They care if your product works. If it delights them. If it solves their problems.

And now, with LLMs, we can finally optimize for what actually matters.

The old religion

Clean Code made sense in its time. When humans were the bottleneck, when every line needed to be understood and maintained by other humans, when refactoring was expensive and bugs were hard to find.

We built cathedrals of code. Beautiful, elegant, pristine. We’d spend days crafting the perfect abstraction, weeks refactoring for cleanliness, months building frameworks for problems we might have someday.

Meanwhile, our users waited. Features shipped slowly. Bugs lingered while we debated architecture. We prioritized code quality over product quality, telling ourselves they were the same thing.

They’re not.

Enter the LLMs

Here’s what changes everything: LLMs don’t care about your code quality either.

They don’t get confused by long functions. They don’t mind repetition. They’re not impressed by your clever abstractions. They just need clarity and context.

Suddenly, the cost of “messy” code plummets. That spaghetti function you were going to spend a day refactoring? An LLM can understand it, modify it, and test it in minutes. That repeated code across five files? The LLM will update all instances flawlessly.

The bottleneck has shifted. It’s no longer “how maintainable is this code?” It’s “how fast can we ship value to users?”

The new religion: Great products

In the age of AI-assisted development, we optimize for different things:

Ship speed over code elegance: That feature your users are begging for? Ship it today with “messy” code rather than next week with “clean” code.

Documentation over abstraction: Instead of clever patterns that self-document, write explicit docs everywhere. LLMs will keep them updated.

Redundancy over DRY: Repeat yourself. It’s fine. LLMs don’t get bored updating multiple places.

Explicit over implicit: That “elegant” implicit behavior? Make it boringly explicit. LLMs need clarity, not cleverness.

Product metrics over code metrics: Stop measuring test coverage. Start measuring user satisfaction.

What this actually looks like

Let me be concrete. Here’s code from our production system:

// Old way: “Clean”
class EmailService extends AbstractMessageService {
  constructor(provider: IEmailProvider) {
    super(provider);
  }

  async send(message: Message): Promise<void> {
    return this.provider.dispatch(message);
  }
}

// New way: “Great Product”
async function sendEmail(to, subject, body) {
  // This function sends emails. It’s used by:
  // - Password reset flow
  // - User notifications
  // - Admin alerts

  console.log(`Sending email to ${to}`);

  if (!to || !subject || !body) {
    throw new Error(’Missing required fields: to, subject, and body are all required’);
  }

  try {
    await gmail.send({ to, subject, body });
    console.log(’Email sent successfully’);
  } catch (error) {
    console.error(’Failed to send email:’, error);
    // Try backup provider
    await sendgrid.send({ to, subject, body });
  }
}

The second version would make Clean Code advocates weep. It’s longer, has console.logs, mixes concerns, has no abstraction. It’s also:

• Instantly understandable

• Debuggable without diving through inheritance chains

• Modifiable by any LLM without context about our architecture

• Shipping value while the first version is still being architected

Follow Neople for more heretical takes on building great products that users actually care about.

The liberation

Letting go of Clean Code is liberating. Instead of agonizing over the perfect design pattern, I’m shipping features. Instead of refactoring for elegance, I’m fixing user-reported bugs. Instead of writing clever code, I’m writing clear code.

My code is messier. It has more documentation than logic. There’s redundancy everywhere. Console.logs litter the codebase. Functions are too long. Files are poorly organized.

And our product has never been better.

User satisfaction is up. Feature velocity has 10x’d. Bugs get fixed in hours, not weeks. We ship experiments daily instead of quarterly.

The heresy that’s actually wisdom

This is heresy in traditional software circles. I’m advocating for what we’ve been taught to avoid: messy code, poor abstractions, violated principles.

But principles are means, not ends. The end is great products that delight users. If messy code gets us there faster in the age of LLMs, then messy code is the right choice.

Your users don’t open your codebase. They open your product. Optimize accordingly.

The new principles

If Clean Code had its principles (DRY, SOLID, etc.), Great Product development has its own:

1. User value over code quality: Every decision should prioritize user impact

2. Clarity over cleverness: LLMs need to understand your intent instantly

3. Speed over perfection: Ship today, iterate tomorrow

4. Documentation over abstraction: Explain everything, assume nothing

5. Product metrics over code metrics: Measure what matters to users

The future is already here

This isn’t theoretical. Teams using LLMs are already making this shift, whether they admit it or not. They’re shipping faster with “worse” code and better products.

The old guard will resist. They’ll point to technical debt, maintenance nightmares, and the collapse of software craftsmanship. They’re fighting the last war.

In the new world, technical debt is paid by LLMs in milliseconds. Maintenance is a conversation with an AI. Craftsmanship means crafting great products, not great code.

Your choice

You can stick to Clean Code. You can keep crafting perfect abstractions while your competitors ship features. You can maintain your principles while your users switch to products that actually solve their problems.

Or you can embrace the new reality. Write messier code. Ship faster. Focus on product quality over code quality. Let LLMs handle the maintenance burden while you handle the user delight burden.

From Clean Code to great products. Your users are waiting.

Building great products with messy code at neople.io. Our users don’t care about our code quality. They care that we ship what they need, when they need it.

Still here? Excellent. Let me show you how I’ve turned software development into an AI orchestra.

The setup: read-only safety net

Here’s the foundation of my workflow:

monorepo-collection/
├── CLAUDE.md               (How to work with this codebase)
├── TECHNICAL_OVERVIEW.md   (Architecture, patterns, conventions)
├── main/                   (READ-ONLY, always on main branch)
├── agent-1-feature/        (git worktree)
├── agent-2-bugfix/         (git worktree)
├── agent-3-refactor/       (git worktree)
└── ...

The main folder is sacred. It’s read-only, always on the main branch, never touched by agents. This is my safety net – a clean reference that agents can read but never corrupt. When an agent needs to understand our codebase, they look here. When they need to edit, they work elsewhere.

The orchestra begins

My day starts by spinning up multiple Claude Code agents. Each gets assigned differently:

• Agent 1: Gets a Linear ticket through my MCP (Model Context Protocol) connection. It reads the ticket, understands requirements, checks related issues.

• Agent 2: Gets a brain dump: “Hey, that thing we discussed about optimizing the skill execution pipeline...”

• Agent 3: Gets context from a Slack conversation: “Users are reporting slow load times on the dashboard”

Every agent has access to our global context document – a Claude-written markdown file that explains our architecture, where features live, coding standards, common patterns. It’s like giving each agent a company handbook on day one.

The plan before the code

Here’s where it gets interesting. Before any agent writes a single line, they create a plan. (Shift+Tab twice in Claude Code to enter plan mode, for those following along.)

The plan includes:

• Understanding of the problem

• Proposed solution approach

• Files they’ll need to modify

• Potential risks or dependencies

• Questions if anything’s unclear

I review these plans like a technical lead reviewing design docs. “Agent 2, you’re missing the edge case where users have no skills. Agent 3, that optimization will break our caching layer.”

Parallel development on steroids

Once I approve a plan, the magic happens. Each agent automatically:

1. Creates a new git worktree: git worktree add ../agent-{timestamp}-{feature-name}

2. Starts implementing in their isolated environment

3. Commits with meaningful messages

4. Pushes to a feature branch

5. Creates a PR following our template

I’m running 5-6 of these in parallel. While Agent 1 is implementing authentication changes, Agent 2 is refactoring our notification system, and Agent 3 is adding new API endpoints.

The review loop of madness

Here’s where it gets meta. Once an agent creates a PR, a GitHub Action spins up another Claude instance to review the code. An AI reviewing an AI’s code. We’re through the looking glass here.

The review catches things like:

• Style violations the linting missed

• Potential performance issues

• Security concerns

• Missing test cases

• Architectural inconsistencies

Then I review the review AND the code. It’s reviews all the way down. I’m checking:

• Did the agent understand the requirements?

• Did the reviewer catch all issues?

• Are there subtle bugs both AIs missed?

• Does this actually solve the user’s problem?

The new bottleneck: human verification

This workflow has completely flipped our constraints. Before, I was limited by how fast I could type. Now I’m limited by:

1. Testing capacity: I can generate 20 PRs a day, but can I properly test 20 features?

2. Context switching: Jumping between 6 different features taxes my brain like nothing else

3. Quality assurance: Ensuring each feature actually works in production, handles edge cases, provides good UX

We’ve gone from “we need more developers” to “we need more testers and reviewers.” It’s a fundamental shift in how software teams need to operate.

Evolving my verification flow

I’m constantly improving my guardrails to reduce time in verification:

Automated smoke tests: Every PR now auto-runs through user journey tests. If users can’t complete basic flows, I don’t even look at it.

AI-written test plans: I have agents write comprehensive test plans for their own features. “Here’s what to test, here’s what could break, here’s the edge cases.”

Preview environments: Every PR gets its own deployed preview. No more “works on my machine” – I can click a link and see it running.

Structured review templates: Instead of freestyle reviewing, I follow checklists. Does it handle errors? Is the UX consistent? Are there security implications?

The goal is to shift from “I need to deeply understand this code” to “I need to verify this works correctly.” Different skill, different mindset.

The mental model shift

The biggest change? I’m no longer thinking in terms of “how do I implement this?” but rather:

• How do I decompose this for AI understanding?

• What context does the agent need?

• How can I verify this was built correctly?

• What’s the highest-leverage use of my human judgment?

I’m rebuilding my entire approach to software development every few weeks as I discover new patterns and optimizations. It’s exhilarating and exhausting.

What actually breaks

Let me be real about what doesn’t work:

• Agents sometimes create circular dependencies between PRs

• They occasionally modify files in unexpected ways

• The review agent might miss context from other parallel work

• Integration tests become nightmares with 6 parallel feature branches

But the productivity gains are so massive that working through these issues is worth it.

From clean code to great product

Here’s something wild I’m discovering: our codebase needs to evolve for our new colleagues. I’ve been tracking every error Claude Code hits, and patterns emerge. The agent expects files in certain places, looks for documentation that doesn’t exist, assumes conventions we never established.

But here’s the real insight: we’re not moving from “Clean Code” to some other coding philosophy. We’re moving from “Clean Code” to “Great Product”.

None of your customers care about your code quality. They don’t care about your test coverage, your linting rules, or your elegant abstractions. They care about whether your product works, delights them, and solves their problems.

LLMs let us stop obsessing over code craftsmanship and start obsessing over product excellence. The code becomes a means to an end, not the end itself.

What great product development looks like

Documentation everywhere: Markdown files in every directory explaining what lives there. Humans are too lazy to maintain docs, but LLMs never skip documentation. They’ll update that README.md every single time they touch the code.

Explicit over implicit: That clever convention you have where userService automatically connects to the user database? Spell it out. AI agents don’t do tribal knowledge.

Claude Code hooks: .claude/ directories with agent-specific instructions. “When working in this directory, always run these tests.” “This service has these dependencies.”

Aggressive automation: Pre-commit hooks, linters, formatters – everything that can be automated, should be. Not because humans need it (we ignore half of it anyway) but because agents follow rules religiously.

Error messages that teach: Instead of Error: Invalid config, we need Error: Invalid config. Expected format: {host: string, port: number}. See docs/configuration.md.

I’m literally restructuring our entire repository not for my human colleagues, but for my AI ones. And you know what? It’s liberating. Instead of agonizing over the perfect abstraction, I’m shipping features. Instead of refactoring for elegance, I’m improving user experience.

The code is messier. The documentation is everywhere. There’s redundancy. And our product has never been better.

The future is already here

This workflow sounds insane because it is. I’m managing a team of AI developers, with AI reviewers, in parallel branches, shipping features at a pace that would have required a team of 10 just a year ago.

It’s not perfect. It’s not even stable – I’m tweaking the process constantly. But it’s so powerful that going back to solo development feels like trying to build a house with a toy hammer.

The bottleneck has shifted from creation to verification. The challenge has moved from “can we build it?” to “can we ensure it works?”

Welcome to the weird, wild future of software development. Bring coffee. Lots of coffee.

Building the future of AI-assisted development at neople.io. Follow our journey as we figure out what it means when AI can code faster than humans can review.

Let me back up a bit. At Neople, we’re building what we call “vibe working” – essentially, we’re creating digital colleagues who can handle the repetitive, time-consuming tasks that eat up your day.

Our first prototype of our newest product, Nora, has access to tools like Notion and Gmail, and she can perform “skills” – sequences of actions that run on schedules or triggers. Think “organize my inbox every morning at 9 AM” or “update my project board whenever I get a new client email.”

The key thing about these skills is they run in the background, asynchronously. Once you set them up, Nora does her thing without needing to check in with you every five minutes. It’s like having a colleague who just quietly handles stuff while you focus on the work that actually needs your brain.

The label dilemma

So here’s what happened. We’d asked Nora to automatically label incoming emails – pretty standard inbox management stuff. She was cruising along, analyzing emails, figuring out which ones needed which labels. Then she hit a snag: the label she needed didn’t exist, and she didn’t have the permission to create new labels in Gmail.

Now, a typical automation would just… fail.

Maybe throw an error. Maybe skip the email. End of story.

But Nora? She got creative.

The “Wait, what?” moment

Instead of giving up, Nora did something we hadn’t explicitly asked her to do. She created a draft email in Gmail with the subject line “[ACTION REQUIRED] Create Label” and politely explained the situation. She basically said, “Hey, I need this label to do my job properly. Could you create it for me?”

When we saw this, we were genuinely stunned. She’d found a way to communicate with her human colleague using the tools she had available. It wasn’t a pop-up notification or an error message – it was a draft sitting in their Gmail, waiting for them to notice it during their regular email check.

What’s happening here

This might seem like a small thing, but it represents something bigger. Nora didn’t just follow a script – she problem-solved. She understood her limitation, recognized she needed help, and found a creative way to ask for it using the tools at her disposal.

It’s these moments that make you realize we’re not just building automation; we’re building digital colleagues who can actually think through problems. The fact that she chose to create a draft (not send an email that might get lost, not fail silently) shows a level of thoughtfulness that feels almost… human?

The future of vibe working

This is exactly the kind of collaboration we envision when we talk about vibe working. It’s not about replacing human creativity or decision-making – it’s about having digital colleagues who can handle the routine stuff and know when to tap you on the shoulder for the things that need a human touch.

Nora’s creative solution reminded us why we’re building Neople in the first place. We want digital colleagues who don’t just execute tasks but actually work with you, finding ways to bridge gaps and solve problems together.

So here’s to Nora and her draft email workaround. Sometimes the best features aren’t the ones you plan – they’re the ones your digital colleague figures out on her own.

Curious about having your own digital colleague? Check out what we’re building at neople.io