Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don't think AI will make your processes go faster

frederickvanbrabant.com

Post reply on HN
Print view View original

421–430 of 490 posts

Re: I don't think AI will make your processes go faster

#421

Post by necovek »

satvikpendem wrote: post #340
BugsJustFindMe wrote: post #283

Earlier quoted context omitted.

> 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…

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 kno…

> ...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

This is where the problem is — such PMs are not "good PMs...by definition". They are usually terrible PMs who start with a solution they envision and work backwards to a customer problem or two.

PMs should be able to clearly form a customers' world model, fit that into their business, and clearly articulate needs to the "builders": UX designers and software engineers.

Builders need to form a sufficiently good mental model of the needs to be able to quickly envision a few solutions with different balance between effort/cost and customer/business value, and then dive deeper on the one they agree on with a PM.

IOW, solutions are provided by the builders who understand the effort part better than the PMs.

Yes, there are PMs who can do that just as well (frequently designers/engineers who switched careers, but not only!) — yet they are far and few between!

This desire to own the solution is usually why engineers and PMs cross horns, and why many a smart person will appear a terrible PM too.

Re: I don't think AI will make your processes go faster

#422

Post by graemep »

necovek wrote: post #421
satvikpendem wrote: post #340

Earlier quoted context omitted.

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 kno…

> ...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 This is where the problem is — such PMs are not "good PMs...by definition". They are usually terrible PMs who start with a solution they envision and work backwards to a customer problem or two. PMs should be able to clearly form a customers' world model, fit that into their bu…

> PMs should be able to clearly form a customers' world model, fit that into their business, and clearly articulate needs to the "builders": UX designers and software engineers

What your describing fits a job I did many years ago and my role was distinct from that of the PM and my job title was Business Designer. That was in the context of software that required complex and precise specifications so may not be typical, but I do think running a project and understanding customer needs are different skills.

Re: I don't think AI will make your processes go faster

#423

Post by _the_inflator »

angarg12 wrote: post #189

> This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like. > This is often the part that slows down software development. Trying to figure out what a vague, title only, feature request actually means. But that is exactly what Software Engineering is!. It's 2026 and the notion that you…

It is called product development.

There is a reason why startups succeeded because the founders actually ate their own dog food as well as solved a problem that many felt.

Products are no projects. Product development is so incredible hard.

The reason why I like Steve Jobs is his nerdy personality, best shown in the iTunes key note. For two hours the guy plays around with the app, demonstrating what to do with it, how and why.

Remember, this is the CEO. No wonder lower ranks had a hard time when they came up with ignorance about a product.

Today’s so called Product Owners know next to nothing about their product nor craft.

Design by committee. And this is what will will AI as bloated bottleneck: piling on a mess of documents only ever increasing context windows can barely make sense of.

The lost art of lines deleted is amplified within the AI age.

Re: I don't think AI will make your processes go faster

#424

Post by tovej »

tptacek wrote: post #355
tovej wrote: post #166

Earlier quoted context omitted.

An AI does not have an IQ.

Sure it does. IQ is simply a measure of performance on an IQ test. A simple Python loop around Google search in 2012 had an IQ.

IQ is a (biased) proxy measure for human intelligence. It is not a meaningful measure when applied to a computer system.

Re: I don't think AI will make your processes go faster

#425

Post by alkonaut »

marcus_holmes wrote: post #368
Philip-J-Fry wrote: post #278

Earlier quoted context omitted.

I don't agree. I regularly get pieces of work someone product guy has thought up in an afternoon. They only care about the happy path, and sometimes only part of the happy path. I work for a global company that has to abide by rules and regulations in each country we operate in. The product guy thinks up some feature, we implement the feature, then we're told "actually, we legally aren't allowed to do this in 90% of…

I think this was TFA's point about "engineers have been begging to be involved earlier in the process forever". Which is absolutely true. It has to be someone's job to push back on the Product Guy's stupid idea and answer all the awkward questions about the not-so-happy path with it. Unfortunately, because of the way we've ended up with this process, that person is often the engineer tasked with building it, without…

That's a software developer's main job. Saying no. Or in rare cases saying "yes, but".

If there is a "hierachy" where product managers are seen as superiors to software development, i.e. where product managers decide what to and then only delegate the implementation to software developers, that product will invariably fail. Don't do that.

Re: I don't think AI will make your processes go faster

#426

Post by IanCal »

RaftPeople wrote: post #258
wise0wl wrote: post #180

Earlier quoted context omitted.

I've seen proposals for Product Managers to define those conditions themselves by speaking with the LLM. A continuing architectural diagram is constructed and graph is updated until all cases are covered and then the LLM writes the code, writes the validations, pushes to CI environments, runs tests, schedules prod deploy (by looking at company event schedule), gets CAB approval, deploys code, tests in prod, and fixes…

> I've seen proposals for Product Managers to define those conditions themselves by speaking with the LLM. But the LLM is not aware of how the business works and why, so someone needs to work with the business to extract the information. Typically it's not well documented.

They can ask, they can do a back and forth and they can write documentation to be used from that point onwards and write it in a common style and structure.

These are language models, being able to talk through something with them and have them extract some information is what they excel at. Given that you’d probably get a halfway decent result with a literal fixed set of questions (an Eliza level docbot) gpt 5.5 is going to nail that as a task.

Re: I don't think AI will make your processes go faster

#427

Post by selicos »

juanre wrote: post #273
angarg12 wrote: post #189

> This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like. > This is often the part that slows down software development. Trying to figure out what a vague, title only, feature request actually means. But that is exactly what Software Engineering is!. It's 2026 and the notion that you…

I completely agree. It's more than 40 years since I wrote my first program, and I've never seen software that was first specified and then written and all was good. The most difficult part of any non-trivial engineering is understanding the problem, and the first versions of a piece of software are how you reach that understanding. That's why I do not think that AI-powered "software factories" will ever work. It's wa…

> AI is, however, very good at helping you go fast from the wrong first version to the less wrong second one.

For me using AI as an entry point into developing my own small tools for personal use, this is incredibly useful. I can start with a concept, fail miserably, then scrap it and try again a few times in an evening. And instead of brute forcing something over that time I can hand off analysis to an LLM and read about better solutions or learn more about what I'm trying to implement.

Re: I don't think AI will make your processes go faster

#429

Post by IanCal »

RaftPeople wrote: post #171
ddosmax556 wrote: post #146

This article assumes that AI only has an impact on the development phase which is certainly not true. It can speed up every part of the step. Including ideation, legal, documentation, development, and deployment. Ideation: Throw ideas back & forth, cross reference with knowledge bases, generate design documents. Documentation: Generate large parts of docs. Development: Clear. Deployment: Generate deployment manifests…

I tend to agree with the article. A typical example of trying to add a new significant capability involves many meetings (days, weeks, months, etc. )with the business to understand how their work flows between systems X, Y and Z as well as all of the significant exceptions (e.g. we handle subset A this way and subset B that way, but for the final step we blend those groups together, except for subset C which requires…

I wouldn’t discount the value of moving small tasks away from developers, nor the value of fast cheap prototypes.

Product owners can very quickly get, for many problems, an interactive demo without coding. For lots of problems this can be somewhere from a static html page which shows the interactions to a hacked in feature that lets them actually test if it solves the customer need and try several variations before handing over much more concrete specs of what they want to happen. So much time is lost between getting an idea from someone’s head to code to use to then find out it wasn’t communicated well and then finally that the idea didn’t help anyway and we want it in a different way.

Yes yes I know someone is about to say that now there’s pressure to push the prototype out but that’s an organisational level problem that existed anyway.

And small problems can much faster to solve as well, or even move away from devs. Often people just need some text changed somewhere or html putting together, or some basic code for analysis. They could understand the logic, but the task of writing it from scratch and how to run things may be too much - now you don’t need to prioritise work for a dev to get some sql written and they can spend their time on the larger more software engineering level problems.

Post reply on HN