# Kaushik Gopal's Site Recent content - Kaushik Gopal's Website This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Tools DevFeed: [Tools]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-09-15T04:00:36.743345Z Content type: article Language: en Sources: [Kaushik Gopal's Site]() Topics: [Programming](), [Cloudflare](), [Terminal](), [Vim](), [Hugo](), [Firefox](), [macOS](), [Obsidian](), [Font]() Tags: [cloudflare](), [firefox](), [hugo](), [mac](), [macos](), [programming](), [programming-font](), [terminal](), [tools](), [vim]() ### AI overview A personal tools page listing services, programming tools, macOS applications, audio equipment, desk items, and physical products. It mentions Buttondown, a customized Hugo site deployed on Cloudflare Pages, Ghostty, tmux, Vim, Zed, Obsidian, Raycast, Firefox, CleanShot, and Logic Pro. ### Source excerpt Bits ## Services ### Newsletter via Buttondown Statically generate site with Henry (highly customized Hugo theme) Deployed on Cloudflare Pages Programming ### Berkeley Mono is my programming font of choice Ghostty for terminal stuff (along with tmux) Within the terminal I'm almost entirely using Vim. Zed as my regular text editor MacOS ### Obsidian for notes & todos Raycast is my launcher Firefox for browsing CleanShot for screenshots on my mac Logic Pro for editing AI Stuff ### With AI evolving so fast, my tag ai-model-choice is a better place to track what I'm using. Atoms ## Desk ### Nordik Leather Desk Mat LEUCHTTURM1917 Soft cover journal dotted Uniball Deluxe 0.5mm Micro pens Audio ### Earthworks Ethos - 400 microphone USBPre 21 audio interface AirPods Max (yes for podcasting!) Physical ### I drive a Tesla Model Y (and eagerly waiting to move to an R3) These are no longer sold but are built like a tank. I'd probably pick the Motu 2 if my USBPre 2 ever fails ↩︎ ## RSS DevFeed: [RSS]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-09-15T04:00:36.743345Z Content type: article Language: en Sources: [Kaushik Gopal's Site]() Topics: [RSS Feed](), [Hugo](), [Open Source]() Tags: [hugo](), [open-source](), [rss]() ### AI overview The article explains how to subscribe to the site's RSS feeds, including general, blog-only, and newsletter-only feeds. It also describes custom topic feeds generated through the Henry theme for Hugo. ### Source excerpt Here are the different ways to subscribe to my content on this site via RSS. Feed Links # /feed.xml -- General feed (all the content I post) /blog/feed.xml -- Blog posts only /letter/feed.xml -- Newsletter letters only Custom feeds ## I use my own theme "Henry" for this site, so there's ∞ flexibility to choose a customized feed based on your liking: Slap /feed.xml or /feed.json at the end of most urls here, and you'll get a feed for that topic. For example I tag my blog posts that are tech tips as /tags/tip. You can get a custom feed for this using the link /tags/tip/feed.xml. Henry for Hugo is open source. ## About DevFeed: [About]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-09-15T04:00:36.743345Z Content type: article Language: en Sources: [Kaushik Gopal's Site]() Topics: [Development](), [Android](), [Hugo](), [Google](), [Azure]() Tags: [android](), [developer](), [development](), [github](), [google](), [hugo](), [podcast](), [talks]() ### AI overview An about page for Kaushik Gopal, an Android-focused Google Developer Expert and Principal Engineer at Instacart. It highlights his podcast, talks, developer posts, and work on Caper smart carts and AI strategy, along with the Hugo theme used to build the site. ### Source excerpt Hi, I'm Kaushik Gopal. I host Fragmented an AI developer podcast and previously the most popular Android developer podcast. I'm also a Google Developer Expert for Android. I work as a Principal Engineer at Instacart leading the development of our Caper smart carts and assist with AI strategies for the company. #work podcast talks github contact #blog posts newsletter RSS #social bluesky linkedin threads twitter mastodon Talks ## 2019-10 Architecting Android and iOS app features for 2020 2018-09 Unidirectional State Flow patterns - a refactoring story 2018-05 Supercharging your workflow with App Center and Azure 2017-07 Rx by example - Volume 3 (the multicast edition) 2016-11 What I learnt using the Presenter pattern 2016-11 Learning Rx by Example (Part 2) 2015-08 Painless UI Testing 2015-06 Learning Rx by Example (Part 1) Colophon ## This site is built entirely with the custom Hugo theme I maintain called Henry. I have put thought into almost every inch of this website and released the theme free for everyone to use. Curious about the tools I use day-to-day? I keep a running list. Want to reach out? I'd love to hear from you. ## What it means to be a truly AI-native software company DevFeed: [What it means to be a truly AI-native software company]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-07-01T20:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Testing](), [bug](), [Pull Request](), [User experience (UX)](), [Code](), [Figma]() Tags: [agent](), [ai](), [bug](), [code](), [figma](), [quality-assurance](), [test](), [ux]() ### AI overview An opinion essay sketches how an AI-native software company might redesign quality assurance, product management, and design around agents, shared context, prototypes, automated fixes, and verification loops. ### Source excerpt Everyone says they're rebuilding their company in an AI-native way. But what does that mean? Most companies look at what their existing employees do and try to automate it with AI. That's not it. That's dabbling. A truly AI-native company rethinks every role and tears down the walls between them. None of us can 8-ball this but here's my sketch. It's not exhaustive but hopefully it sparks something: Role changes # Quality Assurance ## The QA team typically finds bugs and dutifully files them in Jira. Engineering has finite capacity, so they fix the P1s and freeze the rest. P2 and P3 bugs die in the backlog -- the UX nits, the copy, the small fixes. An AI-native QA team files the bug and immediately points an agent at it. The agent takes a first pass, finds a root cause, proposes a fix, and opens a PR -- then sends a test build right back to QA to verify. Along the way the bug is updated in detail, so if it needs escalation to the engineer who built it, all the context is right there. A more advanced team has a loop wired to trigger the minute a bug is filed. Product managers ## A PM understands the business and goals well. They write a thoughtful PRD -- but it's often 70% done. How are they to keep the full codebase and every edge case in their head? The engineer starts building, hits those edge cases mid-feature, and bounces it back to the PM who has better intuition. Tweak the PRD, back to the engineer. This can happen for every slice of that remaining 30%, and it's frustrating for everyone. An AI-native PM sends an agent to walk the real code, surface those forks up front, and spin up throwaway prototypes to explore each one. They keep a knowledge base of past decision briefs so the team doesn't rebuild what was already ruled out. With that in hand, they produce a fully specced PRD -- and maybe pushing further, include end-to-end tests defining what done looks like. Designers ## Designers mock up screens in Figma and ship them over, hoping what shows up in production ## Responsible Loop Engineering DevFeed: [Responsible Loop Engineering]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-06-22T20:39:22Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Loop Engineering](), [Artificial Intelligence](), [Software Engineering](), [future of software](), [Agent Skills]() Tags: [agent](), [agents](), [ai](), [engineering](), [future-of-software](), [loops](), [software-engineering]() ### AI overview The author argues for responsible loop engineering: designing and operating agent systems that can run continuously while controlling costs. The article distinguishes capped one-shot loops from autonomous loops that select tasks, use subagents, research, test, and return results for review. It argues that autonomous loops require bespoke engineering, integrations, execution strategies, and queueing. ### Source excerpt Loop engineering convinced me. Not because it's clever -- because done right, it doesn't bankrupt you. This post captures where I've landed: a responsible way to run loops at scale without burning a hole in your pocket. Naysayer -> Believer ## I've been a vocal naysayer. Not because the approach doesn't work -- it works. The costs never justified it. No surprise -- the people singing its praises usually aren't the ones paying the API bills. But when Peter & Boris tell you something, you look closer. Same thing happened with agent skills -- Simon W saw something early, and that became the biggest hammer in our AI toolbox. Types of loops ## The public discourse mixes loops with loop "engineering," so let's disambiguate. One-shot loops ### Today, an agent can execute a task, have an independent judge review the result1, apply the feedback, and repeat. You put a cap on the number of loops. Or you let it run until it's "satisfied" -- a bad idea. These are easy to set up. Many people are already demonstrating them. I call these one-shot loops. They're easy enough that I'll focus on the other kind. Autonomous loops ### But when Peter Steinberger and Boris Cherny talk about loops, I think they mean autonomous loops. You set up agents to run continuously. They decide when to act, pick up the right tasks, spin off subagents, research, test theories, and send results back for review. Or ship, if confidence is high enough. An entire system running on its own -- you shovel tasks at the speed of thought or voice. These loops are self-sustaining and take real engineering to get right. I'll go out on a limb: Future of Software Engineering is loop engineering Most of the software engineers of tomorrow are going to be spending their time setting up and engineering loops. Because it's hard and it's going to require skill -- there's no one loop we can template for all solutions. From my experimenting so far, this feels bespoke in the way good software is bespoke. You can't just use an agent sk ## Moxy - My new programming font DevFeed: [Moxy - My new programming font]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-06-16T07:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Font](), [Programming]() Tags: [download](), [files](), [fonts](), [jetbrains](), [ligatures](), [mono](), [plex](), [programming](), [programming-font]() ### AI overview The article introduces Moxy, a programming font built on Recursive with opinionated character choices and fixes, incorporating some glyph ideas from Lilex. It explains the font's customizable character choices and provides installation instructions for the v1 release. ### Source excerpt Every time I switch or try out a new font, I track it in my my-new-programming-font series. Some of the popular ones: IBM Plex Mono, Recursive, Commit Mono, Berkeley Mono. This time's a little different. It's one I've "made" myself, and I'm calling it Moxy. Built on strong bones ## Moxy is built on top of Recursive. It's a stretch to call it a new font -- it's Recursive with a set of opinionated character choices and a few fixes to the original. There's two things I love about Recursive: it's one of the most legible and clear fonts out there it's got flair1 Recursive was also a pioneer in pushing what variable type fonts can do. Another font I've been testing and playing with is Lilex. It's popular again because editors like Zed use it as the default. Lilex is really just IBM Plex Mono with a set of special characters and ligature choices. It's an excellent font in many ways, and one I often find myself switching to. Lilex has a few ligatures I absolutely love for programming. So, with the power of AI coding, I thought to myself: what if I had Recursive but with some of the glyphs of Lilex? Thus was born Moxy. What's different: ## The font ships with my specific Recursive character choices baked in. But you can swap them in and out depending on your preference. Install it ## Download the v1 release, unzip it, and install the .ttf files like any other font. Alternatively, use brew: brew install --cask kaushikgopal/tools/font-moxy People understandably love and swear by JetBrains Mono. They keep asking why I don't cite or bring it up. I love that JetBrains Mono exists, but I find it a "drab" font -- and that's not always a bad thing. When you look at Recursive, it makes a statement. ↩︎ ## OpenCode power user tips DevFeed: [OpenCode power user tips]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-06-03T16:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Agent Harness](), [Tooling](), [Open Source](), [Code]() Tags: [agent-harness](), [claude-code](), [codex](), [commands](), [fork](), [how-to](), [model](), [open-source](), [opencode](), [switching](), [tips]() ### AI overview A practical guide to advanced OpenCode features, including the leader key, session management, session forking, conversation rewind, and model switching. ### Source excerpt In this post, I'd like to talk about some power user tips for OpenCode - an open source, model agnostic harness that more people should be using. Hopefully some of the advanced use cases convince you to give OpenCode (and OpenChamber) a shot. intermediate to advanced tips only I am specifically choosing to talk about some advanced tips in this post. If you've never used an agent harness or are looking to learn how to use OpenCode, this post can be useful but reader beware. Unleash the leader key ## While ⌃p (Ctrl + P) will list out all the possible commands (and is helpful), OpenCode has the concept of a "leader" key (which defaults to ⌃x). The leader key allows you to execute targeted useful commands more quickly and there's a slew of useful ones pre-defined1. ctrl-p shows all commands. notice leader key bound to some Manage multiple sessions - leader l ## People reach for whole terminals and extra tooling to juggle between agent sessions. I too had an overly customized tmux setup that looked like this: Before: agent session listing via tmux OpenCode simplifies this. Just hit leader + l and you view current sessions and can instantly switch to that session by just selecting it from the list. After: leader-l allows quick session switching The ability to quickly rename a session from this view is a godsend for me and what lets me be organized. session directory filtering you can pass a --dir . flag to opencode when launching it, which filters the session list to just this workspace/directory by default. You can alternatively not pass that flag, and the session list will show all sessions. Fork (or Branch) sessions /fork ## Forking takes the session you're in and spawns a new one. You branch off into a separate conversation while the main agent keeps grinding on whatever you left it doing. I love this feature and even cobbled my own version with tmux long before most harnesses shipped it. Claude Code, Codex and other harnesses have caught up and support this feature. ## AI model choices 2026-06 DevFeed: [AI model choices 2026-06]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-06-01T17:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Text-based user interface](), [Tool]() Tags: [ai](), [audio](), [code](), [code-review](), [deep](), [gemini](), [gpt](), [model](), [models](), [opencode]() ### AI overview A developer shares their current AI tool stack, preferring Kimi 2.6 as a general-purpose workhorse, GPT 5.5 for coding and planning, Opus 4.8 for deep thinking and writing, and Gemini for image, video, and audio tasks. They also describe using OpenCode with OpenChamber as their preferred harness. ### Source excerpt My 2026 Jan AI tool stack. Six months since my last post and the whole list has turned over. Models ### Kimi 2.6 has become my overall workhorse model. By default I start most AI sessions with Kimi 2.6 now. GPT 5.5 remains my coding model of choice. My detailed planning, creating of exec-plans1, code review, simplification, and one-shot feature changes, reliably happen with GPT 5.5 (high). Opus 4.8 for deep thinking, writing and overall hard tasks. It's been four days since the release, so my opinion is still forming but I've been fascinated how quickly Opus 4.8 is giving me the right solutions, especially for the slightly more complex problems. - I still only reach out to, when other models are struggling, cause 💸🔥 Gemini for anything image, video, or audio. Nothing else is close. It has collapsed work that used to eat hours2 of mine. Harness ### I constantly try multiple harnesses but I think I've firmly settled on OpenCode paired with OpenChamber as my harness of choice. I've since written up my power tips for OpenCode, but I put a lot of these harnesses through the ringer and am really happy with this combo atm. I still drop often into TUI land with OpenCode and while like others I had my dalliance with cmux, I've found it's not great on performance and runs into memory issues. So I'm back to naked Ghostty. OpenCode on the other hand is really good at managing sessions, so often I don't even find myself needing to use tmux. Also, I use Hermes but having discovered OpenChamber, I don't find myself needing to reach as often. Again, this deserves a longer post, if you're curious. What surprised me ### I've just been blow away by Kimi 2.6. I've found it often keeps pace with GPT 5.5 with Medium reasoning. There have even been time it's results matched Opus 4.8 (though Opus typically gets the results one-shot). I'm not sure if I've engineered my harness in some way to work better with Kimi, but dang I love the results I'm getting. If you want to give it a shot, I rec ## How AI agents could shift software work from code changes to specifications and module rebuilds DevFeed: [How AI agents could shift software work from code changes to specifications and module rebuilds]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-05-04T16:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Software Engineering](), [Agent Skills](), [Software](), [Refactoring](), [modules](), [patches]() Tags: [agents](), [ai](), [code](), [module](), [patches](), [refactoring](), [software-engineering]() ### AI overview This opinion article argues that AI agents may act like compilers, turning detailed specifications into software and reducing the need to write implementation code directly. Drawing on examples where the author changed implementations while preserving behavior, it suggests that agents could make rebuilding entire modules more practical than incremental patching and refactoring. ### Source excerpt Linus Torvalds recently said1 AI will be to code what compilers were to assembly -- freeing us from writing it by hand. Around the same time, I talked with Jesse Vincent (creator of one of the most popular agent skills out there -- superpowers). Something he said stuck with me: Specs are going to be the new code. I realize those two ideas snap together a little too neatly. Agents are compilers2 and specs will become code. Software engineering is moving up another level of abstraction and we've seen this play out before. Specs as source ## I saw this first-hand with my tiny USB-C cable checker -- usbi. It started as a shell command over macOS's system_profiler, then became Go when I wanted a proper binary, then Rust because I wanted to practice Rust, and later a .kts version. The code kept changing. The thing I cared about did not: parse the USB tree, identify the attached devices, report the speed, and make bad cables obvious. Podsync, my voice track sync program, followed the same pattern. It started in Python because the audio libraries were there. Then I moved it to Rust because I didn't want to ship a Python runtime or care which Python version happened to be on a machine. Again, the implementation changed. The behavior stayed boringly stable: take a master track and local tracks, find the offset, pad or trim each file, and drop aligned audio into the DAW. Compilers freed us from writing assembly. Agents may free us from writing code because it becomes an artifact the spec produces. The somewhat recent push around detailed exec plans could be an early signal of the looming shift at bigger scale. Rebuilds instead of patches ## Push that thought further. We might get comfortable rebuilding whole modules instead of patching and refactoring them. We preserved the old shape of a system because throwing it away cost too much. Even when you know the module is wrong, you sand it down: extract an interface, migrate one caller at a time, add tests around behavior nobody full ## Using Claude Code and Codex to iteratively improve coding plans DevFeed: [Using Claude Code and Codex to iteratively improve coding plans]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-04-25T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Claude](), [Claude Code](), [codex](), [coding]() Tags: [agent](), [agents](), [claude](), [claude-code](), [codex](), [evaluation](), [multi-agent]() ### AI overview The article describes Agent Kombat, a workflow in which Claude Code and Codex independently draft plans for the same coding requirement, critique each other's plans, and revise them over several rounds. A separate judge agent may then synthesize the plans or run a focused replay. ### Source excerpt Most multi-agent coding setups I see today look like task parallelism. You split the work, hand each piece to a different agent, and merge the results at the end. That is useful. I do it too. But I've been trying a different approach and really liking it: Put two agents on the same problem and make them argue constructively before I trust the plan. The manual version is simple: I spin up Claude Code with Opus 4.7 and ask it to draft a plan: my-plan-claude.md. Then I spin up Codex with GPT-5.5 and ask it to draft a plan for the same requirement: my-plan-codex.md. Now the useful part starts... I ask Claude to read the Codex plan, steal whatever is better, update its own plan, and give me a concrete list of deficiencies in the Codex plan. Then I take those deficiencies back to Codex and ask it to do the same thing: read Claude's updated plan, steal the good parts, defend or fix the weak parts, and update my-plan-codex.md. Then back to Claude. I do this about three times. This works annoyingly well. The final plan is usually much better than the first one-shot plan from either model. Each model forces the other one to look at the problem from a slightly different angle. I started calling this Agent Kombat. And because copy-pasting between two terminals gets old fast, I built a small program that runs the loop for me. Agent Kombat Download the script here The loop ## The loop has only a few rules: Both agents start from the same requirement. Each agent writes its own plan before seeing the other plan. Each round, the agent must name what is stronger in the other plan. Each round, the agent must update its own plan. Each round, the agent must list concrete deficiencies in the other plan. After a few rounds, a separate judge (agent) decides whether to synthesize or run one focused replay. The "concrete deficiencies" part does most of the work. If I just ask, "what do you think?", the models get polite. They compliment each other, merge a few phrases, and call it convergence. ## Harness engineering: Building reliable environments for AI coding agents DevFeed: [Harness engineering: Building reliable environments for AI coding agents]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-04-03T00:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Claude Code](), [codex](), [Model Context Protocol](), [hooks](), [Software]() Tags: [agent](), [claude](), [claude-code](), [codex](), [engineering](), [hooks](), [mcp](), [memory](), [skills](), [software]() ### AI overview This commentary argues that software engineering is increasingly focused on building reliable environments around AI coding agents. It describes harness engineering as configuring files, tools, skills, hooks, feedback loops, memory, guardrails, and blast-radius controls so agents can make changes safely and teams can trust them. ### Source excerpt The role of a software engineer is shifting. Not toward writing more code but toward building the environment that makes agents reliable. Think about what you actually do with Claude Code or Codex today: you configure AGENTS.md files, set up MCP servers, write skills and hooks, build feedback loops and tune sub-agents. You're not writing as much of the software anymore. You're engineering the harness around the thing that writes the software. Mitchell Hashimoto first coined the term harness engineering -- the work of shaping the environment around an agent so it can act reliably. What the model sees, what tools it has, how it gets feedback, when humans step in. We keep hearing that agents will replace engineers. That shouldn't be the focus of the change we're seeing. What's actually happening is product people shipping features directly. A well-harnessed agent lets someone with product instinct but little engineering background make meaningful changes -- safely. The harness engineer makes that possible. Guardrails, design choices, blast radius controls, feedback loops. The scaffolding that turns "just prompt it" into something a team can trust. I say this from first-hand experience. If you want to go deeper, listen to the episode where my cohost and I dug into it. We landed on five pillars: agent legibility closed feedback loops persistent memory entropy control blast radius controls Honestly one of the most important episodes we've recorded. ## Podsync - I finally built my podcast track syncer DevFeed: [Podsync - I finally built my podcast track syncer]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-03-20T00:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Algorithm](), [Rust](), [Claude](), [Java]() Tags: [algorithm](), [claude](), [engineering](), [rust]() ### AI overview The author built PodSync to automate alignment of locally recorded podcast tracks. The tool uses voice activity detection, MFCC audio features, and cross-correlation to match tracks, and was developed with Claude in Rust after earlier difficulties finding suitable JVM audio-processing libraries. ### Source excerpt I host and edit a podcast1. When recording remotely, we each record our own audio locally (I on my end, my co-host on his). The service we use (Adobe Podcast, Zoom, Skype-RIP) captures everyone together as a master track. But the quality doesn't match what each person records locally with their own microphone. So we use that master as a reference point and stitch the individual local tracks together. This is what the industry calls a "double-ender". Add a guest and it becomes a "triple-ender". But this gets hairy during editing. Each person starts their recording at a slightly different moment -- everyone hits record at a different time. Before I can edit, I need to line everything up. Drop all the tracks into a DAW, play the master alongside each individual track, nudge by ear until the speech aligns. Add a guest and it gets tedious fast. 10-15 minutes of fiddly, ear-straining alignment before I've even started editing. There's also drift. Each machine's audio clock runs at a slightly different rate, so two tracks that are perfectly aligned at minute one might be 200ms apart by minute sixty. So I built PodSync2. I've wanted this since 2019 ## I first heard of a similar technique from Marco Arment -- back in ATP episode 25. He had a new app for aligning double-ender tracks and was already thinking about whether something so niche was even worth releasing publicly. I don't think he ever released it. Being a Kotlin developer at the time, I figured I'd build my own. Java was mature. Surely there were audio processing libraries that could handle this. There weren't 😅. At least not in any clean, usable form. Getting the right signal processing pieces together in JVM-land was awkward enough that my interest fizzled, so I kept doing it by hand. tis the age of AI ## When I revamped Fragmented, I finally came back to this. I used Claude to help me build it -- in Rust, no less.3 But before you chalk this up to another vibecoded project, hear me out. The interesting part here was ## Here's my list of reasons for using Opencode DevFeed: [Here's my list of reasons for using Opencode]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-03-17T20:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [User experience (UX)](), [client](), [servers](), [context]() Tags: [agentic](), [architecture](), [bugs](), [external](), [features](), [mcps](), [models](), [opencode](), [plugins](), [switching](), [tailscale](), [ux]() ### AI overview The author gives five personal reasons for using OpenCode: switching between models, its client-server architecture, subagent and mode features, opinionated user experience, and plugin customization. The article also notes that OpenCode has bugs and missing features, which the author says have not stopped them from using it exclusively for two months. ### Source excerpt Here's my list of reasons for using Opencode. 1. Switch between models on the fly ## I'm often experimenting with the bleeding edge models as they come out. I actively switch between models for tasks and I use them all enough where I can tell the difference. Opencode lets me switch between models mid-task or mid-conversation. Fluidly. 2. client-server architecture (a.k.a built-in remote control) ## I wrote about this and agentic fluidity in more detail but tldr: Opencode has the client/server architecture baked in. So I can just start an opencode server on one machine, expose it through tailscale serve and start using it on my phone or other machines. 3. Subagent + mode features ## I talked about this on my podcast in some detail but Opencode has the best implementation of subagents and modes. You can switch to a subagent definition as your primary mode, then operate other subagents from there. It makes orchestrator-type tasks super easy. 4. Opinionated UX ## I love that OpenCode is opinionated about their UX. They don't try to be Claude Code or Codex. In the process they have some really nice UX patterns like a sidebar with ongoing file changes, context/cost, MCPs connected etc. It's the first time I've not needed to worry about a custom statusline.sh or building one. 5. "Highly" customizable via plugins ## The plugin ecosystem is highly customizable. To the point where you can add new features, integrate with external services or even modify OpenCode's default behavior. The wonderful Jesse Vincent mentioned this to me when I was stupidly contemplating a fork. What's missing # It's not all rainbows and sunshine. Anomaly -- the team behind OpenCode -- is small. Which sometimes shows, because there's definitely bugs and some features missing. But I will say... none that's deterred me from using it for the last two months, exclusively. Go give it a shot. Many of the serious AI coders I know are really liking it and switching. ## OpenCode offers server-client access for on-the-go agentic coding DevFeed: [OpenCode offers server-client access for on-the-go agentic coding]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-02-20T21:04:46Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [agentic-coding](), [Command-line interface](), [servers](), [client](), [browser](), [tailscale](), [Artificial Intelligence](), [Open Source]() Tags: [agentic](), [agentic-coding](), [browser](), [cli](), [local](), [open-source](), [opencode](), [project](), [server](), [tailscale](), [terminal]() ### AI overview The article argues that OpenCode is a useful open-source option for accessing agentic coding sessions from multiple devices. It highlights OpenCode's server-client architecture, CLI and web modes, browser access, and use with Tailscale to connect to a development machine remotely. ### Source excerpt One of the reasons OpenClaw got so popular was how fluidly you can chat with and operate your agents. Pull up your phone, send a quick message on WhatsApp, and you're in business. As we focus more on agent orchestration1 in 2026, I think an important aspect will be access fluidity. How do you hop into your agent's context from any device, terminal, or IDE and just start coding? Claude Code supports this in a limited way, while others like Cursor and Codex take a cloud-based approach. The best option I've found for this "on-the-go" agentic coding is an open-source one -- OpenCode. OpenCode - your best "on-the-go" option for agentic coding. Server-client architecture ## OpenCode uses a native server-client architecture. You can simply spin it up in a regular terminal tab, just like claude or codex. But the power move is running it as a server and connecting multiple clients. A client can be your terminal tab, a mobile device, or a desktop computer. Each terminal tab becomes a new, isolated CLI session that connects to the server. Couple this with Tailscale, and you can securely connect to a dev machine running an OpenCode server from anywhere. Getting started ## I'd start by using opencode like a regular CLI tool. Once it feels familiar, switch to server/web mode. # advertises server as opencode.local opencode web --mdns # attach to a session # equivalent to starting a new claude code session opencode attach http://opencode.local:4096 --dir /path/to/project The beauty is you can open that opencode.local URL in any browser, and it's fully synced. Credit to my co-host Iury for tooting the OpenCode horn early, and my Instacart colleague Spencer for questioning my luddite tmux ways.2 I'll write a future post singing OpenCode's other praises. For now, if you're exploring the bleeding edge of agent access fluidity, don't sleep on it. See my post on AI paradigms. ↩︎ I noticed some memory leaks when using tmux sessions with OpenCode, and Spencer asked me: why not lean on the s ## AI model choices 2026-01 DevFeed: [AI model choices 2026-01]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-01-13T19:39:48Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [coding](), [Automation]() Tags: [2026](), [ai](), [automation](), [coding](), [generation](), [image](), [model](), [models](), [transcription](), [voice](), [writing]() ### AI overview The author shares a current set of preferred AI models for different tasks, including planning and writing, coding and tool calling, learning, quick questions, image generation, and voice transcription. ### Source excerpt Which AI model do I use? This is a common question I get asked, but models evolve so rapidly that I never felt like I could give an answer that would stay relevant for more than a month or two. This year, I finally feel like I have a stable set of model choices that consistently give me good results. I'm jotting it down here to share more broadly and to trace how my own choices evolve over time. GPT 5.2 (High) for planning and writing, including plans Opus 4.5 for anything coding, task automation, and tool calling Gemini's range of models for everything else: Gemini 3 (Thinking) for learning and understanding concepts (underrated) Gemini 3 (Flash) for quick fire questions Nano Banana (obv) for image generation NVIDIA's Parakeet for voice transcription ## Forking subagents in an AI coding session with tmux DevFeed: [Forking subagents in an AI coding session with tmux]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-12-29T08:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [agentic-coding](), [coding](), [Claude Code](), [codex](), [Command-line interface](), [Shell](), [Model Context Protocol]() Tags: [agentic-coding](), [bash](), [claude-code](), [cli](), [code](), [codex](), [mcp]() ### AI overview The article describes a thin Bash script using tmux to fork interactive AI coding sessions while preserving context. It emphasizes tool-agnostic workflows across Claude Code, Codex CLI, and Gemini, with separate sessions for exploration or parallel work. ### Source excerpt With agentic coding becoming the primary paradigm for coding, many have tried to come up with a smooth subagent workflow.1 Many of these solutions are reasonable, but none match the simplicity of what I actually want: Spin up another agent instance with the exact same context I've painstakingly built. Pursue a tangential thought interactively in a separate session. Sometimes that's exploratory (understand a subsystem, ask follow-ups). Sometimes it's parallel work (write tests while context is fresh, draft docs, spike an alternative). That's it. Open a new tab, resume the session, take a different path. Sounds straightforward, but tack on a few more requirements and it becomes hard to find a satisfying solution. I've been using a thin shell script for this and it's worked well.2 You can find the source here. My requirements # Super thin glue layer ## I'm deliberately not trying to build on top of existing agents. I use claude code, codex cli & gemini daily, and they change fast enough that anything with a thick layer (like a UI) will lag behind on features. So: a Bash script and tmux. That's it. Available on virtually any computer. Tool-agnostic forks ## I want to start the main session in one tool and fork into another, keeping the same context. So I might start a planning session with codex. After I have a decent plan, I might want to fork into claude code (with all the context I've built) and start a coding session. I might want to fork another subagent from gemini and, using something like the nanobanana MCP, build a before/after flow diagram. Interactive, not one-shot ## When I fork a subagent, I want a real session I can keep interacting with. It's rare that I can one-shot a request and get exactly what I want. Based on the initial response, I might want to go down the rabbit hole and explore more. Many existing solutions are headless or try to merge results back automatically. In practice, I just copy-paste what I need from the fork back into the main session ## Android Wi-Fi Sharing for Captive Portals and Device Limits DevFeed: [Android Wi-Fi Sharing for Captive Portals and Device Limits]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-12-26T20:30:06Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Android](), [Wi-Fi](), [networking](), [tailscale]() Tags: [android](), [tailscale](), [wi-fi]() ### AI overview The article explains Android Wi-Fi sharing, which re-shares an existing Wi-Fi connection through the phone's hotspot. It argues that this can reduce captive-portal logins, work around single-device Wi-Fi plans, restore local device discovery, and, in some setups, route connected devices through Tailscale. ### Source excerpt Ubiquiti announced a new travel router. Much of the internet is excited. So am I. Then I tried to remember the last time I actually needed a travel router. You see, Android has supported a feature I'll call Wi-Fi sharing for years.1 Your phone connects to an existing Wi-Fi network and re-shares it as a hotspot. This might sound like a regular hotspot feature that most phones (including the iPhone) come with. But it's not. iPhones can share mobile data. They can't re-share a Wi-Fi connection as a hotspot. Wi-Fi sharing Your phone connects to Wi-Fi, and then re-shares that same Wi-Fi as a hotspot. This is different from typical hotspot functionality where the phone shares its mobile data connection (vs Wi-Fi). Neat trick, but why bother? Can't you just connect each device to Wi-Fi? Avoid signing every device into a captive Wi-Fi portal ## Captive portals are annoying when you're carrying multiple devices. I typically travel with 3-4 devices that want internet. Signing each one in, every time, gets old fast. Some devices are worse: Chromecast and Fire TV sticks are particularly painful to get past captive portals. If everything connects to your hotspot, you only deal with the portal once.2 Work around "one device at a time" Wi-Fi plans ## On a plane, I sometimes want both my laptop and phone online. Some paid Wi-Fi plans only allow one device at a time. Unless you're ok paying twice, Wi-Fi sharing is simpler.3 Hotels and conference centers do the same: sign-in plus device limits. Wi-Fi sharing works around it. Fix "devices can't see each other" networking ## This one is less obvious, but common in hotels and conference Wi-Fi: your devices have internet, but they can't see each other locally. Chromecast (or printers) won't show up as a cast target because it doesn't appear on the network. That's usually client/AP isolation.4 Put your devices on your phone's hotspot, and local discovery usually works again. Secure networking with a Tailscale setup ## This is slightly adv ## AI can accelerate software work, but understanding and reviewing generated code remains essential DevFeed: [AI can accelerate software work, but understanding and reviewing generated code remains essential]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-12-23T06:01:28Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Vibe coding](), [Code]() Tags: [ai](), [code](), [coding](), [engineering](), [vibe-coding]() ### AI overview This opinion article compares AI with a motorbike for the mind: it can greatly increase the speed of producing words or code, but may weaken the underlying skills if people skip difficult work. It argues that developers must understand generated code, consider trade-offs, and know when to stop and review before shipping. ### Source excerpt Steve Jobs famously called the computer a bicycle for the mind. We humans are tool builders... We can fashion tools that amplify these inherent abilities to spectacular magnitudes. So for me, a computer has always been the bicycle of the mind. Something that takes us far beyond our inherent abilities. That sentiment feels prescient again today but the vehicle has changed. If the personal computer was a bicycle, AI is a motorbike for the mind. I choose this distinction carefully. To ride a bicycle well, you must build muscle. The motorbike is different. You cover vast distances without any tax on your body. Ride it long enough, and the muscles you once relied on atrophy. It's seductive to ship words or code while skipping the slow, painful work. But wrestling with edge cases is how you learn what "good" looks like: a skill you'll need to sharpen even more with AI doing the typing. Speed also changes the nature of failure. A fall at 10 mph is a bruise: a bug you can trace and learn from. A fall at 60 mph is fatal: a bug hidden in code you never wrote, its damage everywhere before you notice. Keep vibe-coding your entire system1 without understanding every line, every trade-off; you'll eventually crash. Here's the thing about motorbikes: everyone can twist the throttle. What separates riders who arrive from those who crash is knowing when to brake - when to stop, look, and understand before you ship. In an age where anyone can go fast, the true skill is no longer the throttle. It's the brake. as opposed to engineering with AI ↩︎ ## Combating AI coding atrophy with Rust DevFeed: [Combating AI coding atrophy with Rust]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-12-05T08:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Rust](), [ai-coding](), [coding](), [Code](), [Software](), [systems]() Tags: [ai](), [ai-coding](), [code](), [coding](), [memory-management](), [rust](), [software](), [systems]() ### AI overview The author reflects on learning Rust to counter concerns about AI-assisted coding causing coding skills to atrophy. Rust's systems-level design, ownership model, lifetimes, and lack of garbage collection provide concepts that challenge the author beyond familiar Kotlin and Go. The article also notes that several everyday developer tools and software use Rust in substantial ways. ### Source excerpt It's no secret that I've fully embraced AI for my coding. A valid concern (and one I've been thinking about deeply) is the atrophying of the part of my brain that helps me code. To push back on that, I've been learning Rust on the side for the last few months. I am absolutely loving it. Why Rust? ## Systems level language ### Kotlin remains my go-to language. It's the language I know like the back of my hand. If someone sends me a swath of Kotlin code, whether handwritten or AI generated, I can quickly grok it and form a strong opinion on how to improve it. But Kotlin is a high-level language that runs on a JVM. There are structural limits to the performance you can eke out of it, and for most of my career1 I've worked with garbage-collected languages. For a change, I wanted a systems-level language, one without the training wheels of a garbage collector. New paradigms ### I also wanted a language with a different core philosophy, something that would force me to think in new ways. I picked up Go casually but it didn't feel like a big enough departure from the languages I already knew. It just felt more useful to ask AI to generate Go code than to learn it myself. With Rust, I could get code translated, but then I'd stare at the generated code and realize I was missing some core concepts and fundamentals. I loved that! The first time I hit a lifetime error, I had no mental model for it. That confusion was exactly what I was looking for. Coming from a GC world, memory management is an afterthought -- if it requires any thought at all. Rust really pushes you to think through the ownership and lifespan of your data, every step of the way. In a bizarre way, AI made this gap obvious. It showed me where I didn't understand things and pointed me toward something worth learning. Built with Rust ### Here's some software that's either built entirely in Rust or uses it in fundamental ways: fd (my tool of choice for finding files) ripgrep (my tool of choice for searching files) ## AI-assisted coding -\> Vibe Engineering \<- Vibe Coding DevFeed: [AI-assisted coding -\> Vibe Engineering \<- Vibe Coding]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-11-18T00:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [AI-assisted coding](), [Vibe coding](), [coding](), [cursor](), [GitHub Copilot](), [Large Language Model]() Tags: [ai-assisted-coding](), [bash](), [code](), [coding](), [cross-platform](), [cursor](), [github-copilot](), [go](), [vibe-coding]() ### AI overview The article distinguishes AI-assisted coding, vibe coding, and vibe engineering by who generates most of the code and who owns the design and quality bar. It presents AI-assisted coding as programmer-led autocomplete, while warning that vibe coding can produce poorly understood code as codebases grow and require maintenance. ### Source excerpt We're still wrestling with how much AI belongs in our day to day coding. Three phrases keep getting mixed together: AI-assisted coding Vibe coding Vibe engineering These are not the same. AI Assisted Vibe coding Vibe engineering Generates the code 👨💻 (+ 🤖) 🤖 🤖 Owns the design 👨💻 ︎🤖 👨💻 ︎ They differ along two dimensions: who generates most of the code and who owns the design and quality bar. 1. AI-assisted coding ## This is where we started. You, the programmer, write most of the code. AI acts as super-powered autocomplete. You type most of the code yourself. AI handles completions, boilerplate, pieces of the logic and maybe small refactors. Your eyes stay on every line, and the AI rarely acts without you explicitly placing or accepting a suggestion. This is still "you drive, AI rides shotgun". GitHub Copilot was the early poster child. Here's an early video of me dabbling with Copilot and scripts. Today, Cursor Tab has taken the crown: fast, inline help without giving up control of the codebase. I particularly like how accurate Cursor is at predicting the next point of code entry or edit. When it works well, it disappears into the background and silently increases your productivity. Get it wrong, and you're immediately frustrated with AI. 2. Vibe coding ## This took the world by storm. AI generates most if not all of the code. You, the programmer, react with feedback in English and are not as in tune with what the actual code shapes up to be. You give up intentional design. In practice, you're letting the model make the architectural calls: file structure, abstractions, naming, everything. As your codebase grows and needs ongoing maintenance, vibe coding breaks down. Your code turns into mystery-meat: it runs, but nobody understands clearly how or why. This is why experienced greybeards raise alarms and complain about AI bots on their lawns. But Vibe coding does shine in a few scenarios: Non-programmers who need something working without caring about internals Fa ## Why Monthly AI Subscriptions Make Sense for Fast-Moving Coding Models DevFeed: [Why Monthly AI Subscriptions Make Sense for Fast-Moving Coding Models]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-11-16T18:46:05Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [coding](), [codex](), [Claude](), [Android](), [Google]() Tags: [ai](), [claude](), [codex](), [coding](), [gemini](), [google](), [gpt](), [model](), [models](), [subscriptions]() ### AI overview The author argues that monthly AI subscriptions are preferable to annual plans because AI models change quickly. They compare GPT Codex and Claude Sonnet 4.5 on an Android dependency-injection issue, favoring Codex's fix, while noting that an upcoming Gemini model may change the comparison. ### Source excerpt Go with monthly AI subscriptions friends I can't remember where I read this tip, but given how fast the AI lab models move, it's smarter to stick with a monthly plan instead of locking into an annual one, even if the annual price looks more attractive. I hit a DI issue on Android and was too lazy to debug it myself, so I pointed two models at it. GPT Codex gave me the cleanest, correct fix. Claude Sonnet 4.5 found a fix, but it wasn't idiomatic and was pretty aggressive with the changes. A month ago, I wouldn't have bothered with anything other than the Claude models for coding. Today, Codex clearly feels ahead. Google is about to ship its next Gemini model and, from what I'm hearing, it's going to be absurdly good. In these wonderfully unstable times, monthly subscriptions are the way to go. ## Firefox and uBlock Origin Compared with Chromium Browsers Under Manifest V3 DevFeed: [Firefox and uBlock Origin Compared with Chromium Browsers Under Manifest V3]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-11-14T04:38:50Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Firefox](), [Chromium](), [Extension](), [Edge]() Tags: [chromium](), [extension](), [firefox]() ### AI overview An opinion article arguing that Firefox with uBlock Origin provides more user-controllable blocking than Chromium-based alternatives constrained by Manifest V3. It describes Brave's native blocking patches and hosting of selected Manifest V2 extensions as workarounds. ### Source excerpt I often find myself replying to claims that Brave, Edge, or other Chromium browsers effectively achieve the same privacy standards as Firefox + uBlock Origin (uBO). This is simply not true. Brave and other Chromium browsers are constrained by Google's Manifest V3. Brave works around this by patching Chromium and self-hosting some MV2 extensions, but it is still swimming upstream against the underlying engine. Firefox does not have these MV3 constraints, so uBlock Origin on Firefox retains more powerful, user-controllable blocking than MV3-constrained setups like Brave + uBO Lite. Brave is an excellent product and what I used for a long time. But the comparison often ignores structural realities. There are important nuances that make Firefox the more future-proof platform for privacy-conscious users. Manifest V3 permanently nerfs Chromium-based browsers # The core issue is Manifest V3 (MV3). This is Google's new extension architecture for Chromium (what Chrome, Brave, and Edge are built on). Under Manifest V2, blockers like uBO used the blocking version of the webRequest API (webRequest + webRequestBlocking) to run their own code on each network request and decide whether to cancel, redirect, or modify it. MV3 deprecates that blocking path for normal extensions and replaces it with the declarativeNetRequest (DNR) API: extensions must declare a capped set of static rules in advance, and the browser enforces those rules without running extension code per request. This preserves basic blocking but, as uBO's developer documents, removes whole classes of filtering capabilities uBO relies on. And Google is forcing this change by deprecating MV2. Yeah, shitty. Brave's workaround for Manifest V3 # To get around the problem, Brave is effectively swimming upstream against its own engine. It does this in two ways: Native patching: It implements ad-blocking (Shields) natively in C++/Rust within the browser core to bypass extension limitations. Manual extension hosting: Brave now ## Cognitive Burden DevFeed: [Cognitive Burden]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-11-04T22:24:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Large Language Model](), [coding](), [Requirements]() Tags: [agent](), [ai](), [coding](), [llms](), [recent-fervor](), [requirements]() ### AI overview The author argues that AI tools are valuable primarily because they reduce cognitive burden and tedious work, rather than because they are inherently faster. Examples include using a custom agent to draft writing from bullet points and using AI while managing multiple software features, with the author continuing to review the output. ### Source excerpt A common argument I hear against AI tools: "It doesn't do the job better or faster than me, so why am I using this again?" Simple answer: cognitive burden. My biggest unlock with AI was realizing I could get more done, not because I was faster, but because I wasn't wringing my brain with needless tedium. Even if it took longer or needed more iterations, I'd finish less exhausted. That was the aha moment that sold me. On Writing # Simple example: when writing a technical1 post, I start with bullet points. Sometimes there's a turn of phrase or a bit of humor I enjoy, and I'll throw those in too. Then a custom agent trained on my writing generates a draft in my voice. After it drafts, I still review every single word. A naysayer might ask: "Well, if you're reviewing every single word anyway, at that point, why not just write the post from scratch?" Because it's dramatically easier and more enjoyable not to grind through and string together a bunch of prepositions to draft the whole post. I've captured the main points and added my creative touch; the AI handles the rest. With far less effort, I can publish more quickly -- not due to raw speed, but because it's low-touch and I focus only on what makes it uniquely me. Cognitive burden ↓. On Coding # About two years ago I pushed back on our CEO in a staff meeting: "Most of the time we engineers waste isn't in writing the code. It's the meetings, design discussions, working with PMs, fleshing out requirements -- that's where we should focus our AI efforts first."2 I missed the same point. Yes, I enjoy crafting every line of code and I'm not bogged down by that process per se, but there's a cognitive tax to pay. I'd even say I could still build a feature faster than some LLMs today (accounting for quality and iterations) before needing to take a break and recharge. Now I typically have 3-4 features in flight (with requisite docs, tests, and multiple variants to boot). Yes, I'm more productive. And sure, I'm probably shipping f ## Standardize with ⌘ O ⌘ P to reduce cognitive load DevFeed: [Standardize with ⌘ O ⌘ P to reduce cognitive load]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-11-01T00:38:50Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [macOS](), [Obsidian](), [Android Studio](), [IntelliJ IDEA](), [cursor](), [ide]() Tags: [android-studio](), [cognitive-load](), [cursor](), [ide](), [intellij](), [keyboard](), [macos](), [notes](), [shortcuts]() ### AI overview The author recommends standardizing ⌘ O for opening a file or note and ⌘ P for opening a command palette across macOS apps such as Obsidian, Android Studio, IntelliJ, and Cursor. They report that using consistent shortcuts reduces the need to remember app-specific commands and helps build muscle memory. ### Source excerpt There are a few apps on macOS in the text manipulation category that I end up spending a lot of time on. For example: Obsidian (for notes), Zed (text editor + IDE lite), Android Studio & Intellij (IDE++), Cursor (IDE + AI), etc. All these apps have two types of commands that I frequently use: Open a specific file or note Open the command palette (or find any action menu) But by default, these apps use ever so slightly different shortcuts. One might use ⌘ P, another might use ⌘ ⇧ P, etc. I've found it incredibly helpful to take a few minutes and make these specific keyboard shortcuts the same everywhere. So now I use: ⌘ O - Open a file/note ⌘ P - Open the command palette (or equivalent action menu) This small change has reduced cognitive load significantly. I no longer have to think about which app I'm in, and what the shortcut is for that specific app. Muscle memory takes over, and I can just get things done faster. Highly recommended! [Next page]()