Programming

• I kinda want to build more git/hub tools. I guess I have been trying to get to 20 repos that I am proud of. I certainly don’t all of them public. I am taking most of mine private or archiving. I should probably focus on like 5 or 1. Open claw happens when you become hyper fixated on just one thing.

  Feb 7, 2026 / Programming / Github

• Why Data Modeling Matters When Building with AI

  If you’ve started building software recently, especially if you’re leaning heavily on AI tools to help you code—here’s something that might not be obvious: data modeling matters more now than ever.

  AI is remarkably good at getting the local stuff right. Functions work. Logic flows. Tests pass. But when it comes to understanding the global architecture of your application? That’s where things get shaky.

  Without a clear data model guiding the process, you’re essentially letting the AI do whatever it thinks is best. And what the AI thinks is best isn’t always what’s best for your codebase six months from now.

  The Flag Problem

  When you don’t nail down your data structure upfront, AI tools tend to reach for flags to represent state. You end up with columns like is_draft, is_published, is_deleted, all stored as separate boolean fields.

  This seems fine at first. But add a few more flags, and suddenly you’ve got rows where is_draft = true AND is_published = true AND is_deleted = true.

  That’s an impossible state. Your code can’t handle it because it shouldn’t exist.

  Instead of multiple flags, use an enum: status: draft | published | deleted. One field. Clear states. No contradictions.

  This is just one example of why data modeling early can save you from drowning in technical debt later.

  Representation, Storage, and Retrieval

  If data modeling is about the shape of your data, data structures determine how efficiently you represent, store, and retrieve it.

  This matters because once you’ve got a lot of data, migrating from one structure to another, or switching database engines—becomes genuinely painful.

  When you’re designing a system, think about its lifetime.

  • How much data will you store monthly? Yearly?
  • How often do you need to retrieve it?
  • Does recent data need to be prioritized over historical data?
  • Will you use caches or queues for intermediate storage?

  Where AI Takes Shortcuts

  AI agents inherit our bad habits. Lists and arrays are everywhere in their training data, so they default to using them even when a set, hash map, or dictionary would perform dramatically better.

  In TypeScript, I see another pattern constantly: when the AI hits type errors, it makes everything optional.

  Problem solved, right? Except now your code is riddled with null checks and edge cases that shouldn’t exist.

  Then there’s the object-oriented problems. When building software that should use proper OOP patterns, AI often takes shortcuts in how it represents data. Those shortcuts feel fine in the moment but create maintenance nightmares down the road.

  The Prop Drilling Epidemic

  LLM providers have optimized their agents to be nimble, managing context windows so they can stay productive. That’s a good thing. But that nimbleness means the agents don’t always understand the full structure of your code.

  In TypeScript projects, this leads to prop drilling: passing the entire global application object down through nested components.

  Everything becomes tightly coupled. When you need to change the structure of an object, it’s like dropping a pebble in a pond. The ripples spread everywhere.

  You change one thing, and suddenly you’re fixing a hundred other places that all expected the old structure.

  The Takeaway

  If you’re building with AI, invest time in data modeling before you start coding. Define your data structures. Think about how your data will grow and how you’ll access it.

  The AI can help you build fast. But you still need to provide the architectural vision. That’s not something you can blindly trust the AI to handle, not yet, anyway.

  Feb 4, 2026 / AI / Programming / Software-development

  Enjoyed this?

• JavaScript Still Doesn't Have Types (And That's Probably Fine)

  Here’s the thing about JavaScript and types: it doesn’t have them, and it probably won’t any time soon.

  Back in 2022, there was a proposal to add TypeScript-like type syntax directly to JavaScript. The idea was being able to write type annotations without needing a separate compilation step. But the proposal stalled because the JavaScript community couldn’t reach consensus on implementation details.

  The core concern? Performance. JavaScript is designed to be lightweight and fast, running everywhere from browsers to servers to IoT devices. Adding a type system directly into the language could slow things down, and that’s a tradeoff many aren’t willing to make.

  So the industry has essentially accepted that if you want types in JavaScript, you use TypeScript. And honestly? That’s fine.

  TypeScript: JavaScript’s Type System

  TypeScript has become the de facto standard for typed JavaScript development. Here’s what it looks like:

  // TypeScript Example
  let name: string = "John";
  let age: number = 30;
  let isStudent: boolean = false;
  
  // Function with type annotations
  function greet(name: string): string {
    return `Hello, ${name}!`;
  }
  
  // Array with type annotation
  let numbers: number[] = [1, 2, 3];
  
  // Object with type annotation
  let person: { name: string; age: number } = { name: "Alice", age: 25 };
  

  TypeScript compiles down to plain JavaScript, so you get the benefits of static type checking during development without any runtime overhead. The types literally disappear when your code runs.

  The Python Parallel

  You might be interested to know that the closest parallel to this JavaScript/TypeScript situation is actually Python.

  Modern Python has types, but they’re not enforced by the language itself. Instead, you use third-party tools like mypy for static analysis and pydantic for runtime validation. There’s actually a whole ecosystem of libraries supporting types in Python in various ways, which can get a bit confusing.

  Here’s how Python’s type annotations look:

  # Python Example
  name: str = "John"
  age: int = 30
  is_student: bool = False
  
  # Function with type annotations
  def greet(name: str) -> str:
      return f"Hello, {name}!"
  
  # List with type annotation
  numbers: list[int] = [1, 2, 3]
  
  # Dictionary with type annotation
  person: dict[str, int] = {"name": "Alice", "age": 25}
  

  Look familiar? The syntax is surprisingly similar to TypeScript. Both languages treat types as annotations that help developers and tools understand the code, but neither strictly enforces them at runtime (unless you add additional tooling).

  What This Means for You

  If you’re writing JavaScript, stop, and use TypeScript. It’s mature and widely adopted. Now also you can run TypeScript directly in some runtimes like Bun or Deno.

  Type systems were originally omitted from many of these languages because the creators wanted to establish a low barrier to entry, making it significantly easier for people to adopt the language.

  Additionally, computers at the time were much slower, and compiling code with rigorous type systems took a long time, so creators prioritized the speed of the development loop over strict safety.

  However, with the power of modern computers, compilation speed is no longer a concern. Furthermore, the type systems themselves have improved significantly in efficiency and design.

  Since performance is no longer an issue, the industry has shifted back toward using types to gain better structure and safety without the historical downsides.

  Feb 2, 2026 / Programming / Python / javascript / Typescript

  Enjoyed this?

• The Rise of Spec-Driven Development: A Guide to Building with AI

  Spec-driven development isn’t new. It has its own Wikipedia page and has been around longer than you might realize.

  With the explosion of AI coding assistants, this approach has found new life and we now have a growing ecosystem of tools to support it.

  The core idea is simple: instead of telling an AI “hey, build me a thing that does the boops and the beeps” then hoping it reads your mind, you front-load the thinking.

  It’s kinda obvious, with it being in the name, but in case you are wondering, here is how it works.

  The Spec-Driven Workflow

  Here’s how it typically works:

  1. Specify: Start with requirements. What do you want? How should it behave? What are the constraints?

  2. Plan: Map out the technical approach. What’s the architecture? What “stack” will you use?

  3. Task: Break the plan into atomic, actionable pieces. Create a dependency tree—this must happen before that. Define the order of operations. This is often done by the tool.

  4. Implement: You work with whatever tool to build the software from your task list. The human is (or should be) responsible for deciding when a task is completed.

  You are still a part of the process. It’s up to you to make the decisions at the beginning. It’s up to you to define the approach. And it’s up to you to decide you’re done.

  So how do you get started?

  The Tool Landscape

  The problem we have now is there is not a unified standard. The tool makers are busy building the moats to take time to agree.

  Standalone Frameworks:

  • Spec-Kit - GitHub’s own toolkit that makes “specifications executable.” It supports multiple AI agents through slash commands and emphasizes intent-driven development.

  • BMAD Method - Positions AI agents as “expert collaborators” rather than autonomous workers. Includes 21+ specialized agents for different roles like product management and architecture.

  • GSD (Get Shit Done) - A lightweight system that solves “context rot” by giving each task a fresh context window. Designed for Claude Code and similar tools.

  • OpenSpec - Adds a spec layer where humans and AI agree on requirements before coding. Each feature gets its own folder with proposals, specs, designs, and task lists.

  • Autospec - A CLI tool that outputs YAML instead of markdown, enabling programmatic validation between stages. Claims up to 80% reduction in API costs through session isolation.

  Built Into Your IDE:

  The major AI coding tools have adopted this pattern too:

  • Kiro - Amazon’s new IDE with native spec support
  • Cursor - Has a dedicated plan mode
  • Claude Code - Plan mode for safe code analysis
  • VSCode Copilot - Chat planning features
  • OpenCode - Multiple modes including planning
  • JetBrains Junie - JetBrains' AI assistant
  • Google Antigravity - Implementation planning docs
  • Gemini Conductor - Orchestration for Gemini CLI

  Memory Tools

  • Beads - Use it to manage your tasks. Works very well with your Agents in Claude Code.

  Why This Matters

  When first getting started building with AI, you might dive right in and be like “go build thing”. You keep then just iterating on a task until it falls apart once you try to do anything substantial.

  You end up playing a game of whack-a-mole, where you fix one thing and you break another. This probably sounds familiar to a lot of you from the olden times of 2 years ago when us puny humans did all the work. The point being, even the robots make mistakes.

  Another thing that you come to realize is it’s not a mind reader. It’s a prediction engine. So be predictable.

  What did we learn? With spec-driven development, you’re in charge. You are the architect. You decide. The AI just handles the details, the execution, but the AI needs structure, and so these are the method(s) to how we provide it.

  Jan 31, 2026 / AI / Programming / Tools / Development

  Enjoyed this?

• Shu has a great article on performance:

  Performance is like a garden. Without constant weeding, it degrades.

  It’s not just a JavaScript thing, it’s a mindset. We keep making the same mistakes even with solid understanding of the code because just like Agents we too have a context window. It takes ongoing maintenance to keep the garden looking good.

  Worth a read: shud.in/thoughts/…

  Jan 28, 2026 / Programming / Performance

• I’m reading an article today about a long-term programmer coming to terms with using Claude Code. There’s a quote at the end that really stuck with me: “It’s easy to generate a program you don’t understand, but it’s much harder to fix a program that you don’t understand.”

  I concur, while building it may be fun, guess what? Once you build it, you got to maintain it, and as a part of that, it means you got to know how it works for when it doesn’t.

  Jan 26, 2026 / AI / Programming / Claude-code

• Security and Reliability in AI-Assisted Development

  You may not realize it, but AI code generation is fundamentally non-deterministic. It’s probabilistic at its core, it’s predicting code rather than computing it.

  And while there’s a lot of orchestration happening between the raw model output and what actually lands in your editor, you can still get wildly different results depending on how you use the tools.

  This matters more than most people realize.

  Garbage In, Garbage Out (Still True)

  The old programming adage applies here with renewed importance. You need to be explicit with these tools. Adding predictability into how you build is crucial.

  Some interesting patterns:

  • Specialized agents set up for specific tasks
  • Skills and templates for common operations
  • Orchestrator conversations that plan but don’t implement directly
  • Multiple conversation threads working on the same codebase via Git workspaces

  The more structure you provide, the more consistent your output becomes.

  The Security Problem

  This topic doesn’t get talked about enough. All of our common bugs have snuck into the training data. SQL injection patterns, XSS vulnerabilities, insecure defaults… they’re all in there.

  The model can’t always be relied upon to build it correctly the first time. Then there’s the question of trust.

  Do you trust your LLM provider?

  Is their primary focus on quality and reliable, consistent output? What guardrails exist before the code reaches you? Is the model specialized for coding, or is it a general-purpose model that happens to write code?

  These are important engineering questions.

  Deterministic Wrappers Around Probabilistic Cores

  The more we can put deterministic wrappers around these probabilistic cores, the more consistent the output will be.

  So, what does this look like in practice?

  Testing is no longer optional. We used to joke that we’d get to testing when we had time. That’s not how it works anymore. Testing is required because it provides feedback to the models. It’s your mechanism for catching problems before they compound.

  Testing is your last line of defense against garbage sneaking into the system.

  AI-assisted review is essential. The amount of code you can now create has increased dramatically. You need better tools to help you understand all that code. The review step, typically done during a pull request, is now crucial for product development. Not optional. Crucial.

  The models need to review itself, or you need a separate review process that catches what the generating step missed.

  The Takeaway

  We’re in an interesting point in time. These tools can dramatically increase your output, but only if you build the right guardrails around them should we trust the result.

  Structure your prompts. Test everything. Review systematically. Trust but verify.

  The developers who figure out how to add predictability to unpredictable processes are the ones who’ll who will be shipping features instead of shitting out code.

  Jan 22, 2026 / DevOps / AI / Programming

  Enjoyed this?

• Learning to Program in 2026

  If I had to start over as a programmer in 2026, what would I do differently? This question comes up more and more and with people actively building software using AI, it’s as relevant as ever.

  Some people will tell you to pick a project and learn whatever language fits that project best. Others will push JavaScript because it’s everywhere and you can build just about anything with it. Both are reasonable takes, but I do think there’s a best first language.

  However, don’t take my word for it. Listen to Brian Kernighan. If you’re not familiar with the name, he co-authored The C Programming Language back in 1978 and worked at Bell Labs alongside the creators of Unix. Oh also, he is a computer science Professor at Princeton. This man TAUGHT programming to generations of computer scientists.

  There’s an excellent interview on Computerphile with Kernighan where he makes a compelling case for Python as the first language.

  Why Python?

  Kernighan makes three points that you should listen to.

  First, the “no limitations” argument. Tools like Scratch are great for kids or early learners, but you hit a wall pretty quickly. Python sits in a sweet spot—it’s readable and approachable, but the ecosystem is deep enough that you won’t outgrow it.

  Second, the skills transfer. Once you learn the fundamentals—loops, variables, data structures—they apply everywhere. As Kernighan puts it: “If you’ve done N programming languages, the N+1 language is usually not very hard to get off the ground.”

  Learning to think in code matters more than any specific syntax.

  Third, Python works great for prototyping. You can build something to figure out your algorithms and data structures, then move to another language depending on your needs.

  Why Not JavaScript?

  JavaScript is incredibly versatile, but it throws a lot at beginners. Asynchronous behavior, event loops, this binding, the DOM… and that’s a lot of cognitive overhead when you’re just trying to grasp what a variable is.

  Python’s readable syntax lets you focus on learning how to think like a programmer. Fewer cognitive hurdles means faster progress on the fundamentals that actually matter.

  There’s also the type system. JavaScript’s loose equality comparisons (== vs ===) and automatic type coercion trip people up constantly.

  Python is more predictable. When you’re learning, predictable is good.

  The Path Forward

  So here’s how I’d approach it: start with Python and focus on the basics. Loops, variables, data structures.

  Get comfortable reading and writing code. Once you’ve got that foundation, you can either go deeper with Python or branch out to whatever language suits the projects you want to build.

  The goal isn’t to master Python, it’s to learn how to think about problems and express solutions in code.

  That skill transfers everywhere, including reviewing AI-generated code in whatever language you end up working with.

  There are a ton of great resources online to help you learn Python, but one I see consistently is Python for Everyone by Dr Chuck.

  Happy coding!

  Jan 21, 2026 / Programming / Python / learning

  Enjoyed this?

• Two Arguments Against AI in Programming (And Why I'm Not Convinced)

  I’ve been thinking about the programmers who are against AI tools, and I think their arguments generally fall into two camps.

  Of course, these are just my observations, so take them with a grain of salt, or you know, tell me I’m a dumbass in the comments.

  The Learning Argument

  The first position is that AI prevents you from learning good software engineering concepts because it does the hard work for you.

  All those battle scars that industry veterans have accumulated over the years aren’t going to be felt by the new breed. For sure, the painful lessons about why you should do something this way and not that way are important to preserve into the future.

  Maybe we’re already seeing anti-patterns slip back into how we build code? I don’t know for sure, its going to require some PHD level research to figure it out.

  To this argument I say, if we haven’t codified the good patterns by now, what the hell have we all been doing? I think we have more good patterns in the public code than there are bad ones.

  So just RELAX! The cream will rise to the top. The glass is half full. We’ll be fine… Which brings me to the next argument.

  The Non-Determinism Argument

  The second position comes from people who’ve dug into how large language models actually work.

  They see that it’s predicting the next token, and they start thinking of it as this fundamentally non-deterministic thing.

  How can we trust software built on predictions? How do we know what’s actually going to happen when everything is based on weights created during training?

  Here’s the thing though: when you’re using a model from a provider, you’re not getting raw output. There’s a whole orchestration layer. There’s guardrails, hallucination filters, mixture of experts approaches, and the thinking features that all work together to let the model double-check its work before responding.

  It’s way more sophisticated than “predict the next word and hope for the best.”

  That said, I understand the discomfort. We’re used to deterministic systems where the same input reliably produces the same output.

  We are are now moving from those type of systems to ones that are probabilistic.

  Let me remind you, math doesn’t care about the differences between a deterministic and a probabilistic system. It just works, and so we¹.

  The Third Argument I’m Skipping

  There’s obviously a third component; the ethical argument about training data, labor displacement, and whether these tools should exist at all.

  I will say this though, it’s too early to make definitive ethical judgments on a tool while we’re still building it, while we’re still discovering what it’s actually useful for.

  Will it all be worth it in the end? We won’t know until the end.

  ---

  1. This “we” I use to mean us as in the human race, but also our software we build. ↩︎

  Jan 18, 2026 / AI / Programming / Software-engineering

  Enjoyed this?

• When do you think everyone will finally agree that Python is Python 3 and not 2? I know we aren’t going to get a major version bump anytime soon, if ever again, but we really should consider putting uv in core… Python needs modern package management baked in.

  Jan 16, 2026 / Programming / Python

• OpenCode | The open source AI coding agent

  OpenCode - The open source coding agent.

  Jan 16, 2026 / AI / Programming / Tools / links / agent / open source / code

• Amp

  Amp is a frontier coding agent that lets you wield the full power of leading models.

  Jan 16, 2026 / AI / Programming / Tools / links / agent / automation / code

• vibe is the bait, code is the switch.

  Vibe coding gets people in the door. We all know the hooks. Once you’re actually building something real, you still need to understand what the code is doing. And that’s not a bad thing.

  Jan 12, 2026 / AI / Programming / Vibe-coding

• CodeAnt AI - Blogs

  Stay updated with the latest news, feature releases, and critical security and code quality blogs from CodeAnt AI.

  Jan 11, 2026 / AI / Programming / blogging / links / security

• Claude Code Learning Hub - Master AI-Powered Development

  Learn Claude Code, VS Code, Git/GitHub, Python, and R with hands-on tutorials. Build real-world projects with AI assistance.

  Jan 11, 2026 / Programming / Development / links / tutorials / code / coding lessons / learning

• Shadcn Studio - Shadcn UI Components, Blocks & Templates

  Accelerate your project development with ready-to-use, & customizable 1000+ Shadcn UI Components, Blocks, UI Kit, Boilerplate, Templates & Themes with AI Tools.

  Jan 6, 2026 / AI / Programming / Tools / links / library / UIkit

• Introducing api2spec: Generate OpenAPI Specs from Source Code

  You’ve written a beautiful REST API. Routes are clean, handlers are tested and the types are solid. But where’s your OpenAPI spec? It’s probably outdated, incomplete, or doesn’t exist at all.

  If you’re “lucky”, you’ve been maintaining one by hand. The alternatives aren’t great either, runtime generation requires starting your app and hitting every endpoint or annotation-heavy approaches clutter your code. At this point we should all know, with manual maintenance it’ll inevitably drift from reality.

  What if you could just point a tool at your source code and get an OpenAPI spec?

  Enter api2spec

  # Install
  go install github.com/api2spec/api2spec@latest
  
  # Initialize config (auto-detects your framework)
  api2spec init
  
  # Generate your spec
  api2spec generate
  

  That’s it. No decorators to add. No server to start. No endpoints to crawl.

  What We Support

  Here’s where it gets interesting. We didn’t build this for one framework—we built a plugin architecture that supports 30+ frameworks across 16 programming languages:

  • Go: Chi, Gin, Echo, Fiber, Gorilla Mux, stdlib
  • TypeScript/JavaScript: Express, Fastify, Koa, Hono, Elysia, NestJS
  • Python: FastAPI, Flask, Django REST Framework
  • Rust: Axum, Actix, Rocket
  • PHP: Laravel, Symfony, Slim
  • Ruby: Rails, Sinatra
  • JVM: Spring Boot, Ktor, Micronaut, Play
  • And more: Elixir Phoenix, ASP.NET Core, Gleam, Vapor, Servant…

  How It Works

  The secret sauce is tree-sitter, an incremental parsing library that can parse source code into concrete syntax trees.

  Why tree-sitter instead of language-specific AST libraries?

  1. One approach, many languages. We use the same pattern-matching approach whether we’re parsing Go, Rust, TypeScript, or PHP.
  2. Speed. Tree-sitter is designed for real-time parsing in editors. It’s fast enough to parse entire codebases in seconds.
  3. Robustness. It handles malformed or incomplete code gracefully, which is important when you’re analyzing real codebases.
  4. No runtime required. Your code never runs. We can analyze code even if dependencies aren’t installed or the project won’t compile.

  For each framework, we have a plugin that knows how to detect if the framework is in use, find route definitions using tree-sitter queries, and extract schemas from type definitions.

  ---

  Let’s Be Honest: Limitations

  Here’s where I need to be upfront. Static analysis has fundamental limitations.

  When you generate OpenAPI specs at runtime (like FastAPI does natively), you have perfect information. The actual response types. The real validation rules. The middleware that transforms requests.

  We’re working with source code. We can see structure, but not behavior.

  What this means in practice:

  • Route detection isn’t perfect. Dynamic routing or routes defined in unusual patterns might be missed.
  • Schema extraction varies by language. Go structs with JSON tags? Great. TypeScript interfaces? We can’t extract literal union types as enums yet.
  • We can’t follow runtime logic. If your route path comes from a database, we won’t find it.
  • Response types are inferred, not proven.

  This is not a replacement for runtime-generated specs. But maybe so in the future and for many teams, it’s a massive improvement over having no spec at all.

  Built in a Weekend

  The core of this tool was built in three days.

  • Day one: Plugin architecture, Go framework support, CLI scaffolding
  • Day two: TypeScript/JavaScript parsers, schema extraction from Zod
  • Day three: Python, Rust, PHP support, fixture testing, edge case fixes

  Is it production-ready? Maybe?

  Is it useful? Absolutely.

  For the fixture repositories we’ve created realistic APIs in Express, Gin, Flask, Axum, and Laravel. api2spec correctly extracts 20-30 routes and generates meaningful schemas. Not perfect. But genuinely useful.

  How You Can Help

  This project improves through real-world testing. Every fixture we create exposes edge cases. Every framework has idioms we haven’t seen yet.

  • Create a fixture repository. Build a small API in your framework of choice. Run api2spec against it. File issues for what doesn’t work.
  • Contribute plugins. The plugin interface is straightforward. If you know a framework well, you can make api2spec better at parsing it.
  • Documentation. Found an edge case? Document it. Figured out a workaround? Share it.

  The goal is usefulness, and useful tools get better when people use them.

  ---

  Getting Started

  go install github.com/api2spec/api2spec@latest
  cd your-api-project
  api2spec init
  api2spec generate
  cat openapi.yaml
  

  If it works well, great! If it doesn’t, file an issue. Either way, you’ve helped.

  api2spec is open source under the FSL-1.1-MIT license. Star us on GitHub if you find it useful.

  Built with love, tree-sitter, and too much tea. ☕

  Jan 5, 2026 / DevOps / Programming / Openapi / Golang / Open-source

  Enjoyed this?

• please make it stop

  😮‍💨

  pattern = re.compile(r"""
      ^                           # The beginning of my hubris
      I \s+ may \s+ be \s+        # A moment of hope
      done \s+ with \s+           # Freedom! Sweet freedom!
      regex                       # The beast I sought to escape
      \s+ but \s+                 # Plot twist incoming...
      regex                       # It's back. It was always back.
      \s+ is \s+ not \s+          # The cruel truth
      done \s+ with \s+           # It has unfinished business
      me                          # I am the business
      $                           # There is no escape, only EOL
  """, re.VERBOSE)
  

  Dec 4, 2025 / Programming

  Enjoyed this?

• Rust I wrote for my Link in Bio site. I think Link in Bio is my favorite thing to build for learning a language or new library combination. Checkout Github Templates setting for base sites that you can iterate on.

  

  Nov 6, 2025 / Programming

• It’s just #Vibes Man

  

  Nov 6, 2025 / Programming

• Automate Folder Archiving on macOS with Raycast and 7zip

  If you’re like me and frequently need to archive project folders to an external drive, you know how tedious the process can be: right-click, compress, wait, find the archive, move it to the external drive, rename if there’s a conflict… It’s a workflow that begs for automation.

  Today, I’m going to show you how I built a custom Raycast script that compresses any folder with 7zip and automatically moves it to an external drive, all with a single keyboard shortcut.

  What We’re Building

  A Raycast script command that:

  • Takes whatever folder you have selected in Finder
  • Compresses it using 7zip (better compression than macOS’s built-in zip)
  • Moves it directly to a specified folder on your external drive
  • Automatically handles version numbering if the archive already exists
  • Provides clear error messages if something goes wrong

  No more manual copying. No more filename conflicts. Just select, trigger, and done.

  Prerequisites

  Before we start, you’ll need:

  1. Raycast - Download from raycast.com if you haven’t already
  2. 7zip - Install via Homebrew:

     brew install p7zip
  

  3. An external drive - Obviously, but make sure you know its mount path

  The Problem with the Built-in Approach

  Initially, I thought: “Can’t I just have Raycast pass the selected folder path as an argument?”

  The answer is technically yes, but it’s clunky. Raycast would prompt you for the folder path every time, which means you’d need to:

  1. Copy the folder path
  2. Trigger the Raycast command
  3. Paste the path
  4. Hit enter

  That’s not automation—that’s just extra steps with good intentions.

  The Solution: AppleScript Integration

  The key insight was using AppleScript to grab the currently selected item from Finder. This way, the workflow becomes:

  1. Select a folder in Finder
  2. Trigger the Raycast command (I use Cmd+Shift+7)
  3. Watch it compress and move automatically

  No input required. No path copying. Just pure automation bliss.

  Building the Script

  Here’s the complete script with all the error handling we need:

  #!/bin/bash
  
  # Required parameters:
  # @raycast.schemaVersion 1
  # @raycast.title Compress Selected to External Drive
  # @raycast.mode fullOutput
  
  # Optional parameters:
  # @raycast.icon 📦
  # @raycast.needsConfirmation false
  
  # Documentation:
  # @raycast.description Compress selected Finder folder with 7zip and move to external drive
  # [@raycast.author](http://raycast.author) Your Name
  
  EXTERNAL_DRIVE="/Volumes/YourDrive/ArchiveFolder"
  
  # Get the selected item from Finder
  FOLDER_PATH=$(osascript -e 'tell application "Finder" to set selectedItems to selection
  if (count of selectedItems) is 0 then
      return ""
  else
      return POSIX path of (item 1 of selectedItems as alias)
  end if')
  
  # Check if anything is selected
  if [ -z "$FOLDER_PATH" ]; then
      echo "❌ Error: No item selected in Finder"
      echo "Please select a folder in Finder and try again"
      exit 1
  fi
  
  # Trim whitespace
  FOLDER_PATH=$(echo "$FOLDER_PATH" | xargs)
  
  # Check if path exists
  if [ ! -e "$FOLDER_PATH" ]; then
      echo "❌ Error: Path does not exist: $FOLDER_PATH"
      exit 1
  fi
  
  # Check if path is a directory
  if [ ! -d "$FOLDER_PATH" ]; then
      echo "❌ Error: Selected item is not a folder: $FOLDER_PATH"
      exit 1
  fi
  
  # Check if 7z is installed
  if ! command -v 7z &> /dev/null; then
      echo "❌ Error: 7z not found. Install with: brew install p7zip"
      exit 1
  fi
  
  # Check if external drive is mounted
  if [ ! -d "$EXTERNAL_DRIVE" ]; then
      echo "❌ Error: External drive not found at: $EXTERNAL_DRIVE"
      echo "Make sure the drive is connected and mounted"
      exit 1
  fi
  
  # Create archive name from folder name
  BASE_NAME="$(basename "$FOLDER_PATH")"
  ARCHIVE_NAME="${BASE_NAME}.7z"
  OUTPUT_PATH="$EXTERNAL_DRIVE/$ARCHIVE_NAME"
  
  # Check if archive already exists and find next available version number
  if [ -f "$OUTPUT_PATH" ]; then
      echo "⚠️  Archive already exists, creating versioned copy..."
      VERSION=2
      while [ -f "$EXTERNAL_DRIVE/${BASE_NAME}_v${VERSION}.7z" ]; do
          VERSION=$((VERSION + 1))
      done
      ARCHIVE_NAME="${BASE_NAME}_v${VERSION}.7z"
      OUTPUT_PATH="$EXTERNAL_DRIVE/$ARCHIVE_NAME"
      echo "📝 Using version number: v${VERSION}"
      echo ""
  fi
  
  echo "🗜️  Compressing: $(basename "$FOLDER_PATH")"
  echo "📍 Destination: $OUTPUT_PATH"
  echo ""
  
  # Compress with 7zip
  if 7z a "$OUTPUT_PATH" "$FOLDER_PATH"; then
      echo ""
      echo "✅ Successfully compressed and moved to external drive"
      echo "📦 Archive: $ARCHIVE_NAME"
      echo "📊 Size: $(du -h "$OUTPUT_PATH" | cut -f1)"
  else
      echo ""
      echo "❌ Error: Compression failed"
      exit 1
  fi
  

  Key Features Explained

  1. Finder Integration

  The AppleScript snippet grabs whatever you have selected in Finder:

  FOLDER_PATH=$(osascript -e 'tell application "Finder" to set selectedItems to selection
  if (count of selectedItems) is 0 then
      return ""
  else
      return POSIX path of (item 1 of selectedItems as alias)
  end if')
  

  This returns a POSIX path (like /Users/yourname/Documents/project) that we can use with standard bash commands.

  2. Comprehensive Error Checking

  The script validates everything before attempting compression:

  • Is anything selected?
  • Does the path exist?
  • Is it actually a directory?
  • Is 7zip installed?
  • Is the external drive connected?

  Each check provides a helpful error message so you know exactly what went wrong.

  3. Automatic Version Numbering

  This was a crucial addition. If project.7z already exists, the script will automatically create project_v2.7z. If that exists, it’ll create project_v3.7z, and so on:

  if [ -f "$OUTPUT_PATH" ]; then
      VERSION=2
      while [ -f "$EXTERNAL_DRIVE/${BASE_NAME}_v${VERSION}.7z" ]; do
          VERSION=$((VERSION + 1))
      done
      ARCHIVE_NAME="${BASE_NAME}_v${VERSION}.7z"
      OUTPUT_PATH="$EXTERNAL_DRIVE/$ARCHIVE_NAME"
  fi
  

  No more manual renaming. No more overwriting precious backups.

  4. Progress Feedback

  Using @raycast.mode fullOutput means you see everything that’s happening:

  • Which folder is being compressed
  • Where it’s going
  • The final archive size

  This transparency is important when you’re archiving large projects that might take a few minutes.

  Setting It Up

  1. Find your external drive path:

     ls /Volumes/
  

  Look for your drive name, then determine where you want archives saved. For example: /Volumes/Expansion/WebProjectsArchive

  2. Create the script:

     • Open Raycast Settings → Extensions → Script Commands
     • Click “Create Script Command”
     • Paste the script above
     • Update the EXTERNAL_DRIVE variable with your path
     • Save it (like ~/Documents/Raycast/Scripts/ or ~/.local/raycast)

  3. Make it executable:

     chmod +x ~/.local/raycast/compress-to-external.sh
  

  4. Assign a hotkey (optional but recommended):
     • In Raycast, search for your script
     • Press Cmd+K and select “Add Hotkey”
     • I use Cmd+Shift+7 for “Archive”

  Using It

  Now the workflow is beautifully simple:

  1. Open Finder
  2. Select a folder
  3. Hit your hotkey (or trigger via Raycast search)
  4. Watch the magic happen

  The script will show you the compression progress and let you know when it’s done, including the final archive size.

  Why 7zip Over Built-in Compression?

  macOS has built-in zip compression, so why bother with 7zip? A few reasons:

  • Better compression ratios - 7zip typically achieves 30-70% better compression than zip
  • Cross-platform - .7z files are widely supported on Windows and Linux
  • More options - If you want to add encryption or split archives later, 7zip supports it
  • Speed - 7zip can be faster for large files

  For project archives that might contain thousands of files and dependencies, these advantages add up quickly.

  Potential Improvements

  This script works great for my needs, but here are some ideas for enhancement:

  • Multiple drive support - Let the user select from available drives
  • Compression level options - Add arguments for maximum vs. fast compression
  • Notification on completion - Use macOS notifications for long-running compressions
  • Delete original option - Add a flag to remove the source folder after successful archiving
  • Batch processing - Handle multiple selected folders

  Troubleshooting

  “7z not found” error:

  brew install p7zip
  

  “External drive not found” error: Make sure your drive is connected and the path in EXTERNAL_DRIVE matches exactly. Check with:

  ls -la /Volumes/YourDrive/YourFolder
  

  Script doesn’t appear in Raycast: Refresh the script directory in Raycast Settings → Extensions → Script Commands → Reload All Scripts

  Permission denied: Make sure the script is executable:

  chmod +x your-script.sh
  

  Conclusion

  This Raycast script has saved me countless hours of manual file management. What used to be a multi-step process involving right-clicks, waiting, dragging, and renaming is now a single keyboard shortcut.

  The beauty of Raycast’s script commands is that they’re just bash scripts with some metadata. If you know bash, you can automate almost anything on your Mac. This particular script demonstrates several useful patterns:

  • Integrating with Finder via AppleScript
  • Robust error handling
  • Automatic file versioning
  • User-friendly progress feedback

  I encourage you to take this script and adapt it to your own workflow. Maybe you want to compress to Dropbox instead of an external drive. Maybe you want to add a timestamp to the filename. The flexibility is there, you just need to modify a few lines.

  Happy automating!

  ---

  Have questions or improvements? Feel free to reach out. If you build something cool with this pattern, I’d love to hear about it!

  Oct 14, 2025 / DevOps / Programming

  Enjoyed this?

• The Password Paradox: When Security Becomes Absurdity

  I created an account on VRBO today and was shocked by their password policy. A password with over 30 characters was flagged as “weak” simply because it didn’t contain special characters. We can do better than this.

  This is the current state of digital security: passwords so complex that humans can’t remember them, pushing us all toward password managers (which, let’s be honest, we should be using). But here’s the thing - while there are some standards and best practices for password security, implementation is wildly inconsistent. Each business decides how much they want to enforce “good” password policies, and even when they try to follow security methodologies, the execution is all over the map.

  You end up with systems that reject genuinely strong passwords while accepting demonstrably weak ones, all because someone’s algorithm prioritizes symbols over entropy.

  It’s security theater at its finest.

  FREE THE EMAILS AT MY blurgl blog

  

  Aug 4, 2025 / Programming

  Enjoyed this?

• What you should start saying in Standup now

  

  Aug 4, 2025 / DevOps / Programming

• So the Gemini CLI...

  Two minor gripes with the Gemini CLI tool. I know, I know … it just came out.

  1. There’s no init command to automatically get it to generate its context file. I asked it to do it, and it created an empty file, and then I had to follow up with a second prompt to get it to update the file with helpful information. I’m never going to use that until it’s easier.

  2. I ran a few prompts, and it automatically switched to the flash model, and there’s no way to control what model it uses. Like maybe I’m okay with a bit slower responses if it means I can use the pro-model. I’d like the ability to be able to control this, and there doesn’t seem to be a way to switch between the models.

  

  Jun 26, 2025 / Programming

  Enjoyed this?

• I built a BlueSky Bot in 6 hours last week. I promise for good reasons.

  TELL THE BOT THEY’RE DOING SUCH A GOOD JOB

  It runs a query, does some analytics, then gives a progress update to socials.

  

  Jun 25, 2025 / Programming