What part of engineering can't be replaced?
Looking back, these past two weeks have been denser and more meaningful than all the time I spent building space ocr alone.
I asked six developers to build a demo with the space ocr API. What they brought back came straight out of the problems they deal with in their own work — use cases I hadn't imagined. Getting to see that, and getting to talk with them about it, was probably the most valuable stretch of time in the whole life of this project.
The same budget spent on Google or Meta ads would have been money set on fire. I'm grateful it went here instead.
Then the feedback came. Things that broke while they were wiring it up, behavior that didn't match what they expected, bugs on my side, gaps between the docs and what the API actually does. More than half of it was about the docs.
That part is a little embarrassing to admit: since I started using Claude Code, I've read documentation less carefully, and thought about my own less deeply. Every one of these developers read the docs properly — closely enough to tell me exactly where they were wrong. That surprised me, and it left me with a lot of respect for them.
It also pushed my thinking about AI a bit further. The assumption right now is that agents can do everything, and in a lot of ways that is becoming true. So what is engineering worth? Two weeks of watching people wire this thing up gave me a partial answer, and it wasn't the code. This is probably the arguable part: space ocr is not a product that could exist through vibe coding, and that becomes more true the more advanced it gets. I'm not saying that to sell anything.
Anyway, the docs got a large update out of it. A few people even said the per-field explanations — what each field means, and why it behaves the way it does — were unusually thorough.
Something else I want to write down: the Japanese developers I worked with were exceptional. Serious and courteous, yes, but more than that, they carry an engineer's mindset all the way through. They took a real interest in space ocr from an engineering point of view, and what seemed to be driving them was engineering curiosity, plain and simple — and then they carried that curiosity all the way into something their own work could actually use. Reading back through all their questions and all their feedback, being able to talk with people like this feels like a blessing. Just having met them, and having put space ocr on their radar, would have been worth it on its own.
These are thoughts that have been circling in my head, written down without much order, so there isn't really a conclusion. But space ocr has come a long way in the process. If you're curious, take a look at the landing page or the docs — some of their demos are up there now, and a few more are still on their way.
Replies
Meridian
The irreplaceable part is judgment: understanding what users actually need, noticing when behavior and documentation diverge, and deciding what “correct” means in messy real-world conditions. AI can accelerate implementation, but engineers still have to ask the right questions and take responsibility for the result.
The part your six developers showed you is the one I would name: reading to the end and noticing where the text and the behavior disagree.
I have checked 500+ coding assessments and sat in 200+ interviews, and the split was rarely about the code. It was whether the person read the task statement carefully enough to spot the sentence that changed the answer. Most did not. The ones who did were the ones you wanted on the team. Now the code part is uniform, so that reading is close to the whole signal.
One thing I would separate from AI, though. More than half the feedback being about docs is what happens to any doc with one reader. You wrote it, so your brain fills the gaps. The first outside reader finds them. Claude Code did not make you read worse, it just meant nobody else had read it until those six people did. Hand the docs to a stranger before the API, and you get the same update a week earlier.
By the way, the Japanese devs detail sounds true. Curiosity that goes all the way into something they can use at work is rare in any country
Both answers here land on judgment and careful reading, and I agree with both, but I would make it narrower. The part that cannot be replaced is whatever shows up the first time the product touches a real customer. Not the design doc, not the code review, not the test suite. The first install.
Five things broke on our first paid setup. Three I can describe cleanly:
The customer refused to hand over the domain. Our whole provisioning model assumed a transfer, because that made certificates and routing trivial for us. He had email records on that name and had known us for about a week, and he was right. We rewrote it to apex-only, so the customer keeps their own DNS and we never hold the name.
Publishing to three marketplaces with a single tag was silently falling back instead of failing. Nobody caught it in review, because a quiet fallback looks exactly like success: the links render, the pages build, everything is green. It just pays nobody. New rule, a marketplace with no tag of its own does not get scanned or published at all. Loud failure beats silent fallback every time.
While the certificate was still issuing, the customer opened his own site from his phone and got an error page. Technically correct, completely wrong for someone who paid an hour ago. We added a status strip that names the current step and says pending is expected.
None of that came out of a planning session. All three came out of one install. The design meeting had produced a world where domains transfer, fallbacks are helpful, and pending is a state nobody looks at. Every one of those assumptions worked fine while I was both the operator and the user, and stopped working the moment those were two different people.
For context, I build usebravery.com, done-for-you Amazon affiliate sites on the customer's own domain. So the question back at you, since you had six developers build against your API: how many of what they found were bugs, and how many were assumptions that only held while you were the only user?