Until a majority of software engineers become unemployed, we won't collectively wake up and act which is what we should to this existential crisis unfolding. Action more than yet another plausible sounding article.
Speaking of Iraq, Sadam decided against using chemical weapons in the Gulf War because he had received intelligence from the Russians that the Americans would counter with nuclear weapons and he didn't want to risk that.
A few days ago I asked Claude what kind of language it would like to program in, and it said something like Forth but with static typing, contracts, and constraint solving, implemented on the Erlang BEAM.
So I have been prodding Claude Code for a few sessions to actually do it. It's a silly experiment, but fun to watch. Right now it's implementing a JSON parser in the generated language as a kind of milestone example.
This is one of the more interesting uses of Claude I've seen. Instead of asking it to write code in an existing language, you asked it to design the language it wants to think in. There's something philosophically fun about that I feel = like asking a painter to design their ideal brush.
I'm curious whether the generated language actually makes Claude produce better/more reliable outputs when writing in it, or if it just reflects Claude's training bias toward what "good language design" looks like in its corpus. Would be a fascinating benchmark to run.
I plan to keep dumping tokens into it here and there to see where it goes, it's a fun rabbit hole.
I find that it's able to produce working code in the generated language just from the README and the previous examples without much trouble. And I've seen the strict typing help it catch and correct bugs quickly.
I steer it very little. The only thing I keep an eye on is not allowing it to cheat about things like writing lots of concrete functionality in the host language and then just calling that from the interpreter.
sure, for example it generated this small demo of the type and contract safeguards. As you can see, it's mostly "Forth but with things":
# bank.ax — The Safe Bank (Milestone 2)
#
# Demonstrates property-based verification of financial operations.
# Each function has PRE/POST contracts. VERIFY auto-generates random
# inputs, filters by PRE, runs the function, and checks POST holds.
# DEPOSIT: add amount to balance
# Stack: [amount, balance] (amount on top)
# PRE: amount > 0 AND balance >= 0
# POST: result >= 0
DEF deposit : int int -> int
PRE { OVER 0 GTE SWAP 0 GT AND }
ADD
POST DUP 0 GTE
END
# WITHDRAW: subtract amount from balance
# Stack: [amount, balance] (amount on top)
# PRE: amount > 0 AND balance >= amount
# POST: result >= 0
DEF withdraw : int int -> int
PRE { OVER OVER GTE SWAP 0 GT AND }
SUB
POST DUP 0 GTE
END
# Verify both functions — 500 random tests each
VERIFY deposit 500
VERIFY withdraw 500
# Prove both functions — mathematically, for ALL inputs
PROVE deposit
PROVE withdraw
# Demo: manual operations
1000 200 deposit SAY
1000 300 withdraw SAY
Running it outputs:
VERIFY deposit: OK — 500 tests passed (1056 skipped by PRE)
VERIFY withdraw: OK — 500 tests passed (1606 skipped by PRE)
PROVE deposit: PROVEN — POST holds for all inputs satisfying PRE
PROVE withdraw: PROVEN — POST holds for all inputs satisfying PRE
1200
700
Yep, we'll evolve patterns which facilitate system to system interaction better than the ones we had built for human in the loop by humans. That's inevitable. CRUD apps with a frontend will be considered legacy etc. They'll be replaced by more efficient means we haven't even considered. We live in an exciting time.
> we'll evolve patterns which facilitate system to system
We have! It has different names, shapes and forms. For example WiFi. Last I checked, it’s not designed for human in the loop and you need multiple levels of decoding for a human to make sense of it.
Speaking of AI taking over the world, have you seen how many projects on ShowHN are using GitHub? Do you think that's by accident or is it trying to normalize a place for an AI to lurk about like a crocodile hanging around a river outlet?
I won't read the article but I think this is the role that will remain for humans, to be the 'fall guy' when the vibes go wrong. You will have to live in chronic stress, on call so to speak, so when prod goes down, you will take the blame. Maybe that vibe coded PR you didn't and couldn't read contained a serious bug or security lapse, maybe the system design you didn't do but approved contained a RCE you never knew about. Fun times ahead.
This is all well and good but Elixir with Phoenix and Liveview is super bloated and you have to have a real reason to buy into such a monster that you couldn't do with a simpler stack.
I'm not sure I agree with the "bloated" description, but I will say that I really like Elixir, and really dislike LiveView. Which is a shame, because the latter is pretty inescapable in Elixir world these days.
Interesting take. I’m an Elixir fanboy because I find LiveView to be very slim. You’re just sending state diffs over WebSocket and updating the DOM with MorphDOM. The simplicity is incomparable to state of the art with JavaScript frameworks in my humble opinion.
I'd use something like a lightweight python framework (take your pick) and pair it with htmx. You can run that on low powered hardware or a cheap VPS. I can't even dev elixir on my N100 minipc, it's too demanding. Otherwise Python and SolidJS or Preact will work perfectly for a SPA.
reply