Intro on Pradeep Roark

LLM's overuse of certain words

Sat, 15 Aug 2026 19:53:31 +0000

LLM’s overuse certain words in their conversations, each model has its favourite, but claude’s favourite one is “load-bearing”. It is as if it wants to be taken seriously or has “pondered” the problem deeply (it may or may not have) but wants to sound useful. It constantly prefixes “load-bearing” when you reframe a conversation or when presenting a conclusion. One wonders from where it got that. Did someone make it say that. possible but less plausible. LLMs are instructed to think before answering and various other micro-instructions to double check its reasoning. All this does it does a token emission phase where it generates tokens relevant to the conversation at hand “without” presenting it to the user. this mere act of recollecting all relevant words relevant to context framed under “think deeply”, “critically analyse” etc.seem to be linked 🔗 closely in layers to words like “load-bearing” making it repeat it.

There is still a small chance that someone instructed it to use the prefix “load-bearing” when presenting conclusions. Either way very annoying.

Code as an "artifact". Means to an end?

Sat, 15 Aug 2026 19:30:46 +0000

Agentic LLM's have changed what "code" means. It used be the end product of the software engineering lifecycle is "code" 📜 and there are purported arguments claiming that it is no more as LLM's themselves write "code". What remains is the spec as the "code" can be regenerated in N number of ways on demand. 🔨

Does that mean "code" is irrelevant and as long as you have a golden spec to derive "machine instructions"? As mused over by Elon Musk

This is exactly right. Source code is on the verge of becoming like assembly.

The next step is getting rid of “source code” entirely and just making an efficient binary directly with AI. https://t.co/g004yjMF95
— Elon Musk (@elonmusk) August 3, 2026

But this is semantics, if you move programming into LLMS, then your instructions/prompt and context become the "code". Yes, one higher level of abstraction but still "code". Traditional programming languages MIGHT need to change to accept this new paradigm properly though but I don't think they are going away. Programming languages exist for a different purpose, to reduce ambiguity in "specification" in natural language. "English" is a notoriously ambiguous language and you need vast amount of context to interpret what is said. Programming languages have been trying to bridge this by reducing the language surface to smaller more semantically well understood bits so there is no ambiguity when it comes to execution of the code.

So in short programming languages are not going away, unless you are willing to "interpretation" of specs "over time" as acceptable.

P.S I do think LLMs can be trivially made to generate binaries, but what you "assert" that the "binary" will do depends still on "code" albeit at a higher level 👼

LLMs - The confident bullshitter

Sat, 15 Aug 2026 18:46:38 +0000

LLMs are confident bullshitters. They speak “things” with a quite confident voice. But “things” are mostly word salad with looks quite like the answer but not entirely. In order to coax them to be useful you need to constantly refine their context i.e what they have seen recently to pull something more meaningful.

Memory and Intelligence in LLM

Wed, 13 May 2026 09:30:52 +0000

Intelligence as shown by LLMs is interesting.

Here by memory I mean “context window size” though they are not equivalent.

And by “Intelligence” I don’t mean human intelligence which jumps into metaphysical debates. Perhaps “cognitive ability” to solve a task at hand is reasonable narrow definition.

At the advent of LLMs the available “context window”for an LLM was limited and took the longest to scale. This led to real funny problems when LLMs were tasked with long running conversations or fed documents that ate up their context window. Half way through implementation they forgot key details discussed earlier or declared partially complete tasks as 💯 done.

Gemini which was the first to introduce longer contexts actually fared poorly . The longer context simply led to “dilution” of attention to key details. And meandering.

Claude Opus though appears to have nailed it . The longer context helps it keep long running sessions on track with all the important learnings in “focus”. I suspect this is due to the nifty feature where it constantly does mini summaries called “Insights” and recaps within a session.

This feature pares beautifully with my pensieve Claude plugin for even longer running projects.

Agentic Scratch Memory using Pensieve

Sat, 22 Nov 2025 17:00:00 +0000

Agentic coding is a phenomenal experience. I’ve been working with AI coding agents for a year now, primarily using Claude Code after trying a variety of models. But there’s one well-known problem — they have a ‘context window’ - a limited memory area for what they’re holding in their ‘agentic minds’. Context is nearly everything because it guides them to approach the task from the proper perspective and captures the small details that wire projects together, keeping the process focused and relevant.

What constitutes context? It could be the code already written, high-level architectural ideas, pitfalls to avoid, or observations about the domain the problem is trying to solve. “Code” alone does not capture everything. My earlier approach was to write extensive specs and capture them as docs, which I had to constantly reference when working on a task. It wasn’t scaling, and it wasn’t enough. The agents frequently forgot key details I had decided were essential and wrote docs on, but they weren’t always bringing that knowledge to bear… creating weird spaghetti. Spaghetti that solved the problem at hand but was inconsistent with earlier pieces. I solved most of this by following rigid structures (like templates) for different parts of the codebase, which nearly solved the inconsistency issue, but not entirely.

Depending on the programming stack you use, there’s still information loss about the domain under consideration unless you meticulously document it in the project. The agent wasn’t really “learning”. This is not a meta discussion about what “learning” is and whether they really do. My insight was that they lack “knowledge” - the kind we bring to bear when we learn a codebase and the domain it’s operating in — the little trickles of insights gained that turn into a knowledge repository. What they needed was a way to build this “knowledge” themselves, through working on a project, and to bring it to bear on the problem at hand.

How did I solve this without agents before? The answer was actually so simple. I used structured notes - a scratchpad filled with entries about different aspects of the codebase or domain. For example, I documented data flow, persistence methods, and design choices-things that happen all the time in artisan coding . These notes acted as a personal memory aid, helping me recall critical details quickly and consistently during development.

But what do I mean by structured notes? You need to distinguish between free-form writing and structured writing. Free-form writing about a problem solved in a project would be like a couple of paragraphs explaining what was solved. But depending upon how good you are at keeping all relevant details, the free-form approach becomes lossy and inconsistent. So I follow a system where I design a template for each type of learning that I have. For instance, a “problem solved” template might capture the problem, the root cause, and what was learned. Or a “design principles” template might have fields for the principle itself (limited to 150 characters), the rationale behind it, and what anti-pattern it prevents. The template forces me to list the relevant details. And I design little templates to use for other things, like “patterns discovered” or “workarounds learned”. These are, by necessity, brief and distinct from project-level documentation. Having a structure enhances consistency and makes the gathered knowledge really valuable.

Now, how do I make the agents follow such a system? Define templates, and use them whenever the context dictates, preferably in a seamless way… like when I think and jot them down.

Enter Pensieve, a scratchpad for AI agents to use - a command-line interface (CLI) tool that agents can use to define templates and record notes in them and recall them as needed. Agents are very good at using CLI-based tools, and they automatically discovered how to use them with a little prompting. The agents designed templates in collaboration with me for each project I was working on and started filling them in as we tackled tasks together. And slowly, as we started new sessions, the agent started recollecting past learnings, informing the task at hand and making it more guided and precise than before. You no longer needed to yell the same information over and over.

But why exactly is this better than using CLAUDE.md or docs in the repo? It is because they are unstructured and the agents follow those instructions in an inconsistent manner. The more you have in this memory, the less likely the agent is going to find it and use it. Also, without specifying limits the agents generated verbose pointless documentation which they themselves did not follow. By forcing the agents to create structured notes with well-defined fields and LIMITING the length of them as needed, more disciplined knowledge capture happened.

Besides templates, Pensieve also encourages agents to link entries with each other. Nothing is lost forever — a note can be “augmented,” “superseded,” or “deprecated” by another note. In most cases this is sufficient, and the agent is encouraged to follow these links when inspecting a note. This allows the agent to crawl through memory AS NEEDED for the task at hand, digging deeper and deeper into memory, building a “graph of sorts” in its agentic mind.

You can check out demos of how an agent uses it. There’s also a standalone version of the CLI tool available, and if you’re using Claude Code, you can install it as a plugin from the Cittamaya marketplace.

✨

TodoMVC using HTMX, Hyperscript and Python Flask

Sun, 24 Dec 2023 10:55:49 +0000

This post evaluates HTMX, a simple framework that uses attributes to enhance HTML with SPA behaviours. Instead of a full-blown javascript framework, it progressively enhances plain HTML to build capabilities. Better articles have been written on why.

We will focus on IF it helps bring SPA-like behaviour intuitively without JavaScript fatigue.

We are going to use TodoMVC as a reference implementation, which has a simple spec and various implementations to compare frontend frameworks, which are predominantly in Javascript/Typescript.

To begin with, I just took the todo-mvc template and modified it progressively to add features with care taken to preserve the original HTML. We use simple requests/responses and return HTML fragments as views to the front end, and HTMX takes care of patching them into the DOM where we target it. No page refreshes are needed, hence the SPA behaviour minus the gluttony of javascript frameworks and the associated build-the-world tooling they bring.

This involved splitting the HTML into small templates, which we can return as fragments from our server. The TODOMVC app has key components of an <input/> to capture new TODOS and an unordered list of list items <li/> to represent them. The <li/> themselves are CRUD enabled, which allows them to be edited/deleted.

Fetching new todos is as simple as using an attribute hx-get and pointing to your endpoint, which returns plain HTML.

<ul class="todo-list" hx-get="/todos" hx-trigger="load"></ul>

Easy to read and understand. On a load of the element, get a list of todos from /todos, which returns,

<li>TODO1</li>
<li>TODO2</li>

which is automatically spliced into our todolist <ul> as children

<!-- ASSEMBLED DOM -->

<ul class="todo-list" hx-get="/todos" hx-trigger="load">
    <li>TODO1</li>
    <li>TODO2</li>
</ul>

Enhancing <li/> items to support Read, Update, Delete involves decorating them with attributes as so,

Read - Render the value of the todo in the template tag {{ todo.label }}
Update - On exiting the input box on blur or on pressing enter (2 triggers), call POST to update the todo
Delete - on delete link clicked, issue DELETE and will remove the list element automatically on success.
Toggle between edit mode - This one was tricky as the mode switch happens in CSS by changing the class name. We track the state of the editmode on the server and return the whole <li/> element on dblclick. This felt unnecessary. Later, with hyperscript, I will show how easy it is to implement this on the client side.

<li id="list-item-{{todo.id}}" 
    class="{{"completed" if todo.status}} {{"editing" if todo.editMode}} {{"notEditing" if not todo.editMode }}"  
    hx-get="/editTodo/{{todo.id}}" 
    hx-trigger="dblclick" 
    hx-swap="outerHTML" hx-target="this"> <!-- TOGGLE EDIT MODE -->
    <div class="view">
        <input class="toggle" type="checkbox" {{'checked' if todo.status}} 
            hx-post="/toggleStatus/{{ todo.id }}" 
            hx-swap="outerHTML" 
            hx-target="#list-item-{{todo.id}}"> <!-- TOGGLE TODO STATUS -->
        <label><span id="todo-label" >{{ todo.label }} <!-- READ: FETCH AND DISPLAY TODO STATUS --></span></label>
        <button class="destroy" hx-delete="/deleteTodo/{{todo.id}}"><!-- DELETE TODO --></button>
    </div>
    <input name="edit-todo" class="edit" value="{{ todo.label }}" 
    hx-trigger="keyup[keyCode==13], blur" 
    hx-post="/updateTodo/{{ todo.id }}" > <!-- UPDATE TODO -->
</li>

Behind the scenes - Server Side

A brief note on the server side implemented here in Python using Flask, a minimal web server. There is nothing much to be noted here. The server can be anything that can serve plain HTML. The prototype’s logic surrounding the todo state management is implemented in a simple Python style with templates serving the results. The todos and the editor state are tracked in session cookies (default flask implementation). This is a deviation from the TODOMVC specification, which requests it to be stored in local storage. This idea of where the state should be held is a good decision point in choosing HTMX.

Example of how state is defined and implementation of clear completed feature which clears all todos that are status complete (True)

@dataclass
class Todo:
    id: str
    label: str
    status: bool
    editMode: bool

@dataclass
class State:
    currentStatusFilter: str
    hideSection: bool
    tobeCompletedCount: int
    clearCompleted: bool
    selectedIndex: typing.Union[int, None]

@app.route("/clearCompleted", methods=['POST'])
def clearCompleted():
    currentState, todos = getState()
    clearedTodos = [todo for todo in todos if not todo.status]
    updateState(currentState, clearedTodos)
    return getTodos("All")

The full implementation can be found in app.py.

Hyperscript

My initial attempt was to get away as much as I could without using any JavaScript, but there are a few features that scripting can solve elegantly. Luckily, HTMX is well paired with a scripting language called Hyperscript from the same creator, and it is bliss. It takes after hypertalk of natural language programming fame.

Here is what it looks like when you need to clear the input after adding a todo.

on htmx:afterRequest if event.detail.successful then set my.value to ''

Redoing the dblclick to toggle the .editing class turns into

<label _="on dblclick toggle .editing on #list-item-{{todo.id}}"></label>

That and a simple mutation observer script to keep track of length of changed list items covers what we need.

on mutation of anything from .todo-list
					if length of <.todo-list li/> == 0 then add .hidden to .main then add .hidden to .footer

The nice thing about hyperscript is it’s declarative feel and it’s first class natural language approach to reference and manipulate DOM elements. Improves readability.

Key takeaways

For certain kinds of applications, plain old HTML served and patched into the DOM is a sufficient approach to deliver a SPA like experience without the bloat of full-fledged JS frameworks and associated builds and maintenance overhead
Taking an incremental evaluate/tackle approach to features in a web app goes a long way in keeping the application responsive and lightweight.
Serving plain old HTML allows flexibility on server-side frameworks. It also helps with keeping the logic close to the origin state.
HTMX encourages thinking about static vs interactive parts of an app and brings in only what is necessary to handle the interactive parts.
Following a declarative approach builds on the strength of HTML. The readability helps with the long-term maintenance of the solution.

Demo

https://todomvc-app-htmx.fly.dev/

Source on Github

https://github.com/pradeeproark/todomvc-app-htmx

Bitcoin is not like a traditional investment

Mon, 29 Aug 2022 16:15:25 +0000

What is the yield you can expect in your Bitcoin investment? Is there a consistent rate of return? Will it outperform other markets? Better than stock market returns? Gold? Will it beat inflation?

All these questions arise from the traditional mindset trained to evaluate everything as financial returns vis-a-vis dollars or whatever fiat currency the prospective investor holds.

But Bitcoin, by its very nature, cannot promise any of these things. Those who say otherwise are wrong. What are we investing in if it is not any of the above?

What would be called success in terms of your Bitcoin investment? And how do you evaluate whether it is living up to its expectation?

For that, we need to look at its roots, All “Bitcoin” promised by Satoshi and what it is turning out to be. A “Peer-to-Peer electronic cash system”. P2P without going through a financial institution. And “cash system” means you get to own it and gives the bearer the right over it. This is in contrast to current systems where all flow happens through trusted 3rd party institutions that are not necessarily incentivised to protect your interests.

That it has a fixed supply could also be a consideration if you like it to hold its value better than unrestrained supply currencies.

If you need these properties, you can invest in “Bitcoin”. The returns are as above, nothing else. Still, others can engage in speculative activity and prattle about “Profits” and “Returns”. Still, it was never meant as a traditional investment.

I see you, Bitcoin

Fri, 24 Dec 2021 23:01:32 +0000

For decades now, the present-day western economic systems have never been challenged.

Fuelled by credit and unhinged from sound money, the system is frothing with bubbles and capital misallocation.

This hardly bothers the incumbents, particularly those at the mouth of the credit flow. Free credit allows them to eat all the fruits of the productive activity in the economy.

Only in the presence of an alternate system one can suddenly see the system as it exists in a new light.

The alternate system is Bitcoin.

As society digests this new system, it ridicules it with enthusiasm. Suddenly the problems with the current system are forgotten as we have already adjusted to it and are loathe to change.

It is much easier to point the finger at the other side and question it in a way never before asked about the present system.

That is a positive thing. It’s been some time since these questions were asked. What is inflation? What is debt? whose debt? Can we print money and erase all our mistakes?

Bitcoin Is Efficient

Tue, 08 Jun 2021 00:46:04 +0000

Engineers like to optimise things. It is one of the ways they express their identity. So, for example, if you give one a coffee machine, they would grumble about how much of the coffee bean pulp is wasted, the leaked milk, the wasted power in overheating. Thermal loss, blah blah blah.

They assure you they can fix it. Make it efficient. Brilliant. But they go haywire when they jump to areas they haven’t fully understood.

Are your transactions going slow? Let me show you how to fix that. You don’t want to use energy for that proof-of-work. Let me optimise that for you, they say. Make it efficient.

But it is already efficient.

One of the long-standing newbie questions in understanding bitcoin. Why is it we are mining doing computationally irrelevant work?. Why target a block of only size 1MB? Why not more? They wonder if it looks like a blatant oversight by this “Satoshi”. So let me fix that for you, Mr Satoshi. They have missed that, like all engineering problems, there are tradeoffs and incentives when designing a solution to a problem.

Bitcoin is by design a “protocol to exchange value minimising trust needed”. But easily verifiable by all participants.” Replace “proof-of-work” with something else, and you have changed the trust model. So, if you increase the block size without thought, you make it more centralised, tweaking the trust model. Keeping it “decentralised” and “trust minimised” is a core tenet of Bitcoin’s design. And its design is efficient enough to allow that and no more.

What about the number of transactions in a block? We can’t store every transaction we want on the blockchain. That’s right. It can’t. It is a constraint that one must balance without losing other properties we want.

A possible solution is being explored for scaling bitcoin if you accept the following premise. You don’t need all the transactions you do in life permanently captured forever in the base bitcoin blockchain. So, for example, movie tickets, waffles and ice creams don’t need a forever entry in the blockchain.

Instead, we can move that transaction to another more private layer which only a few participants alone know at a time. Moving layers is how engineers solve a lot of problems.

The existing layer is called Base Layer (layer 1). We can extend it with other layers like the lightning network with a different trust model. Still decentralised and rooted in layer one but can scale to a higher magnitude than Layer 1. One transaction in the main chain could represent millions of transactions on the lightning network. Efficient without giving up its other properties.

Intrinsic Value of Bitcoin compared to Gold

Wed, 20 Jan 2021 13:11:39 +0000

There is an ongoing debate between gold bugs and bitcoiners about the "intrinsic" value of either money? Goldbugs fervently argue that only gold has intrinsic value, and Bitcoin does not have "intrinsic" value. Thereby its value should be Zero.

That its price is above zero is a source of constant surprise and ridicule from gold bugs. “Wait, you will see. “This is all a misunderstanding,” they say. “It will be zero soon.”

After all, what “intrinsic” value does it have? It is all just 0s and 1s and will vanish when someone unplugs the computer (or) turns off the internet. “Clearly,” they say, “those buying it are misled.” But are they?

On the counterpoint, Bitcoiners claim gold has no “intrinsic” value either. It’s all about the utility of it that gives it value. “Bitcoin has utility too and thus has value ^1” they argue. I think the root of the problem is confusion over the meaning of “intrinsic.” Let’s see its origins.

> intrinsic: to come from the inside, immanent (lat: intrinsecus, “within”)

By that definition, we know gold has many intrinsic qualities: corrosion resistance, high malleability, ductility, low reactivity, and scarcity in our known world.

But the most widely recognised quality that makes it valuable as a “store of value” is its supply scarcity. It is as if people were searching for a rare medium that could also be shaped to be held, counted, and exchanged. It didn’t degrade much with use. Perfect.

Gold is both a commodity and money. Whenever its values are considered, the market evaluates these characteristics to price it.

Industrial demand for gold is only 10-15%; the rest goes to jewelry, investments, and central bank reserves.

Gold demand by sector

https://www.statista.com/statistics/299609/gold-demand-by-industry-sector-share/

And jewellery serves a dual purpose of investment and social status symbol.

Historically looking, it does make a decent medium for a store of value. There have been few periods of supply shocks in its availability (discovery of new deposits, change in mining costs, etc.). On a longer timescale, its scarcity and slow mining are pluses.

It also has a plus in its perceived value due to its long history. Longevity is an essential psychological factor when people assess a medium for long-term “store of value” across time—storing wealth for generations.

But for something to act as “money,” does it need to be a commodity as well? Let us see what properties something has to possess to be “money.” From Wikipedia

> Money is any item or verifiable record generally accepted as payment for goods and services and repayment of debts, such as taxes, in a particular country or socio-economic context. The main functions of money are distinguished as a medium of exchange, a unit of account, a store of value, and sometimes, a standard of deferred payment. Any item or verifiable record that fulfils these functions can be considered money.

Not necessarily. There is also representative money.

Now, what might be the “intrinsic” properties of Bitcoin?

Here it would help if you were careful in its definition. Loose metaphors like “it is just 0s and 1s” while sounding plausible are incorrect. “Bitcoin” is a protocol, a “social contract.” It runs on computers or uses the internet is what you would call the implementation details.

If you want to, you could continue the protocol with pen and paper ^2, it might be painfully slow but not impossible. You could also use it without the “internet,” just using radio waves in a peer-to-peer manner ^3 ^4. You could also be pedantic and point out that you could also use horses and messengers.

So what are the “intrinsic” properties of Bitcoin,

Its design mimics the scarcity of gold using mathematics and cryptography instead of shovels and blasting rocks.

Its design allows the verifiable exchange of value between parties without being in person. Distance does not matter.

By its design, it does not need a trusted intermediary for verification. There is no singular point of failure.

Verification is more straightforward than verifying a gold payment, though, like anything new, it needs to be understood.

Its design has an inherent memory of all that has happened (ledger).

Based on these “intrinsic” properties, people have already started utilising them in the following ways.

As a “store of value” both across time and space. Moving value across artificial borders with minimal friction. Censorship resistant. It can be used as a “store of value” due to its scarcity. We can use it as a “medium of exchange” without any censorship.

Going back to the Goldbugs argument of gold vs bitcoin price.

It is pertinent to recognise that “Price” is the perceived value of something. It is not “intrinsic” to that thing.

A thing is priced based on its utility associated with its “intrinsic” properties.

And Bitcoin has “intrinsic” properties as shown above and hence utility and a non-zero price. Whether it should be higher or lower than gold or other competing mediums is something for the markets to decide.

About

Mon, 01 Jan 0001 00:00:00 +0000

I am a software engineer who loves building software. My recent focus is on agentic ai coding.