alt Hacker NewsI don't think AI will make your processes go faster
Comments
This 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"
It definitely made the process of testing features with the users 10x faster. You can iterate, test and throw away bad ideas much much faster.
The proper implementation and design still take time, but still faster in systems with a lot of available resources online.
LLMs are great at two things: search and speed of generating code.
I get most value from them when I'm asking it to either fill in the blanks of something already half implemented or when I need some feature in a given context/language that only exists in other languages
Someone I know said "software is made of decisions". <https://siderea.dreamwidth.org/1219758.html> Seems very applicable here.
I really love AI to be honest. I feel like I'm using it to achieve much more than I could ever dream of. It changed my life!
Our current most popular methods of using AI with software development is either waterfall or autocomplete. We aren't at a great pair programming experience yet. I presume that would improve speed and accuracy, but it's still unclear.
Great explaination it is true that AI doesn't generates the correct programs everytime but sadly it has become a common practice to involve AI in every aspect of Software Engineering, and it is true that it made Software Engineers to become product manager and their work has become to debug and test the entire codebase which adds more frustation.
Everything is OK, but the size of Gantt chart should be expanded.
You know, AI could help you to produce better-looking charts.
I'm sure this take will age well.
Ai in my mind is a new primitive of computing, like compute a db blob storage.
It goes faster, at least for a while, if you don't look at the code.
Another post that doesn’t understand effective use of GenAI in software engineering.
The assumption is that there’s no way to extract speed and accuracy matching business models.
This isn’t obviously false to the majority of dev/arch’s because most are vibe-coding, but it is extremely obvious to the minority that has focused on accuracy first THEN speed.
It always comes back to Amdahl’s law.
So we have spent 40 years trying to get management and investors to understand that 9 people can't make a baby in one month.
There's no point in falling under the illusion that they'll finally get it now. This will all fall on deaf ears. They're convinced they're automating us out of existence when in fact they'll need the services of people who can surf complex systems more than ever.
We will be able to do more than ever and potentially faster. The issue remains that most of the things these people ask us to do and want us to do and pay us to do remains basically stupid and as TFA points out, the last mile of getting shit properly shipped isn't going to speed up. It's going to slow down.
If you want to see what happens when you put people in charge who sincerely believe in the "AI automates SWEs out of existence" mantra, take a look at the code quality of Claude Code and the recent "bun rewrite in Rust" fiasco.
This blog post is nonsensical and the arbitray time boxes aren't realistic. Not all development cycles or features require legal input and I would hazard most don't, even in Big Tech. Documentation takes seconds to generate. Same as tests.
Feature development could take minutes to hours depending on how you iterate it. These days, all we do now is just think of a feature and add it within an hour using AI. We have a process that is a year old now that is fixing bugs that would have taken us hours or days and it spits out a fix in about 10-15 minutes that is 95% accurate. 5% is garbage, but 24 months ago, 95% of it was garbage so the progress is staggering. The longest pole is code review which is all human, but that will all be automated soon.
Not everything will be much faster, but most processes will be 1-3 orders of magnitude faster. To ignore this or find excuses why LLMs/AI won't speed things up or remove the need for large swathes of humans is delusional and cope-ism.
There are a lot of ways that AI speeds up software development processes that aren't the actual software development.
I am finding that lately I do not allow LLMs to write any code I am interested in maintaining. Or if they do, I have to micromanage them and it usually takes longer. They produce mediocre solutions, and often add redundant state ("Why did you add that state?" "Because we might need it in the future")
That said, they are extremely good at:
- Dev tools: creating debug tooling, debug screens, scripts that get the job done - Auxiliary development: landing pages, "what's new" screens, tedious boilerplate, gathering strings for localization - Prototyping: building full implementations quickly so you can see all the problems rather than having to anticipate them - Pure transformation: porting from one language or paradigm to another
So while I agree with the article that the actual spec of the feature you are building needs just as much human thought, regardless of AI, the speed-ups around that are worth exploring
An example I have from a recent feature development is adding CarPlay support to an existing app. We could have talked about it and designed it for weeks, but with an LLM I was able to get it running in my car in an hour, go for a drive, and feel it to understand whether it was a valuable direction.
The code was a mess, most of it had to be thrown away, and the LLM couldn't even get the initial build functional (not much CarPlay training data, I expect). But it was an accelerator to answer the question "is it worth investing more time in this?"
While I agree with the article, I think AI can speed up all steps in the Gantt chart. It's really good about aggregating and summarizing information.
>Process blocked on human inputs
Have AI check chat, email, issue tracker and see who it's blocked on and what latest status is. It may not save a huge amount of time but it can dig through the info pretty quick.
>Exploration
Once again, have it scour issue tracker, chat, customer suggestions, product documentation and summarize history and current status. Much quicker than setting up new meetings to try to rediscover and organize existing info.
Another use case, have agent build prototype, hand to people, have AI summarize and integrate feedback.
Claude or ChatGPT + Slack MCP + Jira MCP + Google Docs MCP + internal knowledgebase MCP + gh (GitHub) CLI + Datadog MCP--really 1 MCP per process in the Gantt chart--has been a huge boost at work just digging through context scattered all over the place and summarizing.
That said, it definitely still needs supervision and hand holding along the way
Here is my take on the same topic: The AI Productivity Paradox: Why the AI Multiplier is Less Than 2x. https://www.forrestthewoods.com/blog/the-ai-productivity-par...
My hypothesis is that AI greatly accelerates only a small portion of development. It's pretty effing great at prototypes. But the net acceleration factor is just not that large currently.
Opus has been out for ~6 months. If AI were a net 100x multiplier then we'd be seeing what previously took 5 years ship in just 2.6 weeks. This is objectively not happening.
I could see two ways out
- People need to be trained to use AI in ways that we don’t call slop, meaning half is made up by the LLM
- To this effect, LLMs should be trained to ask for more input before offering any kind of final output
It absolutely will make some things faster. Anyone that has ever churned out some boilerplate code with it knows that.
...but yeah most organizational processes & people aren't set up for leveraging it and roll out will be slow (same on learning where it does / doesn't work).
This is wrong already because it makes the assumption is used only for development.
No. AI is used all the way from the very start to the very end and after.
Maybe my existing processes not but it can help you enormously. I literally found a problem with AI analyzing packages in Wireshark and it hinted and steered me in the direction in me finding the error setting in the end. Could a senior network guy found it? Yes but probably not even faster. Did I as a L2 SWE not being familiar with much of networking and the companies stack(was like 1 Month at this company) found it with no AI, absolutely no.
Whilst the conclusion of the article certainly seems plausible, it glosses over the cost calculations and simplifies them too much.
The cost of a subscription is somewhat offset by being guaranteed income regardless of usage, following the financial models of gyms. Whilst api costs represent both the convenience of on-demand pricing and the scale for applications with many users.
Further, the costs of api and subscriptions need to cover the operating costs of the business, the massive SOTA training costs as well as the costs of inference.
The true cost of serving tokens is buried in all of that in these enormous, opaque companies.
The METR report continues to hold up. I would add "No Silver Bullet" to the reading list.
Careful who you share this information with- better to roll with the kool-aid drinkers when they're holding the cards.
Research tells us that only 15% of software engineering is the “writing code” part. It looks like we are rediscovering that.
To be honest, I think my process go 10x faster with AI. It's literally visible lmao.
It makes small teams without organizational overhead go lightning fast.
It might be the ultimate tool of disruption.
What a naïve article. People don’t write software this way anymore. A Gannt chart? We don’t use those anymore.
People have to stop promoting this narrative of the AI doesn’t make you move faster as it’s not helping anybody.
I get it. We all worked hard for our skills and it’s really difficult watching them get automated away, but it’s been this way since the printing press assembly lines and the industrial revolution itself. Things change, and you have to adapt to them and stop thinking about it from a centric point of view. The narrative people should be pushing is that you can build great things with AI.
Of course you might not have a job for a while and yes, that’s a big deal but it doesn’t mean that AI is wrong or stupid. It means you have to adapt.
cars are not faster than horses
The bottom line is that AI is genuinely useful at prototyping new features, acting as a sounding board, and generating quick initial drafts, even if the quality isn't uniformly excellent. It seems plausible to conclude that it will only take a little additional effort to refine and improve that initial draft to achieve excellence and truly high-quality, production-grade code. In reality, whole processes to build properly with AI-generated outputs and that mitigate thoroughly against the fundamental limitations and constraints of AI agents (many of which are not well understood even by daily users) really need to be invented and implemented.
I think many things that were true prior to AI are still true or more so today, but new workflows and processes altogether are needed. I suspect that comprehensive, detailed planning and specification documentation must be assembled in advance of beginning code (akin to waterfall) when working with AI agents. Furthermore, I still believe customers and other key stakeholders need to be involved early and often so that the product can iterate towards a better ultimate end state (i.e., agile). Unlike prior to AI, it's completely plausible to implement both types of approaches, and they aren't mutually exclusive. We can do comprehensive, exhaustive, thorough planning and specification documentation prior to handing off to dedicated engineering and products teams, AND we can work quickly and iteratively via sprints that aim for frequent meetings and updates with the stakeholders that matter.
I also think the same validation gates that mattered before -- linting, SASTs, but most importantly, comprehensive automated testing that gets run locally and in CI/CD and is regularly expanded to cover all expectations about the behavior and structure of newly-implemented functionality -- continue to matter now, more than ever.
New tools and processes also must be built to make human review, the single biggest bottleneck in software development today, more simplified and streamlined, and less taxing. I think tools like CodeRabbit and Qodo can help automate and expedite the code-review and approval processes, but they would be even better if they were working off more surgical and tiny edits. Bloated, verbose AI-generated code edits are the core problem here. Process management techniques to mitigate the problem of AI code overload can prohibit the submission of AI-generated PRs, require senior engineer approval of any PRs prior to merging, or block the maximum number of lines or changes made. More sophisticated processes like Graphite's stacking of PRs are genuinely helpful in breaking down massive PRs into smaller chunks.
Finally, precision-editing tools for AI coding assistants like HIC Mouse (full disclosure, my project) that move beyond the existing options available to AI agents of whole-file replacement or exact string-replacement to enable agents at the editing-tool layer to perform surgical, tiny changes that don't touch any unrelated content, giving agents specialized visibility, recovery, and next-step guidance mechanisms that safeguard AI workflows, can materially reduce AI code slop by alleviating burdens upstream of code reviewers, both automated and human.
The bottom line: Shipping secure, production-grade code was never easy and always took a long time. It's not necessarily easier now just because certain aspects to the overall process can be generated much more rapidly. Arguably, the hardest parts like human review and approval are much harder now -- not easier. Solutions will take hard work and must be tested in the crucible of real-world enterprise usage. I am guessing that companies that deploy successful processes will be wildly profitable. Those that don't, including well-established incumbents, will fail. I do think AI absolutely can give organizations a game-changing boost in development velocity of genuinely high-quality code that might even be better than anything ever created previously. I also fully agree with the author that for many organizations, AI will not make their processes go faster and may even slow things down.
"In 1975, Dr. Joseph Sharp proved that correct modulation of microwave energy can result in wireless and receiverless transmission of audible speech."
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
I just spent a few days cleaning up someone's web app they created with Claude Code. There was more than 30k lines of DEAD code, and I was able to cut the code that was actually being used down by ~30-40%. If I just wrote this app myself It would have taken a day or two.
LLMs are not helpful, they make everything worse. They make you worse, or reduce you to average at best. I really just don't see what ya'll are seeing. I have access to every model with no limits, Its not issue of "holding it correctly" I can assure you, I've tried.
Yes it can create very small programs with low complexity, but anything of any size ends up as a literal Eldritch horror or with so many subtle bugs that make life miserable. I actually hate all of you that are pushing it onto people, its such a lie.
Before, when there was the notion that "building is expensive", product teams would think things through, do user interviews up-front, actually do discovery around the customer + business context + underlying human process being facilitated with software.
This has shortened the cycle to first working prototype, but I'd guess that in the longer scale, it extends the time to final product because more time is wasted shifting the deliverable and experience on the user during this process of discovery versus nailing most of the product experience in big, stable chunks through design.
At the end of the day, there is a hidden cost to fast iterative shifts on the fundamental design of the software intended for humans to use and for which humans are responsible for operation. First is the cost on the end users who have to stop, provide feedback, and then retrain on each cycle. Second is that such compounding complexities in the underlying implementation as product learns requirements and vibe-codes the solution creates a system that becomes very challenging for humans to operationalize and maintain.
Ultimately, I think the bookends of the software development process are being neglected (as author points out) to the detriment of both the end users and the teams that end up supporting the software. I do wonder if we're entering an "Ikea era" of software where we should just treat everything as disposable artifacts instead.