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.
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.
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.
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.
Sounds great in principle but I have been trained to value individuals and interactions over processes and tools and working software over comprehensive documentation.
This kind of workflow really doesn't appeal to me in the slightest. Maybe it works for some people, but it just seems to drain all the pleasure out of programming. For me, at least, solving the little problems are like little satisfying puzzles which makes it easier to maintain motivation.
I am teaching asynchronous programming in typescript to junior developpers.
And i find really tricky to tell them that async and await do MAJOR magic behind their back to make their code readable as synchronous code.
And then, I need to detail very precisely what "Promise.all()" (and "return") really mean in the context of async/await. Which is something that (I feel) could have been abstracted away during the async/await syntax definition, and make the full magic much more natural.
Hi everyone, thanks for the spirited debate! I think there are some great points in the discussion so far. Some thoughts:
* "This didn't work for offshoring, why will it work all of a sudden?" I think there are good lessons to draw from offshoring around problem definition and what-not but the key difference is the iteration speed. Agents allow you to review stuff much faster, and you can look at smaller pieces of incremental work.
* "I thought this would be about async primitives in python, etc" Whoops sorry, I can understand how the name is confusing/ambiguous! The use of "async" here refers to the fact that I'm not synchronously looking at an IDE while writing code all the time.
* "You can only do this because you used to handwrite code". I don't think this workflow is a replacement for handwriting code. I still love doing that. This workflow just helps me do more.
Effective async programming specs read like technical documentation
The thing I like least about software engineering will now become the primary task. It's a sad future for me, but maybe a great one for some different personality type.
I actually like writing code, it does get tedious I get that when you're making yet another component. I don't feel joy when you just will a bunch of code into existence with words. It's like actively participating in development when typing. Which yeah people use libraries/frameworks/boilerplate.
My dream is to not be employed in software and do it for fun (or work on something I actually care about)
Even if I wrote some piece of crap, it is my piece of crap
I don't know why we need a term like "Async AI programming." this is literally what you would do if you were a Tech Lead directing a team of other developers. You define what you want and hand it to one of your devs.
This is just being a TL. the agent is an assistant or a member of the team. I don't know why we need to call it "Async AI programming", unless we want to shy away from or obscure the idea that the agent is actually performing the job a human used to perform.
> My workflow has changed since adopting async programming. I now work on four or five tasks simultaneously: one complex problem synchronously and three or four in the background.
Someone, please, try to convince me why this is a positive thing.
27 comments
[ 3.4 ms ] story [ 50.2 ms ] threadWorked 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.
See also that movie with Johnny Depp where AI takes over the world.
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.
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.
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)?
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.
Just call it Agent-based programming or somesuch, otherwise it's really confusing!
And then, I need to detail very precisely what "Promise.all()" (and "return") really mean in the context of async/await. Which is something that (I feel) could have been abstracted away during the async/await syntax definition, and make the full magic much more natural.
Hi everyone, thanks for the spirited debate! I think there are some great points in the discussion so far. Some thoughts:
* "This didn't work for offshoring, why will it work all of a sudden?" I think there are good lessons to draw from offshoring around problem definition and what-not but the key difference is the iteration speed. Agents allow you to review stuff much faster, and you can look at smaller pieces of incremental work.
* "I thought this would be about async primitives in python, etc" Whoops sorry, I can understand how the name is confusing/ambiguous! The use of "async" here refers to the fact that I'm not synchronously looking at an IDE while writing code all the time.
* "You can only do this because you used to handwrite code". I don't think this workflow is a replacement for handwriting code. I still love doing that. This workflow just helps me do more.
The thing I like least about software engineering will now become the primary task. It's a sad future for me, but maybe a great one for some different personality type.
I actually like writing code, it does get tedious I get that when you're making yet another component. I don't feel joy when you just will a bunch of code into existence with words. It's like actively participating in development when typing. Which yeah people use libraries/frameworks/boilerplate.
My dream is to not be employed in software and do it for fun (or work on something I actually care about)
Even if I wrote some piece of crap, it is my piece of crap
> This version of "async programming" is different from the classic definition. It's about how developers approach building software.
Oh async=you wait until it is done. How interesting.
This is just being a TL. the agent is an assistant or a member of the team. I don't know why we need to call it "Async AI programming", unless we want to shy away from or obscure the idea that the agent is actually performing the job a human used to perform.
Someone, please, try to convince me why this is a positive thing.