Clojurians Log v2

it is issue of the whole job market not just Clojure

by issue, you mean less number of jobs?

yes, finding any job become harder even for chemists from top Universities, job that could be found in a day or two, now takes some months

oh, got it. so any job that can be done by AI is impacted.

not just AI, any job because of the economical issues & would be worse in the future

Yup, the job market was already getting worse before AI started to impact jobs.

In fact, I think that the impact of AI on jobs is overblown—companies are using it as an excuse for layoffs they would already be doing: you can look at graphs of layoffs and they started a couple of years before AI hit the scene.

but there are reports that some companies that did layoffs did re-hiring also. have you seen a reduction of headcount in your orgs? or less number of devs needed to do the same amount of work?

Yes, we've had a reduction in headcount due to market conditions; nothing to do with AI. But we're a small company anyway. Many companies over-hired before/during the pandemic, then went through multiple rounds of layoffs and reorgs, then hired a bunch of new people, or backfilled roles they had cut. I don't think you can draw any useful conclusions from anecdotal evidence tho'...

things are in a major flux right now i guess. there are predictions around both AI-will-take-all-the-jobs vs more-software-devs-will-be-needed in future. i hope the storm settles soon and we get a clear picture for the longish term.

Yeah, I think we'll see the "bubble" burst in one way or another, but when and what the market will look like at that point... who knows? Kent Beck has been saying for a while that we're in that phase of "no one knows anything" 😐

My feeling is that AI-assisted coding is still changing so fast that any courses will be outdated almost immediately. And every team that uses AI is likely to be doing it differently. Join the #C068E9L5M2Q channel and scroll back to learn about the many ways folks are using AI tools.

will do that. thanks!

1. If you're still in the prompt-engineering game - you're lagging behind. Don't get too obsessed with prompts, AGENTS.md, etc. Static config files have a low ceiling, so stop polishing them in isolation and start building the loop around the model. The harness does not replace the prompt; it decides which prompt fragments get loaded for each task. 2. You should be at least at the harness-engineering stage. Build your own harness. Don't wait for anyone to share some beautiful set of tools and skills and all. Whatever they've built - it works for them. An AI-harness is too individual; you can only look at someone else's, but eventually you must have your own. A harness that you control, you maintain and you own. No gym expert can run a treadmill and curl dumbbells for you - they can only give recommendations. Treat whatever you find on GitHub like a recipe book. Pick a language you like, and ask Claude to build things for you, I mean, not for you but for Claude's own benefit. 3. Do get to the spec-driven-engineering stage. I evaluated OpenSpec, Spec Kit, Kiro, BMAD, Tessl, GSD and cherry-picked some goodness into my harness. I mean, I asked a model to do all that. Note though - a harness with specs can still confidently emit wrong answers unless the loop closes on tests, real artifacts, and runtime checks rather than on the model's own summary. But then, if you have tests, etc., don't you get most of the correctness with no spec system at all? Well, specs buy something different: shared intent, reviewability, and continuity across sessions, agents and people. They are the coordination layer, not the correctness layer. The mistake I made initially was that I treated the spec as a diary. It shouldn't be. If things only get appended to it, it's not a spec. Specs should be in a git repo. Speaking of git, please do learn git-worktrees. They are great when multiple agents touching the same codebase. Finally, do not remove thorough evaluation from the loop. Nothing can replace your intuition. You cannot tell whether a harness change helped. Neither can the best model. Keep your harness flexible and ever-evolving, and keep an eye on it. 4. Get to the hand-off and orchestration stage. You eventually need to be able to start a bunch of agents that introspect one-another's work and Lisp-based systems are the best substrate to build such things.

I followed some of the courses provided by Anthropic themselves and they're definitely good enough, either to get started or test your knowledge if you learn by doing on the job (which is what most people do in this area) https://anthropic.skilljar.com/

Thanks!

Here is my way of using AI after 23 years of designing systems. Perhaps you will find it more useful, than random YT. Personally, I lose so much time trying to figure out the right way from YT etc. - these things didn't work for me. Saying that maybe my method will not match with your needs - I don't know :) AI cannot have experience. It runs a short task and stops — it does not work in multi-year sessions where it watches the results of its own decisions. Its recommendations come from training data: marketing, blog posts, opinions of random people. That is why it is a poor architect, even though it writes code very well. It is worth handing data processing over to AI, but keep full control over the data structure, the business rules and the tests — not in documentation written in English, but in code that is part of the system and cannot drift out of sync with it. After 23 years of designing systems, this is what my architecture looks like in projects where I use AI heavily to write code. https://tech.wladyka.eu/posts/2026/ai-specification-as-code/

Will read. Thanks!

1. If you're still in the prompt-engineering game - you're lagging behind. Don't get too obsessed with prompts, AGENTS.md, etc. Static config files have a low ceiling, so stop polishing them in isolation and start building the loop around the model. The harness does not replace the prompt; it decides which prompt fragments get loaded for each task. 2. You should be at least at the harness-engineering stage. Build your own harness. Don't wait for anyone to share some beautiful set of tools and skills and all. Whatever they've built - it works for them. An AI-harness is too individual; you can only look at someone else's, but eventually you must have your own. A harness that you control, you maintain and you own. No gym expert can run a treadmill and curl dumbbells for you - they can only give recommendations. Treat whatever you find on GitHub like a recipe book. Pick a language you like, and ask Claude to build things for you, I mean, not for you but for Claude's own benefit. 3. Do get to the spec-driven-engineering stage. I evaluated OpenSpec, Spec Kit, Kiro, BMAD, Tessl, GSD and cherry-picked some goodness into my harness. I mean, I asked a model to do all that. Note though - a harness with specs can still confidently emit wrong answers unless the loop closes on tests, real artifacts, and runtime checks rather than on the model's own summary. But then, if you have tests, etc., don't you get most of the correctness with no spec system at all? Well, specs buy something different: shared intent, reviewability, and continuity across sessions, agents and people. They are the coordination layer, not the correctness layer. The mistake I made initially was that I treated the spec as a diary. It shouldn't be. If things only get appended to it, it's not a spec. Specs should be in a git repo. Speaking of git, please do learn git-worktrees. They are great when multiple agents touching the same codebase. Finally, do not remove thorough evaluation from the loop. Nothing can replace your intuition. You cannot tell whether a harness change helped. Neither can the best model. Keep your harness flexible and ever-evolving, and keep an eye on it. 4. Get to the hand-off and orchestration stage. You eventually need to be able to start a bunch of agents that introspect one-another's work and Lisp-based systems are the best substrate to build such things.

@ag Thanks for the detailed response! Will keep it as a reference as I learn/practice AI assisted dev.

I'm not sure how useful the answers would be since there is a huge difference between 100% codegen where the prompt is a ticket and the LLM decides on the solution versus prompting a specific solution you decide upon. Both 100%, different outcomes.

this is to know how much the programming language matters now. do better programming languages still give any advantage if you are not writing code anymore? like does it matter in planning or code review?

We were up to about 15-20% AI-generated maybe 6 months to a year ago, but we're down to 5-10% these days—but we are primarily doing maintenance on a well-established app platform. Companies in the "build" phase are likely to be at higher percentages—if they use AI at all—so you're not going to get any useful answers here (nor would any answers really be useful, I suspect: every team in every company is different).

but are companies switching languages based on what the AI can write better or other factors like compile times. or is Scarf(Haskell -> Python) a rare case?

Larger companies already use multiple languages/stacks. Some companies might choose to switch languages/stacks based on AI, maybe, but I haven't seen many cases reported so I would consider them outliers. There are some arguments in all directions: some folks argue a compact language (Clojure, Haskell) is better for AI due to token count, some folks argue statically typed languages are better for AI because compile errors help AI fix problems faster, some folks argue mainstream languages are better because AI has more training data in those languages. Back to Kent Beck's comment about "we don't know anything" right now 🙂

I worked in an org where they managed to grow the backend by 60% LOC in a month (yes, looking at the whole). And this was an 8-year-old organization. There were many tests and so on but it's really a substantial amount. Some orgs are pushing hard on this. Even if they're a couple of devs. I still don't know if this is a good idea to work like this.

"we don't know anything" i guess :D

A lot of remote jobs are still tied to narrow range of timezones. @adityaathalye might have more insight on remote-in-India jobs perhaps?

A year ago, I was in India (Goa) and was searching for jobs online from there. Back then, I found quite a few Clojure job openings in India. But I'm afraid the competition there is very fierce.

might have more insight on remote-in-India jobs

Surveying jobs posted to HackerNews over the last, say 12 months should give you a good signal about the language ecosystems that are still in flavour. If even HN job posters are not visibly hiring for niche language ecosystems, then I'd say jobs asking for those skills are in short supply, in general. In the "Who's Hiring?" threads of recent months, I don't recall seeing even one job posting asking for Clojure, Haskell, Erlang, OCaml, Elixir, Common Lisp, and so forth.

Certainly through 2023, and I feel through much of 2024, there would be several of those (niche skill requirements). Frequently at least one "Who's Hiring" job would be specifically for a Clojure-built product, in each month's thread.

I've seen PlantingSpace last month. But their rejection message was the same as in 2023. > developing our core > focusing on skill sets that match our current needs quite narrowly for now

@adityaathalye Clojure/Haskell jobs are very few in HN hiring for past months. Elixir is better relatively but not too good in absolute terms. Will pick up a mainstream language I guess.

Compared to mainstream languages? No. Compared to each other, maybe. But if you look for FP jobs that are not Clojure or Haskell, you'd be a beginner in that language competing with other FP devs who already know that language.

If you're open to doing FP-style programming in a mainstream language (Java, JS, typescript) then you'll find that there are a lot more options for jobs

But you'll also be competing with an order of magnitude more candidates (see my comments in another thread responding to puneet).

There's definitely more Scala gigs than Clojure out there, so I think it's second in the market. But it's all niche and all FP gigs would sum up to a fraction of Python or JS gigs taken individually. Yep there's FP niceties in other langs but then you might have to fight for those depending of what other team members prefer.

I think I will apply to jobs irrespective of the language and then decide whether I need to pick up a mainstream language depending on the responses.

From my perspective, Elixir jobs seem more abundant than Clojure, often requiring > 6 years of experience.

It probably won't make difference. When my company opened a JavaScript role, we got around 1,000 applications very quickly. When my company opened a Clojure role, we got a lot fewer applications but they were higher quality. Either way, you're competing with a lot of other people in any tech stack. You might even have better odds with Clojure or Haskell than JS/Java/whatever.

thanks!

Focusing on Clojure exclusively is a bit daring in my opinion - I would say you should pursue the opportunities that will lead to your greatest happiness, so consider that the people and the workplace culture may outweigh the choice of language.

In the age of AI, programming is less about the enlightened blissful flow state you associate with your favorite language, and more about managing a to-do list. Sad but true

it's a shame honestly

Anyways... we have #C0B7Q4XRM1U for that discussion...

I've been doing Clojure for about 16 years and it's still the most fun I've ever had programming 🙂

It depends on the company. As a hiring manager of 30+ years, I've never given a task-home assignment at any company (and I don't do "technical tests" in interviews either), but a lot of companies still do that. There are folks here who've had to deal with AI avatars doing the whole interview, or high-pressure interviews where the time is so short you have to use AI to be able to complete the tasks fast enough. The first gate is always getting your resume in front of a human, and that is increasingly filtered via AI systems, unfortunately, because of the huge numbers of applications—too many for humans to realistically filter through on their own 😞

i will make my resume keeping the AI filtering systems in mind. adding buzzwords and all.

ok