With all the emphasis on the speed of modern AI tools, we often seem to forget that velocity is a vector quantity. Increased speed only gets us where we want to be sooner if we are also heading in the right direction. If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be.
I’ve been noticing that this simple reality explains almost all of both the good and the bad that I hear about LLM-based coding tools. Using AI for research or to spin up a quick demo or prototype is using it to help plot a course. A lot of the multi-stage agentic workflows also come down to creating guard rails before doing the main implementation so the AI can’t get too far off track. Most of the success stories I hear seem to be in these areas so far. Meanwhile, probably the most common criticism I see is that an AI that is simply given a prompt to implement some new feature or bug fix for an existing system often misunderstands or makes bad assumptions and ends up repeatedly running into dead ends. It moves fast but without knowing which direction to move in.
> Increased speed only gets us where we want to be sooner if we are also heading in the right direction.
This is a real problem when the "direction" == "good feedback" from a customer standpoint.
Before we had a product person for every ~20 people generating code and now we're all product people, the machines are writing the code (not all of it, but enough of it that I will -1 a ~4000 line PR and ask someone to start over, instead of digging out of the hole in the same PR).
Feedback takes time on the system by real users to come back to the product team.
You need a PID like smoothing curve over your feature changes.
Like you said, Speed isn't velocity.
Specifically if you have a decent experiment framework to keep this disclosure progressive in the customer base, going the wrong direction isn't a huge penalty as it used to be.
I liked the PostHog newsletter about the "Hidden dangers of shipping fast", I can't find a good direct link to it.
>Increased speed only gets us where we want to be sooner if we are also heading in the right direction.
I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, allowing you to iterate more quickly.
I've definitely gotten it into contexts where it will never stop going into the wrong direction, even when I tell it to forget everything it did before, and told it a correct path forward. Usually restarting the entire session fixes it, but not always.
One of my favorite ideas from Nietzsche [1] is that civilizations take millennia to “digest” or integrate concepts. It seems a little obvious, maybe, until you look at the modern world and realize the baseline assumption is something like, “every problem is just a question of resources.”
An example being the common attitude that [advanced tech] is just a math problem to be solved, and not a process that needs to play itself out in the real world, interacting with it and learning, then integrating those lessons over time.
Another way to put this is: experience is undervalued, and knowledge is overvalued. Probably because experience isn’t fungible and therefore cannot be quantified as easily by market systems.
1. Probably not his original idea, and now that I think about it this is kind of more Hegelian. I’m not familiar enough with Hegel to reference him though.
Awesome article, I feel a lot of people have also forgotten that good projects take iteration not 100 new features.
To get few features to an excelent state it requires multilpe iterations at multiple stages.
1) The developer who does a task validates that their thinking was the correct one, they see how they changes impact the system, is it scalable? Does it need to be scalable? While you are working and thinking on it you get more and more context which simply wasn't there at the begining.
2) A feature done once (even after my perfect ClaudeCode plan) is not done forever, people will want to make it better/faster/smoother/etc. But instead of taking the time to analyze and perfect it we go onto the next feature, and if we have to iterate on the current one, we don't iterate we redo...
Really like the article I think it is awesome, and I strongly believe AI for coding will stay, but I also beleive that we need to still have a strong understanding of why we are building things and what they look like.
I've been working on a clone of Sid Meier's Pirates but with a princess theme (for my daughters).
I've been using AI to help me write it and I've come to a couple conclusions:
- AI can make working PoCs incredibly quickly
- It can even help me think of story lines, decision paths etc
- Given that, there is still a TON of decisions to be made e.g. what artwork to use, what makes sense from a story perspective
- Playtesting alone + iterating still occurs at human speed b/c if humans are the intended audience, getting their opinions takes human time, not computer time
I've started using this example more and more as it highlights that, yes, AI can save huge amounts of time. However, as we learned from the Theory of Constraints, there is always another bottleneck somewhere that will slow things down.
I've tried a few game projects with coding agents - having never worked on a game before in my life - and the main thing I learned is that the hard part is designing it to be fun.
Coming up with a genuinely interesting gameplay loop with increasing difficulty levels and progressively revealed gameplay mechanics is a fascinating and extremely difficult challenge, no matter how much AI you throw at the problem.
I have very similar experience. I vibecoded a foreign language practice app for myself. It works decent from functional perspective and I don’t see too many bugs. But the biggest productivity constraint I see is the time I need to spend using it in order to understand what is working and where the issues are.
„I was able to vibecode those 5 apps I always wanted but never had time to code them myself … it is so different now because — I don’t have time to use them”.
> We pay premiums for Swiss watches, Hermès bags and old properties precisely because of the time embedded in them
Lost me in paragraph three. We pay for those things because they're recognizable status symbols, not because they took a long time to make. It took my grandmother a long time to knit the sweater I'm wearing, but its market value is probably close to zero.
I would say that wearing a sweater knitted by one's grandmother is its own kind of status symbol. I'm more impressed by that (someone having a grandmother willing to invest that much effort in a gift for them) than someone spending $1000 on an item of clothing.
The fact that those items took a long time to make is part of what makes them status symbols though, because if you pay a lot of money for something that took no time to make at all (see most NFTs) you look like an idiot to a lot of people.
This sort of thing was done at a time when everybody did it, and now that it's not done, nobody does it
No kid ever said "did you see the sweater that Timmy's grandma knitted for him? That kid is so cool! "
Mostly because they all had grams sweaters as well.
I don't know what term you were looking for, but a handmade present for someone dear is about the furthest thing from a "status symbol" that I can think of:
- it can't be bought
- it can't be transferred without losing almost all value (ie: it's only valuable to you, or at most your family, eBay doesn't want it)
- it provides no improvement whatsoever in one's social standing
What are you referring to with the phrase "status symbol"?
I can't connect it at all to your listed points. An Olympic medal is about obvious a status symbol as I can imagine but it can't (meaningfully) be bought or transferred.
The status signified with a knit sweater is membership (and good standing!) in a caring family with elders not yet fully subsumed into their phones.
People, acquaintances and strangers alike, frequently comment on the knit socks I often wear, ask after who made them, and all of a sudden we're on "how's your mom" terms.
To be worthy that much time is the statussymbol of love. Its a rare thing, money can't buy. Somebody gifts part of his finite time on the planet to you bundled in an artifact.
I like the sweater, and some people like you might recognize it as special, but it doesn't have the universal cachet of a Rolex or something. It's also a bit chunky and funny-looking (but I guess so are some Rolexes).
I feel you, I guess i succeeded in not being lost and keep reading by solving the conendrum in telling myself: it certainly should take time to grow the cows for the bags. Nonetheless I'm glad i finished reading it, it was a good essay.
Yes, Veblen goods, and there are examples of cloning Hermès bags for example (still by hand) where they're much cheaper yet took the same amount of time to create.
> everybody who is like me, fully onboarded into AI and agentic tools, seemingly has less and less time available because we fall into a trap where we’re immediately filling it with more things
You fill a jar with sand and there is no space for big rocks.
But if you fill the jar with big rocks, there is plenty of space for sand. Remove one of the rocks and the sand instantly fills that void.
I think that's kind of the point though: AI is the sand, but it's the rocks that hold all of the value; the further you get away from using AI the more real value you obtain. Like, a few of the rocks have gold deposits in them, and the sand is just infinitely copious but never holds anything valuable. And you've got a bunch of people running around saying, "Behold my mountains of sand!"
You fill the bottle with water, you put a fish in it, you remove half of the water, the bottle is still half full, but if you remove the fish, it will have less water than before.
You fill the bottle with half of the water, you put the fish in, you can fill in the other half. If you start with the first half, you will end up with more water.
The point of the metaphor is not to say "spending time is mechanically similar to putting things in a container". It is to look at spending time from a new angle, and see if it helps you understand it better. A wise person sees a metaphor as a launching point for thought, not as an expression of a metaphysical connection.
Yes, there are bad metaphors, and people who take metaphors too seriously. That you can conjure a bad metaphor with somewhat similar to semantics to some other metaphor does not mean that said metaphor is bad.
In a more advanced civilisation, you would be put in the pillory for the townsfolk to throw rotten cabbage at you until the Lord fixed whatever made you say that.
You write a metaphore in a comment, you remove half of it, you add another one in the middle, you add the half of the first one, and… nobody understands anything.
Hahah, I just have to reply and say I loved the original comment and was happy for the laugh. Obviously this is the answer to the riddle of
> Given a 3-liter container and a 5-liter container, both initially empty, and access to tap water, how can you measure exactly 4 liters of water without using any additional containers
I've offered and received some convoluted metaphors recently, love leaning hard into this one.
They're talking about Archimedes' principle, displacement of water. The fish makes the water bottle overflow, so be careful when you add the fish so that it doesn't. It's a counter analogy to the rocks one above.
They’re pointing out that if the jar was _filled_ with sand, then of course you can’t fit any rocks in because it’s full. It’s cute but misunderstands the original metaphor I think.
I've been hearing similar things from a lot of different directions. The underlying issue about "you cannot replace time" is one that is good to internalize early. A number of people I know who "missed" their kids growing up because they were working hard to make lots of money. You can't go buy "time with my kids when they were growing up."
Agentic coding very much feels like a "video game" in the sense of you pull the lever and open the loot box and sometimes it's an epic +10 agility sword and sometimes its just grey vendor trash. Whether or not it generates "good" or even "usable" code fades to the background as the thrill of "I just asked for a UI to orchestrate micro services and BLAMMO there it was!" moves to the fore.
Yes, you cannot build years of community and trust in a weekend. But sometimes it's totally sufficient to plant a seed, give it some small amounts of water and leave it on its own to grow. Go ask my father having to deal with a huge maple tree, that I’ve planted 30 years ago and never cared for it.
Open Source projects sometimes work like this. I've created a .NET library for Firebase Messaging in a weekend a few years ago… and it grew on its own with PRs flowing in. So if your weekend project generates enough interest and continues to grow a community without you, what’s the bad thing here? I don’t get it.
Sometimes a tree dies and an Open Source project wasn’t able to make it.
That said, I’ve just finished rewriting four libraries to fix long standing issues, that I haven’t been able to fix for the past 10 years.
It's been great to use Gemini as a sparring partner to fix the API surface of these libraries, that had been problematic for the past 10 years. I was so quick to validate and invalidate ideas.
Once being one of the biggest LLM haters I have to say, that I immensely enjoy it right now.
Sounds familiar, for most of my life I have tried to remove all "friction" from life – applying that engineering mindset to make everything as efficient as possible. Only then I realized that life somehow is about that "friction".
Speed is useful, when you have a good idea or a hypothesis you want to test. But if you are running in the wrong direction, speed is of very little value. With LLMs it might be even harder to stop and realize that you are creating the wrong thing, because you are not spending effort to create the wrong thing.
I'm seeing this cultural pattern where developers have started accepting LLM output with very little scrutiny. This ends up code that works on the surface, but most of the times problems are not addressed at their source.
Creating these wrong things is only cheaper with LLMs. Since developers now spend less time and effort to create that wrong thing, they don't feel the need validate or reflect on them so much.
The risk is not the tool itself, but the over-reliance on it and forgoing feedback loops that have made teams stronger, e.g. debugging, testing, and reasoning why something works a particular way.
> But if you are running in the wrong direction, speed is of very little value.
I think of it differently. Speed is great because it means you can change direction very easily, and being wrong isn't as costly. As long as you're tracking where you're going, if you end up in the wrong place, but you got there quickly and noticed it, you can quickly move in a different direction to get to the right place.
Sometimes we take time mostly because it's expensive to be wrong. If being wrong doesn't cost anything, going fast and being wrong a lot may actually be better as it lets you explore lots of options. For this strategy to work, however, you need good judgment to recognize when you've reached a wrong position.
What's faster now are the time-dependent factors of production - product development, go-to market, etc.
What's slower now are threats to production - even minor regulations take years or decades, and often appear only when workarounds have surfaced.
So what changed in the last 40+ years are the many tools for businesses to shape the conditions of their business -the downstream market, upstream suppliers, and regulatory support/constraints. This is extremely patient work over generations of players, sometimes by individuals, but usually by coalitions of mutual corporate self-interest, where even the largest players couldn't refuse to participate.
I work at FAANG, and leadership is successfully pushing the urge for speed by stablishing the new productivity expectations, and everyone is rushing as much as they can, as the productivity gain doesn't really match the expectations, and people overwork to make up for this difference. This works very well with internal competition and a quota system for performance ratings, with some extra fear due to the bad job market.
I feel this new world sucks. We have new technology that boosts the productivity of the individual engineer, and we could be doing MUCH better work, instead of just rushed slop to meet quotas.
I feel I'm just building my replacement, to bring the next level of profits to the c-suite. I just wish I wasn't burning out while doing so.
I’ve noticed this dynamic acutely working at YC startups the last 5ish years. Coding has become like a sweatshop.
I don’t think it’s exclusive to startups or tech either, it seems more like a downstream consequence of the fact that there’s no real innovation anymore. Capitalism demands constant growth, and when there are real technological improvements you can achieve that growth through higher productivity. If there are none, you have to achieve that growth through other means like forcing employees to work longer or cutting costs. The alpha is all coming from squeezing the labor force right now.
> it seems more like a downstream consequence of the fact that there’s no real innovation anymore
This doesn't sound right to me. We are currently getting smacked upside the head by an enormous technological innovation. I believe that, even within the framework of capitalism, this problem has social and political roots. The "robber baron" period late 19th century America has strong similarities to what we are seeing today, and technological stagnation was not the cause.
We're gonna have to learn some lessons from other engineering fields in this regard. Electrical, civil, mechanical, aerospace... They've all had to put processes in place to intentionally slow things down for a long time. I could throw a circuit board layout together 1000x faster then a team of engineers could have 50 years ago, but that industry has developed a culture of rigorous review processes to ensure quality, which means I couldn't actually move nearly as fast as possible.
Undoubtedly a lot of that comes down to production cost and safety. A plane is far more likely to kill people and it costs a shitload more to produce then an app (though plenty of software is mission critical). But now in software we can move quick enough up front that if we don't start applying some discipline it's going to bite us in the ass in the long run.
I don't disagree with the sentiment, but I think the signals that we use to determine whether we're doing the right things are different with the new AI enhanced toolsets.
Refactoring decent sized components are an order of magnitude easier than it was, but the more important signal is still, why are you refactoring? What changed in your world or your world-view that caused this?
Good things still take time, and you can't slop-AI code your way to a great system. You still need domain expertise (as the EXCELLENT short story from the other day explained, Warranty Void if Regenerated (https://nearzero.software/p/warranty-void-if-regenerated) ). The decrease in friction does definitely allow for more slop, but it also allows for more excellence. It just doesn't guarantee excellence.
>Nobody is going to mass-produce a 50-year-old oak. And nobody is going to conjure trust, or quality, or community out of a weekend sprint.
absolutely although i wonder how different 'trust' is in the culture of tomorrow? will it 'matter' as much, be as cherished, as earned over the fullness of time?
i suspect it is a pendulum - and we are back to oak trees at some point - but which way is the pendulum swinging right now?
> everybody who is like me, fully onboarded into AI and agentic tools, seemingly has less and less time available because we fall into a trap where we’re immediately filling it with more things
I do wonder if productivity with AI coding has really gone up, or if it just gives the illusion of that, and we take on more projects and burn ourselves out?
> I do wonder if productivity with AI coding has really gone up
Here's the thing: we never had a remotely sane way to measure productivity of a software engineer for reasons that we all understand, and we don't have it now.
Even if we had it, it's not the sort of thing that management would even use: they decide how productive you are based on completely unrelated criteria, like willingness to work long hours and keeping your mouth shut when you disagree.
If you ask those types whether productivity has gone up with AI, they'll probably say something like "of course, we were able to let go a third of our programmers and nothing really seems to have changed"
"Productivity" became a poisoned word the moment that the suits realized what a useful weapon it was, and that it was impossible to challenge.
> I do wonder if productivity with AI coding has really gone up, or if it just gives the illusion of that, and we take on more projects and burn ourselves out?
It definitely hasn't for me. I spent about an hour today trying to use AI to write something fairly simple and I'm still no further forward.
I don't understand what problem AI is supposed to solve in software development.
Well following advice from folk on here earlier, I thought I'd start small and try to get it to write some code in Go that would listen on a network socket, wait for a packet with a bunch of messages (in a known format) come in, and split those messages out from the packet.
I ended up having to type hundreds of lines of description to get thousands of lines of code that doesn't actually work, when the one I wrote myself is about two dozen lines of code and works perfectly.
It just seems such a slow and inefficient way to work.
> I don't understand what problem AI is supposed to solve in software development.
When Russians invaded Germany during WWII, some of them (who had never seen a toilet) thought that toilets were advanced potato washing machines, and were rightfully pissed when their potatoes were flushed away and didn't come back.
Sounds like you're feeling a similar frustration with your problem.
lots of things take days, not hours. And idt AI changes that much. It does let you (or - let's be real - your middle management) try to make it happen with hours tho :P
I think it's hard to argue with the idea that we should slow down and think more, and that AI is pushing us to do the opposite. But time is limited, it's very limited. And at least in a professional setting, to spend time on the correct things is key.
What AI allow us is to do those things we would not have been able to prioritize before. To "write" those extra tests, add that minor feature or to solve that decade old bug. Things that we would never been able to prioritize are we noe able to do.
It's not perfect, it's sometimes sloppy, but at least its getting shit done. It does not matter if you solve 10% of your problem perfect if you never have time for the remaining 90.
I do miss the coding, _a lot_, but productivity is a drug and I will take it.
On the contrary, you can solve the tree problem with money. There are nurseries that sell mature trees -- most people though will not choose to spend $20k on a tree.
But anyhow, you can buy large-ish burlapped trees but they aren’t as healthy, often die, and nothing close to a 100+ yr old estate oak tree or a decades old rose garden. You just can’t make it faster, transplanting plants that old will kill them.
Besides nitpicking, even your original point isn't even true. You cannot transplant a 100 year old tree (which has not been constrained in size dramatically) and expect it to survive for any reasonable length of time.
> I’m also increasingly skeptical of anyone who sells me something that supposedly saves my time.
Imagine a world in which the promise of AI was that workers could keep their jobs, at the same compensation as before, but work fewer hours and days per week due to increased productivity.
What could you do with those extra hours and days? Sleep better. Exercise more. Prepare healthy meals. Spend more time with family and friends. The benefits to physical and mental well-being are priceless. Even if you happened to earn extra money for the same amount of work, your time can be infinitely more valuable than money.
Unfortunately, that's not this world. Which is why the "increased productivity" promise doesn't seem to benefit workers at all.
If you look at the technological utopias that people imagined 50, 60+ years ago, they involved lives of leisure. If you would have told them that advances in technology would not reduce our working hours at all, maybe they would have started smashing the machines back then. Now we're supposed to be happy with more "stuff", even if there's no more time to enjoy stuff.
Programmers no longer have any leverage now they can all be replaced by machines. It doesn't matter how productive you are, the system will always demand more.
I feel for the larger companies and the people who started 10 years ago, though.
They have spent the last decade building processes and guardrails for getting consistent average performance from people. But now, some talented people who worked at those companies are building their own new companies without the overhead and moving much, much more quickly.
I think what we assume is "vibe slop at inference speed" is not as simple as people make it out to be. From a perspective, I think generally it might be people trying to save jobs.
I'm seeing more slop come out of larger, older companies than the new ones (with experienced operators).
And the speed is somewhat scary. For smaller team it doesn't take as much effort to build deep, beautiful product anymore.
The bottleneck was never the ability for a engineer to code. It was the 16 layers between the customer and the programmer which has vanished in smaller companies and is forcing larger ones to produce slop.
> We know this intuitively. We pay premiums for Swiss watches, Hermès bags and old properties precisely because of the time embedded in them. Either because of the time it took to build them or because of their age.
Oh, I thought it was because they're a way to show off about being rich.
> We require age minimums for driving, voting, and drinking because we believe maturity only comes through lived experience.
Even if she could reach the pedals, my 4yo doesn't have the attention span to drive. This isn't a "lived experience" thing, it's a physical brain development thing. IIRC the are effects with learning math, where starting earlier had limited impact on being able to move to certain more advanced topics earlier; ie there's more going on than just hours of experience.
The standard age for voting is also the age for being a legal adult. There are sound logical reasons that these ages should match.
The standard drinking age is due to pressure by activists, and AIUI is lower in other countries.
> Oh, I thought it was because they're a way to show off about being rich.
Maybe for some. I think these examples were carefully chosen. Hermès are made in France, "Swiss watch" doesn't automatically mean Rolex, though in that case Rolex does own most of their manufacturing (though there is a whole world of carefully made watches out there that don't cost 10K). As for old properties... there is a huge range there, but unless you are living in a castle, most people, at least my city, are likely silently thinking: "I'm so sorry for them that they have to live in that old house."
I'm reading Against The Machine by Paul Kingsnorth, and now reading this blog piece is hard not to make connections with the points of the book: the usage of the tree as a counter-argument for the machine's automation credo exposed in the blog post very much aligns with I've read so far.
I don't see the problem - everything the author describes has, and will always be, true. You can't vibe code anything of value in a weekend exactly because anyone _else_ with the same level of experience can do the exact same thing in the same weekend! This has always been true across all trades and technologies. Once again, the domain expertise, wisdom, and simply _time_ of doing something always win. LLMs literally don't change that at all.
“The power of doing anything with quickness is always prized much by the possessor, and often without any attention to the imperfection of the performance.”
> We require age minimums for driving, voting, and drinking because we believe maturity only comes through lived experience.
Not true, we do this because the 99% of the time it's true, however there are people who would be perfectly competent and responsible to drive without living to the age of 16-18. Same with voting, there are humans who have a deep understanding and intelligence about politics at a younger age than suffrage. Equally there are people who will be reckless drivers at 40 and vote on whim at 60.
We have these rules not because sophistication only comes through lived experience, we have them because it's strongly correlated and covers of most error cases.
To take this to AI, run the model enough times with a higher enough temperature, then perhaps it can solve your challenges with a high enough quality - just a thought.
With all the emphasis on the speed of modern AI tools, we often seem to forget that velocity is a vector quantity. Increased speed only gets us where we want to be sooner if we are also heading in the right direction. If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be.
I’ve been noticing that this simple reality explains almost all of both the good and the bad that I hear about LLM-based coding tools. Using AI for research or to spin up a quick demo or prototype is using it to help plot a course. A lot of the multi-stage agentic workflows also come down to creating guard rails before doing the main implementation so the AI can’t get too far off track. Most of the success stories I hear seem to be in these areas so far. Meanwhile, probably the most common criticism I see is that an AI that is simply given a prompt to implement some new feature or bug fix for an existing system often misunderstands or makes bad assumptions and ends up repeatedly running into dead ends. It moves fast but without knowing which direction to move in.
> Increased speed only gets us where we want to be sooner if we are also heading in the right direction.
This is a real problem when the "direction" == "good feedback" from a customer standpoint.
Before we had a product person for every ~20 people generating code and now we're all product people, the machines are writing the code (not all of it, but enough of it that I will -1 a ~4000 line PR and ask someone to start over, instead of digging out of the hole in the same PR).
Feedback takes time on the system by real users to come back to the product team.
You need a PID like smoothing curve over your feature changes.
Like you said, Speed isn't velocity.
Specifically if you have a decent experiment framework to keep this disclosure progressive in the customer base, going the wrong direction isn't a huge penalty as it used to be.
I liked the PostHog newsletter about the "Hidden dangers of shipping fast", I can't find a good direct link to it.
>Increased speed only gets us where we want to be sooner if we are also heading in the right direction.
I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, allowing you to iterate more quickly.
It's still faster and cheaper to just build the right thing to begin with. As the old saying goes, spend your time sharpening your ax.
> It moves fast but without knowing which direction to move in.
It also moves fast with a tendency to pick the wrong direction (according to the goal of the prompter) at every decision point (known or unknown).
I've definitely gotten it into contexts where it will never stop going into the wrong direction, even when I tell it to forget everything it did before, and told it a correct path forward. Usually restarting the entire session fixes it, but not always.
One of my favorite ideas from Nietzsche [1] is that civilizations take millennia to “digest” or integrate concepts. It seems a little obvious, maybe, until you look at the modern world and realize the baseline assumption is something like, “every problem is just a question of resources.”
An example being the common attitude that [advanced tech] is just a math problem to be solved, and not a process that needs to play itself out in the real world, interacting with it and learning, then integrating those lessons over time.
Another way to put this is: experience is undervalued, and knowledge is overvalued. Probably because experience isn’t fungible and therefore cannot be quantified as easily by market systems.
1. Probably not his original idea, and now that I think about it this is kind of more Hegelian. I’m not familiar enough with Hegel to reference him though.
Awesome article, I feel a lot of people have also forgotten that good projects take iteration not 100 new features. To get few features to an excelent state it requires multilpe iterations at multiple stages. 1) The developer who does a task validates that their thinking was the correct one, they see how they changes impact the system, is it scalable? Does it need to be scalable? While you are working and thinking on it you get more and more context which simply wasn't there at the begining. 2) A feature done once (even after my perfect ClaudeCode plan) is not done forever, people will want to make it better/faster/smoother/etc. But instead of taking the time to analyze and perfect it we go onto the next feature, and if we have to iterate on the current one, we don't iterate we redo...
Really like the article I think it is awesome, and I strongly believe AI for coding will stay, but I also beleive that we need to still have a strong understanding of why we are building things and what they look like.
I've been working on a clone of Sid Meier's Pirates but with a princess theme (for my daughters).
I've been using AI to help me write it and I've come to a couple conclusions:
- AI can make working PoCs incredibly quickly
- It can even help me think of story lines, decision paths etc
- Given that, there is still a TON of decisions to be made e.g. what artwork to use, what makes sense from a story perspective
- Playtesting alone + iterating still occurs at human speed b/c if humans are the intended audience, getting their opinions takes human time, not computer time
I've started using this example more and more as it highlights that, yes, AI can save huge amounts of time. However, as we learned from the Theory of Constraints, there is always another bottleneck somewhere that will slow things down.
I've tried a few game projects with coding agents - having never worked on a game before in my life - and the main thing I learned is that the hard part is designing it to be fun.
Coming up with a genuinely interesting gameplay loop with increasing difficulty levels and progressively revealed gameplay mechanics is a fascinating and extremely difficult challenge, no matter how much AI you throw at the problem.
I have very similar experience. I vibecoded a foreign language practice app for myself. It works decent from functional perspective and I don’t see too many bugs. But the biggest productivity constraint I see is the time I need to spend using it in order to understand what is working and where the issues are.
My newest joke is:
„I was able to vibecode those 5 apps I always wanted but never had time to code them myself … it is so different now because — I don’t have time to use them”.
LMK if you finish it, sounds like something my daughter would enjoy!
> We pay premiums for Swiss watches, Hermès bags and old properties precisely because of the time embedded in them
Lost me in paragraph three. We pay for those things because they're recognizable status symbols, not because they took a long time to make. It took my grandmother a long time to knit the sweater I'm wearing, but its market value is probably close to zero.
I would say that wearing a sweater knitted by one's grandmother is its own kind of status symbol. I'm more impressed by that (someone having a grandmother willing to invest that much effort in a gift for them) than someone spending $1000 on an item of clothing.
The fact that those items took a long time to make is part of what makes them status symbols though, because if you pay a lot of money for something that took no time to make at all (see most NFTs) you look like an idiot to a lot of people.
> status symbol.
This sort of thing was done at a time when everybody did it, and now that it's not done, nobody does it
No kid ever said "did you see the sweater that Timmy's grandma knitted for him? That kid is so cool! "
Mostly because they all had grams sweaters as well.
I don't know what term you were looking for, but a handmade present for someone dear is about the furthest thing from a "status symbol" that I can think of:
- it can't be bought
- it can't be transferred without losing almost all value (ie: it's only valuable to you, or at most your family, eBay doesn't want it)
- it provides no improvement whatsoever in one's social standing
What are you referring to with the phrase "status symbol"?
I can't connect it at all to your listed points. An Olympic medal is about obvious a status symbol as I can imagine but it can't (meaningfully) be bought or transferred.
The status signified with a knit sweater is membership (and good standing!) in a caring family with elders not yet fully subsumed into their phones.
People, acquaintances and strangers alike, frequently comment on the knit socks I often wear, ask after who made them, and all of a sudden we're on "how's your mom" terms.
> it can't (meaningfully) be bought or transferred.
https://www.ebay.com/b/Olympic-Medal/27291/bn_55191416?_sop=...
> People, acquaintances and strangers alike, frequently comment on the knit socks I often wear,
Ok, that explains pretty much everything about your line of thought.
Thanks.
Buying someone else’s medal is not a status symbol. That is why they included the word meaningfully.
(edited for clarity)
> https://www.ebay.com/b/Olympic-Medal/27291/bn_55191416?_sop=...
Of course you can buy an Olympic medal. You can't buy the status conferred by the medal (of Olympic champion / nth runner up).
> Ok, that explains pretty much everything about your line of thought.
I don't understand this either. Are you insulting me?
I don't care about the opinion of kids.
I'm also completely unimpressed by someone wearing a Rolex though, so different mileage for different people.
You should be able to understand the definition of a common term such as "status symbol" though.
Understanding words does not require being impressed by anything, nor caring about the opinion of kids.
Different mileage for different people.
If most people are thinking "whoopdedoo... you clearly have more money than sense" when they see your status symbol, is it still a status symbol?
It depends, if someone fundamentally believes that having more money than someone else means that person is of higher status, then it is.
If people don't consider that someone with more money is of a higher status then symbols of that wealth aren't meaningful.
I think a lot of people have an ingrained belief that "more money == more status"
To be worthy that much time is the statussymbol of love. Its a rare thing, money can't buy. Somebody gifts part of his finite time on the planet to you bundled in an artifact.
I like the sweater, and some people like you might recognize it as special, but it doesn't have the universal cachet of a Rolex or something. It's also a bit chunky and funny-looking (but I guess so are some Rolexes).
"universal" is doing a lot of heavy lifting there.
I feel you, I guess i succeeded in not being lost and keep reading by solving the conendrum in telling myself: it certainly should take time to grow the cows for the bags. Nonetheless I'm glad i finished reading it, it was a good essay.
Yes, Veblen goods, and there are examples of cloning Hermès bags for example (still by hand) where they're much cheaper yet took the same amount of time to create.
https://youtu.be/02CjWIkTy-M
Maybe the analogy was wrong but more and more, I believe that some of a value was implicitly about how many organs/industries did it touch.
Reads like a feel good article to signal virtue and feel validated in the wake of the Delve scandal. But ultimately obvious, opportunistic, and mid.
> everybody who is like me, fully onboarded into AI and agentic tools, seemingly has less and less time available because we fall into a trap where we’re immediately filling it with more things
You fill a jar with sand and there is no space for big rocks.
But if you fill the jar with big rocks, there is plenty of space for sand. Remove one of the rocks and the sand instantly fills that void.
Make sure you fit the rocks first.
I think that's kind of the point though: AI is the sand, but it's the rocks that hold all of the value; the further you get away from using AI the more real value you obtain. Like, a few of the rocks have gold deposits in them, and the sand is just infinitely copious but never holds anything valuable. And you've got a bunch of people running around saying, "Behold my mountains of sand!"
You fill the bottle with water, you put a fish in it, you remove half of the water, the bottle is still half full, but if you remove the fish, it will have less water than before.
You fill the bottle with half of the water, you put the fish in, you can fill in the other half. If you start with the first half, you will end up with more water.
The point of the metaphor is not to say "spending time is mechanically similar to putting things in a container". It is to look at spending time from a new angle, and see if it helps you understand it better. A wise person sees a metaphor as a launching point for thought, not as an expression of a metaphysical connection.
Yes, there are bad metaphors, and people who take metaphors too seriously. That you can conjure a bad metaphor with somewhat similar to semantics to some other metaphor does not mean that said metaphor is bad.
In a more advanced civilisation, you would be put in the pillory for the townsfolk to throw rotten cabbage at you until the Lord fixed whatever made you say that.
You write a metaphore in a comment, you remove half of it, you add another one in the middle, you add the half of the first one, and… nobody understands anything.
You put your right foot in, you put your right foot out, you put your right foot in, and you shake it all about.
> You fill the bottle with water, you put a fish in it, [some water overflows], you remove half of water...
That water overflow step is missing / implicit. But that's an observable event.
you fill the 3 liter bottle up to the top, and pour the contents into the 5 liter bottle
then you fill 3 liter bottle again, and pour the contents into the 5 liter bottle until the 5 liter one is full
empty the 5 liter bottle, and pour the 1 liter in the 3 liter bottle into the 5 liter bottle
fill the 3 liter bottle again and pour that into the 1 liter already in the 5 liter bottle to get 4 liters of water
What?
I assume post used extreme example to demonstrate that wise-sounding metaphors may not have inherent point or value.
Hahah, I just have to reply and say I loved the original comment and was happy for the laugh. Obviously this is the answer to the riddle of
> Given a 3-liter container and a 5-liter container, both initially empty, and access to tap water, how can you measure exactly 4 liters of water without using any additional containers
I've offered and received some convoluted metaphors recently, love leaning hard into this one.
Psilocybin?
Not sure, I used to be better at diagnosing this type of episode.
They're talking about Archimedes' principle, displacement of water. The fish makes the water bottle overflow, so be careful when you add the fish so that it doesn't. It's a counter analogy to the rocks one above.
They’re pointing out that if the jar was _filled_ with sand, then of course you can’t fit any rocks in because it’s full. It’s cute but misunderstands the original metaphor I think.
If that ain’t the secret to solving an np complete problem I don’t know what is!
I've been hearing similar things from a lot of different directions. The underlying issue about "you cannot replace time" is one that is good to internalize early. A number of people I know who "missed" their kids growing up because they were working hard to make lots of money. You can't go buy "time with my kids when they were growing up."
Agentic coding very much feels like a "video game" in the sense of you pull the lever and open the loot box and sometimes it's an epic +10 agility sword and sometimes its just grey vendor trash. Whether or not it generates "good" or even "usable" code fades to the background as the thrill of "I just asked for a UI to orchestrate micro services and BLAMMO there it was!" moves to the fore.
As for the tree analogy and open source.
Yes, you cannot build years of community and trust in a weekend. But sometimes it's totally sufficient to plant a seed, give it some small amounts of water and leave it on its own to grow. Go ask my father having to deal with a huge maple tree, that I’ve planted 30 years ago and never cared for it.
Open Source projects sometimes work like this. I've created a .NET library for Firebase Messaging in a weekend a few years ago… and it grew on its own with PRs flowing in. So if your weekend project generates enough interest and continues to grow a community without you, what’s the bad thing here? I don’t get it.
Sometimes a tree dies and an Open Source project wasn’t able to make it.
That said, I’ve just finished rewriting four libraries to fix long standing issues, that I haven’t been able to fix for the past 10 years.
It's been great to use Gemini as a sparring partner to fix the API surface of these libraries, that had been problematic for the past 10 years. I was so quick to validate and invalidate ideas.
Once being one of the biggest LLM haters I have to say, that I immensely enjoy it right now.
Sounds familiar, for most of my life I have tried to remove all "friction" from life – applying that engineering mindset to make everything as efficient as possible. Only then I realized that life somehow is about that "friction".
Indeed. Without friction you can't steer.
Speed is useful, when you have a good idea or a hypothesis you want to test. But if you are running in the wrong direction, speed is of very little value. With LLMs it might be even harder to stop and realize that you are creating the wrong thing, because you are not spending effort to create the wrong thing.
I'm seeing this cultural pattern where developers have started accepting LLM output with very little scrutiny. This ends up code that works on the surface, but most of the times problems are not addressed at their source.
Creating these wrong things is only cheaper with LLMs. Since developers now spend less time and effort to create that wrong thing, they don't feel the need validate or reflect on them so much.
The risk is not the tool itself, but the over-reliance on it and forgoing feedback loops that have made teams stronger, e.g. debugging, testing, and reasoning why something works a particular way.
> But if you are running in the wrong direction, speed is of very little value.
I think of it differently. Speed is great because it means you can change direction very easily, and being wrong isn't as costly. As long as you're tracking where you're going, if you end up in the wrong place, but you got there quickly and noticed it, you can quickly move in a different direction to get to the right place.
Sometimes we take time mostly because it's expensive to be wrong. If being wrong doesn't cost anything, going fast and being wrong a lot may actually be better as it lets you explore lots of options. For this strategy to work, however, you need good judgment to recognize when you've reached a wrong position.
I can relate to this, when time and effort of coding is a limiting factor it forces people to be more thoughtful about what to create.
What's faster now are the time-dependent factors of production - product development, go-to market, etc.
What's slower now are threats to production - even minor regulations take years or decades, and often appear only when workarounds have surfaced.
So what changed in the last 40+ years are the many tools for businesses to shape the conditions of their business -the downstream market, upstream suppliers, and regulatory support/constraints. This is extremely patient work over generations of players, sometimes by individuals, but usually by coalitions of mutual corporate self-interest, where even the largest players couldn't refuse to participate.
It's evolution.
I work at FAANG, and leadership is successfully pushing the urge for speed by stablishing the new productivity expectations, and everyone is rushing as much as they can, as the productivity gain doesn't really match the expectations, and people overwork to make up for this difference. This works very well with internal competition and a quota system for performance ratings, with some extra fear due to the bad job market.
I feel this new world sucks. We have new technology that boosts the productivity of the individual engineer, and we could be doing MUCH better work, instead of just rushed slop to meet quotas.
I feel I'm just building my replacement, to bring the next level of profits to the c-suite. I just wish I wasn't burning out while doing so.
I’ve noticed this dynamic acutely working at YC startups the last 5ish years. Coding has become like a sweatshop.
I don’t think it’s exclusive to startups or tech either, it seems more like a downstream consequence of the fact that there’s no real innovation anymore. Capitalism demands constant growth, and when there are real technological improvements you can achieve that growth through higher productivity. If there are none, you have to achieve that growth through other means like forcing employees to work longer or cutting costs. The alpha is all coming from squeezing the labor force right now.
> it seems more like a downstream consequence of the fact that there’s no real innovation anymore
This doesn't sound right to me. We are currently getting smacked upside the head by an enormous technological innovation. I believe that, even within the framework of capitalism, this problem has social and political roots. The "robber baron" period late 19th century America has strong similarities to what we are seeing today, and technological stagnation was not the cause.
We're gonna have to learn some lessons from other engineering fields in this regard. Electrical, civil, mechanical, aerospace... They've all had to put processes in place to intentionally slow things down for a long time. I could throw a circuit board layout together 1000x faster then a team of engineers could have 50 years ago, but that industry has developed a culture of rigorous review processes to ensure quality, which means I couldn't actually move nearly as fast as possible.
Undoubtedly a lot of that comes down to production cost and safety. A plane is far more likely to kill people and it costs a shitload more to produce then an app (though plenty of software is mission critical). But now in software we can move quick enough up front that if we don't start applying some discipline it's going to bite us in the ass in the long run.
I don't disagree with the sentiment, but I think the signals that we use to determine whether we're doing the right things are different with the new AI enhanced toolsets.
Refactoring decent sized components are an order of magnitude easier than it was, but the more important signal is still, why are you refactoring? What changed in your world or your world-view that caused this?
Good things still take time, and you can't slop-AI code your way to a great system. You still need domain expertise (as the EXCELLENT short story from the other day explained, Warranty Void if Regenerated (https://nearzero.software/p/warranty-void-if-regenerated) ). The decrease in friction does definitely allow for more slop, but it also allows for more excellence. It just doesn't guarantee excellence.
>Nobody is going to mass-produce a 50-year-old oak. And nobody is going to conjure trust, or quality, or community out of a weekend sprint.
absolutely although i wonder how different 'trust' is in the culture of tomorrow? will it 'matter' as much, be as cherished, as earned over the fullness of time?
i suspect it is a pendulum - and we are back to oak trees at some point - but which way is the pendulum swinging right now?
> everybody who is like me, fully onboarded into AI and agentic tools, seemingly has less and less time available because we fall into a trap where we’re immediately filling it with more things
I do wonder if productivity with AI coding has really gone up, or if it just gives the illusion of that, and we take on more projects and burn ourselves out?
> I do wonder if productivity with AI coding has really gone up
Here's the thing: we never had a remotely sane way to measure productivity of a software engineer for reasons that we all understand, and we don't have it now.
Even if we had it, it's not the sort of thing that management would even use: they decide how productive you are based on completely unrelated criteria, like willingness to work long hours and keeping your mouth shut when you disagree.
If you ask those types whether productivity has gone up with AI, they'll probably say something like "of course, we were able to let go a third of our programmers and nothing really seems to have changed"
"Productivity" became a poisoned word the moment that the suits realized what a useful weapon it was, and that it was impossible to challenge.
A blend of both. You do create more, but the goalposts are always one more step away.
ps: it's strange that YouTubers are talking about the same thing. People in different dev circles. Agentic feels like doom ide scroll.
Sounds similar to a slot machine. How odd…
> I do wonder if productivity with AI coding has really gone up, or if it just gives the illusion of that, and we take on more projects and burn ourselves out?
It definitely hasn't for me. I spent about an hour today trying to use AI to write something fairly simple and I'm still no further forward.
I don't understand what problem AI is supposed to solve in software development.
Apologies for the obligatory question, but what did you try to do, and with which AI did you try to do it with?
Well following advice from folk on here earlier, I thought I'd start small and try to get it to write some code in Go that would listen on a network socket, wait for a packet with a bunch of messages (in a known format) come in, and split those messages out from the packet.
I ended up having to type hundreds of lines of description to get thousands of lines of code that doesn't actually work, when the one I wrote myself is about two dozen lines of code and works perfectly.
It just seems such a slow and inefficient way to work.
> I don't understand what problem AI is supposed to solve in software development.
When Russians invaded Germany during WWII, some of them (who had never seen a toilet) thought that toilets were advanced potato washing machines, and were rightfully pissed when their potatoes were flushed away and didn't come back.
Sounds like you're feeling a similar frustration with your problem.
I don't really see where that comparison is relevant.
Why is AI supposed to be good?
Russians invading Ukraine had some, let's say interesting, reactions to modernities like toilets and washing machines
Which begs the question: how many of those Russians stealing the appliances also took a potato washer or two?
lots of things take days, not hours. And idt AI changes that much. It does let you (or - let's be real - your middle management) try to make it happen with hours tho :P
I love this, and it applies to a lot more than software and trees :)
I think it's hard to argue with the idea that we should slow down and think more, and that AI is pushing us to do the opposite. But time is limited, it's very limited. And at least in a professional setting, to spend time on the correct things is key.
What AI allow us is to do those things we would not have been able to prioritize before. To "write" those extra tests, add that minor feature or to solve that decade old bug. Things that we would never been able to prioritize are we noe able to do. It's not perfect, it's sometimes sloppy, but at least its getting shit done. It does not matter if you solve 10% of your problem perfect if you never have time for the remaining 90.
I do miss the coding, _a lot_, but productivity is a drug and I will take it.
On the contrary, you can solve the tree problem with money. There are nurseries that sell mature trees -- most people though will not choose to spend $20k on a tree.
This is nitpicking his point.
But anyhow, you can buy large-ish burlapped trees but they aren’t as healthy, often die, and nothing close to a 100+ yr old estate oak tree or a decades old rose garden. You just can’t make it faster, transplanting plants that old will kill them.
You're moving the goalposts on his poor analogy :)
Most of the trees do just fine, and these nurseries will typically provide a warranty.
Besides nitpicking, even your original point isn't even true. You cannot transplant a 100 year old tree (which has not been constrained in size dramatically) and expect it to survive for any reasonable length of time.
> I’m also increasingly skeptical of anyone who sells me something that supposedly saves my time.
Imagine a world in which the promise of AI was that workers could keep their jobs, at the same compensation as before, but work fewer hours and days per week due to increased productivity.
What could you do with those extra hours and days? Sleep better. Exercise more. Prepare healthy meals. Spend more time with family and friends. The benefits to physical and mental well-being are priceless. Even if you happened to earn extra money for the same amount of work, your time can be infinitely more valuable than money.
Unfortunately, that's not this world. Which is why the "increased productivity" promise doesn't seem to benefit workers at all.
If you look at the technological utopias that people imagined 50, 60+ years ago, they involved lives of leisure. If you would have told them that advances in technology would not reduce our working hours at all, maybe they would have started smashing the machines back then. Now we're supposed to be happy with more "stuff", even if there's no more time to enjoy stuff.
Also you know, for programmers, say a 3 day work week is right there up for grabs. Even still employers would see big productivity increases.
Programmers no longer have any leverage now they can all be replaced by machines. It doesn't matter how productive you are, the system will always demand more.
This hype too will pass. It's always ebb and flood...
you know what most of us end up doing on those other days? we start side tech projects that require even more effort for even little return.
You can't trust us with self-care. There's just too many shiny toys out there!
Speak for yourself!
I feel for the larger companies and the people who started 10 years ago, though.
They have spent the last decade building processes and guardrails for getting consistent average performance from people. But now, some talented people who worked at those companies are building their own new companies without the overhead and moving much, much more quickly.
I think what we assume is "vibe slop at inference speed" is not as simple as people make it out to be. From a perspective, I think generally it might be people trying to save jobs.
I'm seeing more slop come out of larger, older companies than the new ones (with experienced operators).
And the speed is somewhat scary. For smaller team it doesn't take as much effort to build deep, beautiful product anymore.
The bottleneck was never the ability for a engineer to code. It was the 16 layers between the customer and the programmer which has vanished in smaller companies and is forcing larger ones to produce slop.
> We know this intuitively. We pay premiums for Swiss watches, Hermès bags and old properties precisely because of the time embedded in them. Either because of the time it took to build them or because of their age.
Oh, I thought it was because they're a way to show off about being rich.
> We require age minimums for driving, voting, and drinking because we believe maturity only comes through lived experience.
Even if she could reach the pedals, my 4yo doesn't have the attention span to drive. This isn't a "lived experience" thing, it's a physical brain development thing. IIRC the are effects with learning math, where starting earlier had limited impact on being able to move to certain more advanced topics earlier; ie there's more going on than just hours of experience.
The standard age for voting is also the age for being a legal adult. There are sound logical reasons that these ages should match.
The standard drinking age is due to pressure by activists, and AIUI is lower in other countries.
> Oh, I thought it was because they're a way to show off about being rich.
Maybe for some. I think these examples were carefully chosen. Hermès are made in France, "Swiss watch" doesn't automatically mean Rolex, though in that case Rolex does own most of their manufacturing (though there is a whole world of carefully made watches out there that don't cost 10K). As for old properties... there is a huge range there, but unless you are living in a castle, most people, at least my city, are likely silently thinking: "I'm so sorry for them that they have to live in that old house."
great article. reminds me of the saying “9 women can’t make a baby in a month”
"So welcome to the machine"
I'm reading Against The Machine by Paul Kingsnorth, and now reading this blog piece is hard not to make connections with the points of the book: the usage of the tree as a counter-argument for the machine's automation credo exposed in the blog post very much aligns with I've read so far.
I don't see the problem - everything the author describes has, and will always be, true. You can't vibe code anything of value in a weekend exactly because anyone _else_ with the same level of experience can do the exact same thing in the same weekend! This has always been true across all trades and technologies. Once again, the domain expertise, wisdom, and simply _time_ of doing something always win. LLMs literally don't change that at all.
https://simplytrees.com/
“The power of doing anything with quickness is always prized much by the possessor, and often without any attention to the imperfection of the performance.”
Was hoping this wasn't ai related, disappointed
> We require age minimums for driving, voting, and drinking because we believe maturity only comes through lived experience.
Not true, we do this because the 99% of the time it's true, however there are people who would be perfectly competent and responsible to drive without living to the age of 16-18. Same with voting, there are humans who have a deep understanding and intelligence about politics at a younger age than suffrage. Equally there are people who will be reckless drivers at 40 and vote on whim at 60.
We have these rules not because sophistication only comes through lived experience, we have them because it's strongly correlated and covers of most error cases.
To take this to AI, run the model enough times with a higher enough temperature, then perhaps it can solve your challenges with a high enough quality - just a thought.
The guiding analogy of the piece is that of planting a tree and waiting for it to mature.
The reason we need to wait is that it takes time for some things to mature.
Yes, I'm saying it's not a good analogy