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 all functionality via MCP (or whatever protocol replaces it in a few years). My bet is that users will bring their own agents -- agents that already have visibility into all their services and apps.

I hope Calcapp has a bright future. At the same time, we're hedging by turning its formula engine into a developer-focused library and SaaS. I'm now working full-time on this new product and will do a Show HN once we're further along. It's been refreshing to work on something different after many years on an end-user-focused product.

I do think there will still be a place for no-code and low-code tools. As others have noted, guardrails aren't necessarily a bad thing -- they can constrain LLMs in useful ways. I also suspect many "citizen developers" won't be comfortable with LLMs generating code they don't understand. With no-code and low-code, you can usually see and reason about everything the system is doing, and tweak it yourself. At least for now, that's a real advantage.

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 has been 1) the amount of work it takes to build good direct manipulation tools - the level of detail you need to get to is overwhelming for most teams attempting it - but LLMs themselves make this a lot easier to build, and 2) what to do when users hit the inevitable gaps in your visual system. Now LLMs fill these gaps pretty spectacularly.

> 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'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 unreliable for that. However, just like humans, if you dumb down the space and give them a smaller, simpler, set of primitives - they can do a lot better.

This conclusion is completely off the mark. Author seems to lack a critical piece of understanding of software development and operations. The case against no-code might make sense (UI being a hurdle for AI use), but does not apply to low-code.

Low-code has become especially important now with LLMs for several reasons, especially in terms of stability, maintainability, security and scalability.

If the same feature can be implemented with less code, the stability of the software improves significantly. LLMs work much better with solid abstractions; they are not great at coding the whole thing from scratch.

More code per feature costs more in terms of token count, is more error-prone, takes more time to generate, is less scalable, more brittle, harder to maintain, harder to audit... These are major negatives to avoid when working with LLMs... So I don't understand how author reached the conclusion that they reached.

Interesting article -- my take on low-code has always been less about how much initial development time the application takes to code, and more about how it can ease the long term maintenance of an application. With AI tooling it is going to be easy for companies to spin up hundreds of internal applications, but how are they accounting for the maintenance and support of those applications?

Think about the low-code platform as a place to host applications where many (not all) of the operational burdens long term maintenance are shifted to the platform so that developers don't have to spend as much time doing things like library upgrades, switching to X new framework because old framework is deprecated, etc..

Dumb question: whats the difference between "low-code" and "libraries+frameworks"?

Usually the point of a library or framework is to reduce the amount of code you need to write. Giving you more functionality at the cost of some flexibility.

Even in the world of LLMs, this has value. When it adopts a framework or library, the agent can produce the same functionality with fewer output tokens.

But maybe the author means, "We can no longer lock in customers on proprietary platforms". In which case, too bad!

Never really saw the appeal of low-code. We use ABP framework on the backend, and it take care of 80% of the boring work out of the box with battle tested codebase like multi-tenancy, user management, permissions, OIDC auth, auditing, background jobs, etc. With that handled, you mostly focus on core business logic. Combined with AI for speeding up, shipping a production ready system in months is very realistic.

I was going through my low-code bookmarks and I found this jewel from November 2021 (1 year BC-GPT = Before ChatGPT):

Low-Code and the Democratization of Programming: Rethinking Where Programming Is Headed

https://www.oreilly.com/radar/low-code-and-the-democratizati...

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 market is they own a frictionless deployment channel. Your average non-developer isn't going to learn npm and bash, and then sign up for an account on AWS, when the alternative is pushing a button to deploy the creation the AI has built from your prompt.

I think solutions like Plasmic, Refine, and React-Admin probably have a strong place in this AI future. They combine being able to work LLM-first while still offering agility by providing a solid foundation to build on. Otherwise you're stuck to the whims of untested AI slop for everything from security to component design. There's a reason people writing AI code still use libraries and it's the same reason we used libraries pre-AI. They're tested, they're stable, they have clear documentation. Just because the cost of code is zero doesn't mean the cost of software systems is zero.

My favorite part of "low code" was the conciseness of conveying what the process was and the expected outcome.

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 unmaintainable javascript crap.

We have achieved nothing in the last 25 years if we can't do that. Everyone who entered the industry since about 2005 appears to be completely braindead on how damn easy it was to get stuff actually done back then.

LLMs can assist you to write a shitload of useless bloatware, or can assist you to take something existing and complicated, and create something minimal that is almost as good. It's up to you.

Great to see your name here, Zack. I think the problem with low-code is that its a catch all that spans between primarily data-storage-and-use work (Airtable, quick base, Filemaker, etc), the primarily app-alternative platforms (retool, Mendix, etc, and the ETL tools.

To me, AI changes the inflection points of build vs buy a bit for app platforms, but not as much for the other two. Ultimately, AI becomes a huge consumer of the data coming from impromptu databases, and becomes useful when it connects to other platforms (I think this is why there is so much excitement around n8n, but also why Salesforce bought informatica).

Maybe low-code as a category dies, but just because it is easier for LLMs to produce working code, doesn't make me any more willing to set up a runtime, environment, or other details of actually getting that code to run. I think there's still a big opportunity to make running the code nice and easy, and that opportunity gets bigger if the barriers to writing code come down.

Low code is not disappearing - it is simply changing.

What do you think an LLM is if not no/low-code?

And all the other components such as MCPs, skills, etc this is all low-code.

And who is going to plug all of these into a coherent system like Claude Code, Copilot, etc which is basically a low code interface. Sure it does not come with workflow-style designer but it does the same.

As far as the vibe-coded projects go, as someone who has personally made this mistake twice in my career and promised to never make it again, soon or later the OP will realise that software is a liability with and without LLMs. It is a security, privacy, maintenance and in general business burden and a risk that needs to be highlighted on every audit, and at every step.

When you start running the bills, all of these internal vibe-coded tools will run 10-20x the cost the original subscriptions that will be paid indirectly.

"While it’s possible low-code platforms will survive by providing non-technical users with the kind of magical experience that’s already possible for developers with AI coding tools today" - that magical experience is available to non-technical users today already. The last barrier is deployment / security / networking / maintenance, but I'm assuming here are a lot of startups working on that.

In a way, low-code has been the worst of both worlds: complex, locked-in, not scalable, expensive, with small ecosystems of support for self-learning.

(Context: worked at appsheet which got acquired by Google in 2020)

> "For us, abandoning low-code to reclaim ownership of our internal tooling was a simple build vs buy decision with meaningful cost savings and velocity gains. It also feels like a massive upgrade in developer experience and end-user quality of life. It’s been about 6 months since we made this switch, and so far we haven’t looked back."

Fascinating but not surprising given some of the AI-for-software development changes of late.

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.

I always felt that the biggest problem with low code was the wall you hit when you tried to change something small. You had to fight the tool just to make the button look the way you wanted. AI gives you the speed of low code but allows you to build anything you can imagine. It makes sense to stop paying for tools that limit your freedom.

>the cost of shipping code now approaches zero.

Is this a commonly held assumption?

I thought the point would be that the number of lines of code a LLM produces to solve a given problem is... not low.

Low code wont die. But selling low code might.

But if I can get my AI to use an off the shelf open source flow orchestrator rather than manual coding api calls that is better.

I can only speak for my work. We tried for a few months to use Retool and N8n but the calculus just wasn't there when I could spin up internal dashboard tools in less time with better functionality and less work. It was truly a win/win/win all around.

Things I built for internal use pretty quickly:

    - Patient matcher
    - Great UX crud for some tables
    - Fax tool
    - Referral tool
    - Interactive suite of tools to use with Ashby API

Much easier to just have a Claude Code build it all out for real.

Low Code is just diagram->code in many respects. Many platforms have basically similar constructs.

I work on a 'low code' platform, not really, but we do a lot of EDI. This requires a bunch of very normal patterns and so we basically have a mini-DSL for mapping X12 and EDIFACT into other objects.

You guessed it, we have a diagram flow control tool.

It works, yes I can write it in Javascript too... but most of the 'flow control bits' are really inside of a small sandbox. Of course, we allow you to kick out to a sandbox and program if needed.

But for the most part, yeah I mean a good mini-DSL gets you 90% of the way there for us and we dont reach for programming to often.

So - its still useful to abstract some stuff.

Could AI write it by hand every time? yes... but you still would want all the bells and sidepieces.

SAP the lowest on both axis... had to crack up at that

how much of it is because the VC funding dried up and went to LLMs instead

Broken link, should point to https://www.zackliscio.com/posts/rip-low-code-2014-2025/

>> in a world where the cost of shipping code now approaches zero.

Reallly ?