How about a chatbot in front of feature requests that gets all the details the fist time?
I don't think AI will make your processes go faster
461–470 of 490 posts
Re: I don't think AI will make your processes go faster
#462Earlier 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…
I was too terse, what I meant by writing good tickets is what you just said, gathering requirements, running it through UX designers and engineers then writing their collective findings into a ticket that can be picked up by an engineer with minimal questions, as they've already been answered in the ticket.
Re: I don't think AI will make your processes go faster
#463Earlier quoted context omitted.
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.
What IQ "means" is separable from what it is. IQ is a measure of performance on IQ tests. That's literally what it is. If a computer system can complete IQ tests, it has an IQ.
The issue is that IQ means less than you want it to.
Re: I don't think AI will make your processes go faster
#464Earlier quoted context omitted.
> selling the benefit as being the AI taking a lot of the work off your shoulders; all you have to do is constantly check its work just in case it makes a mistake. Cars can take you from place to place much faster than a horse can, all you have to do is learn to drive and constantly keep your hand on the wheel. Part of using a technology is, well, learning how to use it. It's not the technology's fault that humans ar…
You do not seem to be engaging in good faith: the GP explicitly discusses "self-driving cars", which come with an expectation that you still need to be "just checking they work well", and we have already seen people not do that, or be bad at it (if you have to jump in in an emergency, that's exactly when you want to have been part of getting to that point to react properly). You are debating how people should behave,…
I know they said self driving cars, I am talking about manual cars, it's two different points even though both are analogies about cars. I am not debating how people should behave, I am debating their thought that technology should just work without any sort of instruction or learning and if it doesn't then it's a tech error not a human error. My point is that many technologies require learning how to use them, and therefore it sometimes is human error.
Re: I don't think AI will make your processes go faster
#465Earlier quoted context omitted.
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.
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.
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.
Re: I don't think AI will make your processes go faster
#466well 2026 is easily the most software I shipped so AI is definitely making the process faster. Sad if you with agree with the post, I'm outlier though AI has enabled me to build several subscription apps that was able to make money, not a lot but it will compound trust me.
Re: I don't think AI will make your processes go faster
#467Earlier quoted context omitted.
It could be written more clearly but I think when it refers to a 4x and a 3x slowdown, it's actually a 4x slowdown and 3x larger code that causes cache misses, and the impact of those cache misses on runtime is surely much larger than 3x. > Each individual iteration: ~4x slower (register spilling) > Cache pressure: ~2-3x additional penalty (instructions don't fit in L1/L2 cache) > Combined over a billion iterations:…
3 times 4 is 12. What's the other 157988x caused by?
You’re searching for 13166x, and not 157988x. “Times” is multiplication not exponentiation.
Re: I don't think AI will make your processes go faster
#468I understand this post comes from the PoV of a developer, but the key point is:
>Maybe this setup is faster compared to the old way of working. But I also think it’s an unfair comparison. Working like this requires a much deeper involvement of domain and product experts. This involvement would mean writing out every feature and bug fix down to the tiniest detail.
The game-changer here with AI in software development is that now the Subject Matter Experts (SMEs) can directly guide AI (Claude Code, Cursor, Codex...etc) to translate the vision into code, review and iterate.
Yes, you are removing the developer from this step of the process, at least to build the MVP version of the service/backend/frontend.
By doing this,the process goes faster, as AI codes faster and the iteration with the SME goes way faster as well since there is no handover; you also lower the "quality attrition" of the process handover (in this case expert to developer), since the expert will explain the function to an AI that also has the deep knowledge in the expert field.
Obviously developers still are needed for the refactoring/hardening/compliance of that vibe-coded solution with corporate architectural/security guidelines, but soon enough those things will be done by AI too.
We are seeing this happening right now at all the big companies who are having a gigantic wave of employees (tech AND business) using Cursor, Claude Code and Codex.
So the skills will need to change and SMEs and developers will probably merge into one person that will have deep domain expertise, some systems and architecture knowledge to work more effectively with AI.
Of course this new reality will bring a lot of challenges. Like the software governance issue that some companies (e.g. Amazon) having problems with the huge proliferation of vibe coded solutions that overlap with each other (probably with different outputs) and create confusion in the business...
Re: I don't think AI will make your processes go faster
#469Earlier quoted context omitted.
A workable C compiler is a ~10-50KLOC program, and a fairly simple one at that (batch, with no concurrency or interaction). That Anthropic's swarm of agents wrote 100KLOC before failing is a symptom of the problem. It's certainly possible that many programs are in the sub 5KLOC range, but it's definitely not "most software". Plus, almost no software has this level of detailed spec, ready-made tests, and a selection o…
The compiler that claude made went way beyond workable. It could compile the full linux kernel afaik. That is much further even beyond standard C.
My dude, that compiler couldn't even do hello world successfully. That isn't workable.
Re: I don't think AI will make your processes go faster
#470Earlier quoted context omitted.
> Now most of the friction comes from alignment and coordination with other teams. Then I see a solution! Why don't we simply put the entire company on one big team?
Putting everyone responsible for some function of a product on one team, instead of having separate departments for separate functions, can do wonders for actually shipping and iterating on software.
I don't remember who said it first but "software teams always ship their org chart" has always stuck with me. How a team is organized has such an outsized hand it what they build.