I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.
That’s a good point but I think this article above would push back on this point slightly. I certainly am able to do a lot more with LLMs because it can produce a passable solution in a lot of places but I’m not sure it expands my solution space really. I tend to separate what I’m able to build and what I’m able to solve. I can build a frontend with an LLM but I don’t think I’m able to solve frontend engineering problems.
I've been working with Apache AGE (openCypher in Postgres) recently and found that left to its own device, the agent wrote terribly inefficient queries, even when given a test harness and instructions to examine the result of the query plan.
It just didn't seem to understand the graph traversal, even when given the graph schema and small snippets.
I ended up hand-writing the structural "skeleton" of the main query that I performance tuned to a certain extent and then handed it over to Codex to finish off. Once it had this skeleton to start from, it was able to do a much, much better job of writing this query.
I think this list demonstrates the OP's point—entrenched, resource-heavy, and reputable firms have and will continue to capture most of the markets, not for lack of competition, but by ownership over the distribution channels.
Having said that, I don't think it's all AI (this trend's been going on for a while), nor do I think startups can't thrive—as the pie gets bigger, competitors can carve out yet smaller niches, as the OP points out.
I've had the same experience, although I feel like Claude is far more than a junior to me. It's ability to propose options, make recommendations, and illustrate trade-offs is just unreal.
Supported by my experience too. My tinnitus is very real, but when I discovered just how much of a psychological component was there, it became more manageable. Little by little I thought I was losing my hearing until I had it checked—it was perfect. The audiologist helped me understand that my constant "tuning in" to the tinnitus was creating the perception that my hearing was being harmed by loud noises and leaving a high-frequency sound in its place. Which is there, but when ignored, it largely disappears.
I think the bottom line with Clojure is it's not an ecosystem well-suited for non-veteran programmers. For as simple as the language is, effectively using Paredit, navigating partially documented libraries, diving into source code to see how things interact—it's tough as a new developer. I don't believe Clojure is overtly hostile to newcomers; it's just crafted by veterans, for veterans. And this is the result.
I consider myself something akin to a veteran. I've been coding for over two decades. Not sure if that qualifies, but anyway.
My point is: it's been with experience that I've come to value ergonomics the most.
And that for me includes having a thriving and focused ecosystem, extensive industry penetration, good and stable tooling, lots of well known codebases learn from, etc.
It was when I was young and inexperienced that I didn't see those as the important bits. I was happy hacking on any half assed editor exploring undocumented APIs and trying to discover patterns and idioms by myself. I was happy to waste time.
I'm not anymore. That's why, while a love Clojure as a language, I don't really use it that much nowadays.
If only time served makes you a veteran, I guess I'm one too, but a lot of it was mediocre time.
I still like hacking on things, but only on hobby projects. When it has something to do with work, I agree. Clojure reminds me of why I liked coding in the first place and I like the way LISP-type languages make me think differently about what I'm doing.
But "in the real world," yeah, I don't want those things. I want something I can build and maintain and be done.
Our experience is that Clojure is a very good language for newcomers to programming as a profession.
In fact, we almost exclusively hire new computer science graduates. None of them had heard of Clojure before joining, and the vast majority of them became useful in 2 weeks, and become productive in a few months. What you described as barriers are the things that got sorted out in the first day when they join.
We do not hire veterans unless they already know Clojure. These people need to unlearn stuff, some of them are resistant to changes, so we don't bother with them.
