The AI-native tax
The hidden cost of putting AI to work, and who ends up paying it.
These days, most of the AI-native people I meet have never written a line of code. They run marketing, sales, small companies. And lately they're all learning the same things.
First it's GitHub. Then Supabase. Then Vercel. Then a very expensive lesson about API keys.
From X, 2026. Business people, not engineers, learning the developer stack. Posts by a marketing founder, a product designer, a creator and brand coach and a growth lead.
Agents can make it for you. Making it work for your team is a second job.
The side job
The leader of the house, as AI-native in 2026.
Take a landing page. An agent can make one in minutes, but a page on your laptop isn't a page customers can visit. Hosting it, publishing it, changing it without breaking it: that's Vercel, one more tool to learn.
A dashboard is worse: data to connect, keep fresh and lock down. You wanted to know why ads weren't turning into signups. Now you're learning databases and permissions first.
I've started calling it the AI-native tax: the time you spend learning and maintaining the setup instead of doing the work you wanted AI for. It usually lands on whoever got good at AI first. They're still running the business. Now they're also part-time IT.
More capable agents, more setup
Each step up in what agents can do comes with one more thing to learn.
Every step up in what agents can do came with a step down in what people had to learn. They happened together. The last column is where most companies are stuck: all of it, for everyone.
And the usage numbers show who's paying.
Left: METR's 50% time horizon on software tasks (metr.org). Right: Anthropic, Measuring agent autonomy (Feb 2026), selected domains. Capability kept climbing; half of all agent activity is still software engineering.
The capability is there for everyone. The usage isn't. Half of all agent work is still software engineering, while marketing, sales and finance sit at 3–4% each. Engineers already speak GitHub, Vercel and Supabase, so they can pay the tax. Everyone else is a long way from the door.
What used to be out of reach
Left: every part of the business on its own island, reached by letter. Right: the same islands, bridged.
A business used to be split into pieces its own leader couldn't reach. The website sat with an agency. The CRM sat with a vendor and the consultant who configured it. The numbers sat with an analyst. If you wanted to know why last month's ads didn't turn into signups, you filed a request, and you waited for someone in between to answer.
Now the person who runs the business can go straight to the bottom of it: their own landing page, their own lead enrichment, their own funnel, their own follow-ups, and the answer the same afternoon. That has never been true before. The people best placed to do it are the ones who know the business, and they're the ones least likely to want to learn row-level security. They can get there, but only if they pay the tax.
"Just learn GitHub"
“Or you could just learn to use Github. It actually isn't that hard to learn.”
A reply to “Someone should build GitHub for normies”
Learning those tools is one option. But why should it be the entry requirement? The person who runs a sales team wants to change a dashboard, share it with colleagues and trust that they're looking at the right data. They shouldn't have to become an engineer first. This is about the apps that run a business, not the product you sell. Our engineers still ship that through GitHub.
That's why we built Kylon. We didn't hide the stack; we rebuilt each piece for agents, so you never have to feel it. Pull requests became drafts and previews, with their history kept. Deploys became publishing from the conversation. Every App comes with its own database, on Neon, which branches fast enough that each draft gets its own copy of the data. Outbound messages are prepared as drafts for a person to review and send. The guardrails come with the workspace, so safety doesn't depend on everyone remembering a checklist.
The same jobs, rebuilt for agents and the people who work with them.
One room
In Kylon, that workspace starts with a Room: one place for your team, the agents you already use and the Apps you build together.
What you see is a chat. What makes it work is the harness underneath, run by Kylon.
You connect your data from the conversation. You ask for what you need, and an agent builds it as an App with the views your team needs.
Does that actually change who can build? We looked at our own team. We're ten people: some of us build the product, and the rest run sales, marketing, growth and operations. These are our team's results, not a promise of what every company will achieve.
Across the four measures below, people who don't write code account for most of the work requested or published. They asked for 83% of the Automations we built since July, and the engineers for 3%. They asked for 77% of the code changes to our Apps, and clicked 77% of the publishes. In October, the Automations they asked for delivered 94% of all results.
Who asked for each kind of building in our own workspace. Rows don't add to 100%: the rest is work we can't trace to a requester (14% of new Automations, 6% of October results, 4% of code changes).
The amount of work grew with it. By late October, non-engineers had asked agents for 5,832 changes to our Apps' code, nearly four times the engineers' 1,484.
Agent-made App code versions in our workspace by who asked, Apr 22 to Oct 26, 2026. Another 303 couldn't be traced to a requester.
The clearest example is the page you may be reading this on. Until June, kylon.io lived in a GitHub repository: 164 pull requests from 7 people, 85% of them from one contractor. Anyone else who wanted a headline changed filed a request. Since we moved it into the Landing Page room in Kylon, the team has changed it 3,760 times, across 867 drafts and 877 publishes. In October, 919 of its 1,016 changes were asked for by people who don't write code.
kylon.io is an App in our Landing Page room. The conversation that changes it sits right next to it.
All Apps in our Landing Page room, Jun to Oct 26, 2026. Before June: 164 pull requests from 7 people in a GitHub repo.
For those App changes, the team could ask, review a draft and publish in Kylon, rather than manage a separate development stack. The engineers didn't stop; they kept building the product. The difference is that a business-side change no longer has to wait for an engineer to make it.
Because it all happens in one place, it stays legible. The conversation that produced a number sits next to the number, every App change has a history, and every run leaves a record in its thread.
After it's built
Building is only the start, just as it was with the landing page. Things can break, data sources can change, and your process will evolve. In Kylon, you can return to the same thread and ask an agent to investigate a failed run or update the App. The conversation and run history give it context to work from; you review the change before publishing. You still decide what good looks like, without having to start the technical setup over.
AI-native doesn't have to be hard
The point of becoming AI-native isn't to give everyone a new technical job. It's to let the people who know the business get more of its work done. Smarter agents help. So does a shared place to use them, connect your data, review changes and keep the work moving.
The stack was never the point. The business was.
Try it at kylon.io. Pick one business task you've been waiting on, connect the data it needs, and ask an agent to build it. Review the draft before you publish.
First published on X by Quinn Leng.
Your first company harness. Where humans and agents run your business together.
