logoalt Hacker News

rafterydjyesterday at 12:22 PM1 replyview on HN

Interesting! I am curious to ask someone who has been working on no-code tools for so long: I've been reading about no code platforms from the 1990s, and how all of those ended up failing. The reason I've seen cited most is that the tools/platforms did not allow for enough variability to do the jobs that people wanted (without becoming a full programming language themselves). What do you think about that in the context of the past ten years, pre- and post-LLMs?

And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?


Replies

brainlesstoday at 6:47 AM

"company makes and distributes a specialized coding agent for CSS" - weird that you think this is a path because I think this is not as appreciated as it should be.

No-code has been in a poor state for many reasons. I agree that people want more generic software to be built and the platforms did not allow for enough variability. This is what being better enabled with LLMs.

I think coding agents, particularly Claude Code, makes people think that models are the key. Some people disagree. I disagree as well. I think small models with lots of deterministic code is the way. But this will not fill Anthropic's or OpenAI's pockets.

Using an LSP, for example is recent in coding agents. But if you think about it, we should have started with that. Most agents expect LLMs to know too broadly. I would instead create 40 (random number) agents - one for each language and part of the stack. This is why your CSS example is interesting. I create just an agent for the ORM related code in a Rust/Diesel based coding agent. It worked with a 4B parameter model!

People will fight over "worked" but basically what I did was create deterministic code generator for the ORM layer - schema, model and model accessor or mutator functions and then asked the tiny model to fill in the code with lots of code example straight from the official docs. It played well for many different kinds of prompts - all focused only on model related changes.

What if we create many layers of this - a higher level agent breaks human prompts into an intermediate language and then tech-stack focused agents write the code within deterministic tooling. Agents cannot read or write any file they want - they are specific to that part of the stack, linter, compiler, etc. kick in automatically.

You get the idea.