essay

Becoming a cracked developer

Cracked is a shipping habit that predates AI, and AI mostly pays out for people who already had it.

August 1, 2026

Tagged: craftapplied aishipping

The word going around is “cracked”. Cracked engineer, cracked developer, the person who does in a weekend what a team quotes as a quarter. Most of the writing about it reads like a casting call: young, obsessive, rebellious, up at 3am, wired into three models at once. That description is useless, because it describes the surface of a person instead of the thing that made them.

I want to argue something less flattering and more usable. Cracked is what a long shipping habit looks like from the outside, and almost everyone I would call cracked built that habit before AI could write a line for them.

Before the models

Before the AI era, the way you got fast was you shipped something every day. Not something good. Something.

My own list is a logbook of that.

ghread is a CLI that writes a GitHub profile README, built because I kept not writing mine. DocShift converts documents on a desktop app because I got tired of uploading private files to a stranger’s server. PeerDrift sends files between two browsers with an encrypted room code and nothing that outlives the session. FastCV rewrites a resume against a specific job description, and FastCV Chat is the conversational version of the same idea. HairMama is a booking product for salons. Tendly is tender tracking. Igala Echoes is language preservation work for a language most models have never seen. Programmify exists to give students practical experience instead of another certificate. Aani is research. DevPassport, pFlow BuilderLab, Space AI Sim, OpenBuildLab, and four npm packages I pulled out of my own build setup: wails-release-kit, web-crypto-room, pwa-install-prompt, app-icon-pipeline.

Look at that list honestly and the pattern is not range. Every one of them started as friction I felt on a Tuesday. The dev tools especially. Nobody asked for an icon pipeline. I published it because I had hand-cropped app icons three times and the fourth time made me angry.

That is the engine. Annoyance, then a repo, then something running by the end of the day. Do that for a few years and you have already made most of the mistakes once, which is the whole reason anyone gets fast.

Pull quote reading cracked is what a long shipping habit looks like from the outside, above a four step loop: annoyance on an ordinary Tuesday, a repo opened the same hour, something running before you go to bed, and scar tissue, the thing people call taste. An arrow loops back from scar tissue to annoyance, labelled repeat for a few years. A footer note reads that AI did not create this loop, it widened the gap between the people who already had one and the people who did not.
The loop, and the only part of it that is hard: doing it again tomorrow.

So who is cracked

The people I have watched earn the label have almost nothing in common temperamentally. The overlap is narrower than the articles suggest.

They compress the distance between noticing a problem and having something running. Not planning it, running it. Ugly counts.

They have a shockingly high tolerance for finishing. Starting is common. The rare part is the last 20 percent, the deploy, the domain, the error state nobody will hit, the README. Most unfinished work is not abandoned out of boredom, it is abandoned right before it becomes real and can be judged.

They debug from the actual system, not from a story about the system. When something breaks they go read the response, the log, the network tab. The slow developer is usually the one reasoning about what the code probably does.

They have taste, which is mostly a memory of things that went wrong. Knowing a config system will eat the project is not intelligence, it is scar tissue.

And they ship to real users, which is the difference between a hobby and a feedback loop. I built FastCV for other people, then used it on my own applications, and only then found out it rewrote too aggressively and produced something that read like a job posting with my name on top. No amount of thinking would have surfaced that.

What it takes

Pick problems you personally have. Every tool on that list survives because I am its first user, so the feedback loop is the same day, not the same quarter.

Keep the scope to one job. None of the four npm packages needed a configuration system, which is most of the reason they were quick to publish. Scope is the main lever on shipping speed and it is the one people refuse to pull.

Finish things in public. The published thing teaches you something the private thing never will, because someone else’s confusion is data you cannot generate alone.

Build the boring layer once. Release scripts, icon generation, install prompts. My rule now is that a package is worth publishing once I have copied it twice.

Read your own systems. The fastest debugging move I know is refusing to guess.

Now the AI part

AI did not create cracked developers. It widened the gap between people who already had a shipping loop and people who did not, and it did it in both directions.

If you have taste and a habit of finishing, a model does the boring middle for you. If you do not, it generates plausible code you cannot evaluate, which feels like speed right up until the first real bug, at which point you are debugging a codebase you never read.

The way I use it, concretely:

Use it where verification is cheap. Scaffolding, migrations, test cases, the tenth variation of a form. You can tell in ten seconds whether the output is right, so wrong output costs nothing.

Do not use it where verification is expensive and you are not qualified to verify. Auth boundaries, money, data model decisions, anything a user’s trust sits on. The cost of a confident wrong answer there is not measured in minutes.

Make it argue with you before it writes. My most useful prompt is not “build this”. I describe the approach I plan to take and ask what breaks. It reviews better than it writes.

Keep reading everything it produces. The moment code enters your repo unread, you have traded a codebase you understand for one you supervise. That trade is how a fast project becomes a slow one.

And keep building things by hand sometimes. The taste that makes AI useful came from writing the bad version yourself. If you skip that, you are outsourcing the exact faculty you need in order to use the tool well.

The honest version

The reason “cracked” reads as a personality trait is that we only see people at the point where the habit has already compounded. The weekend project that looks impossible was made possible by two hundred earlier ones that were not impressive at all.

If you want a starting point, pick the thing that annoyed you this week and have something running before you go to bed. Do it enough times and someone will eventually call you cracked, and you will know it was mostly attendance.

← All writing