Skip to content(if available)orjump to list(if available)

The Rise of Async Programming

The Rise of Async Programming

32 comments

·September 11, 2025

lelanthran

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.

sevensor

What the article describes is:

1. Learn how to describe what you want in an unambiguous dialect of natural language.

2. Submit it to a program that takes a long time to transform that input into a computer language.

3. Review the output for errors.

Sounds like we’ve reinvented compilers. Except they’re really bad and they take forever. Most people don’t have to review the assembly language / bytecode output of their compilers, because we expect them to actually work.

MisterTea

Coding interview of the future: "Show us how you would prompt this binary sort."

gobdovan

For generative skills I agree, but for me the real change is in how I read and debug code. After reading so much AI-generated code with subtle mistakes, I can spot errors much quicker even in human-written code. And when I can't, that usually means the code needs a refactor.

I'd compare it to gym work: some exercises work best until they don't, and then you switch to a less effective exercise to get you out of your plateau. Same with code and AI. If you're already good (because of years of hard won lessons), it can push you that extra bit.

But yeah, default to the better exercise and just code yourself, at least on the project's core.

suddenlybananas

What do you mean you can spot errors much quicker?

gobdovan

I mean that I've read so much AI generated code with subtle mistakes that my brain jumps straight to the likely failure point and I've noticed it generalizes. Even when I look at an OSS project I'm not super familiar with, I can usually spot the bugs faster then before. I'll edit my initial response for clarity.

lenerdenator

Agreed.

> Hand it off. Delegate the implementation to an AI agent, a teammate, or even your future self with comprehensive notes.

The AI agent just feels like a way to create tech debt on a massive scale while not being able to identify it as tech debt.

segfaultex

This is what a lot of business leaders miss.

The benefits you might gain from LLMs is that you are able to discern good output from bad.

Once that's lost, the output of these tools becomes a complete gamble.

bpt3

The business leaders already can't discern good from bad.

datadrivenangel

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.

mcny

I think it can only work if the product owner literally owns the product as in has FULL decision making power about what goes or doesn't go etc. it doesn't work when a product manager is a glorified in between guy, dictating the wishes of the CEO through a game of telephone from the management.

jt2190

You’ll have to be more specific about what you mean by “product owner”, because that’s a very nebulous job title. For example, how technical is this product owner? Are they assumed to “just know” that they’re asking for an overly complex, expensive technical solution?

balamatom

I'd guess they'd be assumed to "just know" to trust the developers working with them on that?

ch4s3

> it can only work if the product owner literally owns the product as in has FULL decision making power

This seems like a fairly rare situation in my experience.

swiftcoder

It's not uncommon in the sort of solo-dev bootstrapped startup that is going wild for AI coding right now though.

jmull

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.

thefourthchime

I disagree with being detailed, many times I want to AI to think of things, half the time it comes up with something I wouldn't have that I like.

The thing I would add is to retry to prompt, don't tell it to fix a mistake. Rewind and change the prompt to tell It not to do that it did.

UncleOxidant

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

stahorn

I was ready for a deep-dive into things like asyncio in python; where it came from and what problems it promised to solve!

antimoan

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

hackingonempty

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

skeezyboy

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

arethuza

They don't really as once the spec gets detailed enough it becomes so large and unwieldy that nobody with any actual power reads the things.

An executive at a large company once told me about something where a spec had been written and reviewed by all relevant stakeholders: "That may be what I asked for, but its not what I want."

dboreham

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.

suddenlybananas

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.

bpt3

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)?

conorbergin

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

titzer

Indeed! Why not just call it "asynchronous software development" or something similar? "asynchronous programming" is a bad choice, partly because it will be un-googleable.