Then I looked more carefully at what I was actually producing.

The Good Part Is Real

I want to be honest about this part, because the rest of this article will not make sense without it.

AI genuinely changed the pace of my work. Scaffolding a new feature used to take time — now it takes minutes. Boilerplate code is mostly gone, and when I hit an error, I get an explanation immediately instead of spending twenty minutes reading documentation I half-understand.

The speed is not hype. If you use these tools every day, you feel it.

And that is exactly where the problem starts.

How I Actually Used to Work

Before AI, I was a "paint on canvas" developer. I didn't fully plan features before writing them. I liked to throw something quick and dirty at the wall to get a base layer down, something that roughly worked, and let the shape of the feature emerge as I went. Messy, hacked together, but complete. Once the whole thing was working end to end, I'd step back.

Now I had full context and I could see exactly how the feature fit into the app, what was redundant, what needed cleaning up. That's when I'd refactor.

That allowed me to be fast, because I wasn’t overthinking the feature: get it working first, then refactor it all. Simple.

The messy first pass wasn't a problem to fix, it was the method. Explore fast, understand fully, then clean. That two-stage process was doing most of the real work, and I didn't even realize it until AI quietly erased half of it.

Then AI Broke the Loop

Here's what I didn't expect: AI didn't improve that process. It disrupted the part that made it work.

The first stage, fast and dirty exploration, got even faster with AI, and that part felt great. But the second stage quietly disappeared, and the reason is sneakier than you'd think. AI-generated code looks clean. It's formatted, it's structured, it doesn't scream "this needs another pass."

So I stopped doing the refactor… not consciously, there was no moment where I decided to skip it. The code just looked finished, so my brain treated it as finished.

The problem is that looking clean and being well-thought-through are not the same thing. The messy draft is supposed to be a phase. AI turned it into the final product.

The Prompt Loop Trap

Here is a scenario most developers will recognize.

You have a problem. You write a prompt. The output is almost right, but not quite, so you prompt again with a small correction. Still off. You try a different angle, add more context, rephrase. Fifteen minutes later, you are still working on a problem you could have solved in two minutes if you had just opened the file and fixed it yourself.

At some point, you are no longer solving the problem, you are negotiating with the model. This happens because prompting feels like progress. Every response is something, you are moving. But sometimes the fastest path is to stop prompting, close the chat, and just think.

AI was faster, until I used it to avoid thinking and became lazy. Then it was just slower in disguise.

The Hidden Cost: Thinking Less

This is the part that is hard to see while it is happening.

I started reviewing AI output the same way I skim a news article: looking for obvious problems, checking that it roughly matched what I asked for, then moving on. What I stopped doing was asking harder questions. Not "does it work?" but "is this actually right?"

The code was not obviously bad. It worked, tests passed. But "works right now" is not the same as “clean and maintainable”. I was accepting outputs I would have pushed back on before, because the output was good enough and moving on was easy. Standards do not drop all at once, they slip one small acceptance at a time.

AI Didn't Skip Steps. I Did.

The development process has not changed. You still need to understand the problem before you build, think about the architecture before you write code, refactor the output into clean and maintainable code, and review it all carefully before you ship.

AI does not skip those steps, it only does what you ask, making it way too easy to get complacent. No friction, no obvious cost. The cost shows up later, when something breaks in a way you do not understand, or when you have to modify code you never actually knew.

The Fix Is Not a Tool

When I recognized what was happening, my first instinct was to find a better workflow: a smarter way to prompt, a tool that would catch what I was missing. That was the wrong instinct.

The problem was not the tool. The problem was that I had let the tool collapse a two-stage process into one, without noticing. The fix had to happen at the same level. Not a new tool, but a clearer mental model for how to work.

A few things that actually helped:

I kept the two stages explicit. Fast and dirty with AI is still fine, but I now treat that output the same way I used to treat my own messy first pass. It's a base layer, not a finished product.

I still do the refactor pass. Once the feature is working end to end, I step back and ask: now that I can see the whole thing, what would I actually do differently? That question used to come naturally. Now I have to be deliberate about it. I’ll tell Claude or Codex exactly how I want things to be refactored until I’m satisfied.

When I find myself reprompting the same thing more than twice, I stop. That is a signal that I need to think, not prompt. Sometimes, clearing the context and starting fresh also helps.

When I already know the answer, I just write the code. Not everything needs AI. Knowing when not to reach for the tool is as important as knowing how to use it.

The Real Skill

The developers I see getting the most out of AI are not the ones with the best prompts: they are the ones who know what their process actually is and protect the parts that matter.

For me, the first pass was never where the real work happened. The value was in the second pass, when I had full context and could see clearly. AI made me think I could skip it, but really, I couldn't.

Tools will change and the specific model you use today will look different in a year, but knowing which stages of your process are doing the real work, and refusing to let a tool quietly erase them, that is the skill that does not get replaced. It gets more important.

AI made me faster. It also made me worse, for a while. The difference between those two outcomes was not the tool. It was whether I still did the second pass.

Last week, I wrote maybe 10 lines myself, and I shipped more than I usually do.

It’s not a flex, you’re probably doing the same thing. But it took me a while to get comfortable with it because writing was always the part that felt like real work to me.

Something has shifted though, and I think a lot of experienced developers are feeling it without quite knowing what to do with it.

The Role Has Changed.

There is a version of this conversation that goes: "AI writes code now, so developers are done." That is not what I am seeing.

What I am actually seeing is that the work itself has moved.

For a long time, writing software was the hard part. That is why you spent years getting good at your language, your stack, your mental models. Execution was where most of the effort went. That is no longer true.

And when execution stops being the constraint, everything that used to wait behind it becomes visible. Understanding the actual problem. Defining what the system should look like before a line gets written. Knowing which shortcuts will cost you six months from now. That stuff does not get easier just because the code writes itself. If anything, it matters more.

The job did not disappear. It just sits at a different point in the process now.

My days look different because of it. Less time writing, more time managing what AI produces. It feels less like craftsmanship and more like technical direction. And the catch with that is: a fast, capable system that makes mistakes in subtle ways requires more attention, not less. You still have to know enough to catch what it gets wrong.

What I Actually Do Now

Before I touch any AI tool, I think through what I am building. Not at the line level, but at the system level.

• What are the components?
• How does data move between them?
• What are the constraints?
• What should this thing never do?

This is the part that AI cannot do for you. Not because the models are not capable, but because the answers live in your head and in the business context around the project.

Then, I ask Claude to generate an implementation plan for the feature. I will review that part thoroughly, before asking for a list of TDD-style tests to be generated before any code gets written.

Starting with that allows me to define what “done” looks like for the current feature.

If you skip these steps, you end up reviewing code against a vague idea of what you wanted. That is where AI slop comes from, not from bad models, but from unclear input.

Once I’ve reviewed the tests, the implementation work can start. I’ll usually try to do it step by step, with smaller chunks of the feature that I can review as I go.

This matters more than people realize. When you let AI generate a large chunk at once, reviewing it becomes overwhelming. You end up skimming and you end up missing things. Breaking it down forces both the AI and you to think in sequence, and it keeps each review focused enough to actually catch problems.

Then a second AI reviews the output, then I review it myself one more time.

There is also something worth saying about the speed. I will be honest: there is something genuinely satisfying about watching an idea become working software faster than it used to.

Getting to the built thing faster just means more time for the parts that actually require a human.

What You Still Have to Bring

That last review step is where experience earns its place.

I am not only checking syntax. I am also asking whether this approach makes sense for the business and whether we are solving the right problem at all.

This is where AI has a specific blind spot worth understanding. It is very good at producing code that looks functional. Tests pass. The feature works. But "works right now" and "holds up over time" are different things. AI does not naturally think about what happens when requirements shift, when the codebase grows, or when another developer has to modify this six months from now. It optimizes for the output in front of it, not for the system around it. That gap is exactly where experienced judgment lives.

A junior developer might see the same output and think it looks fine, because it does look fine. What they cannot always see yet is how it will behave when something changes around it. That judgment is not something you can prompt your way into. It comes from having seen enough things break.

If you are earlier in your career, this is not a reason to panic, but it is a reason to be intentional. The repetitive work that used to teach you how things connect is being automated, which means you have to find other ways to build that understanding deliberately. The good news is that learning has also gotten easier. You can take a well-known open source project, something like Rails or Linux, and ask AI to walk you through how a specific part works. When you do, push further than the answer. Ask why it was built that way, not just how it works. That habit is what separates developers who are actually learning from the ones who are just collecting answers.

The developers who will grow in this environment are the ones who use AI to understand systems faster, not to avoid understanding them at all.

What This Means

I did not stop being an engineer.

I stopped being a typist.

The craft is still there. It just looks different now. Less time at the keyboard, more time thinking about systems. Less writing, more reviewing. Less implementation, more direction.

If anything, the parts of the job I find most interesting, the architecture decisions, the problem framing, the moments where you push back and say "I think we are solving the wrong problem", those parts have more space now.

The 10 lines I wrote last week? Those were the lines that actually needed a human.

I personally spend much less time writing code these days. Most of my time is spent managing AI agents and reviewing their work, almost like working with a team of engineers.

That shift matters more than the “AI will replace developers” debate, because writing code was never the most important part of the job.

The real value was always somewhere else: understanding the problem, thinking through the architecture, and translating messy requirements into something that actually works.

And that part hasn’t gone away.

But engineers who refuse to adapt probably will, and junior developers who rely entirely on AI without understanding what they’re building won’t last very long either.

There is a right way to use AI in 2026 if you want to stay productive, and a very wrong way.

Let’s dive in.

What Everyone Is Actually Arguing About

When people say "AI will replace developers" they usually mean one of three different things.

They either mean that junior roles will disappear, the whole profession is going away, or that AI will make engineers so efficient that companies will simply need fewer of them.

These are three completely different claims, and most of the debate online mixes all of them together. So before we go anywhere, let's be honest about what's real.

Yes, AI can write code. Good code, sometimes. It can scaffold a feature, write tests, handle boilerplate, and explain an error faster than any Stack Overflow thread. That part is not hype. If you've used these tools daily, you know they genuinely change the pace of work.

But here's the part that gets left out of the conversation.

Very few layoffs in recent years were actually tied to direct AI automation. Most were companies correcting for overhiring during the boom years between 2020 and 2022. Saying "we're going AI-first" is a better headline than "we hired 30 engineers when we only needed 10." Same layoffs. Better story.

AI didn't kill the job market. The job market corrected itself, and AI got the credit or the blame, depending on where you sit.

But that still doesn't answer the deeper question. Even if developers aren't being replaced right now, what about the work itself? Is the job changing in ways that matter?

Yes. And this is where it gets interesting.

AI Fixes the Code, Not the Problem

A while back, I ran into a bug in the staging environment of an app I help maintain, and it stuck with me. Not because it was complicated, but because of how simple the real fix turned out to be and how AI completely missed it.

You see, in that app, we have a job scheduled to run daily. Its job is straightforward: check documents and expire the ones that have passed their expiration date.

But at some point, we disabled it: development had been paused, costs needed to be cut, and staging wasn’t really needed for a while. It stayed off for about four months.

When we turned staging back on, something was wrong. Many users were showing incorrect expiration states. The data looked off and I wasn’t sure why.

So I asked Codex, which looked at the code, analyzed the logic, and started suggesting fixes:

• Change this condition
• Adjust that check
• Add this validation

The suggestions looked reasonable, but really, the code was completely fine.

The real problem was that the scheduled job only looked back four days when checking for expired documents. After four months of not running, there was a massive gap. The fix wasn't a code change at all. It was just running a script to backfill the last four months of missed processing. There was no need to change any code, since there was no bug.

AI never got there… It kept staring at the code because that's all it can see. You could argue that if Codex had full access to that Heroku account, it would have likely seen that the scheduled job was missing, but giving full access to infrastructure to any AI is still something where I draw the line.

At the end of the day, the problem wasn’t in the code. It was based on a human decision dictated by business needs.

The Knowledge AI Cannot Access

This is worth sitting with for a moment.

Good engineers carry context that isn't written anywhere. They remember the cost-cutting decision from last quarter. They know why a certain table is structured the way it is, even though the original developer left two years ago. They know which parts of the system are fragile and why. It's not because it's documented, but because they were there when it broke.

AI works from what it can see: the code, the error, the prompt you gave it. It has no access to the meeting that never got written down. It can't ask the right question because it doesn't know the right question exists.

This gap doesn't disappear just because models get better. Even a much smarter AI still only knows what it's been told. The institutional memory of a system lives in the people who built and maintained it. That's not a limitation of today's tools.

That's a structural reality.

Translation Is Still a Human Job

Here's the other side of this.

Clients can use AI to build apps now. That's real. You can describe what you want, generate something functional, and ship it without writing a single line of code yourself. The tools exist. People are doing it.

But most clients still hire engineers. And the reason isn't that they can't use AI themselves. It's the same reason most people still call a plumber even though they could theoretically fix a leaky pipe themselves.

They don't want to think about it or deal with it. After all, they don't know what they don't know, and when something goes wrong in a way they didn't expect, they don't know where to start to fix it.

Software is the same. A client can prompt an AI to build an app, but they often can't communicate exactly what they want. They describe the surface, not the system. They say "I want users to be able to track their orders" without knowing that this single feature touches authentication, database design, notification logic, and mobile layout. Getting from "here's what I want" to "here's what you actually need" is a translation job. It requires someone who understands both the business and the technology well enough to bridge them.

That's why business analysts still exist. That's why good engineers ask questions before they write code. The requirement-gathering process, figuring out what a system needs to do before deciding how to build it, is something AI cannot replace, because the client often doesn't know how to tell it what they need.

And there's one more piece to this. A good engineer doesn't just build what the client asks for. They push back when something doesn't make sense. They suggest a simpler approach. They flag a technical decision that sounds reasonable on paper but will create problems at scale. That judgment comes from experience and business understanding. It's not in the prompt.

AI is lazy. It will create features that work, but the code will often be messy, unmaintainable, or poorly structured unless you guide it properly.

What Actually Gets Displaced

Let's be honest here too, because the picture isn't all good news.

Some of what junior engineers used to do is genuinely getting automated. Repetitive boilerplate, simple helper functions, basic test generation, straightforward refactoring, and tons of UI work.

AI handles these faster and with less friction than a person would.

This means the learning path has changed. Before AI, juniors built experience by writing repetitive, simple code. That code taught them patterns, structure, and how things connect. Now AI writes that code instantly. What's left is understanding it, debugging it, and knowing when it's wrong.

That's harder to learn passively. And it's worth being honest that many juniors lose the repetitive practice that used to teach them how systems work. That's a real cost, but for the ones who push through it, it's actually a better foundation. The engineers who grow in this environment skip the surface-level work and go straight to the thinking.

The floor is rising.

What used to require a team of five can now be done by two people with the right tools. That creates real pressure at the entry level, but it also means engineers who develop genuine depth, who understand systems, not just syntax, will have more leverage than ever before.

The Question That Actually Matters

The engineers who will struggle in this environment are the ones who let AI do the thinking entirely. Who accept the first output, ship it, and move on without understanding what they built. They'll feel productive for a while, but when something breaks in a way AI can't diagnose like a cron job that's been off for four months, they won't know where to look.

The engineers who will thrive are the ones who ask the right questions before touching the code. What problem are we actually solving? Does this approach make sense for the business? What context am I missing?

I've seen this play out enough times to believe it. The value of a good engineer was never just in writing code quickly. It was in knowing which problem to solve, understanding the system well enough to ask the right question, and having enough business sense to know when the requirement itself is wrong.

AI didn't change that. It just made it more visible.

The Question Most Developers Skip

Most developers are asking: will I still have a job?

That's not the most useful question.

The better question is: what does good engineering look like when the repetitive work gets automated?

The answer has always been the same. Understand the business. Own the context. Ask why before asking how. Know enough about the system's history to recognize when the problem isn't in the code.

AI changed the pace of the work. It didn't change what the work is actually for.

The developers who bring business thinking, institutional memory, and the ability to translate between what clients say and what systems need, those developers aren't disappearing.

They're just harder to replace, which was always the goal.

Don’t want to be left behind?

If you want to build a real workflow around AI instead of just experimenting with tools, I’m working on a course that will be released in the coming weeks: The Developer’s AI Productivity Blueprint .

It contains everything I’ve learned over the past few months, starting all the way from the basics, to the role shift we’re seeing, as well as more advanced topics like multi-agent workflows.

Check out the course’s page for more details and join the waitlist. I’ll be selecting a few people that will get the course for free in exchange for feedback.

• Creating a small product
• Building an app
• Doing some freelancing to earn more

Something that doesn’t depend on the whims of your boss.

I was one of them, but as a developer, I wasn’t really sure how to get started.

I tried writing books first, before eventually switching to freelancing. At the time, it turned out to be a much better fit for me… but I didn’t know that beforehand.

So I thought it might be a good idea to compile everything I’ve learned about starting businesses as developers safely (i.e. without quitting your job), along with the patterns I’ve seen other developers follow.

That eventually turned into an ebook, Side Hustles For Developers.

What’s “Side Hustles For Developers”?

It’s the ebook I wish I had when I first got started… before spending a decade learning things the hard way.

And it’s free.

It’s a practical breakdown of the real ways developers build income outside their job, organized in a way that makes sense depending on where you are right now and what actually fits your style.

Inside you’ll find:

• How developers actually start side hustles without quitting their job
• Which paths work at different stages of your career
• How to avoid the traps that waste months of effort
• How to choose the right starting point based on your time and skills

The Side Hustle Ladder

The core of the ebook is a framework I call the Side Hustle Ladder.

The idea is simple. Not every hustle fits every person at every stage. Some take a weekend to start, while others take months of consistent work. Some need an audience, while others need nothing but a skill and a willingness to show up.

The Ladder helps you choose your next realistic step.

Not the dream scenario, but something you can actually start this week, based on your time, energy, and what you already know.

Here is a quick overview of the options we cover in the book:

Freelancing and Consulting (The Honest Version)

This is where most developers start, and trust me, it works.

But most developers who try freelancing either undercharge (I was one of them), take on the wrong clients, or burn out because they traded one boss for five.

Digital Products

Templates, tools, open-source projects with a paid tier, courses… These are the ones that sound passive, but honestly, nothing is ever truly passive.

And they’re certainly not at the start as they take real work to build and real effort to promote. What changes is the economics: you build once and sell many times, which is a very different model from billing by the hour or by the project.

Content Creation

Creating content such as tutorials, articles, videos, or podcasts can be an amazing way to build authority as a developer, and eventually turn that authority into real revenue.

My main concern with freelancing is that it doesn’t create much long-term leverage. Each project or hour you work generates revenue, and sometimes leads to more clients through recommendations. But it doesn’t really compound over time.

Content does.

Building a SaaS

Building a SaaS or small product means creating something that solves a clear problem for a clear audience, and I’m going to be honest.

While this has one of the lowest barriers to entry for developers, it’s also one of the hardest paths to break into. Most developers start building right away, only to realize later that there isn’t a real need for what they built, or that they have no idea where to find customers.

One Thing I Want to be Clear About

Not every side hustle is right for every person. We’re all different, and we all approach work in different ways, so it’s important to identify the kind of hustle that fits you and your lifestyle.

That’s why the ebook talks about tradeoffs, not just opportunities.

Because the goal is not to hustle harder. The goal is to build something that fits, and potentially can replace your full-time job (if you want it to), like it did for me.

Start Where You Are

The ebook is free. All of it.

If you are a developer who has been sitting on the idea of building something on the side, this is a good place to start. Not because it has all the answers, but because it will help you figure out the right next step for where you actually are right now.

Table of Contents

• Why Consider Moving Now?
• What We're Assuming About Your App
• Why DigitalOcean App Platform?
• Before You Touch Anything: The Migration Checklist
• Steps to Migrate from Heroku to DigitalOcean App Platform

On February 6, 2026, Heroku officially announced it is transitioning to a "sustaining engineering model." In plain English: no new features, just keeping the lights on. For developers who have relied on Heroku for years, this is a signal worth paying attention to.

For many Rails developers, that marks the end of an era. When Ruby on Rails was thriving, Heroku was the default. It meant you didn’t have to configure nginx on an Ubuntu server just to ship.

If you're still on Heroku, now is a good time to plan your exit before something forces your hand.

This guide walks you through migrating a standard Rails app from Heroku to DigitalOcean App Platform , a fully managed PaaS with a similar push-to-deploy workflow.

Why Consider Moving Now?

Before we get into the migration steps, here’s a quick comparison between Heroku and DigitalOcean App Platform as of early 2026:

Heroku still works. But pricing becomes harder to predict as you scale, especially with add-ons and bandwidth. DigitalOcean App Platform keeps things simpler and more predictable, which is why it’s a practical landing spot if you're planning a migration.

What We're Assuming About Your App

This guide is written for a typical Rails setup:

• Your code lives in a GitHub repository
• You're using PostgreSQL as your database (hosted on Heroku)
• You're using Sidekiq and Redis for background jobs
• You have scheduled Rake tasks running via Heroku Scheduler

Even if your stack is slightly different, most of this still applies.

Why DigitalOcean App Platform?

DigitalOcean is straightforward, well-documented, and affordable, a natural landing spot for developers leaving Heroku.

App Platform is DigitalOcean's managed PaaS, and it's the closest thing to a Heroku replacement you'll find. It uses the same Cloud Native Buildpacks as Heroku, so most apps migrate with little to no code changes. You get fully managed PostgreSQL, MySQL, Redis, and MongoDB built in, free internal service routing between components (no Private Spaces fees), SSL provisioning, and zero-downtime deploys out of the box. You connect your GitHub repo, push code, and it deploys.

No servers to manage, no DevOps overhead, just your app running.

Before You Touch Anything: The Migration Checklist

Before setting up your new server, collect everything you need from Heroku and prepare the migration. Do this while your app is still running. For production apps, enable maintenance mode before exporting the database so no new data is written during the backup.

Most migrations run both platforms in parallel, then cut over at the DNS level once everything is confirmed stable. That's exactly the approach this guide follows, so downtime is minimal to zero.

On Heroku’s side:

• Export all config vars: heroku config -a your-app-name
• Dump your database: heroku pg:backups:capture && heroku pg:backups:download
• Note your custom domain (if any)
• Note all Heroku Scheduler tasks (command + schedule)

Steps to Migrate from Heroku to DigitalOcean App Platform

1. Create an App on DigitalOcean App Platform

   Get started with DigitalOcean here .

   Once you’re in, go to App Platform and create a new app. Connect your GitHub repository and choose the branch you want to deploy.

   

   App Platform will detect your Procfile automatically and set the run command to bundle exec puma -C config/puma.rb. Leave the build command empty.

   

2. Add a Managed PostgreSQL Database

   In the same setup flow, go to the Add a Database tab, add a PostgreSQL database, and create an app.

   

   Heads up: After adding the database, DO will show an environment variable reference like ${your-db-name.DATABASE_URL}. This looks like it should work automatically, but in practice, you’ll want to replace it with the actual connection string so Rails and Sidekiq receive a proper DATABASE_URL. We'll do that in the next step.

3. Add a Managed Valkey Instance

   Add a second database and choose Valkey, DigitalOcean's Redis-compatible service. Your app and Sidekiq won't notice the difference.

   

   

4. Set Environment Variables

   This is the step that trips people up.

   Go to Settings → Environment Variables. You'll see DATABASE_URL and REDIS_URL (If you set one) set to reference values like ${your-db.DATABASE_URL}. Replace both with the actual connection strings.

   To get the connection strings:

   • PostgreSQL: Go to your database → Connection Details → copy the Connection String
   • Valkey: Same thing, go to your Valkey instance → Connection Details → copy the connection string

   

   Then add the rest of your environment variables from Heroku (RAILS_MASTER_KEY, any API keys, etc.).

   

5. Restore Your Database

   Before you deploy, restore your data. If you deploy first, your app will 500 on every request until the database is ready. Run this from your local machine using the connection details from your new PostgreSQL database:

   PGPASSWORD=your_password pg_restore \\
     -U doadmin \\
     -h your-db-host.db.ondigitalocean.com \\
     -p 25060 \\
     -d defaultdb \\
     latest.dump
   

   

   If you're starting fresh with no existing data, skip this and just run migrations after deploying instead.

6. Deploy

   Deploy your app. Once it's live, if you skipped the restore above, open the web console and run:

   rails db:migrate
   

   

7. Add Sidekiq as a Worker Component

   Sidekiq needs to run as a separate component so it has its own process and can be scaled or restarted independently from your web server. In DO App Platform, go to your app and create a new worker component:

   • Resource type: Worker
   • Run command: bundle exec sidekiq
   • Environment variables: Make sure DATABASE_URL and REDIS_URL are set here too. The worker needs both

   

   

   Deploy the worker. Check the runtime logs, you should see Sidekiq boot up and connect to Valkey.

   

   Note: Running a separate worker component means paying for an additional instance. For low-traffic apps, you can start without it and add the worker only when you have actual background jobs that need processing.

8. Recreate Your CRON Jobs

   DigitalOcean App Platform handles scheduled tasks as Job components, configured the same way as the worker above but with a schedule attached. Follow the official guide here:

   https://docs.digitalocean.com/products/app-platform/how-to/manage-jobs/

9. Point Your Domain to DigitalOcean

   

   Once your app is deployed, you can connect your custom domain.

   In App Platform, go to Settings → Domains and click Add domain.

   DigitalOcean will show you the DNS record you need to configure. Add that record at your DNS provider (or inside DigitalOcean DNS if you’re using it).

   After DNS propagates, App Platform will automatically provision SSL for your domain .

   If you want the full step-by-step walkthrough, DigitalOcean has an official guide here .

You're Live

Once everything is running, confirm traffic is flowing to DigitalOcean and monitor the app for any unexpected issues.

You can run both environments in parallel for a day to be safe. When you're confident everything is stable, remove the Heroku app.

Heroku isn't going away tomorrow, but it's no longer moving forward either. DigitalOcean App Platform gives you the same push-to-deploy simplicity with a platform that's still actively growing.

Get started on DigitalOcean with $200 credit today.

That may sound obvious. But when you watch something go viral, when the momentum builds and investors start paying attention, there is an invisible force that pulls you toward the default script: raise money, hire a team, scale fast.

Most people follow it without asking if they actually want to.

Peter Steinberger didn't. And the story of how he built OpenClaw and what he chose to do with it is a good lens for thinking about what it means to build something on your own terms.

What is OpenClaw?

OpenClaw is a local AI framework. You install it directly on your machine, and if you let it, it has system-level access to do anything on your computer.

By itself, it is just a shell. The creator jokes it is like a "space lobster harness", nothing happens until you plug in a brain. But once you connect it to a powerful LLM like Claude Opus 4.6 or GPT-5.3 Codex, it becomes something that can genuinely act. Not just answer questions, but do things. That is the official slogan: "the AI that actually does things."

You can talk to it through WhatsApp, Telegram, or any chat app you already use. It can connect to your browser, translate an audio file you send from your phone, and remind you to buy milk at 2PM. That last feature runs on something called Heartbeat which is basically just a clever cron job but it lets OpenClaw reach out to you, instead of waiting for you to ask.

There is also a soul.md file. That is where you give it a real personality and values. The creator calls it the soul.

But here is the thing about a tool with full system access and a proactive heartbeat: the security concerns are massive. When a bot gets this level of permission, it becomes a real risk.

And the plugins that extend OpenClaw's power? You can never be totally sure what they contain. To address this, Peter partnered with VirusTotal so that every skill is automatically scanned for bad code. It is not a perfect fix, but it is a serious attempt.

The Naming Drama (And What It Reveals)

OpenClaw did not start as OpenClaw.

After some early prototype names, Peter landed on "Clawdbot" (spelled with a W), like a lobster claw. He thought it was clever. He owned the domain. It felt right.

Anthropic, the company behind Claude (spelled with a U), did not think so. An employee sent him a friendly but urgent message: change it before the lawyers get involved. There was no lawsuit. But the message was clear.

Under sleep deprivation and stress, he panic-renamed it to MoltBot because he already owned those domains and needed a fast solution. He hated it immediately. His exact words: "the mold's not growing on me."

After sleeping on it, he came up with OpenClaw. And just to be safe, he actually called Sam Altman at OpenAI to confirm the name was okay to use before committing to it.

That detail matters. It is not just a funny anecdote. It shows someone who moves fast and figures things out under pressure but also someone who does the unglamorous work of getting it right, even when no one would notice if he skipped it.

The Part That Surprised Me

When something goes this viral, the expected move is a funding round.

OpenClaw had everything lined up for it. A strong technical foundation. A lot of buzz. A clear use case. The kind of momentum that usually ends in a hiring spree.

But Peter had already run a software company called PSPDFKit for 13 years. He knew what that path looked like, and not just the technical part but the people part. Managing employees, handling conflicts, navigating high-stress customers. That is what burned him out. And he is already financially comfortable, so making more money is not his main goal.

He also saw a conflict of interest. If OpenClaw became a SaaS startup, every cool community-built feature would become a temptation to lock behind an enterprise paywall. He did not want that pressure shaping his decisions. He believes OpenClaw should stay free.

So instead of starting another company, he joined OpenAI.

His reasoning was direct: "What I want is to change the world, not build a large company, and teaming up with OpenAI is the fastest way to bring this to everyone." OpenAI gave him access to their latest tools and massive computing power. Sam Altman announced that Peter would "drive the next generation of personal agents" at OpenAI.

His one condition: OpenClaw stays open-source forever, similar to how Google treats Chrome. OpenAI agreed. The project will live on in a foundation.

Why This Is Worth Thinking About

I will be honest: when I first read this, it felt strange.

If you build something valuable, aren't you supposed to scale it?

But the more I sat with it, the more I understood.

There is a shift that happens when something you built starts to grow. In the beginning, it is just you and the work, like writing code, shipping fast, and making decisions directly. It feels creative. It feels like building.

Then, if it works, things change. You hire. You manage. You sit in more meetings than you expected. Eventually, you are not building the thing anymore. You are running the thing.

Some people love that transition. Others realize they actually just want to keep building. That is a hard thing to admit in a culture that treats scale as the only real measure of success.

I have moved between freelancing, leading teams, running parts of companies, and building again. When I was in a Director of Engineering role, my days looked very different from when I was freelancing or writing books. Not worse just different. More coordination, more responsibility, less time in the codebase.

When I look at someone who ran a company for 13 years and chose not to spin up another one, I do not see a missed opportunity. I see clarity.

Growth Is Not Always the Goal

There is a quiet assumption in tech that if something works, you should maximize it. Staying small is often framed as lacking ambition.

But sometimes staying intentionally small is a strategic choice.

Growth changes the nature of the work. Once you raise money, you are no longer optimizing for what you find interesting. You are optimizing for revenue, retention, and returns.

That is not evil, that’s just how it works. The question is whether that is the deal you want.

The AI shift makes this question more interesting than it used to be. One developer with the right tools can now do what used to require a small team. If you can build meaningful things without hiring aggressively, you do not automatically need to scale headcount to scale your output.

Personally, I do not want a 50-person team and layers of management. I want something tight. Solid. Work that still feels like building. A small group of smart people who can achieve almost anything.

That does not mean avoiding impact, it just means choosing the shape of the impact.

What OpenClaw Actually Teaches Us

OpenClaw could have become a startup. Maybe a unicorn. Maybe it will still evolve in ways none of us expect, but what stood out to me was not the technology. It was the restraint.

Instead of following the predictable path, Peter asked a different question: what kind of work do I actually want to be doing?

That is the question most builders skip. Momentum is powerful, traction is addictive, and it’s easy to drift into growth because it feels like the responsible next step.

But that changes the job:

• You go from building to managing.
• From designing systems to designing org charts.
• From solving problems to absorbing them.

Some people want that. They thrive on it.

I don’t.

I don’t want a giant company. I don’t want layers of management and constant operational weight. I want something tight. Small. A strong group of smart people building fun things deliberately.

That is not playing small. It is choosing the shape of the work.

OpenClaw is interesting because its creator made that choice consciously. He didn’t drift into scale. He decided what kind of work he wanted to keep doing.

Most builders never stop to ask that question, they just follow the script.

Welcome to the developer identity crisis of 2026.

Something strange is happening in software engineering. The community is splitting into two camps. On one side, developers are ditching AI tools entirely, going back to writing every line by hand. On the other side, programmers are doubling down on AI, treating code as an "implementation detail" they rarely touch anymore.

This isn't just personal preference. Research published in January 2026 by Anthropic reveals the uncomfortable truth: how you use AI determines whether you're getting better or worse at programming.

The Return to Manual Coding

Let's start with the rebels, developers who tried AI coding assistants, then turned them off.

They're not technophobes. They just noticed something was wrong.

The Comprehension Debt Trap

You've heard of technical debt. But AI introduces a new kind: comprehension debt.

Comprehension debt is when code gets written without you actually thinking through it. AI writes it in 60 seconds. You glance at it, see it works, and move on. Then two weeks later, there's a bug. Now you owe interest on that debt, except the interest is paid in confusion.

You're debugging code you never understood in the first place.

GitClear analyzed 211 million lines of code written between 2020 and 2024 . The results are alarming.

Code churn nearly doubled. Code that gets revised within two weeks jumped from 3.1% (2020) to 5.7% (2024). That's code written so poorly it had to be rewritten almost immediately.

Code reuse collapsed. Refactored code dropped from 24.1% to 9.5%. Copy/pasted code shot up from 8.3% to 12.3%. 2024 was the first year copy/pasted code exceeded refactored code.

Duplicate code exploded. Duplicated code blocks increased eightfold in 2024. Research shows 57.1% of bugs involving duplicated code happen because someone forgot to update all the copies.

Why? As GitClear put it: "AI assistants tend to give suggestions for added code, but never suggestions for updating, moving, or deleting code."

The 9-to-1 Curse

Developer Steve Jones coined a term for this: The 9-to-1 Curse . AI saves you 1 unit of time writing code but costs you 9 units reviewing, debugging, and maintaining it later.

You feel productive shipping features. But three months later, drowning in bug reports and technical debt, you realize the trade wasn't worth it.

There's also a psychological cost. AI kills flow state. Every two minutes you're context switching between writing prompts, reviewing output, tweaking, testing. You're not creating anymore. You're managing a conversation with a bot.

Some developers describe it as going from "creator" to "homework checker."

The AI-First Architects

But some developers went the opposite direction. They restructured their entire workflow around AI.

These developers aren't trying to write code anymore. They're trying to orchestrate it.

Spec-Driven Development

Traditional workflow: Think → Code → Test → Debug → Ship

New workflow: Think → Spec → AI Generates Code → AI Writes Tests → Review → Ship

This is Spec-Driven Development. You write detailed specifications like what the function should do, edge cases, error handling, performance requirements. Then you hand that spec to Claude or GPT. The AI generates the code and writes the tests. You review both and ship.

If something's wrong, you don't debug the code. You fix the spec and regenerate everything.

Programming Languages as Walls

Developers in this camp argue programming languages are just friction. You have an idea, but to make it real, you have to translate it into Python or JavaScript. Remember syntax. Handle boilerplate. Write the same patterns over and over.

AI tears down that wall.

Stack Overflow's 2025 survey shows 84% of developers now are using or planning to use AI . The data shows AI excels at specific tasks: boilerplate code, unit tests, API documentation, scaffolding new projects. Why not let AI handle that and spend your brain on system design?

This is the "10x engineer" redefined, someone who ships 10x more by leveraging AI effectively.

This works great for prototyping, repetitive work, and exploring new frameworks. It works less well for complex novel problems, performance-critical code, and security-sensitive code.

What Science Actually Says

So who's right?

In January 2026, Anthropic published a study with actual data .

The Experiment

Researchers recruited 52 software engineers. All used Python regularly. None knew Trio, a Python library for asynchronous programming.

Split into two groups:

1. Control: Learn Trio manually, no AI
2. AI group: Learn with AI assistance available

After completing coding tasks, everyone took a quiz with no AI allowed. The quiz tested debugging, code reading, code writing, and conceptual understanding.

The Results

The AI group scored 17% lower on the quiz. Nearly two letter grades worse. Control group averaged above 60%, reaching 67%. AI group averaged below 60%, some dropping to 45%.

And the kicker: The AI group wasn't significantly faster. Maybe 2 minutes quicker. Not statistically significant.

They learned less and didn't even save time.

Why This Happens

When you solve a problem yourself, your brain builds neural pathways. You understand why the solution works.

When AI solves it for you, those pathways don't form. You get the answer, but not the understanding.

Think of it like an exam. Closed-book (no AI) vs. open-book (with AI). When the test is over, the closed-book group remembers more.

The study validates what manual purists feared: blind delegation destroys skill acquisition, especially for junior developers.

But Some AI Users Didn't Fail

Not everyone in the AI group scored poorly. The researchers identified six interaction patterns.

Low scorers (<40%):

• AI Delegation: Asked AI to write all code, never tried themselves
• Progressive Reliance: Started manual but increasingly offloaded thinking to AI

High scorers (>60%):

• Generate then Ask: Generated code, then asked follow-up questions to understand it
• Hybrid Queries: Asked for both code and explanations
• Conceptual Questions: Used AI like a tutor. Asking "Why does this work?" not "Write this for me".

Low scorers used AI as a generator. High scorers used AI as a tutor.

The Middle Path: Active Learning

You can use AI without losing skills. But you have to be intentional:

1. Try solving it yourself first. That struggle is where learning happens.
2. Use AI for research, not replacement. Ask "How does this work?" not "Write this for me."
3. Review generated code line by line. Read it. Understand it. Modify it yourself.
4. Ask AI to explain. "Why did you write it this way?" is more valuable than "Write this."
5. Maintain ownership. You should explain every line in your codebase.

This is active learning, using AI to accelerate your understanding, not replace it.

What This Means in Practice

Junior Developers

The Anthropic study shows AI during skill acquisition is harmful. You're building your foundation. If AI does the thinking, you won't develop debugging and comprehension skills.

Better approach: Code manually for 6-12 months. Use AI for explanations, not generation. Build muscle memory. Once you have a foundation, then leverage AI more.

Senior Developers

You already have deep understanding. You can use AI more freely because you spot when it's wrong.

This is where Spec-Driven Development makes sense. You know what good code looks like. You can write detailed specs and review AI output effectively.

But watch for skill decay. If you stop coding in a language, you get rusty.

Managing Teams

Code review becomes critical. If devs use AI heavily, reviews need to verify understanding, not just correctness.

Consider different guidelines for juniors vs. seniors. Maybe juniors have limited AI until they demonstrate mastery.

Google's DORA research (2025) describes AI as an amplifier. Adoption is widespread and productivity is up but AI magnifies whatever system it enters. Strong teams see gains in throughput and performance; weaker ones risk amplifying instability.

The Real Answer

Both camps have valid points.

Manual purists are right: Blind AI delegation causes comprehension debt, reduces code quality, and destroys skill formation.

AI architects are right: For experienced developers on the right problems, AI dramatically increases output.

The Anthropic study reveals the truth: how you use AI determines your outcome.

Use AI as a generator, something that does your thinking. You'll get faster short-term but weaker long-term. Comprehension debt compounds. Debugging skills atrophy. You become dependent on a tool that can't solve novel problems.

Use AI as a tutor, something that accelerates your thinking. You learn faster and maintain deep understanding. You explore, explain, verify. But you stay in the driver's seat.

What Actually Matters

The future isn't about speed. It's about deep understanding.

AI can't innovate. It pattern-matches. When you hit a truly novel problem like weird edge case, complex architecture, production performance bottleneck. AI won't save you. Understanding will.

We're entering a world where writing code is easy. AI does it in seconds.

The hard thing (the valuable thing) is understanding what the code should do. Why it works. When it's wrong. How it fits the larger system.

That's the skill worth protecting.

The question isn't "Should I use AI?" It's "How do I use AI without losing the ability to think?"

The answer: Stay actively engaged. Keep thinking. Don't outsource your understanding.

Use the tool. Don't let the tool use you.

Hallucinations?

So how does an AI hallucinate exactly? It's supposed to be logical since it's built on tangible data, right? Technically yes, but really, no. Modern LLMs are optimized to be helpful, not to be silent: they’re designed with an urge to answer.

When they don’t know the answer, they’ll still try to produce a plausible one anyway. That’s what we call a hallucination. It’s nothing more than an educated guess, which is often presented with a high-confidence level (this is all about probabilities, but that's another topic).

So to prevent them from being wrongly helpful, there's RAG: a technique to reduce hallucination.

RAG

What's RAG? RAG stands for Retrieval-Augmented Generation. In plain English: giving AI documents to read before it answers, instead of letting it guess from memory.

Think of it like an exam. Without RAG, AI is taking a closed-book test, relying purely on what it memorized during training. With RAG, it's an open-book exam. The AI gets to look up the answer in actual documents before responding.

Here's why this matters: every AI has a knowledge cutoff. Ask Gemini about events after January 2025, and you'll get "I don't have information about that." Ask Claude about your company's internal policies, and it has no clue because that data was never in its training set.

Now, look at this. Same Gemini. Same knowledge cutoff. But when we let it search Google first (which is basically RAG with the web as the knowledge base), it gets the right answer. That's the power of grounding.

RAG solves this by flipping the script. Instead of asking AI to remember everything, we give it the ability to look things up.

How RAG Actually Works

RAG isn't magic. It's a pipeline with four main stages, and understanding each one helps you see why it works.

Stage 1: Data Ingestion & Prep

Before anything happens, you need to prepare your knowledge base. This is where your PDFs, websites, databases, or API data come in.

But you can't just dump a 200-page PDF into an AI and call it a day. The AI needs that information in a format it can search through efficiently. This is where chunking and embedding come in.

Chunking means breaking down your documents into smaller pieces, usually around 300-500 words each. Why? Because if you feed the AI a massive wall of text, it gets overwhelmed. Smaller chunks are easier to match with user questions.

Embedding is where it gets interesting. Each chunk gets converted into a vector, which is basically a list of numbers that represents the meaning of that text. This isn't keyword matching. It's semantic understanding. A chunk about "resetting your password" and another about "forgot login credentials" will have similar vectors even though they use different words.

These vectors get stored in a Vector Database, a specialized storage system designed to find similar meanings fast. Think of a vector as a GPS coordinate for an idea. Words with similar meanings end up parked in the same neighborhood in the vector database.

Stage 2: Retrieval

Now a user asks a question: "How do I reset my password?"

The system doesn't search for exact keywords. Instead, it:

1. Converts the question into a vector (same embedding process)
2. Searches the Vector Database for chunks with similar vectors
3. Pulls out the top 3-5 most relevant chunks

This is semantic search. The AI finds content that means the same thing, not just content that uses the same words. So even if your documentation says "credential recovery" instead of "reset password," the system will still find it.

Stage 3: Prompt Augmentation

This is where RAG gets its name. The system takes those retrieved chunks and augments the prompt by injecting them into the conversation.

Instead of asking the AI:

"How do I reset my password?"

The actual prompt sent to the AI looks more like:

You are a helpful assistant.

Here are relevant documents:
---
[Chunk from user manual, page 12]
"To reset your password, navigate to Settings > Security >
Change Password. You will need to verify your identity via email."

[Chunk from FAQ]
"If you forgot your password, click 'Forgot Password' on the
login screen. A reset link will be sent to your registered email."
---

User question: "How do I reset my password?"

Answer ONLY based on the documents above. If the answer isn't
in the documents, say you don't have that information.

This is called grounding. You're literally grounding the AI's response in actual source material. No more guessing. No more hallucinations based on vague training data.

Stage 4: Response Generation

Finally, the LLM reads the augmented prompt and generates an answer. But this time, it's not pulling from its training data. It's pulling from the documents you gave it.

The output might look like:

"To reset your password, go to Settings > Security > Change Password. If you've forgotten it, use the 'Forgot Password' option on the login screen, and a reset link will be sent to your email."

The AI synthesizes the information into natural language, but the facts come from your documents. Some systems even add citations, telling you exactly which document or page the answer came from.

Why RAG Works Better Than Alternatives

You might be thinking: "Can't I just copy-paste my documents into the prompt?" Technically, yes. But there are better and worse ways to give AI context.

The key difference? Fine-tuning is like sending the AI to medical school, it learns how to speak and think like a doctor. RAG is like giving that doctor a specific patient's medical file, it provides the facts to apply those skills to.

And unlike fine-tuning, when your documentation updates, you don't need to retrain anything. Just update the Vector Database, and the AI immediately has access to the new information.

Real-World Use Cases

RAG isn't theoretical. It's already powering AI systems you probably use.

Customer Support: Companies like Intercom and Zendesk use RAG to build chatbots that answer questions by reading product manuals, FAQs, and troubleshooting guides. Instead of training a model on every possible question, they just point it at their documentation.

Enterprise Knowledge: Tools like Notion AI and Slack's AI search use RAG to help employees find information buried in wikis, meeting notes, and internal policies. The AI doesn't memorize your company's handbook; it searches through it in real-time.

Education: Platforms like Khan Academy's Khanmigo use RAG to answer student questions by referencing lecture materials and textbooks. The AI becomes a study assistant that actually knows what's in the course content.

Legal & Compliance: Legal tech companies like Harvey.ai and Casetext use RAG to search through contracts, case law, and regulations. Lawyers can ask questions in plain English, and the system surfaces relevant legal precedents.

The pattern is clear: RAG works best when you have a lot of documents and need accurate, source-backed answers.

What You Actually Need to Build RAG

If you're thinking about implementing RAG, the stack isn't complicated. You need four core components:

1. Vector Database – Where your embedded chunks live (Pinecone, Weaviate, Chroma)

2. Embedding Model – Converts text into vectors (OpenAI's text-embedding-3, or open-source like sentence-transformers)

3. LLM for Generation – The brain that writes answers (GPT-4, Claude, Gemini, or open models like Llama)

4. Orchestration Layer – Handles the pipeline (LangChain, LlamaIndex, or build your own)

That's it. The exact choices depend on whether you want managed services or self-hosted, and whether you need to run everything on-premise. But the components stay the same.

Common Pitfalls (And How to Avoid Them)

RAG sounds simple, but the devil's in the details. Here are the mistakes people make:

Problem 1: Chunk Size Is Off

Too large, and the AI gets confused by irrelevant information. Too small, and it lacks context to answer properly. The sweet spot is usually 300-500 words per chunk, with a bit of overlap so sentences don't get cut off mid-thought.

Problem 2: Retrieval Quality Sucks

You ask about "password reset," but the system pulls up chunks about "account deletion." This happens when:

• The embedding model isn't good enough
• Your chunks aren't semantically distinct

Solution: Use hybrid search (combine keyword matching with semantic search) and add a reranking step where a second model filters the results before sending them to the LLM.

Problem 3: Hallucinations Still Happen

RAG reduces hallucinations, but it doesn't eliminate them. The AI might still connect dots that aren't there or misinterpret retrieved chunks.

Solution: Aggressive prompt engineering. Say things like "Answer ONLY if the information is in the documents. If not, say 'I don't have that information.'" Better yet, force the model to cite sources so users can verify the answer themselves.

When NOT to Use RAG

RAG isn't a silver bullet. There are cases where it's overkill or just the wrong tool.

Skip RAG if:

• You have fewer than 10 documents → Just paste them into the prompt (prompt stuffing is fine here)
• You need creative generation (writing fiction, ads) → RAG constrains creativity by forcing the AI to stick to source material
• You're dealing with real-time data (stock prices, live sports scores) → Direct API calls are faster and more accurate

RAG shines when you have lots of static or slow-changing documents that you need to reference accurately. If your use case doesn't fit that pattern, you might be better off with a simpler approach.

The Future: RAG Is Just the Start

RAG is the baseline today, but the technology is evolving fast.

Agentic RAG: Instead of you deciding which documents to search, the AI decides. It can query multiple knowledge bases, APIs, and even the web, then synthesize everything into one answer.

Multimodal RAG: Right now, most RAG systems work with text. But the next generation will handle images, videos, and audio. Imagine asking "Show me diagrams about X" and the AI retrieves relevant charts from your PDFs.

Graph RAG: Instead of treating documents as isolated chunks, Graph RAG uses knowledge graphs to understand relationships. It knows that "John works at Company X" and "Company X makes Product Y," so when you ask about Product Y, it can pull in context about John too.

The core idea stays the same: give AI documents to read before it answers. But how we do that is getting smarter.

Getting Started

If you want to try RAG yourself, here's the easiest path:

1. Start with LangChain: They have pre-built templates and Jupyter notebooks you can run in minutes
2. Use Chroma for storage: It's free, runs locally, and requires zero setup
3. Test with 5-10 documents: Don't start with your entire company wiki. Start small, see what works, then scale

Resources:

• LangChain Q&A Tutorial: https://python.langchain.com/docs/use_cases/question_answering/
• Chroma Getting Started: https://docs.trychroma.com/getting-started

Conclusion

RAG isn't complicated. It's just "let the AI read before it answers." But making it work well requires attention to detail: good chunking, smart retrieval, and careful prompt engineering.

The payoff is worth it. Instead of an AI that guesses and hallucinates, you get one that references actual sources. Instead of a system that gets outdated the moment you deploy it, you get one that stays current as long as you update the documents.

For most real-world use cases where accuracy matters, RAG is the right answer. The question isn't "Should I use RAG?" It's "How do I implement it well?"

The use cases quickly became clear: analyze documents with PDF or Excel skills, create beautiful presentations using your brand guidelines, visualize data for stakeholder presentations, or follow your team's specific coding standards. Skills turn one-off instructions into reusable capabilities.

Recently, Vercel introduced  `skills` , a CLI for installing and managing skill packages for agents. Now you can browse  skills.sh  to see what's trending or check the top 10 on the leaderboard. Or head to  skillsmp , the agent skills marketplace, to find exactly what you need.

Today, we'll try out these skills and see how they perform in a real scenario. I'll use Claude Code as my agent, but you can follow along with any AI agent you prefer.

The skills we'll test are:

• api-design-principles  to create a simple API
• code-review-excellence  to review the result

This gives us a complete workflow: build something with best practices baked in, then get professional-level code review, all automated.

Install the Skills

I'll assume you already have your AI agent of choice installed and ready to go.

Use this command to install skills from Vercel along with the skills set from  `wshobson`  (thank you for these!):

npx skills add wshobson/agents

You'll be prompted to install the skills CLI if you don't have it yet. Then you'll see a list of available skills to install. Pick what we need: api-design-principles and code-review-excellence. Or go ahead and install all of them if you want to experiment later. Continue through the process as shown in the picture below.

The installation is quick. Just a few seconds and the skills are now ready to use. Behind the scenes, these skills are being added to your agent's context, giving it specialized knowledge it can reference automatically.

Try Out the Skills

I created an empty folder called foods-api, cd into it, and used claude to spin up Claude Code. You can do the same, just swap out that last command if you're using a different agent like codex or gemini cli.

I kept the prompt simple to see how well the skill guides the agent, but you can get way more sophisticated with this. The api-design-principles skill supports advanced patterns like Resource Collection Design, HATEOAS, versioning strategies, and more. Check out the full SKILL.md at  this link  to see everything available.

Here's my prompt:

Build food api using this skill /api-design-principles

Right away, the agent asks intelligent questions: which tech stack would I prefer, what database to use, and which resources to manage. This isn't just template generation, it's applying the skill's knowledge to understand requirements properly.

After submitting my configuration, I let Claude Code do its thing. You'll need to keep an eye on it since it will ask for permissions along the way. You can review each action before approving it, which is good practice.

It took about 3 minutes and 30 seconds to scaffold this complete API. Not bad for a production-ready foundation.

Examining the Results

After the agent finished cooking, I took a look at what we got. I have to say, it's pretty impressive. You get a well-structured project with systematic design principles baked in from the start, not just boilerplate, but thoughtful architecture.

The project includes:

• Clear separation of concerns with routes, middleware, database layers, and utilities
• RESTful routing with versioned endpoints (/api/v1/)
• Parameterized SQL queries preventing SQL injection
• SQLite with WAL mode and foreign keys enabled
• Pagination utility with sensible defaults
• Composable validation middleware

Run npm run start to test the API:

Looking good. The API responds properly, and it even includes pagination out of the box. The skill really delivered on creating a well-architected foundation.

Code Review with Skills

Now here's where it gets interesting. We could manually review the codebase ourselves, or we can use another skill to do a professional-level review for us.

I didn't even write a prompt, just invoked the skill using /code-review-excellence inside Claude Code.

The review that came back was extensive and detailed. It organized findings by severity, highlighted the codebase's strengths, and identified specific issues with file paths and line numbers.

The review starts by acknowledging what's done well like parameterized queries, clean structure, proper use of SQLite features. Then it dives into required changes and suggestions.

Required Changes flagged security and robustness issues:

• Internal error details leaking to clients in the error handler
• No request body size limit, leaving the server vulnerable to memory exhaustion
• Missing validation on query parameters that could return silent failures instead of proper errors
• Issues with falsy value handling using || instead of ??

Suggestions included design considerations:

• Whether DELETE endpoints should be truly idempotent
• A note about dynamic SQL construction being safe due to allowlisting, but worth documenting
• Missing test suite
• Schema creation running on every app startup
• Seed script deletes happening outside the transaction

The review even included a Questions section asking about design decisions like whether category_id: 0 is ever valid, plans for authentication, and CORS support.

This is the kind of thorough, structured feedback you'd expect from a senior developer doing a code review. The skill doesn't just point out problems, it explains the implications, provides code examples, and differentiates between critical security issues and optional improvements.

You can fix these issues yourself, or copy the feedback and let the AI handle the improvements. I'd recommend reviewing the changes either way to understand what's being modified and why.

Conclusion

The key benefits of using skills are:

• Specialized agents: Tailor capabilities for domain-specific tasks with expert-level knowledge
• Reduced repetition: Create reusable patterns once, apply them automatically across projects
• Composable capabilities: Combine skills to build complex workflows that handle entire processes

You wouldn't want to repeatedly provide the same detailed guidance across multiple conversations, right? That's where skills shine. They capture that expertise once and make it instantly available.

From what we tested today, you can create powerful workflows for developer tasks by combining skills strategically. The api-design-principles skill gave us a solid foundation with versioned endpoints, proper database configuration, and clean architecture. Then code-review-excellence caught real issues like security vulnerabilities, edge cases, and design considerations with the kind of detail you'd expect from an experienced code reviewer.

The combination compressed what would normally be hours of work and multiple review cycles into a few minutes, while maintaining quality standards and catching issues early.

If you want to create your own skills, check out:

• The cookbook  with examples and templates
• Claude API documentation  for the complete specification

The skills ecosystem is just getting started, and there's huge potential here. Whether you're automating repetitive tasks, enforcing team standards, or building complex multi-step workflows, skills give you a way to package up expertise and make it reusable.

Give it a try and see what workflows you can build.

Today, AI is everywhere. Almost every product uses it or at least wants to use it. But here's the problem: if you pick the wrong AI model, you might waste a lot of money. This guide will help you choose the right AI API and save money.

All prices in this article come from official sources. Data is updated as of January 2026. They can change. Check official sites before you decide.

• Claude Prices
• OpenAI Prices
• Gemini Prices
• DeepSeek Prices

Disclaimer: This article reflects my personal experience and opinions. Your results may differ depending on prompts, usage patterns, and workloads. Pricing is sourced from official provider pages linked above.

Understand Your Use Case First (Most Important!)

Before you look at prices, ask yourself: "What does my project really need?"

Not every job needs the most expensive model. Let's break it down:

Questions you should ask yourself:

• Does my task require complex reasoning?
• Do I really need maximum accuracy, or is "good enough" okay?
• What's my usage volume? (requests per day)
• What's my budget?

What does "Estimated cost" mean?

Before we go further, all “estimated cost” numbers in this article are order-of-magnitude estimates, which means they are estimates, not exact bills.

I will assume a baseline SaaS workload:

• 1,000 requests per day (30,000 per month)
• Average request:
  • ~500 input tokens
  • ~300 output tokens
• Mostly text-based usage (no images)
• Minimal tool calls
• No extreme prompt inflation

This roughly represents:

• A small-to-medium SaaS feature
• An internal developer tool
• A customer support assistant with moderate usage

Actual costs will vary based on:

• Prompt length
• Output verbosity
• Use of reasoning / thinking modes
• Caching and batch APIs

If you want to estimate your own token usage, the following tools can help:

• OpenAI Tokenizer
• Claude Tokenizer
• Gemini API Token Counting
• DeepSeek API Token Usage

The Major Players: Price & Performance Comparison

Tier 1: Premium Models (Expensive but Most Accurate)

**Claude Opus 4.5**

Best for

• High-stakes reasoning
• Important decisions
• Complex analysis where mistakes are expensive

Why

• Very consistent and reliable
• Strong safety and reasoning
• Output quality is stable even on hard tasks

Estimated cost

• ~$250–300/month (baseline workload)

Use only when errors have real consequences (legal, financial, safety).

Not a default choice.

**OpenAI GPT-5.2 Pro**

Best for

• Extremely complex reasoning
• Large-context analysis
• Tasks where maximum quality matters more than cost

Why

• Very strong reasoning
• Large 400K context window
• Highest output quality from OpenAI

Estimated cost

• ~$1,500–1,800/month

This model is intentionally expensive.

Use only for rare, critical workloads.

**Gemini 3 Pro**

Best for

• Long documents
• Multimodal (text + images)
• Large-context applications

Why

• 1M token context window
• Good balance of quality and price
• Strong at document-heavy workflows

Estimated cost

• ~$120–150/month

Best choice when context length matters more than raw reasoning quality.

Tier 2: Balanced Models (Best Value for Most Apps)

**OpenAI GPT-5.2**

Best for

• General-purpose workloads
• Mixed reasoning + creativity
• Apps needing a large context window

Why

• Solid reasoning
• 400K context
• Works well across many task types

Estimated cost

• ~$140–160/month

Often more expensive than Gemini 3 Flash for similar workloads but one of the default safe choices for many real-world products.

**Claude Sonnet 4.5**

Best for

• Production apps
• Coding tools
• General-purpose SaaS features

Why

• Excellent balance of quality and cost
• Very strong at coding and refactoring
• Stable output

Estimated cost

• ~$160–180/month
• ~$80–100/month with Batch API

This is one of the “default safe choices” for many real-world products.

**Gemini 3 Flash**

Best for

• High-volume chatbots
• Simple to medium tasks
• Cost-sensitive applications

Why

• Very cheap
• Extremely fast
• 1M context window

Estimated cost

• ~$30–40/month
• ~$10–15/month with heavy caching

Output tokens usually dominate cost for chatbots.

Tier 3: Budget Models (Cheapest but Still Good)

**GPT-5 Mini**

Best for

• Simple tasks
• High-volume systems
• Budget projects

Why

• Very cheap
• Large 400K context window
• Fast responses

Estimated cost

• ~$22/month

Poor choice for complex reasoning.

**Claude Haiku 4.5**

Best for

• Simple workflows
• Fast responses
• Lightweight assistants

Why

• Cheap and reliable
• Good quality for simple tasks

Estimated cost

• ~$50–60/month

Not suitable for complex reasoning.

**DeepSeek V3.2 (Non-thinking)**

Best for

• Simple chat
• High-volume workloads
• Budget-first systems

Why

• Extremely cheap
• Good enough for basic tasks

Estimated cost

• ~$5–10/month
• ~$3–5/month with caching

Avoid for complex reasoning.

**DeepSeek V3.2 (Thinking Mode)**

Best for

• Math
• Logic-heavy reasoning
• Step-by-step problem solving

Why

• Very strong reasoning
• Much cheaper than premium reasoning models

Estimated cost

• ~$80–110/month

Thinking tokens dramatically increase output cost.

Do not use for simple tasks.

Tier 4: Do It Yourself (Open Source / Self-Hosted)

**Llama 4, Mistral, Phi**

• Price: $0 (if you run it yourself)
• Server Cost: You pay for computers and hosting
• Best For: Privacy matters, you want full control, high volume
• Good: Private, you can change it, no API fees
• Bad: You need to manage servers yourself, takes time

Price Comparison Summary

Baseline assumes 1,000 daily conversations, 500 input + 300 output tokens each.

For reasoning models, “output” may include thinking tokens, so costs can be higher.

Real-World Examples: How to Choose

Example A: Customer Support Chatbot (Lots of Messages)

What you need:

• 5,000 chats per day
• Simple questions and answers
• Fast replies
• Low cost

Best choice: Gemini 3 Flash + Context Caching

Why:

• Very cheap ($0.50/$3)
• Can handle 2,000 requests per minute
• Can store lots of info (1M tokens)
• Caching makes repeated instructions free

Estimated cost:

• Gemini 3 Flash with caching: ~$80–100/month
• DeepSeek V3.2 + caching: ~$10–20/month (cheapest)
• GPT-5 Mini: ~$30–40/month
• Claude Haiku 4.5: ~$120–150/month

Note: For chatbots, output tokens usually dominate cost. Caching mainly reduces repeated system prompts and instructions.

Example B: Code Helper (Medium Use)

What you need:

• ~500 coding requests per day
• Correct code matters
• Bugs can be reviewed
• Medium budget

Best choice: Claude Sonnet 4.5 (Batch API)

Why:

• Strong at coding and refactoring
• Batch API cuts cost by ~50%
• Quality is more than enough for production code

Estimated cost:

• Sonnet 4.5 (Batch): ~$100–120/month
• GPT-5.2: ~$180–200/month
• Gemini Pro: ~$160–180/month

Note: For coding tools, quality differences matter more than raw speed.

Batch processing works well because most code tasks are not real-time.

Example C: Data Analysis (Complex Work)

What you need:

• 100–200 complex questions per day
• Multi-step reasoning (math, logic, code)
• Accuracy matters
• Some results can be reviewed

Best choice: DeepSeek V3.2 Thinking or Claude Opus 4.5

Why:

• DeepSeek V3.2 Thinking: extremely cost-effective for reasoning
• Claude Opus: safer and more consistent for high-stakes decisions

Estimated cost:

• DeepSeek V3.2 Thinking: ~$80–100/month
• Claude Opus 4.5: ~$250–300/month

Rule of thumb:

• If mistakes are cheap or reviewable → start with DeepSeek V3.2 Thinking
• If errors are expensive (legal, financial, safety) → Claude Opus is justified

Hidden Costs to Watch Out For

1. Wasting Space in Your Prompts

If you send longer prompts than needed, you waste money!

Example:

• Your prompt is 5,000 tokens but you only need 1,000 tokens
• You're paying 4x more than necessary!

How to fix:

• Make your prompts shorter
• Cache the parts you repeat
• Delete old chat history you don't need

2. Too Much Output

Some models write very long answers!

DeepSeek V3.2 Thinking Example:

• You ask a simple question
• It shows 10,000 tokens of thinking + 500 token answer
• You pay for 10,500 tokens instead of 500!

How to fix:

• Use max_tokens to limit length
• Use simpler models for easy questions
• Use non-thinking mode when you don't need reasoning
• Ask for short answers in your prompt

3. Rate Limits Slow You Down

When you hit the speed limit → need to try again → waste time and money

Example:

• Gemini 3 Flash: 2,000 requests per minute
• GPT-5.2: 500 requests per minute (typical)
• If you get busy → GPT-5.2 slows down faster

How to fix:

• Pick models with high speed limits
• Add smart retry logic
• Pay for enterprise for higher limits

4. Images Cost Extra

Processing images costs different amounts!

Gemini Image Example:

• Input image: $0.0011 per image (560 tokens equivalent)
• Output image (1K): $0.134 per image
• Process 1,000 images/day = $4,050/month! 💸

How to fix:

• Make images smaller before sending
• Use special image models if needed
• Process non-urgent images in batches

5 Common Mistakes (Don't Do These!)

Mistake 1: Using an Expensive Model for Everything

Bad

• One premium model for all tasks
• High cost, little benefit

Better

• Cheap model for easy tasks
• Premium model only where needed

Result

• Save ~60–80% with no noticeable quality loss

Mistake 2: Not Using Caching

Bad

• Re-sending the same instructions every request

Better

• Cache system prompts and shared context

Result

• Input cost drops by ~70–90%

Mistake 3: Unlimited Output

Bad

• Letting models generate very long answers

Better

• Set max_tokens
• Ask for concise answers

Result

• Output cost reduced by ~50–80%

Mistake 4: Ignoring Batch APIs

Bad

• Using real-time APIs for non-urgent work

Better

• Batch processing for background jobs

Result

• ~50% cost reduction

Mistake 5: Using Thinking Mode for Simple Tasks

Bad

• Reasoning models for basic chat

Better

• Non-thinking model for simple tasks
• Reasoning model only when needed

Result

• Save ~80%+ on reasoning workloads

Summary: No Perfect Answer for Everyone

After looking at all the prices and options, here's what matters:

What You Should Remember:

1. Know What You Need First - Don't just look at price. Understand your work.
2. Mix Different Models - You don't need one model for everything
   • Easy work → Cheap models (DeepSeek V3.2, GPT-5 Mini)
   • Medium work → Mid-tier (Gemini 3 Flash, Haiku)
   • Hard work → Premium (Sonnet, GPT-5.2, Opus)
   • Save 60-90%
3. Small Changes = Big Savings
   • Caching: -90%
   • Batch API: -50%
   • Smart routing: -80%+
   • Using the right mode (Non-thinking vs Thinking): big savings
   • All together: Save over 95%!
4. Keep Testing
   • Start with cheapest models
   • Check if they work well
   • Upgrade only if needed
5. Price Is Not Everything
   • How much text it can handle
   • Speed limits
   • How fast it responds
   • Extra features (images, tools, thinking)

Last Words

Picking an AI API is not hard when you know what you need.

Start simple:

1. Understand what work you're doing
2. Try cheap models first (DeepSeek V3.2, GPT-5 Mini, Gemini 3 Flash)
3. Upgrade only if you must

Remember: saving money = making money. If you save $1,000/month, that's $12,000/year extra profit. With 10% profit margin, that's like earning $120,000 more in sales!

Also, tech gets better and cheaper fast. New models come out every few months with better prices. So check prices every 3 months and optimize.

Rule of thumb: Start with the cheapest model that might work, measure failure rate, then upgrade only where failures are expensive.