8 ms·
My spicy take on vibe coding for PMs
- ambicapter 7mo agoThe linked article on evals is even more interesting.
- deleted 7mo ago[deleted]
- aurareturn 7mo agoI think technical PMs or product oriented developers are the future most valuable people.
- WhiteOwlLion 7mo agoYou make a better product if you plan it out first. That’s part of a PM’s job so it’s natural fit when the ai does the coding. The code may not be ideal but it’ll have the structure you can improve on.
- ryoshu 7mo agoEntire product or a feature for a product? Sometimes you just want to test an idea and vibe coding works well for that in the very short amount of time it takes now. Product market fit, user testing, engineering, those can come after the hunch.
- NitpickLawyer 7mo ago> You make a better product if you plan it out first. Maybe. Maybe not. Sometimes you have to see it to understand what's wrong / how can it be improved. It's one of the actual benefits of pre-religious agile - have something in front of your sponsor ASAP, adapt to their feedback. This loop can be made faster, but you'll still need some expertise at every level. Just not so many bodies.
- array_key_first 7mo agoThe entire evolution of software engineering has been focused on how to plan a product. Because 99% of the time the problem IS NOT writing code. It's writing the wrong code. The wrong requirements, for the wrong people, for use cases nobody cares about.
- chickensong 7mo agoThey always have been, long before AI. Some sales engineers can be in the club as well IMHO. It's pretty normal for integration projects with big corps to have problems, but if the project has executive interest and the A-team gets called in, it's a joy to work with those people. The lines between the roles are blurred, it's just smart and dynamic people making things work. They don't give a shit about following scrum or pedantic coding standards, only project success, but not in a superficial way. I don't know if they truly care about what they're doing, but they're so far above the baseline that it doesn't really matter.
- sublinear 7mo ago> Why should PMs code? Better communicate the idea/feature I think this is the main takeaway, but I'm curious how bad the PM must have been at communicating to begin with if this is necessary.
- dmckinno 7mo agoCommunicating a feature with a doc or mock can be really hard. A prototype can make things much clearer to a broad audience.
- Ronsenshi 7mo ago> Fun!!!!! I noticed that AI evangelists really love to use word "fun" to describe anything they do with AI. Claw people particularly seem really love to use that word when answering what practical or useful they do with AI agents. It's always something absurdly trivial followed by "and it's just fun!" Don't really have any conclusion to this - just thought to share this observation.
- dmckinno 7mo agoWeird take. Coding is fun (and has been since before AI). And vibe coding is fun in an entirely different way.
- Ronsenshi 7mo agoWhat's weird about it? I'm not disputing that it might be fun for vibe coders. Just that they seem to really like using that particular word. I love coding and it is fun for me. Vibe coding on the other hand - not fun at all. It feels to me like playing slots. But then again, I never liked gambling.
- slopinthebag 7mo agoNot weird at all. It's a common motte & bailey tactic, when your defence of the utility of something fails you can just say you do it for fun!!!!!!!.
- wiseowise 7mo agoWhen your only defense is “I’m just having fun!!!!” after dumping your toxic waste in the net, it’s not a weird take.
- overgard 7mo agoIt's probably on the script they've been given
- wiseowise 7mo agoWhenever someone says “Fun!!!!” when it comes to LLMs/Claws I can only imagine the author having that obnoxious face: https://knowyourmeme.com/memes/soy-boy-face-soyjak https://knowyourmeme.com/memes/soy-boy-face-soyjak
- 650 7mo agoMeta, and other large companies have been encouraging PMs to code, while I've seen many negative responses from engineers having to code review, debug, deal with production issues, etc. stemming from crappy code they don't understand. Metrics and KPIs are being gamed into stupid incentives like lines of code, commits, and tickets closed. Leadership claims they are aware of Goodhart's Law, but their actions show otherwise. Overall the rise of business types in tech company leadership has led to a drop in engineering quality, a rise in short term metrics, and fiascos like the COVID overhiring into multiple rounds of layoffs.
- dmckinno 7mo agoFunny story: I work at Meta and posted a version of this internally in response the bizarre pressure and support for PMs landing prod diffs (the response was very positive FWIW).
- ivantop 7mo agowhich workplace group did you post it to?
- dmckinno 7mo agoI don't remember the exact name, but the one about AI productivity. It should be trivial to find my name from my handle, so just look at my profile.
- medi8r 7mo agoQuick everyone, create decoy repos for them to vibe in. When the feature doesn't appear "oh feature gate system has an incident try tomorrow". Even better make the decoy repo have an insufferable pipeline that always breaks and get them in a loop trying to fix it. An adveserial "red team" LLM can keep it broken! But tantalizingly with different problems so progress is felt.
- purrcat259 7mo agoAn easy correction is to only merge PRs from folks who are on the on call rota. Those not on rota can either join or have their PR receive heavy scrutiny
- raviisoccupied 7mo agoI don’t think this is a spicy take at all. A PM’s job is to prioritise, and the most important/high priority projects will naturally be handled by Engineers enabled with AI-coding workflows. The high priority/impact work should be allocated to the folks with the highest level of skill. I feel like PMs coding unlocks a whole new category of work, mainly addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressed. Time will tell how valuable these items are in the long term. And I say this as a PM.
- dmckinno 7mo agoYou'd be surprised. See this sister comment: https://news.ycombinator.com/item?id=47242372 https://news.ycombinator.com/item?id=47242372
- croisillon 7mo agosame, it sounds more like common sense than spicyness? i vibecode prototypes and visualizations but pushing any more than that would just add chaos to the chaos we're trying to avoid
- skydhash 7mo agoMaybe your cool ideas/small optimisations were not addressed because of how they would impact the system as a whole. It's the job of the engineer to keep things running and there are a lot of places that can wreck (slowly of quickly) the product if modified wrong.
- foolserrandboy 7mo agoIsn’t this the type of work interns used to do? Prototype hackathon type things?
- boondongle 7mo agoIn a real, large company, no. Interns generally still get the work that is prioritized but often too simplistic to spend Senior Dev time on to simplify Dev's job. For better or worse, Development represents what the executive level prioritizes often defined by Product Management/Program Management. There's a whole other level of requests which for political or cultural reasons don't get touched even if there's a great internal rate of return to them or they reflect real bottlenecks elsewhere in the company. Ideally any/every company would prioritize by actual internal rate of return but that's just not what most of us observe.
- ef2k 7mo agoMy hot take: the dedicated PM role is becoming optional. Engineers already understand feasibility and tradeoffs, and they often end up informing the PM anyway, which usually comes at the cost of meetings and slow decisions. With clear quarterly goals, engineering and design can own product together. They would shape scope, ship in increments, measure, and iterate. So the "product" function still exists, but its not a separate PM attached to it.
- dmckinno 7mo agoI totally agree (as a PM of ~10 years). I think that all PMs will need to get onto the engineering, design, or research ladder. We are already seeing companies eliminate the function here and there and I expect the trend to continue.
- nimonian 7mo agoThis seems crazy to me. I am a PM and I am busier than ever. People are waking up to the idea that code is cheap and things can change faster now, so deciding _what_ to make and prioritise in the deluge of ideas coming to prod is becoming completely essential. One thing LLMs don't have is taste. That's on me.
- latentsea 7mo agoThey don't seem to have taste when it comes to engineering either, but tbh 'taste' is a computable function, and will eventually be learned.
- krater23 7mo agoAs a developer, I don't see the PM as a boss or planner. It's the guy that handles the communication with all the people that don't understand what I say and ensures that they don't annoy me. A PM is not optional when you want to have developers that have time to code and don't get distracted by thirty people that all want something else and all ASAP.
- 7mo ago
- jackyli02 7mo agoPMs in Meta-scale companies vs. startups has always been different, and they are diverging even more as AI gets better. In startups anything goes. PMs and engs do whatever it takes to ship and scale the business. No one cares who's using AI in what way, as long as they're getting shit done. In a place like Meta or Amazon, people also get more shit done with AI, but because these teams are huge, well-oiled machines, sudden productivity bumps or norm changes can drop overall productivity. Totally agree with this post as long as it's limited to large, mature teams
- dmckinno 7mo ago100%. PMs at startups already wear many hats and AI helps them do that even better. But to this sister comment's point, I do think that the dedicated PM role will vanish and the classic BigCo PM will need to look a lot more like the startup one. https://news.ycombinator.com/item?id=47242699 https://news.ycombinator.com/item?id=47242699
- maplethorpe 7mo agoHot take: only PMs need to code now. With Claude 4.6 Opus, the engineer skill set is no longer useful. Why are we hiring people with code writing ability when code writing ability has no value anymore?
- dmckinno 7mo agoThis is kind of like the reverse of the sister comment, which I agree with: https://news.ycombinator.com/item?id=47242699 https://news.ycombinator.com/item?id=47242699 The general point is that separating PM and eng doesn't make sense any longer. Which subsumes which is an interesting debate. Your argument that 4.6 Opus makes the engineering skill set useless is totally false and maybe shows you haven't built anything complicated, but it is possible that Opus 5.2 will get there.
- slopinthebag 7mo ago> Why are we hiring people with code writing ability when code writing ability has no value anymore? Is this sarcasm? You don't think there is any utility to understanding code? Edit: you got me haha.
- Bridged7756 7mo agoBuddy, when the engineering skill set is "no longer useful" you'll be living in a cardboard box at least a couple of years before that ever happens.
- perrylaj 7mo agoOpposing Hot take (possibly missing the joke....): Coding was never the most valuable skill a software engineer contributed. Socially-capable engineers are going to be far more likely than PMs to 'shine' when agents can write code and engineers are afforded more time to engage with busines/customers/stakeholder/domain experts. If my experience is any reflection of the norm, the avg PMs greatest value has never come from effectively determining the value or requirement of a product or translating requests/feedback to meaningful deliverables. It's been in providing cover (time) for engineers that could do the same job better, but are irreplaceable in the development process and so are more rare/valuable spending time doing development. When engineers no longer need to write code, they are a more direct line to effectively solving "Product-Led" business needs with technical solutions than a typical PM will be.
- shay_ker 7mo agoI remember this post. But I'm not sure what the future really entails and I suspect it'll be very company/culture dependent. In some companies, the engineers are very savvy and understand the business well. In others, it's the designers. Or sales. Ops. And of course Product Managers. You get the picture. Whoever gets the business best (and in detail) will likely be the best builders. It's "intuition as evals" that really matters in the end. You think Software Engineers or Product Managers are replacing Quants at trading shops anytime soon? Nope.
- munchbunny 7mo agoI generally agree with the take. At the moment the models and agents aren’t good enough for someone who isn’t trained to build and maintain a production system. So as long as Eng isn’t significantly more bandwidth starved than PM, PM’s writing production code is not a high leverage activity. The key issue right now is that the models falter in the last mile, and the last mile is where you need the training and experience to make sure the thing that lands is production quality. At some point in the next few years I believe the roles will merge. I suspect that PMs will be forced to specialize towards a discipline (design, data science, engineering, etc.) while engineers will also start to see more of their responsibilities covering former PM territory. Most engineers will probably become closer to “product engineers”.
- fhd2 7mo agoWhich would be pretty much full circle at that point. When I started out, it was common for developers to do "product management", there wasn't a specialised role for it yet. You had developers and maybe project managers (generally also developers) and testers, and that was about it. Management would talk to developers about their strategy and problems, and they'd figure out what to build based on that. I'm pretty weirded out by some "modern" teams where you have product managers spoon feed specifications to developers, and developers focusing on nothing but the code they need to write to do exactly as they've been told. Product managers are in a weird place. They wear a ton of hats and do entirely different jobs based on where they work. They're often really valuable, but I have some trouble putting my finger on what makes a good one. If they're good at whatever it is they end up doing, that's good.
- munchbunny 7mo ago> If they're good at whatever it is they end up doing, that's good. As a former PM (now an engineer), I think that's pretty much it. Teams and companies will vary a lot in terms of what they want the PM's to do, with some common patterns emerging, but as long as the PM's do the work well then the team is much better off. The key issue is how much you can trust the PM to hold up their end of the project. A common theme I've noticed among good PM's: good judgement. When the team can trust the PM's judgement, the whole team flows better. When the team can't trust the PM's judgement, the PM is worth negative bandwidth.
- SurvivorForge 7mo ago[flagged]
- deleted 7mo ago[deleted]
- foltik 7mo agoBegone, bot.
- Bridged7756 7mo agoOur job is done for. We will be shown the door, and everyone will rejoice. Everyone will live in a happy world where you'll doddle a house and Claude will build you a next generation SaaS that makes you millions. Managers will do the job of engineers, by just telling LLMs to make an app or to make money or something. C-suites will have agents doing the jobs of managers, and CEOs will run entire companies with a Claude $200 subscription alone. It is truly the next thing, and the future, probably happening in the next 2 years, or in 2 years in 2 years. Yesterday I had an interview, but I got rejected. They decided to go for a manager with a Claude subscription who vibe-coded a weather app. This is the end of software engineering.
- krater23 7mo agoHAHAHAHA. Dodged a bullet. Do you really want to work in a enterprice where HR is so dumb to buy this shit? Just think, they hire all your colleagues.
- bitwize 7mo ago> by just telling LLMs to make an app or to make money or something. Again, that is literally OpenAI's business model: burn money building ChatGPT until it's smart enough to tell them how to be profitable. "That's a bold strategy, Cotton, let's see if it pays off for 'em."
- tehlike 7mo agocan't tell if you are serious or not.
- MrScruff 7mo agoIt should be obvious, particularly from this line: > It is truly the next thing, and the future, probably happening in the next 2 years, or in 2 years in 2 years.
- ramon156 7mo agoI got laid off at a job where this applied, then at another company got rejected because they cancelled the position altogether to use Agentic Coding by Microsoft instead. Then I joined a small consultancy that just lets me build however I want. There's no reviews, no sprint reviews, no evaluation. They trust that you work on what is important. While this is a very messy and unmaintained workflow, it is a lot nicer and I am honestly wondering if Scrum is even necessary when you're only with 4-5 devs. Maybe it is to streamline newcomers? Because it took a bit of time to gather all the project info, but after that it was pretty relaxing. I don't know, the market has shifted so much that I feel like I should probably be contempt with what I have.
- bg24 7mo agoI think it depends on the company. In large companies, the role of PM probably won’t change that much. However, PMs who are technical and hands-on can bring significantly more value by leveraging AI tools. There’s another path for PMs that the article and most of the comments don’t seem to mention. Technical PMs are now in a great position to start their own companies. In the past, many were blocked or handicapped by the inability to code. With AI-assisted development, that barrier is much lower, which gives them a lot more leverage to build products themselves.
- brumar 7mo agoI get that "landing a prod diff" means "get stuff in production"? I never read this before. Is this slang unique to meta?
- deathanatos 7mo agoNor do I know what an "eval" is, or which of the no less than three different deacronymings of "PM" (that I know of, thus far) FB uses or what that role would mean to them.
- titanomachy 7mo agoYes. “Landing a diff” is very meta-specific.
- bthrn 7mo agoDiff is Phabricator terminology. A diff is roughly equivalent to a Pull Request in GitHub.
- brumar 7mo agoThank you!
- keeda 7mo agoA friend at Meta -- long before the age of LLMs -- got paged at 3am for a site issue. When he found the PR that caused the bug, the testing section for the change simply said: YOLO! This was well into the "Move fast with stable infra" era of Meta, but clearly that still encouraged "Move fast and break things" for everything beyond infra. PMs landing Prod diffs sounds like even more moving fast shall ensue.
- polotics 7mo agoThe quip "move things and break fast" is from which year btw, do you remember?
- keeda 7mo agoHah, not sure of the origin, but I do recall seeing it at some point and I think it was this HN comment: https://news.ycombinator.com/item?id=41581370 https://news.ycombinator.com/item?id=41581370
- dasil003 7mo agoAs much as I recognize that a truly talented product manager is worth their weight in gold, I'd say the average engineer would be much more capable of learning to be an average PM than vice versa. PM vibe coding a prototype for demonstration purposes? Might be a better use of a designer or engineers time, but okay I could see it being valuable. PM vibe coding something to ship to production? Your title is now engineer and you are responsible for your change, otherwise this is a direct path to destroying the quality of your product and the integrity of its data.
- neonstatic 7mo ago> I'd say the average engineer would be much more capable of learning to be an average PM than vice versa. It's a completely different skillset. Practice shows, that most Engineers simply do not want to be PMs or find out about that after making the change and regretting it.
- dasil003 7mo agoI agree but my point stands, even if they don’t want to, an engineer at least has the precision of thought to specify how a product could work. Many PMs simply don’t have this, so asking them to become vibe coders is a hopeless waste of time.
- kaffekaka 7mo agoI agree, the thought of some PMs building an actual system is absurd. They do not understand the details necessary. But quite a few developers I know would also be absolutely hopeless as PMs. No people skills, no interest in strategy or the long term view, do not want to hear about end users. PM = project manager in my world
- bennyelv 7mo agoI imagine you’re saying that as a software engineer :). As a manager of both software engineers and product managers, I think this view is a bit of a stretch. Some software engineers would make good product managers, some product managers would make good software engineers, and the majority of both are best suited to their current job.
- tarcon 7mo ago"Programmers are the ultimate detail managers. All the tiny little details that nobody else wants to deal with wind up in our laps." - Robert C. Martin Let's see if AI makes PMs care for details.
- braebo 7mo agoA lot of details are already beginning to fall through to the AI’s lap anyways.
- mono442 7mo agoPMs writing software seems like a terrible idea. Vibecoding still requires to be quite knowledge about the software engineering to actually get good results.
- fifticon 7mo agoI am glad this essay was on the right side of the fence, otherwise I would have written it myself in response.. Our company is currently one of countless, where we just had a "get with the program" meeting with our PMs, where they showcased stuff they had added to our enterprise system in hours and days, and told us that they expected us to start delivering with the same tools techniques and speed.. Meanwhile, my team had spent that same working day before that meeting, trying to figure out why our production databases were suddenly getting hammered; it turned out some system was suddenly calling an expensive query endpoint 10k (10.000) times each hour, during business hours. Guess 3 times whose vibe-coding adventures were responsible for those 10k calls :-/. Other than that, I noticed during the meeting, that their vibe-coded demo added module to our enterprise system only dealt with happy-path of the data updates, but would leave debris in our database for all the edge cases. Happy times. But heck yeah, let's just ram it straight into production. I wonder who will take care of adding support/clean up for the edge cases.
- jamiemallers 7mo ago[dead]
- alansaber 7mo agoMove fast and break things. If it works well for a startup with 3 users and 1 developer, why not do the same for our critical infrastructure company? Openclaw, fire my engineering team and bring me more alcohol.
- array_key_first 7mo agoEverybody and their mom loves to believe they're the hot young stuff on the block. Even with a company like, say, Meta, they have more freedom to make mistakes than 100% of enterprise companies. Nobody cares too much if Facebook goes down or is slow or something. But if you're selling to another business, they're gonna have your ass for breakfast for even the tiniest mistakes. As they should, they're paying you a lot of money!
- nevertoolate 7mo agoI agree - we should use the tools. But we should be mindful about how humans actually learn. Some improvement ideas: A prototype can help in the “Better communicate the idea/feature” part but it is even better if you let engineers do this as learning by doing is better than just being shown the result. Vibe coding doesn’t help in “Understand the systems” - on the contrary, this is already a well known fact that vibecoding has negative effect in understanding the underlying system. It should be hardboiled documentation reading, trial and error which helps, otherwise you get only the illusion of competence.
- dv_dt 7mo agoI think orgs would get better traction with PMs taking on product complaint or bug issues and using AI to diagnose detailed root cause.
- olafmol 7mo agoLet engineers do Vibe-accounting because, AI.
- tl2do 7mo agoWith AI coding agents, reverse-engineering a codebase into a spec doc has become much more feasible, including details below the usual spec level. That gives PMs a practical way to understand systems more deeply than before, without having to land production diffs themselves. So to "Why should PMs code?" my take is: sometimes they should, but now there are multiple levels of involvement depending on what understanding is needed.
- rimeice 7mo agoText to code is clearly valuable but the code to text capability of LLMs is seriously underrated IMO. I would argue orgs should prioritise giving PMs Claude Code licenses over devs. So much efficiency unlock without the worry about whether vibe code can be shipped to prod.
- otabdeveloper4 7mo agoShipping vibe code to prod is like the dumbest and least useful thing LLMs can do.
- rimeice 7mo agoexactly.
- jwilliams 7mo agoI read takes like this and I feel like it's gatekeeping. I love writing software. I love that others are now getting to share this. I think the issues here are valid. Equally there is lots of hard engineering work to reduce these issues. That's where I'm putting more energy. My scale is decidedly non-Meta, but we're investing to make the whole team able to get their own PRs up. It's not been without it's bumps, but on the whole I think it's been transformative for everyone.
- bluefirebrand 7mo ago> I read takes like this and I feel like it's gatekeeping Yeah man, insisting on good engineering practices instead of "vibes" has always been gatekeeping That's the actual point of engineering credentials What are we even doing here
- DiscourseFan 7mo agoThis was before the bot could competently code things. Software development is now a very different beast, and yes while there have been some very stupid and irresponsible uses of this new technology, many others are integrating it effectively into their workflows.
- bluefirebrand 7mo ago> This was before the bot could competently code things Agree to disagree Getting something working is the absolute bare minimum, it's not "competent"
- DiscourseFan 7mo agoThe fact that it can, and often does, get things working, sometimes even well, is evidence enough. It can't do some things, it can easily do others, and knowing which is which is very important nowadays.
- 7mo ago
- motbus3 7mo agoMy company does not have PM for a while now. Even before AI
- spamjavalin 7mo agoThe brutal truth is that no one likes dealing with developers - now they don't have to.
- akshay2603 7mo agoI am one of those PMs at a big tech that just shipped a PR in prod: My take: 1. Doing this moves my team faster. I now use sourcegraph MCP all the time to file much better bugs. And when the actual bug fixing TAT is larger than bug filing TAT, I rather just do it myself. My engineers appreciate it, truly. 2. This not only helps me do bug filing but just get comfortable with code. And this improves my PRDs, my MVPs and my overall thinking. There is no way that I can do this in isolation. I have to get comfortable with code and that involves shipping the occasional PR. 3. This improves my craft. I am obsessively shipping on the side. The codebase for my personal side projects is manageable. I would love to ship at work as well but that's not doable because of codebase complexity and the inability to read code. However, traditional product management is collapsing and this is the new normal.
- nananana9 7mo agoIf you can't read code and don't understand the codebase, you have no business anywhere near a text editor. I work with a PM that's also learning to program. I assume just like you, they probably feel they'll otherwise will be pushed out. While it's far from the most productive thing I could be doing, I'm always happy to answer questions from a beginner programmer, or walk them through how something works, or how it should work but doesn't, help them debug it, etc. Even though they're more or less ripping off the company, and are being paid a six-digit salary to be an intern programmer, I have infinitely more respect for them, as they're actually putting a good effort into learning the craft, and they're honest about what they're doing. You can argue all you want that throwing vibe-coded PRs at your team improves your MVPs, PDRs, AVBs, DRTs, SVGs, BMPs or whatever un-measurable metrics you come up with, the reality is you're creating more work for everybody. It takes a great amount of hubris to believe that although you may be unable to read code, surely your understanding for the product will lead to a diff that's an overall net positive. Your team will pat you on the back and then quietly clean up your mess. If you want to program; great; learn the craft like the rest of us did. I'm sure you'll find many people happy to share knowledge and help you along if you put in an earnest effort.
- ryanmcl 7mo ago[dead]
- elif 7mo agoAgree with this take for the most part. Vibe coding is bad enough with an engineer in charge. Without a computer science background or engineering experience it's way too easy to go off the rails. The exception would obviously be all the skilled coders who got turned into PM's over the years due to bad salary/title structures or poor organization structure.
- iknowSFR 7mo agoI am a bit confused with the consistency of this community in speaking about MBA’s running their orgs or PM’s making bad decisions… it feels like more resistance by engineers to learn business than the business side not learning code. What I mean is that what a company values seems to be widely understood and the reaction from HN is “they’re wrong.” If anything, this is the green light for engineers to step into the business side and fix all the complaints they’ve had for decades.
- deleted 7mo ago[deleted]
- PokemonNoGo 7mo agoI didn't know what to expect when clicking an URL to "My _spicy_ take on vibe coding for PMs". I'm a little disapointed of the lack of risque content though.
- geooff_ 7mo agoOne thing missing from this discussion is the blast radius of the product or repo in question. Let PMs land new widgets on internal dashboards or CSS changes in internal tooling. The same way we should be aspiring to build tools for devs to merge these same changes with minimal test plans. You wouldn't call a mechanic to help you turn on your windshield wipers. Changes in high-risk environments should be gated for people who actually know what they're doing. That high bar should remain high.
- jonpurdy 7mo ago100% agreed. I'm a Program Manager and have been writing tooling for my own internal workflows for years (like Monte Carlo-based forecasting tools), or program-adjacent low-stakes stuff (like an API to generate a WSJF score based on a fields inputted into Asana, since it couldn't do that itself). But I'm not about to send a PR for fixing production bugs even if I have decent high level context. Nobody has better context than the devs working on it every day.
- youknownothing 7mo agoHype will come down once scalability problems start to show up. It's the same with every new technology: people get excited from the results of their PoC not realising that a PoC is smaller in scope and therefore has better chances of working. Then you try to translate that to a proper project and it all falls apart. Agentic coding will accelerate things, but you'll still need the engineers. Power tools didn't get rid of the tradespeople, they just made the ones that knew how to use the more efficient.
- deleted 7mo ago[deleted]
- laalshaitaan 7mo agoThe best point in this thread: "intuition as evals." That's actually the crux. PMs have context about what the product should do that engineers often don't, and that intuition IS an eval. The problem is it doesn't scale once the system has millions of conversations no one is reading. The empathy from vibe coding is real, the prototype-as-spec culture is where it breaks down for AI products specifically.
- lrakster 7mo agoWe are a much smaller team than Meta and all-in with agentic-coding. But even we are seeing value in specialization of roles. There is so much to be done. Why have PMs work with coding agents to code the product when they aren't going to do as good a job as an Dev will? Have the PMs do research, competitive analysis, mockups, prioritization, etc
- nachocoll 7mo agoThe PM vibe coding scenario described here cuts to the heart of a real accountability problem: when the person shipping code doesn't understand it, can't debug it, and won't be around when it breaks in production, who's responsible? This isn't just a PM problem — it's the same dynamic playing out at every seniority level with AI-assisted coding. The speed feels real, but the ownership gets blurry. A few of us have been working on formalizing exactly this challenge: the Agile Vibe Coding Manifesto (https://agilevibecoding.org https://agilevibecoding.org). It builds on the original Agile Manifesto to address environments where AI is generating significant amounts of code, and its second principle is simply "Humans remain accountable for software systems — regardless of how code is produced." The manifesto doesn't argue against AI-assisted development. It argues that speed of generation has to be matched by clarity of intent, traceability of decisions, and genuine human accountability for what gets deployed. Whether you're a PM shipping a quick tool or a senior engineer steering an agent, the accountability question doesn't go away.