Hacker Newsnew | past | comments | ask | show | jobs | submit | northfield27's commentslogin

Excellent article! Aptly describes what I have been feeling and thinking about the claims many AI optimists make.

---

> He produced a great deal of code, [...] He could not, when asked, explain how any of it actually worked. [...] When opinions were voiced even as high as a V.P., he fought back.

AI has democratized coding, but people have yet to understand that it takes expertise to actually design a system that can handle scale. Of course, you can build a PoC in a few hours with Claude code, but that wouldn't generate value.

The reason why we see such examples in the workplace is because of the false marketing done by CEOs and wrapper companies. It just gives people a false hope that "they can just build things" when they can only build demos.

Another reason is that the incentives in almost every company have shifted to favour a person using AI. It's like the companies are purposefully forcing us to use AI, to show demand for AI, so that they can get a green signal to build more data centers.

---

> So you have overconfident, novices able to improve their individual productivity in an area of expertise they are unable to review for correctness. What could go wrong?

This is one much-needed point to raise.

I have many people around me saying that people my age are using AI to get 10x or 100x better at doing stuff. How are you evaluating them to check if the person actually improved that much?

I have experienced this excessively on twitter since last few months. It is like a cult. Someone with a good following builds something with AI, and people go mad and perceive that person as some kind of god. I clearly don't understand that.

Just as an example, after Karpathy open-sourced autoresearch, you might have seen a variety of different flavors that employ the same idea across various domains, but I think a Meta researcher pointed out that it is a type of search method, just like Optuna does with hyperparameter searching.

Basically, people should think from first principles. But the current state of tech Twitter is pathetic; any lame idea + genAI gets viral, without even the slightest thought of whether genAI actually helps solve the problem or improve the existing solution.

(Side note: I saw a blog from someone from a top USA uni writing about OpenClaw x AutoResearch, I was like WTF?! - because as we all know, OpenClaw was just a hype that aged like milk)

---

> The slowness was not a tax on the real work; the slowness was the real work.

Well Said! People should understand that learning things takes time, building things takes time, and understanding things deeply takes time.

Someone building a web app using AI in 10 mins is not ahead but behind the person who is actually going one or two levels of abstractions deeper to understand how HTML/JS/Next.js works.

I strongly believe that the tech industry will realise this sooner or later that AI doesn't make people learn faster, it just speeds up the repetitive manual tasks. And people should use the AI in that regard only.

The (real) cognitive task to actually learn is still in the hands of humans, and it is slow, which is not a bottleneck, but that's just how we humans are, and it should be respected.


You mean you coding is fully coding agent driven?


I think I was right about AI coding tools, but I was probably just early: https://news.ycombinator.com/item?id=46769188#46782672

I’ve been using and experimenting with LLM-based coding tools for ~2 years, mostly in research systems, and I expected both the upside and the limitations to show up eventually.

There was a period mid last year to early this year where social media hype around AI coding felt very strong. A lot of the discussion was about agents and multi-agent setups replacing large parts of engineering work. My experience didn’t really match that level of capability in practice, especially when it came to larger codebases and long-term maintainability.

The gap I kept seeing was between small, impressive demos and actual production constraints like correctness, debugging, security, and system understanding.

I also remember seeing “vibe coding” discussed around that time. My initial reaction was skepticism because it felt like it was abstracting away too much of the engineering process. I might be misremembering details, but even now my view is that these systems are still not very reliable without strong human structure around them.

I don’t really blame individuals for the hype cycle. The incentives on social platforms and in the industry were clearly aligned toward showcasing success cases and productivity gains, so that naturally shaped the narrative.

My current view is not that these tools are useless. They are clearly helpful for many tasks. But I think the more interesting problem is how to integrate them into real engineering workflows without increasing maintenance burden or accumulating hidden complexity over time.

We probably need better patterns for using them in production settings, and better expectations around what they can and cannot safely automate today.


Haha, i was taking N4 and N6, but didn’t figure the steps after that.

To win we need to let knight die because rook can move multiple steps to kill the king.

From a third person perspective R2 is a deceptive move that takes advantage algorithm to make the black king back off to kill its knight.


you could also just move your king on that move same result knight cant move, only king can, so it has to back away


I have also felt something similar.

A few days back, I tried to implement a PDF reader by pure vibe coding. I used all my free Antigravity, Cursor, and Co-pilot tokens to create a half-baked, but working Next.js PDF-reader that (to be honest) I wouldn't have glued together without 2 weeks of work. As an MLE, I have done negligible web development using JavaScript and have mostly worked with Python and C.

But the struggle actually started after the free tokens were exhausted. I was feeling anxious to even look into those Next.js files. I am not able to describe, but it was probably some kind of fear - fear of either not being able to debug/implement a new feature, or not willing to put in precious hours (precious because of FOMO that I could do something cool with AI-paired vibe coding) to understand and build the feature myself.

I abandoned that project since that day. Haven't opened it yet - partly because I am waiting for the renewal of free tokens.


> If everything passes, it ships, automatically. If something fails, the agent fixes it. A human only gets involved when the system genuinely doesn’t know what to do.

This right here, he conveniently skipped elaborating how will a human fix a system he hasn’t genuinely built but just prompted. Writing code by hand helps you build a mind-map that is helpful while debugging. Without it, a human needs to go through all of the complex code. This is not efficiency, but delaying the heavy lifting to a later date, because system fail and they fail often (nowadays).

And based on how its phrased, it looks like AI has written this article.


Agreed but sadly, many people are too optimistic with AI and are completely forgetting that they can be the part of next layoffs.

And others are not able to believe the (not extreme) but visible speed boost from pragmatic use of AI.

And sadly, whenever the discussion about the collective financial disadvantage of AI to software engineers will start and wherever it goes…

The owners and employers will always make the profits.


> You can write 10x the code - good code. You can review and edit it before committing it. Nothing changes from a code quality perspective. Only speed.

I agree, but this is an oversimplification - we don't always get the speed boosts, specifically when we don't stay pragmatic about the process.

I have a small set of steps that I follow to really boost my productivity and get the speed advantage.

(Note: I am talking about AI-coding and not Vibe-coding) - You give all the specs, and there are "some" chances that LLM will generate code exactly required. - In most cases, you will need to do >2 design iterations and many small iterations, like instructing LLMs to properly handle error gracefully recover from errors. - This will definitely increase speed 2x-3x, but we still need to review everything. - Also, this doesn't take into account the edge cases our design missed. I don't know about big tech, but when I have to do the following to solve a problem

1. Figure out a potential solution

2. Make a hacky POC script to verify the proposed solution actually solves the problem

3. Design a decently robust system as a first iteration (that can have bugs)

4. Implement using AI

5. Verify each generated line

6. Find out edge cases and failure modes missed during design and repeat from step3 to tweak the design, or repeat from step4 to fix bug.

WHENEVER I jump directly from 1 -> 3 (vague design) -> 5, Speed advantages become obsolete.


Agreed


++Hard Agree.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: