The code is cheap now. Understanding isn't.

Not long ago, writing code was the slow part. Now you can describe what you want and get a working draft in the time it takes to refill your coffee. That still feels a little unreal to us. It is the biggest change in how software gets made in a generation, and it has barely started.

So why does everyone we know feel strangely stretched?

Teams are shipping more than ever. Pull requests are bigger. Prototypes appear overnight. And yet ask a good engineer whether they understand their own codebase better than they did a year ago, and you will often get a pause, then a laugh, then an honest "not really."

We think that pause is the story of the next decade in software. Producing code got cheap. Knowing what that code does, why it is there, and whether you can trust it did not.

Most of us have done it. A big diff lands, the checks are green, it looks reasonable, and you approve it because you have eleven other things to do. Maybe it is fine. You will find out later, probably at a bad hour.

That is the quiet cost of abundance. When a machine can write code faster than you can read it, review stops being a formality and becomes the whole job, and almost nobody built their workflow for that.

Meanwhile, the old problems never left. Context is scattered across five tools. The real thinking gets squeezed between meetings and tickets. And now there is a new layer on top: a chat box bolted onto every product, another tab, another place where the answer might be, another thing to double check. Each one is clever on its own. Together they are noise.

We have been measuring the wrong thing for a long time, and AI makes it worse. Lines written, tickets closed, features shipped. All easy to count, all increasingly meaningless when producing them costs almost nothing. The thing that matters is harder to count: how much of the system a team still genuinely understands.

If we do nothing, the likely outcome is not a golden age. It is software that grows faster than anyone can hold in their head, built by people who are quietly losing the thread.

Three things, all at once.

Writing code is becoming a conversation. You describe intent, a model proposes an implementation, you push back, it adjusts. The typing is going away. We are not sad about that. Typing was never the point.

The valuable work is moving up. When the draft is free, what is left is deciding what to build, spotting what is subtly wrong, and knowing when to say no. Taste, judgment, and context were always the real skill. Now they are most of the job.

The software itself is starting to do work, not just suggest it. Tools that take a task, go off, and come back with something finished are no longer a thought experiment. Whoever builds these well will change what a small team can do. Whoever builds them carelessly will bury those teams in output they cannot trust.

Our bet is simple. The winners of this era will not be the tools that generate the most. They will be the ones that leave people understanding more, not less.

AI should make you more capable, not more dependent. If you finish the day having shipped a lot and learned nothing about your own system, something went wrong. The best tools leave you sharper.

Generated code is a liability until someone understands it. Every line has to be read, maintained, and eventually deleted by a human being. Cheap to write is not the same as cheap to own.

Trust should come from evidence. Not from confident tone, not from a green checkmark nobody examined. Show what changed, show why, show how it was checked. If a tool cannot explain itself, we should not hand it the keys.

Verification is the real frontier. Anyone can make a model write code. The hard and valuable problem is making it cheap to know that the code is right. We expect the best work in this field to happen there.

Intent is the new source code. The clearest description of what a system should do will matter more than any single implementation of it. Specs, tests, and constraints stop being chores and become the way people and machines agree on what is true.

Developers stay the authors of the decisions. You can hand off the typing. You cannot hand off the responsibility. Tools should make that responsibility lighter to carry, never invisible.

Friction is a bug, including the new kind. Reviewing a mountain of generated output is friction. Babysitting an assistant that keeps missing the point is friction. If a tool moves work around instead of removing it, it has not done its job.

The best tools get out of the way. A tool you have to think about is already costing you. We want less workflow, not more software in it.

Small teams deserve large leverage. A handful of people with clear heads and good tools can now build things that once took whole companies. We want to make that the normal case, and we want it to be sustainable, not another way to do twice the work for the same pay.

Code is not going away. Plain language is great for saying what you want and poor at guaranteeing it. Underneath every idea, something precise will still need to be inspected and trusted. People who can read and reason about code will matter more, because there will be so much more of it.

Build for the principle, not the moment. Models will change. Interfaces will change. What we are after is not tied to any of that: software exists to serve the person trying to build something real.

Imagine the next five to ten years going well.

You start the morning with a problem, not a backlog. You say what you want in plain terms, and something capable gets to work. When it comes back, the change is small enough to read, clear enough to judge, and comes with proof that it does what you meant. Reviewing it feels like working with a sharp colleague, not auditing a stranger.

The system stays understandable as it grows, because understanding was treated as the thing worth protecting from the start. New people get up to speed in days. Nobody dreads the codebase.

Five people do the work that once needed fifty, and nobody is burned out, because the leverage came from removing waste rather than demanding more.

And the job feels like the reason you got into it. You are deciding, designing, and making things. Not babysitting output.

None of this needs a miracle. It needs people who care enough to build the tools carefully.

We are building tools for this new way of making software, with one aim: help people build faster without losing their grip on what they have built.

Every product we make will answer the same questions. Does it leave the developer understanding more? Does it make the right thing easy to verify? Would a careful engineer, using it on a hard day, finish feeling lighter and still in control?

If not, we are not done.

We will make firm choices and explain them. We will be honest about what our tools can do and where they fall short. And we will judge ourselves by how much clarity and focus we give back, not by how much code we help produce.