Live data from Hacker News

RIP Low-Code 2014-2025

zackliscio.com

81–90 of 160 posts

Re: RIP Low-Code 2014-2025

#81

Earlier quoted context omitted.

This ABP framework sounds like a low-code tool to me. The ability to focus only on business logic is basically the entire premise of low-code. Your argument actually supports the opposite conclusion as the author of the article. You're suggesting that LLMs work better if they can only focus on the business logic without having to get tangled into the weeds of technical details.

Its is not low code, its open-source, modular application development framework built on .net. You can use it as Headless backend with your own UI. We use it like that with our own Next JS front end. You can drop down to raw EF, SQL, custom auth flows (We had written a custom invite based user signup and custom Openiddict app for plan based claims for JWT based feature management) or rip out entire modules if needed.…

If the tool aims to reduce the amount of code required to build features, then it's low-code. IMO, any modular library or reusable mechanism which abstracts away implementation details follows the low-code philosophy. Low-code is just what it says. It's not associated with any specific tech stack or mechanism.

Re: RIP Low-Code 2014-2025

#82

I don't see LLMs as competing with low code at all. Low code solutions make it easier for LLMs to setup something working and robust.

Yeah, I'm someone who uses Codex, but I still use n8n and node-red for some automation stuff in my house.

n8n allows you to work at a higher level, and working at this level allows you to do things in a way that's more likely to be "correct". While it's not necessarily "difficult" to do integrations with Home Assistant or Discord or any of the million integrations that n8n has, it can still be error-prone, even for experienced developers.

With n8n, I'm pretty sure I could even have my parents set up and more importantly debug pipelines to control their thermostat or something. Even if I could get them to prompt Codex or Claude or something, I think it would be hard for them to debug the output if they had to.

Re: RIP Low-Code 2014-2025

#84

Earlier quoted context omitted.

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!

A proper REST API would also work without all the extra overhead of GraphQL. People may dislike XML, but it is easy to make a REST API with and it works well as an interface between computer systems where a human doesn't have to see the syntax.

Depends mostly on efficiency: GraphQL (or Odata as a REST compliant alternative that has more or less the same functionality) provide the client with more controls out of the box to tune the response it needs. It can control the depth of the associated objects it needs, filter what it doesn't need, etc. This can make a lot of difference for the performance of a client. I actually like Odata more than GraphQL for this purpose, as it is REST compliant, and has standardized more of the protocol.

Re: RIP Low-Code 2014-2025

#85

Earlier quoted context omitted.

Mendix is nothing more than MS Access for the Web.

Ok funny anecdote: I once did a special assignment for the CEO of Mendix to build a convertor for MS Access apps to Mendix. So, yes, I can confirm that this is roughly true ;) I wrote a short post about it on my blog: https://blog.waleson.com/2022/10/access2mendix.html

And long before that i built an ms-access UI on top of an Oracle 6 database, so yes, MS-Access was one of the client-server era low-code tools. Like powerbuilder, Oracle Forms, etc. (Hi jouke!)

Re: RIP Low-Code 2014-2025

#87

Earlier quoted context omitted.

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!

A proper REST API would also work without all the extra overhead of GraphQL. People may dislike XML, but it is easy to make a REST API with and it works well as an interface between computer systems where a human doesn't have to see the syntax.

REST + Swagger I'd say

Re: RIP Low-Code 2014-2025

#88
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 think the answer is that by the time AI can replace every function you do, it's also replaced everyone else and the world will either already have or will need to change radically. I personally hope that the future becomes a UBI consumer-as-a-job thing, minus too much of the destructive impact that current consumerism has on the world.

Try to think logically. If AI eats all jobs, then nobody earns money any more to pay for everyone's UBI. The rich certainly won't do it.

Re: RIP Low-Code 2014-2025

#89
I recently used the AI feature in n8n to write a code node to parse some data, which worked really well. Feels more like LLMs are enhancing low-code solutions.

Also, I see great value in not having to take care of the runtime itself. Sure, I can write a python script that does what I want much quicker and more effectively with claude code, but there is also a bunch of work to get it to run, restart, log, alert, auth…

Re: RIP Low-Code 2014-2025

#90
RIP low-code, long live low-code companies :)

For our startup, the low-code vs LLM shift started hugely frustrating and scary, but also hopeful. After years of dev, we were getting ready to launch our low code app product #2, and then bam, chatgpt 3.5 happened and LLMs stopped sucking so much.

We had to look at our future for our corner of the world -- bringing our tricky gpu graph investigation tech into something that goes beyond the data 1%'ers at top gov/bank/tech/cyber investigation teams to something most teams can do -- and made the painful and expensive call to kill the low-code product.

The good news is, as a verticalized startup, the market still needed something here for the same reason we originally built it. LLMs just meant the writing was on the wall that that the market expectations would grow as would what's possible in general. We correctly guessed that would happen, and started building louie.ai . Ex: While we previously had already viewed our low-code platform as doubling a way for teams to write down their investigation flows so they can eventually do ML-powered multi-turn automations on them.. we never dreamed we'd be speed running investigation capture the flag competitions. Likewise, we're now years ahead of schedule on shedding the shackles of python-first notebooks & dashboards.

So yeah, for folks doing generic low-code productivity apps, it's not great. n8n and friends had to reinvent themselves as AI workflows, and there's still good reason to believe that as agent experiences improve, they'll get steamrolled anyways... but...

Verticalized low-code workflow tools get to do things that are hard for the claude codes. Today the coding envs are built better than most of the non-ai-native vertical teams, but the patterns are congealing and commoditizing. It'll be interesting as the ai side continues to commoditize , and the vertical teams get better at it - at which point the verticals get much more valuable again. (And indeed, we see OpenAI and friends hitting ceilings on generic applications and having to lean in to top verticals, at least for the b2b world.)

Post reply on HN