Grief and the AI split

The beginnings of that sustainable approach is already out there: https://boristane.com/blog/how-i-use-claude-code/

Came here to say something similar. For me, the craft aspect is now even more exciting because I can craft more ambitious things without getting bogged down in the details. For me, refining my conceptual model, drawing diagrams, finding the right way to think about something was the craft.

Maybe that's another way of saying: I was trained as a designer, and now the distinction between design (read: architecture, service-design, product, ux, cx) and programming is blurring.

Every little minor dispute can be split into some arbitrary dichotomy which is vaguely defensible. Not interesting.

Twelve years ago I would have the bright idea of why not make a little, just a tiny little (what I would call now) preprocessor for Java which does the same thing in less characters and is clearer. Everyone would love it. Of course no one loved it. Well, I never implemented it. Because I got some sense: you can’t just make tiny little preprocessors, a little code generation here and there, just code-generate this and tweak after the fact. Right? It’s not principled.

You can cook up a dichotomy. Good for you. I think the approach is just space age technology meets Stone Age mindset. It’s Flintstone Engineering. It’s barely even serious.

I am not offended that you took my craft. I am offended that you smear paint on the wall with three hundred parallel walls and painters and pick the best one. Or whatever Rube Setup is the thing that will take over the world as of thirty minutes ago.

Make something rock solid like formal verification with LLM assist (or LLM with formal verification assist?). Something that a “human” can understand (at this point maybe only the CEO is left). Something that is understandable, deterministic.

I might be out of a job. But I will not be offended. And I will respect it.

The point of reviews is that the process of reviews is a feedback cycle where we can identify where our docs are short. We then immediately update the docs to reflect the correction.

Over enough time, this gap closes and the need for reviews goes down. This is what I've noticed as we've continued to improve the docs: PRs have stabilized. Mid-level devs that just months ago were producing highly variant levels of quality are now coalescing on a much higher, much more consistent level of output.

There were a lot of pieces that went into this. We created a local code review skill that encodes the exact heuristics the senior reviewers would use and we ask the agent to run this in AGENTS.md. We have an MCP server over HTTP that we use to deliver the docs so we can monitor centralized telemetry.

The objective is that at some point, there will be enough docs and improved models that the need for human reviews decreases while quality of code reaches a steady state that is more consistent than any human team of varying skill level could produce.

One thing we've done is to decouple the docs from the codebase to make it easier to update the docs and immediately distribute updates orthogonal to the lifecycle of a PR.

(I'll have a post at some point that goes into some of what we are doing and the methodology.)

I think the argument is "a bit too nice," it isn't a binary, motivations are complicated and sometimes both feelings coexist.

If I reflect for a moment about why I personally got into tech, I can find at least a few different reasons:

- because I like solving problems. It's sad that the specific types of problems I used to do are gone, but it's exciting that there are new ones.

- because I like using my skills to help other people. It's sad that one specific way I could do that is now less effective, but it's exciting that I can use my knowledge in new ways.

- because I like doing something where I can personally make a difference. Again, it cuts both ways.

I'm sure most people would cite similar examples.