Teaching AI to Think Like Me Made Me Rethink How I Think

I started building a lot of AI tools for myself and learned more about how I think than I did about how AI tools work.

Many articles about AI’s cognitive effects focus on the negative potential consequences of overreliance on AI - brain obesity, reduced creativity, and intellectual laziness. Based on data from a report by OpenAI¹, these concerns are likely valid given that many people are using ChatGPT and other LLMs to ask questions (as they would of a traditional search engine) or get advice, as opposed to taking action and doing things on their behalf. I’ve been using AI in a much different way; I’ve been building tools that help me in the many investment and management tasks that take up a significant chunk of my workday. Instead of treating AI like a search engine, I’ve enlisted it to be my thought partner and assistant. I’ve learned so much during this process, and it is very much at odds with the idea that using LLMs is an adult version of brain rot. Teaching my AI assistants how I think has forced me to clarify, and in some cases update, the way I think and work².

Over the past few months, I’ve really gotten into building AI assistants and tools to help me with many of the investing and management parts of my job. Along the way, I’ve learned a bit of Python (my first time learning a programming language), learned how terminal commands work so I can build with Claude Code and Cursor, expanded my knowledge of Markdown, learned how to use MCP with Claude Desktop to get access to a lot of existing data I need for analytical projects, and built a rudimentary version control system in GitHub to help me manage the iterative nature of what I have been building. I haven’t been writing here as much because The Learning Corner, the podcast I co-host with my colleague, Mia, has been a good outlet for me to talk through many of my ideas on the current state of the VC market. The time I used to spend writing has (for now) been replaced by building things in AI and learning how to get better at getting more out of LLMs.

Developer Workflows Finally Make Sense to Me

On average, I’m now spending a few hours per day building and refining tools to help me in my daily work.

A big inspiration for this post was a LinkedIn post I read from Chang Xu at Basis Set Ventures. The post talks about how many non-developer knowledge workers are starting to build workflows that mirror what developers have been doing for a long time. I could have spent time learning Python without a coding assistant, learning how version control systems like GitHub work, the basics of Markdown, and some basic terminal commands, before modern AI tooling arrived. I never did it before because the barrier to learning those things felt really high, and the relevance to my daily work felt really low. The only reason to spend the time would have been for pure intellectual satisfaction, and I never got over the hump on that front. AI assistants changed that calculus entirely for me once I started pushing myself to use them more.

The Joy of Being a Novice is Real

Today, I’m learning to apply these concepts to my daily work, and they feel very relevant to what I’m doing. I’m now using quite a few tools every day that were not part of my daily workflow, including Cursor and Claude Code for small Python projects and agents, GitHub for version control of Markdown files, Claude Desktop with MCP and Skills for building assistants and projects, WisprFlow for text dictation, and Obsidian for markdown file creation and editing. When I reflect on why this has been so enjoyable and engrossing and taken up more and more of my time, a few things stand out:

• I started this journey as a novice with no programming background and limited knowledge of the tools I use today; I didn’t expect to be good on day one because much of this was new to me. That turned out to be a very liberating place from which to start when learning something new.

• The tooling is actually pretty good at nudging you toward improvement and helping you get more out of what it can do once you learn how to ask for help and structure things to get the best bang for the buck. You can really learn quickly here once you figure out how LLMs work.

• I feel like I’m part of a large community of people on the internet who are also trying to figure this out. Many have shared helpful tips and tricks, but there are far fewer true experts here, given how new the technology is.

• I have really enjoyed the iterative nature of learning. I started out doing very basic things, and have gotten more sophisticated as I’ve learned more about how the tech works and what it can and can’t do well. You don’t have to understand everything or use every tool on day one; you can work your way toward complexity.

To make this more concrete, here’s how I would summarize my journey of learning how to use Claude Desktop as my primary tool:

1. I began by writing simple prompts and then refined them significantly in chat. This felt really inefficient after a few weeks, so I learned more about writing better prompts and how to structure them more effectively.

2. Next, I wrote prompts that I regularly used and turned them into projects. The projects still required a lot of post-prompt chat to get to the answers I wanted, but it was still an improvement over where I started.

3. Then, I discovered project instructions, and that was a revelation. Projects became much easier to manage, but I was still writing very long project instructions to get projects to work.

4. Later, a friend showed me how to rethink project instructions. I started creating Markdown files I could swap out to handle more of the logic. This simplified the project instructions, resulting in huge gains, but it's still not perfect.

5. Recently, I discovered how to create more robust project logic files in Markdown, separate from project instructions, and how to refine them as I gained a better understanding of what I wanted the system to do and deliver.

6. Managing version control in Obsidian became too tedious, so I migrated the project logic's version control (and other core Markdown files) to GitHub to share them with others and track changes over time.

One thing I’ve learned is that many people who want to build stuff in AI are intimidated. They see fully polished, functional projects that others have created, and they assume the final product looks a lot like the original version they’ve been shown. In my experience, nothing could be farther from the case; these things emerge over time, and the starting point and end point often look very different.

Teaching AI to Think Like Me Made Me Better

So was all of this worth it? Yes, but not for the reasons I expected.

The most significant benefit hasn’t been time saved or better decision support. It’s been that teaching Claude to be a good and useful partner forced me to be explicit about how I make decisions about founders, markets, and companies. I’ve always had a model in my head for how I weigh information, but I’d never really articulated it to anyone - including myself.

To make this more concrete, I recently built a reference-checking skill in Claude to help me identify where to spend my time and energy when checking references. I built the skill to cover all the use cases where I want references: founders we’re evaluating, executives interviewing at our portfolio companies, and prospective lead investors for follow-on rounds where I don’t have a strong prior relationship. As I built out the branching logic, I realized something uncomfortable: my beliefs about where to find the most accurate references had evolved significantly over the years, but I was still following some old practices.

One particular area where my beliefs have changed is how to handle founders who have raised capital for a previous venture and are now raising money for their new company. Two things became clear as I started to articulate my reference logic to my AI companion:

1. First, the seed ecosystem has grown dramatically - there are many more founders who have raised VC money before, and I hadn’t digested what that meant for our reference-checking process.

2. In the last ten years, I’ve learned there is much more nuance about why investors and founders choose to partner again on their next venture; it’s dangerous to assume that you know why two people have chosen not to work together again without knowing more about the outcome and the relationship.

Building the tool forced me to confront this drift between what I used to believe and what I’ve learned over time. The branching logic wouldn’t let me be vague or rely on intuition - I had to articulate clear rules about which reference sources to prioritize, which questions mattered most, and where my time would be best spent. Seeing it all written out made the gaps obvious. I’ve made this change, and a bunch of others, as a result of having to explain how I think and reflect on how I feel about the words I see on the page.

I’ve had similar experiences with other tools I’ve built. The systems I’ve built sometimes produce results that surprise me, forcing me to re-evaluate how I weigh factors in the model I’ve built. Each surprise signals that my implicit model and explicit reasoning have diverged.

This is a different value proposition for AI than the efficiency-and-automation narrative that dominates most conversations. For me, the real insight isn’t that AI can do your job (I don’t believe it can, yet) - it’s that trying to teach AI how you think and make decisions forces you to make the implicit ideas you hold explicit. The act of making implicit thinking explicit doesn’t just help the AI understand you. It forces you to understand yourself.

I started this journey worried I might become intellectually lazy. I’ve found the opposite: building with AI has made me sharper, not by offloading thinking, but by forcing me to examine thinking I’d previously taken for granted.

1. If you’re curious about a more in-depth articulation of how people use ChatGPT, I would encourage you to read this paper - it has good structural definitions about how OpenAI classifies user behavior and what users are actually doing with the service.

2. If you want to explore this concept in more detail, I would encourage you to read Ethan Mollick’s book, Co-Intelligence. I didn’t fully grasp all of the things he was saying until I really started building.