If you thought code writing speed was your problem you have bigger problems

  > Why not? Why can't faster typing help us understand the problem faster?

Can it help? Of course! But I think the question is too vague here and you're (presumably) unintentionally creating a false dichotomy. I'll clarify with the next responses

  > Why can't we figure out the right thing faster by building the wrong thing faster?

The main problem is that solution spaces are very large. There are two general ways to narrow the solution space: directly and indirectly. Directly by things like thinking hard, digging down, and "zooming in". Indirectly by things such as figuring out what not to do (ruling things out).

You can build a lot of wrong things that don't also help you narrow that solution space. The most effective way to "build the wrong thing" in an informative way is to first think hard and understand your solution space. You want to build the right wrong thing. The thing that helps you rule out lots of stuff. But if you are doing it randomly then you aren't doing this effectively and probably wasting a lot of time. You probably are already doing this but not thinking too much about this explicitly, but if you think explicitly you'll improve on this.

  > Presumably we were gonna build the wrong thing either way

You always build the "wrong" thing. But it is about how wrong you are. Despite being about physics, I think Asimov's Relativity of Wrong[0] (short essay) is pretty relevant here and says everything I want to say but better. It is worth the read and I come back to it frequently.

  > I often build something to figure out what I want

Yes! But this is not quite the same thing. I do this too! I never know the full details of the thing I want before I start building. I'm not sure that's even possible tbh. You're always going to discover more things as you get into the details and nuance. But that doesn't mean foresight is useless either.

  Analogy
  -------

Let's say I'm somewhere in the middle of America and I want to get to NYC. Analogous to your framing you are saying "why can't moving faster help us get there faster?" Obviously it can! BUT speed is meaningless without direction. You don't want speed, you want velocity. If you start driving as fast as possible in a random direction you're equally likely to head in a direction that increases your distance than one that decreases. And you are very unlikely to head in a good direction. Driving fast in the wrong direction significantly increases harm than were you to drive slowly in the wrong direction.

So what's the optimal strategy? Find a general direction (e.g. use the sun or stars/moon) to figure out where "east"(ish) is, start driving relatively slowly, refine your direction as you get more information about the landscape, speed up as you gain more information. If you can't find a general direction you should slowly meander, carefully taking in how the landscape/environment is changing. If it is very unchanging, then yeah, speedup, but only until you find a region that becomes more informative, then repeat the process.

If we already had perfect information about how to get to NYC then just drive as fast as fucking possible. But if we don't have that information we need a completely different strategy. Thus, t̶y̶p̶i̶n̶g̶ driving speed isn't the bottleneck.

Speed doesn't matter, velocity does

[0] https://hermiene.net/essays-trans/relativity_of_wrong.html

[dead]

Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another.

Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.

> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.

I've already passed through this phase and have given up on it. I'm sure everyone's experience will vary, but I just find it introduces either sufficiently more context switching or detracts sufficiently enough mental engagement that I end up introducing more errors, feeling miserable, or just straight up losing productivity and focus. This type of workflow is only viable for me if the cost of mistakes is low, the surface area for changes is small, or the mental context is the same between activities.

The expectation that this is a serviceable workflow—I fear, and am experiencing—will ultimately just create more compressed timelines for everything, while quality, design, and job satisfaction will drop. Yes the code can be written while I look at a PR, but if it's a non-trivial amount of code or a non-trivial PR (which tends to become more frequent as more code generation and larger refactors are happening) then I'm just context switching between tasks I need to constantly re-zone in on, which is less gratifying and more volatile in a way that just hurts my mind and soul and money doesn't change in a meaningful way.

That's not to say I'm not using them or seeing no productivity gains, but I'm not reclaiming that much time due to being able to anything concurrently, it's mostly reclaiming time I'd otherwise have procrastinated on something.

I’ve been going on about this in another thread in a separate post. That’s where modularity comes in. From code I write to teams (or multiple teams back in the day). I always enforce micro services. Not always separately deployable micro service, they could be separate packages with namespace/public/private accessibility.

Even if you do have not so good developers, they can ramp up quickly on one specific isolated service and you can contain the blast radius.

This isn’t a new idea. This was the entire “API mandate” that Bezos had in 2002. s3 alone is made up of 200+ micro services