Writing as a thinking tool
muratbuffalo.blogspot.com
muratbuffalo.blogspot.com
The problem with AI writing is that it makes people believe that writing is just writing and not a tool for thinking very deeply about the topic you are writing about. I am not completely opposed to AI assisted writing, but if I see AI writing, it’s telling me that the author tried to take a shortcut in their own thinking and it’s a good heuristic that the ideas will not be thought through enough to warrant my complete attention.
I think if I used AI for the actual writing then, (a) there’d be a lot missing, and (b) I’d rob myself of much of the value, in better understanding, of writing myself.
We’re not all the same so YMMV, but this is what I’ve found from using AI in various ways to see if and how it can help with writing.
The feedback bit is surely more debatable, but I would argue the initial writing and allowing edits are not.
https://antoaenono.com/write/fragments/writing#:~:text=never...
With respect to seeking feedback, my angle is that: even if you do agree with the feedback then what they do. Are you going to take it as is? Are you going to come up with it and phrase it in your own way?
What next? Next, what if there's a bunch more feedback that you agree with and you incorporate it. Then, where do we go from there?
Can you even go back to (b) and make your own edits at this point? I'm not sure and I worry about a slippery slope where you stray too far from your own original form -- so I landed on not seeking feedback either.
note: this all is definitely under progress and as I'm looking at it it's very noisy with all of the formatting... just finally getting my site put together
also not sure about my fish progress bar hah
I tell mine that line editing and formatting are the very last polish.
For audiobooks, I seem to not have as much of a tendency to pause the audio and stop and think, and it’s harder to reread a passage, so it’s a more passive experience.
For online content, there’s not as much of an intention to fully engage with the material. It’s easy to skim or switch to something else.
Thanks for writing that down. It explains in simple terms the difference
Even worse: Facing AI writing, there's a strong suspicion that any concerns or counterpoints you bring won't be actually considered, but rather copypasted into an llm session.
Ironically, that led to a Agile™ consultant-industrial complex that tried to make it a cookie-cutter process again, but we still haven’t escaped the need to break out the IDE and actually put idea into something concrete, and I doubt we ever will.
The writing is downstream of that.
you can dump your thoughts and constraints you can think of, and have it work through untangling, or use it as a summarizing notepad, or yo prototype what you are thinking about in different variations.
its no replacement for pen and paper, but no typed or drawn on tablet picture comes close to a real notebook to scribble on its entirely a thinking tool, as much as a skip-thinking tool
The act of vetting it and finding the failures will increase understanding, but at a cost in speed over doing the research from scratch. (Generating subtly wrong text is often a good way to test understanding, and the output of AI systems is typically a mangled clone of some other well understood system. A very good exercise is building your internal pattern recognition so you can tell what's been mangled, mashed, and served up)
AI is very good at making the mash sound plausible, however, so if you don't look extremely closely, you end up repeating instead of dissecting it. And if you're hoping to learn from the AI how to design a system, you're in trouble.
I used to have a real complicated dilemma on which content exactly to write (& then share), I recently started using handy's TTS and storing it in my scratchpad app within my native language or English and then I paste it into Chatgpt and use its memories to connect with other previous discussions I had.
It helps in saving thoughts which would've otherwise been lost, even provide some new perspectives and get them in a way that I can access them later in more depth.
I think that if I were to now create blogs of these contents. I used to think that it would perhaps be okay to share an blog like thing created by AI if say I spent 10-20 minutes thinking of the rough draft of it, but after reading your comment, I am reflecting on the fact that, atleast once, people should write things themselves no matter which AI thing they use before creating blogs.
As the point of blogs shouldn't be to share unlimited content but rather that it is the specific content where a human effort was placed. Maybe if one still wants, there could be some other blog post which could be written with all the AI blogs content I have created perhaps but still, it should be seperated away from human content.
And there is this fact that as you mention, writing itself forces you to think through ideas and thoughts which are highly relevant. So previously when I used to think that re-writing them would be a waste of time and that AI writes them good enough. I think that writing them still might make a lot of sense as it would be a net benefit if not for anybody else, then for me as it can help me better understand the material myself (even more so than reading/speaking it)
The most typing/writing of myself now occurs in Hackernews comments for me and I do observe that I learn a lot writing them personally.
In writing and designing I think we often have a thought-feeling first: something inchoate that we can’t quite articulate yet. Getting directly to the medium itself — text or frames and layouts — is how we give shape to that feeling and turn it into a concept, insight or design.
I haven’t found this to be true but it could well come down to the type of design work I do. I’m usually working on new features for complex workflows within an already complex app. When I’ve tried to yolo designs with LLMs they never come up with elegant visual or UX solutions. They’ve been occasionally useful as a way to get something on the screen that I can work against — ie “well that’s clearly wrong in these 20 ways” — but at that point I usually then reach for figma so I can just do the damn thing myself.
Agree about the more complex design options it opens up, I just haven’t had call to do much in those spaces yet.
When you are writing code manually, actually you are thinking about what you are doing, what you will build actually, what are your or users' real requirements, etc.
I don't use it too often because of the time it takes, but for critical work it is really good.
I have tried to come up with other equivalent ideas, like asking questions about a specific aspect of a feature, or showing the diff with some gaps to be filled, and even though they help I am still on the look out of methods to "imprint" the understanding of features into our brain.
Does anyone know any good papers or studies that could be useful in this research?
When I get it on paper and everything feels right I start creating the codebase but I have to get it down first, feels like I remember it more after I save my thoughts to external paper storage.
There is something about the complete free form nature of pen and paper that makes me think better, I bought a nice ipad/pencil a few years ago thinking that would replicate it but it didn't, it was closer but not close.
If it's something I want to keep I just take a photo but vast majority of notes are transient anyway.
I made a little system where blue diagrams are services I need to code and host like a nodejs server
green is stuff I need to host only like nginx, but no coding
red is external infra I can't control at all, like Anthropic's API.
And then I make drawings of how I connect them and in the end I just generate the code, so I go from pen and paper to claude code.
For thinking, nothing beats handwriting. It's just the unconstrained freedom of movement in every direction, shape or form, and the lack of friction and distractions.
But then you sometime also want to organize or share stuff, so that's where digital comes in. I have an automation that takes a photo of my notes with my phone, uploads it to Obsidian, and OCRs it into markdown and tags it, so I basically end up with a "symbolic" 1-1 equivalent of analog handwriting + digital text
My system still evolves, but what I currently use is:
Color: - black = just "normal" text - red = critical/"must" - yellow = important/"should" - green = highlighted/"could"
Symbols: - bulletpoint [ ] task -> reminder
I also do brackets and underlines which translate to # heading1 and ## heading2 in markdown
I write by hand with a fountain pen with black ink + use 3 fineliners and small colored sticky flags.
Some observations: - yellow is not great on white paper due to bad contrast; it also rarely comes as ballpoint, but fineliner options are available - blue and green are visually very similar, to the point of kinda being redundant - for sharing with other people, the system must be as generally understandable as possible. Here the traffic norms such as ISO 7010 (https://en.wikipedia.org/wiki/ISO_7010) could be considered - also there's the aspect of accessibility, with a relevant portion of population being colorblind - The simplest most effective system seems to be: one main color (black or blue) and one highlight color (red I think works best), plus a couple of symbols such as bullet point, task, reminder that translate well into markdown
I really think we could go back to pen and paper fully for software design.
It sounds like you have some stationery recommendations!
I'm always in the market for really-good-but-not-expensive pens.
https://flow-six-henna.vercel.app https://github.com/sno6/flow
(Fully local btw)
From there i kinda just moved on and write purely for myself, and use it to up my own thoughts. Very rarely, something will receive a second pass days later, and thats just more to go back on my past thoughts and try to tighten them if i feel that is needed.
I tend to split my day into two parts, my work hours and my "unplug" hours, and the writing was mostly landing in those unplug hours as a way to sorta summarize my day. Last week or so I decided im moving that writing into the very first thing I do each day, and it has really been absurdly effective at getting new ideas flowing quickly. I used to depend on my later day brain that was somewhat "depleted", for lack of a better way to describe how i work, and from there that would kinda birth what i work on the next morning, with maybe some iteration while working.
Now instead I just do both, I open the day with ~500-1500 words, just anything that comes out, then i potentially get stuck, and ill maybe dump that to a model as just a modern rubber duck, not anything like "write for me, or finish this thought", just a kinda nudge to really toss back at me what im fully considering and then maybe i pivot back and chase down the most interesting of the topics for a few hundred more words, or get straight to work on what i thought was the most vital of all those ideas to chase while im fresh in the morning.
But, to the claim of how to think in the age of LLMs, I think it’s worth contrasting the other approach, which is a dialog with the LLM; two things are needed IMO to keep things honest:
First, you need to keep asking the LLM to explain things, until you understand what it did. Lots of angles here; have the LLM make a design/product doc, write one-off architecture explainers, write throwaway data-viz tools to explain the data distribution. Then ask a fresh copy to adversarially review the core concepts. Try asking a different frontier model too.
Second, you need to push for “proof”, in other words, ask for demos and try it yourself. Imagine yourself a CEO or VC; how do you know if the output of an entire org is vaporware? One thing to beware is launching into a field where you don’t have expertise and can’t actually validate the output. This takes time of course, but for example if you write a stress test script and get CPU/QPS numbers, these complex validators are IME quite reliable when you apply the same rigor from 1) above to their construction.
I kept my to my niche.
Now I can build anything, but as I'm building it, I try to understand at least how it works. So I'm constantly asking questions. In the process, I think of my prior engineering skill as somewhat childlike. As I thought I was a decent engineer, I now see that I was decent at some things, but far from the kind of breadth that the wide engineering world has.
I think the takeaway is that you should always be curious and build things. Whether it's writing or discussing with an language model, writing software by hand, or creating software with a model and understanding it, I think you have the same effect.
This is the way!
AI is the best technology ever invented for avoiding learning things. It’s also the best technology ever invented for learning things.
I think it’s very important to be on your guard for accidentally glazing over your understanding, but if understanding is your goal, there are so many more tools for this now.
With writing I think it's the same thing.
Let it organize and work with your thoughts, as you say, how you say, as you do it.
Once that is clear, it can then better create those other artifacts.
Notebooks do not crash, do not freeze, and need only you and a pen. My notebooks often remind me of this passage from "Zen and the Art of Motorcycle Maintenance":
> “For this you keep a lab notebook. Everything gets written down, formally, so that you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complex you get lost in them and confused and forget what you know and what you don’t know and have to give up.”
> Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance
There is a wonderful book "Exploring Writing" by John Langan. I found it in our library when I was in my PhD writing phase. I highly recommend it to anyone who has problems building text and who wants to learn how to master its structuring.
As you work on it the problem becomes more clear and seems to tell you what the actual shape of the problem is and you have to adapt your solution to that actual problem, even if it ignores certain aspects of the original idea.
Writing it down and trying to clarify it is one of the cheapest ways to get to the real answer.
A Turing Machine's capabilities exceed the FA's because it has a 'store of knowledge'. It is both recording and reading, repeatedly. There is erasure, too. So if we're aspiring to TM-hood, the guidance seems to be write, and re-read (your own thoughts), and re-evaluate, and re-write. This process is subject to the halting problem. /g
There has been some occasions where I cannot use AI as a thinking partner. It doesn’t have the imagination, intuition, or judgement. I have been relying more on my team in those cases.
This article reminds me of another method: grabbing paper and pencil and start doodling around to work out some ideas.
I'm a big fan of marbled composition books. They're cheap and durable enough. You can write in them without a table. I have 5-6 of them going at once for various tasks. And somehow (for me) the ideas flow more freely longhand than they do at the keyboard. When full, you can cut the spine off with a box cutter and scan it. G4 compression loses the color, but makes really small PDFs.
It's easy to produce better written content than an LLM. And that's good for the reader and the writer.
It's mainly helpful in changing an exercise for youself into something useful for others, that requires you actually adopt their perspectives and migrate them to yours (or realize the error of your ways). You take on the capability not just to convey ideas but also to change the world.
Writing for me anyway is more like a general anxiety release valve.
Thinking is we just do without external tools as we reassess frame to frame due to the world around us not being static; we develop object permanence of a tree for a while but are burning calories to replace on a much shorter timeline; whole lot of physical state still updating on shorter timelines than a tree; so our brains automatically always wipe and refresh the canvas as a natural consequence of relative entropy
We track these deltas and how to deal with them; writing helps deal with scenarios where there is no roof to fix to stay sheltered. What do I do with these thoughts with nowhere to go; I have food, I have shelter? Writing.
I have a really hard time using WYSIWYG editors for thinking-by-writing. I think it’s because it’s hard to see partially-formed structure so it feels less malleable.
Not all writing needs to be published.
> the TM, unlike the FA, has paper and pencil.
> Think about it.
The analogy doesn't works if you really think about it. A TM with a finite tape is equivalent to an FA. The fundamental difference between a TM and an FA is that a TM has infinite space.
(Yes, I know I missed the point and am not very fun at parties.)
Another analogy which never made sense to me was improving by just 1% every day (1.01³⁶⁵).
Analogies do help explain phenomena I cannot even relate to at all, like telling me how life on Mars would be.
Ofcourse I'm not invited to parties as you can imagine, taking things literally.
A big part of understanding something is getting used to it, and analogies help with getting over a mental hang up. They may also help with deciding which areas of the new space to explore first.
But we should be examining the limits of applicability, as we do for most cognitive tools, so we know when to switch from one tool to another. It also helps to combine such tools in a complementary manner.
And, yes, I also generally believe it’s a good thing to use it as a tool. I try to do use it as often as I can.
But… I think it’s also important to note that there are - like with almost anything - pitfalls and downsides. I rarely see them discussed and thus want to bring them up:
For highly analytical people, writing may become counterproductive. Especially, when it is used to continuously elaborate thoughts rather than to challenge assumptions, test hypotheses or reach decisions.
It can lead to over-analyzing or pseudo-rationalizing.
Ask your favorite LLM for scientific references like this one: https://pubmed.ncbi.nlm.nih.gov/40137068/
This also applies to code. Taking your agent's first draft as a sample and doing a reimplementation often yields an even cleaner version.
Once you do ship, the drafts' weaknesses provide codebase signal. Where should you shore up the architecture - or create more reusability, where is the documentation inadequate. Do you need to bake invariants deeper in so they're harder to violate (custom lints, stricter validation...)
And yeah. Writing is clutch too.
Im even saying this with some level of sincerity
In sales, you might call this finding "words that work" or "the pain points". AI will not know how to do this because it's getting a vibe check of the room.
You cannot merely be a sensory part for the AI unless you want to sound as cringe and out-of-touch as the majority of the training data (stale social media). Garbage in, garbage out.
But things get better if you instruct AI to speak in certain style. It’s still average but for the chosen style and thus less tone-deaf for a given use case.
So my thinking is - how much mileage can we get by introducing specific style guides? We can create a library of styles, and to get out of average for a specific guide individual companies and even people will maintain their own private patches from upstream.
Another option is to maintain history of your own writing and thus preserve your own voice. I feel like “averaging” of style is somehow un-ergonomic, in that in numbs the mind, and thus even diversity for the sake of diversity is valuable.
I'll use the conference room example for clarity, even though a lot of people still work remote these days.
Reading the room could be as subtle yet significant as reacting to the speaker that was on immediately before you. It could be reacting to the temperature of the room or the catered lunch everyone just had. It can be noticing or participating in or critiquing a peculiarity of the audience (hawaiian shirt fridays, etc.). It can also be a million other things and they'll never let you get away with choosing at random. You have to just "get it" or you're going to be ignored at best.
You're at once trying to both signal in-group status while also asserting your own identity and setting the tone for everything you'll be saying after. Remote work has its own idiosyncrasies, but regardless, you need a pulse for this kind of work. And, all this is just the introduction. What about emphasis choices in the rest of your writing/speaking?
Trying to pin that down is simply not logical and it's not just a matter of "adding" a handful of tricks unless you want to alienate everyone. Sometimes it's also the things you don't say or do that make the difference. You also have to accept that you can't please everyone. You could actually piss off everyone but the most important person in the room and still win. That might actually be the best way or the only way to win sometimes (as was the case for the American sales pitch of AI itself!).
The real world is messy and adding AI, or any particular process, to the mix just makes it worse. You cannot plan an accident, but you can avoid one.
---
I was once thrown out of a job interview after their secretary yelled at me for what seemed like 5 minutes because I was filling out a form from the shortest blank to the longest blank rather than from the top to the bottom. I had experienced such a trying day, that I just could not bring myself to fill out anything but the next shortest field. All the while, this crazy lady was yelling at me as I had to stand at her desk in front of a room of HR scum/manager scum and job applicants.
---
I classify linear thinking as one useful way to check if something makes sense, not the only way to think.
It also made the work resumable. Coming back after a few days, the file told me exactly where I was and why things were the way they were, which no amount of reading my own code did.
This hit hard. Great article.