Hacker News Reader

Comment by Maro | Hacker News Reader

A good model for understanding what happens to people as they delegate tasks to AI is to think about what happens to managers who delegate tasks to their subordinates. Sure, there are some managers who can remain sharp, hands-on and relevant, but many gradually lose their connection to the area they're managing and become pure process/project/people managers and politicians.

Ie. most managers can't help their team find a hard bug that is causing a massive outage.

Note: I'm a manager, and I spend a lot of time pondering how to spend my time, how to be useful, how to remain relevant, especially in this age of AI.

View on HN

Indeed. I started using Sonnet for coding only about a month ago. It's been great in that I've finally written scripts I had floating around my brain for years, and very rapidly.

But the feeling of skill atrophy is very real. The other day I needed to write a function that recursively traverses a Python dictionary, making modifications along the way. It's the perfect task to give an LLM. I can easily see that if I always give this task to an LLM, a few years down the road I'll be really slow in writing it on my own, and will fail most coding interviews.

Also, while there is a high in producing a lot in a short amount of time, there is no feeling of satisfaction that you get from programming. And debugging its bugs is as much fun as debugging your coworkers' bugs - except at least with the coworkers you can have a more intelligent conversation on what they were trying to do.

This is exactly why I still play Go, practice martial arts, archery and use the command line for my dev workflow. Those are all arguably less efficient and obsolete. The AlphaGo series can defeat the strongest human Go players and firearms are more effective than unarmed martial arts and archery. GUI is easier for most people than the command line. Yet, I practice all these to develop my mind and body. I don't have to be a world-class Go player to benefit from learning to play Go.

This happens a lot in the natural world in ecosystems. For example, many people plant trees and add a drip system. The trees grow to depend on the drip system, and never stretch and develop their roots -- and the relationship they have with the soil microbiome. They make the trees prone to get knocked down when an unusually strong gust of wind come through.

You might have my favorite profile page here, with the exception of DonHopkins.

Just beautiful concepts, inspiring, and well-represented in this comment.

Peace be with you, my friend.

> This is exactly why I still play Go, practice martial arts, archery and use the command line for my dev workflow.

And this is what worries me. Pre-LLM, I'd get all my practice done during work hours. I fear that with LLMs, I'll need to do all this practice on my free time, effectively reducing my truly "free" time.

> Pre-LLM, I'd get all my practice done during work hours. I fear that with LLMs, I'll need to do all this practice on my free time

If you can attach a valid business reason/excuse then it's fairly easy to get time dedicated to experimentation and learning.

I haven't been a coder for several years now, but I still try to justify a personal lab environment in order to understand the market and customer problems.

If you're an Engineer or EM, I think it would be even easier (attach experimentation to some sort of critical engineering initiative).

Even with Code Gen Copilots becoming a thing, between the lines most of us in engineering and business leadership recognize it cannot replace architecture or design. If it can, then you've solved the Turing or Chinese Room problem and that's a whole other story.

That said, if your day job isn't only "write this terraform/python script" you shouldn't be at risk.

> If you can attach a valid business reason/excuse then it's fairly easy to get time dedicated to experimentation and learning.

This has the same problem as "doing it in free time". I have a finite number of goodie points with management, and I'd be using some when I request this - which means I have fewer things I can request from them in the future.

> That said, if your day job isn't only "write this terraform/python script" you shouldn't be at risk.

I'm not worried about the present, or even the near future. The reason I have other valuable skills is because of the years I spent on writing code. Eventually, I'll stop growing if I rely too much on LLMs. I may have to rely on them if everyone else is and being more productive.

The Turing test can be considered well and truly passed at this point, partially because it has always said more about the human taking the test than it did about the machine. As for the Chinese Room, it was never anything but a pointless exercise in question-begging. If anyone ever considered it relevant, the advent of LLMs should have immediately convinced them otherwise. Searle knew nothing about embedding vectors, never mind attention.

Great points otherwise, though. A strong focus on identifying, understanding, and solving customer problems is, in modern parlance, all you need.

I had someone give me a good use-case for LLMs -- such as, doing the CRUD work that I really don't want to do, if you are short on funding.

On the other hand, there is something I learned from permaculture design. You need to allow what you want to grow in the ecosystem if you want them present. If I wanted to develop the next generation of developers, then I'd be giving that CRUD stuff I've done many times to a junior developer instead. It obviously depends on funding, and whether your investors are on board with that.

As far as keeping up and remaining competitive ... my suggestion is to learn these things in a way where you can broadly apply the underlying principles in other domains, especially that, as you age, your working memory will shrink. This isn't accumulating more of the same thing, but gaining deeper insights that can only be found when you've developed a sufficient level of skill. There are lots of ways this can be accomplished.

> You need to allow what you want to grow in the ecosystem if you want them present. If I wanted to develop the next generation of developers, then I'd be giving that CRUD stuff I've done many times to a junior developer instead.

Indeed, one of my fears is that people won't develop those skills to begin with. In my team, the few senior people can pretty much be trusted with using LLMs and still producing quality code. But we decided against evangelizing it to the junior folks. They still have access via Copilot, but we won't gently suggest they try it out.

Coding is actually a hard skill which requires practice. Regular litcoding for the sake of it should help. The problem with that is it takes the whole brain and breaks other thoughts chain. I'm thinking about to dedicate full days for small tasks like this.

> Regular litcoding for the sake of it should help.

I got where I am without regular leetcoding. For me, regular leetcoding will only marginally improve my skills. And I definitely don't want to do regular leetcoding just to maintain my skills.

You know how many people love jogging outdoors but hate treadmills? Leetcoding is like treadmills. You may have to do it, but it sucks. Yes, some people love treadmills, but they're in the minority.

There’s two kinds of leetcoding. Leetcoding via memorization obviously sucks, but leetcoding by clicking next problem until you get one thats totally alien and then letting it mull in the back of the head for a few days to crack it without reference material is pretty fun

After being a professional programmer for ~20 years, and recently playing around with leetcode - my main issue with leetcode is that there's almost no overlap between leetcode problems and the problems I actually encounter in the wild. The validation tests often have silly corner cases that force you into a single answer to avoid timing out. It's frequently as much work to understand what the problem is actually asking you as it is to implement a solution. Just like I've found ChatGPT to be pretty mediocre at writing the sort of code I work on, but others swear by it, maybe some peoples' dayjob actually looks like writing leetcode all day? I know a lot of interviewers use it, but it feels so disconnected from actual engineering work.

My line of work (ML for medical imaging) is pretty dense with leetcodelikes, especially the classic “what’s the best time complexity? Great now whats the best space conplexity”

I'm working on sort of 'graph' library. It's litcoding all the way. There are many separate containers and algorithms. The problem to a) write them b) optimize for memory c) optimize for performance d) find a 'good' balance where 'good' is undefined. But it starts with architecture which is based one some estimates of achievable functionality/performance.

What if, like me, you hate both jogging outdoors and treadmills?

the flip side to that “high” that comes with working super quickly for me has been a crash associated with a sinking feeling that I’ve outsourced too much.

I started using a C compiler for coding about 30 years ago. It's been great, but the feeling of skill atrophy is very real. I probably couldn't write useful code in x86 assembly any more, at least not without refreshing my memory first.

And you know what? That's just peachy keen. I don't need to write x86 assembly anymore. In fact, these days I do a lot of coding for ARM platforms, but I never learned ARM assembly at all. So it would take more than just a refresher course to bring me up to speed in that. I don't anticipate any such need, fortunately.

So... if I still need to write C in 10 years, why in the world would I consider that a good thing? Things in this business are supposed to progress toward higher and higher levels of abstraction.

I have extremely high faith that the C compiler will produce very reliable x86 assembly code.

I am extremely pessimistic that LLMs will ever reach that level of reliability. Or even close. They are a great helper, but that's all they'll be.

What are some examples of prompts and responses that have made you pessimistic about the technology's ability to improve? Reliability has gotten insanely better over the past couple of years, and it's still improving.

> What are some examples of prompts and responses that have made you pessimistic about the technology's ability to improve?

I'm not saying it won't improve. I think its lack of determinism puts a natural upper bound on reliability - something we don't have to worry about with compilers.

As for examples: Oh wow. As much as I love and use them for coding, almost every project I work on has cases of coming up with complex solutions to a task that do not work, where 1-2 lines of (simple!) code would have solved the problem. It's not just that it fails, but it kept failing even after I told it how to do it right.

Sometimes it does a great job and solves a hard problem for me. Other times I lose a lot of time getting it to do beginner level stuff. It has huge gaps/blind spots.

I think this is the primary reason I have difficulty with management: my brain simply doesn't really work out (in the fitness sense) in the cognitive way it is used to, but instead has to track all sorts of problems, many of which are emotional/political. Those problems are often emotional/political and thus not really something I can readily solve by thinking real hard about things.

That's what the money's for!

I think this is a really good analogy. Delegating problems to others is nothing novel or new to human experience.

Perhaps the biggest difference is the lack of feedback AI gives that humans can give: a subordinate can communicate if they feel like their manager is being too hands off. AI never questions management style.

It's also like trying to manage the most prolific bullshit artist the world has ever produced.

This is a good analogy, and not just because of skills atrophy.

Managers grow the skills needed for their organization. Their team affects them.

A process-oriented team with quality/validation mindset has replaceable roles; the action is in the process. An expert team has people with tremendous skills and discretion doing what needs doing; the action is in selection and incentives. Managers adapt to their team requirements, in ways positive and negative: becoming rule-bound, privileging favorites, etc.

With AI this might be a positive insofar as it forces people to state the issues clearly, identifying relevant context, constraints, objectives, etc.

Agile benefitted software development by changing the granularity of delivery and planning -- essentially, helping people avoid getting lost in planning fantasies.

Similarly, I believe that the winner of the AI-for-development race (copilot et al) will not just produce good code, but build good developers by driving them to state requirements clearly and simply. A good measure here is the number of iterations to complete code.

An anti-pattern here, as with agile, is where planning devolves into exploring and exploring into incremental changes for no real benefit - polishing turds. Again, a good measure is the number of sessions to completion; too many and you know you don't know what you're doing, or the AI cannot grasp the trees for the forest.

> Ie. most managers can't help their team find a hard bug that is causing a massive outage.

Strategy vs tactics. Managers aren't there to teach their reports skills, they hire them because they already have them. They're there to set priorities and overall direction.

He's not disputing that. The difference, though, is that if you're using LLMs as code assistants, your skills will atrophy the way the manager's skills will, but you are still a SW engineer.

While the manager doesn't need those skills, you still do.

LLMs and agents are going to make labels like 'sw engineer', 'qa tester', marketer, CFO, and CEO very squishy.

I think in the coming decade if you put yourself in a box and do a specialized task, and nothing more, you'll have a bad time. This is going to be an era where strategy is far more important than tactics.

This assumes all specialized tasks are fungible.

I can't disagree more strongly. If you're a specialized person with expertise and ability to perform outside the knowledge of all possible interns because you're developing something novel and not covered by standard materials, you'll be hard to compete with using AI because AI will direct people to standardized methods.

Granted, if you do a specialized task that is taught in schools and that anyone can do, that's trouble. But that's not tactics either, that's clock-punching. That's replaceable. You can talk 'strategy' all you like but if you're only exploiting the AI's ability to do what people already know, that's another box to be stuck in.

I think we're in agreement then, I'm saying the specialists of this stripe:

> if you do a specialized task that is taught in schools

are in trouble, and so are you.

> perform outside the knowledge of all possible interns

This is the strategic level thinking I'm referring to. Frankly this role might not be safe either, but if that's the case then we're probably headed for fully automated luxury communism no matter what we do.

What if you use it to handle boring BS work you don't care about and focus on what you actually want to do? I offload my work tasks to GPT and do other stuff during work hours. Play with my dog. Stretch. Paint. Work on other creative projects. I don't give a fuck about work as long as they keep sending me a paycheck. Oh no! My brain is going to atrophy from not manually synthesizing info from this report that no one reads anyway.

real

Startup idea: Farts_Mckensyly

Do all the work Farts_Mckensy does at half the price using AI.

I assure you, it wouldn't be very lucrative.

Fellow manager, it will do you good to realize that we are not in an "age of AI". Out there it's the age of disinformation.

Reply on news.ycombinator.com