The difference is not that it’s “worthless”. The difference is that now it’s “practical” to implement given the low effort.
I wouldn’t be sad about defeating lower complexity challenges. There are always higher complexity challenges that arise once we start operating in a world when you can do more. The bar raises.
No, increasing the offer of something decreases its value, always. Do not necessarily increases its demand. That is basic economic rule. See that I use "value", not "cost". The distinction matters.
Yesterday I went to a bookstore: saw an interesting book cover then I thought "ah, looks like AI"... all excitement went away. There won't be a "new complexity frontier" for artists that used to draw book covers. Or writers, actors, writers, etc.
AI is currently not enabling any use case which previously was "too hard". It is just reducing the value of stuff by increasing the offer and making people delulu about what they can achieve without proper knowledge.
Making good stuff requires paying attention to a lot of details. Even "simple" stuff can become incredible complex once you actually learn about how it must be done. Most of what we humans do is working on that space, not chasing projects Manhattans.
What do we get if population is disconnected of the true complexity of creating stuff? Perceived value decreases and if everything is perceived equally bad people will stop caring about quality. That is why fascism likes uneducated people.
So, that is about the AI contribution to "value" itself.
Now, is it true that AI will allow us to create more complex stuff that is not practical now? I would strongly disagree. The reason is Kolmogorov complexity: it is not possible to find the shortest program that describes a task. Describing it with natural language will not magically give us permission to avoid having to describe that complexity. What is the point of switching from C to English, if I still have to specify every little detail in a much ambiguous and verbose language? Programming languages are not the challenge, they are the solution to the problem of having to specify complex tasks in a reproducible way.
Now gathering everything together: that is why I think that generative AI makes things worthless: value reduction, complexity perception reduction (which reduces value), a population ignorant of the complexity will choose subpar options because "they are all the same garbage" and we will not get any superior engineering capability anyway.
The point is the death of the celebration of excellence and technical mastery.
Once insurmountable challenges are now trivial to implement with, as you say, "low effort."
For those who were attracted to computing by the grind and the grand narrative that you, too, with sufficient effort, discipline, and merit, could become a revered craftsman, LLMs trivialize an entire lifetime of practice. I can't think of anything more demoralizing.
If your goals were fame, then yes. But you can still pursue excellence even if there is an alternative “easy” path.
The equivalent is something like hand tool woodworking - it’s still a thing despite the advent of machines, but more of a niche. You can still aim to become excellent, but maybe you won’t be famous.
They are factories that product goods on a whim. There is nothing to compare them to as we never had anything like that. This is not industrial revolution this is obliteration of work at its core.
I look at them as lab grown bacteria. We’re in the early days and still have a lot of contamination we still don’t understand. They don’t always produce a viable result, and sometimes they break test rigs.
Just because they’re not a pure extension of our bodies or minds like a hammer or pencil doesn’t mean they will magically break the concept of work.
API prices may be profitable. Subscriptions may still be subsidized for power users. Free tiers almost certainly are. And frontier labs may be subsidizing overall business growth, training, product features, and peak capacity, even if a normal metered API call is profitable on marginal inference.
Research and training costs have to be amortized from somewhere; and labs are always training. I'm definitely keen for the financials when the two files for IPO though, it would be interesting to see; although I'm sure it won't be broken down much.
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’ve found there are two major mindset shifts that helped me start passing tech interviews consistently:
1. Study the algorithms and patterns, not the questions
2. Treat it like a serious investment, 2–3 months of focused prep minimum
Most people skip the fundamentals. But these core patterns and data structures come up over and over. If you really understand them, you can solve almost anything.
I used this exact approach to land offers from Google, Amazon, Uber, Airbnb and more, without a CS degree.
That experience led me to write this full breakdown of how to study for tech interviews the right way.
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:
1. Constant refactors (generated code is really bad or broken)
2. Lack of context (the model doesn’t know your codebase, libraries, APIs, etc.)
3. Poor instruction following (the model doesn’t implement what you asked for)
4. Doom loops (the model can’t fix a bug and tries random things over and over again)
5. 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.
LOL, honestly I hated Codex when it first came out. It was backed by o3 at the time.
But literally as soon as GPT-5 came out in Codex and with the "high" option, I completely switched from Claude Codex to Codex. Never imagined that would happen so fast.
> get the best results when the context window is right around 70%
I used to be trigger happy with /compact or using the hand off technique to transfer knowledge between sessions with a doc. But lately the newer generation of models seem to be handling long context pretty well up to around 20% remaining context.
But this is when I'm working on the same focused task. I would instantly reset it if I started implementing an unrelated task. Even if there was 90% left, since theres just no benefit to keeping the old context
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 wouldn’t be sad about defeating lower complexity challenges. There are always higher complexity challenges that arise once we start operating in a world when you can do more. The bar raises.