"This tool 10x the productivity of software engineers"
"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.
I have worked with a few PMs that have been significant helps to my job but LLMs have completely destroyed my ability to work with them. "Oh I asked an AI to put together a demo for this idea and I presented it to leadership. When can you have it finished?" This is now a constant refrain, with LLMs seemingly convincing every PM I know that it is trivial to put together a reliable and maintainable system. "Oh let's just launch this and we'll fast follow with the maintainable infrastructure" and I want to blow my brains out.
The PM discipline has unfortunately maldeveloped as a place for souless MBAs, engineering degree holders who dont want to be engineers or both. Actual Product people are a small minority
Its a tragedy as its undervalued - I firmly believe apples products are significantly worse if their engineers led it. Jobs made those products
Product Management = Big picture product vision. Features and Priorities. Market trends/strategy, Voice of customer
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
What actually happens in most (small) businesses is one person gets lumped with all these jobs and the business is regularly surprised they're constantly over-worked and under-delivering
I often see product and project management combined. Usually it results in mediocre execution on all fronts. The last PM I worked with didn't even understand the product.
Yes, before MBAs took over, project management was more related to actually what happens in the project, GANT charts, stuff like Microsoft Project, resourcing team, setting the overall plan what goes where, who's available, when are vacations allowed,...
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.
There's even more. In games, we also use the term 'Producer' which manages the production, ie they're mostly a project manager. The design team is the product design role. Even here, the producers can and will dabble in design discussions in so far as is needed to meet timelines.
The nice thing is no one gets inflated with a manager title they think makes them the boss of every department. You get engineering lead, production lead etc.
I suspect what you are really lamenting is the effects of poor leadership that does not grant a "product manager" (which is really a misnomer) the authority and autonomy to be a "product manager".
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.
As a Product Manager (not Program or Project), this has been my lived experience of the devolution of the profession.
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.
Yeah, when I read it (probably a decade ago now) it was remarkable how much of the advice was still applicable. If you (yes, you reader) haven't read it before you should do so. It's only 200 pages or so, mostly short articles so it's not a difficult read.
> Most were just middlemen shuttling information between management, marketing, design, and engineering.
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.
In my experience PMs often work at a very high level. How things shold work are defined in a incosistent way when we take into account all the user flows, subtelness and restrictions of other systems. So programmers end up doing a significant chunk of the work by refining the specs so that the thing actually makes sense.
I am sorry you've had only negative experiences. Most of mine with PMs were negative as well, but a good one is a dragon slayer and bottleneck unclogger. They feel not like your manager, but like your servant, listening to exactly what you need, relaying messages accurately from other teams of what they need from you, and with the big picture perspective required for you not just to fulfill the task, but do it in a long-term strategically productive way.
> never met a PM who actual did the work of driving the product vision
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.
"I have never met an engineer who actually did the work of driving the engineering vision. Most were just middlemen shuttling data between servers, disks, clients, and CPUs."
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.
Deeply flawed analogy. Engineers operate in the same organizational structure as PMs.
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.
All the projects I have been part of where this idea took place, either were a complete failure, or eventually one engineer sacrificed themselves into a PM role to help steer the cat herd into something sensible.
Unless it is a team of senior folks with top skills, the team manages itself never works.
> Engineers operate in the same organizational structure as PMs.
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.
Exactly that. Generally, engineers want to build and not go to meetings all day. The problem happens with the PMs who are supposed to be doing this work don't do it, or do it poorly. You wind up with miscommunications: missing requirements, misunderstood edge cases, etc. This pisses people off big time.
Any efficiency gains which come from cleaner organization structure are gone because of the lossy translation mechanism between a PM and Eng team. You can argue that good PMs translate requirements perfectly, but this is a rare skill and I’m just saying I’ve never seen it from someone in this role. Perceived enjoyment of one’s role is a separate topic, but not completely orthogonal. If someone just wants to code and they force them to be a PM then their personal productivity might drop. This is why I asserted in the beginning I’m talking about feature teams, where a role fit I described is more likely.
As engineering becomes less expensive with generative models I can imagine efficiency tilts even further in favor of engineers doing more PM-like work.
For the right set of requirements I can fix bugs in my system with significantly less effort, than rewriting a system which was built with wrong assumptions to begin with.
Again, wrong analogy. I don’t demand perfect analogies though. Treat this as rather charitable gesture.
I have had a bad time with PMs and UX designers not actually understanding how the product works _right now_. How can you ask for changes if you don't understand how it works currently?
Like I am saying how the current behavior of the app downright needs a big flowchart to explain and I get asked: "Add X, but keep it working for all existing users" when that means the whole freaking flowcharts needs to be redrawn from scratch. When I suggest to remove some things to make things simpler (because the users don't understand it either) I get denied because it would be too much hassle to communicate the changes.
Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?
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.
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.
A fully curated backlog with complete specifications that is kept up to date with current changes in the product/industry? I've never had the privilege of working in an environment like that.
Obviously not every item in the backlog has a full design, for work that might be years out.
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’ve been bottlenecked by that middle part quite often. A design isn’t finished, we’re awaiting user feedback or testing, specs are done but waiting for sign off from required parties, etc..
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.
Your "coding team" there isn't actually coding most of the time. Sitting down to type isn't the bottleneck, but the work that needs to happen so you can sit down and type what needs to be typed.
I find it is either coding or design but yeah not sure where the perspective of the GP come from, that has not been my experience. I have actually vented with other devs about too many brainstorming meetings, ideas of what to do we are never short on. Maybe where I agree slightly is the devil is in the maintenance, ai can maybe? help with that but i think you will quickly reach a saturation point where you have more than you can manage.
I had a period of time at my last job where the product org was so dysfunctional engineers did in fact run out of work.
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
This story feels inconsistent. Where did the backlog come from?
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.
> Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?
And you quoted "how many times" contradicting it.
Yes, the art department plans the art and draws it, but an AI tool for generating art could only help with the actual drawing. The possible productivity improvement directly relates to the portion spend actually making art.
Your department or job-role style view of things doesn't make sense for this conversation.
I'd hate to work at a place where the backlog comes from the PM and the requirements come from a mix of PM and UX. Do you really think your PMs know that much more than your Engineers, Data Scientists, Ops/Business, etc.? This just sounds like something the type of PMs most of us hate, the type who insist on being the main character, would say.
Yes, PM's are absolutely supposed to know that much more about what the customers need. That's their job. They're constantly talking to customers; engineers are generally doing that only occasionally, if ever. They're not trying to be the "main character", but their entire job is to be the point person for integrating all the stakeholders' needs and making prioritization decisions. It's organizational needs, not ego-driven.
Sometimes products are simple and straightforward enough where you don't really need a dedicated PM, but then the lead engineer often just winds up informally taking on the same responsibility, and at some point there's enough success and complexity that it needs to become a full-time dedicated position.
I'm really curious how you've arrived at the perspective that engineers and data scientists know as much about customer needs as a PM, that they learned via channels outside of the PM? I've certainly never worked anywhere where that was the case.
Saying the quiet part out loud. What kind of engineering org outsources this? 80% of engineering is confirming your design works, otherwise it is just LARPing.
My thoughts exactly. Most of my coding is actually writing the tests or coming up with a proper harness to check behaviour of the code. Then of course there's other stuff like operations playbook if you are introducing new infrastructure. I have usually worked in environments where ops, q/a, design, code was the full job. First time I worked with explicit SREs it was a bit weird to give people specific commands to run without an overview of the system.
Every time I hear somebody say a phrase like “art assets” I am humbled, reminded that not all programmers have the same experiences or work in the same environments as I do. I don’t usually think about art assets being a blocking part of the workflow because I work on enterprise information systems.
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.
I have seen two sides of these artificial constraints people at their work impose. I am still not sure if these artificial constraints are good or bad.
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.
It doesn't matter what knowledge based industry it is either, its always people, communication and decision making (or lack of) that makes everything take longer.
Get a committee together to decide multiple products priorities, features, designs and you could be months away from having anything defined enough to code.
Good thing those open source developers learned their craft in isolated rooms, never seeing anyone else’s code.
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.
You can get pretty far with just K&R and in isolation if you write algorithmic code. Or with just APUE in isolation.
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.
How many human developers have never learned from other peoples’ code?
And let’s at least make up better stats. No way even 50% of the population understands and thinks about the issues. I’d say it’s probably 11.5184% actually.
I work in a large enterprise where they are jumping on the product manager bandwagon as well. Personally I don't mind the idea of this role but, similar to the product owner role, it seems to be an invention of consultancies as a way to place high-energy high-billable resources at cash rich companies. So, now we're getting all these "hustlers" being onboarded who eventually don't do much other than parading around and shouting orders at the people doing the actual work.
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.
I have worked in large companies with dedicated PM roles and mostly had a pleasant experience. Except a few instances with "real alpha male" energy who wanted me to explain myself. Fortunately this was over Zoom so I explained the problem (I had caused it) and then exited the call. Feature ultimately got delivered, was used and so I was promoted.
These people make me hate working. They don't want to pair with anyone. Understanding work at all is anathema to them. Their brains are too large for such trivial matters.
It’s actually outreach and business development but yeah it’s not coding or product development anymore. Why? because AI makes it easier to make credible sounding stuff, to maintain the appearance of progress, making it harder to tell who’s the real deal. So everyone is drowning in spammish AI. We all see it in recruiting (in all directions), it’s happening too in sales.
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.
LLMs are trained to write out sequences of words by mapping previous writing. So it’s recycling prior statements. There is no process/tech/innovation to train a system to engage in the world and figure out how things work.
So AI is not yet coming for good writers, performers, journalists, programmers. It’s only lifting up the bottom rungs and giving them the ability to recycle, in the way that all the bad writers, performers, programmers do. That’s why it’s so tiring to consume - it’s the automation of hacks (in the writer, journalist sense).
It also has the side-effect of preventing AI users from improving their skills. At least prolific hacks eventually got good in the past. Instead with vibe coding, your skills atrophy, with prolonged use it turns you back into a hack. So no. Coding is not going to get automated. We’re at the point where a critical mass of people are beginning to see that AI is falling short of the promise.
I'd like AI to be the product management layer of the client/mgmt/engineer sandwich as then it has two sets of humans checking the work that are already used to managing around miscommunication. Letting AI do the JIRA work seems like a perfect fit.
He is completely correct in principle, as most of the AI startups I have crossed paths with (I do some investment advisory) keep throwing AI at the wrong problems and/or don’t know how to mine for value in a product concept.
One thing that has changed for me personally is that these days if I’m parsing XML, I might just tell AI to write a parser that can handle these 5 XML files. It might load up a library or it might just roll its own, but one thing that is not going to happen is that I’m not building some beautiful well engineered XML parser which I then open source. I wonder if that is what’s going on?
I don't buy this line of pro-AI reasoning. It sounds like more work with less reliable results than just writing the code myself.
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 imagine the folks in the article and others like it are not building libraries and foundational infrastructure but rather cranking out SaaS startup ideas and CRUD web apps. I find that kind of coding really can go quite fast using AI, particularly if you are building it from zero and not worrying about all the existing quirks of a large codebase or creating technical debt.
Many people are seeing huge gains in coding productivity with AI. If you're not one of those people it might be useful to evaluate why you aren't experiencing any benefits, instead of claiming that there are none.
> Many people are seeing huge gains in coding productivity with AI.
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.
I'm speaking just to coding productivity. I think AI does very little for business development or creativity type issues.
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.
If they were, where are their products and open source projects? Let's circle back.
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?
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.
I, on the other hand, tried to vibe-code BDF-like ODE solver. Not some rough prototype, because I can do the rough prototype easily myself, but something robust and fast, with event handling etc.
AI couldn't do it. Actually it couldn't do correctly anything more complex than out-of-the-textbook explicit RK4, but this is something undergrad students do while learning numerical methods for the first time.
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.
I see what your saying but I would argue that vibe coding an ODE solver is an incorrect use of the tool. For something like and ODE solver you need to have a really solid understanding of what data structures you will use,and solid general knowledge of the numerical methods you want to implement. Then, you can use AI as an assistant when you get stuck, or to deepen your understanding, look over your implementation, etc.
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.
But that is the case - I know how to implement production-ready ODE solver. My issue with AI was that it was able to help with basics, but not with those really important bits, so it couldn't really deepen much.
> For something like and ODE solver you need to have a really solid understanding of what data structures you will use,and solid general knowledge of the numerical methods you want to implement.
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.
I believe in some conspiracy that no one is actually benefitting. I don't want to blame marketing, it's genuinely very cool that I can give Cursor a description of what I'm trying to do and get a result that's like 80% correct. But I've repeatedly found that going from 80% to 100% takes just as much time and effort as it would have to do it myself from the start.
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.
I admit that I don't know how to use it and it does seem like marketing hype and tech bros with some mild value and I'm waiting to be proven wrong and crushed, John Henry the Steel Driving Man style, and it's just not happening.
There are a lot of different niches to software development. It could be that your specific niche isn't seeing much benefit yet. However, continuing to hold onto a view that AI is hype garbage could very possibly hurt your career in the near future.
I don't think this line of reasoning holds. The only thing people should look at are peer reviewed studies, lots of them ideally, and with no conflict of interest. Who's getting productivity gains? What kinds of work are they doing? What doesn't work so well? All of these questions should be investigated by studies. People feeling productivity gains doesn't imply the gains exist.
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."
> The only thing people should look at are peer reviewed studies, lots of them ideally, and with no conflict of interest.
"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.
> When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
Maybe you just think you're being more productive ;)
Maybe because it's become second nature to you, due to a long enough career spent practicing the actual skill rather than using a crutch or tangential skill?
The second point is more incentive than AI capability i'd argue. Your point presumes that Open Source === Good. I'm not sure that's how all of society feels, unfortunately, so even if AI can do it at some point...it might not choose to.
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.
Clearly that's not the use you have for a new XML library. It's a use you're imagining somebody else would have for it. And because you're just imagining the use case, you've failed to think through what "good" would actually mean in that use case.
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.
Your original point would have had a bigger impact if you hadn’t married it to an idiosyncratic affection for XML. Now you’re stuck defending the usefulness of that particular technology which is entirely unrelated to AI.
Can I just remind everyone that GPT was released not even 3 years ago yet. It's been only 2 full years since GPT was released.
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.
bullshit, open source is blooming as never before. also we already have good xml libraries, nobody is interested in that. but yeah i agree with the sentiment that ai is not the magical tool you were promised, useful nevertheless.
I would endorse this position at very least directionally. The job is going to move up the abstraction stack; one person will do what a 5-person startup did, which means a founder must own more product and sales stuff.
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.
> Things that used to take six engineers three months to build, "my friends and I, we'll just build on a weekend," Ng said.
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.
- 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.
You say that, but my experience has been that product managers love nothing more than feeding entire webpages/specs/slack threads/email exchanges/whatever into ChatGPT and getting the 'summary' of it, and then pasting that into Jira and having the AI "make tickets" from it
The 'more efficient' part is where reasonable people disagree, a lot, and very often, in these threads
Andrew Ng has had a really sad career trajectory to a point where it's hard to take him seriously anymore. When I started in ML the very first course I took was actually Andrew Ng's course and it was amazingly good. But the past few years whenever he pops up, it always seems to be him repeating the talking points of some AI company that's paying him money. It's like seeing your hero turn into a complete sellout, shoveling bullshit for anyone who pays him.
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.
These days, most software startups with good ideas should be self-funded. Develop the software and figure out your outreach and marketing. Reap the profits. You don't need paper-pushing PMs. If you are seeking funding for a software startup, to me it's a red flag that your idea is probably bad, that you're just taking VCs for a ride.
"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.