(Author here)

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.

I think this does not bode well for you; be honest with yourself - if you're making simple mistakes like using the term "Async Programming" to refer to something new, your prompting and/or code reviewing is probably not going all that well.

Sure, it can look good now, when there's no legacy, but if you ever move into having to maintain that code you're going to be in a tough spot.

I do think that AI will work well compared to the low end of offshoring, where to get good results you need people who could do the work themselves tightly involved. AI will give you slop code faster and cheaper, and that is sometimes enough.

The question is how it compares to the medium level of offshoring. Near term I think that at comparable cost ($100s of dollars per week), it'll give faster results at an acceptable tradeoff in quality for most uses. I don't think most companies want to spend thousands of dollars a month on developer tools per developer though... even though they often do.

It's just a different workflow IMO. AI is effectively real-time, whereas offshoring, no matter the quality, is something you have to do in batches.

(Author here) I can certainly appreciate having an alternate perspective, but I think it's unfair to say it's DOA. I've personally used this workflow for the last 6 months and shipped a lot of features into our product, including the lowest levels of infra all the way to UI code. I definitely think there is a lot to improve. But it works, at least for me :)

(Author here) Personally, I try to combat this by synchronously working on 1 task and asynchronously working on others. I am not sure it's perfect, but it definitely helps me avoid atrophy.

By synchronously working on 1 do you mean coding it with minimal AI?

Nice article by the way. I've found my workflow to be pretty much exactly the same using Claude code.

(Author here) Haha that is a great point. I was trying to come up with a term that described my personal workflow and specifically felt different than vibe coding (because it's geared towards how professional programmers can use agents). Very open to alternative terms!

This type of coding has been extremely helpful to me in the past few weeks. I’m on parental leave, but also a co-owner of a small company and can’t completely log off.

I can one handed spec out changes, AI does its thing, and then I review and refine it whenever my kid is asleep for 20 minutes. Or if I’m super tired I’m able to explain changes with horrible english and get results. At the same time, I am following a source control and code review process that I’ve used in large teams. I’ve even been leaving comments on PRs where AI contributes and I’m the only dev in the codebase.

I wouldn’t call this vibe coding— however vibe coding could be a subset of this type of work. I think async coding is a good description, but bad because of what it means as a software concept (which is mentioned). Maybe AI-delegation?

There is already a term for it! It's called "Ralph coding": https://ghuntley.com/ralph/

I want to understand the distinction you're making against vibe coding.

In vibe coding, the developer specifies only functional requirements (what the software must do) and non-functional requirements (the qualities it must have, like performance, scalability, or security). The AI delivers a complete implementation, and the developer reviews it solely against those behaviors and qualities. Any corrections are given again only in terms of requirements, never code, and the cycle repeats until the software aligns.

But you're trying to coin a term for the following?

In ??? coding, the developer specifies code changes that must be made, such as adding a feature, modifying an existing function, or removing unused logic. The AI delivers the complete set of changes to the codebase, and the developer reviews it at the code level. Any corrections are given again as updates to the code, and the cycle repeats until the code aligns.

Did I understand it right?

If so, I've most seen the latter be called AI pair-programming or AI-assisted coding. And I'd agree with the other commenters, please DO NOT call it async programming (even if you add async AI it's too confusing).

> In ??? coding, the developer specifies code changes that must be made, such as adding a feature, modifying an existing function, or removing unused logic. The AI delivers the complete set of changes to the codebase, and the developer reviews it at the code level. Any corrections are given again as updates to the code, and the cycle repeats until the code aligns.

Yes

> If so, I've most seen the latter be called AI pair-programming or AI-assisted coding.

I specifically considered both terms and am not a fan * "pair-programming" is something that involves two people paying attention while writing code, and in this case, i'm not looking at the screen while the AI system writes code * "AI-assisted coding" is generally anchored to copilots/IDE style agents where people are actively writing code, and an AI assists them.

I totally hear you on conflating async. However, I think the appropriate term would clearly indicate that this happens without actively watching the AI write code. Unfortunately I think other terms like "background" may also be confusing for similar reasons.

Agentic already implies what you want to imply. Maybe just call it agentic coding?

I feel that be the most clear. Agentic coding implies any workflow using AI agents. Which mean it's always the same agentic coding loop:

    1. Prompt...
    2. Wait or go do something else while agents make edits...
    3. Come back to review the result
    4. Go to 1

> is generally anchored to copilots/IDE style agents where people are actively writing code

I don't know when you last used these, but they're all agentic now. The workflow is exactly the same, you don't write code and auto-complete suggestions, you prompt and they go and make multiple edits to multiple files and can take upwards of 10 minutes, once done they show you a diff (or you can trust) and you're free to review/test or not, and prompt some more.

Edit: Or what the other commenter said: "prompt driven coding", that could be a good term as well.

I think it's still vibe coding. In practice any AI-driven process where you tell the AI what you want and it writes the code is considered "vibe coding."

No, it isn’t. There is a vast amount of difference between “vibe coding” and prompt driven development.

I’m giving the benefit of the doubt to the author here that it’s very unlikely they consider their example to be an actual representative scenario.

Vibe coding is to allow the AI to make the majority of the decisions. What the author describes is more like a highly complex autocomplete; you establish the fairly detailed outline of what is needed, often using tools/servers/etc tailored to use cases, and expect the AI to design an implementation that is in-line with the human-made decisions that preceded it, which is why I draw the comparison to autocomplete. Vibe coding is more like paying the kid next door to write your school essay…comparatively.

Agreed. There is a difference.

I used vibe coding to build a UI prototype of workflow. I used mockup images as the basis of the layout and let the agent use Redis as the persistence layer. I know it will be throw away and don't care how it is working underneath as long as it can demonstrate the flow I want.

I have also used prompt driven development to allow the agent to code something I expect to turn into a longer term product. I do more review of the code, ensure it is meeting all standards to development I would expect of myself or any other developer.

There are certainly differing degrees of the two types of development.

Cool to see the balance between UX and security. I really like the UI!

thanks! i wanted anyone to be able to create notes and be able to share them with others, so tried to come up with the most secure way to accomplish that :)

Thanks for mentioning Braintrust!

We are very committed to the proxy :)

Although, to your point, we have seen less market pull for routing, and more for (a) supporting the latest LLMs, (b) basic translation (e.g. tool call API b/w Anthropic & OpenAI), and (c) solid infra features like caching/load balancing api keys/secret management. So that's our focus.

We absolutely can. The proxy already supports running in multiple environments, including your own AWS VPC deployed on Lambda, so I'm sure we could add support for Bedrock (Anthropic or other models).

Feel free to ping me at ankur@braintrustdata.com and we can chat more!

We think a lot about this. I think it's very important to us to provide building blocks that foster a more open ecosystem. Part of that is providing building blocks (like the proxy) that do not lock you too much into "our" way of doing things either.

Model routers are a "semantic" abstraction -- they analyze the contents of a prompt and automatically determine which provider to use. This proxy is (currently) much simpler: you pick the provider you want and we add a bunch of nice features like caching and low-latency on top.

We will likely work with or build some routing capabilities in the future!

LiteLLM is a great project. The key differences (from what I can tell) are that:

a) This is hosted b) Supports caching and load balancing c) Can manage multiple providers behind a single API key d) Implemented in Typescript (vs. Python)

On the other hand, LiteLLM is a more mature project and supports significantly more model providers than we currently do!