5 ms·

In what I've seen, tickets are much richer in detail now because PMs are using AI (connected to the codebase itself, like Claude Code or Codex) to fill out a te

In what I've seen, tickets are much richer in detail now because PMs are using AI (connected to the codebase itself, like Claude Code or Codex) to fill out a template as to what and why the problem is (ie X field exists in the backend not frontend), how and where to get any data (query the backend), and what acceptance criteria is needed (frontend should have the field exposed and "submit" should push the field's data to the backend where it should show up in the databas), which is something they would not have done before, due I guess to laziness and thinking the devs can figure it out. Then devs can copy paste this Jira ticket content into the LLM agent of choice (or even use the Atlassian MCP to have the LLM read it automatically). This has significantly helped devs and made sure that requirements are very clear. Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves and a few devs will be around as SDETs rather than full blown implementers.

OptionOfT 6mo ago
Except... no one validates the generated tickets, and it's full of inaccuracies. And then someone copy pastes it into Claude and now those inaccuracies become part of the code and tests.
- satvikpendem 6mo ago
  The PMs validate it, why do you think they don't read over it to make sure it fits what they want? You might say "well they're lazy, look why they didn't write enough detail to start off with" but for lots of people, reviewing something to make sure it's close to what they want and then tweaking it is much easier than writing it from scratch. It's the equivalent of writer's block and is why a common advice given to writers is to put anything they can onto the page then edit it later.
  - BugsJustFindMe 6mo ago
    > The PMs validate it, why do you think they don't read over it to make sure it fits what they want? Hahahahahaha. Sorry, I couldn't help myself; this reads like satire. The answer is "real life experience says otherwise".
    - ethin 6mo ago
      Yeah I was so tempted to ask if this person has ever actually met a project/product manager...
      - satvikpendem 6mo ago
        Maybe you both just have bad PMs, because just like good devs they should also be reviewing their work. My point was that it is more likely for PMs to review and edit a generated ticket than to have to write it all themselves which they often won't do.
        BugsJustFindMe 6mo ago
        > My point was that it is more likely for PMs to I feel compelled to point out to you that this is a completely unsustainable, unsupportable, unsubstantiable claim. You have met ~0% of PMs, and of the ones you've met maybe you've experienced a non-zero percentage of their work, but statistically that's also very unlikely. If you think you can say what most PMs do or what PMs are likely to do, then, I'm sorry, but you are not even thinking like an engineer. You're thinking, actually, a lot more like a PM to many of us. > just like good devs I'm so sorry, my sides just can't handle the starry-eyed nature of these takes. This is just too much for me. To many of us this reads like you've never met people before. But who knows, maybe you live in Lake Wobegon, where all the women are strong, all the men are good-looking, and all the children are above average! If so then we're jealous, but you still should be more careful about how unrigorous your mental model is because it will make you a worse engineer. Experience with different PMs and developers aside, the older you get in the profession the more you will hopefully realize that none of your quality effort fantasy matters. Sales happen and money rolls in independently of whether you think the PMs or the people who call themselves engineers do a "good job". Businesses thrive on sales and marketing, not engineering.
        satvikpendem 6mo ago
        What a strange response. By your logic you've met ~0% of developers too yet I assume you can distinguish good development practices from bad. I also mentioned good PMs which by definition review and write good tickets with a clear explanation of the problem and what they want the solution to be. If personally meeting millions of people is the epistemic standard you have to know something then I'm not sure how you know anything at all. As to your latter point, not sure why you think I think business doesn't continue on even with bad employees, of course it does and I didn't say otherwise. But that does not mean they're doing a good job, those two are orthogonal concepts. And I'm not sure how we even got to this, the original point was that I personally as a dev can physically see PM productivity increasing with AI, even as other devs in this thread seem not to. For a competent PM, a tool that automates a detailed first draft fundamentally changes the psychology of ticket creation. If your argument is just "bad PMs will still be bad," then sure, I agree, but that doesn't really engage with how the tooling changes the workflow for everyone else.
  - majormajor 6mo ago
    > The PMs validate it, why do you think they don't read over it to make sure it fits what they want? The PM has historically often not had a detailed enough mental model of the implementation to spot the hard parts in advance or a detailed enough mental model of the customer desires to know if it's gonna be the right thing or not. Those are the things that killed waterfall. You can use LLM tools to help you improve both those areas. Synthesizing large amounts of text and looking for inconsistencies. But the 80th-percentile-or-lower person who was already not working hard to try to get ahead of those things still isn't going to work any harder than the next person and so won't gain much of a real edge.
    - Avicebron 6mo ago
      I'm glad you mentioned it and TFA briefly mentioned waterfall. The second graph shown in the article with documentation overlapping the dev cycle, it's like the worse of both agile and waterfall. It's supposedly real-time waterfall. Normally waterfall works where the scope is extremely-well defined and articulated in design plans. Which shortens dev time because prior to AI code was mostly deterministic. Here we have to do waterfall level of documentation while iterating on a non-deterministic solution (code gen) to non-deterministic requirements (per usual). It's bonkers. I still think the technology is cool though. And to answer the questioner.. Have you worked with a PM? Most of the ones I've worked with try to be simultaneously in charge yet not responsible for anything. Validating something implies skill and responsibility.
    - satvikpendem 6mo ago
      Then they're just bad PMs and don't deserve to have the job. That can be said in any profession, devs or lawyers or doctors who blindly accept LLM output without review are bad employees.
      - BugsJustFindMe 6mo ago
        > Then they're just bad PMs and don't deserve to have the job. Nobody "deserves" anything. They do have the jobs though. Thinking that the world isn't full of people doing what they need to do to get by who don't give a shit about fitting a fantasy ideal is wild.
  - zxornand 6mo ago
    I think validating a fully generated novel of a ticket, is much harder than thinking through the problem in the first place and creating your own ticket. We see it with code too right? It’s harder to review code than to write it. On top of that the LLM can work so fast that the amount of things that need validating grows! This is where humans get lazy and the problems come in IMO. Whether its a PM not validating their ticket, or a dev doing a bad code review. Add on to that that the incentives currently are to move fast and trust the AI. It becomes clear to me that a lot of that review work either won’t be done at all, or won’t be nearly thorough enough.
    - paulhebert 6mo ago
      I agree. I hate getting tickets like this because they’ve often gone down the wrong path and I have to work backwards to understand the actual problem and the right way to solve it
    - satvikpendem 6mo ago
      The tickets are not "novel"-length, they are about a few bulleted lists of the sections I mentioned above. In that case it is indeed way easier to review that a ticket only saying "do X with Y data." Reviewing code is harder than reviewing text because code does something and has interdependencies and therefore must be correct in its function, do not mix the two. This is like saying an editor reviewing an article or novel is harder than actually writing the novel which is blatantly incorrect.
      - zxornand 6mo ago
        Most real tickets are more complicated than “Do x with Y data” and also have many interdependencies throughout the business
        satvikpendem 6mo ago
        Most? That's doubtful especially when a lot of tickets are simply CRUD which are fine being generated by an LLM. Those that are more complex require more review and interdependency management, sure, but to say that that is most tickets is simply not correct.
  - mrbombastic 6mo ago
    just this week i pushed back on some requirements in a very detailed product spec I was implementing to speed up time to ship. The pm had no idea what I was talking about because the requirements were invented by an LLM. This is not a bad PM, discipline doesn't scale.
- resters 6mo ago
  This failure is human laziness, not an issue with the technology. People who use AI because they are trying to avoid doing work fall into a completely different category than people using AI as a force multiplier and for skills/capabilities enhancements / quality improvement.
  - OptionOfT 6mo ago
    It's also the only way to get those massive increases in productivity.
  - danaris 6mo ago
    This is very much a "you're holding it wrong" response. If your technology relies on humans using it in ways that go against the ways they are inclined to use them, then that is an issue with the technology.
    - majormajor 6mo ago
      I don't think that works as a critique of LLMs because it's far too broadly applicable to well-accepted tools. Are advanced calculators bad because a student could use the CAS to ace calculus homework, exams or the SAT without actually learning the material? Is copy/paste bad because a person could use it to copy/paste code from one place to another without noticing some of the areas they need to update in the new location, adding bugs and missing a chance to learn some more subtleties of the system? Is Git bad because a manager could use it to just measure performance by number of lines of code committed instead of doing more work to actually understand everyone's performance? Many tools can be used lazily in ways that will directly work against a long term goal of improving knowledge and productivity.
      - convolvatron 6mo ago
        but in this case that's exactly what AI is doing, and no more. its filling in the gaps with some plausible sounding goo so that the person doesn't have to worry about the details. ok, so for some of the jobs we're doing plausible sounding goo is just fine. and that's kinda sad. but the 'just playing around' case is fine for PSG, this isn't a serious effort but just seeing how things might work out without much effort. taking the remainder, where understanding and intent are important, the role of the ai is produce PSG, but the intentional person now goes through everything and plucks out all the nonsense. this may take more or less time than simply writing it, but we should understand this is resulting in less real engagement by the ultimate author. where this is actually interesting is a parallel to Burrough's cutup method - where source text and audio were randomly scrambled and sometimes really clever and novel stuff pops out. but to say the current model of vibe coding has much to offer in the second case is really quite unclear. to the extent to which coding is the production of boilerplate is really a problem with APIs and abstraction design. if we can get LLMs to mitigate some of that I the short term without causing too much distraction, that's fine, but we should really be using that to inform the solution to the fundamental problem. so for me what's missing in your model is how LLMs are supposed to be used 'properly'. I don't think laziness is really the right cut here, make-work is make-work, and there's plenty of real work to be done. but in what sense does LLM usage for code actually improve our understanding of these systems and get us more agency?
wijej 6mo ago
lol Just lol. Is this what you guys mean by productivity boost? Comical. LLM’s aren’t all that great - it’s more that most orgs are horribly inefficient. Like it’s amazing how bad they are. That’s why Elon succeeded with spacex - he saw how horrible inefficient the industry was. And used that thinking to take a gamble and it’s paid off.
- jnovek 6mo ago
  > most orgs are horribly inefficient Considering that that’s been a running complaint for like 50 years, it doesn’t seem like project management is going to get better on its own at this point. So, yes, an LLM does represent a productivity boost in that area.
  - batshit_beaver 6mo ago
    The problem is that organizations are inefficient in such a way that extra output from white collar workers doesn't translate to improved org-wide performance in a positively correlated, linear fashion. When the org is misaligned, mismanaged, has poor customer feedback loops, bad product market fit, too much bureaucracy, etc etc no amount of AI slop is going to make a meaningful impact on its bottom line. In fact, it will likely do the opposite through combination of exponentially increasing complexity, combined with worker force deskilling, layoffs, and rising token prices. Real bottleneck is and always has been communication & alignment. It might make the employees _happier_ in the interim though, which, I believe, is what we're predominantly seeing during this AI mania. People fed up with the bullshit jobs of rewriting the same service for the 5th time in 2 years or creating TPS reports weekly just for their manager to throw them directly in the trash are absolutely giddy that they no longer have to do this manually. I think we need to question the economic value of these jobs in the first place, though. I've worked at big tech prior to LLMs becoming a thing, and consistently saw projects of 20-50 people carried by 2-3 individuals that actually understood what needed to be done. I don't think this ratio will be any better with genAI, and I also don't think that tokenmaxxing has any meaningful correlation with impact. Bullshit jobs (and questionable personal projects) just get done faster now. Yay, I guess.
well_ackshually 6mo ago
> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves Yes please, I've seen the vibecoded slop PMs put out every day because software engineering is simply not a skill they have, and I'd love to make a LOT of money fixing their crap once it dies in production <3
- wijej 6mo ago
  I’m a former PM who’s now a founder and all the engineers I worked with loved me. I can tell you right now most pm’s are absolutely useless and glorified project managers who don’t know how to think and get in the way - and don’t know how to enable engineers to be more productive.
- satvikpendem 6mo ago
  I already do the latter, not very difficult to get into. Good consulting money.
hedgehog 6mo ago
If you do that someone still needs to make sure the details make sense which, from experience, sometimes they will and sometimes they won't. When I open tickets using automation I often back into the ticket from a running implementation that passes tests so the description is at least internally consistent but there are often still issues that need corrected.
- satvikpendem 6mo ago
  That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation.
  - AdieuToLogic 6mo ago
    > That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation. The bottleneck is understanding, never "code generation." Below is an an axiom which has served me well over the years. Perhaps it will for you as well. When making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely.
    - satvikpendem 6mo ago
      Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.
      - AdieuToLogic 6mo ago
        > Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD. If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them. More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed. Conversely, I have too often observed rapid code generation lacking intrinsic understanding fail to deliver satisfactory solutions.
lr4444lr 6mo ago
I can't imagine SWEs will be reduced to SDETs anymore than attorneys will be reduced to spell-checkers on AI powered case briefs. I am a very AI-forward person, but hallucinations are becoming more pernicious than ever even as they get less frequent, especially if the code actually works. A human absolutely has to guide these processes at a macro level for sustainability for SaaS as it evolves with business needs. Maybe for one and done systems with no maintenance/no updates/no security patches you can reduce humans to SDETs, but systems like that are more the exception than the norm.
- satvikpendem 6mo ago
  By SDET I mean one who reviews not writes code, maybe we have different definitions of that term because you also mention humans being needed to guide the processes. Even still, other professions interact with the real social world which is not necessarily the case with programming. A lawyer will always be needed because judgments are and must be made by humans only. Software on the other hand can be built and tested in its own loop, especially now with human readable specifications. For example, I wanted to build an app and told Claude and it planned out the features, which I reviewed and accepted, then it built, wrote tests, used MCPs including the browser for interacting with the UI and taking screenshots of it, finding any bugs and regressions, and so on until an hour later it came back with the full app. Such a loop is not possible in other professions.
  - lr4444lr 6mo ago
    No one's arguing you can't stand up a good MVP. It's when you have to iterate to handle changing business needs, scale issues, and integrate with other systems where the entropy becomes a scary concern over a long enough timeline. And it's not just "checking" - it's wholesale rejections of code, reframing prompts to target specific classes or approaches, etc... I don't think you will take the human out planning any time soon.
    - satvikpendem 6mo ago
      I agree, humans will always be there.
majormajor 6mo ago
IMO the code-generation for boilerplate and the improvement of copypasta quality are much bigger improvements than that. PMs turning their brain off and letting the LLMs extrapolate from quick and dirty bashing of text into a template (or, PMs throwing customer feedback at a slackbot to generate a jira ticket form it) can be better than PMs doing nothing but passing ill-defined reqs directly into the ticket, but that's a low bar. And it doesn't by itself solve the problems of the details that got generated for this ticket subtly conflicting with the details that got generated for (and implemented) in a different ticket 8 months ago.
newobj 6mo ago
I literally can’t tell if this comment is a joke or not.
- satvikpendem 6mo ago
  The last sentence was party facetious sure but the first paragraph is not, I have seen ticket quality go up quite a bit from a few years ago.
decidu0us9034 6mo ago
Maybe for some subset of sotware (like CRM panels or something) PMs will do everything. But if you're projecting the way one sort of software (ie user-facing, business use oriented software) is developed and put to use with software writ large, then no I don't think so
- satvikpendem 6mo ago
  Sure, I'm just talking about 90% of software which is basic CRUD, not complex systems or microcontroller programming. In that case it's likely that just a PM could build something with LLMs.
  - sarchertech 6mo ago
    For basic CRUD we’ve had no code solutions that PMs could have been using for decades. The truth of the matter is that software starts as basic CRUD and then given time and users evolves into its own special snowflake. Every single system given enough time and users will become a “complex system”.
    - satvikpendem 6mo ago
      The difference is no code tools are not flexible in the same way LLMs are. As long as PMs can articulate those snowflake requirements to the LLM then it will happily build it.
      - sarchertech 6mo ago
        Sure for a few. But eventually the interaction of all those complex features turns it into a “complex system”. Which as you yourself just said are not conducive to PM vibe coding.
        satvikpendem 6mo ago
        I'd say the majority of these sorts of tools are actually simple enough to be vibe coded, only some are complex enough to require an actual engineer building it rather than vibe coding. So in most cases it's actually a win for the PM.
derefr 6mo ago
> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves I'm guessing they've tried (or been induced to try by upper management), but given up because they don't know how to debug any problems that arise due to the LLM working itself into a corner. Coding-agent LLMs act a lot like junior devs. And junior devs are: eager to write code before gathering requirements; often reaching for dumb brute-force solutions that require more work from them and are more error-prone, rather than embracing laziness/automation; getting confused and then "spinning their wheels" trying things that clearly won't work instead of asking for help; not recognizing when they've created an X-Y problem, and have then solved for their Y but not actually solved for the original problem X; etc. The way you compensate for those inexperience-driven flaws in junior devs' approach, is to have them paired with, or fast-iteration-code-reviewed by, senior devs. Insofar as a PM has development experience, it's usually only to the level of being a "junior dev" themselves. But to compensate for LLMs-as-junior-devs, they really need senior-dev levels of experience. The good PMs know all of this, and so they're generally wary to take responsibility for driving the actual coding-agent development process on all but the most trivial change requests. A large part of a PM's job is understanding task assignment / delegation based on comparative advantage; and from their perspective, it's obvious that wielding LLMs in solution-space (as opposed to problem-space, as they do) is something still best left to the engineers trained to navigate solution-space.
- deleted 6mo ago
  [deleted]
deleted 6mo ago
[deleted]
beej71 6mo ago
> Then devs can copy paste this Jira ticket content into the LLM agent of choice Super glad to have gotten out when I did...
bodge5000 6mo ago
> it seems the PMs are already halfway there to implementation Halfway there feels way overblown, and only seems to further devalue to work that devs do. Having clearly written requirements would be fantastic, and even as someone less pro AI even I can see great utility for it here, but its not halfway there to implementation. Not even 25% in all honesty, since edge cases and unforeseen consequences can cause changes to the spec midway through development.
datsci_est_2015 6mo ago
> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves and a few devs will be around as SDETs rather than full blown implementers. Judging by every PM I’ve worked with, 0% chance of this happening. Much sooner would see SWEs making PMs redundant than the other way around. Unless of course you want a system that falls apart like a house of cards as soon as you get a single user for your vaporware.

OptionOfT 6mo ago

Except... no one validates the generated tickets, and it's full of inaccuracies. And then someone copy pastes it into Claude and now those inaccuracies become part of the code and tests.

satvikpendem 6mo ago
The PMs validate it, why do you think they don't read over it to make sure it fits what they want? You might say "well they're lazy, look why they didn't write enough detail to start off with" but for lots of people, reviewing something to make sure it's close to what they want and then tweaking it is much easier than writing it from scratch. It's the equivalent of writer's block and is why a common advice given to writers is to put anything they can onto the page then edit it later.
- BugsJustFindMe 6mo ago
  > The PMs validate it, why do you think they don't read over it to make sure it fits what they want? Hahahahahaha. Sorry, I couldn't help myself; this reads like satire. The answer is "real life experience says otherwise".
  - ethin 6mo ago
    Yeah I was so tempted to ask if this person has ever actually met a project/product manager...
    - satvikpendem 6mo ago
      Maybe you both just have bad PMs, because just like good devs they should also be reviewing their work. My point was that it is more likely for PMs to review and edit a generated ticket than to have to write it all themselves which they often won't do.
      - BugsJustFindMe 6mo ago
        > My point was that it is more likely for PMs to I feel compelled to point out to you that this is a completely unsustainable, unsupportable, unsubstantiable claim. You have met ~0% of PMs, and of the ones you've met maybe you've experienced a non-zero percentage of their work, but statistically that's also very unlikely. If you think you can say what most PMs do or what PMs are likely to do, then, I'm sorry, but you are not even thinking like an engineer. You're thinking, actually, a lot more like a PM to many of us. > just like good devs I'm so sorry, my sides just can't handle the starry-eyed nature of these takes. This is just too much for me. To many of us this reads like you've never met people before. But who knows, maybe you live in Lake Wobegon, where all the women are strong, all the men are good-looking, and all the children are above average! If so then we're jealous, but you still should be more careful about how unrigorous your mental model is because it will make you a worse engineer. Experience with different PMs and developers aside, the older you get in the profession the more you will hopefully realize that none of your quality effort fantasy matters. Sales happen and money rolls in independently of whether you think the PMs or the people who call themselves engineers do a "good job". Businesses thrive on sales and marketing, not engineering.
        satvikpendem 6mo ago
        What a strange response. By your logic you've met ~0% of developers too yet I assume you can distinguish good development practices from bad. I also mentioned good PMs which by definition review and write good tickets with a clear explanation of the problem and what they want the solution to be. If personally meeting millions of people is the epistemic standard you have to know something then I'm not sure how you know anything at all. As to your latter point, not sure why you think I think business doesn't continue on even with bad employees, of course it does and I didn't say otherwise. But that does not mean they're doing a good job, those two are orthogonal concepts. And I'm not sure how we even got to this, the original point was that I personally as a dev can physically see PM productivity increasing with AI, even as other devs in this thread seem not to. For a competent PM, a tool that automates a detailed first draft fundamentally changes the psychology of ticket creation. If your argument is just "bad PMs will still be bad," then sure, I agree, but that doesn't really engage with how the tooling changes the workflow for everyone else.
- majormajor 6mo ago
  > The PMs validate it, why do you think they don't read over it to make sure it fits what they want? The PM has historically often not had a detailed enough mental model of the implementation to spot the hard parts in advance or a detailed enough mental model of the customer desires to know if it's gonna be the right thing or not. Those are the things that killed waterfall. You can use LLM tools to help you improve both those areas. Synthesizing large amounts of text and looking for inconsistencies. But the 80th-percentile-or-lower person who was already not working hard to try to get ahead of those things still isn't going to work any harder than the next person and so won't gain much of a real edge.
  - Avicebron 6mo ago
    I'm glad you mentioned it and TFA briefly mentioned waterfall. The second graph shown in the article with documentation overlapping the dev cycle, it's like the worse of both agile and waterfall. It's supposedly real-time waterfall. Normally waterfall works where the scope is extremely-well defined and articulated in design plans. Which shortens dev time because prior to AI code was mostly deterministic. Here we have to do waterfall level of documentation while iterating on a non-deterministic solution (code gen) to non-deterministic requirements (per usual). It's bonkers. I still think the technology is cool though. And to answer the questioner.. Have you worked with a PM? Most of the ones I've worked with try to be simultaneously in charge yet not responsible for anything. Validating something implies skill and responsibility.
  - satvikpendem 6mo ago
    Then they're just bad PMs and don't deserve to have the job. That can be said in any profession, devs or lawyers or doctors who blindly accept LLM output without review are bad employees.
    - BugsJustFindMe 6mo ago
      > Then they're just bad PMs and don't deserve to have the job. Nobody "deserves" anything. They do have the jobs though. Thinking that the world isn't full of people doing what they need to do to get by who don't give a shit about fitting a fantasy ideal is wild.
- zxornand 6mo ago
  I think validating a fully generated novel of a ticket, is much harder than thinking through the problem in the first place and creating your own ticket. We see it with code too right? It’s harder to review code than to write it. On top of that the LLM can work so fast that the amount of things that need validating grows! This is where humans get lazy and the problems come in IMO. Whether its a PM not validating their ticket, or a dev doing a bad code review. Add on to that that the incentives currently are to move fast and trust the AI. It becomes clear to me that a lot of that review work either won’t be done at all, or won’t be nearly thorough enough.
  - paulhebert 6mo ago
    I agree. I hate getting tickets like this because they’ve often gone down the wrong path and I have to work backwards to understand the actual problem and the right way to solve it
  - satvikpendem 6mo ago
    The tickets are not "novel"-length, they are about a few bulleted lists of the sections I mentioned above. In that case it is indeed way easier to review that a ticket only saying "do X with Y data." Reviewing code is harder than reviewing text because code does something and has interdependencies and therefore must be correct in its function, do not mix the two. This is like saying an editor reviewing an article or novel is harder than actually writing the novel which is blatantly incorrect.
    - zxornand 6mo ago
      Most real tickets are more complicated than “Do x with Y data” and also have many interdependencies throughout the business
      - satvikpendem 6mo ago
        Most? That's doubtful especially when a lot of tickets are simply CRUD which are fine being generated by an LLM. Those that are more complex require more review and interdependency management, sure, but to say that that is most tickets is simply not correct.
- mrbombastic 6mo ago
  just this week i pushed back on some requirements in a very detailed product spec I was implementing to speed up time to ship. The pm had no idea what I was talking about because the requirements were invented by an LLM. This is not a bad PM, discipline doesn't scale.
resters 6mo ago
This failure is human laziness, not an issue with the technology. People who use AI because they are trying to avoid doing work fall into a completely different category than people using AI as a force multiplier and for skills/capabilities enhancements / quality improvement.
- OptionOfT 6mo ago
  It's also the only way to get those massive increases in productivity.
- danaris 6mo ago
  This is very much a "you're holding it wrong" response. If your technology relies on humans using it in ways that go against the ways they are inclined to use them, then that is an issue with the technology.
  - majormajor 6mo ago
    I don't think that works as a critique of LLMs because it's far too broadly applicable to well-accepted tools. Are advanced calculators bad because a student could use the CAS to ace calculus homework, exams or the SAT without actually learning the material? Is copy/paste bad because a person could use it to copy/paste code from one place to another without noticing some of the areas they need to update in the new location, adding bugs and missing a chance to learn some more subtleties of the system? Is Git bad because a manager could use it to just measure performance by number of lines of code committed instead of doing more work to actually understand everyone's performance? Many tools can be used lazily in ways that will directly work against a long term goal of improving knowledge and productivity.
    - convolvatron 6mo ago
      but in this case that's exactly what AI is doing, and no more. its filling in the gaps with some plausible sounding goo so that the person doesn't have to worry about the details. ok, so for some of the jobs we're doing plausible sounding goo is just fine. and that's kinda sad. but the 'just playing around' case is fine for PSG, this isn't a serious effort but just seeing how things might work out without much effort. taking the remainder, where understanding and intent are important, the role of the ai is produce PSG, but the intentional person now goes through everything and plucks out all the nonsense. this may take more or less time than simply writing it, but we should understand this is resulting in less real engagement by the ultimate author. where this is actually interesting is a parallel to Burrough's cutup method - where source text and audio were randomly scrambled and sometimes really clever and novel stuff pops out. but to say the current model of vibe coding has much to offer in the second case is really quite unclear. to the extent to which coding is the production of boilerplate is really a problem with APIs and abstraction design. if we can get LLMs to mitigate some of that I the short term without causing too much distraction, that's fine, but we should really be using that to inform the solution to the fundamental problem. so for me what's missing in your model is how LLMs are supposed to be used 'properly'. I don't think laziness is really the right cut here, make-work is make-work, and there's plenty of real work to be done. but in what sense does LLM usage for code actually improve our understanding of these systems and get us more agency?

wijej 6mo ago

lol Just lol. Is this what you guys mean by productivity boost? Comical. LLM’s aren’t all that great - it’s more that most orgs are horribly inefficient. Like it’s amazing how bad they are. That’s why Elon succeeded with spacex - he saw how horrible inefficient the industry was. And used that thinking to take a gamble and it’s paid off.

jnovek 6mo ago
> most orgs are horribly inefficient Considering that that’s been a running complaint for like 50 years, it doesn’t seem like project management is going to get better on its own at this point. So, yes, an LLM does represent a productivity boost in that area.
- batshit_beaver 6mo ago
  The problem is that organizations are inefficient in such a way that extra output from white collar workers doesn't translate to improved org-wide performance in a positively correlated, linear fashion. When the org is misaligned, mismanaged, has poor customer feedback loops, bad product market fit, too much bureaucracy, etc etc no amount of AI slop is going to make a meaningful impact on its bottom line. In fact, it will likely do the opposite through combination of exponentially increasing complexity, combined with worker force deskilling, layoffs, and rising token prices. Real bottleneck is and always has been communication & alignment. It might make the employees _happier_ in the interim though, which, I believe, is what we're predominantly seeing during this AI mania. People fed up with the bullshit jobs of rewriting the same service for the 5th time in 2 years or creating TPS reports weekly just for their manager to throw them directly in the trash are absolutely giddy that they no longer have to do this manually. I think we need to question the economic value of these jobs in the first place, though. I've worked at big tech prior to LLMs becoming a thing, and consistently saw projects of 20-50 people carried by 2-3 individuals that actually understood what needed to be done. I don't think this ratio will be any better with genAI, and I also don't think that tokenmaxxing has any meaningful correlation with impact. Bullshit jobs (and questionable personal projects) just get done faster now. Yay, I guess.

well_ackshually 6mo ago

> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves Yes please, I've seen the vibecoded slop PMs put out every day because software engineering is simply not a skill they have, and I'd love to make a LOT of money fixing their crap once it dies in production <3

wijej 6mo ago
I’m a former PM who’s now a founder and all the engineers I worked with loved me. I can tell you right now most pm’s are absolutely useless and glorified project managers who don’t know how to think and get in the way - and don’t know how to enable engineers to be more productive.
satvikpendem 6mo ago
I already do the latter, not very difficult to get into. Good consulting money.

hedgehog 6mo ago

If you do that someone still needs to make sure the details make sense which, from experience, sometimes they will and sometimes they won't. When I open tickets using automation I often back into the ticket from a running implementation that passes tests so the description is at least internally consistent but there are often still issues that need corrected.

satvikpendem 6mo ago
That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation.
- AdieuToLogic 6mo ago
  > That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation. The bottleneck is understanding, never "code generation." Below is an an axiom which has served me well over the years. Perhaps it will for you as well. When making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely.
  - satvikpendem 6mo ago
    Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.
    - AdieuToLogic 6mo ago
      > Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD. If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them. More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed. Conversely, I have too often observed rapid code generation lacking intrinsic understanding fail to deliver satisfactory solutions.

lr4444lr 6mo ago

I can't imagine SWEs will be reduced to SDETs anymore than attorneys will be reduced to spell-checkers on AI powered case briefs. I am a very AI-forward person, but hallucinations are becoming more pernicious than ever even as they get less frequent, especially if the code actually works. A human absolutely has to guide these processes at a macro level for sustainability for SaaS as it evolves with business needs. Maybe for one and done systems with no maintenance/no updates/no security patches you can reduce humans to SDETs, but systems like that are more the exception than the norm.

satvikpendem 6mo ago
By SDET I mean one who reviews not writes code, maybe we have different definitions of that term because you also mention humans being needed to guide the processes. Even still, other professions interact with the real social world which is not necessarily the case with programming. A lawyer will always be needed because judgments are and must be made by humans only. Software on the other hand can be built and tested in its own loop, especially now with human readable specifications. For example, I wanted to build an app and told Claude and it planned out the features, which I reviewed and accepted, then it built, wrote tests, used MCPs including the browser for interacting with the UI and taking screenshots of it, finding any bugs and regressions, and so on until an hour later it came back with the full app. Such a loop is not possible in other professions.
- lr4444lr 6mo ago
  No one's arguing you can't stand up a good MVP. It's when you have to iterate to handle changing business needs, scale issues, and integrate with other systems where the entropy becomes a scary concern over a long enough timeline. And it's not just "checking" - it's wholesale rejections of code, reframing prompts to target specific classes or approaches, etc... I don't think you will take the human out planning any time soon.
  - satvikpendem 6mo ago
    I agree, humans will always be there.

majormajor 6mo ago

IMO the code-generation for boilerplate and the improvement of copypasta quality are much bigger improvements than that. PMs turning their brain off and letting the LLMs extrapolate from quick and dirty bashing of text into a template (or, PMs throwing customer feedback at a slackbot to generate a jira ticket form it) can be better than PMs doing nothing but passing ill-defined reqs directly into the ticket, but that's a low bar. And it doesn't by itself solve the problems of the details that got generated for this ticket subtly conflicting with the details that got generated for (and implemented) in a different ticket 8 months ago.

newobj 6mo ago

I literally can’t tell if this comment is a joke or not.

satvikpendem 6mo ago
The last sentence was party facetious sure but the first paragraph is not, I have seen ticket quality go up quite a bit from a few years ago.

decidu0us9034 6mo ago

Maybe for some subset of sotware (like CRM panels or something) PMs will do everything. But if you're projecting the way one sort of software (ie user-facing, business use oriented software) is developed and put to use with software writ large, then no I don't think so

satvikpendem 6mo ago
Sure, I'm just talking about 90% of software which is basic CRUD, not complex systems or microcontroller programming. In that case it's likely that just a PM could build something with LLMs.
- sarchertech 6mo ago
  For basic CRUD we’ve had no code solutions that PMs could have been using for decades. The truth of the matter is that software starts as basic CRUD and then given time and users evolves into its own special snowflake. Every single system given enough time and users will become a “complex system”.
  - satvikpendem 6mo ago
    The difference is no code tools are not flexible in the same way LLMs are. As long as PMs can articulate those snowflake requirements to the LLM then it will happily build it.
    - sarchertech 6mo ago
      Sure for a few. But eventually the interaction of all those complex features turns it into a “complex system”. Which as you yourself just said are not conducive to PM vibe coding.
      - satvikpendem 6mo ago
        I'd say the majority of these sorts of tools are actually simple enough to be vibe coded, only some are complex enough to require an actual engineer building it rather than vibe coding. So in most cases it's actually a win for the PM.

derefr 6mo ago

> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves I'm guessing they've tried (or been induced to try by upper management), but given up because they don't know how to debug any problems that arise due to the LLM working itself into a corner. Coding-agent LLMs act a lot like junior devs. And junior devs are: eager to write code before gathering requirements; often reaching for dumb brute-force solutions that require more work from them and are more error-prone, rather than embracing laziness/automation; getting confused and then "spinning their wheels" trying things that clearly won't work instead of asking for help; not recognizing when they've created an X-Y problem, and have then solved for their Y but not actually solved for the original problem X; etc. The way you compensate for those inexperience-driven flaws in junior devs' approach, is to have them paired with, or fast-iteration-code-reviewed by, senior devs. Insofar as a PM has development experience, it's usually only to the level of being a "junior dev" themselves. But to compensate for LLMs-as-junior-devs, they really need senior-dev levels of experience. The good PMs know all of this, and so they're generally wary to take responsibility for driving the actual coding-agent development process on all but the most trivial change requests. A large part of a PM's job is understanding task assignment / delegation based on comparative advantage; and from their perspective, it's obvious that wielding LLMs in solution-space (as opposed to problem-space, as they do) is something still best left to the engineers trained to navigate solution-space.

deleted 6mo ago
[deleted]

deleted 6mo ago

[deleted]

beej71 6mo ago

> Then devs can copy paste this Jira ticket content into the LLM agent of choice Super glad to have gotten out when I did...

bodge5000 6mo ago

> it seems the PMs are already halfway there to implementation Halfway there feels way overblown, and only seems to further devalue to work that devs do. Having clearly written requirements would be fantastic, and even as someone less pro AI even I can see great utility for it here, but its not halfway there to implementation. Not even 25% in all honesty, since edge cases and unforeseen consequences can cause changes to the spec midway through development.

datsci_est_2015 6mo ago

> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves and a few devs will be around as SDETs rather than full blown implementers. Judging by every PM I’ve worked with, 0% chance of this happening. Much sooner would see SWEs making PMs redundant than the other way around. Unless of course you want a system that falls apart like a house of cards as soon as you get a single user for your vaporware.