Live data from Hacker News

RIP Low-Code 2014-2025

zackliscio.com

151–160 of 160 posts

Re: RIP Low-Code 2014-2025

#151

I think this view is really short-sighted. Low-code tools date back to the '80s, and the more likely outcome here is that low-code and agentic tools simply merge. There's a lot of value in having direct manipulation and visual introspection of UIs, data, and logic. Those things allow less technical people to understand what the agents are creating, and ask for help with more specific areas. The difficulty in the past…

Agreed, the low code dream has been around a long time. Douglas Copeland, the novelist who named Generation X, wrote a book called Microserfs in 1995 about a startup building a low code platform.

Re: RIP Low-Code 2014-2025

#152

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 saw a Second Brain demo [0] using no-code with using AI inside the widgets to do the work. It took a little handholding, but it turned out to be very flexible, showing me a new way to look at the whole industry.

[0] https://youtu.be/gLaMDOrDGHA?si=CIWVD-TLJrPju1RO

Re: RIP Low-Code 2014-2025

#153

Earlier quoted context omitted.

I use Cursor daily, I have worked on Agents using LangChain. Maybe we are doing something wrong but even ysing SOTA models unless we explicitly give which mcp tool to call, it uses anything - sometimes - while other times it can do a passavle job. So now our mandate is to spell everything out to LLM so it doesn't add a non existent column like created at or updated at to our queries I've used every SOTA for day to da…

Precisely, I always find myself thinking that maybe I'm just too dumb to use these LLM's properly, but that would defeat the purpose of them being useful haha.

And I keep reading people who heap praises at AI like the Staff engg at Google who weirdly praised a competitor LLM. They miss one important part - AI is good for end to end problems that are already solved. Asking it to write a load balancer will result in a perfect solution because it has access to very well written load balancers already.

The real MOAT is to write something custom and this is where it struggles sometimes.

Re: RIP Low-Code 2014-2025

#154

Earlier quoted context omitted.

REST is self documenting. Edit: for down voters, I'd be curious why.

I didn't downvote, but I'm thinking that you need endpoint discovery, bucket types, etc. Sure you could write a 1 page document describing the buckets at the root level, the relationships of the objects, etc., but why not let swagger do that for you at compile time?

I'm talking about actual REST here though, not RPC. Endpoint discover and typed schemas are core pieces of REST, we don't need Swagger or similar to fill in those gaps.

Re: RIP Low-Code 2014-2025

#155
I am the founder of one of the very first no-code/low-code platforms (DaDaBIK, first released in 2001). Three years ago I released appifytext.ai, an AI agent that develops DaDaBIK apps starting from textual specifications.

Low-code and LLMs can coexist: low-code can be just another layer (or, if you prefer, a more abstract programming language) that LLMs can use. You have less freedom, but more predictability and robustness, which is perfectly fine for internal tools.

Re: RIP Low-Code 2014-2025

#156

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…

Skills are the way, MCP is decent if you just have a few "endpoints", otherwise it's just polluting the context.

Re: RIP Low-Code 2014-2025

#157

Earlier quoted context omitted.

Why would anyone need docs.

REST is self documenting. Edit: for down voters, I'd be curious why.

Self documenting, but mainly to the architect who put ‘RESTful’ in the slide deck and called the documentation done.

Re: RIP Low-Code 2014-2025

#158
post #103

Earlier quoted context omitted.

That's not even remotely close to the idea. It's conceptually entirely different. I'll note that Access existed in a completely usable form before the www even existed.

How is it conceptually different? RDBMS ORM-based web frameworks (with built-in Admin GUIs) ate the web-oriented crowd, and the rest are happy managing their data in Excel. That doesn't leave much room for MS Access.

Try building a complex report or even a printable invoice output in Rails or Django.

Re: RIP Low-Code 2014-2025

#159

Low-code tools for actual developers is dying but AI might be the thing that makes low-code take off for the broader market. Software development will look very different five years from now. It could be filled with knowledge workers with no CS education using no-code tools and AI while the hardcore engineers still build technology that they build on. A strong advantage a platform like retool has in the non-developer…

I'm not a developer but I figured out Claude Code agents and skills and use surge.sh to share things out as needed. In my company I feel like the last to this party,

You're on HN so I assume you're in a technical or technical-adjacent role. Of course, you could be an accountant at a restaurant supply company or something.

Here's another data point for you. A few weeks ago, I had to do a screenshare with a product manager just to help them install Claude Code. There is a wide spectrum of technical literacy out there.

Re: RIP Low-Code 2014-2025

#160
post #158

Earlier quoted context omitted.

How is it conceptually different? RDBMS ORM-based web frameworks (with built-in Admin GUIs) ate the web-oriented crowd, and the rest are happy managing their data in Excel. That doesn't leave much room for MS Access.

Try building a complex report or even a printable invoice output in Rails or Django.

I assure you generating PDFs is not something that Microsoft has a moat around.
Post reply on HN