'Minimal' is an overloaded term in software engineering, perhaps because it is a marketing friendly term. Most people when hearing the word minimal applied to software, seem to map it to some vaguely good quality (anecdotal, can't prove it) without asking 'minimal how?'.
I can think of a few ways it gets used (non-exhaustive obviously)
1. Surface Minimal in the UI sense, the Dieter Rams lineage of "less but better". Clean non intrusive UI, show users only what they need to see when they need to see it. No clutter.
2. Scope The YAGNI principle, don't build it until you need it. The product owner exercises scope discipline to cut down unnecessary features so what is important can be focused on.
3. Systems Implement what is needed with minimal added complexity. Keep refining and reformulating the problem until you reach a form that can be built elegantly and maintained efficiently by keeping the system consistently close to its lowest entropy state.
4. Effort The builder optimizes for ease at the cost of good design or a well defined scope. Typically asks an LLM to build something for them with a poorly specified set of requirements and design. This is largely an 'unlock' from LLMs becoming good enough at coding.
Notice that the first 3 have one thing in common: they require effort and a nuanced understanding. It takes a lot of hard work to make something look simple. There are inherent complexities of a system that come from the fact that you have multiple competing priorities, multiple distinct constraints and multiple use-cases. I am calling this inherent but perhaps a more precise version would be 'emergent', in a Conway's Game of Life sense. When you have many different axes interacting in a system, complexities emerge. Keeping these complexities cleanly and consistently mapped to rigid, deterministic primitives is an ongoing work.
Now the number 4: Effort minimalistic systems, the deluge of 'fast minimal XYZ built in a day from scratch' variant. The minimalism here was achieved mostly by not addressing important concerns and/or avoiding the high effort parts. This often gets conflated with the LLM use at all, however a more accurate version would be 'irresponsible use of LLMs'.
What makes this worse is LLMs' tendency to treat everything as a demo unless steered otherwise. If you looped through an implementation describing simply the behavioral expectations like "do this, make no mistake", LLMs will most often implement the behavior but also add a lot of nasty complexity in the code like god objects, functions that handle a dozen responsibilities and errors swept under the rug. Ironically, without steering, LLMs tend to produce code that they can't maintain well themselves. So, every vibe-coded project gets increasingly slower and more token consuming in development and maintenance.
Is this just an LLM capability question?
No, and for well-founded reasons. LLMs can get arbitrarily good at handling tasks, but they will produce outcomes only as good as what information they were supplied. And to really supply a perfectly accurate picture of every requirement and every constraint that is constantly updating is still an enormous amount of work.
This is also why it looks unlikely that AI in its current form will cause mass joblessness. The human engineer role in the era of powerful models perhaps becomes that of a 'chaos to order mapper'.