Hacker News Reader

If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above.

And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above.

Even much of the "validating releases" and "testing" parts should also be things that a decent PM should be able to wrangle now by themselves with some LLM agents to assist them. Afterall, why bother about code quality of a testing harness. So long as the PM can keep a coherent test case list and have end to end tests that cover them, programmers can leave that to them as well.

Well, it's true. In a world where code is commoditized, a PM who knows exactly what the customers' needs are will be much more successful than an engineer who does not. Not sure what is controversial about that.

Why not have the customer talk to an llm and iterate on the plan? Many customers will appreciate the 30m back and forth replacing the multiple hour meetings.

People are subtracting a lot of hard parts from their thinking, and think it's simpler than it is. What happens when the test suite isn't testing the real thing? The ci/cd doesn't even start? There is a bug requiring a hot fix ASAP? The code is growing into a nasty meatball and spaghetti dish, and the llms just turn shift it around. What about when the agent starts thinking in circles and neefs guidance to start working?

I'm not a ludite: I use llms every day, but I try not to be a meat proxy. Some one off scripts are vibe coded, but applications need real maintainable code.

My prediction for winners and losers: some companies will lay off a ton of programmers and replace with AI, with short term success but long term big problems. Other companies will use llms to boost productivity, but keep their engineers responsible for the health of the products. Short term gains won't be as impressive, but productivity will be higher and the company will be competitive in the long term.

> Why not have the customer talk to an llm and iterate on the plan?

They already do that, hence the SaaSpocalypse. The hope for these AI companies is that the models get better than engineers such that the answer to all your questions is that the AI will handle it.

> They already do that, hence the SaaSpocalypse

The market believes they will do that, hence the SaaSpocalypse. very important difference

No they already do do that. I know many companies building internal tools with LLMs.

sure, does your dad also work at Nintendo?

One is verifiable, if you don't believe maybe you should ask others in the field too. Or maybe you're just wrong and won't admit it, clutching to your preconceived notions.

if it's verifiable, I'd love for you to verify it. I don't consider hearsay a strong form of verification

> maybe you're just wrong and won't admit it, clutching to your preconceived notions.

I assume in your world this is only something other people do, but your judgement is perfect right?

https://youtu.be/9Q9Yrj2RTkg

https://youtu.be/HQXi4snP36I

A simple Google search found these, maybe you should look harder when looking to verify something instead of dismissal. My judgement is indeed perfect in this comment because, as I said, it is verifiable that it is happening, unless you think that no company at all is building internal tools with AI which would be the counter example to my claim that at least some are. Not even sure what your point is here, because your counter claim is nearly unfalsifiable unless you know every single company's operations in the world.

I think the controversial part is that an engineer cannot talk to or understand customers.

A test doesn’t prove much.

Highly experienced programmers seem to have a hard time understanding this.

Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?

LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.

> Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?

Do those tests test the right thing?

Adding more features is given higher priority vs optimizing current features.

Arent humans the weakest link in security, click on some random link and enter your credentials because the fake site looks legit.

It’s getting everyone to understand the problems, working together (etc)…

There are manuals for this too, and interestingly enough this has been studied since the Romans at least! Is it then really the hard part?

Apparently it is. Modern companies seem to prefer dysfunction over anything else. I have been trying to understand why for my whole career.

Competing incentives and the natural result of dealing with lots of people mostly

Two things...

Firstly, I agree with you on all those things.

One aspect of the programmer you are missing is managing complexity in a system. This i find to always be the main goal of the programmer. As design changes, it's easy to code a solution, it's hard to anticipate the direction, build extensible systems, and not compromise other demands that happen now.

Another is communication. Using code to express a solution concisely, in clear language, and with an abstraction that doesn't compromise that correspondence to reality.I often have to steer an AI model a bit to use the correct terms and I will often "rephrase" their code to match my view of the world.

Organization is too abstract here.

It also depends on how you model the problem. You can easily say the hardest part is hiring people if you are the boss. Since the people you hire can do everything else that needs to be done.

Managing and motivating people is the hardest part for the person who is doing it.

If you are hiring you might say it is harder to find good managers than programmers.

It is not measurable who did a good job at what as almost everything requires a group of people doing different things.

You can see how pointless this is becoming as we don’t have a measure for anything.

This kind of problem requires assumptions because it doesn’t hing on anything natural.

For example, if you start by believing salary indicates value then you can go from there.

In the end there are millions of managers, millions of programmers, millions of ux designers etc. It is kind of funny to suggest doing any of these is inherently harder than the other.

Just imagine you are judging a project. You have everything about it recorded. How hard do you think it would be to judge who had more part in the outcome in what way? If 10 people judged it separately, how many would have similar opinions etc.

It is impossible to judge even for a specific case, so it is a joke to consider to find the universal rule for it.

In the end it is ok to believe something but it is also important to not forget that it is a belief

Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.

They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)

Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.

I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability.

But these are skills that can be taught to individuals.

But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.

Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.

What we’ve been delving into for the last decade has been a decline in the value of labour and work.

“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.

1000%. The expense of writing software was and still is high.

Whether it’s commercial software company or an internal team writing custom software, the return on that investment depends on many things outside of the code itself.