umm thats the issue in most startups. code has docs. product fit does not.
"AI has made coding the easy part."
"Things that used to take six engineers three months to build, "my friends and I, we'll just build on a weekend," Ng said.
The man has a complete disdain for the field and for the thousands of open source developers whose code he is using in laundered form.
All of culture and technology builds be accreting on top of previous works. I can’t stand the moral outrage from people who are themselves standing on the shoulders of giants.
On top of this there’s also a confounding factor where it seems we can all do things we couldn’t before. So everyone is trying to reduce their dependencies and increase their offering. Which is driving down opportunities. The world of business is turning into one of those one-sided conferences where everyone is either look for a job, or looking for a sale. No-one is hiring. No-one is buying.
"GREAT! That means we can fire the people who do the actual work, and replace them with MBA robots, who neither understand nor care about making a good product"
Pardon my pessimism, but in my whole career, I have never met a PM who actual did the work of driving the product vision. Most were just middlemen shuttling information between management, marketing, design, and engineering. Thinking that hiring more PMs would increase the output in the age of AI is such a childish fantasy.
LLMs cannot, they need vast bodies of stolen text to become remotely useful. For all activities, humans need less training material than the laundromats.
Aside from that, there are legal, philosophical and economic arguments that machines are not the same as humans and do not deserve the same rights. 99.99% of the world population outside of SV hype circles would agree with that.
It might be that the gp is smart enough to code without a crutch.
The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.
You seem to have a deep misunderstanding of the value PM's provide. What you describe as "just" is a challenging job.
Generally, the vision is set by the founder, and it can be written down in a sentence or two. There's a ton of work trying to translate that vision into something that is coherent across engineers, customers, sales, and marketing.
Hardware startups could still use funding.
I don't want to speak for the person you replied to, but I think that their main point is... are they?
I see lots of articles about huge increases in productivity, but I think it's fair to argue that we've yet to see the huge increases in useful products that would surely (we hope) result from that if it were true.
Its a tragedy as its undervalued - I firmly believe apples products are significantly worse if their engineers led it. Jobs made those products
Literally all the time? Every single month?
I am struggling to understand your perspective. In my existence, the bottleneck is always the coding.
The development team has a backlog that could keep them busy for years. Meanwhile, everyone else -- QA, localization, whatever -- operates at whatever pace the code gets delivered.
Never in my entire life have I been in the situation where the engineering manager said, "well folks, localization is backed up so we've got no more code we need to write. Go home and check in next week to see if we have any work?"
The only exception I can think of might be videogames where the bottleneck is the art and then maybe the testing loop. But gaming isn't representative of software development generally at all.
People should realize that denying that AI can boost productivity in coding makes it look like they don't know how to use it, or believe in some conspiracy that no one is actually benefitting and it's all market hype from tech bros.
Also, in product feature teams it is up to the debate whether PMs provide any value, if you put engineers closer to customers. For the PM role to work, they need to convey customer requirements to product requirements. I have never seen a PM do a better job at this in comparison to just sending a TL to a video call with a client.
Most of the Internet ifra depends on libxml2, major vendors like Juniper and Cisco use it. To my knowledge Android use it as well,
Naturally, with the advancement of AI, one would expect XML would be first thing to rewrite, given that library is in the critical path literally everywhere.
This is still part of “coding”. It doesn’t make any sense to say you’ve “finished coding” when the program doesn’t actually work as required.
I’ve been aghast to see developers present an unequivocally broken product and try to argue making it not visibly broken is “scope creep”.
I mean, that’s why we argue so much about the best ways to write code: we want to reduce the incidence of bugs and make it easier to correct unexpected errors.
Figuring out libraries, deciding on architectures, researching documentation, that's an integral part of coding.
The topic here is not keystrokes.
Initially I didn’t mind it because my team focused on technical debt, but it pretty quickly turned sour. Having to scrape up “work” for the team of 6 engineers each morning to appear productive to management was dreadful
If you like working in software because you enjoy writing code, I predict you’re gonna find it harder to make this pay. (Though leisure coding will likely get more fun, and there will always be niche CS-type roles that require inventing new technical systems.)
If you like software because you enjoy making things that people find valuable or entertaining, then I think you’ll do just fine.
I've shadowed people who believe AI is helping them, and it seems to me that some of them don't notice how much effort they're spending while others don't bother to correct the 80% version once tests are passing.
As you imply, that role is really more a director role, not a manager role. A manager managers, a director directs, including the vision and product market fit. Most Product Managers I see do not have that authority at all, and at best are constantly having to convince "leadership" like some door-to-door salesman, rather than simply updating leadership in an advise and consent format.
https://www.businessinsider.com/andrew-ng-vibe-coding-unfort...
So, at least his investors that he convinces are paying him. I do not know if he has other engagements in that area like speaker's fees etc.
well, in my experience as a developer integration between different systems with different views about how things should work is often the most challenging part of the job, so what you describe sounds like it would be difficult.
Otherwise it sounds like "many people have had their lives changed by {insert philosophical/religious movement}, so if you're not finding it true you should look into what's wrong with you."
First of all, nobody is writing and open sourcing their own XML parser in 2025, so that's hyperbole.
Second, the boilerplate to use most XML libraries can be copy/pasted out of their docs. So where is AI saving you time here? The prompting and other BS is a waste of time and just looks silly, and you still have to read and understand the code. At best it seems like breaking even.
I get that people are anxious, worried, and are going through the "cycles of grief", but do you really think that in another 2 years, let alone 5 it won't be able to code a good XML library? We are just going to have to see how things go, because they are clearly going to go, whether we want or not.
And what does open source and the quality of projects have to do with it? There were bad open source projects before GPT's release.
One thing I've noticed about the super-AI enthusiasts on HN is that not a single one ever have a single comment linking to a repo of work they've made with it.
I check. I actually always do because I'm really keen to learn how to use these magical super-AI workflows. I've watched streams, replicated clause MD files, tried all the context tricks.
I'm not even saying AI doesn't help, it's great for getting me over the blank page writer's block. It's just not great at much else.
So I've just checked your comments and not only do you not have any examples of your super-duper AI skills, but it looks like you've been in the industry less than a year, graduating from a PhD last year?
You also admit it took you a week trying to debug a problem before an AI fixed it for you. Because you'd missed some parentheses in an algo.
I'm not trying to shame you, but that does signal your inexperience. If you'd have made the code well and easy to test, you should have spotted your bad algo quickly.
So is it that we're all bad at using AI? Or is it that AI benefits inexperienced programmers more?
Product management was interfacing with the client, understanding what is actually supposed to be built as vision, understanding UI/UX before that became a field of its own, coordinating usability sessions, and so forth.
Naturally they have common touch points like what is possible from the vision, given the actual budget and available resources, expectation management and what not.
Unless it is a team of senior folks with top skills, the team manages itself never works.
"Ignore your own direct experience, only research papers matter" is certainly a take.
The beautiful thing about the current generation of tools is that they are so incredibly cheap relative to historical tools intended to improve engineering productivity. You can't just run out and pick up CASE tools for less than ~$CAR to ~$HOUSE. A pro subscription to whichever AI tool you want to try is $20.
Ignore research, try them, if you have success, use them. There's no dogma here. Just empiricism.
The bad algo was a scaling problem for one equation. That particular equation wasn't some y = mx + b thing, it was the result of a discontinuous galerkin finite element scheme that I wrote from scratch. The actual equation was one that I found after about 2 pages of hand written derivations with high level math. Not really a coding issue, just an algebra issue after really intense manipulations of partial differential equations.
The fact that AI found that problem, a problem that could only be found by someone able to do complex manipulations of PDEs is incredible to me. Perhaps I didn't tell the story well in the past comment, but it isn't like I didn't know python syntax and AI held my hand.
I don't post repos because I keep my hacker news life separate from my personal life, and my repos are tied to my name.
Most major software companies are demanding that their employees use AI, so you should be able to look at any open repo from Google, Microsoft, Facebook, etc for examples of AI use in code.
But yes, the next few items for the team to work on should always have the necessary specifications to start work. Whether it's UX mocks or a requirements document or whatever. Having that stuff ready to go is a primary job of the PM who manages the backlog.
Obviously the engineering team then has to break it down further into tasks to complete, but that's what engineering is. And you will run into areas that turned out to be underspecified and the PM needs to liaison with other folks to figure out answers, but again that's part and parcel. That's not generally stopping the whole team from work, and teams often work on multiple features at once so even being temporarily blocked on one doesn't keep you from progress on another.
I don't know what this means. Engineers are not generally spending half their time talking to management, marketing, sales, customers, and other stakeholders.
> Also, in product feature teams it is up to the debate whether PMs provide any value, if you put engineers closer to customers. For the PM role to work, they need to convey customer requirements to product requirements. I have never seen a PM do a better job at this in comparison to just sending a TL to a video call with a client.
Great, but ten different clients want ten different product requirements, that in fact contradict each other. And it takes ten hours of calls to talk to those ten customers.
Plenty of engineers could certainly do the PM job. Many PM's come from engineering. But the point is that it's far more efficient and effective to have one person doing that, and let engineers do the engineering. That's the value. As an engineer, do you want to spend 20 hours every week talking to customers and writing feature specifications and managing a backlog? Or do you want to do, you know, engineering?
Just because you could do the PM job doesn't mean that's an efficient use of your time, or what you enjoy doing.
The 'more efficient' part is where reasonable people disagree, a lot, and very often, in these threads
To replace libxml2 across these ecosystems you would need it to be API-, ABI, and probably bug-compatible with a decrepit old C library. That's not something anyone or anything can write from just the XML spec.
- in professional settings, I internally feel more pressured to complete product thinking 'faster'. I don't yet see product management being the bottleneck though, it is still code (or getting people together) - in personally settings/side projects, def. What to build has become so much more important. But I also feel it has taken the pressure a Lil off bad ideas, when the cost of building has reduced.
Project Management = Day to day to execution, logistics, resources, schedules. Scheduling meetings, sending out meeting minutes etc
Program Management = Team management towards delivering business goals/product launches on schedule
Where its tricky is the differentiation between project and program management. IMO we dont really need both terms or both roles, causes uneccessary/unnatural separation of responsibilities
I’ve never had a shortage of work as an engineer, but that doesn’t mean that work has always been perfectly optimized to business priorities - there’s plenty of other bottlenecks in the process that are not coding.
If you look into the courses, each one is basically a ~1 hour infomercial made in collaboration with a commercial company that is selling a product.
Just to pick one off the top, here's "Fast Prototyping of GenAI Apps with Streamlit"
Description: "Build and iterate GenAI apps in hours instead of days! Start with a simple chatbot, then add prompt engineering and RAG powered by Snowflake’s secure data and LLM services, then push your prototype to Snowflake or Streamlit Community Cloud for instant feedback and quick improvement."
Instructor: "Dr. Chanin Nantasenamat is a Senior Developer Advocate at Snowflake, where he creates educational content for Streamlit and teaches developers to build interactive data apps."
Every one of his "courses" are like this. It's fucking disgraceful.
There's that word "just".
There is no way Andrew Ng—Stanford professor and cofounder and former head of Google Brain who is 49 years old with a net worth of $100m and has written 200 research papers—is calling up his friends to come over and vibe code on the weekend. Does he entice them with pizza and beer? And at the end of the weekend they lean back, look at the AI's handiwork, and slap each other on the back, congratulating themselves on not taking three months to produce this thing they are going to ignore? (Or does Andrew Ng and his buddies have a new startup's worth of code every Monday for the last couple of years?)
I mean, if that was my situation I'd like to think I'd spend time coding, but herding a bunch of other millionaires to get together and think they're competing, John Henry style, with actual, dedicated engineers doing it "the old way" seems unlikely.
As engineering becomes less expensive with generative models I can imagine efficiency tilts even further in favor of engineers doing more PM-like work.
And solvers are actually a simpler aspect of the project I am working on. It also includes (or rather aims to include) optimizing compiler with DAE to ODE reduction, advanced numerical debugging etc.
This is why these discussions are pointless - AI works well for some people in some contexts, for others not so much, yet both sides extrapolate their experience as universal.
The way I see it, product management is not a role, is a discipline. There needs to be more partnering in software. E.g. pair a project manager with a tech-lead, together they do product management.
It seems like developers used to always joke about how much they used stack exchange (even senior devs). Now it seems like there are suddenly so many people who claim to never need any help and can just smoothly bust out beautiful code all day long.
Maybe you just think you're being more productive ;)
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
For basically every thing you program, you need to have a really solid understanding of what data structures you will use, and solid general knowledge of the methods you want to implement.
I claim that as a conservative estimate at least 90 % (likely more than 95 %) of what I code at work (and even more for what I code privately) is of this kind.
We want PMs to understand the market, the tech, the customer, and the economic value of building a product.
We then ask them to tell us when it will be built, down to the discrete feature and function, be a technical expert for the field and engineering in the product space, ask them to convey the roadmap and timeline to customers and prospects, build reports about everything from utilization to capacity, save deals by changing timelines for “just this one feature”, participate in product marketing, and understand how their product space co-exists in the complex product offerings from a company.
“You are the Chief Product Officer for your product!” is the promise and rallying cry. That’s not an accurate description of what most PMs do and even fewer are capable of doing.
You can also argue that good devs translate requirements into code perfectly with zero bugs, but it's also a rare skill and I've never seen that.
Because in the real world, nobody's perfect. The good news is you don't need to be perfect to still add lots of value.
Demanding a standard of perfection from others, that I would hazard to guess you do not meet yourself, is rather uncharitable.
I have a couple times, but they didn't have an MBA. Unfortunately though if you have an incompetent C suite or board, it's hard to get anything meaningful done no matter how good the team under them is.
Get a committee together to decide multiple products priorities, features, designs and you could be months away from having anything defined enough to code.
On one hand, I see these artificial constraints making it hard for individuals of varying skill set (outside of the imposed constraint) to contribute better for a group of people working together. This is when startups say they are scrappier and ‘just do it’ instead of being bogged down by bureaucracy.
On the other hand, having these artificial constraints makes it very easy for hiring, training, communication and alignment, all which are also important in a functioning group.
I work at a place where I interact with customers of various sizes. Sometimes I wonder why larger companies come up with this weird bureaucratic political system of constraints limiting their employees.
Other times, I wonder why some smaller companies let their employees manager a critical system when they seem part expert but not really capable of handling it end to end yet.
The developers would have to help with the requirements and planning all the code changes. That implies a huge amount of non-coding work was done by the developers.
The backlog comes from the PM, as user needs are established.
The requirements come from a mix of PM and UX.
Obviously developers plan how to write the code. That's part of coding. Not part of product requirements.
Imagine an architect who never writes a line of code. Under your accounting, they're doing coding, because it's the planning for code.
Again, wrong analogy. I don’t demand perfect analogies though. Treat this as rather charitable gesture.