[flagged]
I don't think AI will make your processes go faster
61–70 of 490 posts
Re: I don't think AI will make your processes go faster
#62Earlier quoted context omitted.
I’m not convinced. I’ve been using AI pretty heavily for about 18 months and agents for a little over 6 months. I’m currently working on a data migration for an enormous dataset. I’m writing the tooling in go, which is a language I used to be very familiar with, but that I hadn’t touched in about 12 years when I started this. It definitely helped me get back into go faster. But after the initial speed up, I found mys…
>if so it’s on the order of 10-20%. Nothing revolutionary. For many businesses that is revolutionary. Not sure that's enough magic to make the math work for the trillions being invested, but on a ground level within companies even small wins stack up. You may have burned through $1000 without getting much done, but from a company perspective they've probably got an employee with better instincts as to what does or do…
I think the $1000 was worth spending just as a one time experiment. And there are use cases where LLMs are fantastic. It’s great at debugging because tracking down a bug usually takes much longer than verifying it once it’s pointed out.
Where I have a problem is with the FOMO, panic, and mania that has come down from up top. There are people in my company saying that we should be spending 3x our salaries in tokens.
But if you’re in a business where a 20% speed up is revolutionary, there are so many things that have been on the table for years that you could have been focusing on. I’ve seen at least 5 advances over that have happened over the last 20 years with that kind of boost.
That’s probably about you’d get from spending time really learning vim or eMacs.
Re: I don't think AI will make your processes go faster
#63I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…
What's even worse is that when dealing with human software teams, a vague requirement will (at least in a well-run org) receive demands for further specification. "What do you mean by 'get data'?", etc.
An LLM will just say, "Sure! Here's the fully implemented code that gets the data and give it to the user. " and be done with it.
Re: I don't think AI will make your processes go faster
#64Every large corporation is stuck in communication problems and approval processes. They have grown so large as to have minimal alignment between what the company attempts to produce, what makes the company profitable, and what people actually do. Enshittification, The Gervais Principle, Bullshit Jobs. Pick your favorite, flawed way to look at what is going on, it's all blind people touching different parts of the sam…
While this is true, it doesn’t stop businesses being overzealous with AI. It’s a compound issue of a decade of ZIRP, grow at all costs and then covid overhiring and AI is suddenly poised as some kind of magical panacea.
The broader issue is the sheer number of businesses that build massively overcomplicated stacks, bought heavily into bandage solutions like AWS lambda, got on dumb tech bandwagons like big data, nosql etc. This is just another one.
I think you can engineer yourself into being leaner, in some businesses AI will help but we’ve had over a decade of “we can just add more complexity” and it just does not work.
I’m a rails guy. People forget for every unicorn there’s 10 9 figure businesses just ticking away on some niche with a VPS, rails and like 4-10 devs.
Re: I don't think AI will make your processes go faster
#65This is so true. Recently, I’ve been working on a project involving almost every department, including Product, Engineering, Compliance, Finance, etc.. We kicked things off late last year with a many meetings. Product was primarily coordinating between the teams, but engineers also met directly with non engineering departments to explain technical details and accelerate the timeline.
However, while the engineering team successfully fast tracked development, UAT, and production testing largely thanks to AI other departments only began digging deeper into the project toward the end of April. To be fair, they do use AI in their workflows to some extent, but they haven't adapted their processes to keep pace with engineering's increased productivity.
In my opinion, this lag is mostly because many employees in those departments are older and hesitant to change their routines. While I understand that resistance to change is a natural human trait, what comes to my mind is this beautiful German adage, "Wer nicht mit der Zeit geht, geht mit der Zeit" which loosely translates to, "Who doesn't change with time is left behind by time"
Re: I don't think AI will make your processes go faster
#66Earlier quoted context omitted.
> I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. This was substantially predicted by Fred Brooks in 1986 in the classic No Silver Bullets [1] essay under the sections "Expert Systems" and "Automatic Programming"…
It's interesting how predictable some of this is. The LLMs turn out fully formed clones of stuff for which there exists copious amounts of code openly searchable on the web doing the exact same thing. LLMs require developer-like specification, task/subtask breakdown and detail where such example code already exists. As a professional prior to LLMs, how many problems that you work on have many existing free solutions…
So true.
I can only think of hobby projects, like writing yet another emulator, expression parser or media processor in a new language I'm trying to master.
In a professional setting, you would always diligently explore libraries and only implement your own if there is no suitable alternative.
Re: I don't think AI will make your processes go faster
#67There is another problem. For developers, productivity means "functionality produced per hour of work", but that's not what productivity means for businesses. To them, productivity means "money produced per hour of work", and because AI costs money, it is this number that needs to go up (not quite, as it's more "value" than money, but until the economy adjusts they are similar). Even if we could considerably reduce the time between releases and/or do it with fewer people at scale across the industry, for it to pay off, we'll need to see a corresponding rise in demand for software and/or features.
Another option is that lower software costs would significantly reduce the cost of whatever non-software product the software supports (manufactured good, electricity, services, telecom etc.) but I don't know in which industry the cost of software is a large portion of the overall product cost.
And there's another thing. A company that makes tractors can't produce food without land. A company that makes metal machining equipment can't make cars without the raw materials. But a software company that makes software that automatically makes software could just produce the result software itself rather than sell the software-making software. If AI ever reaches the point it makes software at a marginal cost that's not much higher than the cost of the AI itself, what would be the incentive of selling that AI?
Re: I don't think AI will make your processes go faster
#68I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…
product people love LLM because it doesn't ask
"what does X means? how will it work?"
while a programmer will ask, about all cases.
Re: I don't think AI will make your processes go faster
#69Earlier quoted context omitted.
It's interesting how predictable some of this is. The LLMs turn out fully formed clones of stuff for which there exists copious amounts of code openly searchable on the web doing the exact same thing. LLMs require developer-like specification, task/subtask breakdown and detail where such example code already exists. As a professional prior to LLMs, how many problems that you work on have many existing free solutions…
> how many problems that you work on have many existing free solutions but you neglected to use that code and decided to spend days doing it yourself? Only when the existing free solutions are licensed with something like GPL. Now I can just say, write me a C webserver library similar to mongoose and I get the functionality without the license burden.
Indeed, no license burden but you get a maintenance burden instead.
Re: I don't think AI will make your processes go faster
#70I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…
What's even worse is that when dealing with human software teams, a vague requirement will (at least in a well-run org) receive demands for further specification. "What do you mean by 'get data'?", etc. An LLM will just say, "Sure! Here's the fully implemented code that gets the data and give it to the user. " and be done with it.
When the cycles are short enough, though, that is to some degree the right thing. That is, it's the right thing for things the users can then immediately see and give feedback on, because it lets them give feedback on something tangible.
It's the wrong thing for important things under the hood (like durability and security requirements) that are not tangible to them.