I did this early in my career as a product owner with an offshore team in India... Write feedback/specs, send them over at end of day US time. Have a fresh build ready for review by start of business.

Worked amazingly when it worked. Really stretched things out when the devs misunderstood us or got confused by our lack of clarity and we had to find time for a call... Also eventually there got to be some gnarly technical debt and things really slowed down.

Those of us who worked in hardware, or are old programmers will find this familiar. Chip/board routing jobs that took days to complete. Product build/test jobs that took hours to run.

See also that movie with Johnny Depp where AI takes over the world.

He says define the problem like its the easy part. If we had full specs, life would be a lot easier.

This works until you get to the point that your actual programming skills atrophy due to lack of use.

Face it, the only reason you can do a decent review is because of years of hard won lessons, not because you have years of reading code without writing any.

Awful font.

That's not the kind of async programming I was expecting.

Redefining commonly understood phrases to mean something else in your own little world make you look ignorant.

This vision of AI programming is DOA.

The first step is "define the problem clearly".

This would be incredibly useful for software development, period. A 10x factor, all by itself. Yet it happens infrequently, or, at best, in significantly limited ways.

The main problem, I think, is that it assumes you already know what you want at the start, and, implicitly, that what you want actually makes some real sense.

I guess maybe the context is cranking out REST endpoints or some other constrained detail of a larger thing. Then, sure.

It takes my longer to thoroughly review code I didn't write, especially code written by a junior developer.

Why would I choose to slow myself down in the short term and allow my skills to atrophy in the long term (which will also slow me down)?

I think there is a confusion here between Coding and Programming. I think what is described here as "Async Programming" is just programming the way it should be which is different than coding. This is what Leslie Lamport pointed out a while back [1] and recently [2]. According to him programming has 3 stages:

  1- Define what task the program should perform
  2- Define how the program should do it
  3- Writing the code that does it.

Most SWEs usually skip to step 3 instead of going through 1 and 2 without giving it much thought, and implement their code iteratively. I think Step 3 also includes testing, review, etc.

With AI developers are forced to think about the functionality and the specs of their code to pass it to AI to do the job and can no longer just jump to step 3. For delegating to other devs, the same process is required, senior engineers usually create design docs and pass it to junior engineers.

IMO automated verification and code reviews are already part of many developers workflows, so it's nothing new.

I get the point of the article though, that there are new requirements for programming and things are different in terms of how folks approach programming. So I do not agree that the method is new or should be called "async", it's the same method with brand new tools.

  [1] https://www.youtube.com/watch?v=-4Yp3j_jk8Q
  [2] https://www.youtube.com/watch?v=uyLy7Fu4FB4

Sounds great in principle but I have been trained to value individuals and interactions over processes and tools and working software over comprehensive documentation.