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

311–320 of 490 posts

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

#311

Post by satvikpendem »

danaris wrote: post #224
jnovek wrote: post #159

Earlier quoted context omitted.

> This is very much a "you're holding it wrong" response This isn’t actually an argument for or against anything, I don’t know why people say this. It is entirely possible that people are using this brand new, historically unprecedented tool wrong. Cars have been a huge success in spite of requiring people to learn a bunch of new things use them.

It's not about having to learn things ; it's about the required methods of using the tool going directly against the grain of the way people in general operate. The classic "you're holding it wrong" was about the iPhone 4: sure, people could learn to hold the iPhone in such a way that they didn't block the particular parts of the antenna that were (supposedly) the problem. But "holding an iPhone" is a fairly natural…

> 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 are lazy or not able to pay attention and crash.

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

#312

Post by physicsguy »

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…

What I've seen in an AI-forward looking environment is that it's much more common for PM/POs to be knocking up at least a UI prototype now, and experimentation is happening often even before writing the tickets. Similarly when devs are proposing something they often are coming with a couple of prototypes already implemented. Both of those mean decisions are coming a lot quicker.

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

#313

Post by ianbutler »

pron wrote: post #285
ianbutler wrote: post #279

Earlier quoted context omitted.

> Can they write production software without careful and close human supervision? Not yet. That's not disparagement, just an observation of where we are today. I never claimed they could! I just view this as a successful experiment. I don't think anthropic was making that claim with their experiment either. It feels reflexive to the moment to argue against that claim, but I tend to operate with a bit more nuance than…

The experiment failed to produce a workable C compiler despite 1. the job not being particularly hard, 2. the available specs and tests are of a completely higher class of quality than almost any software, not to mention the availability of other implementations that the model trained on. You can call that a success (as it did something impresssive even though it failed to produce a workable C compiler) but my point…

That's great and all, but that's not the point I was making and you're engaging rather uncharitably on it. So when you view it from the perspective of capability increase it's rather impressive. Note the slope of progress which this experiment was to show.

Edit: Maybe uncharitably is too strong, but we're talking past each other.

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

#314

Post by nuancebydefault »

Philip-J-Fry wrote: post #278
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 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…

> Requirements gathering is NOT a software engineering problem. Software is implementation, product is behaviour. That's the split.

That's a theory but I've never seen this work in practice. A piece of software is unique. If it weren't, we'd just use the cp command.

What usually happens is you get a set of requirements that looks simple. Then you start thinking about a design and see 10 different possibilities, each corresponding to a slightly different interpretation of the requirements set. You iterate a few times reviewing the designs with who set the requirements and a few peers and see more possible variations to the requirements. You need to double check its parent requirements up to the master requirements. Then you need to take time/feature/quality tradeoffs, affecting the fulfillment of requirements.

Once starting to implement, you see dependencies to other software (framework, sdk, drivers, language features,...) and understand that other software is not what you thought, or has bugs. Or you see an issue with performance or see that one particular feature becomes unfeasible.

That's where all the complexity goes. AI doesn't change that, but can make prototyping iterations and bug hunting faster, as long as someone holds it on a leash and understands its decisions.

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

#315

Post by KajMagnus »

pron wrote: post #285
ianbutler wrote: post #279

Earlier quoted context omitted.

> Can they write production software without careful and close human supervision? Not yet. That's not disparagement, just an observation of where we are today. I never claimed they could! I just view this as a successful experiment. I don't think anthropic was making that claim with their experiment either. It feels reflexive to the moment to argue against that claim, but I tend to operate with a bit more nuance than…

The experiment failed to produce a workable C compiler despite 1. the job not being particularly hard, 2. the available specs and tests are of a completely higher class of quality than almost any software, not to mention the availability of other implementations that the model trained on. You can call that a success (as it did something impresssive even though it failed to produce a workable C compiler) but my point…

Saying the model failed to write a competitive C compiler makes more sense.

I don't think they tried to do that though.

> today's models are not yet able to produce production software without close supervision, even when uncharacteristically good specs and hand-written tests exist.

That's a good point anyway

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

#316

Post by giancarlostoro »

AI is not supposed to bypass the process, but it can speed up things nonetheless, it can help with refactoring, writing boilerplate, finding errors you never even spotted before, and things that linters cannot catch.

I see so many comments that seem to me like either they don't use standard known processes, or they assume AI doesn't need you to follow the standards.

Can I ship more code and features? Absolutely I can, if I have a good set of requirements, and thorough testing. All AI written code needs to be reviewed and tested, and should be in discrete commits and pull requests, anyone pushing a PR with thousands of lines of code is a red flag, you wouldn't do it without AI, why would you do it with AI? Major rewrites / refactors are the only known exception, and even then I would argue that these should still have discrete commits you can switch to so you can see how things changed, and make a more informed decision.

If you show me a massive one shot commit or PR I will deny it. Break it down into bits a normal developer can audit.

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

#317

Post by rowanG077 »

pron wrote: post #277
rowanG077 wrote: post #257

Earlier quoted context omitted.

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.

People who independently tried to use it reported that it is very much not workable: - "CCC compiled every single C source file in the Linux 6.9 kernel without a single compiler error (0 errors, 96 warnings). This is genuinely impressive for a compiler built entirely by an AI. However, the build failed at the linker stage with ~40,784 undefined reference errors."( https://github.com/harshavmb/compare-claude-compiler…

Well then as you say a 10-50KLOC C compiler is workable. Could you show me the C compiler that does manage to compile a modern Linux kernel that is of that size?

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

#319

Post by thisisit »

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…

> we should reduce coordination overhead and empower individuals and teams to make decisions and execute on them.

Improved collaboration. Says every new CEO and manager. The notion that this is ever going to be solved especially with different experience, views, agendas etc needs to die too. AI is surely not going to help and with that roadblock iterating faster doesn’t help because then people want to try just for trying.

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

#320

Post by pron »

KajMagnus wrote: post #315
pron wrote: post #285

Earlier quoted context omitted.

The experiment failed to produce a workable C compiler despite 1. the job not being particularly hard, 2. the available specs and tests are of a completely higher class of quality than almost any software, not to mention the availability of other implementations that the model trained on. You can call that a success (as it did something impresssive even though it failed to produce a workable C compiler) but my point…

Saying the model failed to write a competitive C compiler makes more sense. I don't think they tried to do that though. > today's models are not yet able to produce production software without close supervision, even when uncharacteristically good specs and hand-written tests exist. That's a good point anyway

> 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 even more importantly, the compiler cannot be fixed or evolved. It's bricked (at least as far as today's models' capabilities go). For any kind of software, not being able to improve or fix anything or add any new feature means it's effectively dead.

You could not use it in production even if no other C compiler existed.

Post reply on HN