Field notes
The things I'd hand you if we were sitting next to each other. Opinionated, updated as I learn.
// tools I actually use
Just getting started
My daily driver. Better than most for writing, reasoning, and long documents. Start here if you want one tool that does almost everything well.
Where most people start, and for good reason. Excellent for quick questions, brainstorming, and drafting. The free tier is genuinely useful.
AI search with citations. Use it when you need current information and want to know where it came from.
Google's model. Worth trying — different strengths, and if you're already in the Google ecosystem it fits naturally.
Ready to build
Claude in your terminal. This is what I use to build. It reads your whole project, writes and edits files, runs commands. Nothing else I've tried comes close for actual building. Switched to this from Cursor for cost and simplicity.
An AI-native IDE with a spec-driven workflow. Good if you want structure around your builds — requirements, design, tasks — before you write a line of code.
AI-native code editor. Where I worked before Claude Code. Still excellent if you prefer a visual IDE over a terminal.
Describe a UI, get a real interface. The first tool that made me feel like I could build with words. Great for prototyping fast.
Personal agent system. I ran a local instance — named mine JB (Julius Bot) — to run tests and explore user experiences on my own projects.
// things worth reading
My own origin story. Start here if you want to understand what this site is actually about.
A Wharton professor writing about AI for normal people. The most grounded, non-hype writing I've found. Start anywhere in his archive.
A developer who writes clearly about what AI tools actually do. Good for understanding the mechanics without needing a CS degree.
// things I wish someone told me
Don't overthink it. But stay humble about what you don't know.
Move fast, try things, don't let uncertainty paralyze you. And keep asking whether you've actually understood what you've built. The confidence to start and the humility to check your work are both required. Neither one alone is enough.
Help it understand your level.
Tell the AI what you know and what you think you don't know. It calibrates, like being assigned the right reading level. "I've never written code" or "I understand the concept but not the implementation" changes the output completely. Most people skip this step and wonder why the answers feel off.
Solve real problems for real people.
Don't imagine customers. Get real test subjects. The gap between a problem you think exists and a problem someone will actually pay to solve is wide, and you can't close it from your desk. Ship the simple thing first and let real reactions teach you.
Build the thing people want to try.
Perfection is not the goal. Stability, security, and the "so what" are the goal. A simple thing that works and solves a real problem beats a complex thing that almost works every time.
The magic feeling is a trap.
When the tools feel magical, you start mistaking the magic for progress. I spent months generating things I never shipped. Output isn't progress. Shipped things are progress.
Once you have live customers, everything changes.
Dev vs. prod. Staging environments. Backups. End-to-end architectural thinking. These feel abstract until someone real is using your system and you realize a small change to how a customer name renders touches five things you didn't expect. Build with that day in mind from the start.