This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?
It depends. Ah, well I guess it's a litlle unfair to say that because in the context of your question I absolutely didn't mean for it to be taken literally and I should've been more clear. It does depend on domain though. For some of our engineering and control software it is almost meant literally. Since we'd have very few abstractions beyond the language primitives because of explicity.
For what you were asking though, it's not no-abstractions it's YAGNI where business logic lives in "just" functions which operate on plain data structures with runtime assertions and validation. The data structures will usually include domain specific types. There are no classes, object hierachies or architecture abstractions, at least, there almost never ever are. When it absolutely doesn't make sense not to introduce an abstraction beyond what we typically want, then it's allowed. This pains a lot of Uncle Bob's disciples, until it doesn't.
The advantage of it is that we've found that it works really well with LLM's. At least in my experience they seem to be absolutely excellent with explicit, localized code instead of layers of indirection.
Right, that makes a lot of sense. Seems like reviewers can easily see and check those asserts to understand if the LLM has written something sensible (and I presume those asserts are strongly declared in the prompts).
I'd love to read a blog post or something on what you've discovered on good software patterns for AI. I'm only now getting into using LLMs and beyond the purely technical aspect of what LLM is "best" it seems like there's a wealth of learned experience in how to structure and write code to work well with them.
I've heard good arguments for using Rust with LLMs because the compiler keeps the LLM from making silly mistakes. What languages have you been developing in?
With low code / no code systems like Power Automate, Boomi, Workato you can already do plenty of enterprise workflows without a line of code, just diagrams.
Now those systems have evolved to become orchestration workflows engines with agents and tools integrations, thus several scenarios that still required proper code, have now been reduced to agent instructions.
I think many in HN don't have a clue how little traditional coding some enterprise scenarios require nowadays, plugging SaaS products with such tools.
Being a backend dev is more administration than actual classical coding.
I think orchestration is the perfect description. In enterprise you have a bunch of standard systems which play by their own tune, and even with a lot of the "low-code" options you're going to build systems that transfer data to the right system at the right time. Like a director of an orchestra.
Having spent a lot of time in enterprise which is not related to software development (or IT at all) I'm pretty familiar with a lot of the low / no code or Robot Process Automation systems. Which always end up requiring specialized developers, except, you can't hire software developers for them so you end up with various consultants creating huge messes. Microsoft's Cowork is the first time I've seen a system which can actually directly replace people who aren't experts in their business domain. It requires a lot less than any other system I've seen before. You need someone who has global, intune and AI admin in the Microsoft ecosystem, who know enough about software development to evaluate an app to be safe and efficient and how to debug it, and a domain expert. Then you'll have something which "just works". It's scary really.
I had no domain knowledge of PowerBI like at all, and while I could fill a data architect role, I would have never been able to do anything beyond a semantic model in Fabric and even on the semantic model it's not like I've ever worked with DAX. Yet Cowork (with read access to the Fabric workspace) could guide me through the process of creating a powerBI report set which was good enough that the business wanted to use it with a few minor improvements... Five months ago, this would have been a 2 people job. Now I was basically a puppet getting told which button to click in the report editor. If Cowork had write access it wouldn't have needed me in the loop once the data was delivered to the datalake it shortcutted to.
Thanks for the experience overview, those kind of experiences is what makes me evaluate that long term, some of us are lucky to slid into other roles, more architecture like, others not so sure.
For many kind of products, where selling software isn't the main business, companies will settle for approaches like that you describe, writing classical business software isn't what it used to be.
For what you were asking though, it's not no-abstractions it's YAGNI where business logic lives in "just" functions which operate on plain data structures with runtime assertions and validation. The data structures will usually include domain specific types. There are no classes, object hierachies or architecture abstractions, at least, there almost never ever are. When it absolutely doesn't make sense not to introduce an abstraction beyond what we typically want, then it's allowed. This pains a lot of Uncle Bob's disciples, until it doesn't.
The advantage of it is that we've found that it works really well with LLM's. At least in my experience they seem to be absolutely excellent with explicit, localized code instead of layers of indirection.