Live data from Hacker News

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

frederickvanbrabant.com

431–440 of 490 posts

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

#431
post #8

> Yes, AI can generate code quickly (whether that’s a good thing is open for debate), but that doesn’t mean it’s generating the correct code. No, the code is actually almost always correct. The way it’s added is probably not what you’re going to like, if you know your code base well enough. You know there’s some ceremony about where things are added, how they are named, how much comments you’d like to add and where e…

> No, the code is actually almost always correct.

I wouldn't go that far. It is actually almost always incorrect in that its incomplete. It also needs more iterating and bug fixing.

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

#433
post #269

Earlier quoted context omitted.

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

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: 158,000x total slowdown

I think that "2-3x additional penalty" refers to this:

> The 2.78x code bloat means more instruction cache misses, which compounds the register spilling penalty.

Also, the analysis refers elsewhere to other factors that weren't included in this part.

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

#434

Earlier quoted context omitted.

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 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, when the reality is that does not happen except for a minority — meaning everybody needs to live in this reality.

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

#435
post #295

Earlier quoted context omitted.

And that’s fine. I was pointing out that a simpler solution exists. I prefer simple solutions, because I want to test whatever idea I have in real world situation first before I go for a more complete one. Kinda like doodling before committing to do a sketch (or spend weeks doing a painting). > It's been 30+ years, we deserve a better desktop experience That desktop experience would need to be like smalltalk (where i…

There's also a pattern based on the simple solution that used to be more common: One command-line program for updating and querying the current state, and a second GUI one that just acts as a dumb interface for the first one. Even aside from separation-of-concerns purity, there are two more practical benefits: this gives you scriptability (say, automatically choosing an environment on startup) as well as easier suppo…

Experience has taught us that the two operating modes are different enough by nature, that you need slightly different APIs for each (look at tools wrapping CLI programs: they generally suck one way or another).

What the industry settled on is building an API (library or service) around the data model and business logic, and then building UIs on top.

When done well, UIs are relatively shallow wrappers around the library, but do allow being creative about the UX too.

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

#436

Earlier quoted context omitted.

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.

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

In my opinion software is a "set of decisions". If you let the AI loose, you will get software and the AI will make decisions on your behalf. Even if you read the code once for review, you probably won't know what those decisions were, until you've familiarized yourself with the code base.

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

#437

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…

Also things like improving devx - nicer log analysis, speeding up test suites, auto handing some CI failures, improving scripting, tooling etc.

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

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

[deleted]

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

#439
Non-engineer here, doing growth at a small company, using these tools on side projects as well. The thing i find expensive is how to trust the output. I am not a coder so i cant rate the code to know if it's right. I end up running a second model to check the first one's output or testing. That takes time as well :)

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

#440
post #429

Earlier quoted context omitted.

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

"that’s an organisational level problem that existed anyway"

That's very true to many organizations. One cannot just slap an AI tool on it when you are dealing with fundamental organizational problems in the first place.

"they can spend their time on the larger more software engineering level problems"

For sure, devs still needs to focus on the right type of work and maintain the balance. I built a tool to just do that: https://worktypefocus.com/

Post reply on HN