Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RIP Low-Code 2014-2025

zackliscio.com

Post reply on HN
Print view View original

111–120 of 160 posts

Re: RIP Low-Code 2014-2025

#111

Post by dgxyz »

bronco21016 wrote: post #57
dgxyz wrote: post #55

Fuck all this pointless noise, verbose analysis, LLMs and other associated crap. Just someone give me MS Access for the web with an SSO module and let me drive it. That'd cover 99% of LOB app needs and allow me to actually get shit done without tools that dissolve in my hands or require hordes of engineers to keep running or have to negotiate with a bullshit generator to puke out tens of thousands of lines of unmaint…

Have you tried Airtable or the likes?

I've seen it yes. It's not even close to what LOB apps need in reality.

Re: RIP Low-Code 2014-2025

#112

Post by cheschire »

dgxyz wrote: post #109
cheschire wrote: post #107

Earlier quoted context omitted.

What you just described is a sample size of one. I spent ten years supporting a 30k+ person company and never saw Access used in reasonable ways. It was always on a network share, data always stored in the local file instead of SQL, “engineering” done entirely by a power user that got a book on MS Access at the bookstore instead of by anyone with actual engineering experience. There’s a reason people in IT hate Acces…

Sample size is irrelevant. The problem is bad people, not bad software. It ran a 50 seat ERP system that managed over 1000 suppliers and 500 customers, did all invoicing, inventory/stock management, logistics and financials. In the hands of clue that is. They did replace it with SAP eventually but this was at a 15x per seat cost multiplication. There is still is a lot of stuff hiding out there that works like that wh…

Sample size is irrelevant to you, the sample size.

Re: RIP Low-Code 2014-2025

#113

Post by Foobar8568 »

rahilb wrote: post #24

> the cost of shipping code now approaches zero Does anyone actually believe this is the case? I use LLMs to ‘write’ code every day, but it’s not the case for me; my job is just as difficult and other duties expand to fill the space left by Claude. Am I just bad at using the tools? Or stupid? Probably both but c’est la vie.

I feel I spend easily 3-5 times more on "QA" with LLM vibe coding than doing myself, the only difference, I couldn't code what I am currently making without LLM, the breath of knowledge required is just too vast.

Re: RIP Low-Code 2014-2025

#114

Post by cpursley »

sergiotapia wrote: post #30
davidpolberger wrote: post #27

I'm a co-founder of Calcapp, an app builder for formula-driven apps, and I recently received an email from a customer ending their subscription. They said they appreciated being able to kick the tires with Calcapp, but had now fully moved to an AI-based platform. So we're seeing this reality play out in real time. The next generation of Calcapp probably won't ship with a built-in LLM agent. Instead, it will expose al…

I highly suggest you expose functionality through Graphql. It lets users send out an agent with a goal like: "Figure out how to do X" and because graphql has introspection, it can find stuff pretty reliably! It's really lovely as an end user. Best of luck!

Hasura is working on this approach: https://promptql.io

Re: RIP Low-Code 2014-2025

#115

Post by pjc50 »

mikewarot wrote: post #108

Please note that we had two independent working low code systems, back in the 1990s. Back then, a domain expert could fire up either Delphi or Visual Basic 6, and build a program that was useful for them. If they needed more performance, they would hire a professional programmer who used their work as a specification, and sanded off the rough edges. These days, Lazarus is the open source follow on to Delphi. It'll wo…

It has been a very long time since I have written any Delphi, but I prefer dotnet these days. The only (very real) problem is trying to predict what the best long term UI option is for native apps.

Re: RIP Low-Code 2014-2025

#116

Post by cpursley »

agent013 wrote: post #105

Low-code tools have guardrails that keep things predictable - you know what a Retool app can and can't do. AI-generated internal tools are just... code. Code that will need updating when APIs change, when requirements shift, when the person who prompted it leaves. "We migrated everything in a couple of sprints" is doing a lot of heavy lifting. Check back in 18 months when half those tools have drifted into unmaintain…

Well thats the problem right there, business logic belongs in the database, not JavaScript rats nests. I’d argue that Claude and even Coeldex are so good with SQL that it would be insane to use any other approach. And the database survives the hot framework of the week churn.

Re: RIP Low-Code 2014-2025

#118

Post by lloydatkinson »

siliconc0w wrote: post #68

I'm not so sure. IMO agents are actually a huge unlock for low code tools because before you had to teach a disinterested human how to use your new DSL/tool. But Agents are a lot more patient and enthusiastic. So you can have the agent generate the low-code instead of the human. You could try to generate the business tools straight from the conventional toolsets but the problem is that agents are still far to unrelia…

I totally agree with this and with the comment above yours in regards to predictability. I don't understand this manufactured FUD the linked article or the low code spreadsheet product in another comment are creating here. It is literally the perfect match.

Re: RIP Low-Code 2014-2025

#119

Post by csomar »

dgxyz wrote: post #110
csomar wrote: post #106

Earlier quoted context omitted.

I think it's just nostalgia for a simpler, less complicated past. We do lots of things today that would've been impossible with Access and that we now take for granted. For example, most people today expect to access their system from anywhere via the internet; pulling up a specific invoice on their phone, for instance. That just wasn't possible with Access 2000. And if you tried building a web-accessible system on t…

Most businesses don't really operate like that though. That's what has been sold to us as an idea and we are blinded by the environments we work within in the tech industry. Really a hell of a lot of it is bums on seats in offices still. One of the hilarious things I've seen recently was an ex partner of mine's hair salon paid for a SaaS booking system. It's a pile of junk. Doesn't work properly, screws up scheduling…

Sure, which is why roughly 2/3 of the world's desktops are still running Windows. I actually met an accountant the other day (from Germany) who still uses the desktop version of Microsoft Excel (not the 365 web edition) because the old version works fine for his needs while the web one doesn't.

> They literally went back to a paper bookings diary and just phone or whatsapp people if there's a problem.

I couldn't book a place the other day because their online booking system was broken. It made me realize why most places and hotels use Booking.com or Airbnb. It's not just about discoverability; getting a booking system to actually work is a really hard problem.

But look at these two examples: MS Access wouldn't help in either case. For a booking system to be useful, people need to access the calendar online. These are things only made possible with web or mobile apps. Booking.com and Airbnb have a combined market cap of around a quarter trillion dollars. That's how valuable a functioning booking system really is.

Re: RIP Low-Code 2014-2025

#120

Post by phartenfeller »

Heavily disagree (for serious low-code platforms). AI produces code that only AI maintains. That's a big burden. Low-code vendors ship code patterns that are easy to compose. They have the burden of maintaining that code.

Let AI build apps using these building blocks instead of wasting tokens reinventing the wheel on how interactive tables should be, which chart library to use, and how speaking from the frontend to the backend works securely.

LLMs will make creating low-code apps as easy as normal apps. But it has one constraint: how is the extensibility of the low-code framework?

Post reply on HN