I remember being a big fan of Venn diagrams while studying set theory from mathematics, back in high school. I never touched any of this set theory, and all that jazz after that brief encounter.

It was only recently while trying to navigate some complex decision making, that I realised how useful set theory is, as a mental model for visual reasoning:

All it takes is a bunch of circles, that’s all there is here to help reason complex decisions. I’ll start with the most simplest decisions, and visualise them through sets, and slowly turn up the notch, progressively increase the complexity of the decisions, to show how this could also be visualised.

Throughout, let: U = Universal set (all possible work, opportunities, artefacts or problems), A = User Outcomes, B = Business Outcomes, T = technology feasibility.

I’ll take you through a couple of examples, starting with the “sweet spot”:

$$A \cap B \cap T$$

In this case, the feature that’s being planned to be built is aligning with the expected user outcomes, expected business outcomes, and is also feasible with the current technology. For eg. faster checkout performance, better for the business (more monies), better for the users who make payments, and also technically possible.

As someone doing product work, a term that’s usually thrown around quite a lot is alignment. If we look at this purely on a rational basis, without looking at the emotional component at all, alignment is ultimately about reaching an unified understanding of the collection of sets, and their relationships. In case of the “sweet spot” category, every set is aligned (user outcomes, business outcomes, and the delivery/tech team involed)

---

Everyone agrees, but impossible to build:

$$(A \cap B) \setminus T$$

---

Helps users, but pathetic business case:

$$(A \cap T) \setminus B$$

Could be a dream for users to have on the product, but very weak business case: for eg. accessibility concerns that are usually ignored, unless it becomes a part of compliance

---

Helps business, but users really don’t care:

$$(B \cap T) \setminus A$$

Audit logs, account balance reporting etc, come under this category.

Now, what I’ve shown so far are the simple cases, which can also be explained verbally in a succinct line. However, we also see other more twisted cases:

---

Misaligned incentives:

$$(A \setminus B) \cup (B \setminus A)$$

Category of use cases that either only benefit just the user, or just the business. There are no overlaps, at all.

---

Valuable, but blocked:

$$(A \cup B) \setminus T$$

For eg: user wants offline mode for their favourite app, but building that capability requires larger architectural changes which wouldn’t be possible

---

Most problems are nested within larger problems:

$$A_1 \subset A_2 \subset A_3 \subset U$$

There is often a hierarchy of problems which gets missed accounting for. While discussing with others, this visualisation helps us know at which level of hierarchy we’re discussing the problem. Often we mistake one hierarchy for the other.

---

Requests (R) don’t match with Business goals (B):

$$R \cap B = \emptyset,\quad R,B \subseteq U$$

Let’s take an example of a CEO requesting for a dark mode to be added to the app, but then, adding dark mode doesn’t serve any user problem. It’s just a useless request coming in from an influential person, and the game becomes more political..

---

The balanced roadmap:

$$(A \cap B) \cup \bigl(U \setminus (A \cup B)\bigr)$$

Sometimes, some features dont fall into the intersection of user <> business outcomes, but still worth doing as a strategic technical investment, helping strike the ideal balance of today, and tomorrow

---

Ship obvious wins, while investing in platform health:

$$(A \cap B \cap T) \cup \bigl(U \setminus (A \cup B)\bigr)$$

---

Mixing strategic bets with easy user wins:

$$(A \cap B) \cup \bigl((A \setminus B) \cap T\bigr)$$

Every disagreement is, at its core, a disagreement about boundaries. Alignment problems are usually about where one thing ends, where another begins, what belongs together, what doesn’t, what overlaps, what has been mistaken entirely, etc. All this is made super clear with the language of set theory. It gives a good technique to make these boundaries visible..

Everything around us is a relationship between sets, sets of sets, and sets of sets of sets:

Needless to say, that it just makes me want to stop arguing less, and just open up an Excalidraw instance, and start drawing colorful circles. Alignment is then, lot less of an hassle.

When we see two events, A and B, our natural tendency is to place a succinct left-to-right arrow —>, in between two events A and B. It hardly crossed my mind sometimes that A and B could be feedback loops. A could effect B, and B could effect A, and the effect of B effecting A, could effect the effect of A effecting B…. . Why complicate things isn’t it? We will just leave it as it is, after all simplicity is the ultimate sophistication..

Okay, enough of abstractions, let’s talk specifics:

• I see a thing called a “problem”, and another thing called a “solution”, and I imagine the problem leading to the solution, or so the thinking goes.

• I see a person being “religious”, and a set of rituals called “practice”, and I imagine the belief came first and the practice merely expressed it.

• I see “aging” and “disease”, and I imagine aging as the background condition, while diseases are the foreground enemies we are meant to defeat.

As you could notice from the above examples, I kept mistaking the loop, for a A —> B type line.

Most of what we see around the world don’t work in a capital “L” linear way. by the end of this essay, I hope I’ve driven the point around self reinforcing feedback loops strong enough..

And even August Kekule, the German chemist famous for the discovery of the Benzene ring, had made the same mistake (but he did learn from his mistake, and was able to unearth the chemical structure of Benzene). He thought the benzene was a linear chain of carbon atoms, but the mathematics of the chemistry didn’t just add up if it were to be a linear chain.

To him, this was an unsolved enigma, a ghost in the molecular machine. So he was taking a sweet nap on a rocking chair in front of the Victorian fireplace, when inspiration struck him:

And in that sudden hallucinogenic drift, he noticed the benzene atoms dancing, whirling like a molecular conga line, before cooling into a ring and biting its own tail. The mythical ouroboros appeared.

How many of us are making a similar such mistake? Are we all mistaking the loop for a line? Could this visual of a snake eating its own tail, serve as metaphysical guide for us to think through reality and how everything is connected? Let’s look at these patterns in more detail:

problem ↔ solution

In my first career arc of being an “fresher”, an inexperienced product newbie, I used to think of the problem and the solution as a traditional waterfall. You think of the problem, define the constraints, check. Head to explore solutions. Check. Finalise the solution. Check. And then pass it on, and move on to the next problem <> solution. It was supposed to always point right —>, from the problem and into the solution..

Jumping into “solutions” prematurely, before understanding the problem was also considered to be offensive in some circles.. as we have not thought through the problem completely, and that we’re not qualified to take such a serious move so early. This was the designerly equivalent of the cardinal sin.

It took me that entire decade and a Masters education in design methodology to help me realise that it seldom works that way, in reality. Problem and solution pairs are having a kekulean dance with each other, eating each others tail, biting and pouncing at each other until they end up with a better problem and solution pair. There is a co evolution which we miss noticing. In retrospect, it felt fairly obvious and I was scrutinising myself as to why I needed a masters education in design theory for me to be educated enough to know this..

Timing through solutions can help us think through the problems which can also help us think through better solutions.. while working on a recent creative experiment, I spent much more time cooking up multiple variations of the concepts through prototypes. I could have also gone the problem definition route first, doing informational interviews first, and assess which pain points are more important, and after all that, I could have then considered possible solutions. But the reality was quite zigzaggy. Those prototypes then served as better tools for enquiry helping me reach traction and momentum through them, the image of the double-diamond which is flashed left, right, and centre as a part of the designers indoctrination program across various universities seldom withstands contact with reality, this theory wrinkles and perishes with usage, as like other processes, this is also not a linear conveyor belt style causality..

belief ↔ practise

I also then realised that I make the same mistake in other aspects too — bidirectional pairs, unidirectional pairs. This topic keeps coming up again and again..

Let’s talk about belief and practise. Tanya Luhmann, the American professor explores the relationship between belief and practise in her book—How God becomes real. She describes herself as “anthropologist of mind”. In her quest to understand the way people represent thought itself, and the way those culturally varied representations shape the most intimate experience of life itself.

This is Nielsen describing his own experience reading this book:

Tanya M. Luhrmann has written a beautiful book exploring this question, “How God Becomes Real: Kindling the Presence of Invisible Others”. The book explores the idea that much of the purpose of religious practice is to help practitioners believe. This inverts conventional wisdom, with Luhrmann taking seriously the possibility that sometimes people aren’t worshipping because they believe, but rather believing because they worship. More generally: Luhrmann makes a compelling case that there is a much more complex relationship between belief and religious practice than you might naively suppose, and she explores some of that relationship.

I used to think that people who are “religious” by spirit, also do practise a lot of rituals because they’re religious. Atleast that was the notion I was used to hearing. However, Tanya explores a different dynamic where she suggests that practise itself by virtue of practise — practise instils belief.

Personally, I come from the other side of the spectrum where I want to be religious for some reason, and I lack embedding some rituals in my day to day. This thought that religion and practise are a co-evolutionary loop gives me great hope. I’ve envied my mom, and my sister in the way they have cultivated their faith through practise: which involves chanting Hanuman chalisa, Vishnu sahasranaamam, Lalitha sahasranaamam etc and various other Hindu japa mantras in the evenings as a part of their daily/weekly/occasional puja rituals.

Right now, It’s 6:15 PM at dusk, an auspicious time usually meant for evening prayers, and here I am talking about the process of Bhakti (practise of worship), rather than doing the practise itself. How ironic, but I will get there.

Religious belief isn’t something that’s easily attained or endowed with, and it’s hard to tilt towards a religious worshipper from a somewhat-agnostic mode, unless cultivated with practise:

Let me review a few of the moves Luhrmann makes in setting up her project. She points out, convincingly, that religious belief usually isn’t something easily attained, despite the fact that many theories of religion “presume that belief is direct and unproblematic – that in most cultures, people simply take spirit and the supernatural to be there. That doesn’t make sense. Gods and spirits cannot be seen. You cannot shake their hands, look them in the eye, or hear their voice when they speak. It seems odd to assume that people just take for granted that they are present.”

I find it weird when I say this, but knowing this theory has actually makes me more religious. It has given me more meaning to what’s interpreted as practise. From the day I read this book review article on the co-evolutionary loop phenomenon exhibited by religion and practise, I am not able to unsee these patterns applied across everywhere. And there are more..

aging ↔ disease

Now, the thinking here is Ageing → Disease, that as we age:

• DNA damage accumulates.

• Cells become senescent (they stop dividing but release inflammatory molecules).

• Mitochondria become less efficient.

• Stem cells lose their ability to repair tissues.

• Chronic low-grade inflammation (“inflammaging”) increases, leading to more diseases, and ultimately death.

But now, increasingly, scientists are thinking that it is rather: Ageing ↔ Disease, instead of merely, Disease → Ageing.

With this U-turn in the direction of arrows, we have this bet that ‘aging itself is a disease’ which can be treated. And that part just blew my mind. We now have scientists trying to reverse the age of human cells, and we now have clinical trials trying to prove this in full swing. Newlimit is one such company, working in this bleeding edge of longevity with this same thesis.

“And by combating ageing itself as a disease, they want to combat all diseases.”

NewLimit uses RNA to switch on the combinations that make an old cell start acting young again. They already have a prototype that does this to human liver cells, healing the liver faster after injury and speeding up recovery from alcohol damage. the first human trial is set for 2027. Brian Armstrong’s company just raised $435M to do this.

What excites me from all this latest development in tech is not the fact that the age 120 stops being a fixed ceiling, or the fact that cellular reprogramming gives potential pathways to 150 years on average, but the fact that this all started with a smart framing of a statement that got flipped on its own head: “that ageing is a disease”.. who would have thought?

Most of us are primed to think linearly with “X causes Y” logic, but we have to adopt a systems thinking lens, and I’m trying to train myself here with the notion that everything is a system (X causes Y, which feedback’s into X again..), and it’s not easy..

To me, most of the smartest ideas out there starts with a unique counter-positioned framing, a view that shakes the world view, this creates a literal tear in the space-time continuum and leads to innovation, as a side effect..

I will keep hunting for more such co-creative systemic loops. And I hope to find more. After all, the whole world is just the snake eating its own tail…

I recently read Kevin Kelly’s Excellent Life Advice for Living. And immediately after that, on Substack, I also came across Nabeel Qureshi’s Substack post which is in this similar genre of being a listicle. I felt a genuine urge to articulate my own life lessons in this wonderful format and share it across to the world. So here goes:

1. I’m angry not because someone else did something wrong, and I’m venting it out by being angry. That’s not true. I am angry because I’m trying to prove that I’m better than the other person who made that blunder. If someone spilled tea on my shirt, I get angry to show the supremacy of my ego more than anything else. Anger is not serving the function to solve the problem of “tea being spilled on my T-shirt”. As there is no utility of anger, there is no need to get angry (I keep telling this myself every time I get angry that it’s my ego playing supremacy games). If this seems illogical and absurd, read Courage to be Disliked.

2. While handling difficult conversations, bend the voice and modulate it in such a way that there is this parabolic tilt. It’s called the Late night FM DJ voice. Even if you’re dealing with a terrorist kidnapping or a hostage situation, bending your voice like Beckham, making it slope downward, calms and eases up any person who is listening to it. End it in a descendo, and not a crescendo.

3. While taking risks, I ask myself “what’s the worst thing that could happen?”. Nothing is as worse as one imagines.

4. If given a task, I get to the 5% done state as fast as possible. It doesn’t matter if this is accurate. It would be hardly perfect, but I’ve already reached critical velocity to make sure I accomplish the task sooner. It saves a lot of back and forth and contemplation whether it’s a task worth doing or not. Often we spend more time thinking about what to do, rather than doing. This reduces the gap even further. And if something takes less than 2 mins to do, I do it right away, why think? One of my favourite writers of all time, Derek Sivers talks about the same in this essay titled “take the first step immediately”

5. While trying to grasp a complex subject, see if you can find a “philosophy explainer” of the same. For example, for doing software design I chanced upon the book, The Philosophy of Software Design by John Ousterhout which primes the reader with various cognitive pumps and thinking tools to help structure one’s chain-of-thought in a better way while building software. Nowadays as we hardly “write” code but rather instruct the coding agents instead, the grounding with this philosophy primer has stayed with me even more.

6. Best advantage would lie in mastering three-word niches. If you are trying to master “product management”, not much of an advantage. But if you’re doing “Healthcare product management” then there is some benefit, but not truly an undetectable advantage. But if you’re really wanting to double down then probably “Healthcare product management with AI tooling enabled” could be three-word niche which has benefits if one masters. Three word niches are also easier to discover both to search engines, as well as ChatGPT and various other generative tools. It could be anything ranging from medieval-snail-enthusiasts, to espresso-drinking-airport-lounge-nomads

7. Read one chapter at a time for non-fiction, and spend atleast a significant period waltzing around thinking out loud the ideas. The thinking should be more in terms of cultivating intuition and less towards rote comprehension. Only proceed to the next chapter when understanding is satisfactory, and use ChatGPT to steelman and strawman the ideas. Also make sure you’re walking around, so the exploratory mode of thinking is ON.

8. Best way to freshen yourself up is to take a double-espresso shot (or a lungo) and then couple it with a 25-min nap. Works like a charm. I call it the “nappucinno”

9. When you smell BS whataboutery in a conversation, do a “two degree probe”. Probe once, and then probe one level deeper. Those who are good at BS might have subterfuge tactics to circumvent one degree probe, but not for the second degree probes. Three-level probe is dangerous, don’t do that ⚠️. Nobody likes to be asked why, why, why (I suspect this is because of the MBA-ization of english language, especially the “5 Whys” technique, along with the 3Ps of success, and 4Ps of management)

10. Contrary to what people otherwise think, solution can also influence the problem, your practise can also influence more “belief”.. most of these are kekulean co-creative loops that feed into each other. I try not to think in a linear fashion. Once you see it, you start seeing it everywhere: ageing, and disease. Or even: problem, and solution. This is also a classic example of a systems thinking perspective and what’s categorised as a”reinforcing loop”.

11. If non-fiction is for the mind, fiction is for the heart. There should actually be more bibliotherapists out there. In some situations, all you need is a good book to feed your soul. I read Courage to dislike yourself by Ichiro Kishimi, at a cathartic phase in my life, and it helped me recover better.

12. Keep a notebook with a Uniball 0.7 mm always nearby your laptop desk. Typing is faster, more efficient and all that, but writing with hand activates much more parts of our neural circuitry. Whereas typing decomposes into a single act, triggering neurons in only a selective part of the brain. I did remember seeing this research, but now I’m not able to quote/hyperlink it as I’m not able to find it.

13. Listening to bird songs, especially the cackling melodies in the rainy forest types are so great for calming you down. I also listen to the Slack’s elevator music on repeat for these reasons, and more recently I’ve come to a conclusion that the bird songs are more soothing, and there ought to be an evolutionary biology that explains this behind the scenes.

14. When I’m listening to someone on a call, I keep speaking and exhaust all possibilities of unanswered questions they might have. I keep probing, “and then?”.. “and then..” or “Is there anything more?” Etc etc until the tap is dry. Whatever needs to be shared should be shared, and is to be listened in to.

15. Internet is not always noisy, it’s just unevenly distributed. People who use X for politics, might have a different notion of X consumption as compared to those who use it for AI researchers alpha. For X, I block the politics, block the finance bros, block also the crypto bros etc and etc. eventually I only have one specific focussed feed for X that gives me what I want. Also mute words like “politics, crypto, sports” etc forever.

16. Best way now to network with interesting minds is to submit a PR intro. You find a project the creator has published on github and then contribute to that project by pushing a PR. When the PR gets accepted, it becomes a badge of accolade, and could be a precursor to something even bigger (maybe you collaborate with the creator next as you’ve already proved your value through proof of work?)

17. Happiness is a skill. The framing that this is a “skill” and not just a turbulent river which ebbs and flows as happiness/sadness/melancholy etc is important to keep aware.

18. There is an art associated to accepting praise gracefully. And denying a compliment is not the best strategy. As La Rouchefoucauld puts it “the ability to deny praise is a tendency to accept praise twice”. When someone compliments you, just take it. That’s the best way

19. I try my best to write to creators whose creations resonate with me. If I liked a particular thought or an idea from your essay which I read, then I want to write to you to explain why. I DM’d Vishan Veerasamy on his YouTube vlog series, and he replied back with a thumbs up. That’s all I want, folks

20. I think Poker is the best game ever and everyone should learn how to play it (Mafia comes as a close second if there are 12+ players). Poker is crafty in the way it mixes skill and luck, and it’s a simulacra of how it would play out in a real world scenario. You always have an ungodly balance of skill and luck. Chess is interesting but boring because it’s all so heavily deterministic. But not Poker. I didn’t say this BTW, John Neumann described this about Poker. For learning the mathematics of Poker, this is a fascinating lecture series on YouTube.

21. Every city has a vibe. And it’s a gross injustice to the human product (yes, you) if we don’t do enough aura farming to harvest this energy. Paul Graham talks about this in his essay where he says London reeks of “culture appreciation”, New York about money, Boston about being smart etc. I want the city to wear off its aura on me.

22. If you’re tired of social media feeds, use an RSS feed instead. Maintain a list of important writers, and read regular essays from them via RSS (I recommend Netnewswire, as a RSS reader app). This is a list that Karpathy maintains to keep abreast of AI engineering.

23. When I decide to write, often the best ones are when the emotions attached to the storyline are so overwhelming, the pot is brimming with excitement to share it out loud.. it’s as if your thoughts are passing through various stages of matter: from its fuzzy gaseous state, then into a liquidy jelly like state, and then into a highly emotive solid state where your internal molecules are all buzzing and vibrating. That’s when the best drafts are written, I think. For instance, I wrote this after a medical appointment while sitting in the Starbucks cafe and waiting. I wrote this all on my smartphone as I couldn’t wait anymore.

24. Language is a powerful technology. Everyone around you is forging it for their own best interests, like it or not. It took me a long time to realise why “global warming” was more useful to use than “climate change”. Please read more George Lakoff.

25. If you are on a long-winded conversation with your friend filled with a lot of non-sequitors sprawling multiple topics, do your friend a favour and drop links on WhatsApp after the convo has ended. This is the WhatsApp equivalent of the literary “footnote” for books.

26. Write down the goals you want to achieve this year and speak them out loud in your own voice, record and save it on your phone. If you have an iPhone, trigger an Apple shortcut which launches every night at 10:30 PM, forcing you to listen to this message. I’ve been doing this for 2 months and feel pumped up for the days to come..

27. Talking to my wife, I naturally end up in a problem-deconstruction-solving mode, and it took me a long-long-long time to realise that I don’t have to always be in this mood, and the adage “men are from Mars, women from Venus” is a cliche that exists for a reason. So now, I ask beforehand ‘Should I help solve or should I listen’. You might mostly get an answer right away, and for even more difficult situations, you would need a bit more fine tuning your antennas for accentuated sense making of whether it’s a “solve it” mode, or “listen deeply” mode.

28. Use your phone in black and white mode. Every app, every colour chosen is designed to keep you spinning the wheel, and scrolling the feed. Engineer your digital environment to work in your favour..

29. If you’re 18, read Ayn Rand’s Fountainhead. Your youth needs a strong sense of unrealistic idealism. Resist the urge to read Ayn Rand after 20.

30. Never ask “How can I help you?”. That puts too much of burden on the other person to tactically calculate the right favour which fits. Instead ask “When should I think of reaching out to you?”.. that’s more subtler. And if you have time, also ask this bonus question: “who else should I talk to? Any reccos?”.. you’re spinning the wheel for some organic discovery here.

31. Don’t use AI to “clean” your humane writing prose. It’s good as it is, and don’t prune the edges. Embrace your quirky style (except the typos, of course). Let it not drift into becoming the “average Gaussian mean” of the written word.

32. Best way to start the opening line with a friendly stranger is to just give them a peak into your mind voice. Yes, “hey, hi, how are you” is the worst opening line ever. If I have an interesting thought or observation, I just prevent myself from repressing the thought and just blurt it out. Recently I noticed someone reading Watching the English book which I was also coincidentally reading on the Kindle and mentioned the same to that person.

33. In this world where optionality is everywhere, hugging the X axis gives meaning to life. It doesn’t matter what hugging the X life means, as long as it’s something. For Victor Frankl, reuniting with his wife gave him meaning to survive the Auschwitz holocaust.

34. If I had to get the most high-signal alpha information on a particular topic in the least amount of time, I would start with 10 informational interviews first. I would let this guide me to wherever it would take me. I tried this for my job hunting process, helping me pivot from service design to product management as a career

35. There is an interesting sub niche of vintage lectures by professors on esoteric topics on YouTube. You would just land into it someday by merely manifesting it. A good entry point for flourishing your YouTube feed with such suggestions is this one: Introduction to Writing by Brandon Sanderson

36. Always read raw transcripts, feel the granular ebbs and flows of emotions. Reading the AI-generated summary is yuck. Stay away from it if the purpose is to gain insight. Imagine what a blasphemous travesty it would be if you were to feel complete by reading an AI-generated summary of Marcel Proust’s In Search Of Lost Time. “An aging narrator rediscovers his life through memory and realizes that art can redeem the time that seemed lost”.. yikes!

37. If you like someone on X, read their posts in reverse chronological order to see how their thought process has evolved over time. There are some Chrome extensions which could let you do that on the browser. I have done this for Pieter Levels and Anne Laure le Cunff

38. If a trend is coming out as a full length McKinsey report, then the alpha is already over, 6 months ago. Alpha on the Internet moves bottom-up across multiple layers: Polymarket/TikTok → Twitter → YouTube/Linkedin threads → Consultancy reports. Conversational intelligence predates financial intelligence. People think first, and then pay with their wallets.

39. I changed my mind thrice on the relationship between theory and practise. I first thought theory comes first and then practise. But then entrepreneurship taught me that practise is needed to give colour to the theory and allow it to resonate. Then I changed my mind again when I read Kevin Simler’s blog on how ads work, and I started looking at ads in a very different way (which then proved that theory informs practise too, therefore the answer here is that theory and practise are in a kekulean reinforcing loop)

40. Do become good at a particular thing, do 100 of it first. This avoids the intellectual trap to overthinkingmaxx and make “perfect” things. Visakan Veerasamy suggest to cook 100 tamagoyaki egg omelettes, 100 YouTube videos, whatever. Taste is only through iteration. I recently finished my 100 essays project, and am 10/100 into my 100 YouTube videos project.

41. Have an opinion over everything, instead of being in a “not having any opinion” state. To start somewhere, establish your minimum viable opinion and in a Popperian way try to strawman it as much as possible. If the opinion is still standing strong despite your best criticism, then it should be a valid, well-formed opinion.

42. Morning pages provides a burst of much needed creativity especially when you’re hungry for fresh new ideas. There is something about dedicated writing/thinking time at a zero-cache state in the morning right before you pick up your phone.

43. Try placing some 2.5 second pauses in the middle of your conversations. Dont overdo it, and such contrast in terms of silences and voice modulations make it easier for the audience to remember what we are speaking about.

44. A request for a podcast is just an excuse to talk to a high profile person who might otherwise not accept the offer to “let’s grab a coffee and touch base on various topics”.

45. I usually soften the assertiveness in a statement to make the recipient sway. Instead of saying “X needs to be done because of Y”, I say, “I think X needs to be done as Y…” this works all the time and is easier to persuade/influence others..

46. The third spaces are now running clubs, brunch events, weekend trials etc, and have replaced the hanging-out-in-the-pub-for-drinks situation. This is a win for teetotallers.

47. Great minds discuss ideas, mediocre minds discuss people. The moment an idea receives an ad-hominem attack it’s a subterfuge technique to shift the playing field to the realm-of-people, and not the realm-of-ideas, be wary..

48. People say that as you age, your sense of time gets shrunk dramatically, making you remember your childhood events much more vividly than your Middle Ages. Turns out that it’s possible to thwart this effect by getting bored and doing nothing. I try to do nothing instead of scrolling on my phone when I have a few spare minutes. I am getting more bored, and I feel like I’m living a longer life. This is a form of life-extension where you’re changing the perception of time, rather than extending your life biologically..

49. ChatGPT provides the worst possible cooking advice as the suggestions are diluted to water down any specific technique which is helpful. Especially for cooking, rely on grandmothers wisdom instead of generic LLMs. For Indian cooking, I have got premium mediocre results by loading the PDF of Krish Ashok’s Masala Lab as a ChatGPT project to ask specific questions, and the responses were not watered down compared to a generic ChatGPT response. Could still improve, but not bad.

50. Your personal website is your pincode on the internet. Dont let it die, maintain it as your canonical source, and if possible do POSSE (Publish originally, syndicate elsewhere)

51. It’s better to read books that are “niche but loved”, rather than the ones which are recommended by everyone (case in point: The Monk who sold his Ferrari, Atomic Habits etc). Kremlin school of negotiation is an example of a book in the “niche but loved” category while, Start with a No is famous but cliched, so definitely not worth going for. I don’t believe in the wisdom of crowds, but I believe in the Lindy

I’ve always been fascinated by the aesthetic of the scientific illustrations commonly found in academic research papers, especially journals like Nature and Cell. So I recently developed a Codex skill that can replicate that kind of visual language. This is the github repo if you’d like to try it out.

Here are a few examples:

Generate one clean scientific illustration suitable for a research paper or review article. Purpose: Conceptual microbiology mechanism schematic. Scientific subject: Bacterial biofilm formation on a surface and antibiotic tolerance. Core message: Biofilm structure creates protected microenvironments that reduce antibiotic access and support tolerant bacterial subpopulations.

Create a clean physics/engineering concept figure: A photonic chip routes light through tunable waveguides, allowing optical signals to be switched between output channels.

Create a research-paper-style geology schematic: Fractured basalt improves subsurface fluid circulation by increasing connected flow pathways while exposing more reactive mineral surfaces for water-rock interaction. Show a two-panel comparison: massive basalt vs fractured basalt. Use simplified rock cross-sections, blue arrows for fluid flow, highlighted reactive surfaces along fractures, and a plain text outcome callout: Enhanced fluid circulation. Keep the style clean, journal-like, white background, muted gray/blue/orange palette, Arial/Helvetica-like labels, and avoid fake maps, seismic sections, microscope images, spectra, mineral formulas, or numerical permeability claims. Labels to include: A Massive basalt B Fractured basalt limited flow path connected flow path

Generate one clean scientific illustration suitable for a research paper or review article. Purpose: Conceptual microbiology mechanism schematic. Scientific subject: Gut epithelial barrier interaction with commensal and pathogenic bacteria. Core message: A healthy mucus and epithelial barrier spatially separates most microbes from host tissue, while barrier disruption allows closer bacterial contact and inflammatory signaling.

The objective was to create the specific style of scientific illustration commonly found in high-prestige journals like Nature, Cell, and others.

I wanted the outputs to be coherent and consistent across different examples, without introducing confusion or scientific errors. Consistency is key, right?

I drew inspiration from a design skill created by a Chinese creator named Xiaohei. He demonstrated a well-structured approach to creating a skill for image generation using Codex. Since Codex has native image generation capabilities, the skill can generate images on the fly.

While exploring Xiaohei’s skill, I noticed a few useful formats. First, he has a markdown file for DNA that outlines the essential elements that need to be captured and preserved during image generation. It also provides a prompt template that asks for any gaps or details that need further elaboration, enabling the skill to generate more accurate and comprehensive images.

I just fed this skill skeleton to ensure that I could adapt these best practises to make this happen.

My agentic engineering workflow has changed in the recent past. The models are better, and there is much more freedom in choosing the harness, abilities, and actions you provide.

Table of contents:

• Pre-planning, pre-idea, pre-everything
• The first chat with the agents
• The first chat on the terminal
• Setting up the Opencode environment
• Doing light research, deep research
• Model choices while working with coding
• The design process: sequence of steps while building apps
• Ensuring that the design in the design process is coherent and consistent..
• Ensuring the code generated is clear, and reviewed
• Templatize everything that needs templatizing

I’ll walk you through each of the phases in this workflow which I follow to build my side projects (as of June 1, 2026). It has evolved from IDE chat, to CLI coding agents, to now “slice-driven product development”.. so let’s get right into it..

Pre-planning, pre-idea, pre-everything

To curate the list of ideas I have in the pipeline, I use Trello for a simple kanban board. There are many other tools you could use for a simple, organized list of items, even a TODO list app would suffice. However, I’ve particularly liked Trello for this purpose because it also allows you to add a nice little thumbnail for each idea. Usually, an idea comes to me all of a sudden, out of nowhere. In this fleeting moment, I try my best to capture it as accurately as possible, as if I were feeling it in my veins. So, a picture along with a one-line description helps me capture this fleeting thought..

Trello mobile experience is also nice, and I mostly capture them while on-the-go.

My only heuristic for picking my next side project here would be to go with something I’m most excited with. I have a crematory of 100s of abandoned side projects, and I don’t want to add another one to this ever growing list of dead projects that don’t bite. I would at least want to ship what I start, and for that, the fuel here is motivation. You feel it in the gut, and you want it to guide what you should do next.

The first chat with the agents

Usually, when you capture an idea or thought, it might be in a very urgent mode and you wouldn’t go into the weeds of how this might be envisioned. So to explore what this could mean, I start having a chat with the agents. I usually feel more comfortable doing this on mobile, so I pick this up on ChatGPT. One other reason I’ve been tied into the OpenAI ecosystem is the additional benefit I get from the $20/month subscription package. I get to also use this for leveraging GPT-Codex via Opencode. More on the agentic coding setup later, but I just wanted to mention this right away, as I see great benefits in tying into the ecosystem offered by OpenAI.

Another reason I use ChatGPT is, interestingly, its default typographic choices. Look at Claude, and the mess they’ve made with their default choices. Anthropic folks have used and abused the serif fonts, and their defaults have slowly trickled down to the way everyone vibe codes and makes their half-cooked apps. It’s a mess, and I want to stay away from it.

Another important reason for going with ChatGPT is in its ability to do OAuth with any of the self-learning, persistent memory agents such as Openclaw or Hermes. This allows any user already with a ChatGPT subscription to connect directly with Openclaw, instead of having to buy additional API credits.

While having this on-the-go chat with the agents, I might also end up in a deep-research rabbit hole. An example from the recent past was when I tried to find open source repositories on GitHub for creating music karaoke tracks for my father-in-law, who is practicing to be a singer more recently. I was itching to build a custom solution for his needs, but then, I wanted to double-confirm if there are any ready-made solutions available right off-the-shelf on GitHub which I could fork. (and it just turns out that there was an off-the-shelf solution, so I didn’t have to reinvent the wheel)

So I ask ChatGPT on the Deep Research mode to provide me a list of well-maintained repositories which do the whole thing, or a ‘part’ of the pipeline, really well.

^^ Early explorative conversations done on ChatGPT.

I have noticed that I get better results this way, rather than just trying to piece together a curated list of repos by searching through GitHub manually. While doing forking and modifying, I also try to ensure I have the right licenses to do so.

Having more Socratic dialogues

I have also noticed that this type of search works better than a mere LLM search. I also instruct the agents to “steelman” or “strawman” the concept to identify the fault-lines, or even to cultivate an opinion sometimes.

All software engineering is ultimately tradeoffs, and there exists no perfect solution without tradeoffs, so this line of reasoning helps shape an opinion on what the product should do (without having to do everything under the sun)

Once, GPT presented this list in a table format. (Make sure to provide custom instructions to always use comparison tables wherever necessary.) I began visualizing the concept in my mind, keeping the architecture in mind. Sometimes, I say, “Help me visualize the end-to-end pipeline in ASCII, including the components and libraries we’re using.” At this stage, it’s crucial to hold the complete concept in our minds without drifting away. All these conversations and visualizations help shape our vision. And with these simple ASCII diagrams, the simple act of arrows pointing to each other can help us conceptualize better.

At this stage, all of the chat threads are still on ChatGPT, and I haven’t even opened my laptop yet. All this is on mobile. And when I finally find satisfaction with the chat outputs, I would then do a ‘handoff’ to do some serious work with the foundation already set by my chat. For this handoff, I would try to synthesize the conversation into either a spec .md file, just to see if what I understood and what the agents have understood are the same. I’m looking here for mind-AI convergence here, nothing else. And in case there is some drift, I still have a way to make sure there aren’t any gaps.

The first chat on the terminal

Now that we have something to work with, we start our first chat on the terminal. I primarily use Ghostty as my default terminal application. Surprisingly Ghostty is faster than the native terminal offered on Mac, and I haven’t looked back.

Why use the CLI over a code editor? Because, the job becomes more of pointing the agents at the right location in the codebase, rather than writing code. We’re in the era of CHOP - Chat-oriented programming.

Apart from the speed benefits, it also provides a similar interface as that of Google Chrome: Just like you open multiple tabs on Google Chrome, you can also open multiple chats with agents on Ghostty, and the interface helps a lot to have multiple conversations with the agents. Just to maintain sanity, I keep one project for each tab, and open multiple panes/agents under that tab for that specific project. In that way, I could streamline my chats with multiple agents working, across multiple projects. I’ve tried going this route and have got a dopamine hit from the code throughput, but have realized that it’s much more important to hold an ‘entire problem in your head’ from start to finish. So I’ve let go of context switching, and have embraced FOCUS.

^^ I’m usually opening multiple Opencode conversations via Ghostty.

With Ghostty as the terminal application, I use Opencode as the TUI app for chatting with the agents directly. Think of it as a more hackable, model-agnostic alternative to tools like Claude Code, Codex CLI, Cursor Agent, or Gemini CLI.

I’ve also heard that Pi agent is even more hackable than Opencode, but Opencode strikes a good balance in my view. Pi can even manipulate its own installation, and emits events for everything, making it easier to build reactive UIs on top of it. (With Opencode, you could still do various customizations by means of Opencode plugins).

Setting up the Opencode environment

The default Opencode application itself helps you do most of what you need. These are the skills I use with Opencode:

Skill	Purpose
build-cli	Design or improve agent-friendly and human-friendly CLIs.
copy-ads	Create paid ad copy variants for channels like Google, Meta, LinkedIn, X, and TikTok.
copy-marketing	Write persuasive website, landing page, headline, CTA, and value prop copy.
copy-release-notes	Generate user-facing release notes and changelogs from shipped work.
customize-opencode	Edit or create opencode configuration, agents, skills, plugins, MCP servers, or permissions.
frontend-advanced	Build technically ambitious frontend experiences such as shaders, virtual tables, spring physics, and scroll effects.
frontend-performance	Improve frontend loading speed, rendering, animation, images, and bundle performance.
frontend-remotion	Apply best practices for Remotion video creation in React.
frontend-slides	Build animated HTML presentations or convert PowerPoint decks into web slides.
meta-design-setup	Set up persistent design context and guidelines for a project.
meta-find-skills	Help discover and install additional agent skills.
meta-thinking	Act as a structured thinking partner for decisions, tradeoffs, mental models, and stress testing ideas.
product-breadboard-review	Review an existing breadboard against implementation and surface wiring/design drift.
product-breadboarding	Map workflows into product affordances, code affordances, stores, and wiring.
product-framing	Turn transcripts or interview notes into structured product framing documents.
product-kickoff	Convert kickoff transcripts into builder-facing implementation reference docs.
product-naming	Brainstorm five memorable product names with rationale.
product-shaping	Collaboratively shape a product or feature before implementation.
product-vision	Create inspiring product vision statements and alignment narratives.
research-bluesky	Deep research using docs, web, and codebase before planning.
research-deep	Thorough evidence-backed research across code, docs, and web.
research-last30	Recency-focused research across many sources from the last 30 days.
research-light	Targeted lightweight research before planning or implementation.
tool-browser	Automate browser tasks like navigation, screenshots, forms, scraping, and web app testing.
ux-clarity	Improve interface microcopy such as labels, buttons, helper text, errors, and empty states.
ux-onboarding	Design or improve onboarding, activation, setup, and first-run flows.
ux-resilience	Make interfaces robust against errors, edge cases, i18n, overflow, and production issues.

You could download my total list of skills here: https://github.com/shreyas-makes/agent-skills

As you can see here, more broadly the list of skills are more focused on UX, research, copywriting, performance and browser-automation testing. I see skills being created and updated as a dynamic ongoing process that needs to be reflected upon every now and then. It would look something like this diagram here: if it’s a process that has been repeated more than 5 times, then definitely create this as a skill.

In the first wave of adoption to agentic coding, we saw a lot of impetus given to designing the right prompt.

In the old era, this would have been quite a useful technique to get a lot more sauce from the models, but in the new way, where the agents have caught up with intelligence, we don’t require any such sorcery.

Prompt engineering is just English grammar in my view, and even if you’re rambling incoherently (making sense sometimes), they are still OK.

Doing light research, deep research

For complex tasks, you might want to research, walk through the planned sequence of steps, and then execute. Sometimes you might need to do all three, and might straightaway jump to execute too, that’s fine too. Especially on the “research” step, I might do a light-research that’s not too rigorous, and a more extensive “deep research” that scrapes every last bit of information arbitrage from the internet..

If I have to do more ‘light-research’ inline while using the terminal, I use the light-research skill popularized by Josh Pigford..

If I’m looking for more “hot” research, especially the word-of-mouth from the zeitgeist, especially since every day is a year in the AI age, I use the /last-30-days skill.

The /last30days skill popularized by Matt vhorn is an ‘AI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary’.

Reddit upvotes. X likes. YouTube transcripts. TikTok engagement. Polymarket odds backed by real money and insider information. That’s millions of people voting with their attention and their wallets every day. /last30days searches all of it in parallel, scores it by what real people actually engage with, and an AI agent judge synthesizes it into one brief.

Google aggregates editors. /last30days searches people.

You can’t get this search anywhere else because no single AI has access to all of it. Google search doesn’t touch Reddit comments or X posts. ChatGPT has a deal with Reddit but can’t search X or TikTok. Gemini has YouTube but not Reddit. Claude has none of them natively. Each platform is a walled garden with its own API, its own tokens, its own auth. But you can bring your own keys and browser sessions, and suddenly an AI agent can search all of them at once, score them against each other, and tell you what actually matters.

That’s the unlock. Not one better search engine. A dozen disconnected platforms, bridged by an agent.

In their own words, I was baited by the description here where they mention how their search offers conversational intelligence by pulling in info from pretty much all the biggie social platforms):

Source	What the people tell you
Reddit	The unfiltered take. Top comments with upvote counts, free via public JSON. The real opinions that Google buries.
X / Twitter	The hot take, the expert thread, the breaking reaction. First to know, first to argue.
YouTube	The 45-minute deep dive. Full transcripts searched for the 5 quotable sentences that matter.
TikTok	The creator reaching 3.6M people with a take you’ll never find on Google.
Instagram Reels	The influencer perspective with spoken-word transcripts. The visual culture signal.
Hacker News	The developer consensus. 825 points, 899 comments. Where technical people actually argue.
Polymarket	Not opinions. Odds. Backed by real money. 96% confidence on album sales. 4% on an acquisition.
GitHub	For people: PR velocity, top repos by stars, release notes. For topics: issues and discussions.
Digg	Curated story clusters from Digg’s AI 1000 leaderboard (~1000 high-signal AI accounts on X), with attributable inline quotes (no X auth required). Auto-enabled when digg-pp-cli is on PATH.
Threads	The post-Twitter text layer. Conversations from creators and brands.
Pinterest	Visual discovery. Pins, saves, and comments on products and ideas.
Bluesky	The decentralized social layer. AT Protocol posts from the post-Twitter migration.
Perplexity	Grounded web search with citations via Sonar Pro.
Web	The editorial coverage, the blog comparisons. One signal of many, not the only one.
/last30days can be used for person research, competitor analysis, feature A versus feature B, etc.

Model choices while working with coding

I mostly have subscribed completely to Peter Steinberger with the obsessive use of the Codex agents. And this is before him joining OpenAI, so I know that the initial take was unbiased.

Sometimes it just silently reads files for 10, 15 minutes before starting to write any code. On the one hand that’s annoying, on the other hand that’s amazing because it greatly increases the chance that it fixes the right thing. Opus on the other hand is much more eager - great for smaller edits - not so good for larger features or refactors, it often doesn’t read the whole file or misses parts and then delivers inefficient outcomes or misses sth. I noticed that even tho codex sometimes takes 4x longer than Opus for comparable tasks, I’m often faster because I don’t have to go back and fix the fix, sth that felt quite normal when I was still using Claude Code. — Peter Steinberger

I also don’t use the “plan mode”, when I need the agent to do a set of instructions, I say “let’s discuss”.. My approach here with building is very iterative. I am not a big fan of taking a complete spec, and putting it in a ralph loop, if that’s so easy, then that should not be a software then.

This is my current stack of model choices:

1. Codex GPT series
2. MiniMax or Kimi series (for fallbacks in case I run out of Codex credits)

The design process: sequence of steps while building apps

I follow this sequence of steps in my conversations with the agents while building 0 to 1. I’d outlined this in my previous essay (breadboarding and shaping with AI agents), and have it here handy:

This is how my current process looks like:

Step	Term	What happens	Why it exists	Output artifact
1	Vision	Describe the future state of the product	Aligns all work to a long-term direction	Vision statement
2	Problem	Identify the concrete obstacle preventing the vision	Prevents building random features	Problem statement
3	Requirements (R)	Extract constraints and must-have behaviors	Creates a contract to evaluate solutions	Requirement list
4	Shaping (Solutions A/B)	Propose high-level solution approaches	Moves from problem → possible architectures	Shape document
5	Fit Check (R × A)	Verify if the solution actually satisfies requirements	Reveals gaps, over-engineering, or missing pieces	Fit matrix
6	Spikes	Research unknown technical areas	Reduce uncertainty before architecture solidifies	Spike notes
7	Fat Marker Sketch	Sketch user interaction and visible state	Clarifies product behavior and UI affordances	Simple UX diagram
8	Breadboarding	Map system wiring (UI + code + data + services)	Convert ideas into architecture	Breadboard diagram
9	Slicing (Scopes)	Divide architecture into demoable pieces	Enables incremental delivery	Vertical slice plan
10	Steel Thread	Build the minimal end-to-end path	Prove the architecture integrates correctly	Working skeleton
11	Iterative Slice Build	Expand slices into complete features	Gradually complete the product	Production system

You might be looking at this 11 point list, and questioning why do all this?? Why can’t we just prompt in one line and be okay with whatever AI agents generate? This was my initial line of exploration, and I failed badly after encountering various bugs in the process.

Why vision first? This gives a sense of direction, especially when agents could take you anywhere, and be sycophantic when they say “you’re absolutely right!”. You need a strong, opinionated product vision.

How I start the chat:

Ask me one question at a time so we can define and shape a strong product vision for this idea. Each question should build on my previous answers, helping clarify the user, the problem, the unique insight, the product’s point of view, and the future it is trying to create. Let’s do this iteratively and focus on asking the right questions before jumping into features or implementation. Remember, only one question at a time.

Here’s the idea:

Once you get to the end of the dialogue, you then say:

use your shaping skill to capture the requirements and tease apart the key parts of solution A that I have specified here

More often than not, we give lengthy jumbled up argumentation mixing up the problem and the solution together. By doing it this way, we separate out the problem and the solution neatly.

Alongside the conventional software development lifecycle, what has changed here is me incorporating Ryan Singer’s workflow in terms of building shapes, and slices. Long story short, you don’t constrain yourself too much by finalising a “spec.md” and then telling our AI overlords to “go build it!”. That kind of stuff seldom works. Instead what I do is to come up with a few requirements/constraints, and spend more time ‘shaping’ multiple approaches. Let’s say, if you have shape A, shape B and shape C (with some unknowns on how they tie together to create a complete solution), you then spike the unknowns, resolve (or not resolve them) in the process, and come up with the right “shape”.

Once you have a shape, based on the complexity of the shape, which could be as complex as “rewrite Linux in Rust” or as simple as “build a HTML presentation deck”. If things get way way too complex, then you might also have to slice the shape into multiple pieces. Each “slice” is a demoable piece, which means it’s possible for us to feel something and feed useful information back to the agents instead of just ‘TAB, TAB, TAB, CONTINUE, ENTER, TAB, TAB, TAB…’

This is a remix, or a fork of the conventional agile development lifecycle, adapted to work better with AI agents, and I have found great results so far, especially since this is more universal go-to process that could work for the entire spectrum of simple to complex/heavy-duty stuff.

Another benefit of breaking them into such slices is to reinforce the need to split a giant agent output into reviewable pieces. You would certainly not be able to review a 15,000 line PR.

To incorporate the Shape Up methodology of Ryan Singer, here is the GitHub repo

If slicing doesn’t work, try steelthreading it..

Imagine standing at the edge of a canyon, needing to cross to the opposite cliff. One option is to construct a bridge, starting with logs, ropes, and foundations—carefully assembling each piece until a complete, safe crossing exists. This is similar to how MVPs are often built: you fully develop a core feature or component (like building an engine) before moving on to other parts, ensuring that the piece you create is robust and ready for future scaling.

In product development, a concept known as the steel thread has gained attention for its focus on creating the most direct yet robust path from concept to functionality. Unlike traditional methods such as building a Minimum Viable Product (MVP), which often prioritize incremental construction and polishing a single component before moving to the full system, the steel thread approach prioritizes end-to-end integration early on, even with minimal implementation.

The steel thread approach, however, takes a different perspective. Instead of starting with a full bridge, you imagine a thin steel thread stretched across the canyon. It represents the simplest, lightest, and most minimal path to achieve an end-to-end connection. The steel thread is strong enough to support essential functionality and demonstrates that all critical integrations work together. Even if the overall experience is barebones, the team can traverse the complete journey from point A to point B, proving that the product can function holistically.

From a product development perspective, this method focuses on building the smallest possible version of the full flow. Rather than fully developing isolated components, the goal is to establish a working skeleton that spans the entire product experience. This allows teams to quickly identify integration challenges, potential bottlenecks, and areas of risk. Once the steel thread is in place, subsequent iterations can enhance, reinforce, and expand it—eventually turning the thread into a fully realized product structure.

By prioritizing end-to-end connectivity over depth in one area, the steel thread approach offers several advantages:

• Rapid validation of system feasibility
• Early identification of integration issues
• Efficient feedback collection on the full user journey

In contrast to building a polished engine first (the MVP approach), the steel thread demonstrates the viability of the whole vehicle—even if, at first, it is only a bare-metal prototype. Teams practicing this method move faster toward functional products and discover critical insights earlier in the development lifecycle.

In short, the steel thread method is about achieving the simplest full journey before committing to deep, complex builds. It highlights the importance of robust integration early, providing a strategic pathway to scale confidently and efficiently.

Ensuring that the design in the design process is coherent and consistent..

My mantra here is to first make it work, then, make it fast, and then, make it delightful.. Form should follow the function. And when I reach this stage where I’m happy with the functionality, and there aren’t much glitchiness to the way it achieves its core function, I move on to the design bit.

Hardik Pandya, in his essay — Expose your design system to LLMs, talks about how LLMs undergo design drift, and why it’s important to feed the design system to the AI coding agents, to make it stop guessing.

To achieve a consistent and coherent way of presenting the interface for my app, I set up a design system if I haven’t already. In case of brownfield apps, I use /design-audit skill, inspired by this essay, to comb through all the patterns it could find and translate it into the right theming. This then becomes a ‘DRY’, where I wouldn’t have to repeat myself to the agents for the 100th time.

You could place this at the root of your project:

Audit this project and make the design system LLM-readable.

Step 1: Audit
Scan every CSS/SCSS file. List every hardcoded visual value:
hex colors, rgb/rgba colors, pixel spacing, raw font sizes,
font weights, border radii, z-index values, box shadows,
and transition durations. Group them by category. Count totals.
Report which files have the most hardcoded values.

Step 2: Token layer
Create a tokens.css file with three layers:
- Layer 1: upstream design system tokens (use existing ones
 if the project already uses a design system, otherwise
 derive sensible primitives from the audit)
- Layer 2: project aliases that reference Layer 1 with
 fallbacks, e.g. --color-text: var(--ds-text, #292A2E)
- Layer 3 is the components themselves — they only ever
 reference Layer 2 aliases, never raw values

Include tokens for: colors (text, background, link, border,
interactive states), spacing (at least 8 steps), typography
(font families, sizes, weights, line heights), border radius,
elevation/shadow, z-index, and motion/transitions.

Step 3: Spec files
Create a specs/ directory. Write structured markdown specs:
- specs/foundations/ — color.md, spacing.md, typography.md,
 radius.md, elevation.md, motion.md
- specs/tokens/ — token-reference.md (master map of every
 CSS variable, its value, and when to use it)
- specs/components/ — one file per major component in the
 project. Each spec follows this template:
 1. Metadata (name, category, status)
 2. Overview (when to use, when not to use)
 3. Anatomy (parts of the component)
 4. Tokens used (which CSS variables it references)
 5. Props/API (if applicable)
 6. States (default, hover, active, focus, disabled, error)
 7. Code example
 8. Cross-references (related components)

Only spec components that actually exist in this project.

Step 4: Audit script
Create scripts/token-audit.js (or .sh) that:
- Scans all CSS files for hardcoded values
- Suggests the correct token for each violation
- Prints file, line number, violation, and suggestion
- Returns exit code 1 if any errors found (CI-ready)
- Distinguishes errors (hardcoded colors, spacing) from
 warnings (raw durations, uncommon values)

Step 5: Replace hardcoded values
Go through every CSS file and replace hardcoded values with
the tokens from Step 2. Every color:, background:, padding:,
margin:, gap:, border-radius:, font-size:, font-weight:,
box-shadow:, z-index:, and transition: should reference a
var(--token). No raw values should remain.

Step 6: Project instructions
Add a section to the project's AI instruction file (CLAUDE.md,
.cursorrules, or equivalent) that says:
"Before writing or modifying any UI code, read the relevant
spec file in specs/. Use only tokens from tokens.css. Run the
token audit script before committing. Zero errors required."

Run the audit script at the end and confirm zero violations.

It also happens that AI still makes a lot of common mistakes on spacing, typography, hierarchy, etc., which a very keen design engineer who is trained for that eye can spot, I use /design-type for such tweaks that get repeated.

This is the current list of design specific skills I use, and you could remix or fork them by clicking here.

design-audit	Produce a comprehensive UI audit across accessibility, performance, responsiveness, theming, and UX quality.
design-bold	Make safe or boring designs more visually striking.
design-color	Add strategic color to monochromatic or visually flat interfaces.
design-critique	Evaluate a design’s product and UX effectiveness.
design-delight	Add personality, joy, micro-moments, and memorable touches to interfaces.
design-distill	Simplify designs by removing unnecessary complexity.
design-extract	Extract reusable components, tokens, and design patterns into a system.
design-layout	Improve spacing, rhythm, composition, and hierarchy.
design-minimal	Create clean editorial minimalism with restrained warm monochrome styling.
design-motion	Add purposeful animations and micro-interactions.
design-normalize	Align a feature with an existing design system and component language.
design-polish	Perform final pre-ship UI refinement.
design-premium	Create expensive, cinematic, agency-crafted interfaces.
design-quiet	Tone down overly aggressive or loud visual designs.
design-responsive	Adapt designs across screen sizes, devices, and contexts.
design-systematic	Build stricter frontend design systems and measurable UI implementation rules.
design-type	Improve typography, font hierarchy, sizing, weight, and readability.
design-ui	Create distinctive production-grade frontend interfaces from scratch or through major redesign.
You could download my total list of skills here: https://github.com/shreyas-makes/agent-skills

Ensuring the code generated is clear, and reviewed

If you have read the theory of constraints, you would know that a bottleneck is never completely eliminated, it just shifts from one place to the other. Previously we had the bottleneck in terms of generating or writing code, that was a bottleneck. But then once the coding agents were able to like solve that bottleneck, the bottleneck just shifted to code review. Which makes the need for having better tools to support code review, even more important.

There is even an argument floating around in the internet that there is a cost to accelerating the code throughput without reviewing the code properly, leading to complex failures which are harder to resolve, by AI agents, as well as by human engineers. But for which I would say that the only metric that matters are the number of decisions that could be taken per day. At normal velocity, a team might make one or two decisions per week, but at 10x velocity, you see them making multiple a day. The usual bottlenecks where you’re waiting for a slack response, or for scheduling a quick sync later, no longer exist.

I’ve previously used the /review tool available in most coding agents, and yet, the fundamental question which I still don’t have answer to is: if the language models need a separate tool for code review, why can’t it just stitch the review loop onto the code generation? Currently, I’m a bit skeptical about code review, and think this would eventually be a part of the code-generation loop.

Right now, after a major feature update, I try to ask the agent its plan before it writes any code (so that I could perform some pre-emptive strikes), and ask it in plain English what it has written. In a previous note on this topic, I write about how the top layer and bottom layer should still be done by humans, leaving the middle layer for the AI agents:

The AI sandwich technique outlines a structured approach where humans and AI agents collaborate effectively.

In this model, the top layer involves human input, where goals and instructions are clearly defined by humans. This ensures that the desired outcomes are aligned with human intentions. The middle layer is where AI agents take over, handling the orchestration, execution, and processing tasks. This allows for efficient and automated handling of complex operations. Finally, the bottom layer involves human evaluation, where the output is assessed based on subjective human taste and feedback. This ensures that the final result meets human standards and expectations.

Think of the end game polishing done by humans, akin to how pilots and co-pilots still have the final call on the airliner they’re operating in, despite all the automations at place that could technically automate the role of the pilot, but not in principle.

A concept which I recently became aware of is that of a backpressure. It’s described as a pressure which arises from failed builds/tests that pushes the model loop to improve output.

Templatize everything that needs templatizing

If I have already built the feature successfully somewhere else in a different project, I cross-reference that successful implementation to the AI agents for helping diagnose what’s wrong.

I’ve already mentioned my way of planning a feature. I cross-reference projects all the time, esp if I know that I already solved sth somewhere else, I ask codex to look in../project-folder and that’s usually enough for it to infer from context where to look. This is extremely useful to save on prompts. I can just write “look at../vibetunnel and do the same for Sparkle changelogs”, because it’s already solved there and with a 99% guarantee it’ll correctly copy things over and adapt to the new project. That’s how I scaffold new projects as well.

I started templatizing patterns across projects because I was spending too much energy repeating setup decisions in every new repo: how to plan work, how to enforce coding preferences, how to deploy etc. The core idea is simple: separate reusable workflow rules from project-specific code. That gives me a stable operating layer across all work in ~/Projects, while still letting each project keep its own context.

Instead of reinventing process every time, I reuse a consistent scaffold and only customize where the stack or business logic actually differs.

The agent-scripts model came from studying Peter Steinberger’s setup and adapting the parts that matched my own way of working. I kept the structure but changed the intent: a global rules file for hard constraints, stack-specific profiles for Rails Inertia vs Next.js vs Tauri behavior, and command-like prompts for recurring actions such as build, review, research, and ship.

1) Folder/System View
/Users/shreyas/Desktop/Projects/
|
+-- agent-scripts/                    <-- YOUR canonical workflow system
|   |
|   +-- AGENTS.md                     <-- global rules (always-on behavior)
|   +-- stack-profiles/
|   |   +-- rails-inertia.md          <-- stack-specific rules
|   |   +-- nextjs.md
|   |   `-- tauri.md
|   +-- prompts/
|   |   +-- build-feature.md          <-- reusable command templates
|   |   +-- review.md
|   |   +-- research.md
|   |   +-- ship.md
|   |   `-- inspire.md
|   `-- skills/
|       +-- build-feature/SKILL.md    <-- execution workflow skills
|       +-- review/SKILL.md
|       +-- ship/SKILL.md
|       `-- inspiration/SKILL.md
|
+-- my-saas-app/                      <-- your real project
+-- next-app/                         <-- your real project
+-- tauri-tool/                       <-- your real project
`-- others/                           <-- external repos, reference only
    +-- cool-ui-repo/
    `-- random-oss/

In my day-to-day workflow, it looks like this: I open a repo, trigger /build-feature, get a short plan, and then let the agent execute within the detected stack profile. If I get stuck, I run /inspire, which inspects relevant repos under ~/Projects/others and returns transferable patterns without copying code. Once implementation is stable, I run /review for risk-first feedback, and only invoke /ship when I explicitly want release actions.

While inspiration-seeking, I also identify some starred GitHub repos that can hold some clues and examples that could be applied to the current problem at hand.. when that happens, I clone that repo into the Projects/others/ folder and then chat with the repo with a prompt that looks somewhat like this:

read the code for this repo and write a markdown doc telling me everything you can infer or know with certainty about the high-level intent and idea behind this repo ask me questions for anything that isn't clear then pop open the doc for me to review and answer the goal here is to make sure my intent is obvious to any agent reading this code

Closing thoughts

I just want to close by saying that purely spec-driven development, where you make a “perfect” spec to send it to the agents on a ralph loop is not going to work. These are for the same reasons why we have moved away from waterfall to agile, they are still the same reasons. We sometimes revert our earlier decisions, cross over or even contradict what we might have said earlier, as every new iteration of the product is a learning for us, and new facts could evolve.

One thing that’s clear from this exercise of writing this essay is that software has started transitioning from a software development lifecycle, to a “context development lifecycle”, aka CDLC. SDLC, is now being offloaded to agents, with utmost trust, where engineers are now involved in maintenance of context, which constantly gets updated over time, and needs a human owner for its reliability.

I keep mistaking the kekulean loop, for a line.

I see a thing called a “problem”, and another thing called a “solution”, and I imagine the first one comes before the second. I see a person called “religious”, and a set of rituals called “practice”, and I imagine the belief came first and the practice merely expressed it. I see “aging” and “disease”, and I imagine aging as the background condition, while diseases are the foreground enemies we are meant to defeat.

In this essay, I will try to chalk out three such examples, to illustrate the point. By the end of this essay, I want the reader to think, if they have any such kekulean loops, they are mistaking for a linear line?

• the problem and solution co-creative loop
• the belief and practise co creative loop
• the aging and disease co-creative loop

the problem and solution co-creative loop

In my first career arc of being an inexperienced product practitioner, I used to think of the problem and the solution as a traditional waterfall.

You think of the problem, define the constraints, check. Head to explore solutions. Check. Finalise the solution. Check. And then pass it on, and move on to the next problem <> solution. It was supposed to always point right —>

It took me that entire decade and a Masters education in design methodology to help me realise that it seldom works that way, in reality. Problem and solution pairs are having a kekulean dance with each other, eating each others tail, biting and pouncing at each other until they end up with a better problem and solution pair.

There is a co evolution which we miss noticing. In retrospect, it felt fairly obvious and I was scrutinising myself as to why I needed a masters education in design theory for me to realise this trivial aspect of life.

the belief and practise co creative loop

After all, life is nothing but problem solving right? How can I get this all wrong for something so fundamental?!

I also then realised that I make the same mistake in other aspects too. I have been mistaking bidirectional pairs for unidirectional pairs the whole time.

I’ll give another example of such a mistake from my most recent reading of the book review of Tanya Luhrmann’s How God Becomes Real by Michael Nielsen:

Tanya explores the relationship between belief and practise in this book. I used to think that people who are “religious” by spirit, also do practise a lot of rituals because they’re religious. Atleast that was the notion I was used to hearing. However, Tanya explores a different dynamic where she suggests that practise itself by virtue of practise — practise instils belief.

Tanya M. Luhrmann has written a beautiful book exploring this question, “How God Becomes Real: Kindling the Presence of Invisible Others”. The book explores the idea that much of the purpose of religious practice is to help practitioners believe. This inverts conventional wisdom, with Luhrmann taking seriously the possibility that sometimes people aren’t worshipping because they believe, but rather believing because they worship. More generally: Luhrmann makes a compelling case that there is a much more complex relationship between belief and religious practice than you might naively suppose, and she explores some of that relationship.

Personally, I come from the other side of the spectrum where I want to be religious for some reason, and I lack embedding some rituals in my day to day. This thought that religion and practise are a co-evolutionary loop gives me great hope. I’ve envied my mom, and my sister in the way they have cultivated their faith through practise: which involves chanting Hanuman chalisa, Vishnu sahasranaamam, Lalitha sahasranaamam etc and various other mantras in the evenings as a part of their daily/weekly/occasional puja rituals.

Right now, It’s 6:15 PM at dusk, an auspicious time usually meant for evening prayers, and here I am talking about the process of Bhakti (practise of worship), rather than doing the practise itself. Religious belief isn’t something that’s easily attained or endowed with, and it’s hard to tilt towards a religious worshipper from a somewhat-agnostic mode:

Let me review a few of the moves Luhrmann makes in setting up her project. She points out, convincingly, that religious belief usually isn’t something easily attained, despite the fact that many theories of religion “presume that belief is direct and unproblematic – that in most cultures, people simply take spirit and the supernatural to be there. That doesn’t make sense. Gods and spirits cannot be seen. You cannot shake their hands, look them in the eye, or hear their voice when they speak. It seems odd to assume that people just take for granted that they are present.”

I find it weird when I say this, but knowing this theory has actually made me more religious. It has given me more meaning to what’s interpreted as practise.

From the day I read this book review article on the co-evolutionary loop phenomenon exhibited by religion and practise, I am not able to unsee these patterns applied across everywhere. And there are more..

the aging and disease co-creative loop

I sometimes wonder if it’s a cognitive psychology flaw where we mistake such systemic effects.

Aging is considered from the ancient ages to be a linear line. We grow old, we age, and we die. However, in the recent past, this notion has been contested, with the bet that aging is a disease which can be treated. We now have scientists trying to reverse the age of human cells, and we now have clinical trials trying to prove this more recently. Newlimit is one such company, working in this bleeding edge of longevity with the same thesis that aging is the root cause of most major diseases (resulting in loss of function in our cells).

if you’re under 50, cellular reprogramming drugs are how you’ll live to 150.

even if we cure every disease on Earth, that still wouldn’t get you there on its own.

the oldest person who ever lived, jeanne calment, made it to 122, and in almost 30 years nobody has come close to beating her.

120 is just the natural human limit.

so while curing diseases can keep you healthy right up to that limit, it can’t actually extend the limit.

but what if you treated aging itself as a disease, and cured that?

that’s exactly what brian armstrong’s company just raised $435M to do.

NewLimit is working on something called cellular reprogramming.

in plain terms, every cell carries a set of instructions that decide how young or old it behaves

NewLimit uses RNA to switch on the combinations that make an old cell start acting young again.

they already have a prototype that does this to human liver cells, healing the liver faster after injury and speeding up recovery from alcohol damage.

the first human trial is set for 2027.

now, to be clear, solving aging is unfathomably hard.

this first liver drug is one cell type in one organ, and reversing aging across an entire body is a much bigger problem than repairing the liver.

but the reason it’s even on the table now is AI.

there are more possible combinations of those cellular instructions than any human could test by hand in a billion years

but machine learning is what lets you search that space and find the few that actually make a cell young again.

that’s the bet NewLimit is built on.

so the liver is the proving ground. once you can safely reset the age of human cells there, 120 stops being a fixed ceiling.

cellular reprogramming is the real path to 150, and if you can keep resetting the clock, there’s no obvious reason it has to stop there…

• From anon, Twitter

question and answer is also a co-creative loop

This is also one of the most obvious.

This is also one of the reasons why therapy works. It’s just manipulating words in a special and unique way to bring out comfortable and uncomfortable subjects and objects into the conversation

Also telling and listening, has a similar relationship

https://open.substack.com/pub/velvetnoise/p/the-best-conversations-help-you-hear?r=1cfkf&utm_medium=ios

closing thoughts

It’s all in an ultimate evolutionary loop. And we fail to realise the systemic complexity hidden underneath the everyday narratives.

Most of us are primed to think linearly with “X causes Y” logic, but we have to adopt a systems thinking lens, and I’m trying to train myself here with the notion that everything is a system (X causes Y, which feedback’s into X again..), and it’s not easy..

I will keep hunting for more such co-creative systemic loops. And I hope to find more.

You’ve heard of TDD, and more recently also SDD (spec driven development)… but have you heard of HDD — aka Hammock driven development?

I recently came across a video gifted to me by the YouTube algorithmic gods with a catchy enough title that sounded more like a “honest bait” than a clickbait, it was titled: “Hammock driven development”, talking about an alternate approach to software development. I’ve currently been thinking a lot about various new processes that could improve software development, and this lecture from Rich Hickey from 13 years ago seems like one of those older ideas that need a new revival story. Especially now.

So I jumped right in.

I try here to write in my own words what I understood from the lecture and not refer to any of the supporting transcripts or Youtube timestamps (it’s now ‘fresh’ in my mind and want to make use of this moment in time)

---

We have two types of minds: the waking mind, and the background mind. Historically we’re quite used to the system 1 and system 2 framing by Daniel Kahnemann, but this is far more encompassing than I’d expected, the background mind here, the OP refers to being generally good at strategic, holistic thinking.

You would normally want to leverage such strategic tasks for the background mind. Not that the waking mind doesn’t do strategy, but it’s more focussed on the input <> output processing. And as such its results are much more strategic and immediate output oriented. The OP then suggests to leverage this partisanship to our interests.

While writing code, we are thinking through problems and we should first know how to draft a problem, and this could be in terms of scope, constraints, framing etc, we need to get that right first, and then when we have to start solving problems, at times we might encounter harder problems which were not used to encountering before (not the usual fetch from a dB and display it on the CRUD UI types).

When this happens, we then need to think and segregate such problems into the known types which can be easily done by the ‘waking mind’, and the harder subset which needs to be delegated to the background mind. The background mind works in interesting ways, you would not know in advance what the solution might be, you just need to assign it to this background mind and see what the ‘eye of the mind’ unravels.

But you will get there nevertheless, and to let this slow burn process happen without any stress it needs. In fact stress environments make you go into the ‘waking mind’ mode, and you would not be able to do the slow burn. That’s also one of the reasons why this should be done through a shower thought.

OP also recommends Michael Poyalyi’s How to solve problems book as it gives a much more mathematical rigour to the varied approaches to solve problems. There is another book I was able to find on the YT comments called ‘How to solve with computer’ that gives an algorithmic perspective to solve problems. This is another one on my Umberto Eco’s antilibrary style to-read list.

This time when I listened to the lecture, it hit me in a different way especially since I’ve also been fascinated about the AFK (away from keyboard) and HITL (human in the loop) segregation of work by Matt Pocock, an AI tutor who recently shared this in his talk at the AI engineers forum.

The AFK mode is usually for known solved problems, it’s similar to the waking mind for the agents, where they could run autonomously and completely solve the problem/s without causing much tech debt.

The HITL mode is usually for problems that require a feedback-loop type dynamic with humans to provide the right inputs for it to solve the problems better. This works well for human guidance aided by the right ontology. In the HITL mode, for example in case of 1 and 2:

1:

“I have a deep pimple only on my chin is it more likely from diet or hormones”

2:

“sudden cystic acne isolated to chin, is the more likely etiology hormonal fluctuation or pro-inflammatory gut disruption from dietary changes?

Both 1 and 2 are effectively the same question but 2 provides you vastly different (and better) responses. There is also a Harvard AI safety study which talks about this method, where changing ontology provides different responses.

And for AFK mode, you might not even need such thoroughly grounded ontology. It gets the aim, the objective and the steering right in one go.

Now coming back to the original topic by OP about the waking mind and background mind, and also finding similar analogies in the agentic coding world with the AFK and HITL types, I do think there is a bigger set of problem space where despite the best of agentic coding modes, both HITL and AFK, you would need to consciously use your background mind, for days, weeks or months to probably crack the code.

This process might take days, or months. A question I have for the reader here is how rare or common has it been for you to be in this background mind mode trying to solve a hard problem? Me, personally, it’s been quite rare. It’s such a terrific experience to be in this mode of problem solving, where you don’t want to be disturbed, and neither do you should be in front of the computer.

You should be lazying around, doing random chores, or as the OP suggests, if you do have a hammock in your background, then that’s all you need.

Recently I had made a digital painting on Procreate, this was describing the Hindu deities in the Kerala mural art style. What I painted doesn’t matter much for this story, but what I wanted to share was the way in which this digital painting was printed and framed. Naturally, I was interested to get a quote from multiple printing vendors in my hometown, Thrissur, to compare the prices and see which one offers the best price at the best quality of service.

I instinctively went for three quotes from different vendors for comparison, and I asked myself why did I settle for three? Couldn’t I have picked four? Or why not just one, or two, or seven, for that matter.

Another thought which stuck me here was the analogies the three-quote selection process was similar to the teachings I had had during my design studies at Delft University. The professors always used to point out that while hunting for solutions it’s always best to choose three solutions of equal fidelity, navigate the tradeoffs and constraints through user testing and then arrive at the final solution. And this was similar to the vendor selection process, which intrigued me about the unique nature of the three options.

What kind of psychological window does it offer to help take better decisions? With just a single option to choose from, you’re not thinking about alternatives, so it might mostly be a wrong decision with a huge sunk cost attached to it. With two options, my suspicion is that you are too focussed on steelmanning and straw manning both the sides engaged in a Hegelian dialectic, that you don’t really think outside this context window.

In the design process, when you have to arrive at three options which are more of less similar, you would also have to do a lot more preparatory work to make them more or less similar, and also harder to make a quicker decision on which is a best option. In an ideal world, the options available have all their own unique advantages, and while evaluating, we start thinking hard about the tradeoffs, the constraints, and by the merit of thinking hard about the constraints, we might arrive at a unique solution. With three options, you can still hold the solution space entirely in your head.

With four, it might probably be too exhaustive that you end up losing the sight of the forest over the trees.

If we look closely, the rule of three manifests everywhere, and I now think it has to do with the ability to hold the three options properly in our head. Take storytelling, and you see this as “beginning —> middle —> end”. Or the three click-rule in UX, or even in religion where you see the trinity in Christianity, and trimurthi in Hindu traditions. My theory here is that the comfort of using three has a lot to do with the way it sits neatly into our funny little brains, and less with how the numerologists or the astrologer soothsayers would like to point out..

The AI sandwich technique outlines a process where certain phases of product development are led by AI agents, while others require human intervention. The phases led by AI agents include planning, coding, reviewing, testing, and creating pull requests (PR). These tasks are automated to enhance efficiency and consistency.

In contrast, the phases that should be human-led are brainstorming (deciding what to build) and polishing (ensuring the product is of high quality). These stages require human creativity, judgment, and critical thinking, which AI agents cannot fully replicate.

The AI sandwich technique outlines a structured approach where humans and AI agents collaborate effectively.

In this model, the top layer involves human input, where goals and instructions are clearly defined by humans. This ensures that the desired outcomes are aligned with human intentions. The middle layer is where AI agents take over, handling the orchestration, execution, and processing tasks. This allows for efficient and automated handling of complex operations. Finally, the bottom layer involves human evaluation, where the output is assessed based on subjective human taste and feedback. This ensures that the final result meets human standards and expectations.

Think of the end game polishing done by humans, akin to how pilots and co-pilots still have the final call on the airliner they’re operating in, despite all the automations at place that could technically automate the role of the pilot, but not in principle.

The technique is particularly effective in scenarios where outcomes can be verified, such as in RLHF (Reinforcement Learning from Human Feedback) environments. Initially, human feedback is crucial, but as the AI system becomes more proficient, the need for human intervention decreases. The analogy of a sandwich or an airliner illustrates this process, where humans set the course and make critical decisions, while AI agents manage the routine operations. This collaborative approach leverages the strengths of both humans and AI, ensuring optimal results.

I’ve updated my writing process and workflow for 2026, and the main reason I am revisiting it is because the process itself has started to change in a meaningful way.

Writing is no longer just about producing an essay. It has become a feedback loop where each draft I produce also acts as training data. I’ve naturally been interested in the gap between what AI generates and how I would naturally write is something I am now actively trying to close. Every piece I write contributes to that. The process I am describing here is not just how I write, but how I am shaping future AI outputs to sound more like me. In a way, this essay itself is part of that loop, and I’m naturally interested in the end game, where the AI sounds exactly like me; we’re not even 50% there yet, but curious how this would unfold..

While doing this, I’ve also ensured the principle source of the “key idea” still comes from me, it should resonate with me first, and the integrity of this nature continues to remain uncompromised.

To talk about my writing process, it begins long before I open a document. It starts with a running surface of thoughts that I maintain in Trello.

This is where everything goes first, without pressure to make sense. Ideas arrive as fragments, questions, contradictions, or half-formed intuitions. I don’t try to structure them immediately. What matters is that they are captured quickly. Over time, some of these ideas begin to stand out. They survive small acts of revisiting, get slightly reworded, or start to point in a clearer direction. Sometimes I had a good image thumbnail, to entice myself in drafting the essay further. When an idea feels like it has “hit home”, it shapes up to be explored further, it stops being just a card and becomes something I want to work on deliberately.

That is the point where I move it into Obsidian. This is where the rest of my personal knowledge base resides, and which I now try to take advantage of through a compounding loop which I will talk later about.

I create an Obsidian note with the intention to shape this into an essay, YouTube video, Substack article or anything else. Around it, I begin to gather material. This includes articles, essays, research, and most importantly, my own past writing that might connect to the same theme. The vault becomes a kind of extended memory. I follow links, revisit old notes, and slowly build a context around the central idea. Sometimes this expands what I already think. Other times it challenges it. Either way, the idea becomes less isolated and more dimensional.

As the material builds up, I move into a more deliberate way of processing it using the Zettelkasten approach. I have started to think of this stage as a process of crystallization. Ideas, when they first appear, are in a gaseous state (in this case, the ones that are first documented on Trello). They are diffuse, free-floating, and difficult to pin down. You can sense them, but you cannot yet hold them. As I begin working through notes, something changes. Writing reference notes and especially literature notes from memory forces the idea to condense. It becomes more coherent, more bounded. This is the liquid state. It can still flow and change shape, but it has a form that can be worked with.

During this process of working with my drafts on Obsidian, I also use tools like Enzyme, to start making more semantic connections with my existing notes on the vault. Connections appear between ideas that did not seem related at first. And then, in writing permanent notes, the idea crystallizes. It becomes solid. It takes the form of a single, clear, self-contained thought expressed in my own words. At this point, it is no longer something I am trying to understand. It is something I can use.

The Zettelkasten process, for me, is fundamentally about taking ideas through these states, from gas to liquid to solid, until they become stable enough to build with.

Some ideas still feel unclear even after this. They might have internal tension or multiple possible interpretations. Or might even lack proper framing.

In those cases, I use the Hegelian dialectic to shape them further. I take an initial framing and push it as far as it can go. Then I construct an opposing view and strengthen that as well. The goal is not to balance the two, but to force both sides to become sharp. What emerges from this is usually a better articulation of the idea. Sometimes it is a clearer position. Sometimes it is a reframing that resolves the tension altogether. Often, it simply results in better wording that feels more precise.

Once the idea feels clear enough, I start assembling it into a draft. This is where I bring together the different notes and arrange them into a sequence that makes sense. I pay a lot of attention to what deserves to be central and what should remain in the background. Not every idea should carry the same weight. There is usually one core message that I want to drive, and everything else either supports it or stays peripheral. This shaping is important because without it, the writing tends to become scattered, with too many ideas competing for attention.

If I have used any AI-generated text in the process, I clean it up at this stage. I remove phrases that feel generic, sections that over-explain, and structures that feel predictable. The amount of AI-generated text might vary essay by essay. Sometimes I just ramble on my phone (ChatGPT dictation on chat threads work quite well), and then convert this messy rambling into a AI generated first draft.

The goal is not just to simplify, but to make the writing feel specific and grounded. After this, I don’t treat the draft as final. Instead, I use it as a reference and start writing again from scratch. I type everything in my own words. This helps me rebuild the flow in a way that feels natural to me. While doing this, I also pay attention to how I feel about what I am writing. There are moments where the writing needs more intensity and others where it needs restraint. This emotional alignment is something I can only achieve when I am actively rewriting rather than editing.

At the end of this, I have two versions of the same piece: one that came out of the structured process and another that reflects how I naturally write. I treat this as an input-output pair to train a custom agent skill that I’ve developed to make the AI generated writing write like me.

Over time, I am collecting these pairs with the intention of using them to train models that can better match my style. The idea is that the gap between what the AI produces and what I would write myself keeps shrinking. It is not something that happens instantly. It improves gradually as more examples accumulate, and every essay I write contributes to that convergence.

Once the writing is ready, I turn it into an artefact. Sometimes it remains a blog post. Other times it becomes a rough note or evolves into something larger like a video.

Alongside this, I am building toward a system where a persistent agent takes over distribution. I use a Hermes agent for this, a self-evolving memory layer that can run independently and learn from how I write, what I publish, and where it performs best. The direction is for it to eventually handle publishing across platforms on my behalf, adapting the same core idea to different contexts without losing the original intent. It is still a work in progress, but it is the natural extension of the system I am building.