I coded up a crossword puzzle game using agentic dev this weekend. Claude and Codex/GPT. Had to seriously babysit and rewrite much of it, though, sure, I found it “cool” what it could do.
Writing code in many cases is faster to me than writing English (that is how PLs are designed, btw!) LLM/agentic is very “neat” but still a toy to the professional, I would say. I doubt reports like this one. For those of us building real world products with shelf-lives (Is Andrej representative of this archetype?), I just don’t see the value-add touted out there. I’d love to be proven wrong. But writing code (in code, not English), to me and many others, is still faster than reading/proving it.
I think there’s a combination of fetishizing and Stockholm syndroming going on in these enthusiastic self-reports. PMW.
A) The modern extreme thirst for dopamine predates the Internet. We've had powerfully addictive and destructive street drugs for decades now and art and creativity still thrive.
B) People who are not (or don't believe they are) in full control of their lives, which is most of the non-rich on the planet, generally are subject to having to spend a lot of time doing things they don't want to do, and want some form of escape.
Any medium will be a trap that can catch people who would prefer to escape permanently, whether it's good for them or not. I'm sure you had children and housewives addicted to radio shows in the 1940's.
For creatives who are dedicated to their craft and are not in it for mass-market leverage, this is fine, it's going to be a filter. The people who get caught in these traps are not going to be the ones that can appreciate or support art, even if it's not their fault.
I feel like I've been meeting people of different ages (strong bias for millenials) that just don't enjoy the internet anymore. And yes, most are addicted to this dopamine drip, yet it makes me optimistic that something _is_ changing.
> but the truth is that behind the volatility and public speculation, there has been a smooth, unyielding increase in AI’s cognitive capabilities.
> We are now at the point where AI models are … good enough at coding that some of the strongest engineers I’ve ever met are now handing over almost all their coding to AI.
Really?
All I’ve seen on HN the past few days are how slop prevails.
When I lean into agentic flows myself I’m at once amazed at how quickly it can prototype stuff but also how deficient and how much of a toy it all still seems.
The disconnect is weird isn't it? The latest coding models can churn out a lot of mediocre code that more or less works if the task is sufficiently well specified, but it's not particularly good code, they have no real taste, no instinct for elegance or simplification, weak high level design. It's useful, but not anywhere near superhuman. It's also my impression that improvements in raw intelligence, far from increasing exponentially, are plateauing. The advances that people are excited about come from agentic patterns and tool use, but it's not much higher levels of intelligence, just slightly better intelligence run in a loop with feedback. Again that's useful but it's nowhere in the realms of "greater than Nobel winning across all domains".
Outside of coding, the top models still fall flat on their face when faced with relatively simple knowledge work. I got completely bogus info on a fairly simple tax question just a few days ago for example, and anyone using AI regularly with any discernment runs into simple failures like this all the time. It's still useful but the idea that we're on some trajectory to exceeding top human performance across all domains seems completely unrealistic when I look at my experience of how things have actually been progressing.
This is one of those discourses that disappoints me about our industry.
Estimation can be done. It's a skillset issue. Yet the broad consensus seems to be that it can't be done, that it's somehow inherently impossible.
Here are the fallacies I think underwrite this consensus:
1. "Software projects spend most of their time grappling with unknown problems."
False.
The majority of industry projects—and the time spent on them—are not novel for developers with significant experience. Whether it's building a low-latency transactional system, a frontend/UX, or a data processing platform, there is extensive precedent. The subsystems that deliver business value are well understood, and experienced devs have built versions of them before.
For example, if you're an experienced frontend dev who's worked in React and earlier MVC frameworks, moving to Svelte is not an "unknown problem." Building a user flow in Svelte should take roughly the same time as building it in React. Experience transfers.
2. "You can't estimate tasks until you know the specifics involved."
Also false.
Even tasks like "learn Svelte" or "design an Apache Beam job" (which may include learning Beam) are estimable based on history. The time it took you to learn one framework is almost always an upper bound for learning another similar one.
In practice, I've had repeatable success estimating properly scoped sub-deliverables as three basic items: (1) design, (2) implement, (3) test.
3. Estimation is divorced from execution.
When people talk about estimation, there's almost always an implicit model: (1) estimate the work, (2) "wait" for execution, (3) miss the estimate, and (4) conclude that estimation doesn't work.
Of course this fails. Estimates must be married to execution beat by beat. You should know after the first day whether you've missed your first target and by how much—and adjust immediately.
Some argue this is what padding is for (say, 20%). Well-meaning, but that's still a "wait and hope" mindset.
Padding time doesn't work. Padding scope does. Scope padding gives you real execution-time choices to actively manage delivery day by day.
At execution time, you have levers: unblock velocity, bring in temporary help, or remove scope. The key is that you're actively aiming at the delivery date. You will never hit estimates if you're not actively invested in hitting them, and you'll never improve at estimating if you don't operate this way. Which brings me to:
4. "Estimation is not a skillset."
This fallacy is woven into much of the discourse. Estimation is often treated as a naïve exercise—list tasks, guess durations, watch it fail. But estimation is a practicable skill that improves with repetition.
It's hard to practice in teams because everyone has to believe estimation can work, and often most of the room doesn't. That makes alignment difficult, and early failures get interpreted as proof of impossibility rather than part of skill development.
Any skill fails the first N times. Unfortunately, stakeholders are rarely tolerant of failure, even though failure is necessary for improvement. I was lucky early in my career to be on a team that repeatedly practiced active estimation and execution, and we got meaningfully better at it over time.
Writing code in many cases is faster to me than writing English (that is how PLs are designed, btw!) LLM/agentic is very “neat” but still a toy to the professional, I would say. I doubt reports like this one. For those of us building real world products with shelf-lives (Is Andrej representative of this archetype?), I just don’t see the value-add touted out there. I’d love to be proven wrong. But writing code (in code, not English), to me and many others, is still faster than reading/proving it.
I think there’s a combination of fetishizing and Stockholm syndroming going on in these enthusiastic self-reports. PMW.
reply