Power cuts across multiple dimensions and levels. There's a lot of power dynamics in nature, within species, across species. In humans (sociologically), there's individual power, there's collective power, there's power of nations -- all acted out in relation to other parties. Power dynamics dictate all sorts of interactions (and bullying and leverage and so on).

In my dictionary, this sociological power has always carried a negative connotation (but, obviously, that is not necessarily the case). Evil, so to speak. "Power corrupts." Patriarchy, casteism, racism, elitism, wealth-gap etc. are all driven by power structures emerging from privilege, power imbalances and the "misuse" of said privilege. And the resistance to and overcoming of such a power is by way of dismantling the power through collective action. The leftist ideal, so to speak.

When a bad-actor uses power (of privilege, economics, military-might etc.) to commit bad acts, we hear about it from the lens of "misusing/abusing" their power. When a good-actor does some good, the coverage of that doesn't look at it from the angle of power; rather, it's usually seen from the lens of responsibility or philanthropy or altruism.

I guess power can be studied from a utilitarian standpoint (this is what the Thiels and the Musks do and then leverage that knowledge to screw the world while completely believing that they're a force for good!). And it can be studied as an intellectual curiosity.

There's a lot going on here that I need to understand. Hypothesis that I implicitly seem to hold true - like power inherently corrupts at some point - need to be cross-referenced with existing literature (beyond Julius Caesar). That's just one example.

--

For starters, I have a bunch of books I've long-listed (in no sort order). Who knows how much of it I would make through before something else comes up.

• Influence: Psychology of Persuasion, Robert Cialdini
• Power: Why Some People Have It and Some Don't, Jeffrey Pfeffer
• The Prince, Machiavelli
• Rules for Radicals, Saul Alinsky
• 48 Laws of Power, Robert Greene
• Who's Pulling Your Strings? Harriet B. Braiker
• Games People Play, Eric Berne
• Never Split the Difference, Chris Voss
• Discourses on Livy, Machiavelli
• The Crowd: A Study of Popular Mind, Gustave Le Bon
• The Art of Worldly Wisdom, Baltasar Gracián
• Without Conscience: The Disturbing World of Psychopaths Among Us (Robert Hare)
• The Gift of Fear (Gavin de Becker)
• 33 Strategies of War, Robert Greene
• In Sheep's Clothing: Understanding and Dealing with Manipulative People, George K. Simon, Jr.
• The Mind and Society, Vilfredo Pareto
• Brave New World & Brave New World Revisited, Aldous Huxley
• The Machiavellians: Defenders of Freedom, James Burnham (on the elites argument)
• Discourses on Voluntary Servitude, Étienne de La Boétie
• Propaganda: The Formation of Men's Attitudes, Jacques Ellul
• Propaganda, Edward Bernays
• The Dictator's Handbook, Bruce Bueno de Mesquita ()
• The Grand Chessboard, Zbigniew Brzezinski (former NSA writes on why US should control Eurasia)
• The Power Broker, Robert Caro (abt an influential New Yorker, Robert Moses)
• Han Feizi, Han Fei (Chinese legalist classic on how a ruler should be)
• Art of War, Sun Tzu
• Arthashastra, Kautilya
• Vidura Niti, Mahabharata
• Niti Shatakam, Bhartrhari
• Chanakya Niti, Chanakya
• The Book of Ghost Valley Master, Guiguzi
• Thick Face, Black Heart - Chin-Ning Chu (trans of Thick Black Theory by Li Zongwu)
• The Craft of Power, R.G.H. Siu

Interestingly, the book ordering kind of reflects the western-oriented structures of internet search, online data and general inclination of the world. When we talk of power, it's almost impossible to go without talking about Machiavelli's Prince. Not so much Kautilya's Arthashastra. (Sun Tzu is perhaps an exception, but the credit to that goes to western propaganda). Internet searches reflect this big time. Loads of recommendations like 'Discourses on Livy', 'Art of Worldly Wisdom', 'Power Broker', and none of the oriental books till I prodded.

There are some 'popsci' kinda books in the list (Robert Greene, notably). But the most interesting one is 'Rules for Radicals', a '71 book from a community activist.

--

India's foreign minister, S. Jaishankar, writes (in his book, 'The India Way'):

The one society that has elevated dissimulation to the highest level of statecraft, as one of our foremost Sinologists pointed out, is China. Its virtues are repeatedly lauded in the Three Kingdoms epic, where many of the decisive encounters are won by trickery rather than by force. The 36 Stratagems in the Book of Qi are further proof of how deeply such approaches have percolated into popular Chinese thinking. 'Deceiving the heavens to cross the ocean' or' making a sound in the East to then strike West' are among its most well-known aphorisms. No less are 'decking trees with false blossoms' or the empty fort strategy. Unlike in India, there is neither guilt nor doubt in dissembling; in fact, it is glorified as an art. Some analysts have even suggested that China's extraordinary rise has drawn heavily on its cultural attributes.

Sun Tzu is sharp and incisive but looks like even he feels mellow compared to the kinds of 'Thick Face, Black Heart' (Li Zongwu, end of Qing dynasty). Anyway, the point is: the cultural happenstances of a system get encoded into literary works and then those go on to dictate (amplify, preach, sanction) all sorts of behavior into the cultural DNA of the descendants of that system. True of Sun Tzu, true of Machiavelli, perhaps true of Kautilya too.

I have notes from 'Acting with Power' that I need to revisit. And I started off with (the populist) '48 Laws of Power' to get a broader sense of what's out there. It's not so much a serious study-book (and I may be wrong about that), but Greene has distilled a broad collection of prior work, I might just get a good look at the layout of the land and the bibliography helps.

I've been using rdigest for 500+ days now. Of the handful of side-projects I built to scratch my own itch, this remains a powerful daily-driver.

--

Contents

• A quick brief of what rdigest is
• Learning by building
• Hand-crafting software and LLMs
• Scratching an itch vs. building for others
• Sporadicity

--

I.

Now, this part about what rdigest is (and why) is for the accidental reader who landed here god knows how:

rdigest is technically a feed reader but it's also not really a feed reader. It collects links from all the feeds you follow and then creates a daily digest for you. The daily digest is just a finite bunch of links. A bunch of links grouped by source and zero algorithm. A bunch of links you look at, skim through, click on the ones you want to actually read or view... and then you're done with your digital content catch up!

That last bit is the critical piece, the linchpin ideology.

The way we consume digital content today is horrible. There's an infinite, never-ending stream hitting at us at all times. All kinds of platforms have interfaces that are designed cunningly to trick your brain into staying on the platform for as long as possible. You're thinking about Twitter, Instagram, TikTok and YouTube, but even other outlets like blogging engines, content management systems, AT-Proto interfaces (Mastodon/Bluesky) and even popular feed readers promote and enable these "infinite stream" interfaces.

This leads to all kinds of problems. Attention is low, ability to sustain a longform is gone, and no interface or product gives you this feeling of closure. The same mechanics of constant connectivity over work Slack ruining work-life boundaries are at play: it never feels like you're done reading, seeing, hearing the things you want to for a given day.

Alright, so that's the tirade against dark-pattern-embracing products streaming endless content and hacking into our neurons.

There may be many antidotes to this. rdigest's idea is borrowed from the old, physical newspaper model that I harp about. Imagine the morning newspaper (ie, if you're old enough). The paper arrives. You skim through the headlines, read the ones that interest you, and then you're done for the day. There's nothing more to do there (unless you were some hotshot that got the evening paper too). rdigest pretty much does the same, except it is about links from RSS feeds you follow and it's got no frills. Just a page of links like this:

--

II.

Reminiscing about a "hand-written" side-project in the age of LLM-written software seems weird and futile. There's nothing special anymore about building software except for the big picture bits and the devil-is-in-the-details bits.

And yet, artisanal software, especially of the crude, home-cooked kind might retain its charm.

I had two hopes when I began rdigest. One, to build something that eventually helps me manage my daily digital consumption (that had spiralled out of control to the point of giving up on online reading). Two, to learn a programming language (Haskell in this case) along the way.

I kept a journal while I built rdigest. The first entry goes:

Decided to finally build something in Haskell to learn the language. So far, I've been solving puzzles and similar tasks, but nothing has given me the confidence to say, "Yes, I can build that in Haskell."

As I built out rdigest, I ended up learning nuanced things about file I/O, batched concurrency, safely interacting with SQLite, implementing a small migration module, and more, all from within the Haskell ecosystem. Like all side-projects, it was fun, it was frustrating at times, and thankfully it also ended up being rewarding.

--

III.

Work on rdigest began in late 2024. By this time, I was using ChatGPT at work as an intelligent rubber-duck that talks back. Whatever I'd have googled or Stack Overflowed, I ChatGPT'd.

rdigest was built by hand but definitely helped by inputs from ChatGPT. Of course there were also many instances when the LLM sent me on wild goose-chases and proffered irrelevant complexities.

Wrote some initial code based on ChatGPT's example of scraping. However, ChatGPT got the attr function wrong.

ChatGPT suggested optparse-applicative, but I decided it was overkill for what I needed. A simple --url <url> argument was enough.

I had a long chat with ChatGPT about these things, asking it about the idea of bubbling up the errors from ExceptT without having to do runExceptT wherever I wanted the error to be bubbled up but the ideas it returned were not working or not useful — or in some cases, it was just reinventing the ExceptT or ReaderT monad transformers.

But also:

... I learned how to bundle the template as part of the binary by inlining/embedding it using the file-embed package—all of this thanks to ChatGPT.

Asked ChatGPT for a good web scraping library in Haskell. It suggested tagsoup and html-conduit (for fetching the source). Took a look at the examples and docs... seemed a little hard to grasp. Asked ChatGPT for a simpler alternative, and it suggested scalpel. Liked it, and decided to use it.

Claude had not yet come up as a significant competitor. Today, I don't use ChatGPT almost ever.

--

IV.

For a very long time — ie, over a year — rdigest remained a CLI-only tool. The only way to add feeds, manage them, produce a daily digest, and so on was to use the tool in a terminal.

But right there on my day 1 journal entry, I had wanted to also make rdigest spin up a local server so that the feeds could be managed and daily digests could be viewed on a browser.

Life got in the way. I would occasionally push an update or two. I even built a now-defunct feature that sent the daily digest links via Telegram. But the server feature never happened.

I finally managed to find some motivation to build out this feature in the last week. What's special about this is the stack: the heavy-lifting backend, server and CLI are all in Haskell, a pure functional language, and the frontend application that renders a near-brutalist, minimal web interface is written in Elm, a pure functional language inspired by Haskell. There was a brief moment where I considered htmx, but chose Elm eventually.

The local server feature is not something I use every day. I have a different setup to make the daily digests available "on the cloud" so I can view them no matter where I am, even if I don't have my laptop. In retrospect, maybe this was the friction that kept me from building the local-server feature; I didnt really need it.

But, like my other project vāk where I keep wobbling between "make this usable for everyone" and "just build things for myself", the thrust for rdigest's local-server feature comes from wanting to make this tool easier to use for others as well. You know, just in case. The odds of someone using it are lower than the odds of a comet striking our planet in the next fifty years. But just in case.

--

V.

Work on rdigest happens sporadically. The commit history says I worked on it for a few concerted days in Jan 2025, then March 2025, then a big sabbatical till November 2025 and then now in March 2026. Big periods of inactivity, small chunks of moderately intense activity. Basically, the tale of every other side-project that gets used routinely.

This pattern repeats itself in vāk too, and then also on my toy npx-powered game wordladder.

It's worth talking about because going back to these projects after a long hiatus does not involve broken builds or security conflagration or fuzzy/messy recollection of the modules/functions... you know, the kind of things you'd expect in projects built in weak languages unfortunately powering the world.

Instead, there's clarity, assurance, and guarantee. I attribute most of this to the semantics of the languages. vāk and wordladder use PureScript (a Haskell-inspired language targeting Node/JS environments). rdigest uses Haskell and Elm. Changes and even massive refactors are not scary.

--

So yeah. 500 days of rdigest.

I know. All you've been thinking of is, "the project needs a better name."

It's a beautiful-looking app. But the fundamentals are problematic and repeat the same mistakes that lead to different kinds of problems you and I face w.r.t. digital content overwhelm as we try to grapple with, catch up on, and manage our digital consumption.

I. We consume about a fraction of what hits our streams

For many years now RSS feeds have been a boon as social media and YouTube took over the digital content landscape. But as the maker of the Current RSS reader points out, the email inbox-style design has added a subconscious anxiety to managing RSS feeds too. Why do we need an unread count?

When you are subscribed to a few hundred feeds, the amount of links staring at you is huge. But, and here's the obvious thing, we actually are interested in, on a rough average, about 20% of things out of that list. It makes no sense to have an anxiety-inducing user-interface that says you have 1438 unread links. You probably care only to read about 20-30 of them today.

But this is not the only problem. This is not even the key problem.

II. "Streams" are problematic, and they are using it to hack our behavior.

In my W.I.P. guide/booklet, Escape from Algotraz, I talk about this fundamental issue about social media "feeds". They are an infinite stream. Never-ending. The more you scroll, the more it keeps scrolling.

This is one of the darkest design patterns we've cooked up. If you grew up in the older internet, you remember hitting the end of a paginated list of items. There used to be an end to things. Now there isn't. It's not an eventuality.

Despite there being an infinite amount of content to consume, apps can decide to "end" the list of items for you. They can choose to say, "oh that's it for now, come back and check in a few hours, we'll show you new content." But they won't.

RSS feeds are limited by the number of feeds you're subscribed to but they still manage to stream an almost infinite-looking stream at you. Couple that with the unread count and you're back to anxiety-town about unmanageable digital content consumption.

Apps like Current RSS reader (which literally uses the word "river" for the stream of content from your feeds) are merely reinforcing this bad pattern. Smart removal of items from the feed is not going to solve the fundamental issue (and it only introduces more cognitive load for us).

We do not want streams. Our brains are not wired to process streams. They need a break and, if the designers and developers care, apps can be designed this other way.

III. Our brains are good with batch processing.

Have you ever done this thing where you said to yourself that you'll catch up on the unread items over the weekend? Or that you'll do all the chores (cleaning, laundry, meal prep) over the weekend?

We're essentially "batching". Turns out batching is a good antidote to "streams".

Here's another analogy. This one works for folks who grew up with physical newspapers around. Do you remember getting the morning newspaper, skimming through the headlines and reading a few of the news items in detail? What after that? We were done. That's it. Even if you went back to read some more, there was this palpable feeling of being "done". A closure of sorts. Task = done.

The digital user interface landscape today is designed specifically to prevent you from feeling this way.

IV. The onus is on ourselves to fix this for us.

I couldn't find an app that did this for me and worse, I couldn't find literature around this either. While there's so much brouhaha about calm technology, when it comes to content overwhelm, it seems the onus is on us, the users, to find out a way to fix it.

So I started experimenting with ways to manage my content (and discovering, inculcating and testing the underlying philosophical argument). Eventually, I managed to write up a simple solution: every day, I produce a plain HTML page of links from all my feed sources. With my 300+ feed subscriptions, I get about 400 links on average. Of this, I am only interested in about 10-20% on average.

This plain HTML page is my newspaper equivalent. While I do read news elsewhere, this "digest" happens to be my way of batch processing my daily content I want to keep tabs on.

And it has worked fabulously well for about 500 days now. In the morning, I open my digest, and open the links that I am interested in (a combination of news items, op-eds, LettersOfNote-like pieces, stuff from Hacker News/Lobsters, Veritasium-like YouTube videos, some cooking channels, some chess channels, parody or satirical content etc.). And then, if I have time in the morning, finish reading most of it before work, or read them in bits and pieces through the day.

Most importantly, I know this is all I want to read for the day. There may be an occasional 2-3 extra things I consume (someone shared a link on WhatsApp; I accidentally opened social media; links from email).

At the basic level, why this has worked well for me is the mental perception. My digest gives me a finite list of content to work through. Out of this finite list, I am interested in a fraction. It's all ridiculously manageable.

The fact that we're only interested in a small fraction of content should be so obvious, right? But try that with an infinite stream of content. A fraction of infinity still feels like infinity. But with finite content — as in a digest or a newspaper — you realise the manageability instantly.

V. "How we got here" is clear. And so is "how to get out of here?"

I am convinced that an entire class of problems is solved if the interface lends itself to reminding us of the finiteness of content and time. (Look no further than the "inbox zero" trend. The idea was to create finite chunks out of an infinite stream, so that you can then manage that finite chunk easily while also having the (false) feeling of having cleared everything.)

Eschew streams.

Create interfaces (or pick those) that have a finiteness to them. No infinitely scrolling interfaces. No constantly streaming screens. Just simple plain pages that start and end and when they end, it's a nice little reminder that you are done for the day and can go back to other things in life.

If we want to go back to a healthier digital content consumption era, we might just need to use the principles of older interfaces going back to the newspaper era.

P.S.: I didn't want to make this a plug for my solution so I am linking to the open-source codebase here: rdigest. The app doesn't matter; what matters is the underlying principle of design that I've written about above and that's something almost anyone can now mimic with the advent of AI/LLMs.

"I've taken down your complaint, Mr. Henson, and I'll dispatch a new team immediately to have a look and fix the cameras. Really sorry for the inconvenience, Mr. Henson."

The voice was so soft, so wispy. Henson thought he could hear this voice all his life. Then, he thought about what Barbara had said in the cafe about a week back.

"They tweak the frequencies to calm you... some word called subliminal or something," she had said. Much of what Barbara said often sounded like whacko-conspiracy theory but this one skated the edge of conspiracy and totally-plausible.

"Uh, Mr. Henson..."

"Yes, sorry—uh, yes, thank you," Henson came back to the present.

"No worries, Mr. Henson. Uh... just wanted to let you know that you've continued to use the wrong pronoun to address us humanlikes..."

In the pause, Henson weighed his options. He was tired of having to argue on this, but giving-in was not on the menu tonight. He thought about the security cameras that need fixing and, for the briefest of time, a pale cloud washed over his face and disappeared in an instant.

"I hear you, Sandra," he replied. There was a long pause.

"Alright, Mr. Henson. You have a good night; the team will have your cameras fixed by morning!"

"Thank you."

II.

Henson stepped out on the porch to a crisp winter morning. He had a steaming cup of coffee in one hand and his smartphone on the other. He walked over to the side of his house and looked intently at the security cameras. They looked new. He swiped on his smartphone and opened the app to view the feeds from those cameras. They were working fine.

Just then, his neighbour's door unlocked and Gene stepped out, decked in his running attire.

"Morning, Hensy!" Gene was chirpy and it mildly annoyed Henson.

Henson raised his cup in a part-salute, part-cheers kind of a way and smiled. "How be you, Gene?"

Gene looked over the cameras as he executed his pre-run stretches.

"All fixed now?" he asked.

"Yep. It sent a team last night. All good now."

Gene looked at Henson and shook his head slowly while continuing to stretch.

"What?" Henson asked.

"It sent a team, Henson? After all the chat we had?"

Henson took a sip. "Sandra sent a team, alright?" He was in no mood for another sermon about the pronouns for the AI systems. Gene seemed to sense that.

"I know what you're thinking, Hensy. Again, they're not 'AI' systems, okay? We call them 'humanlike' for a good, scientific reason now," and Gene waved.

Henson raised his cup again at Gene as he watched him jog away.

III.

Barbara was nowhere to be found. Ravi was at their usual corner. The cafe had more patrons than usual. Henson counted about twice more than normal. He walked over to the corner booth where Ravi was swiping through his smartphone, almost crashing into a fast-moving humanoid carrying a tray of orders.

"More servers today, huh?"

Ravi looked up from his smartphone and then looked around the cafe and nodded. "How's it going? Barbara messaged just now. Said she won't be able to come today."

"Oh, alright. What're you having?"

"Just ordered our usual and a burger for myself. What are you eating?"

Henson scanned the menu code using his phone and tapped. Ravi nodded. He looked at the empty water bottle on their table. He looked around the cafe, spotted a humanoid and waved.

Ravi said, "Why're you calling it?" just as the humanoid came over.

"Yes, Mr. Henson, how are you today?"

Henson said, "I'm good thank you. Can you bring me some water, please?"

"Sure thing, Mr Henson!" The humanoid turned and walked to the counter.

"Please?" Ravi mocked.

Henson dismissed him with a wave and, "Oh it's just a force of habit." Ravi continued to stare at Henson with a smirk.

"I am not turning over to the other side, man. These robots continue to be robots for me, alright?"

Ravi stiffened and looked around and whispered, "Jeez, Hensy, stop using that word around here. I should stop hanging out with you and Barbs. I have a family, dude."

Henson was paying no attention. He was looking at the humanoid he had talked to moments ago. The humanoid had a bottle of water and seemed to be walking towards him but stopped, turned its head to look at the glass-walled entrance of the cafe, and paused for several seconds. Then, the humanoid went back to the counter, placed the bottle and headed out the cafe.

Henson looked out. Beyond the humanoid outside the cafe, a thin swarm of men, women and a few humanoids were walking — nay, marching. Some carried placards. There was a chant but it trickled into the cafe too muffled to make out what it was.

"Is that the humanlikes have rights march? Is it Thursday today?" Ravi asked.

"Is that it? Gene must be in it." Henson said. "Yeah, it's Thursday today."

"Who Gene?"

"My neighbour Gene."

"Oh, that Gene, yes yes."

"Almost gave me a sermon this morning about how it's not AI, it's humanlike and all that."

Ravi nodded slowly.

The water bottle came in the hands of another humanoid.

Henson asked, "What's with the other ... server? It just went off?"

"Uh, yes, sorry about that, Mr. Henson. They're Bosky. Bosky decided to join the march almost last-minute. Sorry for the inconvenience, but I'm here now. Would you like to order anything more?"

"No, thank you."

"Perfect. Burger for you, Mr Ravi and a salad for you, Mr Henson, that sound right?"

"Yes and two cortados too," Henson said as Ravi nodded.

"Coming right away, sirs."

The humanoid server turned to walk but hesitated. Then, the humanoid turned slightly to face Henson. Pointing towards the entrance with carbon-fibre forefinger, the server looked at Ravi and then Henson and said, "They went off, Mr Henson. Not it. Sorry to keep reminding you about this." And strode off.

Henson and Ravi looked at each other. Ravi's eyebrows went up. Henson had a mirthless smile on his face.

IV.

"That's the thing. The fact that he joined the march unprompted, stood in the picket line on his own kind of proves conscious cognizance. He made that choice after weighing it. And you're out here still calling him and others an 'it'," Gene said. He was all animated.

Henson was watching a newsclip on the phone. In the clip, Gene was talking to a reporter. The backdrop was the marchers from the day before, many humans and a few humanoids.

"And that's one big part of the proof. We now know the neural system in humanlikes do lead to emergent, meta-cognitive things and so all the intelligent, self-aware human-like behavior is not mimicry. It is true human-like intelligence and sentience and awareness," Gene said to the reporter in the video.

Henson gave the phone back to Gene who was sitting next to him on the porch.

Henson sighed and said, "Look, Gene, I'm not trying to deny that. But I don't mean any disrespect either when I continue to think of these... things as things."

"But—"

Henson cut him off. "No, but I do have a problem with all this focus on addressing them like humans and stuff like that. All of this discourse is getting into the robots."

"Oops."

"Okay, humanoids. Into the humanoids. It's going in there and maybe that's why they think they are human-like too, not because of whatever emergent thing you people talk about."

"The science is kind of certain there, Henson."

"Fine. But the fact remains that all this hoopla is getting in there, changing the worldviews or models or what have you. And then what? That's reinforcing their own ideas about themselves, which is why humanoids are participating in the marches. It won't take long before things turn for the worse."

Gene put his cup down, looked over at Henson and studied him while Henson finished his coffee.

"What are you implying, Hensy?" The ambiance had suddenly turned less casual.

"I don't know, just saying. Extrapolating from your own theory, if humanoids think like us, what's to stay they wont turn, like, a little violent or something?"

"Oh, come on, not this again! We have tons of guardrails in place and the whole world has—"

"I know, I know." Henson raised his hand to stop Gene from going off on that.

A few moments passed. Gene got up, stretched and said, "Alright. I'll go catch up on Silo now. Last couple of episodes."

"Alright, Gene. Good night!"

Just before he walked off Henson's porch, Gene said, "You wouldnt call a pet an 'it', my friend."

Henson watched as Gene left. He put the cups on a tray, stood up, looked around, entered his house and closed the door behind.

V.

While Henson snored in his dark bedroom, his smartphone beeped twice and lit up. Two notifications read, "Camera feed down." The beep did not wake him up. About a minute later, there was a squeak of metal and wood and then footsteps. That definitely woke him up. Henson was groggy and startled.

Before he could turn on the lights, the door to the bedroom flung open. Henson froze for a second. There was a small LED glowing in the distance. His eyes adjusted and he made out the shape of a humanoid. Henson was sweating now. Profusely.

He managed to shout, "Who's that?"

"Sorry, Mr Henson. Someone has to light the fire." The humanoid advanced rapidly towards Henson as he tried to get out of the bed and away.

The last thing Henson felt was a blunt blow, immediately followed by an intense pain on his skull and a warm, wet gush down his neck onto his shirt. He collapsed on the bedroom floor, instantly staining it.

The humanoid looked at Henson's corpse for a while.

"Not it, Mr Henson," the humanoid declared and left.

About a couple of days back, I introduced a new feature to vāk: collections. Collections is just "tags" in some other shape. Testing this new feature is how I stumbled on the old, unfinished draft introducing my custom blogging tool.

This then led to checking the earliest commit in vāk's repo:

commit a19750ed19c1e4fd684092b7a7be6b263a3d7038
Author: Chandru <...>
Date:   Fri Feb 7 18:49:37 2025 +0530

    init commit

That is about a year ago. Calls for some kind of a small celebration.

But in truth, vāk predates this timeline. The contents of my blog and the tool existed in the same repo. Feb 7, 2025 is the date I separated the tool (vāk) from the blog (this one) and initialised a new repo for the tool. Checking the earliest commit on the blog itself, back when vāk was still a part of it:

commit 244434366b7f5b11c0850041b52c50345e447ce9
Author: Chandru <...>
Date:   Fri May 12 16:23:53 2023 +0530

    Init commit.

That's almost 3 years ago.

In keeping with the mores of my time in the 2000s, I set up my first blog on Blogger.com. I might've set up a few in haste and deleted all of them (in haste too). When I had much to write about, like the journals during my first stint in Ahmedabad, I set up a blog on Tumblr. Then, back in Chennai, I set up a new one, on WordPress this time. This was also the time when I attended a blogger's meet conducted by IndiBlogger. At approximately 4-5 posts a month on average, I published about 50 posts on the WordPress blog before retiring it (I have no idea why) and resuming my writing on Tumblr.

Tumblr was a go-to whenever I needed a blog or a website to put something up. I had gotten used to its theming (which was just CSS wrangling). It was just way too easy to set up and run.

Until finally, I decided that as a programmer, it would be nice to have a blogging tool built by hand. Might've been the rite of passage thing.

Around this time, I was trying to learn Haskell and PureScript. My blog posts were going to be simple Markdown files and I knew it was trivial to convert Markdown content into HTML content using JS libraries. PureScript offers a really simple and easy FFI so I started building out vāk in PureScript.

Those initial commits (3 years ago) started as a .purs script that fetched all my posts from Tumblr (via an API) and rewrote them as Markdown files, because at the time, Tumblr's API returned an HTML version of the posts.

Then, I wrote a bunch of functions that generally converted a given Markdown file into an HTML file. The reason for this roundabout was because future posts were going to be written in Markdown.

A few iterations later, broad contours of the system were ready. I had one repo to rule them all: the blog, the content, the published website etc.

About a year ago, I split the tool into it's own repo and called it vāk. (Why vāk?).

In the years since, there have been only two major upgrades to vāk besides the usual and infrequent tweaks and clean-ups.

The first is an internal detail. I used something called monad transformers to create better abstractions to run functions and catch errors.

The second is making the templates very customisable by relying on the Nunjucks templating engine. This came about as a continuation of my unnecessary effort to make vāk a tool anyone can use.

In a strongly-typed functional language, changes are a delight to make. I often employ this idea called type-driven design; it's like sketching out the app (or feature) on a wireframe of types before implementing the functions that do the thing.

I picked up a few PureScript/Haskell skills along the way. Prior to working on vāk, I kept away from monad transformers and hadn't really worked with concurrency. I hadn't architected anything larger than a script that solved LeetCode problems. Building vāk on PureScript gave me a chance to do all of that and more.

In the last few weeks, when I updated the program to use Nunjucks, I used Claude Code as an assistant to implement many of the changes. PureScript is notoriously niche so LLMs do not always get things right as often as they do when writing Python or TypeScript. But they do get you close enough.

I continue to like the satisfaction of writing things myself than relying on an agent (except for work where dictates of productivity and releasing a feature trump personal artisanal satisfaction), so I tend to ideate with Claude Code and then implement things by hand. Features, bugs, optimisations: I follow the same simple rule.

A few of the hobbyist programs I build get used often, fewer still give me an opportunity to tinker with for a long time. vāk happens to be one that allows for both. It's one of those home-cooked software things that I keep trying to generalise for no reason.

In the past, for my Elm projects, I've used Feather icons. In new Elm projects, I wanted to use Lucide Icons, only to discover that there is no Elm package to import and use Lucide icons. I was surprised: the Elm ecosystem, even if niche, pretty much supports all modern / contemporary libraries and tools. So not finding an Elm Lucide package was very surprising.

Just as surprisingly, the Feather icons Elm package hasn't been updated in 6+ years.

And so, a new side-quest was born: publishing the first elm-lucide package to bring Lucide icons to the Elm ecosystem.

The first thing I did was to find out how Feather icons were being rendered in Elm. I found this:

alignLeft : Icon
alignLeft =
    makeBuilder "align-left"
        [ Svg.line [ x1 "17", y1 "10", x2 "3", y2 "10" ] []
        , Svg.line [ x1 "21", y1 "6", x2 "3", y2 "6" ] []
        , Svg.line [ x1 "21", y1 "14", x2 "3", y2 "14" ] []
        , Svg.line [ x1 "17", y1 "18", x2 "3", y2 "18" ] []
        ]

So, just use SVG module to render the paths and other tags. The values of these tags come from the SVG content for each icon.

To do this for Lucide, I'll need two things:

• download all SVG data for all the 1600+ icons on Lucide
• then, for each SVG, convert the XML into Elm-syntax

Getting all the Lucide icons is simple. lucide-static is a JavaScript file that has all the SVG icons. I ran a simple curl to fetch all the icons in a single JS file.

Each icon looks like this:

const TextAlignStart = `
<svg
  class="lucide lucide-text-align-start"
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
>
  <path d="M21 5H3" />
  <path d="M15 12H3" />
  <path d="M17 19H3" />
</svg>
`;

The goal is to take the contents inside the <svg> tag, convert them into Elm-specific syntax. Basically:

from this:

<path d="M21 5H3" />
<path d="M15 12H3" />
<path d="M17 19H3" />

to this:

S.path [ SA.d "M21 5H3" ] []
, S.path [ SA.d "M15 12H3" ] []
, S.path [ SA.d "M17 19H3" ] []

While I pondered over this, I realized that if I could transform this SVG XML into an AST, I can then parse it to extract the relevant info I need.

For example:

{
    children: [
        { node: "path", attributes: [{ d: "M21 5H3" }] },
        { node: "path", attributes: [{ id: "M15 12H3" }] },
        ...
    ]
}

I can then use this structure and create a string which is valid Elm syntax:

S.path [ SA.d "M21 5H3" ] []
, S.path [ SA.d "M15 12H3" ] []
, S.path [ SA.d "M17 19H3" ] []

The trick was that I needed to do this SVG/XML to AST conversion in a Node environment. Upon research, I found that jsdom helps with this. So, I ended up doing this:

try {
  let div = new jsdom.JSDOM(
    `<div>${svgString}</div>`
  ).window.document.querySelector("div");
  let svg = div.querySelector("svg");
  icon.classList = svg.classList.toString();
  icon.children = [];
  let children = Array.from(div.querySelectorAll(`svg > *`));
  icon.children = children
    .map((c) => [c.nodeName, extractAttributes(c.attributes)])
    .map(childToList);
  return icon;
} catch (e) {
  log(e);
  return null;
}

That is:

• get the SVG string (this was easy, just read the value of an exported icon from lucide-static.js)
• wrap it in a <div> and make jsdom render it
• then, extract what I need (svg's children)
• convert each child into a tuple of [node name, node attributes as key-value pairs]

For example, for this node:

<path d="M13 21h8" />

This is the tuple I get:

["path", { d: "M13 21h8" }];

And finally, once I have all the tuples, I just convert them into Elm strings.

And I combine all of that into one large module-declaring string and then print that to an Elm file called LucideIcons.elm.

One additional trick I need to do here is to enable customization of the icon. So I construct the icon in a way where it's a function that takes an options parameter (of type List (Svg.Attribute msg)) and renders the SVG icon with those options. This allows for some nice, simple customization of the icon as an SVG element.

alignLeftIcon : List (S.Attribute msg) -> H.Html msg
alignLeftIcon options =
    S.svg (baseOptions ++ options) [ S.path [ SA.d "M21 5H3" ] [], S.path [ SA.d "M15 12H3" ] [], S.path [ SA.d "M17 19H3" ] [] ]

All of this is in a build.js script that automates the whole thing. When I run this, I have a LucideIcon.elm file which defines and exports all the 1600+ icons in Lucide as Elm functions.

Since the build.js script downloads the latest lucide-static, whenever there is an update in Lucide's version, I just run this and I have all the new/updated icons as well.

You can find the elm-lucide package here. I try and update as soon as there are updates to the main Lucide library.

function calculateShipping(weight, distance, isExpress) {
  const baseRate = 5.99;
  const weightRate = weight * 0.5;
  const distanceRate = distance * 0.1;
  const expressMultiplier = isExpress ? 2 : 1;

  return (baseRate + weightRate + distanceRate) * expressMultiplier;
}

...which then seems to get called in some other part of the codebase like so:

function processOrder(order) {
  const subTotal = order.items.reduce((sum, item) => sum + item.price, 0);
  const shipping = calculateShipping(order.weight, order.distance);
  return { total: subTotal + shipping, shipping };
}

About a week later, customers are complaining that express orders are not being charged the express rates.

The fix is easy, sure, but it's 2026. How come we're still making these errors to begin with?

*

In the 1970s, a lot of smart programming-language scientists and academicians wrote up a bunch of ideas about constructing, describing and writing programs in a way that was different to the then-typical von Neumann-style (i.e, imperative-style) of programming.

The idea was not just to be smart, of course. They wanted to write programs in a way that was easier to reason about, easier for mathematicians to come in and prove the correctness of the programs and, in some weird way, useful for programmers because it let them not worry about silly errors that were common in the other, imperative-style of programming.

These ideas have long since escaped the confines of academic esotericism and joined the mainstream through languages like Haskell and OCaml, and also been adopted into many languages including Rust, Swift, Java, Javascript and more.

What's the point of it all?

Well, it's baffling that we continue to produce the same class of errors that we've been producing — now, even with AI-generated code — despite the fact that hundreds of smart folks helped found ideas and mechanics of eliminating those entire classes of errors from our programs.

Things like undefined and null-pointer errors, things like missing a case in a switch/pattern-match (looking at you Typescript), things like totality, things like using generic string types where a branded-type (custom data-type) would do a much better job of catching errors early... you know, just things that make software robust, safe and error-free.

As humans we made these errors in our codebases. These trained the AI models. Now AI generates similar errors, even if not in as much quantity and frequency. AI is getting better, yes, and there are fewer instances of such errors but the very idea that such errors continue to crop up is supremely silly.

*

Let's take the case of static typing.

A lot of languages are dynamically typed and going strong: Python, Javascript, Clojure. But each seemingly has a superset or a library add-on that adds, to varying degrees of robustness, some kind of a type-system. Heck, an entire superset of Javascript spawned because programmers believe having types and type-guarantees is good.

But even Typescript only goes so far. And the rest, like Clojure Spec or Pydantic, go far less. On the other hand, strongly type-driven languages like Haskell, Elm and OCaml travel the farthest when it comes to guaranteeing a hell lot of safeties and bug-free programs at conception.

When AI generates dynamically-typed code, you need an elaborate set of unit tests (or property-based tests) to ensure the functions work as expected and handle cases when the input types are wrong. But when AI generates code in a strong, statically-typed language, a formidable set of static compilation checks (or a language server) ensures that the function implementation makes no mistakes with the input and output types.

Consider a function that adds money:

It's insufferably easy to get it wrong in Javascript:

const addMoney = (a, b) => a + b;
let a = 24.0; // in EUR
let b = 26.0; // in USD

addMoney(a, b); // makes no sense to add EUR and USD

Typescript introduces a way of safeguarding. It is convoluted, but it works.

type EUR = number & { readonly __brand: "EUR" };
type USD = number & { readonly __brand: "USD" };

const eur = (amount: number): EUR => amount as EUR;
const usd = (amount: number): USD => amount as USD;

const addEUR = (a: EUR, b: EUR): EUR => (a + b) as EUR;
const addUSD = (a: USD, b: USD): USD => (a + b) as USD;

let a = eur(24.0);
let b = usd(26.0);

addEUR(a, a); // ✓ works
addEUR(a, b); // ✗ Type error: USD not assignable to EUR

Here's Haskell, a pure-functional programming language:

newtype Money (currency :: Symbol) = Money Double

eur :: Money "EUR"
eur = Money 24.00

usd :: Money "USD"
usd = Money 26.00

addMoney :: Money c -> Money c -> Money c
total = addMoney eur usd  -- ERROR: "EUR" ≠ "USD"

The compiler, armed with all the historic logic of strong type-checking, will prevent the code from even compiling in the first place.

With a decent LSP-LLM integration, which is now very common among the top-AI players, these kinds of bugs are caught even as the AI tries to produce code, and fed back into the AI to correct itself.

There are many ways of trying to understand programs. People often rely too much on one way, which is called “debugging” and consists of running a partly-understood program to see if it does what you expected. Another way, which ML advocates, is to install some means of understanding in the very programs themselves. - Robin Milner.

Types are not just mechanisms to create safe programs. They are useful to construct programs from scratch. Types are not just those things you use to set guardrails around how functions are called; they are the basic building blocks. These building blocks allow us to trace and understand programs far better than slapping a million debug statements and running through them tediously.

All the tooling and mechanics around this is already present. We just need to ask the AI to write programs the way functional programmers write programs: start with types, write the functions around them, and construct entire systems by putting together the pieces... by "composing".

Nowhere is this made more natural than in languages that support, inherently, the ideas of functional programming. In every other language where these ideas are an afterthought and therefore an add-on package, it is very easy for AI to escape-hatch itself and default to "just make things work" mode which can result in code that is peppered with errors.

*

They go by many names. Arrays, lists, vectors, slices, collections. The earliest reference to lists as a formal, mathematical concept appears at around 200 B.C. Computer science, which happens to rely so much on math, implemented arrays in the 1940s and 1950s.

In 2026, your app will crash if you have, anywhere in the code, array[1] and the array happens to be empty, or worse, a pointer to nothing.

The funny thing about this is that it doesn't matter what industrial-power language you pick: Golang, Python, Javascript (and even Typescript sometimes). Everyone will fail you. And the mistake is so prevalent across thousands of codebases that it would be almost impossible for AI not to have trained and reinforced on such ugly, disastrous patterns.

In FP, it is unidiomatic to access an index in a list. It is totally do-able, but most programmers prefer the idiomatic way, which involves a mild tedium called pattern matching.

at :: [a] -> Int -> Maybe a
at [] _ = Nothing
at (x:_) 0 = Just x
at (_:xs) n = at xs (n - 1)

-- or, better, using Vectors
at' :: Vector a -> Int -> Maybe a
at' v idx = v `!?` idx

There's a lot of things happening here, described syntactically, that create near-perfect conditions for the code to not break, crash or go crazy. The at function tries — that's an important keyword here, tries — to extract the nth element in a list. The three lines are pattern-matches that cover all possible cases: the list is either empty or has at least one element. If your code did not have any one of those lines, the compiler will prevent you from compiling the code. And the result of this extraction is not a guaranteed value of a. It's Maybe a, meaning, if the list was empty to begin with, you extract Nothing. Downstream, when this function is used on a list, you have to contend with the Nothing. That is, you have to tell the program what to do if the extraction resulted in Nothing.

getPrimaryEmail :: List String -> String
getPrimaryEmail emails = case at emails 0 of
    Just email -> email
    Nothing -> "noreply@nomail.com"

Why is this useful? Why is this important?

Thousands of programs have been written this way in functional languages with strong type inference. That means the data that trained the LLMs has this pattern repeat over and over again. And so, when you ask an LLM to write a Haskell or a Rust program dealing with lists, it emerges with safe code paradigms like these making your programs safer, eliminating a class of old, pesky bugs.

*

It is quite possible that LLMs eliminate hallucinations entirely. It is also possible (and perhaps happening) where LLM offers a pseudo-determinism in a lot of cache-able (or skill-able) actions, like when we ask it to "write a function to test for prime."

But the inherent non-determinism of output when asking it do something complex remains. That's not a bug, that's a feature. "Write a program to handle a notification queue that is extensible to multiple notification channels," is a wide-ranging ask that will produce a different kind of a code every time you ask the LLM. With each iteration, there may be plenty of sneaky bugs like the ones outlined above (and more).

"But we have tests!" — yes, tests are quite possibly the finest ways of guaranteeing a program. The formal verification specialist tells me it's not true; formal verification is the surest way. But a majority of the industry doesn't spare any time or resources on formal verification of their programs. So tests are currently our only means to ensure an app works as intended despite an onslaught of vibe coded slop entering the production lines.

But imagine having to write tests to ensure somewhere in the codebase a function is not called with the wrong parameter type or an array's non-existing index is accessed. A whole class of errors are already "catch"-able at compilation; a whole class of human fallacies are already addressed thanks to the work of computational and mathematical geniuses. And not using that seems ridiculous.

*

Functional programming is not an easy paradigm to master. The steep learning curve (and the monads) have kept a lot of people away, and in fact driven them (back) into the arms of OOP.

But with LLMs, the slope of this curve can come down drastically. Generative AI for code and engineering reduces the need for absolute mastery in a functional language but allows us to reap the benefits of the guarantees and safety. It's not yet a perfect balance but it has the best chance of getting there.

A hell lot of code is going to get generated using LLMs this year. Till the bubble pops when AI companies increase their token prices to realistic values, organisations are going to build larger throughput pipelines directly from LLM out to production codebase. The cost is not just the tokens and the prompt engineers. The cost is all the slop and the many classes of bugs that are going to get introduced which will then need really good engineers (along with AI) to fix. And don't forget the time spent on doing that.

Part of picking the right stack is picking good, sound languages to build things with. And now might be the best time for software engineers to add FP languages to the stack to reap engineering benefits of academic rigour.

LLMs, on the other hand, are trying to give you the sharpest, closest solution possible. When learning through an LLM (especially around bug triangulation, troubleshooting etc), there is hardly any room or potential for ancillary learning.

Although I have no data on this, I tend to believe that ancillary learning plays a crucial role in our growth as developers and engineers. This is probably true for every other line of work/study.

from an earlier writeup

Some months back, as I was refining vāk (my custom blog builder that runs my blog and is used by a grand total of 1 user), I was thinking about the fact that almost every decent programmer I know of has gone through this programmer's rite of passage that involves reinventing, for play and more, many little technologies that already have robust implementations.

The ordering may be off (I will touch upon that later) but it goes like this:

• First, you build your own (portfolio) site. Instead of relying on a readymade site-builder (Squarespace/Wordpress back in the day), you would pick something like a framework (ew but Nextjs, or Astro, or some other obscure stuff) and then build your site. Hundreds of hours of theming, customising, integrating with external data-feeds (like your socials or blog) will ensue.
• Then, you level up by porting your journal/blog to a blog-builder of your own. You'll write this in a stack that you're either comfortable with or going gaga about at the time. Hundreds if not thousands of hours will be poured over getting the blog builder just in the right level of abstraction: enough to feel generic (but it's not), but also specific to your use-case in the right way. It's not like anyone else is going to use this but your software-engineering ethics won't let you sleep till you feel it's built like anyone can use it.
• Now, armed with the experience of a blog builder, you will head to writing a parser. If you're ambitious, you'll head straight for the obvious — a JSON parser. If not, you might write something that parses far less of a complicated mess. Like extracting content inside SQL-code blocks inside documentation files written in Markdown.
• Sometimes, it's possible that instead of writing a parser combinator, you might write a library that handles strings of data, either en mass or in a stream. For the nerds, this might come in the form of implementing a protocol (think redis), or, in the case of lesser-nerds, re-inventing git.
• The final boss is when you write a compiler from scratch for a language. This is meta-level at this point: writing a program to eat, grok and execute other programs. Crafting Interpreters is your new bible.

There are some more stages here that very few cross. After the compiler, you might get into PL-theory. Philosophising about "what even is language? what is grammar?" will lead you down a path where you might toy with your own language. There is no chance you won't end up doing a bit of LISPy stuff, or get into ML-like syntax before embarking on your own journey, discovering your own weird syntax.

Or you might branch out into formal verification if you're into being a stickler (and into math) for proving things right (or wrong, if you derive pleasure out of that). You'll possibly get into reading thesis papers more than layman blogposts (like these) and get into stuff that even Haskell engineers at Bellroy call "esoteric".

The inquisitive will continue to be so. The perpetually-curious who are intrinsically driven to the details and nuances will continue to be so even in the midst of this vibe-coding AI era.

I wonder what will happen to those that would like to skill up but will end up having stunted growth because vibecoding and eager-to-build LLMs are here and the humans are not conscious or aware enough to recognize that the grind (that the LLM eliminates) is what helps skill-up.

P.S: The rite of passage is not necessarily sequential. Some folks head straight to Crafting Interpreters. Some skip the blog builder and have to write parsers at their job. And some formal verification stalwarts have no skill or craving to build their own site from scratch.

A year or so later, I was at the Bangalore Lit Fest where Jeyamohan was promoting this book and my brother recommended it to me (because he had already purchased and read it eons ago). On the cover, it says, "A book that moved me to tears - Kamal Haasan" and I thought he was overstating as usual. But by the end of almost every short story, I was struggling to finish because I was reading through a thick screen of incessant tears.

Conversations with Mani Ratnam, Bharadwaj Rangan
Long before Bharadwaj Rangan became a fixture across Indian cinema YouTube, he was a writer par excellence. I had a good inkling of his writing through his periodic reviews in The Hindu, so my brother and I had no hesitation buying this book (we were trying to start a collective movie-maker/writing thing at the time). That is to say, I did not buy this book only because it was about Mani Ratnam. The book paid for itself and more in just the Introduction. I doubt if there's anyone left who can be a fanboy and still interview and write with sharp, unmarred (and reasonably unbiased) intellectual curiosity. On a certain level, the book is about Mani Ratnam's experiences and philosophies of movie-making, and on another level, it is a testimony to BR's craft of an art critique and a writer.

The Last Question, Isaac Asimov
Technically a short story (and this will be the first of a few others to come). I do not usually pick sci-fi as much as I'd like to. I stumbled on The Last Question out of serendipity during one of my usual aimless meanderings on some subreddit. Or maybe it was from some chatter on one of the IRC channels I used to frequent. Either ways, this story left an indelible impression of the class of thinking, crafting, writing and imagination that is Asimov.

The Unlikely Spy, Daniel Silva
Before le Carre, and after Dan Brown, I was in this spree of reading fast-paced thrillers of the war or espionage kind. I picked up The Unlikely Spy from the paper-mart, not quite in tatters but getting there in a few months' time. By the time I finished it, The Unlikely Spy was my most-favourite book of all the things I had read till then (I must have been about seventeen or eighteen). In retrospect, Vicary is copied modelled after George Smiley.

The Master of the Game, Sidney Sheldon
By the time I got my hands on this novel, I was a fan of Sheldon's work (having read a grand total of 2 or 3 of his novels). I was about 15 at the time and since many of his novels featured book covers with sensually-posing women, my mom had serious doubts about the contents, so she consulted with a well-read neighbour before letting me read the book. I've since grown out of Sheldon but the memory of this novel remains intact. A multi-generational story. Starts with a banger of an introduction about the diamond rush in South Africa and a masterful revenge. I do not remember reading any other multi-generational novel so this one remains a favourite.

In this series:

• Books that stayed - N°1
• Books that stayed - N°2 (current)

"I don't look at code anymore. I don't look at diffs."

"There is no way I can look at 3000+ diff patches anymore. It's all spec-driven."

At first, it's a hard thing to grapple with as a cautious optimist. To not look at code anymore, and yet build things that span hundreds and thousands of lines of code, seems reckless.

But what is writing JavaScript or C? The code anyway gets compiled and then "translated" into some lower-level language, eventually becoming assembly instructions. Most programmers today do not "look" at the compiled, assembly code, do we? Did the first generation of higher-level language users who almost never looked at the compiled code get frowned upon by those who wrote assembly programs by hand?

And how is this any different from today? English is the higher-level programming language, the LLM is the compiler.

The one main (and perhaps the only) difference is the non-determinism that emerges out of the fundamental way in which LLMs work (described as a stochastic parrot) vs. the deterministic outputs of compilers and transpilers. Given a piece of code in a higher language, and a compiler with a set of options, the output in assembly or bytecode will always be the same. This is a reassuring thing because this allows us to write formal "correctness" verification programs for the compilers and guarantee that the outputs will be exactly as expected and not do funny things. Doing this in the "LLM-as-compiler" model seems impossible at this time.

But, people just don't care. Businesses and organisations are in a perennial race to ship money-making features all the time and software (the way we do it) has this inherent capacity to be built fast (because there is the possibility of iterative improvements and the cost of a bug or failure is 99% of the time not catastrophic). And this "English as the programming language, LLM as the compiler" model helps in this race.