DevOps

• When to Use Python Over Bash

  When to use python over bash is really a question of when to use bash. Python is a general-purpose language that can handle just about anything you throw at it. Bash, on the other hand, has a very specific sweet spot. Once you understand that sweet spot, the decision makes itself.

  What Bash Actually Is

  Bash is an interactive command interpreter and scripting language, created in 1989 for the GNU project as a free software alternative to the Bourne shell. It pulled in advanced features from the Korn shell and C shell, and it’s been commonly used by Unix and Linux systems ever since.

  What makes Bash unique is its approach to data flow programming. Files, directories, and system processes are treated as first-class objects. Bash is designed to take advantage of utilities that almost always exist on Unix-based systems. So think of tools like awk, sed, grep, cat, and curl. Another important thing to know when writing effective Bash scripts, you also need to understand the pipeline operator and how I/O redirection works.

  A good Bash script will look something like this:

  #!/bin/bash
  set -euo pipefail
  
  LOG_DIR="/var/log/myapp"
  DAYS_OLD=30
  
  find "$LOG_DIR" -name "*.log" -mtime +"$DAYS_OLD" -print0 |
    xargs -0 gzip -9
  
  echo "Compressed logs older than $DAYS_OLD days"
  

  Simple, portable, does one thing well. That’s Bash at its best.

  Where Bash Falls Short

  Bash isn’t typed. There’s no real object orientation. Error handling is basically set -e and hoping for the best. There’s no try/catch, no structured exception handling. When things go wrong in a Bash script, they tend to go wrong quietly or spectacularly, with not much in between.

  Python, by contrast, is optionally strongly typed and object-oriented. If you want to manipulate a file or a system process in Python, you wrap that system entity inside a Python object. That adds some overhead, sure, but in exchange you get something that’s more predictable, more secure, and scales well from simple scripts to complex logic.

  Here’s that same log compression task in Python:

  from pathlib import Path
  import gzip
  import shutil
  from datetime import datetime, timedelta
  
  log_dir = Path("/var/log/myapp")
  cutoff = datetime.now() - timedelta(days=30)
  
  for log_file in log_dir.glob("*.log"):
      if datetime.fromtimestamp(log_file.stat().st_mtime) < cutoff:
          with open(log_file, "rb") as f_in:
              with gzip.open(f"{log_file}.gz", "wb") as f_out:
                  shutil.copyfileobj(f_in, f_out)
          log_file.unlink()
  

  More verbose? Absolutely. But also more explicit about what’s happening, easier to extend, and much easier to add error handling to.

  The Performance Question

  In some cases, performance genuinely matters. Think high-frequency trading platforms, edge devices, or massive clusters. Bash scripts excel here because there’s almost zero startup overhead. Compare that to Python, which needs to load up the interpreter before it can start executing code. You’re going from microseconds to milliseconds, and sometimes that matters.

  But startup time is just one factor. When you compare the actual work being done, Python can pull ahead. String manipulation on structured data? Python wins. Parsing JSON, YAML, or any structured format? Python’s core libraries are written in C and optimized for exactly this kind of work. If you find yourself reaching for jq or yq in a Bash script, that’s a strong signal you should be using Python instead.

  The Guidelines People Throw Around

  You’ll see a common guideline online: if your script exceeds 100 lines of Bash, rewrite it in Python. But a lot of veterans in the industry feel like that cutoff is way too generous. Experienced engineers often put it at 50 lines, or even 25.

  Another solid indicator: nested if statements. Some people say “deeply nested” if statements, but let’s be honest, more than one level of nesting in Bash is already getting painful. Python handles complex branching logic far more gracefully, and you’ll thank yourself when you come back to maintain it six months later.

  Unit Testing Tells the Story

  You can do unit testing with Bash. BATS (Bash Automated Testing System) exists, and ShellCheck is useful as a lightweight linter for catching bad practices. But despite these tools, Python’s testing ecosystem is on another level entirely. It’s fully mature with multiple frameworks, excellent mocking capabilities, and the ability to simulate network calls, external APIs, or system binaries. Complex mocking that would be difficult or impossible in Bash is straightforward in Python.

  If your script needs solid testing or if it’s doing anything important, that’s a strong vote for Python.

  Bash’s Biggest Win: Portability

  So what does Bash actually win at? Portability. When you think about all the dependencies Python needs to run, Bash is the clear winner. You’re distributing a single .sh file. That’s it.

  With Python, you have to ask: Does Python exist on this machine? Is it the right version? You’ll need a virtual environment so you don’t pollute system Python. You need third-party libraries installed via a package manager; and please friends, remember that we don’t let friends use pip. Use Poetry or uv. Pip is so bad that I’d honestly argue that Bash not having a package manager is better than Python having pip. At least Bash doesn’t pretend to manage dependencies well.

  If you want something simple, something that can run on practically any Unix-based machine without setup, Bash is your answer. Even Windows can handle it these days through WSL, though you’re jumping through a few hoops.

  TLDR

  The decision is actually pretty straightforward:

  • Use Bash when you’re gluing together system commands, the logic is linear, it’s under 50 lines, and portability matters.
  • Use Python when you’re parsing structured data, need error handling, have branching logic, want proper tests, or the script is going to grow.

  If you’re reaching for jq, writing nested if statements, or the script is getting long enough that you’re losing track of what it does… it’s time for Python.

  I think in a future post we might look at when Go makes sense over Bash. There’s a lot to cover there about compiled binaries, but for now, hopefully this helps you make the call next time you’re wondering what to start your scripting with.

  Mar 10, 2026 DevOps Programming Python Bash Scripting

  Enjoyed this?

• Local Secrets Manager - Dotenv Encrypter

  I built a thing to solve a problem. It has helped me, maybe it will help you?

  It all starts with a question.

  Why isn’t there a good local secrets manager that encrypts your secrets at rest? I imagine a lot of people, like me, have a number of local applications. I don’t want to pay per-seat pricing just to keep my sensitive data from sitting in plaintext on my machine.

  I built an app called LSM Local Secrets Manager to solve that problem. The core idea is simple. Encrypt your .env files locally and only decrypt when you need them (sometimes at runtime).

  The Problem

  If you’ve got a bunch of projects on your machine, each with their own .env or .env.local file full of API keys you’re definitely not rotating every 90 days. Those files just sit there in plaintext. Any process on your system can read them. And with AI agents becoming part of our dev workflows, the attack surface for leaking secrets is only getting easier.

  ThE CLAW EnteRed ChaT

  I started looking at Doppler specifically for OpenCLAW. Their main selling feature is injecting secrets into your runtime so they never touch the filesystem. I was like, cool. Also I like that Doppler stores everything remotely. The only thing was the cost did not make sense for me right now. I don’t want to pay $10-20 a month for this set of features.

  So what else is there?

  Well GCP Secret Manager has its own set of issues.

  You can’t have duplicate names per project, so something as common as NODE_ENV across multiple apps becomes a more work than you want to deal with. Some wrapper script that injects prefixes? No thanks. I imagine there are a thousand and one homegrown solutions to solve this problem. Again, no thanks.

  So what else is there?

  You Find A Solution

  AWS Secret Manager

  A Problem for Solution Problem

  AWS IAM

  🫣

  I have a lot more to say here on this subject but will save this for another post. Subscribe if you want to see the next post.

  The Solution

  The workflow is straightforward:

  1. lsm init — Run this once from anywhere. It generates your encryption key file.
  2. lsm link <app-name> — Run this inside your project directory. It creates a config entry in ~/.lsm/config.yaml for that application.
  3. lsm import — Takes your existing .env or .env.local and creates an encrypted version.
  4. lsm clean — Removes the plaintext .env files so they’re not just sitting around.
  5. lsm dump — Recreates the .env files if you need them back.

  But wait there’s more.

  Runtime Injection with lsm exec

  Remember that cool thing I just told you about? Instead of dumping secrets back to disk, you run:

  lsm exec -- pnpm dev
  

  I feel like a family man from Jersey, who don’t mess around. Aye, you got, runtime injection. I got that.

  Well that’s lsm anyways. It can decrypt your secrets and inject them directly into the runtime environment of whatever command follows the --. Your secrets exist in memory for the duration of that process and nowhere else. No plaintext files hanging around for other processes to sniff.

  Credit to Doppler for the idea. The difference to what we are doing is your encrypted files stay local.

  What’s Next

  I’ve got some possible ideas of improvements to try building.

  • Separate encrypt/decrypt keys — You create secrets with one key, deploy the encrypted file to a server, and use a read-only key to decrypt at runtime. The server never has write access to your secrets.
  • Time-based derivative keys — Imagine keys that expire or rotate automatically.
  • Secure sharing — Right now you’d have to decrypt and drop the file into a password manager to share it. There’s room to make that smoother.

  I’m not sure how to do all of that yet, but we’re making progress.

  Why Not Just Use Doppler?

  There are genuinely compelling reasons to use Doppler or similar services. I mean bsides the remote storage, access controls and auditable logs. There’s a lot to love.

  For local development across a bunch of personal projects? I don’t think you should need a SaaS subscription to keep your secrets encrypted.

  LSM is still early, but the core workflow is there and it works.

  Give it a try if you’re tired of plaintext .env files scattered across your machine.

  

  Mar 9, 2026 DevOps Programming Tools security

  Enjoyed this?

• Doppler | Centralized cloud-based secrets management platform

  Doppler’s secrets management platform helps teams secure, sync, and automate their secrets across environments and infrastructure. Experience enhanced security, agility, and automation with our cloud platform.

  Mar 5, 2026 DevOps links platform security cloud security

• Claude Code Now Has Two Different Security Review Tools

  If you’re using Claude Code, you might have noticed that Anthropic has been quietly building out security tooling. There are now two distinct features worth knowing about. They sound similar but do very different things, so let’s break it down.

  The /security-review Command

  Back in August 2025, Anthropic added a /security-review slash command to Claude Code. This one is focused on reviewing your current changes. Think of it as a security-aware code reviewer for your pull requests. It looks at what you’ve modified and flags potential security issues before you merge.

  It’s useful, but it’s scoped to your diff. It’s not going to crawl through your entire codebase looking for problems that have been sitting there for months.

  The New Repository-Wide Security Scanner

  Near the end of February 2026, Anthropic announced something more ambitious: a web-based tool that scans your entire repository and operates more like a security researcher than a linter. This is the thing that will help you identify and fix security issues across your entire codebase.

  First we need to look at what already exists to understand why it matters.

  SAST tools — Static Application Security Testing. SAST tools analyze your source code without executing it, looking for known vulnerability patterns. They’re great at catching things like SQL injection, hardcoded credentials, or buffer overflows based on pattern matching rules.

  If a vulnerability doesn’t match a known pattern, it slips through. SAST tools also tend to generate a lot of false positives, which means teams start ignoring the results.

  What Anthropic built is different. Instead of pattern matching, it uses Claude to actually reason about your code the way a security researcher would. It can understand context, follow data flows across files, and identify logical vulnerabilities that a rule-based scanner would never catch. Think things like:

  • Authentication bypass through unexpected code paths
  • Authorization logic that works in most cases but fails at edge cases
  • Business logic flaws that technically “work” but create security holes
  • Race conditions that only appear under specific timing

  These are the kinds of issues that usually require a human security expert to find or … real attacker.

  SAST tools aren’t going away, and you should still use them. They’re fast, they catch the common stuff, and they integrate easily into CI/CD pipelines.

  Also the new repository-wide security scanner isn’t out yet, so stick with what you got until it’s ready.

  Mar 4, 2026 DevOps AI Claude-code security

  Enjoyed this?

• You move fast. Cloud development cycles do not.

  Mixing and matching optimization strategies won’t fix your slow development loop. LocalStack streamlines your feedback loop, bringing the cloud directly to your laptop. Same production behavior. Faster feedback. Fully under your control.

  Feb 27, 2026 DevOps Development links localcloud docker

• Stop Using pip. Seriously.

  If you’re writing Python in 2026, I need you to pretend that pip doesn’t exist. Use Poetry or uv instead.

  Hopefully you’ve read my previous post on why testing matters. If you haven’t, go read that first. Back? Hopefully you are convinced.

  If you’re writing Python, you should be writing tests, and you can’t do that properly with pip. It’s an unfortunate but true state of Python right now.

  In order to write tests, you need dependencies, which is how we get to the root of the issue.

  The Lock File Problem

  The closest thing pip has to a lock file is pip freeze > requirements.txt. But it just doesn’t cut the mustard. It’s just a flat list of pinned versions.

  A proper lock file captures the resolution graph, the full picture of how your dependencies relate to each other. It distinguishes between direct dependencies (the packages you asked for) and transitive dependencies (the packages they pulled in). A requirements.txt doesn’t do any of that.

  Ok, so? You might be asking yourself.

  It means that you can’t guarantee that running pip install -r requirements.txt six months or six minutes from now will give you the same copy of all your dependencies.

  It’s not repeatable. It’s not deterministic. It’s not reliable.

  The one constant in Code is that it changes. Without a lock file, you’re rolling the dice every time.

  Everyone Else Figured This Out

  Every other modern language ecosystem “solved” this problem years ago:

  • JavaScript has package-lock.json (npm) and pnpm-lock.yaml(pnpm)
  • Rust has Cargo.lock
  • Go has go.sum
  • Ruby has Gemfile.lock
  • PHP has composer.lock

  Python’s built-in package manager just… doesn’t have this.

  That’s a real problem when you’re trying to build reproducible environments, run tests in CI, or deploy with any confidence that what you tested locally is what’s running in production.

  What to Use Instead

  Both Poetry and uv solve the lock file problem and give you reproducible environments. They’re more alike than different — here’s what they share:

  • Lock files with full dependency resolution graphs
  • Separation of dev and production dependencies
  • Virtual environment management
  • pyproject.toml as the single config file
  • Package building and publishing to PyPI

  Poetry is the more established option. It’s at version 2.3 (released January 2026), supports Python 3.10–3.14, and has been the go-to alternative to pip for years. It’s stable, well-documented, and has a large ecosystem of plugins.

  uv is the newer option from Astral (the team behind Ruff). It’s written in Rust and is 10–100x faster than pip at dependency resolution. It can also manage Python versions directly, similar to mise or pyenv. It’s currently at version 0.10, so it hasn’t hit 1.0 yet, but gaining adoption fast.

  You can’t go wrong with either. Pick one, use it, and stop using pip.

  Feb 23, 2026 DevOps Programming Python

  Enjoyed this?

• Serverless and Edge Computing: A Practical Guide

  Serverless and edge computing have transformed how we deploy and scale web applications. Instead of managing servers, you write functions that automatically scale from zero to millions of users.

  Edge computing takes this further by running code geographically close to users for minimal latency. Let’s break down how these technologies work and when you’d actually want to use them.

  What is Serverless?

  Serverless doesn’t mean “no servers”, it means you don’t manage them. The provider handles infrastructure, scaling, and maintenance. You just write “functions”.

  The functions are stateless, auto-scaling, and you only pay for execution time. So what’s the tradeoff? Well there are several but the first one is Cold starts. The first request after idle time is slower because the container needs to spin up.

  The serverless Platforms as a Service are sticky, preventing you easily moving to another platform.

  They are stateless, meaning each invocation is independent and doesn’t retain any state between invocations.

  In some cases, they don’t run Node, so they behave much differently when building locally, which complicates development and testing.

  Each request is handled by a NEW function and so you can imagine that if you have a site that gets a lot of traffic, and makes a lot of requests, this will lead to expensive hosting bills or you playing the pauper on social media.

  Traditional vs. Serverless vs. Edge

  Think of it this way:

  • Traditional servers are always running, always costing you money, and you handle all the scaling yourself. Great for predictable, high-traffic workloads. Lots of different options for hosting and scaling.
  • Serverless (AWS Lambda, Vercel Functions, GCP Functions) spins up containers on demand and kills them when idle. Auto-scales from zero to infinity. Cold starts around 100-500ms.
  • Edge (Cloudflare Workers, Vercel Edge) uses V8 Isolates instead of containers, running your code in 200+ locations worldwide. Cold starts under 1ms.

  Cost Projections

  Here’s how the costs break down at different scales:

  Requests / Month	~RPS (Avg)	AWS Lambda	Cloudflare Workers	VPS / K8s Cluster	Winner
  1 Million	0.4	$0.00 (Free Tier)	$0.00 (Free Tier)	$40–$60 (Min HA Setup)	Serverless
  10 Million	4.0	~$12	~$5	$40–$100	Serverless
  100 Million	40	~$120	~$35	$80–$150	Tie / Workers
  500 Million	200	~$600	~$155	$150–$300	VPS / Workers
  1 Billion	400	~$1,200+	~$305	$200–$400	VPS / EC2

  The Hub and Spoke Pattern

  Also called the citadel pattern, this is where serverless and traditional infrastructure stop competing and start complementing each other. The idea is simple: keep a central hub (your main application running on containers or a VPS) and offload specific tasks to serverless “spokes” at the edge.

  Your core API, database connections, and stateful logic stay on traditional infrastructure where they belong. But image resizing, auth token validation, A/B testing, geo-routing and rate limiting all move to edge functions that run close to the user.

  When to Use Serverless

  • Unpredictable or spiky traffic — APIs that go from 0 to 10,000 requests in minutes (webhooks, event-driven workflows)
  • Lightweight, stateless tasks — image processing, PDF generation, sending emails, data transformation
  • Low-traffic side projects — anything that sits idle most of the time and you don’t want to pay for an always-on server… and you don’t know how to setup a Coolify server.
  • Edge logic — geolocation routing, header manipulation, request validation before it hits your origin

  When to Use Containers / VPS

  • Sustained high traffic — once you’re consistently above ~100M requests/month, a VPS is cheaper (see the table above)
  • Stateful workloads — WebSocket connections, long-running processes, anything that needs to hold state between requests
  • Database-heavy applications — connection pooling and persistent connections don’t play well with serverless cold starts
  • Complex applications — monoliths or microservices that need shared memory, background workers, or cron jobs

  The Hybrid Approach

  The best architectures often use both. It depends on your specific use case and requirements. It depends on the team, the budget, and the complexity of your application.

  Knowing the tradeoffs is the difference between a seasoned developer and a junior. It’s important that you make the right decisions based off your needs and constraints.

  Good luck and godspeed!

  Feb 21, 2026 DevOps Development Serverless Cloud

  Enjoyed this?

• Switching to mise for Local Dev Tool Management

  I’ve been making some changes to how I configure my local development environment, and I wanted to share what I’ve decided on.

  Let me introduce to you, mise (pronounced “meez”), a tool for managing your programming language versions.

  Why Not Just Use Homebrew?

  Homebrew is great for installing most things, but I don’t like using it for programming language version management. It is too brittle. How many times has brew upgrade decided to switch your Python or Node version on you, breaking projects in the process? Too many, in my experience.

  mise solves this elegantly. It doesn’t replace Homebrew entirely, you’ll still use that for general stuff but for managing your system programming language versions, mise is the perfect tool.

  mise the Great, mise the Mighty

  mise has all the features you’d expect from a version manager, plus some nice extras:

  Shims support: If you want shims in your bash or zsh, mise has you covered. You’ll need to update your RC file to get them working, but once you do, you’re off to the races.

  Per-project configuration: mise can work at the application directory level. You set up a mise.toml file that defines its behavior for that specific project.

  Environment management: You can set up environment variables directly in the toml file, auto-configure your package manager, and even have it auto-create a virtual environment.

  It can also load environment variables from a separate file if you’d rather not put them in the toml (which you probably want if you’re checking the file in).

  It’s not a package manager: This is important. You still need poetry or uv for Python package management. As a reminder: don’t ever use pip. Just don’t.

  A Quick Example

  Here’s what a .mise.toml file looks like for a Python project:

  [tools]
  python = "3.12.1"
  "aqua:astral-sh/uv" = "latest"
  
  [env]
  # uv respects this for venv location
  UV_PROJECT_ENVIRONMENT = ".venv"
  
  _.python.venv = { path = ".venv", create = true }
  

  Pretty clean, right? This tells mise to use Python 3.12.1, install the latest version of uv, and automatically create a virtual environment in .venv.

  Note on Poetry Support

  I had to install python from source using mise to get poetry working. You will want to leave this setting to be true. There is some problem with the precompiled binaries they are using.

  You can install global python packages, like poetry, with the following command:

  mise use --global poetry@latest
  

  Yes, It’s Written in Rust

  The programming veterans among you may have noticed the toml configuration format and thought, “Ah, must be a Rust project.” And you’d be right. mise is written in Rust, which means it’s fast! The project is stable, has a ton of GitHub stars, and is actively maintained.

  Task Runner Built-In

  One feature I wasn’t expecting: mise has a built-in task runner. You can define tasks right in your mise.toml:

  [tasks."venv:info"]
  description = "Show Poetry virtualenv info"
  run = "poetry env info"
  
  [tasks.test]
  description = "Run tests"
  run = "poetry run pytest"
  

  Then run them with mise run test or mise r venv:info.

  If you’ve been putting off setting up Make for a project, this is a compelling alternative. The syntax is cleaner and you get descriptions for free

  I’ll probably keep using Just for more complex build and release workflows, but for simple project tasks, mise handles it nicely. One less tool to install.

  My Experience So Far

  I literally just switched everything over today, and it was a smooth process. No too major so far. I’ll report back if anything breaks, but the migration from my previous setup was straightforward.

  Now, I need to get the other languages I use, like Go, Rust, and PHP setup and moved to mise. Having everything consolidated into one tool is going to be so nice.

  If you’re tired of Homebrew breaking your language versions or juggling multiple version managers for different languages, give mise a try.

  The documentation is solid, and the learning curve is minimal.

  Feb 11, 2026 DevOps Tools Development Python

  Enjoyed this?

• Two Changes in Claude Code That Actually Matter

  As of 2026-01-24, the stable release of Claude Code is 2.1.7, but if you’ve been following the bleeding edge, versions 2.1.15 and 2.1.16 bring some significant changes. Here’s what you need to know.

  The npm Deprecation Notice

  Version 2.1.15 added a deprecation notification for npm installations.

  If you’ve been using Claude Code via npm or homebrew, Anthropic will soon start nudging you toward a new installation method. You’ll want to run claude install or check out the official getting started docs for the recommended approach.

  This isn’t a breaking change yet, but it’s a clear they are moving away from npm for releases going forward.

  Built-in Task Management

  Version 2.1.16 introduces something I’m genuinely excited about: a new task management system with dependency tracking.

  If you’ve been using tools like beads for lightweight issue tracking within your coding sessions, this built-in system offers a similar workflow without the setup.

  You can define tasks, track their status, and—here’s the key part—specify dependencies between them. Task B won’t start until Task A completes.

  This is particularly useful for repositories where you don’t have beads configured or you’re working on something quick where setting up external tooling feels like overkill.

  Your sub-agents can now have proper task management without anything extra.

  Should You Update?

  If you’re on 2.1.7 stable and everything’s working, there’s no rush. But if you’re comfortable with newer releases, the task management in 2.1.16 is worth trying, especially if you work with complex multi-step workflows or use sub-agents frequently.

  The npm deprecation is something to keep on your radar regardless. Plan your migration before it becomes mandatory.

  Jan 25, 2026 DevOps Ai-tools Claude-code

  Enjoyed this?

• 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?