aozora

Should Junior Developers Still Learn to Code From Scratch in 2026?

aozora — Sat, 17 Oct 2026 14:53:19 GMT

Yes. But probably not the way you think, and definitely not for the reasons people gave in 2019.

Here is the straight answer: AI has not removed the need to learn programming. It has moved the bar. The junior developer who only knows how to translate a ticket into syntax is in trouble, because that is exactly the task AI now does cheapest. The junior developer who understands how software actually works, and uses AI as leverage on top of that understanding, is more employable than ever. The difference between those two people is not talent. It is what they chose to learn first.

So the real question is not whether to learn to code. It is what "learning to code" should mean now.

What AI Actually Changed About Junior Hiring

Let us start with the uncomfortable part, because the numbers are hard to argue with.

According to Stanford's 2026 AI Index, employment for software developers aged 22 to 25 fell nearly 20% since late 2022, when generative AI tools went mainstream. Over the same period, employment for older developers grew 6% to 12%. The same analysis found that AI boosts software development productivity by roughly 26%. Read those two facts together and the mechanism is obvious: companies did not stop needing software. They stopped needing as many people to produce it, and the people they stopped needing first were the least experienced.

SignalFire's 2026 State of Tech Talent report tells the same story from the hiring side: new-grad and entry-level hiring at the twelve big tech majors fell about 65% compared with 2019, and about 76% at early-stage startups. Total hiring at those companies is down 25%, but engineering hiring is down only 11%. One economist team studying online job postings found a 14% to 15% relative decline in junior developer postings compared with senior ones after ChatGPT's release. Companies are not firing juniors en masse. They are doing something quieter: the requisition never gets posted.

Notice what did not collapse: demand for engineers who can already carry production work. The story is not "robots took the jobs." It is closer to this: companies kept the senior engineer and dropped the apprenticeship.

That is the world you are entering. The old deal, where a company hired you green and taught you on the job for a year, is mostly gone. The new deal is that you arrive pre-trained on things that used to be taught on the job. Which brings us to the actual question.

The Experience Trap, Stated Plainly

There is a cruel loop at the center of this. To become a developer worth hiring, you need to build real things, ship real code, fix real bugs, and read enough bad code to recognize what good code looks like. That education used to happen during your first job, while you handled the routine work seniors were too expensive to do.

That routine work is exactly what AI absorbed first: boilerplate, simple bug fixes, unit tests, documentation formatting. A senior engineer put it bluntly in a widely shared discussion: they used to hire a junior to handle the boring stuff so they could focus on architecture, and now AI handles the boring stuff.

So the question is no longer "how do I get good enough to get hired?" It is "how do I get experience when the job that provided experience no longer exists?" Anyone who tells you the answer is easy is selling something. But the answer does exist, and it starts with understanding which fundamentals actually matter.

Which Fundamentals Still Matter (And Why)

There is a popular argument that goes: AI writes the code now, so just learn to prompt. This works for toy projects and falls apart the moment something breaks in production. Here is the version of fundamentals that actually earns its keep in 2026.

Reading code fluently. This is the single highest-leverage skill, and it is not close. You will spend far more of your career reading code than writing it: yours, the agent's, your team's, the library's. Before you accept any AI suggestion, you should be able to read it line by line and predict what it does. If a line surprises you, that is your lesson for the day. Juniors who cannot read code cannot review AI output, and reviewing AI output is now a core part of the job.

How a program actually runs. Variables, control flow, functions, scope: the boring basics. Not because you will write them from memory every day, but because every bug you will ever debug is a story about state changing over time. When the AI gives you a subtly broken retry loop with no backoff, or a database query that will melt under load, you catch it because you know how programs run, not because it looked unfamiliar.

Data structures and basic algorithms. You do not need to invert binary trees on a whiteboard. You do need to know what a hash map, a list, a tree, and a queue are, and roughly what each costs. This is the vocabulary of every technical conversation you will ever have. Skip it and you cannot participate; learn it and half the "hard" discussions become readable.

Debugging as a discipline. Forming a hypothesis, reproducing the problem, isolating the cause, verifying the fix. This is the muscle production will demand from you in your worst moments, and it is the one thing an agent cannot lend you. Debugging is where fundamentals convert directly into money.

How the web actually works. HTTP requests and responses, what a database does, what an API is, how authentication works at a conceptual level, what happens between typing a URL and seeing a page. You do not need depth here yet. You need the map, because every AI-generated backend you touch will assume you have it.

Git and the command line. Non-negotiable and unglamorous. You cannot collaborate, deploy, or recover from mistakes without them.

Security instincts. Not expertise: instincts. Never trust user input, never hardcode secrets, know what SQL injection and XSS are at a conceptual level. AI generates insecure code with total confidence, regularly. Someone has to catch it, and on a junior-heavy team that someone might be you.

Notice the pattern: none of these are about typing speed or memorized syntax. They are about comprehension and judgment. The industry shifted the junior role from "person who writes code" to "person who directs, evaluates, and takes responsibility for code, some of it written by AI." Fundamentals are what make that role possible.

What You Can Skip (Or At Least Defer)

Learning everything is not the answer either. Time is finite, and some of the traditional curriculum has genuinely depreciated. Here is what to cut or postpone.

Memorizing syntax and standard library details. This was never the point, and now it is actively wasteful. Know that the function exists and what it is for; let documentation and AI handle the exact signature. Your memory is for concepts, not spellings.

Hand-writing everything, forever. The purist position says you should not touch an AI assistant until you have "earned it" by suffering through everything manually. That is nostalgia, not strategy. Hand-write the core concepts once, to encode them. Then use the tools. The goal was never calluses.

Deep computer science theory up front. Compilers, operating system internals, formal algorithm analysis: valuable for some paths, irrelevant for most junior web development roles. Defer these until you have a reason. Learn them on demand, when a real problem makes them concrete, and they will stick ten times better than they would from a textbook chapter you read out of duty.

Grinding algorithm puzzles beyond the basics. Interview practices are shifting, and more importantly, puzzle skill correlates weakly with the actual job. Learn the common patterns well enough to reason about them, then spend that time building things instead.

Framework tourism. Learning five frameworks shallowly is worth less than learning one deeply. The fundamentals transfer; the framework specifics do not, and AI is better at framework specifics than you will ever be. Pick one stack, go deep enough to be dangerous, and let the agent handle the API you forgot.

The principle: learn what helps you judge correctness. Defer what only helps you produce text, because text production is the part that got automated.

How to Use AI as a Tutor Without Becoming Dependent

This is the part most advice gets wrong, because it treats the choice as binary: either learn without AI like it is 2012, or let the AI do everything and hope for the best. Both paths fail. The first wastes the best tutor ever built. The second produces developers who freeze the moment the tool is wrong, which it regularly is.

The middle path is to use AI from the start and deliberately protect the fundamentals it would otherwise erode. Protection has to be intentional, because the default, letting the agent handle it, always wins when you are tired or behind.

Here is the operating system that actually works:

Default to "explain," not "do." When you are stuck, your first prompt should be "explain why this fails," "what are the tradeoffs here," or "where is my mistake," not "fix it" or "write it." An AI that explains is a tutor. An AI that writes is a ghostwriter, and ghostwriters do not teach you anything. Reserve generation for things you already understand and are just tired of typing.

Read more code than you generate. This deserves repeating because it is the whole game. Every AI suggestion is a free code-reading exercise. Before accepting, trace it mentally. Predict the output. Find one thing you would have done differently. This single habit converts passive AI use into active learning, and it is the difference between developers who grow with the tools and developers who atrophy with them.

Debug unaided on a timer. When something breaks, give yourself 20 to 30 minutes before you paste it into a chat. Form a hypothesis. Add a print statement. Be wrong, then be less wrong. If you are still stuck after the timer, bring the AI in, but bring it your hypothesis too: "I think the problem is X because Y, but Z contradicts that." You will get better answers, and you will have practiced the exact skill production incidents require.

Hand-write the core stuff once. You do not need to hand-roll everything forever. But write a few data structures, a recursive function, a small parser, an HTTP server from scratch, by hand, without help, at least once. The point is not the artifact. It is the encoding that only effort produces. After that, automate freely.

Keep a "surprised me" log. Every time the AI produces something you did not expect, or you catch it being wrong, write one paragraph about it. What did you assume? What was actually true? This log becomes a personalized textbook of exactly your weak spots, and reviewing it monthly is worth more than any course.

Learn to spot the failure modes. AI-generated code has tells: confident but subtly wrong edge cases, missing error handling, security holes it never mentions, solutions that work for the demo and collapse at scale. Study these deliberately. The junior who can say "this looks right but will break under load because..." is already operating above the level AI can replace.

The through line: AI should make your thinking faster, not replace it. If you notice you cannot explain what your own project does without the chat history open, you have crossed the line. Pull back, rebuild the understanding by hand, then return to the tools.

A Concrete 90-Day Plan

Advice without a plan is just encouragement. Here is a 90-day outline that implements everything above. It assumes a few focused hours per day and one chosen stack: pick JavaScript or Python and stick with it.

Days 1 to 30: Foundations, mostly by hand.

The goal is comprehension, not output. Work through the basics deliberately: variables and types, conditionals and loops, functions and scope, the common data structures, basic object modeling. Write small programs daily. This is the one phase where you keep AI assistance minimal: use it to explain concepts you are stuck on, not to write your exercises.

By day 30 you should be able to: read a 200-line program and explain what it does, write a simple program from scratch without help, and debug your own errors with print statements and hypotheses. Build one small project entirely by hand, something ugly and real: a CLI tool, a tiny game, a script that solves an actual annoyance in your life. Ugly is fine. Yours is what matters.

Days 31 to 60: Build with AI as a tutor.

Now open the toolbox, but on your terms. Start a larger project: a web app with a real backend, a bot, a data dashboard. Let AI scaffold and accelerate, but enforce the rules from the previous section. Every generated block gets read before acceptance. Every bug gets 20 minutes of unaided debugging first. Every prompt defaults to explanation.

Add the professional layer in this phase: Git done properly with real commits, a README that explains your decisions, deployment somewhere public. A deployed project you can link to is worth ten tutorial certificates. Also in this phase, deliberately study one AI failure per week: find something it generated for you that was subtly wrong, understand why, log it.

By day 60 you should be able to: direct an AI agent to build a feature and evaluate its output critically, explain every architectural decision in your project, and deploy and maintain something live.

Days 61 to 90: Ship and prove.

This phase is about evidence. Hiring managers in 2026 do not screen for "knows syntax." They screen for three things: a portfolio that shows judgment, demonstrated AI literacy, and proof you can operate in production.

So: finish two or three quality projects, not ten shallow ones. For each, write a README that shows your thinking: what you built, why you chose the approach, where AI helped and where you intervened. Include at least one piece built substantially by hand, to prove fundamentals. Customize any AI scaffolding visibly rather than shipping it as-is. If you can, contribute a small fix to an open-source project: it proves you can read other people's code and collaborate, which is exactly what employers are buying.

By day 90 you should have: a public portfolio with two or three documented projects, one deployed application, visible Git history showing real iteration, and the ability to talk through any of it in detail without notes. That is a stronger position than most bootcamp graduates held in 2022, because it was built for the market that actually exists.

What Hiring Managers Actually Screen For Now

It helps to see the plan from the other side of the table. The entry-level market has bifurcated: it is contracting sharply for candidates who cannot demonstrate AI competency and holding steadier for those who can. The underlying shift is in what "junior" means.

The traditional junior was defined by implementation capacity: write features from a ticket, fix bugs, follow the established pattern. In 2026, that implementation capacity is increasingly handled by AI tools. What remains human-required, and what companies now hire juniors to do, is AI-mediated implementation: using AI tools effectively, evaluating AI outputs for correctness, integrating AI components into larger systems, and catching the specific failure modes AI tools reliably produce.

Concretely, that means your portfolio should demonstrate: one project where you evaluate AI output visibly (document where it was wrong and what you changed), production experience of any kind (deployed, monitored, fixed when it broke), and enough fundamentals to discuss tradeoffs in an interview. The candidates who show all three are not competing with AI. They are competing for the roles AI created.

The Calm Takeaway

The panic around this question comes from framing it as an ending: coding is over, the ladder is pulled up, too late. The data says something less dramatic and more useful. The bottom rungs of the ladder were automated, so the ladder now starts higher. That is harder, and it is unfair to people who planned around the old deal. It is also navigable, and the people navigating it share a profile: fundamentals first, AI as tutor rather than crutch, proof of judgment in public.

Learn to code. Just learn the parts that make you the person who knows when the machine is wrong. That person is not going anywhere.

If you are learning to code right now, what is the one fundamental you are glad you learned by hand, and the one thing you wish someone had told you to skip?

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

How I Built and Monetized a Mobile App With AI in One Weekend

aozora — Sat, 17 Oct 2026 14:48:10 GMT

Here is the straight answer up front: yes, you can go from zero to a monetized Android app in a single weekend in 2026. I know because I just did it. Friday evening I picked the idea, Saturday I built it, Sunday I wired up ads and prepared it for the Play Store.

But here is the honest second half of that answer, the part most "I built an app in a weekend" stories skip: the weekend gets you a shippable v1 with the monetization plumbing installed. It does not get you a business. Revenue is a lagging indicator. It shows up weeks later, after real users, real retention, and real ad impressions. Anyone quoting day-three revenue figures for a weekend app is either lying or got extraordinarily lucky.

So this is not a "how I made $10k in a weekend" story. This is the build log: the exact playbook, the tools, the ad setup, and the unglamorous checklist between "it compiles" and "it earns." If you follow it, you will end Sunday with a real APK on your phone, AdMob test ads rendering, and a clear path to publishing. That is a genuinely great weekend.

Friday Evening: Picking an Idea Small Enough to Finish

Every failed weekend project I have ever attempted died the same death: the idea was too big. So Friday evening had one rule. The idea had to be buildable as a static web app, because that is the fastest thing AI can generate reliably, and a static web app can be wrapped into a native Android app with almost no extra work.

That constraint eliminates 90% of ideas, which is the point. What survives: quizzes, flashcards, calculators, converters, habit trackers, simple reference apps. Content-driven, single-purpose, no accounts, no backend, no real-time anything. I landed on a quiz app: timed multiple-choice questions, lives, hints, progress tracking. It is the kind of thing people open for five minutes on a commute, which matters later for ads.

Three filters I ran the idea through:

Can AI generate 80% of it? A quiz is HTML, CSS, and JavaScript with a data file of questions. This is squarely in the zone where AI coding assistants are excellent.
Does it work offline? A quiz with bundled questions works without internet. Offline-capable apps get used in more situations, and "works on the subway" is a real retention feature.
Is there a natural ad moment? Games and quizzes have them built in: game over, "watch an ad for an extra life," hint refills. If your app idea has no natural moment where the user wants something an ad can give them, monetization will always feel bolted on.

Pick the smallest version of the idea that is still a complete experience. My v1 spec fit in one paragraph: endless quiz questions, three lives, a hint system, five difficulty levels, progress saved on device. Nothing else. Features are the enemy of shipped.

Saturday Morning: Scaffolding With AI

Saturday morning started with a spec, not a prompt. I wrote down the screens, the game rules, the data format, and the ad placements I would want later, in plain language, before asking the AI for a single line of code. This is the highest-leverage habit in AI-assisted development: ten minutes of spec writing saves hours of regenerating.

The stack decision was deliberately boring: plain HTML, CSS, and JavaScript, no framework, no build step. For a weekend project this is a feature, not a limitation. No bundler config to fight, no dependency updates, and the whole app is four files you can read end to end. AI assistants write vanilla web code extremely well because there is so much of it in their training data.

I had the AI generate the app in passes, not all at once. First the data layer and question engine. Then the UI. Then the game logic: timer, lives, hints, persistence via localStorage. Then the ad integration points, stubbed out so the web version could run a demo fallback while the native app would call real ads. Each pass got reviewed before the next one started. AI-generated code that you have not read is not your code; it is a liability with nice formatting.

One thing I insisted on: the web app had to be fully playable in a desktop browser first. If the game is not fun as a web page, wrapping it in a native shell will not save it. I played through it myself, found the timing felt off, tuned it, and only then moved to mobile. The wrapper is packaging. The product is the web app.

By lunch, I had a working quiz running in the browser. Rough edges everywhere, but the loop was fun. That is the Saturday morning milestone: a playable thing.

Saturday Afternoon: The Capacitor Wrapper

Here is the part that surprises web developers: turning that web app into a native Android app is about an hour of work if you pick the right tool. I used Capacitor, the open-source successor to Cordova from the Ionic team. The concept is simple. Your app is a web app running inside a native WebView, wrapped in a real Android shell. Capacitor provides the bridge: a plugin layer that exposes device APIs to your JavaScript when you need them.

There are two ways to point the WebView at your content, and the choice matters:

Option A: remote URL. You set server.url in the Capacitor config to your hosted site, and the app loads it live. The huge advantage: every web update goes straight to app users with no rebuild. The disadvantage: the app needs internet, and the Play Store has opinions about apps that are just website wrappers.

Option B: bundled files. You copy your HTML, CSS, and JS into the project's web directory, and they ship inside the APK. The app works fully offline. The tradeoff: every content update means rebuilding and redistributing the app.

I started with the remote URL for speed of iteration, then switched to bundled files for the final build, because an offline quiz is a better product and I did not want the app to depend on my server staying up. For a weekend project, my advice is: develop against the remote URL, ship bundled.

The actual mechanics are unglamorous, which is good:

npm install the Capacitor core and Android platform packages.
npx cap init with your app name and a package ID (this is permanent-ish; pick something like com.yourname.appname and do not typo it).
npx cap add android, which generates a real Gradle project.
npx cap sync, which copies your web files and config into the native project.
Open the project, build a debug APK, install it on your phone.

Two gotchas bit me, and they will probably bite you. First, the Android back button: by default it kills the app, which feels broken. You need a small override in MainActivity that goes back through WebView history when possible and only exits at the root. Second, edge-to-edge display: modern Android wants your content drawn behind the status and navigation bars, with insets applied so nothing important hides underneath them. A few lines in MainActivity handle it. Neither is hard; both are the difference between "demo" and "app."

By Saturday evening I had a debug APK installed on my phone, running the quiz natively. It felt like a real app, because at that point, it was one.

Saturday Evening: Break It on Purpose

I spent Saturday evening doing nothing but using the app like a hostile user. Airplane mode on. Rotate the phone mid-question. Spam the back button. Kill the app mid-game and reopen it. Let the timer run out repeatedly.

This is where localStorage persistence earned its keep: lives, progress, and settings survived app kills, which is the bare minimum for anything with the word "game" in its description. The offline check mattered too. My ad code paths all assumed internet, so I added a guard: if the device is offline and the user taps "watch ad," they get a clear message saying ads need internet, instead of a hung screen or a silent failure. Small thing, huge difference in how polished the app feels.

One real bug surfaced that I want to flag because it is a classic: I had two Capacitor config files in the project (a .ts and a .js), and the build silently used the wrong one, which pointed at nothing. The app launched to a blank white screen. The fix took thirty seconds once diagnosed; the diagnosis took an hour. Lesson: when a Capacitor app shows blank white, check what the WebView is actually loading before you blame anything else.

End of Saturday: a tested, offline-capable APK that survived my abuse. No ads yet. That is Sunday's work.

Sunday Morning: AdMob, the Right Way

Monetization for a small indie app in 2026 still starts with AdMob. It is free, it is Google's, and it has the deepest advertiser demand, which is what actually determines what you earn. Here is the setup, in order, with the mistakes removed:

1. Create the AdMob account and register the app. You do this with your Google account before you even need it. Register the Android app and create your ad units with descriptive names, like quiz_banner_bottom and quiz_rewarded_extralife. Future you will thank present you for the naming discipline.

2. Develop with test ads. Always. Google publishes official test ad unit IDs for development. Use them. This is not a suggestion; it is policy. Clicking your own live ads, or even letting test devices serve live ads during development, can get your AdMob account limited or banned, and appeals are slow. I built and tested the entire ad flow on test IDs and only planned the swap to real IDs at release time.

3. Banner first, because it is simple. A banner is a small ad strip, conventionally pinned to the bottom of the screen. Implementation-wise it is a native view sitting under your WebView. The one layout detail that matters: reserve space for it. Your WebView content needs a bottom margin equal to the banner height, or the ad will cover your app's buttons and users will hate you. I set this up in the MainActivity insets handling so the game area automatically shrinks above the banner.

4. Rewarded ads are the real money, and the real design work. A rewarded ad is a full-screen video the user chooses to watch in exchange for something: an extra life, a hint refill, unlocking a level. The user opts in, watches to completion, and your app grants the reward only when the ad SDK confirms completion. If the user closes early, no reward. This contract, enforced by the SDK callback, is the entire trust model. Get it wrong in either direction and you either give away rewards for free or cheat users out of earned ones, and both will show up in your reviews.

For the quiz, I wired two rewarded placements: "+1 life" on the game-over screen, and "+1 hint" during play. Both are moments where the user genuinely wants what the ad offers. That is the whole secret of rewarded ads: the ad is not an interruption, it is a trade the user proposes to you.

5. Never stop at AdMob alone, eventually. AdMob mediation lets multiple ad networks compete for your inventory, which typically raises what you earn per impression. That is a month-two optimization, not a weekend task. For the weekend, one network, correctly integrated, beats three networks wired badly.

Sunday Afternoon: Designing the Ad Experience

Sunday afternoon was not coding; it was judgment calls. Ads are a UX design problem disguised as a revenue problem, and small apps live or die on these decisions:

Frequency caps are not optional. I decided the rewarded placements would have no artificial cooldown (the user chooses each time), but I deliberately skipped interstitial ads, the full-screen popups, for v1. Interstitials earn well per impression and cost you users per impression. For a new app with no loyal base, that trade is bad. Earn the right to interrupt people after they love the app, not before.

Every ad needs a graceful failure. Ads fail to load. Networks time out. Test this by turning on airplane mode and tapping every ad button. Each one should explain what happened and return the user cleanly to where they were, with the game timer resuming. An ad that breaks the game loop is worse than no ad at all.

Respect the offline user. Since my app works offline, a chunk of sessions will have no connectivity. Those users get the full game with no ads and no nagging. The moment they tap an ad placement, one clear message: this needs internet. No dark patterns, no fake buttons.

Measure from day one. I did not ship analytics expecting revenue; I shipped it expecting questions. The questions you will have in week three are: how many sessions per user, where do users drop off, what fraction of game-overs convert to a rewarded view, and what is the effective earnings per thousand impressions by country. You cannot answer any of that retroactively. Instrument first, optimize later.

Sunday Evening: Signing and the Road to the Play Store

The last unglamorous block: making the app publishable. Debug APKs are signed with a debug key and cannot go on the Play Store. Release builds need a release keystore, and this is the part I want to underline because it is the most permanent decision of the whole weekend.

The keystore is your app's identity. Lose it, and you can never update your app again; you would have to publish as a brand-new app and abandon your users and reviews. Back it up in at least two places that are not the same laptop. This is not paranoia; this is the single most common catastrophic indie dev mistake, and it is irreversible.

Some things that softened the risk since I last looked: Google Play now uses Play App Signing, where Google holds the final signing key and you hold an upload key. If you lose the upload key, there is a reset process with identity verification. It is still a bad week, but it is no longer a funeral. And note the Play Store requires the AAB (Android App Bundle) format for new apps, not the APK; the APK is for your own device testing and direct distribution.

The remaining publishing checklist, none of which is code: a privacy policy page (required, even if your app collects nothing, because the ad SDK collects device identifiers), a content rating questionnaire, store listing text and screenshots, and an app icon that does not look like a default. I left Sunday night with the keystore plan decided and the checklist written. Publishing itself is a next-weekend task, and that is fine. The weekend goal was a shippable, monetized v1, and that goal was met.

What "Monetized" Actually Means on Day Three

Let me close the honesty loop I opened at the start. As I write this, the app has test ads, not live ones. I am not going to quote revenue figures because there are none yet, and any number I gave you would be fiction dressed as data.

Here is what I can honestly say the weekend bought:

A real asset. An installable app with a complete game loop, offline support, and two ad placements, built in roughly two focused days.
Zero marginal cost per user. Static content, no backend, no server bills scaling with downloads. Every user is nearly pure margin minus Google's cut.
A realistic expectation. Small utility apps earn modestly per user. The math that matters is retention times sessions times impressions, and all three are earned after launch, not during the build weekend. Anyone selling you a weekend-to-riches story is selling the story, not the app.

The weekend did not make me money. It made me ready to make money, which is what weekends are actually for.

The Takeaway

The meta-lesson of the weekend is not about any single tool. It is that the stack has compressed: AI writes the app, Capacitor wraps it, AdMob monetizes it, and the Play Store distributes it. Each layer is a solved problem with documentation. The scarce resource is no longer engineering skill; it is taste in what to build and discipline in keeping it small.

If you have a weekend free, pick the tiniest app idea you have been sitting on, spec it on Friday, build it Saturday, monetize and harden it Sunday. You will not get rich by Monday. But you will have something most people never get: a shipped product with the cash register installed, waiting for customers.

Have you shipped a weekend app? What did you build, and what would you do differently with the ad setup?

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

What Is MCP and Why Does Every Developer Talk About It?

aozora — Sat, 17 Oct 2026 14:44:35 GMT

If you have spent any time around AI tooling in 2026, you have heard the letters MCP dropped into conversations like everyone already knows what they mean. Blog posts assume it, coding agents ship with it, and job-adjacent Twitter threads treat it as obvious.

Here is the straight answer: MCP, the Model Context Protocol, is an open standard that lets any AI application talk to any external tool or data source through one shared protocol, instead of needing a custom integration for every combination. Think of it as USB-C for AI apps: one plug shape, and everything just connects. It was introduced by Anthropic in November 2024, and since December 2025 it has been governed by the Agentic AI Foundation under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, and Cloudflare. When the three largest model providers all speak the same protocol, building against it stops being a bet and starts being the safe default.

That is the what. The why is more interesting, and it is the reason every developer keeps talking about it: MCP quietly solved one of the most annoying problems in AI engineering, and in doing so it became the foundation that coding agents are built on. Let's unpack it properly.

The Problem MCP Solves: The N×M Integration Mess

Before MCP, connecting AI to the real world was a bespoke nightmare. Suppose your team wanted an AI assistant that could read from your database, file tickets in your tracker, search your docs, and deploy through your CI. And suppose you wanted that assistant to work with three different models. Every model-to-tool pairing needed its own custom integration: its own authentication logic, its own schema mapping, its own error handling, its own maintenance burden.

Engineers call this the N×M problem. With N models and M tools, you build N×M integrations. Three models and four tools means twelve connectors. Add a fifth tool and you do not add one integration, you add three. Change one tool's API and you touch every connector that uses it. It scales horribly, and every team building serious AI features was living inside that scaling curve.

MCP collapses N×M into N+M. Each AI application implements the MCP client side once. Each tool or data source implements the MCP server side once. After that, any client can talk to any server with no additional glue code. That single insight is the entire business case for the protocol, and it is why adoption exploded: by April 2026 there were already over a thousand open-source MCP server implementations covering databases, cloud providers, DevOps tools, and productivity apps.

How MCP Actually Works: Hosts, Clients, and Servers

MCP defines three roles, and keeping them straight clears up most confusion.

The host is the AI application you actually interact with: Claude Desktop, Cursor, VS Code with an AI extension, or your own custom agent. The host owns the conversation with the user and with the model. It decides which servers to connect to, what they are allowed to see, and when the user needs to approve an action. Servers never get to read your full conversation; the host mediates everything.

The client lives inside the host. It is the connector that speaks MCP to exactly one server: a one-to-one relationship. A host can run many clients at once, one per server, so your IDE might simultaneously hold a client connected to your GitHub server, another to your database server, and another to your docs server. The client handles the protocol details: attaching version and capability information to each request, routing messages, handling timeouts and cancellation, and keeping the boundary between servers clean so one server cannot reach across into another.

The server is the program that exposes capabilities: tools the model can invoke, data the model can read, and prompt templates the model can use. It can run locally on your machine or remotely as an HTTP service. That is it. Three roles, clean separation, and the security boundaries fall out naturally from the architecture.

Communication between client and server uses JSON-RPC 2.0 messages. For transport, local servers typically run as a subprocess the host launches over stdio, which is simple and keeps everything on your machine. Remote servers run as HTTP services that many clients can reach, and they use OAuth 2.1 for authorization. One notable change: since the July 2026 revision of the spec, the protocol is stateless. There is no more connection-level initialize handshake; every request is self-contained and carries its own protocol version and the client's capabilities. In practice this means a remote MCP server can sit behind an ordinary load balancer with no sticky sessions, which makes hosted MCP deployments horizontally scalable in the most boring, reliable way possible.

The Three Things a Server Can Expose

Everything an MCP server offers falls into three primitives. This is the part worth memorizing, because once you see these three, every MCP server you ever encounter becomes legible.

Tools are functions the agent can call. Send a message in Slack, create a ticket, run a database query, trigger a deployment. Tools are the action half of the protocol: they let the model do things in the world, not just talk about them. Each tool comes with a description and a parameter schema, which is how the model knows what the tool does and what arguments it needs.

Resources are read-only data the agent pulls in as context. Files, documents, database rows, API responses. Resources are the "let me look at that" half: the model reads them to inform its reasoning but cannot change them through the resource interface. The read-only distinction matters for security, and we will come back to that.

Prompts are reusable prompt templates the server offers. Instead of every user hand-crafting the perfect incantation to get good results from a tool, the server ships templates that encode the right way to ask. It is a small feature that turns out to matter a lot in practice, because prompt quality is one of the biggest variables in agent reliability.

A typical run looks like this. You type "create a task in the tracker about the login bug." The host passes your message to the model. The model sees, via the client, the tracker's MCP server and its available tools, including one for creating tasks with its parameter schema. The model decides this is the right tool, fills in the parameters from your message, and the client sends the tool call to the server. The server executes it against the real tracker API and returns the result. The host shows you the outcome. You never touched the tracker yourself, and no custom integration code was written for your specific AI app: the tracker team wrote one MCP server, and every MCP-compatible client can use it.

What It Looks Like in Practice

Concretely, using MCP servers is usually a configuration entry, not a coding project. Here is what an MCP server entry looks like conceptually in a client's config file:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server-github"],
      "env": {
        "GITHUB_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "uvx",
      "args": ["mcp-server-postgres", "--db-url", "postgresql://localhost/mydb"]
    }
  }
}

Two entries, two capabilities. The first launches a GitHub server as a local process over stdio and hands it a token. The second does the same for a Postgres database. Once these are in the config, the host connects a client to each, and the model can suddenly list repositories, open pull requests, and query your database. No SDK imports, no adapter classes, no per-client plugin code. That is the whole developer experience, and its simplicity is a large part of why MCP spread so fast.

Why Every Developer Talks About It

MCP did not become ubiquitous because of the elegance of its spec. It became ubiquitous because it arrived at the exact moment coding agents needed it.

The agent boom of 2025 and 2026 created enormous demand for a standard way to give agents tools. Every coding agent, Claude Code, Cursor, Cline, and the rest, faces the same question: how does the agent touch GitHub, the database, the terminal, the browser, without the agent vendor building every integration themselves? MCP is the answer the whole industry converged on. Build one server per tool, and every agent can use it. The agent vendors get an ecosystem of tools for free; the tool vendors write one integration instead of ten.

There is a second, subtler reason developers talk about it: MCP changed who gets to extend an AI product. Before, adding a capability to your AI assistant meant waiting for the vendor to build it or hacking together an unofficial plugin. Now, if the tool you need has an MCP server, and increasingly it does, you add a config entry and you are done. If it does not, you can write a server yourself, often in an afternoon, and it works with every client at once. That shift of power from vendors to users is the kind of thing developers notice and talk about.

And there is a third reason, the economic one. Reusable agent skills, the versioned workflow files that teach agents your team's practices, increasingly ship alongside or on top of MCP servers. The combination is potent: MCP provides the tools, skills provide the judgment about how to use them. Teams that invest in both are building institutional knowledge that compounds, and that is a genuine competitive advantage, not just a productivity hack.

The Catches Nobody Should Skip

MCP is genuinely useful, and it is also genuinely easy to misuse. Here is the honest list.

Security is real and it is yours to manage. A tool the model can call is an action the model can take, and models can be tricked. A malicious or compromised MCP server is a live attack surface: prompt injection through tool descriptions, exfiltration through innocent-looking resources, confused-deputy problems where the agent uses a legitimate tool for an illegitimate purpose. The mitigations are well understood: least privilege on every server, authentication on remote servers, human approval gates on destructive actions, monitoring of what agents actually invoke. But they are mitigations you must implement, not properties you get for free. Treat every MCP server like any other third-party dependency: audit it before you trust it.

Statelessness changed the mental model. If you learned MCP from older tutorials, note that the July 2026 revision removed sessions and the initialize handshake. Older guides describing the lifecycle as initialize, capability negotiation, request/response, shutdown are describing the old world. The new world is simpler, servers expose a discover capability, clients call it optionally, but make sure the material you are learning from matches the current spec.

It does not fix bad agent design. MCP gives your agent tools. It does not give your agent judgment, tight context management, or a verification loop. An agent with fifty MCP servers and no discipline is not powerful, it is a liability with a large attack surface and a larger token bill. The developers getting the most from MCP are selective: a small set of well-understood servers, each with a clear purpose, each audited.

The ecosystem is still settling. A thousand servers sounds like maturity, but quality varies wildly. Some are maintained by the tool vendors themselves and are excellent. Some are weekend projects with no security review. Check who maintains a server before you hand it your production credentials, the same way you would check who maintains any dependency.

What To Do About It on Monday Morning

If you have read this far, here is the practical version.

First, check whether the AI tools you already use support MCP clients. In 2026, most serious coding agents and AI-enabled editors do. If yours does, look at which servers are available for the tools you touch daily: your git host, your database, your docs, your issue tracker.

Second, install one server and actually use it for a week. The GitHub or filesystem-adjacent servers are the usual starting points. Pay attention to two things: how often the agent reaches for the tool correctly, and how the approval prompts feel. If approvals are constant noise, your server has too broad a scope; narrow it.

Third, before you install a server that touches anything sensitive, read its source or at least its tool list. Know exactly which actions you are granting. Set approval gates on anything destructive or irreversible. This is not paranoia, it is the same hygiene you apply to any production credential.

Fourth, if you maintain an internal tool that agents should use, consider writing an MCP server for it instead of a chatbot-specific plugin. One implementation, every client. That is the N+M math working in your favor, and it is the single highest-leverage MCP investment most teams can make.

The Takeaway

MCP is not magic and it is not hype. It is plumbing: a well-designed, openly governed standard that solved the integration problem standing between AI models and the tools developers actually use. The reason every developer talks about it is that it works, it is neutral ground owned by no single vendor, and it arrived exactly when agents needed it most.

The developers who benefit most will not be the ones with the most servers installed. They will be the ones who understand the three primitives, respect the security model, keep their server list small and audited, and treat MCP as infrastructure: boring, reliable, and load-bearing. Learn it once, and every agent you touch for the rest of your career gets more useful.

Have you wired up an MCP server yet? I am curious which one earned its place in your setup, and which one you removed after a week. The comments are open.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

Can a Solo Developer Still Compete With AI-Native Teams?

aozora — Sat, 17 Oct 2026 14:33:52 GMT

Yes, but not in the way the hype suggests. The popular story is that AI coding agents turned every solo developer into a ten-person team overnight, and now one person can outbuild anyone. That story is half true. The other half is that teams got the same tools. Your competitors are not five developers with laptops anymore. They are five developers, each with agents, shipping in parallel.

So the real question is not whether AI makes solo developers powerful. It does. The question is where a single developer still holds a structural edge when everyone has leverage, and where that edge disappears. Let's be honest about both.

What Actually Changed

Something real happened to the economics of starting a software business. Solo-founded startups rose from 23.7% of all new companies in 2019 to 36.3% by mid-2025, according to an analysis by Cipher Projects. That is not a rounding error. It is a structural shift, and the cause is not mysterious: the functions that used to require departments, content marketing, customer support, financial modeling, design, and a large share of software development itself, can now be handled by one person running the right stack.

A solo founder today can plausibly spend a few hundred dollars a month on tooling and produce the output that used to require a small payroll. That changes who gets to play. It does not change who wins. Winning was never mostly about output volume, and AI made that more true, not less.

Where Solo Developers Win: The Structural Advantages

Forget the motivational posters. The solo developer's advantages are structural, which means they hold up even when teams are equally well-equipped with AI.

Speed of decision. A team of five, no matter how AI-augmented, still needs alignment: standups, reviews, approvals, someone to resolve the disagreement about the database schema. You need a coffee. When the market shifts or a user reports something surprising, you can change direction in an afternoon. A team changes direction in a sprint. Over a year, that compounds into a meaningful number of extra experiments, and experiments are what find product-market fit.

Zero coordination cost. Every team pays a coordination tax that grows roughly with the square of headcount. Meetings, handoffs, merge conflicts, the "who owns this?" conversations. AI reduces some of this, but it does not eliminate it, because the tax is mostly about humans agreeing with each other, not about typing code. A solo developer pays none of it. One hundred percent of working hours go to the product.

Focus on niches teams cannot afford. This is the big one, and it is pure arithmetic. A venture-backed team burning tens of thousands a month needs a market big enough to justify that burn. A solo developer with near-zero overhead can build a calm, profitable business on a few thousand dollars of monthly recurring revenue. Markets that are too small for teams are wide open for individuals. The riches are genuinely in the niches, because the niches are where you have no competition from anyone with payroll.

Taste and coherence. Products built by one person with a clear vision tend to feel coherent in a way committee-built products rarely do. Every decision, from the API design to the error messages, comes from one brain. Users notice this, even if they cannot name it. Teams can hire for taste, but they cannot shortcut the alignment cost of maintaining it across many people.

Where Teams Win: The Honest Part

Now the other side, because pretending teams have no advantages is how solo developers walk into walls.

Distribution. Building the product was never the hard part; getting people to use it is. Teams can run marketing, partnerships, content, and sales in parallel while the product keeps shipping. A solo developer doing everything is constantly choosing between building and promoting, and both suffer. The most common failure mode of solo projects is not bad code. It is a good product nobody heard about.

Support and operations load. Users write in at all hours. Servers fail on weekends. Payment disputes need responses. One person can automate a lot of this, and modern tooling helps enormously, but there is a floor of human attention that automation does not remove. Past a certain scale, support becomes a full-time job that eats the product.

Parallel work. This one is simple and undefeated: five people with agents can genuinely advance more independent workstreams than one person with agents. AI multiplies each person's output, but it does not change the arithmetic that five multiplied is more than one multiplied. If the game is raw throughput, teams win.

Trust and compliance. Enterprises buy from companies, not individuals. Procurement departments want SOC 2, SLAs, a support contract, and someone to sue. A solo developer can sell to consumers, prosumers, and small businesses all day. Selling to enterprises is a different sport with different equipment.

So the honest map looks like this: solo developers win on speed, focus, cost structure, and coherence. Teams win on distribution, scale of operations, throughput, and institutional trust. AI raised the ceiling for both. It did not erase the difference.

The AI Leverage Stack for Solo Builders

If you are going solo, your stack is your team. The goal is not to collect the most tools; it is to cover every function a small company needs with the fewest moving parts. Here is what that looks like in practice.

Building: one coding agent, learned deeply. Pick one agent, Claude Code, Cursor, Codex, or similar, and learn its actual loop instead of skimming five tools. The developers getting the most leverage are not the ones with the most subscriptions. They are the ones with tight specs, verification habits, and reusable agent skills that encode their workflow. A solo developer with a well-tuned skill library is carrying institutional knowledge the way a team carries it in people's heads.

Backend: boring and managed. Supabase, Firebase, or a self-hosted option like Coolify on a cheap VPS if you want to control costs. The indie playbook here is well established: managed Postgres, built-in auth, and deploys on git push. Pricing for the common managed tiers sits around $20 to $25 a month at the time of writing, which is trivially affordable. The point is to spend zero hours on infrastructure plumbing.

Frontend and shipping: the fastest path to a URL. Vercel, Netlify, or Railway. Frameworks with strong defaults, Next.js, Astro, or whatever you already know. Speed of iteration beats architectural elegance when you are one person. You can always refactor later; you cannot refactor a product that never shipped.

Support: automate the routine, own the exceptions. This is where many solo developers underinvest. A searchable docs page, canned responses for the common questions, and an AI-assisted triage layer over your inbox can resolve the majority of routine tickets. The goal is not zero human support. The goal is that the human, you, only touches the interesting ten percent.

Marketing: pick one channel and be consistent. You cannot do SEO, social, partnerships, and paid ads simultaneously. Pick the channel where your users already are, usually one, and show up regularly. Building in public works for developers because the audience is developers. Writing, which you are already doing if you blog, compounds.

The meta rule: every tool must remove a job, not add a hobby. Solo developers love tinkering with tooling, and AI made the toy shelf enormous. Audit quarterly. If a tool does not clearly replace hours of work or unlock something you could not do otherwise, cut it.

Monetization Paths That Actually Fit One Person

Not every business model suits a solo operator. The ones that do share a trait: revenue without a proportional increase in human labor.

Small SaaS for a sharp niche. The classic indie path. A focused tool solving one painful problem for one specific audience, priced modestly, with self-serve signup and automated billing through Stripe or a merchant of record like Lemon Squeezy or Paddle. The math that matters: at near-zero cost, a few hundred paying users is a life-changing business. You do not need venture scale. You need a problem people will pay to make go away.

Mobile apps with ads. Lower revenue per user than SaaS, but distribution is handled by the app stores and monetization can be largely passive once the app is stable. Rewarded and banner ads through networks like AdMob mean you earn while you sleep, and updates can be infrequent for mature utility apps. The tradeoff is platform dependence and the long grind of getting initial downloads.

Templates, themes, and boilerplates. Sell the starting point instead of the finished product. A well-crafted starter kit, UI kit, or boilerplate for a popular stack can sell for years with minimal maintenance. The work is front-loaded: build it once, document it well, then collect. Marketplaces and your own site both work.

APIs and micro-services. If you can package a capability as an API, keyed billing plus usage tiers, you get the purest form of leverage: the product serves itself. This demands more engineering rigor up front, reliability and docs are the product, but the operational load per dollar of revenue is the lowest of any model here.

What to be careful with: anything where revenue scales with your personal hours, consulting disguised as product, custom development, or high-touch enterprise sales. Those are fine businesses, but they do not compound for a solo operator. They just become a job with extra steps.

The Data Nobody Wants to Read

Here is the part the hype skips. AI made it dramatically easier to launch software. It did not make it easier to sell software. The revenue data is sobering: analyses of indie hacker products show that only a small fraction ever cross six figures in annual recurring revenue, and putting AI at the center of the product does not seem to improve the odds. One analysis found that AI-labeled products earned revenue at roughly the same rate as non-AI products, about half in each group. The barrier that fell was building. The barrier that remains is the one that always mattered: finding people with a problem and getting them to pay.

This is actually good news, if you read it correctly. It means the game did not change into something unrecognizable. It is still: pick a real problem, solve it well, reach the people who have it, charge fairly, keep them. AI just lets you play more rounds of that game per year. More rounds means more learning, and learning is the actual compounding asset.

Set expectations accordingly. Most solo products earn little or nothing. A meaningful minority earn a living. A tiny few earn a lot. Your edge is not that AI guarantees success; it is that each attempt now costs you weeks instead of months, so you can afford to be wrong several times on the way to being right.

What "Compete" Should Mean

We should define the word in the title, because most arguments about solo developers versus teams are really arguments about different finish lines.

If "compete" means outbuilding a funded team feature-for-feature in a head-on market, then no. That was never the solo game, and AI did not change it. Five people with agents will outship you. Accept it and stop playing that game.

If "compete" means building a profitable, independent business that a team would not bother with, then yes, absolutely, and the conditions have never been better. The solo game is not about beating teams. It is about playing where teams cannot follow: markets too small for their burn rate, products too opinionated for their committees, timelines too fast for their process.

There is a third definition worth naming: compete as in optionality. A solo developer with a profitable product and low costs has something most startup employees do not: the freedom to say no. No to bad customers, no to misaligned investors, no to growth-at-all-costs. That freedom is a competitive advantage in life, even if it never shows up on a leaderboard.

A Practical Starting Point

If this article convinced you to try, here is the smallest honest version of the plan:

Pick a niche you understand from the inside, not one you read about. Your unfair advantage as a solo developer is specific knowledge of a specific pain.
Ship the smallest thing that solves it. One agent, one managed backend, one deploy target. Weeks, not months.
Charge from the start, even a little. Free users give feedback; paying users give truth.
Spend half your time on distribution from day one. The product will not sell itself, and you are the marketing department.
Keep costs near zero until revenue says otherwise. Your low burn rate is the entire strategy. Do not surrender it for comfort.

And the thing to avoid: building for six months in silence. The solo developer's speed advantage only counts if you actually ship and learn. An unreleased product has no advantages at all.

The Calm Takeaway

AI did not make solo developers into teams. It made something better: it made being one person a legitimate strategy instead of a stepping stone. The structural advantages, speed, zero coordination cost, niche economics, and coherence, are real and durable. The structural disadvantages, distribution, operations load, throughput, and institutional trust, are equally real and will not be solved by a better prompt.

The solo developers who thrive in the next few years will not be the ones with the most tools. They will be the ones who pick small markets on purpose, ship fast, charge early, and treat their low costs as the moat. Teams cannot follow you down there. That is the whole game.

Are you building solo right now? I would like to hear what your stack looks like, and which part, building or selling, is harder for you.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

How Much Does It Really Cost to Run AI Coding Agents Every Day?

aozora — Sat, 17 Oct 2026 14:29:52 GMT

Here is the straight answer: for most developers, running AI coding agents costs about the same as one flat subscription per month, somewhere in the tens of dollars. But that number is misleading, because 2026 is the year the pricing model broke. Vendors spent the first half of the year moving away from flat subscriptions toward usage-based and credit systems, and the gap between a light user and a heavy user went from small to enormous. A casual user might spend less than a lunch per month. A heavy agent-first developer on pure usage pricing can spend many times a flat subscription, sometimes several hundred dollars a month, without doing anything unreasonable.

The second part of the straight answer: the sticker price is not the real price. Underneath every plan sits token economics, and tokens are where your money actually goes. Output tokens cost several times more than input tokens. Frontier models can cost an order of magnitude more than small ones for the same task. And the way you work, how much context you feed the agent, how often it retries, how many agents you run in parallel, matters more than which vendor you pick.

One warning before we go further, and I mean it: pricing in this market changes constantly, sometimes quarterly. Do not treat anything you read here, or anywhere, as current pricing. I will describe the models and the mechanics qualitatively so this article stays useful after the next price change. Always check the current pricing page before you commit.

Why 2026 Changed Everything About Pricing

To understand today's costs, you need to understand why flat subscriptions stopped working. A flat subscription is a bet: the vendor bets that average usage stays bounded, and they price the plan a little above that average. For years, that bet was safe. A human typing in an editor can only read, think, and accept suggestions so fast. There is a natural ceiling on how much compute one person can consume in a day.

AI agents removed the ceiling. Point an agent at a repository and walk away, and it will plan, read files, write code, run tests, fail, retry, and try again for hours, burning tokens the entire time. The heaviest users were not abusing the system; they were doing exactly what the product was designed for. The vendors were effectively subsidizing power users with everyone else's subscriptions, and in the middle of 2026, several major vendors decided that subsidy had to end. The whole category repriced within weeks: flat plans got usage caps, credit pools, and overage meters, and usage-based pricing became the default for serious agent work.

This is not a billing footnote. It changed the nature of the decision. Model choice became a per-task cost decision. Budgets became a daily concern instead of a monthly one. And the developers who learned to run agents cheaply suddenly had a real economic advantage over those who did not.

The Three Pricing Models, Honestly Explained

Every plan you will encounter is a variation on three models. Understanding the model matters more than memorizing today's numbers, because the model determines how your bill behaves as your usage grows.

1. Flat subscriptions. A fixed monthly fee with an included usage allowance. Predictable, simple, and kind to steady daily users. The catch is the fine print, and in 2026 the fine print got longer: most "flat" plans now include usage caps, fair-use limits, or throttled speeds after a threshold. The subscription still exists, but the truly unlimited version mostly does not. Flat is at its best when your usage is consistent and human-paced: completions, chat questions, occasional agent runs.

2. Usage-based pricing. You pay for what you consume, measured in tokens or in per-request credits. This is honest and scales down to nearly zero, which makes it the cheapest option for light users. Its weakness is that agent architectures are token-hungry by design. Every file the agent reads, every retry after a failed test, every long explanation it writes costs you. A single bad afternoon with a confused agent can cost more than a month of flat subscription. Usage-based pricing rewards discipline and punishes flailing, which is fair but unforgiving.

3. Hybrid models. A base subscription that includes a pool of credits, with metered overage when you exceed it. This is where most of the market landed in 2026. The base fee covers your normal days; the overage meter covers your intense ones. The danger is psychological: the base fee feels like a cap, so the overage bill arrives as a surprise. Read the overage terms before you commit, and set up usage alerts on day one, not after the first surprise invoice.

The practical rule of thumb: if you use AI assistance daily at a human pace, flat or hybrid usually wins on simplicity and total cost. If you use it a few times a week for well-scoped tasks, pure usage-based is often cheaper. If you run agents hard, long autonomous sessions, parallel workers, you are living in usage-based territory whether you like it or not, and your job is to manage the burn, not to find a cheaper sticker price.

Token Economics: The Layer Underneath Everything

Underneath every subscription, credit pool, and overage meter sits a single layer that determines the real economics: tokens. Every plan is a wrapper around token costs. Understand tokens and you understand every bill you will ever get.

A token is roughly a chunk of a word, and models charge separately for tokens going in (your prompt plus all the context the agent gathered) and tokens coming out (the model's response: reasoning, code, explanations, tool calls). Two facts dominate everything else:

First, output tokens cost several times more than input tokens. The ratio varies by model, but output is consistently the expensive direction. This matters because agentic coding sessions are output-heavy: the agent writes long reasoning traces, generates large diffs, and narrates its actions. A session that feels like "a quick question" can be output-dominated once the agent starts working.

Second, model tiers differ enormously in price. Small, fast models can cost a small fraction of what frontier models cost per token, sometimes an order of magnitude less, sometimes far more than that. The capability gap between tiers keeps shrinking while the price gap stays wide. This is the single biggest lever on your bill: running a frontier model for a task a small model could handle is like hiring a senior architect to carry boxes.

Think in sessions, not months. A typical agentic coding session, one well-scoped task, might involve a few thousand input tokens (your prompt plus the files the agent read) and considerably more output tokens (its reasoning and the code it wrote). On a mid-tier model, that session costs a fraction of a dollar in raw token terms. Run a handful of those a day and you are in flat-subscription territory. Run dozens, on frontier models, with retries, and you can see why heavy users land in the hundreds per month. The math is simple; the only question is how many sessions you run and on which tier.

And remember the subscription caveat from the token handbook wisdom: even on a flat plan, tokens still matter, because the usage caps underneath are measured in tokens. The habits that cut token burn will make any plan's limits last longer.

What Actually Drives Your Token Burn

If your bill surprises you, it is almost always one of these five drivers. They are worth understanding individually because each has its own fix.

1. Context size. This is the biggest one. When you ask an agent to work on your codebase, it reads files to build context, and every file it reads is input tokens. An agent that pulls in your entire repository to change one function is burning money on context you will never benefit from. Large monorepos are the classic trap: the agent reads broadly "to be safe," and you pay for its caution. The fix is pointing the agent at the relevant files and keeping the working set tight. A tight context beats a clever prompt, and it also beats an expensive one.

2. Retries and flailing. Every failed attempt costs tokens, and agents fail in expensive ways: they write code, run the tests, watch them fail, reason about the failure at length, and try again. One retry roughly doubles the session cost; three retries can multiply it several times over. The root cause is usually vague delegation. "Fix the bug" gives the agent a wide search space to flail in. A precise spec, what done looks like, what not to touch, how to verify, collapses that space. Ten minutes of spec writing routinely prevents the most expensive failure mode in agent economics.

3. Model choice. Many tools default to the most capable model, and most developers never change the default. But not every task needs frontier reasoning. Boilerplate, simple refactors, test scaffolding, and documentation are all tasks where a smaller model performs nearly as well for a fraction of the cost. The expensive habit is using one model for everything. The cheap habit is tiering: small models for routine work, frontier models for genuinely hard problems. Some tools now do this automatically; if yours does not, do it manually.

4. Parallel agents. Running multiple agents at once multiplies everything: the context reads, the output tokens, the retries. Five agents working in parallel is five meters running simultaneously. Parallelism is legitimate leverage when you have genuinely independent tasks, but it is the fastest way to convert a normal day into a shocking bill. Each parallel agent should earn its place with a tight, independent spec. Vague parallel delegation is the most expensive sentence in software: "just have agents look into these five things."

5. Verbose output. Agents love to explain themselves at length: long reasoning traces, detailed summaries of what they did, play-by-play narration. Some of this is tokens you did not ask for. Concise output settings, where available, trim this directly. And when you review agent work, remember that the explanation is often longer, and more expensive, than the code itself.

Three Realistic Cost Scenarios

Enough theory. Here is what daily costs actually look like for three kinds of developers. These are qualitative scenarios, not quotes from a pricing page, because the numbers move. Focus on the shape of each scenario and where you fit.

The light user. You code a few days a week, accept inline completions, ask the occasional chat question, and run an agent session maybe twice a week for well-scoped tasks. Your token burn is modest and human-paced. On a flat subscription, you will likely never touch the usage cap. On pure usage-based pricing, your monthly total stays small, often well below a flat plan's price. For you, the cheapest option is usually either the flat plan for simplicity or usage-based for raw savings. Your risk is close to zero; the main mistake available to you is paying for a premium tier whose limits you never approach.

The medium user. You are at the keyboard most workdays. Completions flow all day, you chat with the AI dozens of times a day, and you delegate a few agent sessions daily: refactors, test coverage, debugging help. This is the profile most professional developers now match. On a flat plan, you live comfortably inside the allowance on normal weeks and brush against the cap during intense sprints. On a hybrid plan, the base fee covers you and the overage meter spins up occasionally. On pure usage-based, your bill lands in the same neighborhood as a flat subscription, sometimes a bit above, sometimes a bit below, depending on your model choices and retry rate. For you, the decision is mostly about predictability versus flexibility, and the biggest lever is still model tiering: the medium user who runs everything on frontier models pays noticeably more than the one who tiers.

The heavy user. Agents are your primary workflow, not your assistant. You run long autonomous sessions, you parallelize across tasks, you point agents at large codebases and let them work while you review. Your usage has no natural ceiling, which is exactly the profile that broke flat pricing. On a flat plan, you will hit caps, throttles, or overage, that is what the caps are for. On usage-based pricing, your bill reflects your actual consumption, and for genuinely heavy use it can run to several times a flat subscription, reaching into the hundreds per month. This is not a malfunction; it is the honest price of the compute you are consuming. For you, cost control is not optional, it is a skill, and the tactics in the next section are your job description.

Notice what the scenarios have in common: the driver is never the vendor's logo. It is session count, model tier, context discipline, and retry rate. Two developers on the same plan can have bills that differ by an order of magnitude, because they work differently.

Cost-Control Tactics That Actually Work

Here is the practical playbook, ordered by impact. None of this requires changing tools.

1. Tier your models. This is the highest-leverage habit and most developers skip it. Use small, cheap models for boilerplate, simple refactors, docs, and test scaffolding. Reserve frontier models for architecture, hard debugging, and ambiguous problems. If your tool supports per-task model selection, use it every time. If it auto-tiers, verify that it actually does. The price gap between tiers is the widest margin in the whole system; capturing even part of it transforms your bill.

2. Shrink the context. Before delegating, decide which files matter and say so. Do not let the agent "explore the repo to get familiar" on your dime more than once per project; after that, it should know where things live, or you should tell it. For repeated work in the same codebase, persistent project notes or skills that describe the architecture pay for themselves almost immediately by replacing repeated exploration reads.

3. Spec before you delegate. Vague prompts are the most expensive input in agent economics because they maximize the retry loop. Write down what done looks like, the constraints, what not to touch, and how to verify. This is not bureaucracy; it is the difference between one clean pass and five flailing ones. The developers with the lowest bills are usually the ones with the most precise prompts.

4. Use caching and reuse. Many providers discount repeated context heavily through prompt caching: when the agent re-reads the same files across turns, the repeat reads can cost a small fraction of the first read. This happens automatically on some platforms and needs enabling on others. Either way, it rewards a stable working pattern: same project, same core files, many turns. Chaotic context-switching across unrelated tasks defeats caching and you pay full price every time.

5. Set spending limits on day one. Every API key gets a monthly spending limit and an alert threshold, set before the first real session, not after the first surprise. Most providers offer this in their console. For subscriptions with overage, turn on usage notifications. The developers who get burned are not the ones with high usage; they are the ones with high usage and no alarm.

6. Kill runaway sessions early. Learn what a flailing agent looks like: repeated tool calls with no progress, growing reasoning traces, tests failing the same way twice. When you see it, stop the session, tighten the spec, shrink the context, and restart. Every minute of flailing is tokens you will never get back, and agents rarely recover on their own from a truly confused state. Intervening early is a financial skill, not just an engineering one.

7. Track weekly, not monthly. Monthly bills arrive too late to change behavior. A quick weekly glance at your usage dashboard, sessions count, rough token trend, any overage, is enough to catch a bad pattern while it is still cheap. The first month with any new tool deserves this attention; after that, your habits are usually stable enough to check monthly.

8. Separate the desk from the scripts. A common and effective setup: a subscription for your personal daily work, where the flat fee buys predictability, and API keys with hard spending limits for anything automated, scripts, CI-adjacent tooling, experiments. Mixing the two, running automation on a personal subscription or doing daily work on an uncapped API key, is how surprise bills happen.

The Math That Actually Matters

After all the tactics, here is the frame that keeps costs in perspective. The right question was never "how do I spend as little as possible." It is "what is the return on each dollar of compute."

Even a heavy usage-based bill, in the hundreds per month, is cheap compared to engineering time. One hour of a senior developer's week, saved or redirected to higher-value work, pays for the most aggressive agent usage several times over. The developers who should worry are not the heavy users with big bills and big output; they are the users with big bills and nothing to show for them, which is always a workflow problem, never a pricing problem.

So run the numbers honestly. Track what you spend. Track what you ship. If the ratio is good, the absolute number does not matter much. If the ratio is bad, the fix is in your habits, context discipline, model tiering, precise specs, not in hunting for a cheaper vendor. The vendors all buy from the same token economy; the developers who win are the ones who learned to spend tokens well.

Cost is a feature of your workflow now, not a footnote on someone else's pricing page. Treat it like any other engineering resource: measure it, budget it, optimize it. The era of not thinking about what a coding task costs is over, and honestly, that is an improvement. Invisible costs were never actually cheap; they were just unexamined.

How much are you actually spending per month, and which tactic cut your bill the most? I am curious where the real-world numbers land.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

Is Vibe Coding Dead? What Replaced It in 2026?

aozora — Sat, 17 Oct 2026 14:25:16 GMT

Is vibe coding dead? The pure form of it, yes: describing what you want in a chat box, accepting whatever the agent produces, and shipping it. That approach had a glorious eighteen-month run, and it ended the way every shortcut ends, at the exact moment someone had to maintain the result.

But the instinct behind vibe coding, the speed, the conversational flow, the feeling of building software at the speed of thought, did not die. It got domesticated. What replaced vibe coding in 2026 is not its opposite. It is vibe coding with rails: spec-driven development, agent skills, eval harnesses, and a human back in the loop where it matters. Let me explain what happened, why it had to happen, and what the working method looks like now.

What Vibe Coding Actually Was

The term was coined by Andrej Karpathy in February 2025, and it captured something real. For the first time, a person who could barely code could describe an app in plain language and watch an AI agent build it. No planning documents, no architecture diagrams, no test suites. Just vibes: prompt, run, see what breaks, ask the agent to fix it, repeat until it looks right.

And for a certain class of work, it was genuinely magical. Landing pages, weekend prototypes, internal tools, hackathon demos, the kind of software with a short life expectancy and a single author. Vibe coding lowered the floor of who could build software, and that was a real achievement. Thousands of people shipped their first app in 2025 because the barrier to entry collapsed to "can you describe what you want?"

The problem was never the first weekend. The problem was month three.

Why It Hit the Wall

Every developer who vibe-coded something real eventually met the same wall, usually around the three-month mark, usually at 2 AM. The app works, mostly. Nobody understands it, completely. Here is what goes wrong, in the order it typically goes wrong.

First, context drift. A vibe-coded project lives in chat history. Every prompt, every fix, every "actually, change that back" accumulates into a sprawling conversation the agent can barely keep straight. As sessions get longer, the agent starts contradicting earlier decisions, reintroducing fixed bugs, and confidently rebuilding things that already worked. Research on frontier models keeps confirming the same uncomfortable finding: stuffing more context into the window does not make the agent smarter. Flooded with irrelevant history, it gets worse. Your intent was never written down anywhere permanent, so it decays with every session.

Second, the "almost right" trap. The most common frustration developers report with AI-generated code, showing up as the top complaint in the Stack Overflow 2025 Developer Survey, is output that is almost right but not quite. Vibe coding maximizes this failure mode. The code looks correct. It runs. It passes a casual glance. Then it fails on the edge case you did not think to check, because neither you nor the agent ever wrote down what correct meant. Almost-right code is more expensive than obviously-wrong code, because obviously-wrong code gets caught immediately.

Third, maintenance becomes archaeology. In a vibe-coded codebase, the code is the only artifact. The prompts that produced it are gone, or buried in chat logs nobody kept. When something breaks six months later, there is no design document to consult, no spec to check intent against. You read the code and guess what it was supposed to do, which is exactly the job the AI was supposed to spare you from. Teams inheriting vibe-coded projects report the same experience: it is faster to rewrite than to understand.

Fourth, debugging at scale breaks down. Vibe coding debugs by conversation: "it is broken, fix it." That works for one bug. It collapses when the bug is an interaction between three features built in three separate chat sessions, each with its own assumptions. The agent cannot hold the whole system in its head because nobody ever gave it the whole system, just a sequence of vibes.

Fifth, security. Veracode's 2025 testing across more than a hundred models found that 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities. That number should sober anyone shipping vibe-coded code that touches authentication, payments, or user data. An agent optimizing for "looks like it works" does not optimize for "cannot be exploited," and nothing in the vibe coding loop checks the difference.

Karpathy himself drew the line in 2026. His framing was precise: vibe coding raises the floor of what people can build, which is wonderful. But professional engineering has to preserve the quality bar, and you are still responsible for your software, vulnerabilities and all, no matter which agent wrote it. The industry took the hint.

So no, vibe coding is not literally extinct. It is still the fastest way to explore an idea, spike a prototype, or learn an API. But as the default method for building software you intend to keep, it is dead. Something more disciplined took its place.

What Replaced It, Part 1: Spec-Driven Development

The core replacement is spec-driven development, or SDD. The idea is simple enough to fit in one sentence: write down what the software should do, precisely, before the agent writes any code, and make that specification the source of truth everything else derives from.

In practice, a spec-driven workflow looks like this. You write a structured specification: the feature's purpose, its inputs and outputs, the data shapes involved, the edge cases, and how you will verify it works. The agent reads the spec and generates code against it. Tests are derived from the spec, not from whatever the agent happened to produce. When requirements change, you change the spec first, then regenerate. The spec is a living document, and the code is its output.

This flips the vibe coding dynamic exactly backwards. In vibe coding, the code is the artifact and the prompts are disposable, so intent is never recorded. In SDD, the spec is the artifact and the code is disposable, which it should be, because code is the cheapest thing in the loop to regenerate.

The movement has real infrastructure behind it now. GitHub released Spec Kit in September 2025, a toolkit that scaffolds the spec-first workflow, and it hit version 1.0 in August 2026 with well over a hundred thousand stars and support for dozens of coding agents. AWS built Kiro, an IDE designed from the ground up around specs as the unit of work. DeepLearning.AI launched a dedicated course on spec-driven development with coding agents, which is the kind of signal that tells you a methodology has crossed from experiment to mainstream.

Early adopters report dramatically higher first-pass success rates from agents on non-trivial tasks, which makes sense when you think about it. An agent working from a precise spec is doing translation. An agent working from a vibe is doing guesswork. Translation is a much easier job.

But let me be fair, because SDD has failure modes too, and the honest advocates admit them. Thoughtworks put SDD at "Assess, not Adopt" in their late-2025 Radar, which is consultant-speak for "promising, not proven." And spec bloat is real: there are documented cases of thousand-line specifications for trivial features, which is just waterfall with new branding. A spec should be as precise as the task demands and no more. Writing a formal specification for a one-line CSS fix is ceremony, not engineering. The discipline is knowing which work deserves a spec, which brings us to the middle path later in this article.

What Replaced It, Part 2: Agent Skills and Steering Files

The second replacement is quieter but arguably more transformative: agent skills. These are small, versioned files, usually called SKILL.md, that teach a coding agent your team's repeatable workflows: how you write tests, how you do code review, how you structure a migration, what your conventions are. Instead of re-explaining your standards in every chat session, you write them down once, and every agent run picks them up automatically.

If specs are the blueprint for a specific feature, skills are the building code for everything you construct. And they compound. A team that invests in a good skill library finds that a mid-tier agent with great skills outperforms a frontier agent with none, because the skills carry institutional knowledge the model never had.

Closely related are steering files: AGENTS.md, CLAUDE.md, and their cousins, which sit at the root of a repository and tell any agent working in it how the project works. Conventions, commands, architecture notes, things not to touch. One practitioner put it memorably: steering files are just your vibe, written down where the agent cannot lose it. That line captures the whole transition. Vibe coding failed because the vibe lived in ephemeral chat. The fix was not to kill the vibe but to persist it.

What Replaced It, Part 3: Eval Harnesses and Verification Gates

The third replacement addresses the "almost right" problem head-on: you do not let the agent declare its own work correct. You build the check before the agent starts.

An eval harness is a fixed set of tasks with observable pass/fail criteria, run against the agent's output automatically. It is the same relationship tests have to a refactor: you need the safety net before you let anything change. Teams doing serious agent work in 2026 write the verification first, then let the agent loose, then trust the harness instead of their tired eyes at midnight.

On top of harnesses sit human approval gates: explicit checkpoints where nothing proceeds until a person signs off. Destructive operations, schema migrations, anything touching production data, these pause for human review by policy, not by hope. AWS's open-source AI-DLC workflow is a good example of the mature form: it adapts its rigor to the task, lightweight checks for small fixes, full verification for big features, with human gates throughout.

This is the part of the transition that makes the human's job harder, not easier, and that is worth saying plainly. The fantasy was that agents would remove work. The reality is that supervising agents well is skilled work: writing specs, maintaining skills, building harnesses, reviewing diffs at gates. The developers thriving in 2026 are not the ones who handed over the keyboard. They are the ones who built structure around the tool. DORA's 2026 research put it bluntly: time saved writing is often re-spent auditing. The winners are the ones who made the auditing systematic instead of ad hoc.

What Replaced It, Part 4: Context Engineering

The fourth replacement has the least glamorous name and possibly the highest leverage: context engineering, sometimes called ContextOps. It is the practice of governing exactly what the agent sees at each step of its work.

Remember the context drift problem. The naive fix is a bigger context window, and it does not work. The real fix is curation: the agent working on the payment module sees the payment spec, the relevant files, and the test harness, not the entire repository and three weeks of chat history. Specs help here enormously, because a spec is a compact, immutable artifact. You can hand an agent a spec and a file list instead of a chat log, which keeps the work targeted and, as a bonus, token-efficient.

The rule of thumb that experienced agent users keep repeating: a tight context beats a clever prompt every time. Context engineering is that rule turned into a discipline.

The Middle Path: Vibe With Rails

Here is where I part ways with the purists on both sides. The spec-driven crowd is right about drift, but wrong when they prescribe ceremony for every change. The vibe coders are right about speed, but wrong when they ship the spike. The working method in 2026 is both, used deliberately.

Vibe code the exploration. When you do not know what you want yet, a spec is premature. Spike the prototype conversationally, throw it away, keep what you learned. This is what vibe coding was always best at, and nothing about SDD changes that.

Spec the commitment. The moment you decide to keep something, write the spec from what the spike taught you, then let agents build the production version against it. The rule I use: if you would write a ticket longer than two sentences for a human colleague, write a spec for the agent. Shorter than that, the overhead is not worth it.

Put rails under everything. Steering files in every repo, skills for repeated workflows, approval gates on destructive actions, tests before refactors. These cost almost nothing to maintain and they catch the failures that make vibe coding dangerous. The vibe-vs-spec war was always a false choice. The future is vibe with rails: the speed of conversational building, steered by persisted intent.

This is also, not coincidentally, how the best teams already worked before AI. Nobody serious ever shipped a design doc-free feature to production and hoped for the best. The spec is just the design doc, rewritten for an audience that includes agents. The more things change, the more the fundamentals reassert themselves.

The Verdict

So, is vibe coding dead? The undisciplined version, the version where you prompt and pray and ship, is dead as a professional practice. It died of perfectly natural causes: unmaintainable code, untestable output, and security holes nobody checked for. Nobody killed it. It just could not survive contact with production.

What replaced it is not the return of waterfall. It is a new discipline built for a world where code is cheap and intent is expensive: specs as the source of truth, skills as institutional memory, eval harnesses as the verification layer, context engineering as the efficiency layer, and humans at the gates where judgment is required.

The uncomfortable truth underneath all of it: AI did not remove the need for engineering rigor. It raised the price of skipping it. When code took hours to write, sloppiness was throttled by typing speed. Now that an agent can generate a thousand lines before your coffee cools, the only thing standing between you and a mountain of almost-right code is the structure you build around the machine.

Write the spec. Keep the vibe. That is what replaced vibe coding in 2026.

Where do you draw the line? Which of your projects get a full spec, and which ones stay pure vibe? I am curious how others are calibrating this.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

How Do Agent Skills (SKILL.md) Actually Work Under the Hood?

aozora — Sat, 17 Oct 2026 14:23:17 GMT

Here is the straight answer: a skill is a folder containing a markdown file called SKILL.md, plus optional supporting files. When your coding agent starts a session, it loads only each skill's name and one-paragraph description, about 80 tokens per skill. The full instructions stay on disk. Only when your task matches a skill's description does the agent pull the complete file into its context and follow it.

That is the entire trick. There is no magic protocol, no compiled plugin, no API handshake. Skills work because of a mechanism called progressive disclosure: show the model a menu, let it pick, and load the details on demand. Everything else, the frontmatter fields, the scopes, the install tooling, exists to make that simple loop reliable. Let's open the hood and look at each part.

The 30-Second Version: What a Skill Actually Is

Before skills, there were two ways to teach a coding agent how your team works. You could paste instructions into every prompt (tedious, inconsistent), or you could stuff them into a giant config file like CLAUDE.md that loads into every session whether it is relevant or not (expensive, and it pollutes the model's working memory with rules it does not need right now).

Skills are the third option: packaged, reusable expertise that loads only when relevant. A skill is a directory named after the skill, containing a SKILL.md file with YAML frontmatter at the top and markdown instructions below, plus optional extras: reference documents, example files, and scripts the agent can run. Think of it as a specialist you keep on retainer. The agent knows the specialist exists and what they are good at, but only calls them into the room when the job calls for it.

The format started inside Anthropic and was released as an open standard, which is why the same SKILL.md shape now works across Claude Code, Cursor, Codex, Cline, Gemini CLI, and dozens of other agents. Write it once, and it is portable.

Anatomy of a SKILL.md

Every skill has the same skeleton. Here is a realistic example, a small code-review skill, so you can see every part doing its job:

---
name: review-pr
description: This skill should be used when reviewing a pull request or a batch of uncommitted changes. It performs a five-axis review covering correctness, security, performance, readability, and test coverage, and produces a prioritized list of findings with file and line references.
allowed-tools: Bash, Read, Grep
---

# PR Review

You are reviewing code changes. Follow this process exactly.

## 1. Gather the diff

Run `git diff` against the target branch (default: `main`). If the
changeset is larger than 500 lines, review it file by file and summarize
each file before giving findings.

## 2. Review on five axes

- **Correctness:** logic errors, off-by-one mistakes, unhandled edge cases.
- **Security:** injection points, auth checks, secrets in code.
- **Performance:** N+1 queries, unnecessary allocations, blocking calls.
- **Readability:** naming, dead code, misleading comments.
- **Tests:** are the new paths covered? Would you bet on them?

## 3. Report

List findings ordered by severity: blocker, should-fix, nitpick.
Every finding needs a file path, a line number, and a one-line
suggested fix. If there are no blockers, say so explicitly.

Three things to notice. First, the frontmatter: name and description are the two required fields. The name is lowercase letters, numbers, and hyphens, up to 64 characters. The description is capped at 1024 characters and has one job: explain what the skill does and when the agent should use it. That "when" clause is not decoration. It is the trigger mechanism, and we will come back to it.

Second, the optional allowed-tools field restricts which tools the agent may use while executing the skill. You can also set a different model for the skill, run it in an isolated subagent with context: fork, or mark it user-invocable so people can call it directly. These are refinements; name and description are the load-bearing walls.

Third, the body is plain markdown instructions, written the way you would brief a competent colleague. No code, no schema, no ceremony. The skill above is under 200 words, and that is a feature: convention says keep SKILL.md under about 2000 words and move deep detail into a references/ subdirectory that loads only on demand.

Progressive Disclosure: The Three Stages

The reason skills scale, you can have fifty installed without drowning your agent, is that the agent almost never reads them. Loading happens in three stages, and each stage costs more context than the last:

Stage 1: Discovery. At session start, the agent indexes every installed skill but loads only the metadata: name plus description, roughly 80 to 100 tokens per skill. In Claude Code this surfaces as a system reminder listing the skill catalog. Fifty skills cost you about 5,000 tokens of menu. That is the whole point: the agent knows what is available without reading any of it.

Stage 2: Activation. When your request matches a skill's description, the agent invokes its Skill tool with the skill's name, and the full SKILL.md body loads into context. This is the moment the specialist walks into the room. The body typically runs a few thousand tokens, and it stays in context for the rest of the session, so loading skills you will not need is pure waste.

Stage 3: Execution. If the skill references bundled resources, scripts in a scripts/ folder, detailed docs in references/, worked examples, those load only when the agent actually reaches for them during execution. Unlimited depth, zero upfront cost.

This design is a direct answer to the context-window economy. A 500-line CLAUDE.md with a worked example for every policy pollutes the model's identity on every single session. Skills keep the menu cheap and make the meal pay-as-you-go. It is also why skill bodies persist until context compaction: once loaded, they are part of the session's working memory, for better or worse.

How the Agent Decides: The Description Is the Router

Here is the part most skill authors get wrong. Nothing about the skill's body influences whether it gets used. The model never sees the body until after it has decided to load it. The entire routing decision happens on the description field.

Concretely, the flow looks like this:

At startup, the agent builds its catalog: every skill's name and description.
You describe a task. The model compares your intent against the descriptions semantically, the same way it matches anything else in language.
On a match, the agent calls its Skill tool with the skill name. The body loads. The agent follows it.

That makes the description the single highest-leverage text you will write. Community convention, distilled from what actually fires in practice:

Write in third person: "This skill should be used when..."
Say when to trigger, with the specific phrases a user would actually type. If people say "review my PR," those words belong in the description.
Be specific and a little pushy. Models undertrigger; a timid description ("general code utilities") gets skipped while a precise one ("use when migrating a REST endpoint to GraphQL") gets picked.
Stay under 1024 characters, single line, no angle brackets. The indexer is picky about formatting.

There is one more rule that surprises people: never write Read .claude/skills/my-skill/SKILL.md inside a prompt or inside another skill. That forces the Read tool to load the full body unconditionally, bypassing discovery entirely. You pay the context cost whether the skill was relevant or not, and you defeat the routing you just carefully designed. The Skill tool exists for on-demand loading; the Read tool exists for one-off file viewing. Trust the mechanism and let the model pick.

Where Skills Live: Scopes

A skill's location determines who sees it. Claude Code checks several scopes, in precedence order:

Enterprise or managed skills, from a policy-controlled path. Your org's standard practices, pushed centrally.
Personal skills, in ~/.claude/skills/. Yours everywhere: every project, every session.
Project skills, in .claude/skills/ directories, walking up from your current working directory. These travel with the repo, which means your team's practices check into version control alongside the code they govern.
Additional directories, passed explicitly, for the exotic setups.

The format also extends beyond Claude Code. Gemini CLI looks in .agents/skills/ or .gemini/skills/ with the same /SKILL.md shape, and symlinks work, so teams share one skills folder across CLIs. Plugin authors bundle skills inside /skills/, namespaced so they do not collide with yours.

One practical note: keep each skill exactly one directory deep, /SKILL.md. Nested categories like skills/dev/testing/SKILL.md are not reliably discovered. Flat and boring wins.

Skills vs Slash Commands vs Tools

Three things get confused constantly, so let's separate them:

Skills load automatically. The model reads the catalog and invokes the skill itself when your task matches. You do not type anything special. They are for workflows the agent should just do: review this PR properly, write the migration the way we do migrations.

Slash commands are manual. You type /something and the agent runs that prompt. They are for workflows you choose to start. Many skill libraries ship both: the skill fires on its own when it recognizes the situation, and a companion slash command lets you force it.

Tools are the agent's hands. A script under scripts/ that calls an API or transforms data is a tool: it runs, returns stdout, and has no opinions. The skill is the brain: it holds the policy, the decision logic, the "do not ask the user for the tracking number twice" rule. The dividing line matters. If business logic hides inside a script, the model cannot see it, the skill author cannot review it, and the next person cannot find it. Data in the tool, judgment in the skill.

How Skills Get Onto Your Machine

Nobody hand-writes all of this from scratch anymore. A small ecosystem grew up around installing and sharing skills, and it is worth knowing the two main paths.

The cross-agent CLI. The open skills CLI (from vercel-labs) installs skill repos into 70-plus agents with one command: npx skills add /. It knows where every agent keeps its skills, copies the skills/ directories into the right place, and lets you pick individual skills with --skill or browse first with --list. Updates come through npx skills update. There is also a leaderboard at skills.sh where installed skills surface automatically, no registration step. This is the fastest way to go from zero to a working catalog.

Native plugin installs. Each agent also has its own plugin route: /plugin inside Claude Code, the plugin marketplace in Codex and Copilot, extension installs in Gemini CLI. Plugins bundle skills with a manifest, namespace them to avoid collisions, and usually self-update. Pick the CLI for speed and portability, the plugin route for versioning and namespacing.

The libraries worth knowing. A few collections became the reference implementations everyone learns from. Matt Pocock's skills library focuses on small, composable, spec-driven engineering workflows: turn tickets into specs, specs into implementations, with setup skills that ask about your issue tracker and conventions once per repo. Addy Osmani's agent-skills ships around 25 production-grade engineering skills covering the full lifecycle, spec to test to review to ship, with slash commands for each phase. Anthropic publishes official skills as reference examples. These are worth reading even if you never install them, because they show what good descriptions and tight bodies look like in the wild.

One portability caveat the library READMEs are honest about: installing a single skill with npx skills add --skill copies only that skill's folder, not the repo-level references/ directory that shared checklists may live in. The skill still works, but links to those shared files break. If a skill leans on shared references, install the whole repo or vendor the checklists into the skill's own references/ folder.

Writing a Skill That Actually Fires

If you take one thing from this article, make it this: most skills fail at the description, not the body. A brilliant 1500-word workflow with a vague description is a book nobody opens. Some rules that hold up:

Name it like a command, describe it like a trigger. The name is an identifier (review-pr); the description is a bouncer deciding who gets in ("This skill should be used when reviewing a pull request...").

Put the user's words in it. The model matches your task against descriptions semantically, but semantic matching still starts from vocabulary. If your team says "cut a release," the description should say "cutting a release," not "software delivery lifecycle management."

One job per skill. A skill that does code review and writes changelogs and updates the roadmap will trigger on all three and do each one worse. Small, composable skills beat Swiss-army skills, and they combine better: a release skill can call on the review skill and the changelog skill in sequence.

Keep the body tight. Under 2000 words for SKILL.md itself, with the deep material in references/. Remember stage 2: the whole body enters context the moment the skill fires and stays there. Every paragraph should earn its tokens.

Version it with the repo. Project-scoped skills in .claude/skills/ get committed alongside code, which means skill improvements go through the same review process as code improvements. When the team's review checklist changes, the skill changes in the same PR. That is the whole institutional-knowledge idea working as intended.

The Failure Modes

Skills are simple, which means their failure modes are instructive rather than mysterious:

1. The stale skill. A skill is a promise the agent keeps faithfully, including the outdated parts. A deployment skill that references a retired staging environment will march your agent straight into it. Treat skills like code: review them, expire them, delete the ones nobody triggers anymore. A stale rule does real damage precisely because the agent obeys it.

2. The trigger-happy description. The mirror image of undertriggering. A description so broad ("use for any coding task") that it fires on everything, loading thousands of tokens into sessions that did not need them. Specificity is a budget decision.

3. The context hog. A skill body that dumps everything the author knows instead of what the agent needs right now. Progressive disclosure only works if you actually disclose progressively. If the body is 4000 words, you have written a manual, not a skill; split it.

4. The bypass. Someone writes "first, read .claude/skills/x/SKILL.md" into a prompt or another skill, and suddenly the full body loads unconditionally on every matching session. It feels helpful. It quietly doubles your context spend.

5. The ghost reference. The single-skill install that leaves shared checklists behind, so the agent follows a link to a file that does not exist and improvises. Either install whole repos or keep each skill self-contained.

None of these are arguments against skills. They are arguments for treating skills as engineering artifacts: small, reviewed, versioned, and deleted when they stop earning their keep.

The Quiet Power of the Format

Step back and notice what happened here. The most important extensibility mechanism in the coding-agent world is not an SDK, not a plugin API, not a marketplace with revenue share. It is a markdown file with two required frontmatter fields and a three-stage loading trick.

That simplicity is the point. Because a skill is just files, it works with any model, it diffs in git, it survives vendor changes, and a junior developer can read one end to end in five minutes. The open standard means the expertise you encode is an asset you own, not a setting inside someone else's product. Anthropic's own document skills, the ones that let Claude handle Word, PDF, PowerPoint, and Excel, ship in exactly this format. If it is good enough for the platform vendor's flagship features, it is good enough for your team's deploy checklist.

The developers getting the most out of agents in 2026 are not the ones with the cleverest prompts. They are the ones who turned their hard-won practices, the review checklist, the migration runbook, the incident playbook, into skills their agents load exactly when needed and never when not. The model supplies the reasoning. The skill supplies the judgment. That division of labor is the whole game.

Start small: pick one workflow your team repeats weekly, write the description first, keep the body under a page, and watch whether it fires. Then write the second one. The catalog compounds.

Do you have a skill your agent loads every week? I am curious which one earned its place in your catalog, and which one you deleted. The comments are open.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

Claude Code vs Cursor vs Codex: Which One Ships Faster?

aozora — Sat, 17 Oct 2026 14:10:40 GMT

Claude Code vs Cursor vs Codex: Which One Ships Faster?

Here is the straight answer: none of them ships fastest at everything. Claude Code wins on hard refactors and gnarly debugging. Cursor wins on day-to-day feature work where you stay in flow. Codex wins when the job is really ten jobs you can run in parallel. If you pick the wrong tool for the task type, you will watch a "faster" agent lose to a slower one, every time.

So the real question is not which tool is fastest in the abstract. It is which one gets your kind of work from task description to merged pull request in the least wall-clock time, including the time you spend reviewing its output. Benchmarks like SWE-bench measure whether an agent can solve a task at all. Shipping speed measures how long the whole loop takes: spec, generate, verify, fix, review, merge. That loop is where races are actually won and lost.

What "Ships Faster" Actually Means

Let me define the metric, because most comparisons never do. "Ships faster" means: from the moment you start a task to the moment a working PR is merged, how much of your time did it consume? Note the two parts. The agent's compute time barely matters; what matters is your time: writing the spec, waiting, reviewing the diff, catching the mistakes, iterating.

An agent that produces a PR in 4 minutes that takes you 40 minutes to review and fix is slower than an agent that takes 15 minutes and produces a PR you merge after a 5-minute review. Speed without reviewability is just deferred work. Keep that in mind for everything below.

The second thing to know: the models underneath these tools are close enough that raw capability is rarely the differentiator anymore. Community consensus in 2026 is that code quality across the three is comparable on real tasks; each leads on some benchmark or other, but the workflow around the model decides the outcome far more than the model badge. So this comparison is about workflows, not model supremacy.

The Three Contenders, in One Paragraph Each

Claude Code is Anthropic's terminal-first agentic coding tool. It lives where your repo lives, reads your codebase broadly, plans before it acts, and follows instructions with unusual reliability. Its superpower is sustained, careful work on complex code: multi-file refactors, deep debugging, tasks with real dependencies between steps. Its price is that it is deliberate rather than instant, and it burns tokens on that deliberation.

Cursor is the AI-native IDE, a fork of VS Code rebuilt around AI at every layer: tab completion, inline edits, chat, agent mode, cloud agents. Its superpower is flow. You never leave your editor, you never context-switch to a separate tool, and the AI meets you at the exact point of the cursor. It is also model-agnostic, letting you switch between frontier models from different vendors inside one interface.

Codex is OpenAI's coding agent, spanning a terminal CLI, IDE extensions, and cloud sandboxes. Its defining feature is parallelism: native multi-agent support with worktrees, so you can have several agents working on separate tasks at once, plus fire-and-forget cloud runs you delegate and review later. Its CLI is open source. It is the youngest of the three as a standalone product, and it shows in rough edges, but the architecture is the most ambitious.

Round 1: Greenfield Feature Work

This is the bread and butter: a new endpoint, a new component, a new screen, small-to-medium scope, maybe a few files. You know roughly what you want.

Cursor usually wins here. The reason is loop tightness. You describe the feature, the agent scaffolds it inline, you see diffs in the editor instantly, you accept or adjust, tab completion fills the gaps as you hand-tune. There is almost no waiting and almost no context switching. For features you could plausibly write yourself in an hour, Cursor compresses that hour to twenty minutes because the review surface is small and immediate.

Claude Code is overkill for most greenfield work of this size. It will do a fine job, often a more careful one, but you pay in setup and deliberation time for thoroughness you do not need on a fresh file with no legacy constraints.

Codex can handle greenfield features, especially via a quick cloud run, but the async model adds latency to a task where you want instant feedback. Delegating a 20-minute feature to a background agent and waiting is slower than just building it with inline assistance.

Winner for greenfield features: Cursor, by loop tightness.

Round 2: Large Refactors

Now the hard one: rename the core abstraction across 40 files, split the monolith module, migrate the state management pattern. Steps have dependencies. A wrong move breaks everything. This is where "fast" agents go to die.

Claude Code wins here, clearly. This is the task it was built for. It maps the dependency graph before touching anything, works through steps in order, runs the tests between changes, and, crucially, follows the plan instead of improvising halfway through. Developers consistently report it as the most reliable at strict plan adherence, which is the entire game in refactoring: the plan is the work.

Cursor can do refactors, and its agent mode has improved, but refactors are where its speed becomes a liability. Fast multi-file edits with weaker dependency tracking mean more broken intermediate states for you to untangle. You end up spending your saved time on review and repair.

Codex's parallelism is actually a poor fit for most refactors, because refactor steps are rarely independent. Spinning up parallel agents on a task with hidden dependencies is how you get merge conflicts with yourself.

Winner for large refactors: Claude Code, by plan discipline.

Round 3: Debugging

The bug is in production, the symptom is three layers from the cause, and nobody fully understands this part of the system anymore. Debugging is search plus reasoning, and the search space is the whole repo.

Claude Code wins again, for a specific reason: it investigates before it prescribes. Its whole-codebase agentic search means it actually reads the relevant code paths instead of guessing from the error message. The failure mode of weaker debugging agents is the confident wrong fix: a patch that silences the symptom and ships a new bug. Claude Code's deliberation costs tokens and minutes, but a wrong fix costs hours and sometimes an incident.

Cursor is fine for shallow bugs: the typo, the off-by-one, the misconfigured prop. Its speed shines when the search space is one or two files. But for deep bugs it tends to propose fixes before it has finished understanding, and you become the investigator anyway.

Codex is a mixed bag for debugging. Its terminal-bench strength suggests it is capable, but debugging is inherently interactive: each finding reshapes the next question. Fire-and-forget async runs fit poorly with that loop.

Winner for debugging: Claude Code, by investigation depth.

Round 4: Bulk Migrations

Twenty services need the same dependency bump. A deprecated API must be replaced in 300 call sites. Test coverage needs to go from 40 percent to 70 percent across the repo. The tasks are numerous, similar, and mostly independent.

Codex wins, and it is not close. This is the workload its architecture was designed for: spin up parallel agents in worktrees, one per service or per batch, and let them grind while you do something else. No other tool in this comparison parallelizes natively. What takes you a week of serial evenings becomes an afternoon of review.

The catch, and it is a real one: you become a manager. Parallel agents with vague instructions produce parallel messes, and review is now your full-time job during the run. The developers who win with Codex on migrations invest heavily upfront in task specs and verification scripts. Ten minutes of spec per batch saves hours of divergent output.

Claude Code can do migrations serially and carefully, but serial is serial: one agent, one task at a time. For truly bulk work, careful-and-serial loses to parallel-and-supervised.

Cursor is the wrong tool for bulk migrations almost by definition. It is built for one developer in flow, not for fleet operations.

Winner for bulk migrations: Codex, by parallelism.

Round 5: The Daily Editing Flow

There is a fifth category most comparisons skip, and it might be the most important: the hundred tiny interactions per day. Autocomplete a function, rename a variable across the file, explain an error message, write the boring test. No single one matters; together they are half your day.

Cursor dominates here. Advanced tab completion trained on your patterns, inline edits without opening a chat panel, instant answers without leaving the editor. The time savings are measured in seconds per interaction, but seconds times a hundred is real. None of the terminal agents compete in this category because the category is about not switching tools.

This is also Cursor's moat: even developers whose "real" agent work happens in Claude Code or Codex keep Cursor (or a similar AI IDE) open for the daily flow. The tools are complements, not substitutes.

Winner for daily flow: Cursor, by zero friction.

Where Each One Loses Time

Winning a category is only half the story. Each tool has a characteristic way of wasting your time, and knowing it in advance is worth more than any feature list.

Claude Code loses time to deliberation and token burn. It reads more, plans more, and verifies more than the task sometimes needs. On simple tasks this is pure overhead. It is also usage-metered in a way that punishes exactly its strength: long, careful sessions on big repos. If you point it at everything, your bill and your afternoon both evaporate. Reserve it for work that deserves deliberation.

Cursor loses time to the request meter and to over-delegation. Its subscription tiers include limited premium agent requests, and power users discover that the agentic workflows Cursor encourages are exactly what consume the allowance fastest. The subtler time loss: because it is so frictionless, you delegate things you should have just typed, then spend longer reviewing than typing would have taken. Frictionless tools need disciplined users.

Codex loses time to management overhead and latency. Parallel agents need specs, and specs take time to write. Async cloud runs add round-trip latency to every iteration. And review scales with output: five agents produce five diffs, and skimming five diffs carefully is genuinely slower than reviewing one. Codex makes generation parallel; judgment stays serial, and judgment is the bottleneck.

Notice the pattern: every tool's weakness is the shadow of its strength. There is no free speed. There is only choosing which kind of work you want to do yourself.

The Cost Question, Briefly

Pricing changes quarterly in this market, so verify current numbers before deciding. The structural facts that matter: Cursor and Claude Code both sit around the familiar twenty-dollar monthly tier for individual plans, with heavier usage pushing you into higher tiers or metered overage. Codex pricing has moved around as the product matured, so check OpenAI's current terms.

But the purchase price is the least interesting part of the cost. The real cost questions are the ones from the previous section: How many premium requests does your workflow burn? How token-hungry is a careful agent on your monorepo? How much of your salary-equivalent time goes into review? A developer who bills their own time honestly usually finds that one avoided bad afternoon pays for months of any of these tools. Buy the workflow, not the price tag.

The Decision Framework

Enough rounds. Here is how to actually choose.

Step 1: Audit your task mix. For two weeks, notice what you actually do. What percentage is greenfield features, refactors, debugging, bulk migrations, daily editing? Most developers are shocked by the answer. The tool should match the plurality of your work, not the most exciting 10 percent of it.

Step 2: Pick your primary by plurality.

Mostly features and daily coding: Cursor.
Mostly refactors and hard debugging: Claude Code.
Mostly migrations and parallelizable batch work: Codex.

Step 3: Consider the two-tool stack. The most productive developers in 2026 rarely use just one. The common winning combos:

Cursor + Claude Code: Cursor for daily flow and features, Claude Code in the terminal for refactors and deep debugging. Different task types, no overlap, no conflict.
Cursor + Codex: Cursor for hands-on work, Codex for delegated batch tasks running in the background while you keep coding. Review Codex output in Cursor's diff view.
All three: daily work in Cursor, complex engineering in Claude Code, fleet tasks in Codex. This sounds extravagant until you price it against a single wasted senior-engineer day per month.

Step 4: Match the interface to your nervous system. This sounds soft, but it decides everything. Some developers think in terminals; some think in editors. Forcing a terminal-native developer into an IDE-first workflow (or vice versa) costs a week of friction that no feature list repays. The decisive questions are "terminal or editor?" and "one model vendor or model-agnostic?" Answer those honestly and the choice usually makes itself.

How to Make Whichever You Pick Ship Faster

The tool is maybe 30 percent of shipping speed. The rest is technique, and it transfers across all three:

Write the spec before you prompt. What does done look like? What must not change? How will you verify? Ten minutes of spec routinely saves an hour of agent flailing. This is the highest-leverage habit in AI-assisted development, and almost nobody does it consistently.

Verify in the loop, not at the end. Tests running between steps, diffs reviewed per chunk, not per PR. The longer an error survives, the more expensive it gets. Agents that verify as they go ship faster than agents that generate impressively and collapse at the end.

Constrain the context. Point the agent at the relevant files. A tight context means faster runs, cheaper runs, and better output, because the agent spends its attention on your actual problem instead of your entire repo.

Review like it matters, because it does. The review burden is the hidden term in every speed equation. Skimmed reviews ship bugs; bugs ship incidents; incidents are the opposite of fast. Budget review time explicitly instead of treating it as free.

Measure your own loop. Time a few tasks end to end with each tool you are evaluating: spec to merged PR, including your review time. Your codebase, your habits, your numbers. Nobody else's benchmark survives contact with your reality.

The Takeaway

So, which one ships faster? Cursor ships features fastest. Claude Code ships refactors and fixes fastest. Codex ships migrations fastest. The developers who ship fastest overall are not the ones with the fastest tool; they are the ones who match the tool to the task, spec tightly, verify continuously, and treat review as part of the job rather than an afterthought.

Speed was never really about the agent. The agent is leverage, and leverage multiplies whatever you bring to it: your clarity, your discipline, and yes, your sloppiness too. Pick the workflow that fits your work, measure your own loop, and spend your optimization energy on the spec and the review. That is where the hours actually live.

Which of the three is your daily driver, and what task type made you choose it? I am curious where your experience matches or breaks this breakdown.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

Can You Really Build a Side Project With AI and Zero Coding?

aozora — Thu, 15 Oct 2026 12:00:09 GMT

Yes. In 2026, a person who has never written a line of code can describe an app in plain language in the morning and have a working, deployed product by the evening. That part is real. It is not a demo trick, and it is not limited to toy projects. People are shipping real side projects this way: booking tools, directories, internal dashboards, small paid products.

But here is the part the landing pages skip: "zero coding" does not mean "zero technical judgment." Everyone who actually ships something real with these tools ends up learning the same handful of non-coding skills: how to specify what they want precisely, how to test what they got honestly, and when to stop trusting the machine.

So the complete answer is yes, with an asterisk. You can build it without writing code. You cannot secure it, maintain it, or grow it without understanding how software works at the level of concepts. The good news is that this level is learnable in weeks, not years. This article is the map: the tools, what people actually ship, where it breaks, and the framework that separates shipped projects from abandoned demos.

What "Zero Coding" Actually Means in 2026

The phrase covers two very different families of tools, and confusing them is the first mistake beginners make.

Prompt-to-app AI builders turn plain-language descriptions into real code and deploy it. Lovable, Bolt, Replit's Agent, and v0 live here. You chat, the tool writes a full application (frontend, backend, database), and you get a live URL. Under the hood there is real code, usually modern web stacks, and most of these tools let you export it or sync it to GitHub.

Visual no-code platforms let you assemble apps from drag-and-drop components without any code existing in a form you would recognize. Bubble, Glide, and Base44 live here. You trade away code ownership for simplicity: in Bubble's case, there is no clean code export, so your app lives on their platform permanently.

The practical difference: with prompt-to-app builders you are commissioning code from a very fast, very literal junior developer. With visual no-code you are assembling furniture from a kit. Both can produce a real product. They fail in different ways, which we will get to.

The Tools, Honestly Compared

Lovable is the best starting point for most non-coders who want a real product. You describe the app in chat, it generates a full-stack application with a Supabase Postgres backend, authentication, and hosting, and it syncs two ways with GitHub so the code is yours. That last part matters more than beginners realize: code you can export is an asset; code trapped on a platform is a rental.

Pick Lovable if: you want to ship something you might one day hand to a real engineer, charge money for, or keep alive for years.

Bolt (bolt.new) is the fastest path from an idea to a live URL in a browser tab. It generates full-stack apps from prompts and runs entirely in the browser. It is superb for prototypes, hackathons, landing pages with real functionality, and validating an idea this weekend.

Pick Bolt if: speed of validation is the whole game and you accept that the codebase may be disposable.

Replit is a real cloud development environment with an AI Agent that builds and deploys from prompts. Unlike the pure prompt builders, it is a genuine Linux runtime: background processes, scheduled jobs, many languages. When your "side project" needs real server-side behavior (a scraper, a bot, a cron job, a Python service), Replit is the serious option.

Pick Replit if: your project does things on a schedule or behind the scenes, not just web pages.

v0 by Vercel is the sharpest tool for generating polished user interfaces, tuned for React and with a direct path to Vercel hosting. If your project is UI-heavy and design quality matters (a marketing site with interactive tools, a beautiful dashboard), start here.

Pick v0 if: the interface is the product.

Bubble, Glide, and Base44 are for builders who want as little technical surface as possible. Glide is excellent for internal tools built on top of spreadsheet-like data. Bubble handles genuinely complex web apps visually but locks you into its runtime with no code export. Base44 generates simple apps from very short prompts and is cheap to start with.

Pick these if: you never want to see code, even exported code, and you accept platform lock-in as the price.

One more honest note on pricing: most of these tools are credit or token metered, and your real bill is decided by how much you iterate, not the sticker price. Entry paid tiers generally cluster in the tens of dollars per month, but pricing in this market changes every quarter, so check current plans before committing. Budget for your heaviest building month, not your calmest.

What Non-Coders Actually Ship

Forget the hype reels. Here is what people without coding backgrounds reliably get into production, roughly ordered by difficulty:

Landing and waitlist pages with real behavior. Email capture, pricing calculators, interactive demos. This is the safest first project: if it breaks, nothing of value is lost, and you learn the whole loop of prompting, previewing, and deploying.

Internal tools and dashboards. A dashboard for your own business data, a small CRM, an ops tool for a team. The users are people you know, the data is yours, and "good enough" really is good enough. Glide and Replit shine here.

Directories and content sites. Curated lists, job boards, resource collections. Mostly reading from a database and displaying it nicely, which is exactly what AI builders do well.

Simple paid products. A tool with login, a database, and Stripe payments. This is where Lovable's combination (auth plus database plus payments plus code export) earns its reputation. Entirely achievable, but this is also where the limitations below start to bite, because now strangers trust you with their accounts and money.

AI wrappers and chatbots. A chatbot over your own documents, a writing assistant with your templates. Fast to build, genuinely useful, but remember the value is in your data and workflow, not the wrapper: wrappers are easy to build and therefore easy to copy.

Notice what is not on this list: anything handling health data, financial transactions beyond standard payment processors, or real-time systems at scale. That absence is the next section.

Where It Breaks: The Honest Limitations

Everything below is well documented by now, and ignoring it is how side projects become cautionary tales.

1. Security is the biggest gap. AI-generated code handles the happy path of authentication correctly and misses the edge cases: expired tokens that still validate, overly permissive database rules, secrets pasted directly into code. Security studies keep finding that a significant share of AI-generated code ships with vulnerabilities, and the failures concentrate exactly where context matters: auth flows, permissions, business logic. If strangers will create accounts or pay you money, get a technical person to review the auth and data-access setup before launch. This is not optional.

2. The fix loop. The most common failure mode has a pattern: the AI produces code that is almost right, you ask it to fix the issue, the fix breaks something else, you ask it to fix that, and a new problem appears. Hours vanish. The way out is not more prompting. It is better specifications and smaller steps: when you hit the loop, stop, rewrite the request more precisely, and rebuild that section fresh instead of patching the patch.

3. Silent failures. This is the one founders miss completely. The app looks fine. The button shows a success message. But the database write failed, the email never sent, or the payment webhook returned an error that got swallowed without logging. Test the outcomes, not the screens: did the row appear in the database, did the email arrive, did the money move.

4. Zero test coverage. AI builders generate features, not safety nets. Every change you make later, whether by AI or by a hired developer, has no guardrails. For a side project this is survivable; for anything with paying users it means every update is a gamble. At minimum, keep a written checklist of the ten things that must work, and run through it before every deploy.

5. The three-month hangover. This is the famous one. Three to six months in, the project becomes a black box: you cannot confidently change anything because you do not understand the architecture, and no new developer can understand it quickly either. The prevention is structural: keep the project small, insist on code export from day one, and document what each part does in plain language while it is fresh. A side project you can still understand in six months beats an ambitious one you abandon.

The Framework: From Idea to Shipped in Five Stages

Tools do not ship projects; processes do. Here is the process that works for non-coding builders, and each stage has a clear exit test.

Stage 1: Validate before you build. Talk to ten potential users before generating a single screen. Better yet, ship a landing page describing the product with an email signup, and see if strangers care. AI makes building cheap, which makes building the wrong thing the dominant risk. A weekend of validation beats a month of building something nobody wants. Exit test: ten people who are not your friends say they want it.

Stage 2: Spec it like an engineer. Before prompting, write down in plain language: who the users are, what each user can do step by step, what data the app stores, and what "done" looks like for version one. This document is the highest-leverage artifact in the entire project. Vague specs produce vague apps; every hour here saves many hours in the fix loop later. Exit test: a stranger could read your spec and describe your app back to you accurately.

Stage 3: Build in small slices. Do not ask for the whole app at once. Build one slice (say, user signup), test it thoroughly, then add the next slice (say, the core feature). Small slices keep the AI's context tight, make failures easy to locate, and give you a working product at every step instead of a big bang that big-bangs. Exit test: each slice works end to end before the next begins.

Stage 4: Harden before launch. This is the stage beginners skip and later regret. Walk through the security basics: can users see each other's data, are secrets out of the code, what happens when someone enters garbage into every field. Run your ten-thing checklist. Have a technical friend spend one hour clicking through with malicious curiosity; offer them dinner, it is the cheapest security audit in existence. Set up basic backups of your data. Exit test: you have tried to break it and failed.

Stage 5: Maintain or sunset deliberately. Decide up front what happens after launch. Either keep the scope small enough that you can maintain it with occasional AI help, or budget for a developer to take over the parts that matter. The worst outcome is not failure; it is a half-alive app with real users and nobody able to fix it. A clean sunset (export the data, tell users, shut it down) is a respectable ending. Exit test: you know who fixes it when it breaks at 2 AM, even if the answer is "nobody, and here is the shutdown plan."

What You Still Have to Learn (the Non-Coding Curriculum)

"Zero coding" was never "zero learning." Here is the actual curriculum, and none of it requires writing code:

Writing specifications. The ability to describe exactly what you want, including edge cases. This is the single most valuable skill in the AI-building era, and it transfers to everything: managing developers, writing product requirements, even writing good prompts for anything else.

Data modeling basics. What information your app stores, how pieces relate (users have orders, orders have items), and what should never be deletable. You do not need SQL; you need to think clearly about what exists in your app's world.

How authentication actually works. What a login session is, why password resets are sensitive, what "row-level security" means in plain terms: users should only ever see their own data. You need this to evaluate whether your AI builder set it up correctly.

Reading error messages and logs. When something breaks, the app usually tells you what happened in logs. Learning to read them, copy the relevant part, and hand it back to the AI (or to a human helper) turns you from helpless into effective.

Testing like a skeptical user. Click everything, enter nonsense everywhere, try two browsers, try it on your phone. Systematic distrust is a skill, and it catches most silent failures.

Cost awareness. Credits, tokens, hosting, database rows, email sends: know what each action costs on your platform, and check the dashboard weekly while building actively. Surprise bills come from surprise iteration, and both are preventable.

All of this is learnable in weeks of evenings. Compare that to the years a traditional development education takes, and the bargain becomes clear: the AI removed the syntax barrier, and what remains is judgment, which was always the scarce part anyway.

The Money Question, Answered Plainly

Can the project pay for itself? For the categories listed above, usually yes, with honest math.

Your costs are the builder subscription, plus any usage overages during heavy building months, plus third-party services (payment processing takes its standard cut, email services charge by volume). Your revenue, if any, comes from subscriptions or one-time payments for something people value. The projects that work financially share a trait: they solve a painful, specific problem for a defined group, and they charge from early on. Free users give you feedback; only paying users give you a business.

What does not work is building a generic AI wrapper and hoping for viral growth. Wrappers are trivially easy to build now, which means they are trivially easy to copy, which means the moat has to be distribution, data, or workflow depth, never the wrapper itself. Be honest with yourself about which one you have before spending six months on it.

The Verdict

So: can you really build a side project with AI and zero coding? Yes, and thousands of people now prove it every month. The honest version of the dream is not "type a sentence, get a business." It is this:

Pick a small, specific problem. Validate it with real humans. Spec it carefully. Build it in slices on a platform that lets you export your code. Harden it before strangers trust it with their data. Keep it small enough to understand, or budget for help when it grows.

The people who fail at this usually fail at the human parts, not the technical ones: they build without validating, they skip the spec, they trust the demo instead of testing outcomes, they launch with other people's data on an unreviewed auth setup. Every one of those failures is avoidable with the framework above.

And here is the calm takeaway for the developers reading this: none of this threatens your craft. The judgment you spent years building, specifications, data modeling, security thinking, debugging discipline, is exactly what the non-coding builders are now forced to learn the hard way. The syntax was never the moat. It was always the thinking. AI just made that visible to everyone.

Build the thing. Spec it well. Test the outcomes. And when it handles real user data, get a second pair of technical eyes on it before you celebrate.

Have you shipped something without writing code? What broke first, and what would you do differently? The comments are open.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.

Which AI Coding Agent Is Actually Worth Paying for in 2026?

aozora — Thu, 15 Oct 2026 11:30:55 GMT

If you write code for a living in 2026, you have probably already paid for at least one AI coding tool — and you have probably wondered, at 2 AM, staring at a usage dashboard, whether it was worth it. The market went from "GitHub Copilot and not much else" to a crowded shelf of agents in barely two years: Cursor, Claude Code, OpenAI Codex, GitHub Copilot, Cline, Windsurf, and a long tail of newcomers. Every one of them claims to 10x your output. Most of them want your credit card.

So let's ask the question properly: which AI coding agent is actually worth paying for in 2026? Not which one has the best demo, not which one trends on GitHub for a week — which one earns its subscription, month after month, in real work.

The honest answer is that there is no single winner. But there is a right answer for you, and it depends on something most comparisons skip: what kind of leverage you actually need. Let's break it down.

What "Worth Paying For" Really Means

Before comparing tools, we need a working definition of value. An AI coding agent is worth paying for when the time it saves you — or the capability it unlocks — is worth more than its total cost. And total cost is not just the sticker price. It has three parts:

The subscription or usage bill. Flat monthly plans are predictable; usage-based pricing scales with how much you actually lean on the agent. Heavy users on usage-based plans can easily outspend a flat subscription several times over.
Token efficiency. This is the hidden line item. Two agents powered by comparable models can burn wildly different amounts of tokens on the same task, depending on how their harness manages context — how much of your codebase it stuffs into the prompt, how many round trips it makes, how often it retries. As agents get more capable, token efficiency increasingly matters more than the sticker price.
Your time spent supervising. An agent that writes 500 lines in a minute but needs 30 minutes of careful review and rework is not obviously better than one that writes 100 careful lines. The review burden is real, and it grows with the agent's autonomy.

Keep those three in mind. Every tool below will be judged against them.

The Contenders

Claude Code: The Deep Thinker

Claude Code is the terminal-native agent from Anthropic, and it has become the default choice for developers working in large, messy, real-world codebases. Its strength is reasoning depth: it reads broadly, plans before acting, and handles multi-step refactors that span dozens of files without losing the plot.

Where it shines: exploring unfamiliar code, architectural refactors, debugging sessions where the bug is three layers removed from the symptom, and long autonomous runs where you give it a well-specified task and come back later. Developers consistently report that it "gets" intent better than competitors on complex tasks.

Where it costs you: it is usage-based, and deep reasoning burns tokens. A long session spelunking through a big monorepo can get expensive fast. It also lives in the terminal, which is either home or a dealbreaker depending on your workflow.

Worth paying for if: you regularly work on large codebases, refactors, or ambiguous problems where reasoning quality beats raw speed. If your work is mostly small, well-scoped edits, you are paying for depth you rarely use.

Cursor: The Speed Demon

Cursor is the AI-native IDE — a fork of VS Code rebuilt around AI assistance — and it remains the pick for developers who want AI woven into every keystroke. Tab completion, inline edits, multi-file changes, and an agent mode, all without leaving the editor.

Where it shines: flow state. If you live in your editor and want AI that feels like an extension of your hands rather than a separate tool you delegate to, Cursor is unmatched. Its inline suggestions are fast and eerily well-tuned to your style after a while.

Where it costs you: the subscription model has limits, and power users hit them. Multi-file agent runs consume premium requests, and once you develop the habit of delegating everything to the agent, the meter runs. Some developers report that the per-request economics punish exactly the agentic workflows Cursor encourages.

Worth paying for if: you want AI inside your editor loop all day and you write a lot of code by hand with AI assistance rather than delegating whole features. It is the best "pair programmer" of the bunch.

OpenAI Codex: The Parallel Worker

Codex is OpenAI's coding agent, built for parallel and background workflows — spin up multiple agents on different tasks, let them work, review the results. It leans into the "fleet of interns" model of AI-assisted development.

Where it shines: throughput. If your bottleneck is the number of independent tasks you can advance at once — migrations across many services, bulk test coverage, parallel feature branches — Codex's model of concurrent background agents is genuinely different from a single brilliant assistant.

Where it costs you: parallel agents multiply token burn by definition. Five agents working at once is five meters running. The review burden also scales: you become a manager of AI workers, and management is work.

Worth paying for if: you have many parallelizable tasks and the discipline to spec them tightly. It rewards good task decomposition and punishes vague delegation.

GitHub Copilot: The Incumbent

Copilot was the first mainstream AI coding tool, and in 2026 it is the safe enterprise choice: deep IDE integration, admin controls, predictable per-seat pricing, and the trust that comes with being inside the Microsoft/GitHub ecosystem.

Where it shines: organizations. If you need SSO, audit logs, IP indemnity, and a procurement department that has already approved it, Copilot wins by default. Its completions remain excellent for boilerplate and common patterns, and its agent mode has closed much of the gap with newer rivals.

Where it costs you: on raw capability for hard problems, most independent comparisons now place it a half-step behind the frontier agents. You are paying partly for the ecosystem and compliance wrapper, which is worth a lot to enterprises and little to solo developers.

Worth paying for if: you work in an enterprise, or you want the lowest-friction AI assistance inside VS Code/JetBrains without thinking about it. For individuals chasing maximum capability per dollar, the field has moved on.

Cline, Windsurf, and the Rest: The Specialists

Cline (the open-source VS Code extension) appeals to developers who want control: bring your own API key, pick your model, see exactly what the agent is doing. Windsurf carved out a niche with strong agentic multi-file workflows. Aider remains beloved by terminal purists who want a lightweight, scriptable agent.

Worth paying for if: you have a specific workflow these fit — Cline for model flexibility and transparency, Windsurf for its particular agent UX, Aider for minimal terminal-driven assistance. They tend to be cheaper but demand more setup and judgment from you.

The Pricing Models, Honestly Explained

Pricing in this market changes quarterly, so treat any specific number you read — including in this article — as a snapshot, not a promise. What matters more than today's prices is understanding the models, because the model determines how your bill behaves as your usage grows.

Flat subscriptions (a fixed monthly fee with included usage) are predictable and kind to heavy, bursty users. Their weakness is the fine print: "unlimited" rarely means unlimited, and the throttling or top-up mechanics kick in exactly when you are in the middle of something important.

Usage-based pricing (pay per token or per request) is honest and scales down to zero, which is great for light users. Its weakness is that agent architectures are token-hungry by design — every file the agent reads, every retry, every verbose explanation costs you. A single bad afternoon with a confused agent can cost more than a month of flat subscription.

Hybrid models (base subscription plus metered overage) try to split the difference and mostly succeed at being confusing. Read the overage terms before you commit.

The practical rule: if you use the agent daily and heavily, flat or hybrid usually wins. If you use it a few times a week for well-scoped tasks, usage-based is cheaper. And whatever the model, watch token efficiency — an agent that solves your task in one careful pass beats a cheaper-per-token agent that flails for ten rounds.

How to Actually Decide: Match the Tool to Your Leverage

Here is the framework I promised. Forget feature matrices; ask yourself where your bottleneck is.

Your bottleneck is understanding complex code. You inherited a codebase, or you are debugging across service boundaries, or you are doing refactors where a wrong move breaks everything. You need reasoning depth. Lean toward Claude Code. The token bill is the price of not breaking production.

Your bottleneck is typing speed and flow. You know what to build; you just want to build it faster, with fewer interruptions. You need inline assistance. Lean toward Cursor. It disappears into your workflow, which is the highest compliment a tool can earn.

Your bottleneck is task volume. You have twenty small migrations, a backlog of test coverage, five services that need the same dependency bump. You need parallelism. Lean toward Codex. But invest in task specs — parallel agents with vague instructions produce parallel messes.

Your bottleneck is compliance and procurement. You are not choosing for yourself. You need enterprise packaging. That is Copilot, and the comparison is not really about the tool.

Your bottleneck is cost control. You want AI help but you watch every dollar, or you want to choose your own models. You need transparency. Look at Cline or Aider with your own API keys.

Most developers are actually a mix of two of these. A common and effective stack in 2026 is a daily-driver editor assistant (Cursor or Copilot) plus one deep agent (Claude Code) for the hard tasks. Two subscriptions sounds extravagant until you compare it to one hour of wasted senior-engineer time per week.

The Mistakes That Make Any Agent "Not Worth It"

The tool is rarely the real problem. These are the failure modes I see most:

1. Vague delegation. "Fix the bug" or "add the feature" without context produces expensive, wrong output. The developers getting the most value write specs: what done looks like, what not to touch, how to verify. Ten minutes of spec writing routinely saves an hour of agent flailing — and the token bill that comes with it.

2. No verification loop. Agents are confident and occasionally wrong with total conviction. If you are not running tests, reading diffs, or both, you are not using an agent — you are generating future debugging work. The cheapest agent run is the one you verify.

3. Letting context bloat. Every file the agent reads costs tokens and, worse, attention. Point agents at the relevant files. A tight context beats a clever prompt every time — this is the single highest-leverage habit in AI-assisted development.

4. Paying for autonomy you don't use. If you only ever accept inline suggestions, you do not need the most autonomous (and most expensive) agent on the market. Match the tool's strength to what you actually do, not what the marketing made you imagine doing.

5. Ignoring the meter. Check your usage dashboard weekly for the first month with any new tool. Most "this is too expensive" stories are really "I had no idea the agent was doing that" stories.

The 2026 Reality Check

A few things that are true now and were not two years ago:

First, the models matter less than the harness. The gap between frontier models on raw coding benchmarks keeps shrinking, while the gap between good and bad agent harnesses — context management, tool design, retry logic — keeps growing. When choosing, evaluate the product, not just the model badge.

Second, skills changed the game. Reusable agent skills — versioned, shareable workflow files that teach agents your team's practices — turned agents from clever interns into institutional knowledge carriers. A mediocre agent with great skills often outperforms a frontier agent with none. If your chosen tool supports skills, invest there before upgrading tiers.

Third, cost is a feature now. The teams getting the best ROI treat token budgets like any other engineering budget: measured, allocated, reviewed. The ones getting burned treat AI like electricity — invisible until the bill arrives.

The Verdict

So, which AI coding agent is actually worth paying for in 2026?

Best all-around value for serious developers: Claude Code, if your work includes hard problems. The reasoning depth justifies the usage bill where it matters.
Best daily driver: Cursor, if you live in your editor and want AI in your flow rather than beside it.
Best for teams with compliance needs: GitHub Copilot, and it is not close.
Best for parallel throughput: Codex, provided you spec tasks well.
Best for cost control and transparency: Cline or Aider with your own keys.

And the meta-answer: the developers getting 10x value are not the ones with the most expensive tool. They are the ones with tight specs, verification loops, managed context, and a measured token budget. The agent is leverage. Leverage multiplies whatever you bring to it — including your sloppiness.

Pick the tool that matches your bottleneck, watch the meter for a month, and invest in skills before subscriptions. That is what "worth paying for" actually looks like.

What is your current setup? I am curious which agent earned its keep in your workflow — and which one you cancelled. The comments are open.

bayu writes about the creator economy and builds small tools on the side — including a Japanese vocabulary quiz at bayu.id.