Back to Handbook
Chapter iconChapter 14

Where we are going

Between us. – Troy McAlpin, Co-Founder & CEO, August 2026

We have all worked at a lot of software companies. Different places, same problems. Culture, process and systems fighting creativity and building. We started Atono to change that, and building it helped us find the root causes.

For the builders

Every field runs on software. Medicine, travel, health, research, economics, science, politics. All move as fast as the software they run on – that speed is changing by 3x.

Can humankind solve global warming? Global inequity? Cure cancer? Maybe. And if so, faster because AI exists.

But it won't be the AI that does it.

Humans have the inalienable ability to visualize, dream and create. We also build and we get stuff done. The people who will fix the grid or crack the disease are out there right now, with a clear idea of what they want to build and not enough hours to build it. What's stopping them isn't ambition nor intelligence.

In software it takes 15 to 20 tools, lots of meetings and a dozen people to get from intent to outcome – a fraction of that time goes into building. Handoffs exist in attempts to optimize the human assembly line.

So that's Atono. Build the shortest path from intent-to-outcome, and let the chips fall where they may.

Our part in this evolution is small. It's the builders who change the world. Tools help, and this new generation is solid – Figma, Cursor and Claude Code, GitHub, Slack. None of them is ours and the path only works when they work together. What's missing is a tool that carries the meaning with the work.

And what's in the way isn't a competitor. It's comfort. It's custom. Nobody ever got fired for keeping Jira or going to a standup meeting. Most of what a team does to coordinate itself is overhead, and people will defend it to the end because it fixed a serious problem once upon a time. That's what we're up against. Habit, and fear.

What we'll leave behind this time

The reflex in tech is to tell people the fear is silly. People feared the round earth, the loom, the telephone, the automobile, self-driving cars and so on. "You are overreacting, relax."

Fear is a valid warning signal – when appropriate. We handed navigation to machines and stopped being able to picture our route home. We handed arithmetic to spreadsheets, and we're still here. Some fears that came true are the ones where nothing caught what we were leaving behind.

So, will AI take our jobs or the parts we enjoy? Will it wake up one day, decide it's done with us, and leave us on a SpaceX flight to Mars? No. Developers aren't going anywhere, and the ones who understand the system get more valuable. They stop building and start coaching AI to better outcomes, faster. The number of builders goes up, not down – the technical barrier is dropping, and when a barrier drops more people join in.

What's being left behind isn't jobs. It's the builder's personal understanding of the system they're responsible for. Not because anybody gets worse at it. Because they stop. And that is unsettling.

There's a name for it now, and it isn't ours – intent debt. The rationale, the goals, the constraints nobody wrote down, which humans and AI both need in order to change software safely. You can carry it, you pay interest on every change, and the bill arrives when somebody new has to touch the thing. So far nobody has built the thing that retires the debt.

The one limit that doesn't close

AI is a tool with incredible capabilities, and being specific about them beats being excited about them. It's outstanding at generating stuff. It's outstanding at writing code – code is words. It's outstanding at repetitive tasks. It's not outstanding at authentic work, or whole complex systems, or automating a full function end to end.

It has limits, today. Most of those will improve, so building a company on them would be a bad idea.

One is different. A model can't know why something is the way it is if nobody ever wrote it down. A better model makes that worse rather than better, because a faster agent makes more decisions per hour that nobody records. We measured it rather than assuming it. Turn the context off and the same work takes 60% more changes to get right.

The iron triangle

Velocity, quality, cost. You can't materially move one without paying for it in the other two, and every engineering leader treats that as physics, because for fifty years it was. It held because the binding constraint was the humans. Quality came from people reading things carefully.

AI breaks half of that and makes the other half worse. Velocity goes way up, cost per unit falls, and quality is disguised within "looks right" – the attention needed to check the work never got cheaper, it got scarcer against the volume. The triangle doesn't dissolve. It distorts, and quality is the corner that weakens.

Our goal is to change the shape. That means checking work against a record of what the team decided, instead of against somebody's memory and whatever hours they have left.

It also means reviewing the right thing. An agent touches forty files to add one behavior, and that's one decision. AI made lines cheap. It did not make decisions cheaper.

This behavior was added. This constraint was relaxed. This decision was reversed.

Somebody who wasn't in the room can evaluate those three lines. Nobody can evaluate a four hundred line diff at 3am, which is why in practice nobody does. And when the code and the record disagree, that's a question somebody answers – which is the bug – instead of a stale document everybody ignores.

None of it works if it's documentation. Humans suck at documentation. It's a natural law. Don't expect it to get better – embrace the suck. Add AI to a messy, stale Confluence and see how that goes over time.

Rather, capture it as you work, not after. Humans hide in meetings and behind complexity, and AI exposes that, which is an opportunity rather than something to be defensive about.

What we're building

The vision is the product engineering platform. To get there we have to help people transform to agentic work. And to do that, they need visibility, because you can't improve what you can't see.

DevOps took about ten years to go from an argument to how everybody works. Not a product, a movement, and the tools that mattered showed up along the way. Pick your own tool to get the job done, a rally cry.

Product engineering will be similar. Anybody promising you it lands easily and quickly is selling you something.

Now, and the next three years or so. The harness. Capture what the agents and the people actually did, show the journey, prove out what's working and what isn't. It starts with one team rather than a company. Nobody has to move to get going – a tiger team runs their work through us alongside whatever else you have, and you watch what happens as they adopt AI.

If it works, moving is something you'll want rather than something we asked for. The reason it lands isn't cost, it's fear. Every transformation runs longer and costs more than the plan said, and the executive who started one is often not there to finish it. Being twelve months in with nothing to show a board is a career event, not a status update. Visibility is how you don't become that story.

We expect the urgency of that initial value to expire. You can't measure this work without capturing what the agents did and why, and that capture is the same record everything else runs on.

After that. The loop in one place, for the teams that want it. Intent is authoritative. Review happens at the decision.

Eventually. A company keeps its understanding of its own software the way it keeps its code. Somebody joining a ten year old company reads the product's memory instead of booking six meetings with the people carrying it around in their heads.

And on the machines, my answer is probably not the fashionable one. This doesn't end with AI building while we eat popcorn. It ends with AI advising, arguing, suggesting what to build, and the two of us dreaming and deciding together. That's a partnership, not a handoff.

In short

  1. Evaluate each team's agentic journey as they continuously improve their craft

  2. Own the work, so the reasoning gets recorded without anybody writing a document

  3. Use that record to check whether changes match what the product actually intends

  4. Let teams hand off more as it gets earned, with the score kept in the open

  5. Build the shortest path from intent to outcome and let the chips fall where they may

And whatever you do, don't call it documentation.

One more thing

Since this is between us I'll say it plainly. None of this is happening because of us. The change was coming with or without Atono. The people who are going to do remarkable things over the next ten years are already out there, already good at their jobs, already frustrated by the same things that frustrated us.

They don't need our vision. They need less junk between them and the work. That's the job. Not leading a transformation. Clearing a path for people who already know where they're going, and getting out of the way while they do something we couldn't have.

It's ok to snicker at us. But every generation of software gave organizations a way to keep something that mattered. ERP kept operations. CRMs kept customers. Git kept code. Every time we put something down and built the thing that caught it, the trade was worth making.

We're putting down our understanding of our own software. Product intent has never had a home. We won't build one alone, and it won't work unless the rest of the toolchain does its half.

Let's take a shot at changing it.