It's not different than when coding by hand, often we take shortcuts by hand that we then have to pay for later. It really just becomes a judgement call on when to stop prompting new features and start service what you have.
I think with AI and vibecoding its tempting to assume the output is good and chase the dopamine hits of more features, more features, more features, but eventually you get stuck.
That being said AI is also a great tool at paying down tech debt. It's great at helping you read a codebase and can be great at making the mechanical changes you want. And I think there is some truth to the story that newer models will be able to pay down debt (fix the slop) of older models. But its all shades of grey, newer models are better than older ones, but can I emit slop with 5.6 faster than 5.7 will be able to fix it in the future? Nobody knows.
It's not like human projects are devoid of bad code, its all tradeoffs and shades of gray. But to be honest I haven't written a line of code by hand in a while.
Clear goal, share context, delegate but verify. Running a team of engineers also inevitably generates pages and pages of material, design spec, code, test, review. Just that we now do that with agents and agents are way less trust worthy
Usage is metered/billed by the token. This suggests a few possible hypotheses for why they might tend to be verbose.
I've known some people who can never stop talking. Maybe they are overly represented in the training set.
If you're not convinced - sign up and pay by the token of a high or highest level model. Anthropic or Grok for example. The vendor isn't the concern. The quality of what can be done. Then, find an agentic 'harness' that is written in a language you can read. There are several (pi, opencode, crush, etc) and then clone that repo or one of yours you don't mind having exposed and then point your agent to that repo.
Now ask questions: what api calls are made by this repo? Where are secrets stored and sourced from? Do an adversarial investigation and list the bugs. Then fix the bugs.
Then review the work and determine the value and how to wield this new tool. It replaces reading, writing, and editing - not thinking.
The revelation to me was that I used to code what I know, now I could code what I don’t know. The common path is that when I face something I don’t know, which is quite often, to move forward I have to level up my understanding.
I've been very pleasantly surprised. The combination of the compiler improvements in Elixir 1.20 and the structural guardrails from Ash seems to have led to very consistent, organized and readable code.
Once you have something concrete you can iterate on the prototype until it's a mess. But, hopefully, in that time you got closer to figuring out what you want. And even if the code for the prototype is a mess the "idea" of it should be cleaner. I like to have an LLM make a new spec at that point, and start fresh with it. You can clean up the abstractions and the UX there.
When writing code is cheap figuring out what you want to write is the hard part. It always was, but the barrier of getting the code written and working made that less obvious.
Same story as building a house. There’s so many unknowns.
Does anyone want one?
The article says to stop building and go outside!
And actually, talking about climbing apps with fellow climbers is a great way to be outside.
> talking about climbing apps with fellow climbers is a great way to be outside.
Indeed. The climbers I met are very supportive. They helped me scan the gym, shared their own climbing footage, which is what I'm trying to do, visualize climbing in a 3D scene.