Code Is Getting Cheap. Attention Isn't.
The hard part of building a software company is moving, and I don’t think the move will be comfortable for anyone who has organised their business around where it used to be.
The old hard part was making the thing. Finding people who could write the code, paying them, keeping them, and getting a working product out of the arrangement before the money ran out. My expectation is that this keeps getting easier and cheaper, because large language models are writing a growing share of the code and are improving at it faster than most teams are restructuring around them. The consequence I think gets underpriced is on the other side of the transaction. If it costs a fraction of what it used to cost to produce a working application, more working applications get produced — and the number of hours a human being has available to notice any of them does not move at all.
That is the whole argument, and I want to state it plainly before going anywhere near the interesting parts. I expect two things. First, pressure on developer headcount inside venture-backed teams, as the amount of output a given number of engineers can produce rises. Second, and more consequential, an attention and audience crunch: cheap-to-build software competing for a scarce, fixed supply of human attention. This is my read on where things are going, not a report on where they already are.
Why the code being written is increasingly Python
These models are strongest in the languages they saw the most of. Python has, as far as I can tell, more representation in what they learned from than anything else, and the practical result is that Python is the language they write most fluently and the language that AI-assisted work drifts toward when nobody is deliberately steering it elsewhere.
That drift compounds. More Python gets written with model assistance, which puts more Python into the world, which strengthens the position of Python the next time around. I don’t think anyone chose this. It’s a byproduct of where the material happened to be.
What it changes is the nature of the decision. Choosing a language used to be an engineering argument with engineering reasons on both sides — performance characteristics, the libraries you needed, what the people you could hire already knew. Increasingly the deciding factor is which language your tooling produces most reliably, which is a different question with a different answer. A language a model writes well is not the same thing as a language that suits the job, and teams will pick the first one anyway, because the tooling makes it the path of least resistance.
I don’t think this is a tragedy. I find it much less interesting than the people arguing about it do. I raise it only because the same force is at work underneath everything else here: the more the production of code concentrates into something a model does well, the faster the cost of production falls, and the falling cost of production is what sets the rest of this in motion.
What I expect to happen to engineering headcount
I want to be careful about how I say this, because the version of the argument that gets repeated loudest is not the version I hold. I am not claiming that machines replace developers. I’m claiming something narrower and, I think, more likely: that the amount of working software a given number of engineers can produce goes up, and that in a venture-backed company this shows up as pressure on the hiring plan.
Those are different statements. The first is a prediction about people losing jobs. The second is a prediction about a marginal hire not being made.
Let’s imagine a funded team of twelve, eight of them engineers, with a plan to be twenty-five people by the end of next year. That plan rests on an assumption about how much one engineer produces in a quarter — nobody writes the assumption down, but it sits underneath every line of the hiring forecast. Now suppose that number climbs sharply over eighteen months. Nothing dramatic happens. There’s no announcement. What happens is that the roadmap starts arriving on time with the people already there, and the next board conversation shifts from “you’re hiring too slowly” to “walk me through why you need the next four.”
Headcount is the dominant cost in most venture-backed software companies, and the growth expectation attached to the funding makes every cost a live question. A change in output per person lands there first, before it lands anywhere else. That is what the pressure looks like — not a decision anyone announces, but a plan that quietly stops getting approved.
Where I think this argument stops
There are a few conditions that would make the headcount half of this wrong, and I’d rather name them than pretend they aren’t there.
Cheaper production has historically tended to produce more of the thing rather than fewer of the people who make it. If software gets cheap enough to build, businesses that could never justify custom software might start commissioning it, and demand for people who can steer that work could hold up perfectly well even as output per person climbs.
Some of the work also resists this more than the demos suggest. Integrating with systems that are already messy, operating where being wrong has a regulator attached, and maintaining something that already carries paying customers are not the same activity as producing a new application from an empty directory. The empty directory is the part whose cost is collapsing, and it was never the expensive part of a product that already exists.
And if I’m wrong about headcount, it doesn’t rescue the second half. The attention argument doesn’t depend on anyone losing a job. It depends only on the cost of producing an application falling, which is happening regardless of what the hiring plans do.
The attention and audience crunch
This is the half of the argument I care about most.
When building costs collapse, the supply of things built goes up. That much is reliable. What doesn’t go up is the audience. There is no more time in the day than there was, no more room on anyone’s phone, no more willingness to try a fourth tool this month. The shelf doesn’t get longer because manufacturing got cheaper; it gets more crowded, and each thing on it gets looked at less.
I expect this to be the defining constraint for consumer and small-business software over the next few years. The binding question stops being whether you can build it and becomes whether anyone ever finds out you did.
Imagine a category with, say, six credible competitors today. Reduce the cost of building a credible entrant by an order of magnitude and you don’t get seven. You get a long tail of entrants, several of them from people with no intention of building a company at all — someone competent with a free weekend. Most of those will be bad and will die quietly. That doesn’t help you, because a product doesn’t have to be good to take up the attention you needed; it only has to be in the way.
Three things follow from that, and they’re uncomfortable in different directions.
The first is pricing. When the marginal competitor can afford to be free, because it cost them a weekend and they aren’t trying to make rent from it, the floor under your pricing gets soft in a way that has nothing to do with the quality of what you built.
The second is that the cost of reaching a stranger does not fall alongside the cost of building. It’s set by how many other people are bidding for that same stranger’s hour, and by my reasoning that number is about to go up sharply. Building gets cheaper while being noticed gets more expensive, and those two moving in opposite directions is the squeeze I’m describing.
The third is what it does to differentiation. If everyone is building with the same models, “we built this with AI” stops being a claim about you and becomes a description of the weather. I already find that positioning tedious, and I think it has a short shelf life — a customer has never once cared how a product was produced, only whether it does the thing.
If a competent person can rebuild your product over a weekend, what’s left that they can’t copy?
Not the code. Not the model, since anyone can buy access to the same one. What’s left is knowing a specific group of people well enough to build for them precisely, and having a way to reach those people that doesn’t involve paying an ad platform every single time. The second one takes years to build and can’t be acquired in a hurry, which is why it’s worth starting on before the crunch rather than after it. I’ve written separately about why owned media matters again; this is the same point approached from the supply side rather than the demand side.
What I’d be thinking about if I were building right now
I’d treat distribution as a design constraint rather than a later problem. Not as a slide near the end of the deck, but as a question asked before the first line of code: who specifically is this for, and through what route does it reach them? If the honest answer is “we’ll figure that out once it works,” the plan is resting on the assumption that building is the hard part, and that assumption is the one I think is expiring.
I’d also get narrower than feels comfortable. A product for everyone is a product you have to advertise to everyone, which is the most expensive option available and getting worse. A product for a specific, findable, describable group of people can be put in front of those people at a cost that makes sense, and being the obvious choice for a small audience is a defensible position in a way that being an option for a large one is not.
And I’d spend some of the time that AI-assisted building gives back on the audience rather than on more features. The temptation will be to take the extra build capacity and produce a great deal more product, because that’s the visible, measurable, satisfying thing to do with it. My guess is that most of the teams who do this end up with more software and the same number of customers.
Predictions about scarce attention are themselves in generous supply at the moment, and I’m aware this is another one. I hold it with moderate confidence. I could easily be wrong about the pace, and the timing question is genuinely hard. What I’d rather be argued out of is the direction. If you’re building something right now and your experience says the cost of building is still the binding constraint on your business, tell me what you’re seeing — that would be the most useful thing anyone handed me this quarter.