zlacker

Most likely you are creating boilerplate at 20x/50x, as opposed to genuinely new concepts, mechanisms, etc.

To be fair, most web/mobile frameworks expect you to do that.

Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.

>>vemv+(OP)
Precisely what I was going to say. As domain specificity increases, LLM output quality rapidly decreases.

>>vemv+(OP)
There's three types of work in software:

- Commodity work, such as CRUD, integrations, infra plumbing, standard patterns.

- Local novelty, i.e. a new feature for your product (but not new to the world).

- Frontier novelty, as in, genuinely new algorithms/research-like work.

The overwhelming majority of software development is in the first two categories. Even people who think they are doing new and groundbreaking stuff are almost certainly doing variations of things that have been done in other contexts.

>>vemv+(OP)
Yes, there is A LOT of boilerplate that is sped up by AI. Every time I interface with a new service or API, I don't have to carefully read the documentation and write it by hand (or copypaste examples), I can literally have the AI do the first draft, grok it, test it, and iterate. Often times the AI misses latest developments, and I have to research things myself and fix code, explain the new capabilities, then the AI can be used again, but in the end it's still about 20x faster.

>>vemv+(OP)
> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.

The problem with this configuration based approach is that now the actual code that executes has to be able to change its functionality arbitrarily in response to new configuration, and the code (and configuration format) needs to be extremely abstracted and incomprehensible. In the real world, someone figures out that things get way easier if you just put a few programming language concepts into the configuration format, and now you're back where you started but with a much worse programming language (shoehorned into a configuration format) than you were using before.

Boilerplate may be cumbersome, but it effectively gives you a very large number of places to "hook into" the framework to make it do what you need. AI makes boilerplate much less painful to write.

>>vemv+(OP)
>> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.

Be very careful with this approach. there are many ways it can go completely wrong. i've seen a codebase like this and it was a disaster to debug. because you can't set breakpoints in data. it was a disaster.

It may not look compact or elegant but I'd rather see debuggable and comprehensible boiler point even if it's repetitive rather than a mess

>>vemv+(OP)
Most of the post reads like "boilerplate created at 20x/50x" to me, too, frankly.

>>woah+s11
Working on a system like this (mostly configured with complex yaml, but extended with a little DSL/rule engine to handle more complex situations) a long while ago, I introduced a bug that cost the company quite a bit of money by using `True` instead of `true`—something that would have been readily caught in a proper language with real tooling.

>>macNch+Q51
That would be caught by any schema validation system at runtime, e.g. Zod in typescript, Malli in Clojure, and so on.

>>woah+s11
There are always middle grounds to be explored. The way I see it, 80% of a "codebase" would be data and 20%, code.

Both worlds can be cleanly composed. For instance, for backend development, it's common to define an array (data) of middleware (code).

At a smaller scale, this is already a reality in the Clojure ecosystem - most sql is data (honeysql library), and most html is data (Hiccup library).