[ragall]

> Now you could say a piece of software completely written by a coding agent is just another abstraction

You're almost there. The current code-generating LLMs will be a dead end because it takes more time to thoroughly review a piece of code than to generate it, especially because LLM code is needlessly verbose.

The solution is to abandon general-purpose languages and start encapsulating the abstraction behind a DSL, which is orders of magnitude more restricted and thus simpler than a general-purpose language, making it much more amenable to be controlled through an LLM. SaaS companies should go from API-first to DSL-first, in many cases more than one DSL: e.g. a blog-hosting company would have one DSL for the page layouts, one for controlling edits and publishing, one for asset manipulation pipelines, one for controlling the CDN, etc... Sort of IaC, you define a desired outcome, and the engine behind takes care of actuating it.

[order-matters]

I agree. Additionally, a company can own and update a business language of their own design at their own pace and need. Then they can use AI to translate from their controlled business language to the DSL needed (translation being an area it actually does well). In this way the LLM would only ever be going from General -> specific, which should keep it on the rails, and the business can keep its business logic stored

Now that said, there is still the actual engineering problem of leveraging the capabilities of the underlying technology. For example, being able to map your 4 core program to a 16 core system and have it work is one thing, actually utilizing 16 cores is another. Extend to all technological advancements

[ragall]

> I agree. Additionally, a company can own and update a business language of their own design at their own pace and need.

Yes, although I was more thinking of this being in most cases a SaaS offering because the implementation of the DSL needs solid non-LLM engineering. Larger companies will be able to afford an internal platform team, but most won't.

> Now that said, there is still the actual engineering problem of leveraging the capabilities of the underlying technology. For example, being able to map your 4 core program to a 16 core system and have it work is one thing, actually utilizing 16 cores is another.

I see this more of an extension of existing trends, for example Wordpress themes with limited customizability. Most DSLs won't allow full utilization of the underlying technology, on purpose because that's the only way to keep it simple. I do see this leading to a split into two classes of developers: those who only target simple DSLs using an LLM, and the "hard" engineers who might use LLMs every now and then, but mostly not.

[order-matters]

I see the angle you're coming from now, more mass market and expanding best practices from bigger companies out to medium and small businesses looking for plug and play solutions.

I was thinking more about what I believe you describe as the "hard" engineers, and would say the power AI provides for mapping and translating will greatly benefit those teams as well with the right set-up. People are pushing for the "code for me" angle, but i think there will be a lot of opportunity to have LLMs take on a middle ground of syntax management while the engineers manage the system effects. for example, the engineer may be deciding whether to use a linked list or binary tree and the LLM is implementing it with the available code stack approved by the company.

A company that can successfully implement such an LLM opens up their talent pool from people who know their stack (or want to learn it) to people who know any stack

[ragall]

> for example, the engineer may be deciding whether to use a linked list or binary tree and the LLM is implementing it with the available code stack approved by the company

At this point it's a slightly more sophisticated version of the IDE's "refactor tool". If, in addition to replacing "HashMap" with "LinkedList" in a bunch of places, it might also fix tests, then it's indeed useful but won't be worth paying much more for it.

> A company that can successfully implement such an LLM opens up their talent pool from people who know their stack (or want to learn it) to people who know any stack

Think about it: if the business usefulness of a tool is mostly in reducing onboarding time by even a 75%, it's not really that valuable.

[ebhn]

I like this direction, but I worry about developers involvement in the design of the DSL becoming the new bottleneck with the same problems. The code which becomes the guardrails cannot just be generated slop, it should be thoroughly designed and understood imo

[ragall]

Sure, that's why I think that it will mostly be SaaS businesses doing the DSLs, because the business contracts allow for more accountability than having employees do poor reviews, accumulating tech debt, that will only become visible down the road.