We write mostly Java, some Kotlin, targeting the JVM.
Most commonly our software runs on premises on server-class hardware (or what passes for server-class depending on the industry...), sometimes hosted in the cloud, sometimes on "edge" hardware (think Raspberry Pi class power/spec wise).
One component of the software actually is a web frontend (and a Jetty backend) to go with it, but it's not your typical "web-app" and it's not SaaS. But there's much more to it than that.
The problem is you still think that the perfect prompt or AGENTS.md or whatever is going to get you a one-shotted (or close) feature in return. There isn't (yet) a model or orchestration framework that is going to take a large feature from start to finish for you.
The reality is that LLMs/agents are just a new way to write code. You still need to understand, more-or-less, how this feature is going to actually work, and how it needs to be implemented, from start to finish.
The difference is that you don't write the code, you tell the LLM to write the code. Once you've figured out the right "chunk size" an LLM can handle it's faster than doing it yourself.
I've found it's actually a little _harder_ in green field projects because the LLM doesn't have guard rails and examples and existing patterns to follow.
You missed my point, the original comment is stating that the market for such a device doesn't exist because developers are too finicky and customisation focussed.
As a counter example - look at macbooks which are about as un-customisable as they come, but a large portion of developers use them. Meaning the market exists even if it's currently dominated by Apple (which as you/the post points out is slipping)
Having said that I do believe that many brands have way too mamy SKU and I widh they would be more opinionated on what they believe is better for their customers while maintaining clear and strong ethics (reliability should be #priority)
We use it for (non-Spring) backend development. It's lovely and always my first choice over Java.
I like to avoid mixing Java/Kotlin within the same module when I can, but it still works, and parts of our codebase are mixed this way. (by module I mean e.g. the same Maven or Gradle module, i.e. try to avoid a situation where you have a `src/main/java` and `src/main/kotlin` next to each other)
In fact, if there was a better, more direct way than publishing on GitHub to feed my open source code directly into future training runs, I would probably do that.
>The Politiken article has been corrected. They're dropping Microsoft Office but not Windows. They might in the future, that seems to be the general trend, but in this case the minister said they're dropping Microsoft services and interviewer misinterpreted that as including Windows.
This in combination with making the tool call / json response itself also "batched" is a good pattern. Instead of returning a single `{english, foul}` object per record, pass in an array of records and have it return an array of `[{english, foul}]`. Adjust the inner batch size depending on your record size and spread the rest over the batched API.
