Writing Code Was Never the Bottleneck

It's funny, I have the same problem, but with subject matter expertise. I work with internal PR people and they clearly have shifted their writing efforts to be AI-assisted or even AI-driven. Now I as the SME get these AI-written blog posts and press releases and I spend a far more time on getting all the hallucinations out of these texts.

It's an effort inversion, too - time spent correcting the PR-people's errors has tripled or quadrupled. They're supposed to assist me, not the other way around. I'm not the press release writer here.

And of course they don't 'learn' like your junior engineers - it's always AI, it's always different hallucinations.

P.S.: And yes I've raised this internally with our leadership - at this rate we'll have 50% of the PR people next year, they're making themselves unemployed. I don't need a middleman who's job it is to copy-paste my email into ChatGPT, then send me the output; I can do that myself.

It's something that takes time. That time is now greatly reduced. So you can try more ideas and explore problems by trying solutions quickly instead of just talking about them.

Let's also not ignore the other side of this. The need for shared understanding, knowledge transfer etc is close to zero if your team is agents and your code is the input context (where the actual code is now at the level that machine code is now: very rarely if ever looked at). That's kinda where we're heading. Software is about to get much grander, and your team is individuals working on loosely connected parts of the product. Potentially hundreds of them.

Code is not a bottleneck. Specs are. How the software is supposed to work, down to minuscule detail. Not code, not unit tests, not integration tests. Just plain English, diagrams, user stories.

Bottleneck is designing those specs and then iterating them with end users, listening to feedback, then going back and figuring out if spec could be improved (or even should). Implementing actual improvements isn't hard once you have specs.

If specs are really good -- then any sufficiently good LLM/agent should be able to one-shot the solution, all the unit tests, and all the integration tests. If it's too large to one-shot -- product specs should never be a single markdown file. Think of it more like a wiki -- with links and references. And all you have to do is implement it feature by feature.

    """
    This is the new adder feature. Internally it uses chained Adders to multiply:
    Adder(Adder(Adder(x, y), y), ...)
    """
    class Adder:
       # public attributes x and y
       def __init__(self, x: float, y: float) -> None:
          raise NotImplementedError()
 
       def add(self) -> float:
          raise NotImplementedError()
 
    class Muliplier:
       # public attributes x and y
       # should perform multiplication with repeated adders
       def __init__(self, x: float, y: float) -> None:
          raise NotImplementedError()
 
       def multiply(self) -> float:
          raise NotImplementedError()

For changes, you'd do the same thing. Specify it as comments and "high level" code ("# remove this class and switch to Multiplier") etc.

Then spec -> review -> tests -> review -> code -> review.

Depending on how much you trust a dev, you can kill some review steps.

1. It's harder to vibe good specs like this from the start, and prevents Claude from being magical (e.g. executing code to make sure things work)

2. You're embedding a design process into reviews which is useful even if they're coding by hand.

3. It simplifies reviewing generated code because at least the interfaces should be respected.

This is the pattern I've been using personally to wrangle ChatGPT and Claude's behavior into submission.