I work at Airbnb where I write 99% of my production code using LLMs. Spotify's CEO recently announced something similar, but I mention my employer not because my workflow is sponsored by them (many early adopters learned similar techniques), but to establish a baseline for the massive scale, reliability constraints, and code quality standards this approach has to survive.
Many engineers abandon LLMs because they run into problems almost instantly, but these problems have solutions. If you're a skeptic, please read and let me know what you think.
The top problems are:
* Constant refactors (generated code is really bad or broken)
* Lack of context (the model doesn’t know your codebase, libraries, APIs, etc.)
* Poor instruction following (the model doesn’t implement what you asked for)
* Doom loops (the model can’t fix a bug and tries random things over and over again)
* Complexity limits (inability to modify large codebases or create complex logic)
In this article, I show how to solve each of these problems by using the LLM as a force multiplier for your own engineering decisions, rather than a random number generator for syntax.
A core part of my approach is Spec-Driven Development. I outline methods for treating the LLM like a co-worker having technical discussions about architecture and logic, and then having the model convert those decisions into a spec and working code.
I work at Airbnb where I write 99% of my production code using LLMs. Spotify's CEO recently announced something similar, but I mention my employer not because my workflow is sponsored by them (many early adopters learned similar techniques), but to establish a baseline for the massive scale, reliability constraints, and code quality standards this approach has to survive. Many engineers abandon LLMs because they run into problems almost instantly, but these problems have solutions. If you're a skeptic, please read and let me know what you think. The top problems are: * Constant refactors (generated code is really bad or broken) * Lack of context (the model doesn’t know your codebase, libraries, APIs, etc.) * Poor instruction following (the model doesn’t implement what you asked for) * Doom loops (the model can’t fix a bug and tries random things over and over again) * Complexity limits (inability to modify large codebases or create complex logic) In this article, I show how to solve each of these problems by using the LLM as a force multiplier for your own engineering decisions, rather than a random number generator for syntax. A core part of my approach is Spec-Driven Development. I outline methods for treating the LLM like a co-worker having technical discussions about architecture and logic, and then having the model convert those decisions into a spec and working code.
So you're right and we're all wrong. Thank goodness you've put us straight.
[dead]