Live data from Hacker News

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

frederickvanbrabant.com

381–390 of 490 posts

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

#381
post #349
post #320

Earlier quoted context omitted.

> Saying the model failed to write a competitive C compiler makes more sense. Their compiler fails to compile (well, at least link) some C programs altogether, and in other cases it produces code that is 150,000x slower than a real C compiler with optimisations turned off (interestingly, the model trained on the real compiler's source code). That's not "not competitive" but "cannot be used in the real world". But eve…

> Their compiler fails to compile (well, at least link) some C programs altogether, and in other cases it produces code that is 150,000x slower than a real C compiler with optimisations turned off I would bet that those things are also true of at least one expensive commercial C compiler.

I'd love to hear of any currently available commerical C compiler which has that level of issues. I would bet you'll be hard pressed to find one. C compilation is a quite thoroughly solved problem. In any case please provide an example.

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

#382
Worked at a place that spent a ton on an AI automation platform for a process that took 3 weeks. After months of setup, it still took 3 weeks. Nobody had bothered to map out that the real holdup was legal waiting 4 days for clarifications from the business side. AI can't fix bad inputs. Bottlenecks should receive predictable high quality inputs, that's the whole thing in one sentence.

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

#384

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…

> yet I assume you can distinguish good development practices from bad

Uh. We're not talking about knowing what good is, which is completely irrelevant to anything in this thread. You made a claim without qualification about what it is more likely for PMs to do. I can't tell if you've lost the chain or are engaging in some kind of motte and bailey fallacy. Either way it's a bad sign for this conversation.

I'm going to summarize the threads so far. I hope it highlights why what you've said sounds so silly:

Someone: "I see X failing to do Y."

You: "X definitely do Y. Why would you think that X aren't doing Y? Doing Y is the obvious thing for X to do."

Someone: "I literally am seeing it happen right now."

You: "Well then those X are bad."

Someone: "Yeah, no shit. They just said as much."

You: "But most X would do Y."

Someone: "In my experience that is false."

Someone else: "Mine too."

Someone else: "Mine as well."

Someone else: "Same."

You: "The bad ones shouldn't have their jobs."

Someone: "They do though."

You: "But we can tell which ones are the bad ones."

Someone: "Bartender, another drink please."

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

#385

Earlier quoted context omitted.

I've noticed even more than the "hallucinations", just the code is generally quite bad. At least with concurrent and distributed systems stuff (which is really all I know nowadays), it is great at getting a prototype, but the code is generally mediocre-at-best and pretty sub-optimal. I don't know if it's because it is trained on a lot of mediocre and/or buggy code but for concurrency-heavy stuff I've been having to r…

I'm getting the impression that LLMs are just not very good at "reasoning" about time. I have definitely had success getting a coding agent to produce decent concurrent code, but I had to basically lead it by the nose, and I strongly suspect that in most cases it would have taken less time to just do it the old fashioned way.

I've had good luck having it translate TLA+ specs to programming languages. The specs are written by me and my fingers, and I've done most of the interesting concurrency reasoning beforehand.

I'm pretty sure it still saves me time, and if nothing else it's an excuse to write TLA+, and that's fun.

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

#386

Earlier quoted context omitted.

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

Deserving and having are two different things, that doesn't mean they can't be criticized either way. By the same logic bad devs and bad dev practices can also be criticized.

[deleted]

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

#387
Interestingly, there is already role for that called "business analyst". Their job is exactly what's written in here. But surprisingly, I saw them only at SWE vendors (aka head shops), probably because customers don't understand what they really want, and BAs translate their vague requirements for SWEs to work. I would say we are all gradually becoming BA/UX, even if we don't want to call ourselves that.

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

#388

Earlier quoted context omitted.

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

Deserving and having are two different things, that doesn't mean they can't be criticized either way. By the same logic bad devs and bad dev practices can also be criticized.

"They're bad PMs" does not meaningfully respond to people saying the world is full of bad PMs. They know. It was already given. Giving it again in response isn't engaging thoughtfully.

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

#389

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

A previous iteration of my company had a CEO with a simple management idea that I believe worked really well: treat each product team as a mini startup.

That means EVERY role needed to develop the product was in that team. No separate corporate wide QA function, infrastructure and operations function, sales function, project management function, or domain expertise function. All the people performing those functions for that project were part of the project team.

Now this is somewhat hyperbole as if there is no sharing of resources whatsoever you don’t really have a single corporation.

But the idea is clarifying and helps to eliminate silos and tighten communication and feedback loops.

I miss that style of working. Although I try to break those barriers where I can as an individual contributor by just figuring out who needs to talk to who to make things happen and opening those channels of communication.

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

#390
post #269

Earlier quoted context omitted.

Sorry where are we seeing that it failed? It compiled multiple projects successfully albeit less optimized. " It lacks the 16-bit x86 compiler that is necessary to boot Linux out of real mode. For this, it calls out to GCC (the x86_32 and x86_64 compilers are its own). It does not have its own assembler and linker; these are the very last bits that Claude started automating and are still somewhat buggy. The demo vide…

> where are we seeing that it failed? Anthropic said the experiment failed to produce a workable C compiler: - I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality. - The compiler successfully builds many projects, but not all. It's not yet a drop-in replacement for a real compiler. (source: https://www.anthropic.com/eng…

This evaluation appears to be AI-written itself. It claims a 3x slowdown and a 4x slowdown combine to produce a 158000x slowdown "because there are billions of iterations" - yeah well both versions of the program had the same number of iterations.

Does anyone know how the 158000x slowdown happened? That's quite ridiculous.

Post reply on HN