logoalt Hacker News

bigstrat2003 • today at 1:40 AM • 1 reply • view on HN

Personally, I believe that the supposed productivity gains of LLMs will turn out to be much like outsourcing to India around the turn of the century: managers think it's a great idea to cut costs, but it will also make quality plummet, and there will be a correction back towards sanity. That doesn't mean that everything is all roses - even if the market will get over the AI insanity someday, that's cold comfort if you're out of a job right now. But I do think that it's not going to be "if you aren't on board, then gg" in the long run.

Replies

gravypod • today at 2:05 AM

I have already seen multiple CLs from people who are both senior and junior where I know they did not look at the code. I thought, at first, they worked and upon review it looked good but when I synced these changes I found either big bugs that a human would never make or a test would never catch or lots of code repetition.

One example was an engineer who was refactoring some code that ended up doing this:

    def execute(jobs):
      for job in jobs:
        asyncio.create_task(compute(job))
        yield await compute(job)
This is very simplified, it as actually broken up into two separate loops and hidden behind multiple nested calls but at some point there literally was a `asyncio.create_task` where the result was not being used.

I looked at this code because we were hitting some quota limits very early for some reason and it turned out we ran 2x the reads we needed to. I refactored this code, 1/2ed the execution time, fixed the quota issues, and took it from ~300 lines to 80 lines.

This was code from a *senior software engineer* with 15 years in the industry. What is very interesting is I see similar bugs from juniors who do or don't use AI.

I am not saying AI can't be useful. On weeks I have had clear tasks set out, while the rest of my team was OOO, I tackled probably 5x the work our team normally accomplishes (this was after all the work was identified, just working). My skip actually said "Wow, we had a very productive week!" so multiple layers noticed the productivity. I think what made this possible was:

    1. I fully understood the **entire** task and the end-user needs.
    2. The code base was structured "fine" with enough decoupling between components that I wasn't hitting merge conflicts with myself.
    3. I self-reviewed all the work before sending anything to other people (opened all the changes in my IDE, read all the tests).
    4. If something seemed too complicated I refactored it manually. 
    5. I left the AI chugging for long periods of time on objectively measurable tasks.
I don't think the practice of engineering software is dead. The architecture of your software now has measurable impact on productivity. I don't think thinking about performance is outdated. If you're running code no one has reviewed but is functional you wasting cycles / money. Having domain knowledge still improves your velocity.

Because of these reasons I think there is still marginal value to programmers. Companies which maintain internal talent pools and build tooling to scale the impact of people will probably beat out smaller companies that just vibe code.