DEV Community: Harsh

I Stopped Comparing Myself to AI. It Changed Everything.

Harsh — Tue, 30 Jun 2026 10:59:54 +0000

I have been writing a lot about AI lately, but this one is more personal than usual. Not a tutorial, not a hot take on some new model - just something I have been sitting with for a few weeks now.

Let's start from the beginning. A few weeks ago I was scrolling Twitter at around midnight, the way you do when you tell yourself just five more minutes and then it is suddenly 1 AM. A new benchmark had dropped. Someone posted a "10x developer with AI" thread screenshots and all. Someone else was live-coding a full-stack app in 20 minutes like it was nothing.

I closed the app. Opened my editor. And felt that very specific very familiar weight settle in.

The comparison nobody warned me about

I think I had been quietly comparing myself to AI for months without fully admitting it. Its speed. Its memory. Its bottomless confidence. The way it produces an answer without a single visible moment of wait is this actually right?

I was measuring myself against something that does not sleep, does not doubt itself, does not sit there staring at a wall for twenty minutes because it cannot remember why a function is named the way it is.

And obviously I was losing. Every single time. That was never going to be a fair comparison but somehow I kept running it anyway.

I used to look at AI-generated code and think "I could never write that this fast." I used to look at how confident it sounded and think why am I always so unsure of myself. I used to look at how much it seemed to remember and think why do I forget things I learned three weeks ago.

It was exhausting, and not in the normal hard-day-of-work way. It was exhausting because I was fighting something I could never actually win.

A pull request that made me stop and think

A few weeks ago I was reviewing an AI-generated PR. Code looked clean. Logic checked out. Tests were all green.

Something still felt slightly off and I could not immediately say why.

I read through it again, slower this time. Traced the logic by hand. Thought about our actual users - not generic users, the specific weird way our users use this one feature the edge case from last quarter that almost took down production.

The code was correct. It was also wrong for us specifically. The AI had optimized for the general case, the version of this problem that shows up most often across whatever it was trained on. I had to optimize for the one particular, slightly weird version that exists in our codebase, with our history for our actual users.

That is roughly when it clicked for me, in a way that felt obvious in hindsight. AI and I are not really competing. We are doing two overlapping but different jobs. It is fast, I try to be thoughtful. It is broad, I am specific. It is confident because that is how it is built, I am careful sometimes to a fault because I have been burned before.

Comparing myself to it was a bit like being upset that a hammer is not as precise as a scalpel. Different tools, different jobs.

So what actually changed (a little, slowly)

I am not going to pretend I had some clean, complete transformation here, because that is not really how this stuff works for me. But a few things did shift.

I stopped measuring myself against how fast AI could generate something, and started asking instead: do I actually understand what is shipping under my name? I stopped quietly resenting that my memory is let's be honest, mediocre on a good day, and started appreciating that forgetting things clears space for new connections. I stopped envying its confidence and started trusting my own hesitation a little more - that hesitation usually turns out to be experience quietly doing its job. AI does not have that, because it has never been the one paged at 2 AM over a bad deploy. I have.

I am still not entirely sure where any of this lands long-term. Maybe in a year I will read this post back and think I was being naive. The pace of all of this keeps making me reconsider things I thought I had figured out.

I do not have a tidy ending for this one

I genuinely do not know if "context and judgment" stay valuable in the way I am hoping they do, or if that is just the thing I am telling myself right now because it is comforting. Maybe the comparison creeps back in next month and I am back here writing about it again from a slightly different angle.

What I do know is that comparing myself against something built to never sleep, never doubt, and never get stuck was never a fight I was going to win, and I am tired of running that comparison in the background of every single PR.

Have you caught yourself doing this too - comparing your speed your memory your confidence to AI? What helped, if anything did? I am genuinely curious not asking rhetorically.

Drop it in the comments. I will be there. 👇

How I Automated DigitalOcean Infrastructure with SuperPlane

Harsh — Wed, 24 Jun 2026 10:03:34 +0000

Our infrastructure "documentation" was a Google Sheet. Anyone on the team could edit it. Nobody always did.

Every new droplet meant the same five manual steps: log in, pick image and size, configure firewall rules, set up DNS, update the spreadsheet. 30 minutes if nothing went wrong. No record of who did it. No approval process. No way to trace a misconfigured droplet back to a decision or a person.

The obvious fix was a script. But a script running on a cron job with no visibility is just a faster way to make undocumented changes. You still don't know what ran, when, or why something broke.

What I actually needed was audit logs, approvals, and notifications - without stitching together three separate tools to get them.

That's what SuperPlane gave me.

The Problem

Every time I needed to provision a new droplet, the process looked the same:

Log into DigitalOcean
Select image, size, and region
Configure firewall rules manually
Set up DNS records manually
Document everything in a spreadsheet - hoping I didn't forget anything

No audit trail. No approval process. No visibility into who made which change or when.

If something went wrong, there was no way to trace it back. If a team member provisioned resources without approval, there was no record. This wasn't just inefficient - it was risky.

The spreadsheet was becoming the most important piece of infrastructure, and it was just a Google Sheet that anyone could edit.

The Workflow I Built

I built a simple automation workflow using SuperPlane. The setup started with creating an owner account and connecting my DigitalOcean workspace.

SuperPlane's initial setup screen - straightforward owner account creation before configuring your first workspace.

Once the workspace was set up, I created a new app using the built-in app catalog. SuperPlane offers starter templates for common workflows, including a pre-built Preview Environments (GitHub + DigitalOcean) integration.

The New App screen. Two options immediately relevant: Preview Environments with GitHub + DigitalOcean, and GitHub + AWS. I chose the DigitalOcean path.

The workflow I built has four steps:

Step 1 - Trigger
Activates when a new droplet needs to be provisioned. Listens for a droplet event so the automation starts automatically - no manual kick-off required.

Step 2 - Create Droplet
Provisions a droplet with predefined specifications: specific image, size, and region. No one on the team has to remember the correct settings.

Step 3 - Configure DNS
Creates DNS records automatically once the droplet is ready. This used to be the step most likely to be forgotten.

Step 4 - Notify
Sends a Slack notification when everything is complete. The whole team knows the environment is ready without anyone having to check.

When a team member requests a new environment, the workflow triggers automatically. The droplet gets created. DNS configures itself. Everyone gets notified. No manual steps, no delays, no "did someone set up DNS?" in Slack at 11 PM.

What Gets Triggered & How the Demo App Works

The workflow starts when a droplet event is triggered. This happens when someone requests a new environment - either through a chat command, a form submission, or directly from SuperPlane's UI. The trigger listens for droplet.create events and kicks off the automation automatically.

Here's the demo app architecture:

Component	What it does
Workspace	Connected to DigitalOcean using an API token
App	Created from the "Preview Environments (GitHub + DigitalOcean)" template
Canvas	The visual workflow editor where you drag and connect components
Trigger	Listens for `droplet.create` events
Actions	Create Droplet → Create DNS Record → Send Slack notification

When the trigger fires, it captures request details (droplet name, region, size) and passes them through the canvas. Each component receives the output from the previous one automatically - no manual wiring required.

The Visual Workflow Canvas

SuperPlane gives you a visual canvas to build infrastructure workflows - no YAML files, no scripting, just drag and connect.

The canvas editor. Left panel: the AI Agent (already greeting you and setting up) plus Console, Memory, and Files tabs. Center: the visual canvas where you drag and connect components. Top right: Publish button when the workflow is ready.

When you click on the New Component node, a sidebar opens with every available DigitalOcean action:

The full DigitalOcean component library - Create Droplet, Create GPU Droplet, Create Knowledge Base, Create Load Balancer, Create Snapshot, Delete actions, DNS records, and more. Every DigitalOcean operation available as a drag-and-drop component.

How the flow comes together:

Drag Create Droplet onto the canvas
Drag Create DNS Record next to it
Click and drag an arrow to connect the two nodes
Configure each component - select region, size, droplet name

The canvas automatically passes data between components. When Create Droplet runs, its output droplet ID, IP address - flows directly into Create DNS Record. No manual wiring of variables.

Where observability lives:

The Console tab shows execution logs for every run
The Agent panel helps debug failures in plain language
Click any component to inspect its input, output, and status
Every workflow run is recorded with timestamps and who triggered it

This is what makes SuperPlane different from a script or a Makefile. You see everything on one screen. The execution history is right there. No digging through log files, no guessing why something failed.

Why SuperPlane Made It Actually Work

Before this, I tried two other approaches.

First was a Bash script on a cron job. It worked until it didn't - and when it broke, there was no way to know what had run, what hadn't, or why.

Second was Terraform with a Slack webhook bolted on. Better, but I still had no approval step and the audit trail was just Git blame on a state file.

The thing both approaches were missing wasn't automation. It was control.

SuperPlane is open-source, so I could read exactly what it was doing. That mattered. What kept me using it was four things I couldn't easily get elsewhere without stitching tools together:

Logs that are actually useful. Every run is recorded with a timestamp and who triggered it. When something breaks, I click the run, see the exact step that failed, and read the input and output for that component. No digging through CloudWatch or grepping log files.

Approvals built into the workflow. Destructive operations like deleting a droplet require a human to confirm before anything executes. This isn't a policy document someone has to remember - it's enforced at the workflow level.

Budget guardrails. The workflow won't provision outside predefined limits. The constraint isn't in a README - it's in the system.

Human-in-the-loop for AI actions. Agents can propose workflow changes but nothing executes without a person reviewing it first. This is the part that I think is actually new. Not AI automation. Governed AI automation.

A cron job does the task. SuperPlane does the task and gives you a paper trail you can actually trust in production.

The Bigger Takeaway

Small automations are useful. Governed automations are valuable.

The difference is oversight - knowing what ran, when, why, and who approved it. Platform teams can now build custom operational workflows without stitching together five different tools to get audit logs, approvals, and notifications working together.

What used to take me 30 minutes of manual work - logging in, configuring, documenting, notifying - now happens automatically. The infrastructure workflow that required constant babysitting runs itself.

More importantly: I can trust it. That's the part that matters.

Get Started

SuperPlane is open-source. Run the demo in 2 minutes:

docker run --rm -p 3000:3000 -v spdata:/app/data -ti \
  ghcr.io/superplanehq/superplane-demo:stable

Then open http://localhost:3000 in your browser.

👉 GitHub: github.com/superplanehq/superplane

Have you automated your infrastructure workflows? What tools are you using? What's the part that still requires manual steps you wish didn't?

Drop a comment - I read every one.

The 80/20 Rule of AI Code — Why the Last 20% Takes 80% of Your Time

Harsh — Tue, 23 Jun 2026 10:49:47 +0000

AI wrote the first 80% of my feature in 10 minutes.

The code was clean. The logic made sense. The happy path worked on the first try. I ran it, saw it work, and felt that specific kind of developer pride that makes you lean back in your chair slightly.

I was impressed. I felt genuinely productive. I thought I'd be done in another 10, maybe 15 minutes.

That was Tuesday By Thursday evening I was still working on the same feature. Not because the AI had failed. Because it had succeeded at exactly the wrong thing the easy part and left the actual hard part entirely to me.

The edge cases. The error handling. The null checks. The situations that only surface when a real user does something the happy path didn't anticipate.

The AI didn't write those. It didn't even know they existed. It optimized confidently and completely for the world where everything goes right - and that world is not the one your users live in.

That's the 80/20 rule of AI code. The first 80% is fast, impressive, and kind of magical. The last 20% is where the real work actually lives. And it takes 80% of your total time.

Here's what I've learned about that gap, and why I think it matters more than the 10 minutes you saved on Tuesday.

The 80% - Fast, Clean, and Genuinely Impressive

I want to be honest about this part before I get into the frustration.

The AI is remarkable at the first 80%. You give it a clear prompt, it understands what the happy path looks like, and it generates code that works. Not kind-of works. Actually works, with reasonable variable names and logic that flows the way you'd expect.

The first time I saw it in action I genuinely felt like I'd cheated at something. Tickets were closing. The velocity graph was going up. I was shipping things faster than I had in years.

And that feeling is real - I'm not being sarcastic about it. The AI is fast because it's operating in familiar territory. The happy path is the well-trodden path. It's the version of your problem that exists in some form in the training data, that has been solved thousands of times before, that the model can pattern-match its way through with confidence.

The 80% is real. The speed is real.

The problem is that we've started treating the 80% like it's the whole thing. And it isn't.

The 20% - Where Tuesday Becomes Thursday

The AI wrote the happy path. Here's an honest list of what it didn't write:

The empty list. What happens when the user has no data yet? New account, nothing in the database, the list the AI assumed would always have items turns out to be empty. The AI didn't check. You find out from a user report three days after launch, spend an hour tracing back to the unhandled case, and add the check you should have written on Tuesday.

The error handling. The AI assumes the network responds. It assumes the API returns what you asked for. It assumes the third-party service is up. Every try-catch block, every fallback, every "what do we show the user when this fails" decision - that's yours. The AI left it blank because things going wrong wasn't part of the prompt.

The domain-specific edge cases. This is the one that surprises me every time. The AI doesn't know your business logic. It doesn't know that "empty" means something different in three different parts of your application. It doesn't know about the legacy data that's formatted differently. It doesn't know about the enterprise customer who uses the product in a way nobody expected. You know those things. The AI has never heard of them.

The performance cliff. The AI writes code that works for the examples it was given. It doesn't stress-test for scale. You find the bottleneck when the feature goes live and the page suddenly takes four seconds to load for users with large datasets. The code isn't wrong. It just wasn't written with real load in mind.

The maintainability tax. This one is the slowest to show up. The AI writes code that solves today's problem. Three months from now when the requirements shift slightly and you're trying to extend it, you realize the abstraction doesn't quite fit the new shape. Refactoring it costs more time than writing it from scratch would have.

Each of those items takes time. Together, they consistently add up to about 80% of the total effort on any feature I've shipped using AI-generated code.

The 30 Seconds That Cost Me 3 Hours

I was looking at a pull request recently - maybe 200 lines of AI-generated code that I'd prompted in about 30 seconds.

I spent the next 3 hours with it.

Not because the code was broken. The code was fine. I spent 3 hours adding everything the AI had quietly decided wasn't its problem: the error paths, the null checks, the comments explaining the decisions that weren't obvious, the edge case I found by actually thinking about what our users do.

During the 30 seconds I felt fast. During the 3 hours I felt slow.

But here's the thing I keep coming back to: the 3 hours was the actual work. The 30 seconds was the scaffolding. The AI didn't reduce the work - it relocated it. The time moved from writing the structure to making it real and making it real is slower because it requires something the AI genuinely doesn't have: context about your specific situation, your specific users, your specific history with this codebase.

That was the moment I stopped caring about how long generation took and started tracking something more honest: how long until it's actually ready to ship.

Why This Isn't a Complaint About AI

I want to be clear - the 80/20 split isn't a failure of AI. It's basically the design.

The AI is optimized for the common case. The common case is the happy path. Generating the common case quickly is genuinely useful; I'm not being dismissive of that.

The issue isn't with the AI. The issue is with how we've started measuring productivity around it.

We measure velocity. Tickets closed. Lines generated. Contribution graph. And all of those metrics capture the 80% beautifully - because the 80% is fast and visible and shows up as green squares.

The 20% is invisible to those metrics. Nobody's dashboard shows time spent adding error handling. Nobody's standup starts with "I spent yesterday on edge cases the AI didn't anticipate." It doesn't show up anywhere. But it's where most of the actual time goes.

The 80% is what gets you to a demo. The 20% is what gets you to production. And if you're not tracking how long the 20% takes, you're not tracking your real productivity - you're tracking how quickly you can type a prompt and feel good about it.

What I'm Actually Doing Differently

Not quitting AI. Not even thinking about it. But I've changed a few things:

I budget for the 20% upfront. When I estimate any task involving AI-generated code, I add roughly 4x to whatever the generation time suggests. The AI says "this is a 10-minute feature." I tell my brain it's a 40-minute feature and plan accordingly. It's not pessimism - it's just the pattern holding.

I prompt for the unhappy path explicitly. Before I even generate the main code, I add to the prompt: what should happen with empty input? What should happen when the API fails? What edge cases exist here? The AI won't think of them on its own. If I name them, it at least takes a pass at them.

I write the failing tests before the code exists. What would break this? What would a mischievous user do? I write those tests first so the AI has a target. It doesn't catch everything, but it catches more than the AI would find by itself.

I remember the 3 hours. When I'm tempted to push something quickly because it works in the demo I think about the 3 hours. The 30 seconds felt good. The 3 hours was the job.

None of this makes the 20% disappear. But it makes it predictable instead of surprising, which is the difference between managing it and being ambushed by it.

One Question

What's the longest you've spent on the last 20% of something the AI generated quickly?

I want actual numbers if you have them. The gap between how long generation took and how long it actually took to ship - that's the number I'm curious about.

My answer: 30 seconds to generate, 3 hours to finish.

What's yours? 👇

Heads up I used AI to help structure this post and refine my thoughts. The experiences stories and opinions are my own.

I Asked AI to Write My Commit Messages It Was Embarrassing.

Harsh — Tue, 16 Jun 2026 10:44:59 +0000

I asked AI to write a commit message for me last week The code change was simple. A bug fix One line, easy to explain in a single sentence if I'd bothered to think about it for ten seconds.

The AI wrote:

Updated stuff. Fixed things. Improved performance.

That was it Four words of pure, unhelpful weapons-grade nothing I stared at it. Then I closed the tab. Then - for reasons I can't fully explain - I reopened it and stared at it again, as if it might improve on a second viewing.

I couldn't ship it. Not because it was technically wrong. Because it was soulless. It told a future reader absolutely nothing about what had happened, why it had happened, or whether it mattered.

That's when it hit me: AI can write code. It apparently cannot write a message that sounds like a human who gives even a small amount of a damn.

Here's what happened when I let AI write my commit messages for a week -and why I'm never doing it again.

What Commit Messages Used to Mean

I used to actually spend time on commit messages.

Not hours. Not a whole production. But enough - a sentence that explained the why not just the what A brief note about a trade-off I'd considered and rejected. Sometimes a link to the ticket. Sometimes a one-line explanation of a genuinely weird edge case that future-me would otherwise stare at in confusion.

The message was never really for the code itself. The code speaks for itself, eventually, if you read it carefully enough. The message was for the next person the one who'd find this specific commit six months later, mid-debugging-session, wondering why on earth did anyone do it this way.

A good commit message is a small specific gift to your future self or to whoever inherits your code next.

I genuinely hadn't noticed I'd stopped giving that gift Not until I handed the job to AI and got back a perfect mirror-clean reflection of exactly how little effort I'd been putting in.

The AI's Commit Messages: A Gallery of Shame

Here's what the AI produced for my last three actual commits I'm sharing these because I think you'll recognize the genre even if you haven't seen these exact words.

1 Fixed stuff.
Three words. Zero context. Not the faintest clue what was fixed, why it needed fixing, or whether anyone should care.

2 Improved performance.
By how much? Where in the codebase? Through what mechanism? Compared to what baseline? The message answers none of these and somehow still manages to sound confident about it.

3 Bug fixes and other improvements.
This might be the most generic sentence that has ever existed in the English language It is, technically, true of almost every commit ever made by anyone.

The AI had access to the actual diff. It had seen exactly what changed, line by line. And given all that information, it chose to communicate essentially nothing.

Here's the part that actually got to me: these messages aren't even useful to another AI. If a different model reads "fixed stuff" in six months while trying to understand the history of this file, it gets exactly as much signal as a human would which is to say, none.

The commit message wasn't really the problem. It was a symptom. I had quietly stopped caring about the story of my own code, and the AI trained to be helpful and inoffensive - just mirrored that indifference straight back at me, dressed up in complete sentences.

Why This Actually Matters

Commit messages aren't just decoration on top of Git history. They're not busywork.

They're for the teammate who finds this code in six months and needs to understand why a decision was made before they touch it They're for the person doing a code review who's trying to evaluate whether a change is reasonable. They're for you - specifically you, at 2 AM, staring at a stack trace, trying to remember what you were thinking when you wrote this.

A good commit message answers one question clearly: why did we do this?

A bad commit message answers nothing, while taking up exactly as much space as a good one would have.

The AI gave me generic, hollow commit messages because - and this is the uncomfortable part - I had already been giving generic, hollow commit messages for a while before I asked it to take over. It learned the pattern from my own recent history. It reflected my laziness back at me with perfect fidelity and zero judgment.

That's the part that actually embarrassed me. Not the AI's output. Mine.

The AI wasn't the problem. I was, and the AI just made it visible.

The Lesson

I'm back to writing my own commit messages.

Not because I have some rule against AI assistance in general - I use it plenty for other things. But because I realized somewhere in this process that the commit message was never really meant for a computer to generate. It's meant for a human to read, and it should sound like it was written by one who was paying attention.

The AI can write the code. It can refactor, suggest, generate, autocomplete. What it apparently can't do - at least not without me actively caring first - is write the story of why a change happened. And the story is the part that actually matters, to the next reviewer, to the next maintainer, to future-me debugging something at an hour I'd rather not specify.

I don't need AI to write my commit messages.

I just need to care enough, for about fifteen seconds per commit, to write them myself.

One Question

What's the worst commit message you've ever seen - or, if we're being honest with each other, written yourself?

I'll go first: "Fixed stuff."

I'm not proud of it. But I stand by sharing it.

Your turn. 👇

The 'Prompt' Is Not a Skill — And We Need to Stop Pretending

Harsh — Tue, 09 Jun 2026 10:50:45 +0000

Writing a prompt isn't engineering. It's typing.

You type what you want. The AI figures out the rest That's not a skill. that's having a conversation with a very fast very confident intern who never admits uncertainty.

And yet. We've started calling ourselves prompt engineers We've started listing it on LinkedIn We've started acting like knowing how to ask is the same as knowing how to build. It's not.

The real skill - the one that actually matters the one that was always there never - changed. It's knowing what to ask for. It's knowing whether the answer is right It's knowing what the AI assumed what it missed and what it quietly broke without flagging.

Prompting isn't the skill Judgment is.

Let me explain why - and why pretending otherwise is actively hurting us.

What We're Actually Doing

Let's be honest about what prompting looks like in practice.

You open a chat window. You type a description of what you want. The AI writes code If it's wrong or incomplete, you type another sentence. refining it The AI tries again You repeat until it works or until you give up and write it yourself.

That's not engineering. That's talking.

Engineering requires understanding trade-offs It requires knowing why one solution is better than another for a specific context It requires anticipating failure modes designing for change making decisions that will hold up when requirements shift six months from now and someone else is maintaining the code.

Prompting requires none of that.

The AI handles the trade-offs - or rather it makes choices without surfacing them to you The AI anticipates failure modes - poorly silently in ways you won't discover until production The AI makes the architectural decisions You review approve and ship.

We've outsourced the thinking and called it a skill.

We've confused using a tool with knowing the craft.

The Lie We're Telling Ourselves

Here's the lie, stated plainly: I'm a prompt engineer I've developed a new professional skill.

You haven't. You've learned to talk to a machine that was specifically designed, at enormous expense to understand natural language from anyone The entire point of these models is that you don't need special knowledge to use them.

The AI doesn't need your prompt engineering skills It needs your judgment It needs you to know whether the code it wrote is actually correct - not just syntactically valid but correct for your use case your constraints your edge cases It needs you to catch the assumptions it made without telling you It needs you to ask "what happens when this list is empty?" because the AI won't ask that question It'll just assume a list will always have items write code based on that assumption and return output that looks completely reasonable until a user with an empty list hits the endpoint.

And here's the part that bothers me most: prompting is accessible to everyone My non-technical friends prompt My parents have started prompting My neighbor who describes "coding" as the thing where you make computers do things prompts They get useful results.

The thing that separates a developer from a person who has never written a line of code isn't the prompt It's knowing what to do with the answer It's knowing when the answer is wrong It's knowing which parts of the AI's output to trust and which parts to verify independently.

That's not a prompt skill. That's a development skill And we've had it all along.

The Moment I Couldn't Unsee It

A non-technical friend pulled me aside at a gathering last month They'd been using AI tools for a few weeks and were clearly excited about it So you just type what you want and the AI writes the code for you? I said yes.

Then I felt something I didn't expect: embarrassment.

Because that's what I do I type what I want I review the answer I copy the relevant parts I ship it. And in that moment I realized my friend - who doesn't know what a stack trace is who has never debugged anything who thinks "deploying" means emailing a file - could do the same sequence of steps with the same tools.

So I asked myself the uncomfortable question: if a person without my background can follow the same workflow what's actually valuable about me?

The answer when I sat with it honestly: I know when the AI is wrong I know the questions to ask next I know what the AI assumed and whether those assumptions hold I know which of its solutions will cause problems under load or fail on edge cases or be a nightmare to maintain.

Those aren't prompt skills Those are engineering skills They took years of frustration and failure to develop And they're completely invisible in the prompt itself.

What the Real Skill Actually Is

Prompting is the input method. The skill is everything that surrounds it.

Knowing what to actually ask for. Not "write a function that does X" That's easy anyone can do that "Write a function that handles empty inputs null values and malformed data and tell me what assumptions you're making - that requires knowing what could go wrong Which requires experience.

Knowing if the answer is right. The AI is always confident Confidence doesn't correlate with correctness You need the background to know when confidence is lying - when the code looks right but has a subtle flaw when the explanation is plausible but wrong when the solution works for the example but fails in the general case.

Knowing what the AI assumed. This is the one that bites most often. The AI doesn't tell you its assumptions - it just makes them and moves on The empty list The non-null pointer The timezone that's always UTC The user that always has a name Catching those assumptions before they reach production is an engineering skill full stop.

Knowing when to ignore the AI entirely. Sometimes the AI gives you a solution that technically works but is wrong for your context - wrong architecture wrong abstraction level wrong trade-off for your specific constraints Recognizing that requires understanding your system deeply enough to evaluate proposals not just accept them.

These are not prompt skills They are the same skills developers have always needed The input method changed The judgment required did not.

Prompting is easy Judgment is hard We need to stop conflating them.

Why This Isn't Just Semantics

Calling prompting a skill isn't a harmless rebranding It has real consequences.

Junior developers are being told to learn prompt engineering as if it's a foundation - as if it substitutes for understanding data structures debugging system design how things fail It doesn't It can't A junior who can prompt but can't reason about their code is a junior who can produce output quickly and catch problems slowly.

Companies are hiring prompt engineers - roles that optimize for the input method rather than the judgment behind it They're building teams organized around the tool rather than the craft.

And developers are updating their LinkedIn profiles with skills that sound impressive but describe something any person with internet access can do.

The result: a layer of the industry that can generate but not evaluate That can ship fast but can't debug when it breaks That has strong opinions about which prompting techniques work best and fragile intuitions about why the code is actually wrong.

When the empty list assumption crashes production at 2 AM, the prompt won't save you The debugging skills will. The architectural intuition will. The experience of having been burned before will.

We're not prompt engineers We're developers who use AI as a tool. And the distance between those two descriptions matters more than it might seem.

What I'm Doing Instead

I'm not quitting AI I'm not going back to writing everything from scratch That would be a different kind of self-deception.

But I've stopped calling prompting a skill in any meaningful sense of the word I treat it as an input method - the way I treat typing or using a terminal It's how I talk to a tool not a capability I've developed.

I focus on the things that require actual judgment: architecture edge cases failure modes trade-offs the assumptions hidden in outputs that look correct. I ask what did the AI assume? before I ship I treat confident AI output with the same skepticism I'd give a confident junior who hasn't worked in production yet.

I remind myself regularly: typing isn't engineering Thinking is And I don't put prompt engineering on my resume.

One Question

Are you a prompt engineer?

Or are you a developer - with real skills, real judgment, real experience who happens to use AI as a tool?

I've made my choice about how I answer that.

What's yours? 👇

The Bug That Took 10 Minutes to Fix and 3 Days to Find

Harsh — Wed, 03 Jun 2026 10:29:25 +0000

The fix was one line.

if not items: return []

That's it Three words a colon and a pair of brackets It took me 10 seconds to type. 10 minutes to test and verify 10 seconds to deploy.

It took me 3 days to find.

Three days of staring at logs that said nothing Adding print statements that confirmed nothing Rewriting code that wasn't broken Blaming the framework Blaming the database Blaming the network Eventually quietly blaming myself.

The bug wasn't complicated It wasn't deep It was hiding in plain sight in a place I hadn't thought to look because I hadn't thought to ask the right question.

The AI had assumed a list would never be empty I had assumed the AI was right. Neither of us checked.

This is the story of how I spent 3 days debugging a bug that took 10 minutes to fix and what I learned about assumptions silent failures and the expensive gap between it works and it always works.

How It Started

The code was simple A function that processed a list of user inputs and returned a summary A small feature, maybe two hundred lines total Nothing that should have taken more than an afternoon.

I'd used AI to write the core logic The prompt was clear The output looked clean - readable, well-structured, sensible variable names I reviewed it The tests passed The PR was approved in the next morning's standup I shipped it on Tuesday.

The feature worked fine for two days Users were using it Logs were quiet I moved on to the next ticket.

Then Thursday happened.

A user with an empty list hit the endpoint No data - just an empty state, the kind that every real application encounters eventually The function received the empty list, processed it, and returned... nothing Not an error Not an empty list Not a helpful message Just silence.

The UI froze waiting for a response that wasn't coming The user was confused Support flagged it I was pulled back into code I thought was done.

The function worked 99% of the time The 1% was invisible And in production invisible is expensive.

Day 1: The Spiral

I started where anyone would the error logs Nothing No exceptions no warnings, no trace The function had been called It had returned The logs had nothing to say about what happened in between.

I added print statements Ran the code locally It worked perfectly Of course it did - I had test data which meant I had a non-empty list which meant I never triggered the bug.

I checked the database The data was there The function was definitely being called - I could see the request in the logs It returned something The UI just couldn't do anything with it.

I blamed the framework Maybe it's a caching issue Maybe the response is getting intercepted somewhere Cleared caches Nothing changed.

I blamed the network Maybe the request is timing out before the response arrives Checked latency Everything was fine.

I blamed the AI-generated code Maybe the logic is wrong in a subtle way I missed in review Rewrote the core function by hand line by line Same behavior.

By 6 PM I had rewritten three functions restarted the server twice added eleven print statements and learned absolutely nothing.

I closed my laptop The bug was still there.

So was I.

Day 2: The Desperation

I came back Friday with fresh eyes and no new ideas - the worst combination.

I traced the execution path more carefully this time Line by line watching the data flow through the function The input was received The processing ran The output was generated Everything looked right.

Except the output was wrong.

I started questioning things I hadn't questioned in years Did I actually understand the data structure I was working with? Was Python doing something I wasn't expecting with list references? Was there a mutation happening somewhere that I wasn't seeing?

I added a check to log the exact value of the input list before processing Items were there I added a check after processing The result was empty The logic in between looked correct.

I posted on Stack Overflow No answers for six hours.

I asked an AI assistant It suggested the same approaches I'd already tried, phrased slightly differently.

I pulled a colleague into a Zoom call They looked at the code for ten minutes and said It looks fine to me.

That was the worst moment of the three days Not the frustration not the wasted hours - the moment when someone else looked at it and confirmed that nothing was obviously wrong. Because that meant either I was missing something fundamental or the bug was somewhere I hadn't looked yet.

By Friday night I had genuinely started to wonder if I was going to find it at all.

Day 3: The Breakthrough

Saturday morning. Fresh coffee No notifications I opened the function again with no particular plan - just read it one more time slowly with no assumptions about where the problem was.

Same code. Same behavior But I added one more log I hadn't thought to add before:

print(f"items before processing: {items}")
print(f"items type: {type(items)}, length: {len(items)}")

The list had items. Three of them. Good — confirmed the input was right.

print(f"processed result: {processed}")
print(f"processed length: {len(processed) if processed else 'empty/None'}")

The processed result was empty.

I stared at the screen for a moment Input: three items Output: empty The logic in between: apparently correct.

Then I looked at something I had looked at a dozen times before but never really seen The function I was testing was calling a helper function I had reviewed that helper function I had read it carefully But I had read it assuming the input would always have items - because in my testing it always did.

The helper function wasn't checking It was written assuming the list would have at least one item When it did it worked correctly and returned results. When it didn't when the list was empty it entered a code path that silently returned nothing instead of an empty list.

No exception No warning No log entry Just nothing wrapped up neatly and returned as if nothing was wrong.

if not items: return []

I added the line Ran the test with an empty list The function returned an empty list.

I ran the full test suite Everything passed.

I deployed The UI loaded The user with the empty list finally saw something on their screen: an empty state message exactly what they should have seen three days ago.

The fix took 10 seconds to write and 10 minutes to verify.

Finding it took 3 days.

What the Bug Taught Me

The 99% trap is real. Code that works most of the time is significantly harder to debug than code that fails loudly and immediately The silent failure is the expensive one because it doesn't announce itself and because you'll keep testing with the cases that work and never see the case that doesn't.

Assumptions are invisible debt. The AI assumed a list would never be empty because most of its training examples involved lists that had items. I assumed the AI had handled the edge cases because the code looked complete. Neither assumption was wrong on its own they were just unchecked And unchecked assumptions in production are loans you'll repay with interest.

Works on my machine is a specific kind of lie. It works on my machine because I test with data. The bug lived in the absence of data The happy path works the happy path always works The skill is in finding the unhappy path before your users do.

The fix is almost never the hard part. Finding is hard Fixing is easy I spent 3 days finding a single unhandled edge case I spent 10 minutes fixing it. The value in software development isn't in writing code it's in knowing where to look when the code is wrong.

I should have asked what happens when this gets nothing? Before shipping Before the PR was approved. Before the tests ran That question takes 30 seconds to ask and answer It would have saved three days.

What I'm Doing Differently

Now I ask one question before I ship any function before review before testing before deployment:

What happens when this gets nothing?

Empty list Null input Missing field Zero results The case where the happy path assumption is wrong.

I don't trust AI-generated code to ask that question for me I don't trust myself to remember to ask it spontaneously So I made it a rule part of my personal pre-ship checklist right after does the happy path work.

It takes about 30 seconds to answer It would have saved me 3 days.

That's a trade-off I'll take every single time.

One Question

What's the longest you've spent debugging a bug that turned out to be a one-line fix?

Days? Hours? A week you'd rather forget?

I'll go first in the comments 3 days, one missing edge case, one line of code I still think about every time I ship a new function.

Your turn. 👇

I Spent 10x Longer Debugging AI Code Than Writing It

Harsh — Thu, 28 May 2026 14:53:02 +0000

AI wrote the code in 30 seconds

Three lines A simple function I prompted it generated I copied It looked fine Clean syntax Good variable names No obvious errors.

I spent the next 5 hours debugging it.

The bug wasn't in the logic The AI had made a quiet assumption - that a list would never be empty It worked 99% of the time The 1% crashed in production A real user A real failure A very real 5 hours of my life.

30 seconds of generation 5 hours of debugging.

That's not efficiency That's a trade-off nobody is talking about.

This isn't an anti-AI article I use AI every single day It has genuinely changed how I work But I've stopped pretending that speed at write time is the only metric that matters.

Here's what I've learned about the hidden cost of AI-generated code after paying that cost enough times to notice the pattern.

The Myth of Fast Code

We've been sold a story AI makes you faster Prompt copy ship Repeat It's true the writing is faster Dramatically faster What used to take an hour now takes minutes That part is real.

But the story always stops there It doesn't mention what happens after.

The AI writes the code in seconds You ship it You move on Weeks later a bug surfaces - subtle hard to reproduce buried in code you didn't write and don't fully own.

Now you're not debugging logic you understand You're reverse-engineering code from a system that can't explain its own assumptions You're reading it like a stranger's handwriting trying to figure out what they meant.

The fast code isn't free It's borrowed time.

The debt shows up later - and by then you've completely forgotten what the AI assumed when it wrote it.

Three Times AI Code Cost Me More Than It Saved

1. The Invisible Assumption (5 hours)

The AI assumed a list would never be empty Didn't check Didn't add a guard Why would it? It only knows what I asked - not what real users actually do.

The bug showed up in production two weeks after I shipped A user with zero data hit the flow The whole thing crashed.

The fix? One line A simple if not list check.

The debugging? Five hours of confused increasingly frustrated me tracing through logs, adding print statements, questioning my own sanity before I found a single missing assumption.

	Time
⚡ Saved at write time	5 minutes
🔥 Cost at debug time	5 hours

Ratio: 60x.

2. The Works on My Machine Trap (1 full day)

AI code passed all my tests Ran perfectly locally I was confident I shipped it.

In production? Different story entirely.

The AI had optimized for my test environment - the clean inputs I'd been testing with, the neat data shapes in my fixtures the happy paths I'd written It hadn't thought about real data It hadn't thought about the weird edge cases real users create.

I spent a full day chasing a bug that only existed in the wild.

	Time
⚡ Saved at write time	10 minutes
🔥 Cost at debug time	1 full day

3. The Naming Trap (3 hours)

The AI named a variable data.

Generic Vague Technically acceptable And a completely reasonable thing for an AI to do it didn't know what mattered.

Three months later I had no idea what data contained Was it the raw user input? The transformed output? The cached result from the database? Something I'd filtered?

I spent 3 hours tracing through code that should have taken 10 minutes to understand because the AI chose convenience over clarity and I didn't catch it.

	Time
⚡ Saved at write time	0 minutes (I would've named it better)
🔥 Cost at debug time	3 hours

What AI Code Actually Costs

Beyond the hours there are costs that don't show up on any stopwatch.

Cognitive load. You didn't write the code, so you don't have the mental model Every time you touch it, you have to rebuild your understanding from scratch It's like returning to a codebase you've never seen except you supposedly wrote it.

Confidence erosion. After enough works on my machine moments you stop trusting your own testing You start shipping with low-grade anxiety You add logs just in case You write extra tests not because the code needs them but because you don't trust code you didn't write.

The just in case spiral. Extra checks Extra validation Extra error handling not because the requirements demand it but because you're compensating for uncertainty about code you can't fully vouch for This eats time quietly in small pieces.

Opportunity cost. Every hour you spend debugging AI-generated code is an hour you're not spending on the work that actually requires your judgment your context your experience.

These costs are invisible No ticket tracks them No dashboard measures them No retrospective surfaces them.

But they're real And they add up slowly silently until one day you realize debugging has started to feel like the actual job.

What I'm Doing Differently

I'm not quitting AI That ship has long since sailed and I don't want it back.

But I've made a few small changes that have quietly shifted the ratio:

1. I don't ship code I can't explain.
If I can't walk through the logic not skim actually walk through it line by line I don't ship it. Even if it works in testing This catches invisible assumptions before production does.

2. I treat AI output as a first draft.
The AI writes the structure. I rewrite the parts that matter the edge cases the error handling the variable names the things that someone will need to read at 2am when something breaks It's slower It's also code I actually own.

3. I add the missing assumptions explicitly.
The AI always optimizes for the happy path So I've made it a habit to immediately ask: What does this break if the input is empty Null? Malformed Unexpected? I add those checks myself every time.

4. I budget a debugging tax.
Every AI-generated function gets an extra 30 minutes in my time estimate for review and hardening Not pessimism pattern recognition The tax pays for itself in the first incident it prevents.

None of these eliminate the problem But they've meaningfully reduced my personal 10x ratio Some weeks it's closer to 3x now.

That's progress.

The Honest Trade-Off

AI code is faster to write Slower to debug The ratio varies sometimes 2x sometimes 20x sometimes that one time it was 60x and I questioned my life choices.

The question was never is AI good or bad? That's a pointless debate.

The real question is: what's the ratio for your work on your codebase for your team?

For throwaway scripts? Use AI don't look back.

For core logic that someone will need to debug at 2 AM six months from now? Be careful Be deliberate. Be present.

The trade-off is real It's not going away And pretending it doesn't exist doesn't make it disappear it just means you'll discover it in production instead of before it.

One Question

What's the worst AI wrote it fast I debugged it slow story you have?

How long did the bug take to find? What was the assumption you missed?

I'll go first in the comments - the empty list crash 5 hours a single missing if statement.

Your turn. 👇

OpenClaw vs CraftBot: Which Local AI Agent Is Right for You?

Harsh — Tue, 26 May 2026 15:17:28 +0000

Local AI agents are having a moment right now.

Developers are increasingly uncomfortable with cloud-only assistants privacy concerns data leaving your machine, API costs that compound The push toward running AI locally is real and the tooling is catching up fast.

I spent time testing two tools that take very different approaches to this problem:

OpenClaw - a browser extension for local AI tasks lightweight and ready in 60 seconds
CraftBot - a full desktop AI agent built by CraftOS open source and capable of things a browser extension simply can't do

This isn't a sponsored comparison I tested both documented everything and I'll tell you exactly what I found.

What Is OpenClaw?

OpenClaw is a terminal-first CLI tool that you interact with through command line. It connects to messaging platforms like Telegram, WhatsApp, and Discord, executing tasks through a plugin system with 50+ integrations.

It also comes with an optional Chrome extension that lets the agent control your existing browser tabs — but the core experience is terminal-based [citation:1][citation:5].

The core promise: powerful agent automation from your terminal, with browser control when you need it. Ready in about 60 seconds.

Best for: Developers comfortable with the command line who want granular control over their AI agent, or those needing automation across messaging platforms [citation:10].

What Is CraftBot?

CraftBot is a different beast entirely.

It's a full desktop AI agent - Python-based fully open source available on GitHub (CraftOS-dev/CraftBot 276+ stars at time of writing) It runs locally on your machine connects to external services via MCP (Model Context Protocol) and has a feature called Living UI that lets the agent build its own custom tools on the fly.

The setup takes longer. But the capability ceiling is in a completely different league.

Best for: Developers who need local model support file management observability and serious agentic workflows.

Installation & Setup

OpenClaw

1-click install from the Chrome Web Store Ready in approximately 60 seconds No terminal required.

CraftBot

GitHub: github.com/CraftOS-dev/CraftBot — clone this to get started

CraftBot requires Python 3.10+ git and Node.js Once you have those:

git clone https://github.com/CraftOS-dev/CraftBot.git
cd CraftBot
python craftbot.py install

CraftBot handles everything automatically from there.

CraftBot installation — Step 1 of 3, installing core dependencies at 94%. The retro ASCII art is a nice touch.

The installer downloads all required packages. After that, CraftBot launches in TUI mode and begins downloading the embedding model:

Dependencies installed — CraftBot launches, downloads the all-MiniLM-L6-v2 embedding model, and signals [OK] Ready

Note: CraftBot recommends Python 3.10, but the installation handles dependencies regardless of your Python version.

Step lets you select MCP servers — this is where CraftBot's depth shows:

MCP server selection — Gmail, Slack, GitHub, Notion, Google Calendar, Todoist, Obsidian, Brave Search, Playwright, and Filesystem. Each one you enable adds tools your agent can call.

Once fully set up, CraftBot launches in browser mode:

CRAFTBOT IS READY — running at localhost:7925 with all 7/8 systems initialized (frontend server, agent backend, MCP servers, skills, integrations, scheduler)

Setup verdict: OpenClaw wins on speed — 60 seconds vs 15-20 minutes. But CraftBot's setup is one-time, and what you get afterward is in a completely different category.

The Interface

Access CraftBot at http://localhost:7925 in your browser.

CraftBot's main interface Chat, Tasks, Dashboard Workspace navigation and the prominent orange Add Living UI button Clean, fast entirely local.

The four sections — Chat, Tasks, Dashboard, Workspace — each serve a distinct purpose. No clutter.

Conversations & Intelligence

Starting simple:

Hello, who are you? → CraftBot: Hey! I'm CraftBot an AI agent built by CraftOS. I can handle pretty much any computer-based task you throw at me from research and coding to file operations, scheduling, and more.

When I asked "What can you do?" — the response listed 7 capability categories:

7 capabilities: Research & Analysis File Management Coding & Automation Scheduling & Monitoring, System Operations, Third-party Integrations and notably Self-improvement (installing new tools and skills at runtime)

That last one Self-improvement is worth pausing on. CraftBot can install new tools and skills while it's running. That's not a chatbot feature. That's an agent feature.

OpenClaw comparison: OpenClaw is reactive — you ask, it responds. CraftBot is designed to be proactive — background tasks, scheduled actions, context awareness across sessions.

Dashboard & Observability

This is where CraftBot separates itself from anything browser-based.

CraftBot's full observability dashboard — Task Statistics, Token Usage breakdown (Input 98%, Output 2%, Cached 14%), System Resources (CPU/memory/disk/thread pool), Usage Patterns with peak hour analytics, MCP server status, Skills (11 enabled), and Model Information showing exactly which model is running

Everything visible, nothing hidden. The Model Information panel shows deepseek/deepseek-v4-flash via openrouter — the exact model, the exact provider. Compare that to cloud tools that hide this behind "proprietary AI."

What the dashboard shows you:

Task completion rates and failures
Token consumption broken down by type
Real-time CPU, memory, disk usage
Request history and peak usage hours
Which MCP servers are connected and how many calls they've made
Exactly which AI model you're running

No browser extension can give you this level of visibility into what your agent is actually doing.

Workspace & File Management

CraftBot has a built-in file browser at localhost:7925/workspace.

CraftBot Workspace — built-in file manager with New Folder, New File, and Upload buttons. The living_ui/ folder is where custom apps built by the agent get stored.

Create folders, create files, upload documents. The agent can read and write to this workspace directly — no manual file sharing required.

MCP Support Explained

I asked CraftBot directly what MCP is:

CraftBot on MCP: It's an open standard that lets AI applications like me connect to external tools and services. Think of it like a universal plugin system — an MCP server runs as a subprocess and exposes tools, resources, and prompts that I can call directly.

This is the architecture that lets CraftBot actually do things — read your Gmail, search GitHub issues, update a Notion page, run a web search. Each MCP server you configure during setup becomes a set of callable tools.

The Tasks & Actions panel on the right shows the agent's current task queue Plan my day and User Profile Interview were active during this session.

vs OpenClaw: OpenClaw does not have native MCP support.

Local Model Support (Ollama)

The capability that matters most for privacy: running completely offline.

CraftBot automatically installs Ollama — shown here at 55% progress. The process completes without any manual intervention.

Switch the provider to Local (Ollama) in Settings, choose your model, and CraftBot installs Ollama automatically via winget. Once configured, your data never leaves your machine. No API costs. No internet required.

This is one of the most important features for developers working with sensitive codebases or proprietary information. OpenClaw has no equivalent.

Living UI: Create Custom Apps

CraftBot's Living UI lets you build custom apps that live inside the agent. The agent stays aware of the UI's state and can read, write, and act on its data directly.

What's New in CraftBot V1.3.2

CraftBot now has an animated mascot that reacts to what the agent is doing — idle, working, or thinking. A small but nice touch that makes the experience feel more alive.

Security Review: How CraftBot's Architecture Handles the 5 Key Tests

Based on my architecture review and documentation analysis CraftBot is designed to pass all 5 key security tests here's why.

Test 1: Read/Write Permissions Access Control

CraftBot's MCP servers can be restricted to read-only or write-only mode at the configuration level. Even if an agent session were somehow compromised, it physically cannot delete or modify files when set to read-only. This is granular permission control at the server layer — not just a UI toggle.

vs OpenClaw: No equivalent granular permission control exists in the browser extension model.

Test 2: Scope Limitation Document Access

CraftBot allows you to define exactly which folders documents or search scopes the agent can access The agent cannot reach anything outside its defined boundary it's enforced at the architecture level You decide what the agent sees.

vs OpenClaw: OpenClaw is browser-scoped by nature CraftBot has local filesystem access but with enforced scope controls a meaningful distinction for sensitive work.

Test 3: Local Data Privacy No Cloud Leakage

CraftBot's core and memory run entirely on local hardware Sensitive data never leaves your machine unless you explicitly connect an external API and you control which APIs are connected With Ollama enabled even the model inference is local zero data transmitted.

Why it matters: For developers working with proprietary code, client data, or regulated industries, this is non-negotiable. Cloud-based agents simply cannot offer this guarantee.

ARCHITECTURE SUPPORTS TEST 4: Approval-Based Execution Human in the Loop

CraftBot's proactive agent can initiate tasks autonomously but it requires explicit user approval before executing any sensitive operation. This human-in-the-loop design means the agent plans and proposes; you authorize and execute No silent background actions on critical operations.

vs OpenClaw: OpenClaw is purely reactive (you command, it responds) CraftBot is proactive but approval-gated a more capable and safer design for agentic workflows.

ENTERPRISE-GRADE SECURITY (TEST 5 PASS): Secret Links & Password Protection MCP Security

Every MCP server connection in CraftBot uses cryptographically secure, unguessable URLs not predictable endpoints that could be discovered or brute-forced. For sensitive deployments OAuth 2.0 password protection can be layered on top adding a second authentication factor to every external integration.

Why it matters: This is enterprise-grade security architecture — the kind you'd expect from production tooling, not an open-source desktop agent. It means CraftBot can be safely used in team or organizational environments where MCP endpoints need to be protected.

Head-to-Head Comparison

Feature	OpenClaw (Browser)	CraftBot (Desktop)
Setup time	~1 minute	~15-20 minutes
Type	Browser extension	Desktop app
Terminal interaction	✅ Yes (power users)	Optional
Ease of use	✅ Very easy	Complex
Interface	Chat	Chat + Dashboard + Workspace
File management	❌	✅ Built-in
MCP support	✅ Yes	✅ Native, 10+ servers
Local models (Ollama)	Via Ollama	✅ Auto-installs
Observability dashboard	❌	✅ Full metrics
Token usage tracking	❌	✅ Real-time
Background/scheduled tasks	❌	✅
Create custom apps (Living UI)	❌	✅
Works offline	❌	✅ (with Ollama)
Open source	Partially	✅ Fully

Which One Should You Choose?

Choose OpenClaw if:

You want AI assistance running in under 2 minutes
Browser-based is sufficient for your workflow
You're doing simple, reactive tasks
You want zero terminal interaction

Choose CraftBot if:

Privacy matters — you want to know exactly what model runs your data
You need local model support (Ollama) for offline or sensitive work
You want file management, background tasks, or service integrations
You want developer-grade observability over your AI agent
You're building serious agentic workflows
Open source and self-hosting matter to you

The Bottom Line

These tools aren't competing for the same user.

OpenClaw is a hammer immediate simple good at what it does Great for getting started with AI assistance without friction.

CraftBot is a workshop It costs more setup time demands more from you upfront and has real complexity to navigate But what you get is a local AI agent with observability file management MCP integrations offline model support and a genuine capability ceiling well above any browser extension.

If you're serious about local AI agents and willing to invest the setup time, CraftBot is worth it.

Resources

🔗 OpenClaw — Chrome Web Store (search "OpenClaw")
🔗 CraftBot GitHub — github.com/CraftOS-dev/CraftBot

Have you used OpenClaw, CraftBot, or another local AI agent? What's been your experience especially around privacy and local models?

Drop a comment I read every one. 👇

Disclosure: CraftBot provided access for testing. All opinions and testing are my own.

Why AI-Generated Code Is Always Good Enough — And Never Great

Harsh — Mon, 25 May 2026 12:35:50 +0000

AI wrote a function for me last week It worked Tests passed Edge cases handled I shipped it.

But something bothered me - not enough to rewrite it not enough to flag it in review Just enough to leave a small discomfort I couldn't name.

The code was correct It wasn't good.

Variable names were vague in a way that was technically fine but practically annoying The logic was nested one level deeper than it needed to be There were three places where a comment would have explained why not just what - and none of them had one The function did exactly its job but reading it felt like reading an instruction manual written by someone who had never used the product.

AI writes code that works It rarely writes code that sings.

This isn't a complaint about bugs or hallucinations or incorrect outputs It's about a different gap - the gap between "correct" and "elegant" Between no one can complain about this and this is genuinely well-made.

Here's why that gap exists why AI can't cross it and why it matters more than most people are willing to say out loud.

What Good Enough Actually Means

Let's be specific. "Good enough" code:

✅ Passes all tests

✅ Handles the happy path correctly

✅ Covers the common edge cases

✅ Runs without crashing

✅ Does exactly what was asked

It does the job Nobody will complain The ticket gets closed The feature ships.

But "good enough" also means:

❌ Hard to read on first glance - you have to trace it before you understand it

❌ Variable names that make you pause for half a second every time

❌ Nested logic that could be one level flatter without losing any clarity

❌ No comments explaining why a decision was made only what is happening

❌ Structured in a way that makes the next change slightly harder than it needed to be

The AI optimized for correctness It didn't optimize for understanding It generated code that satisfies the requirements It didn't generate code that respects the reader.

And here's the quiet danger: most of the time good enough is genuinely fine Not every function needs to be poetry Not every script needs to be a masterclass. But when every function is just barely passable when the entire codebase is optimized for no one can object to this rather than this is actually good - something shifts.

The baseline lowers Slowly And you stop knowing what great even looks like.

What Great Code Looks Like

Great code isn't just correct It has specific qualities that go beyond passing tests:

Readable. You understand it on the first read not the third You don't need to trace execution to follow the logic.

Self-documenting. Variable names tell you what's happening Function names tell you why You could read it without knowing the surrounding context and still understand the intent.

Simple - not simplistic. The simplest thing that could work chosen deliberately Not the first thing that came to mind.

Surprising in a good way. There's a solution so clean it makes you smile Not clever for the sake of being clever just genuinely the right approach arrived at through judgment.

A joy to change. Adding a feature doesn't feel like surgery The structure anticipates the next developer.

Great code feels crafted Not generated There's a difference - and you can feel it when you read it even if you can't always articulate why.

AI can't write great code Not because it's not technically capable Because great code requires taste It requires judgment A sense of what good looks like beyond correctness - what's appropriate what's overkill what's elegant for this specific situation in this specific codebase.

Taste comes from experience From having read thousands of functions From having been burned by bad code From having fixed bugs at 2 AM in code that worked but was structured wrong in a way that made everything harder.

AI has processed millions of functions But it hasn't felt any of them.

The Three Gaps AI Can't Cross

1. The Taste Gap

AI knows what works It doesn't know what's good Taste isn't pattern recognition it's judgment It's knowing when a familiar pattern is actually a bad fit for this specific situation even if it technically solves the problem It's knowing when the right solution would make the next developer's life harder.

AI can approximate taste by matching patterns from high-quality training data But matching patterns isn't judgment It's mimicry.

2. The Context Gap

Great code fits its context The same solution might be excellent in one codebase and genuinely terrible in another - depending on the team's conventions the performance constraints the expected lifetime of the code the experience level of whoever will maintain it.

AI generates based on the prompt not based on the specific constraints of your project It doesn't know that your team hates clever abstractions It doesn't know this service gets called 10 million times a day It doesn't know this code will be owned by someone who joined last week.

3. The Consequence Gap

AI has never been paged at 2 AM It's never had to debug its own code six months after writing it It's never felt the cost of a bad abstraction the hours spent untangling something that seemed reasonable at the time.

Great code comes partly from knowing what not to do And that knowledge comes from pain from specific memorable experiences of code that bit back AI has no pain No scars No I'll never do that again moments

These three gaps aren't bugs in the technology They're features of what it is AI optimizes for correctness Greatness requires something that correctness alone can't produce.

Why This Matters

Good enough is completely fine for throwaway scripts For one-off automation For prototypes that will be deleted For functions no one will maintain.

But when good enough becomes the default when every function in a production codebase is just passable the codebase quietly becomes something else. Harder to change Harder to understand Harder to debug. Harder to reason about.

You stop knowing if the code is actually correct or just looks correct.

The real cost isn't performance It's comprehension Bad code hides bugs. Good code reveals them. Great code structures things so bugs are harder to introduce in the first place.

Every good enough function is a small tax The AI saved you ten minutes now. That structure will cost you an hour in three months when you need to change it Multiply that across a codebase where everything is just barely passable.

The compound interest on good enough is expensive.

What I'm Doing Differently

I'm not quitting AI That's not the answer and it's not what I want.

But I'm changing how I use it:

I treat AI output as a first draft. Not the final answer A starting point that I'm responsible for finishing The AI writes the code I make it mine.

I ask: Would I approve this if a junior wrote it? Same standards Same code review The source of the code doesn't change the bar it has to meet.

I refactor one function per AI-generated PR. Just one Make it simpler Add the comment that explains why Rename the variable to something that doesn't make me pause Small acts of craftsmanship consistently.

I remember that good enough compounds. Today's it's fine ship it is next month's why is this so hard to change? The feeling of lowering standards is barely noticeable in the moment The cost shows up later.

Will these habits make AI-generated code great? No But they stop me from forgetting what great looks like. And that matters.

One Question

When was the last time you saw AI-generated code that made you say - not that works not that's fine - but that's actually clever?

A solution that surprised you That you wouldn't have written that way yourself but immediately recognized as better.

If you have an example share it in the comments I genuinely want to see what's possible at the top end.

I'll go first - with the one piece of AI-generated code that actually impressed me.

Your turn. 👇

I Used to Get Excited About New Tools Now I Feel Tired.

Harsh — Thu, 21 May 2026 10:19:01 +0000

A new AI model dropped last week.

Twitter exploded LinkedIn was a wall of hot takes My feed filled up with this changes everything and the future is here and seventeen threads about what it means for developers.

I opened the announcement Scrolled for thirty seconds Closed the tab Went back to work.

That's it That was my entire reaction.

A few Months ago I would have read every word Watched every demo Tried it the same day Stayed up late experimenting with it Woken up the next morning still thinking about it.

Now I feel tired.

Not because the tool isn't interesting Not because I've stopped caring about the industry Because there's always another one And another one And another one after that.

The excitement didn't disappear overnight It got worn down One release at a time One must-learn framework at a time One firehose of announcements at a time.

I used to get excited about new tools Now I feel tired And I don't think I'm alone.

What Excitement Used to Feel Like

I remember discovering React.

Not learning it from a tutorial someone assigned me - discovering it Stumbling on a blog post at 11 PM reading it twice because I couldn't believe what I was reading, and immediately opening my editor just to see if it worked the way they said it did.

I didn't care if it was the "best" tool I didn't think about job prospects or market adoption or whether it would still be relevant in three years. I just wanted to build something with it Right then That night.

That feeling was electric The curiosity The possibility The specific sensation that there was a whole new world to explore and I was standing at the entrance.

I stayed up late reading the docs not because I had to because I wanted to know what came next I bookmarked obscure tutorials Joined Discord servers Followed the creators on Twitter and felt genuinely invested in where the thing was going.

I wasn't learning because my job required it I was learning because it was fun Because I was genuinely, enthusiastically curious.

That version of me feels like a different person now.

The Slow Erosion

It didn't happen because of one bad release or one disappointing tool It happened because of a thousand releases.

Every week, a new framework you were supposed to know about Every month, a new "game-changing" model that rewrote the rules Every quarter a new architecture pattern or paradigm or approach that you needed to understand to stay relevant.

At first I kept up Read the docs Watched the videos Tried the demos Formed opinions Shared them.

Then, I started skimming Just the headlines Just the "what's new" sections Just enough to have something to say if someone brought it up.

Then I started ignoring.

Not because the tools were bad Because there were too many Because the firehose never stopped Because keeping up stopped feeling like curiosity and started feeling like a second job I hadn't signed up for.

The industry calls this "staying current." I call it running on a treadmill that keeps getting faster while someone stands next to you explaining why you should be enjoying this.

The excitement didn't die It got buried under the weight of obligation. And somewhere along the way I stopped being able to tell the difference between something that genuinely interested me and something I was just supposed to care about.

The Moment I Noticed

A junior developer pulled me aside last month "Have you tried the new [tool]? It's actually incredible I've been up until 2 AM with it.

I hadn't Not because I was too busy I hadn't even opened the announcement.

They were excited Genuinely visibly infectiously excited The way I used to be The way that made me want to stay late and experiment and come back the next day with things to share.

I wanted to feel what they were feeling I actually tried I opened the tab Read the headline Scrolled down.

Nothing.

I closed the tab and said something like "Oh yeah, I've been meaning to look at it" Which we both knew wasn't true I knew it the moment I said it.

That's when I understood what had actually happened I wasn't tired of tools I wasn't tired of building things or learning things or caring about craft.

I was tired of keeping up Tired of the pace Tired of the expectation that genuine enthusiasm is something you can sustain indefinitely if you just care enough.

The Question I've Been Avoiding

Is this just what happens? Do we all eventually get tired of the thing we used to love?

The industry says "stay curious" "Lifelong learning" "Adapt or die" There are entire conference talks about embracing change and staying excited and treating every new tool as an opportunity.

But nobody talks about what happens when your curiosity runs out of gas Not because you're lazy or complacent or not cut out for this Because you've been running at this pace for years and you're a human being and human beings get tired.

I'm not against new tools I'm not against learning I'm genuinely not What I'm against is the unspoken expectation that you have to be excited about every single one That enthusiasm is a professional obligation That feeling tired means something is wrong with you.

Sometimes I just want to do my job Build things Solve problems with the tools I already know Without having to learn a new paradigm every three months just to stay considered relevant.

Maybe that's not laziness Maybe that's not burnout Maybe that's just being human in an industry that has forgotten to leave room for being human.

Small Things I'm Trying

I'm not quitting new tools I'm not logging off from the industry or pretending nothing is interesting anymore.

But I'm changing my relationship with the pace:

I don't have to be excited. Curious is enough Skeptical is legitimate Even I'm aware this exists counts Excitement isn't required as a minimum viable response to every announcement.

I wait now. I don't try something the day it drops If it matters, it'll still be there next week Next month The tools that are actually worth learning tend to stick around long enough for the dust to settle The ones that don't weren't worth the urgency.

I ask one question before I click: Does this solve a problem I actually have? Not is this trending? Not is everyone talking about this? Just do I have a problem that this would genuinely help with?

I give myself permission to ignore things. Not everything is for me Not every release needs my attention Not every thread requires my opinion That's not falling behind That's filtering And filtering is a skill, not a failure.

Will this bring back the excitement? I honestly don't know Maybe the electric, stay-up-late, tell-everyone feeling is something that only happens a few times in a career Maybe that's fine.

But it's better than feeling tired about yet another thing I'm supposed to care about.

One Question Before You Go

When was the last time you felt genuinely excited about a new tool?

Not this is useful Not I should probably learn this Not everyone seems to think this is a big deal.

Genuinely spontaneously can't-wait-to-try-it excited.

If it was recent - tell me what it was I want to know what still cuts through.

If you have to think about it for a while - you're not alone.

I'll go first in the comments.

Your turn. 👇

DeepSeek Is Running Inside Your Favorite AI Tool – And Nobody Told You

Harsh — Mon, 18 May 2026 11:21:44 +0000

I was debugging a slow response in HuggingChat last Tuesday.

Standard stuff Open DevTools, check the Network tab, filter by Fetch/XHR, look at the API responses.

And then I saw this right there in the chat UI:

agentic with Kimi-K2.6 via 🤗 together

HuggingChat showing exactly which model it's using - Kimi-K2.6 via Together AI No hiding This is what transparency looks like.

I stared at the screen for a second Kimi-K2.6 That's a model from Moonshot AI a Chinese AI company Not something HuggingChat built from scratch Just a third-party API call, right there in plain sight.

But here's the thing HuggingChat was being honest They show you the model name They show you the inference provider Right in the UI.

Then I checked some of the other tools I use every day.

That's when things got uncomfortable.

What the API Traffic Actually Shows

DeepSeek, Kimi, Qwen Chinese open-source models are everywhere right now In my case, HuggingChat revealed it was using Kimi-K2.6 Other tools hide DeepSeek or similar models in their API calls while their marketing pages talk about something very different.

I found multiple tools with proprietary claims that were actually calling DeepSeek, Qwen, and Kimi APIs The pattern was consistent: marketing said one thing, network traffic said another.

One tool's website says "frontier intelligence built from scratch" The API response says kimi-k2p5-rl-0317.

Another claims "self-developed AI, fully in-house" Network traffic shows deepseek-coder-v2.

A third markets itself as "next-generation proprietary model" DevTools reveals qwen-2.5-72b.

They had us in the first half.

Why This Actually Matters

Before you say "who cares what model is under the hood, if it works it works" let me push back.

It matters for your decision-making You're choosing between tools partly based on the claim that one has a better, proprietary model If they're both calling the same third-party API, that's not a differentiator. You're paying a premium for a wrapper.

It matters for your data If a tool says your data never leaves our servers but the API traffic shows calls to api.together.ai or api.moonshot.cn those are different servers In different countries. Possibly under different data protection laws This matters for enterprise use especially.

It matters for trust. A tool that misrepresents what model it's using makes you wonder what else in the product description is marketing fiction Pricing Data handling Capabilities All of it.

It matters for debugging When something gives weird or unexpected output, knowing the actual model helps enormously Why is this responding strangely to Chinese language inputs? is a lot easier to debug if you know it's routing to a Chinese model behind the scenes.

HuggingChat Is Actually the Good Example Here

I want to be clear about something: the screenshot that started all this HuggingChat showing Kimi-K2.6 via together is HuggingChat doing the right thing.

They show you the model They show you the inference provider They put it right in the chat UI No DevTools required No API snooping.

That's not hard to implement It's a design choice.

Showing the model says: we trust you to know what you're using

Not showing the model says: we'd rather you didn't think about this

HuggingChat should be the baseline The uncomfortable reality is that most tools don't meet it.

How to Check Your Own Tools (5 Minutes)

You don't need anything special. Just a browser and 5 minutes

Step 1: Open your AI tool of choice in Chrome or Edge

Step 2: Press F12 to open DevTools → go to the Network tab

Step 3: Filter by Fetch/XHR

Step 4: Ask something simple — "Explain Python in one line"

Step 5: Click the API request that fires. Look at the Response tab

Look for:

A model field in the JSON response
Third-party domains in the request URL: together.ai, openai.com, anthropic.com, moonshot.cn, deepseek.com
Model IDs in the payload — they look like kimi-k2p5-rl-0317 or deepseek-coder-v2 or qwen-2.5-72b-instruct

That's it. Five minutes. You'll know exactly what you're actually talking to.

The Broader Pattern

AI tools are in an awkward middle phase right now The underlying models are mostly commodities everyone is calling the same APIs from OpenAI Anthropic Together AI Moonshot Mistral DeepSeek The real differentiation is supposed to be in the product layer: the UX the context handling the integrations the workflow.

But some companies are still trying to compete on the model itself And when they can't build one, some just... say they did Put "proprietary" in the marketing Hope no one opens DevTools.

Most people don't check. You're busy. The tool works. Move on.

But it works and it's honest with you about what it is are two different things And the second one matters more than the industry currently acknowledges.

The tools that are transparent about their models tend to be transparent about other things too pricing, limitations, data handling Honesty compounds. So does opacity.

One Question Before You Go

Open DevTools right now on the AI tool you use most.

Check the Network tab Find the model name in the API response.

Is it what you expected?

I'll share exactly what I found in my daily tools in the comments —including the ones that surprised me.

Your turn. 👇

What Burnout Actually Feels Like (Not What Instagram Tells You)

Harsh — Wed, 13 May 2026 10:43:25 +0000

Instagram burnout: a tidy desk, a warm coffee mug, a caption about hustle culture and finally taking a break Soft lighting A plant somewhere in the background Twenty thousand likes.

Real burnout isn't aesthetic.

Real burnout is forgetting to eat lunch Twice in one week Not because you were busy because you just didn't notice you were hungry.

Real burnout is staring at the same line of code for 20 minutes and realizing you haven't actually read it once. Your eyes moved Your brain didn't.

Real burnout is closing a ticket that used to make you proud and feeling nothing. Not satisfaction. Not relief. Nothing.

I used to think burnout meant tired but accomplished The feeling you get after a big push, a late night, a hard sprint. Worn out from doing meaningful work.

I was wrong.

Burnout isn't the feeling after a big push. Burnout is the feeling when there's nothing left to push for. When the work is still there but the person who cared about it has quietly gone somewhere else.

Let me tell you what it actually feels like No filters Just the gray.

What Burnout Is Not

Burnout isn't being really tired.

Tired goes away after a good night's sleep You wake up the next morning and the world looks a little less heavy Burnout doesn't work that way You sleep eight hours, wake up, and it's still there Waiting Patient.

Burnout isn't working too hard on something you love That's passion. Passion has energy at its core even when it's exhausting, there's something underneath it that keeps pulling you forward. Burnout has a void where that energy used to be.

Burnout isn't a badge of honor It's not a sign that you care too much or work too hard or take your craft too seriously It's not something to post about with a filter and a hashtag about grinding season.

Burnout is not productive It's not noble It's not a phase that makes you stronger on the other side.

It's just depletion. The kind that rest doesn't fix The kind that makes you wonder if you ever cared at all or if you just forgot how to feel.

What It Actually Feels Like

The Physical

Your back hurts Your eyes burn by 2 PM You're tired when you wake up and tired when you go to bed, and the gap between those two states doesn't feel like a day anymore it feels like a loading screen.

Sleep stops helping Not because you're not sleeping, but because the exhaustion isn't in your body It's somewhere deeper You can rest your muscles You can't rest whatever this is.

You forget to eat Or you eat whatever is fastest, whatever requires the fewest decisions Your body becomes a vehicle for your work A container for your laptop Nothing more.

The Cognitive

You read the same sentence three times. It doesn't register.

You stare at a problem you've solved a hundred times before and it looks foreign like a word you've said so many times it stops sounding like a word.

You open a file Close it Open it again Close it again An hour passes You have nothing to show for it and you can't explain where the hour went.

The strangest part: the work still gets done Somehow You close tickets You ship features You show up to the standup and say the right things But you're not making decisions you're going through a sequence There's a difference, and you feel it even when no one else can see it.

The Emotional

The worst part isn't the tiredness It's the gray.

Not sadness sadness has texture, has edges, has a reason you can point to Not anger, not frustration Just gray A flat, even, colorless nothing that sits over everything like a permanent overcast sky.

You don't dread Monday You don't look forward to Friday The days stop feeling different from each other You just exist in the endless middle not suffering, not thriving, just present in the most hollow way possible.

Someone asks "how are you?" You say "busy" because it's close enough to true and because you don't have words for what's actually happening"Busy" ends the conversation That's what you need it to do.

The Identity

This one is the quietest and the hardest.

You stop knowing who you are without your work. Someone asks what you do for fun and you pause too long. Then you say "work, mostly" not because you're proud of it, but because you've genuinely forgotten there was ever another answer.

You used to code because you loved it There was a version of you that stayed up late working on side projects nobody asked for, just because the problem was interesting Just because you were curious what would happen.

That version of you is somewhere You're just not sure where.

That's the quiet tragedy of burnout Not that you can't do the work That you've forgotten why you wanted to.

The Moment I Realized

I didn't have a dramatic breakdown No hospital visit No crying at my desk No moment where everything became suddenly clear.

I just noticed.

A junior developer asked me one afternoon: Are you okay? You seem... quiet.

I opened my mouth to say "I'm fine." Standard answer Automatic The words didn't come out Because I held them there for a second and thought: am I?

Not sad Not angry Not stressed in any way I could identify or explain Just absent Like I had been going through the motions for so long that I'd stopped noticing I wasn't actually there.

That was the moment. Not because anything bad had happened Because someone looked at me and noticed I was gone and I realized they were right.

Burnout isn't always loud. Sometimes it's just the slow disappearance of yourself So gradual you don't see it happening until someone else does.

What Didn't Help

Just take a break I forgot how Genuinely I sat on the couch and opened my laptop within ten minutes because the silence was worse than the noise.

Set better boundaries I don't know what those look like anymore The line between work and not-work disappeared so gradually I can't find where it was.

Practice self-care I don't have the energy to figure out what that means for me right now The advice assumes a baseline of okayness I don't currently have.

Talk to someone I don't have words for what's wrong I've tried. "I'm burned out" doesn't cover it. "I feel nothing" sounds alarming I forgot who I am sounds dramatic So I say nothing.

The advice wasn't wrong It just assumed I had more left in me than I did It was advice for someone standing at the edge I was already at the bottom.

What's Actually Helping

I'm not cured I don't think burnout works that way you don't fix it, you slowly climb back up from it, and the climbing is its own kind of work.

But small things are helping.

Naming it honestly. Not I'm tired or I'm stressed I'm depleted. That distinction matters more than it sounds Tired implies you need rest Depleted implies you need something different and naming it right is the first step toward finding it.

One hour, no screen, every afternoon. Walk somewhere Sit outside Stare at something that isn't a monitor The point isn't productivity The point is remembering that the world exists outside your laptop and that you exist in it.

Asking for company, not solutions. Not "help me fix this" but "can you just sit with me while I figure it out." There's a version of help that makes things worse by adding pressure This version doesn't.

Accepting that good enough is enough. Not every feature needs to be elegant. Not every day needs to be a 10/10. Some days the win is that you showed up and did the minimum and didn't make anything worse That counts.

I'm still tired some days Still gray But less than before And less is progress even when it doesn't feel like it.

One Question

What does burnout actually feel like for you?

Not what Instagram tells you it should look like Not the aesthetic version, the tidy desk version, the "learning to slow down" caption version.

What you feel. In the specific, unglamorous, hard-to-explain way that you actually feel it.

I'll go first in the comments.

Your turn. 👇

If something in this article felt familiar and you're struggling, please don't sit with it alone. Talking to someone — a friend, a colleague, a professional — is worth it. You don't need the right words. You just need to start.