--- title: "The AI-native tax: the hidden cost of putting AI to work | Kylon" description: "Most AI-native people have never written code, yet they end up learning GitHub, Supabase and Vercel. Quinn Leng on the setup cost business people pay to use agents, and what our own team's numbers show when that cost goes away." url: "https://kylon.io/blog/the-ai-native-tax" language: "en" --- [HOME](https://kylon.io/)\>[Blog](https://kylon.io/blog)\>[AI for business](https://kylon.io/blog/topics/ai-business-adoption)\>The AI-native tax Stories6 min read # The AI-native tax The hidden cost of putting AI to work, and who ends up paying it. [Quinn Leng](https://www.linkedin.com/in/suanmiao/)Co Founder October 29, 2026 ![A Renaissance-style painting of a smiling merchant carrying crates marked with the GitHub, Vercel and Supabase logos, an old computer terminal and a ring of keys through his busy counting house](https://kylon.io/blog-assets/ai-native-tax/00-hero.webp) 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. ![Four posts on X from business people, not engineers: a marketing founder who says you need Claude Code and a GitHub account, a product designer who got a first PR merged, a creator learning GitHub on day 27 of speed running AI, and a growth lead who rebuilt a website with Claude, Supabase and Vercel](https://kylon.io/blog-assets/ai-native-tax/01-learning-the-stack.webp) _From X, 2026. Business people, not engineers, learning the developer stack. Posts by [a marketing founder](https://x.com/irabukht/status/2107618232945504605), [a product designer](https://x.com/hyumankind/status/2063244547963167095), [a creator and brand coach](https://x.com/BentoBoiNFT/status/2040173108724740486) and [a growth lead](https://x.com/joaopkury/status/2061456266052972855)._ Agents can make it for you. Making it work for your team is a second job. ## The side job ![A Renaissance-style painting of a smiling merchant leading his busy counting house, while carrying crates marked with the GitHub, Vercel and Supabase logos, an old computer terminal and a ring of keys](https://kylon.io/blog-assets/ai-native-tax/02-the-side-job.webp) _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. ![A ladder of what agents can do, from chat answers to working with your team, mirrored by what people have to learn to let them, from copy-paste context and the terminal to GitHub, pull requests, deploys and a database with API keys, and finally all of it for everyone](https://kylon.io/blog-assets/ai-native-tax/03-capability-ladder.webp) _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 chart: the length of software task an agent finishes half the time rose from 2.0 hours for o3 in April 2025 to 12.0 hours for Opus 4.6 in February 2026. Right chart: share of agent tool calls on Anthropic's API by domain, with software engineering at 49.7 percent and marketing, sales and finance at 3 to 4 percent each](https://kylon.io/blog-assets/ai-native-tax/04-capability-vs-usage.webp) _Left: METR's 50% time horizon on software tasks ([metr.org](https://metr.org/time-horizons)). Right: Anthropic, [Measuring agent autonomy](https://www.anthropic.com/research/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 ![A Renaissance diptych. Left: separate islands, each holding one part of a merchant's business, with boats slowly ferrying letters between them. Right: the same islands joined by stone bridges into one connected quarter, the merchant walking across the middle](https://kylon.io/blog-assets/ai-native-tax/05-islands-bridged.webp) _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”](https://x.com/cpaulsenn/status/2092701776977793420) 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](https://neon.com/), 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. ![What business people had to learn: GitHub for pull requests, branches and versions; Vercel for deploys and hosting; Supabase for a database and its permissions; and their own judgment, hoping nothing leaks. What the Room runs instead: drafts, previews and history; publishing from the conversation; a database that comes with every App; approvals before anything goes out](https://kylon.io/blog-assets/ai-native-tax/06-stack-rebuilt.webp) _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. ![Above the surface: chat with agents, Rooms and threads, Apps and results to approve. Underneath, six layers Kylon runs: identity and access, agent routing, connections, runtime, build and ship, and governance](https://kylon.io/blog-assets/ai-native-tax/07-harness.webp) _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. [A Kylon Room where someone connects PostHog, Google Ads and Meta Ads, an agent shows where signups come from, and a draft campaign appears one click later](https://static.purework.app/files/0e949c09d9d2f6e32842a25845396b84/room-clip.mp4) Ask, connect, see where signups come from, and get a draft campaign one click later, all in the same Room. Nothing goes live until you publish. Sample data. 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. ![Bar chart of who asked for each kind of building in our workspace. New Automations asked for, Jul 20 to Oct 25: non-engineers 83%, engineers 3%. Automation results delivered in October: 94% and 0.5%. App code changes asked for, Apr 22 to Oct 26: 77% and 19%. One-click publishes, Aug to Oct: 77% and 23%](https://kylon.io/blog-assets/ai-native-tax/09-who-builds.webp) _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. ![Running total of App code changes from April to October: 5,832 asked for by non-engineers and 1,484 asked for by engineers](https://kylon.io/blog-assets/ai-native-tax/10-code-changes-running-total.webp) _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](https://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. ![The kylon.io landing page open as an App inside the Landing Page room in Kylon, with the room's thread beside it](https://kylon.io/blog-assets/ai-native-tax/11-kylon-io-in-the-room.webp) _kylon.io is an App in our Landing Page room. The conversation that changes it sits right next to it._ ![Monthly code changes to kylon.io after it moved into the Landing Page room, June to October 2026](https://kylon.io/blog-assets/ai-native-tax/12-landing-room-changes.webp) _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](https://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._ [Quinn Leng@quinn\_lengThe AI-native taxThe hidden cost of putting AI to work, and who ends up paying it.Oct 29, 2026Read on X](https://x.com/quinn_leng/status/2115840988799508773) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## Keep reading [More in AI for business](https://kylon.io/blog/topics/ai-business-adoption) [ ### Design the App Before You Build It: One Spec, a Design Page and a Working App Asking an agent to build a recruiting system gets you its guess. We ask for a design page first: the business flow, the tables, every field, where each field comes from and who sees what. Once that is signed off, the same spec builds the App. Here is the skill, with one prompt to run it in your own workspace. Kylon TeamOctober 8, 2026 ](https://kylon.io/blog/design-an-app-before-you-build-it)[ ### Kylon Use Cases by Function: From Email to Team Systems A practical guide to how marketing, sales, operations, people teams, product teams, and strategic leaders turn recurring work into shared systems with Kylon. Kylon TeamAugust 6, 2026 ](https://kylon.io/blog/kylon-use-cases-by-function)[ ### How Non-Technical Teams Build Internal Tools Through Chat Your team doesn't need a developer, a drag-and-drop builder, or three months. Describe what you need in a conversation. AI agents build it, your team uses it, and the system grows as you work. Kylon TeamJuly 29, 2026 ](https://kylon.io/blog/build-internal-tools-with-ai-agents)