I spend a lot of time in the shell, and I keep running into the same small frustration.

Inside our company repo, I kept seeing the same pattern play out in different ways. In some places, we had custom scripts just to get watch-based recompilation or repeat a file operation. In other places, we deliberately gave up on small bits of automation, like automatic cp, because building a dedicated solution for them felt like overengineering. The result was inconsistent workflows around a problem that should have felt simple.

I wanted the convenience of "watch mode," but I did not want to stop using the commands I already reach for every day. I did not want to wrap everything in a bespoke script. I did not want to move simple workflows into a task runner just to get automatic reruns. I wanted to keep using grep, cp, sed, ls, and cargo test, and I wanted them to run again when their inputs changed.

That is why I built with-watch.

with-watch is a Rust CLI that reruns a delegated command when its inferred or explicit filesystem inputs change. The idea is simple: keep your existing command line, add a small wrapper, and get repeatable reruns without changing how you work. More than anything, I wanted the API to feel user-friendly: no new workflow to memorize, no new config format to invent, and as little change to the original command as possible.

The approach I cared about most was this: in many cases, the user has already expressed the watch requirement in the command they typed. The job is not to ask for a second description of intent. The job is to read the intent that is already there and turn it into a watch plan.

Why I built it

Most watch tools are great when your workflow already fits their model. But a lot of day-to-day shell work is more direct than that.

What pushed me over the edge was seeing how uneven this became in a real codebase. For watch-based recompilation, some parts of our repo had accumulated custom scripts. Elsewhere, we skipped automating a simple copy step because we did not want to build yet another layer around it. Both choices were understandable on their own, but together they pointed to the same missing tool.

Before with-watch, I even used Air for jobs like protobuf recompilation. It worked well, but in a larger project it also meant carrying more project-level configuration than I wanted for something as small as rerunning protoc. That experience made the gap even clearer to me: I did not just want live reload for one category of workflow. I wanted a small, user-friendly, input-driven interface that I could apply to the commands I was already running.

Sometimes I just want to:

• re-run grep hello input.txt whenever the file changes

• re-run cp src.txt dest.txt when the source changes

• re-run a small shell pipeline while I am iterating

• re-run cargo test for a specific crate when files under src/ change

I wanted a tool that respected those workflows instead of asking me to adopt a new one. I wanted something light enough that I would actually use it for the boring cases where writing a custom watcher felt silly, but structured enough that I did not have to keep rebuilding the same tiny automation in different corners of the repo. I wanted a user-friendly API: something you could understand in seconds, not something that required learning a new DSL, config model, or command vocabulary before it became useful.

I also wanted it to be conservative. If a tool can safely infer what to watch, great. If it cannot, it should not guess. It should fail clearly and give me a way to be explicit. That is the design principle I kept coming back to while building with-watch: convenience when the intent is obvious, and an escape hatch when it is not.

What with-watch is

At a high level, with-watch sits in front of a command and watches the files or directories that matter for that command.

That sounds ordinary, but the important part is where the watch plan comes from. I wanted the command itself to be the starting point. If someone types cp src.txt dest.txt, the input already tells us something meaningful about what should be watched and what should be treated as output. If someone types grep hello input.txt, the input already tells us where the read dependency is. The watch requirement is often already embedded in the command; with-watch is built around extracting that instead of demanding a separate layer of configuration.

It supports three command modes:

with-watch [--no-hash] <utility> [args...]
with-watch [--no-hash] --shell '<expr>'
with-watch exec [--no-hash] --input <glob>... -- <command> [args...]

The first mode is the one I wanted most: wrap a familiar utility and let with-watch infer the inputs.

The second mode is for simple shell command lines on Unix-like platforms that need operators like &&, ||, or |.

The third mode is the explicit escape hatch. If inference would be ambiguous, or if the delegated command does not have stable filesystem inputs on its own, exec --input lets me say exactly what should trigger a rerun.

How it works in practice

Here are a few real examples that match the current CLI and docs:

with-watch grep hello input.txt
with-watch cp src.txt dest.txt
with-watch ls -l
with-watch --shell 'grep hello src.txt | wc -l'
with-watch sed -i.bak -e 's/old/new/' config.txt
with-watch exec --input 'src/**/*.rs' -- cargo test -p with-watch

That mix is what makes the tool feel useful to me.

For straightforward commands, I can stay in passthrough mode and let with-watch do the boring part. For a quick one-liner pipeline, I can use --shell. For something like cargo test, where I want to define the watch set myself, I can use exec --input and keep the original command untouched.

That last detail matters to me: with-watch reruns the delegated command exactly as provided. It does not inject changed file paths into argv. It does not rewrite the command line behind the scenes. It just decides when to run the command again.

The design choices I cared about most

1. Treat the user's command as the primary source of truth

This is the core idea behind the tool.

I did not want watch behavior to start from a separate config file, a second DSL, or an extra description of what the user meant. In many cases, the requirement is already present in the input. The command, its operands, and even parts of shell syntax already contain the information needed to build a useful watch plan.

That is why passthrough mode is the default shape of the tool. It is also why exec --input is an escape hatch rather than the main interface. I wanted explicit inputs to be available when needed, but I wanted the primary experience to begin with the command the user was already going to run.

2. Run once immediately

After input inference, watcher setup, and baseline capture succeed, with-watch performs one initial run right away.

That sounds small, but it makes the tool feel natural. I do not want to start a watch command and then wait for the first file change just to confirm that everything is wired correctly. I want the command to run once immediately, then keep running when inputs change later.

3. Prefer real content changes by default

By default, with-watch compares content hashes when it decides whether to rerun.

This is not just a theoretical preference for me. It comes from real workflow friction. In practice, I kept running into cases where a rerun happened because something in the pipeline wrote to the filesystem again, even though the actual content had not meaningfully changed. When that happens, I usually do not want the rest of the pipeline to keep flowing. I want it to stop as early as possible, or at least in the middle, instead of paying for more downstream work that does not represent a real change.

I recently made a similar optimization in my day job: if the content-based result had not changed, the step would skip the filesystem write entirely. That experience reinforced the same instinct behind with-watch: treat real content changes as the thing that matters most, and avoid turning incidental rewrites into more work.

If I want metadata-only comparison instead, I can opt into it with:

with-watch --no-hash grep hello input.txt

That keeps the default behavior more intentional while still leaving room for the lighter-weight mode when it is the right tradeoff.

4. Fail safely when inference is not trustworthy

One of the easiest ways to make a watch tool feel magical is also one of the easiest ways to make it feel wrong: infer too much.

I did not want with-watch to pretend it knows what to watch when it really does not. If it cannot infer safe filesystem inputs from the delegated command, it fails with guidance instead of guessing. The answer in those cases is to use exec --input and make the watch set explicit.

That tradeoff is deliberate. I would rather make the explicit path easy than make the implicit path unpredictable.

5. Do not loop forever on self-mutating commands

Commands like this are common:

with-watch sed -i.bak -e 's/old/new/' config.txt

This kind of command mutates a watched input. A naive watcher can easily end up retriggering itself forever.

with-watch avoids that by refreshing its baseline after self-mutating commands run, so the command does not keep firing just because of its own write. If a real external change happens later, it can rerun again.

6. Keep shell support useful, but intentionally narrow

--shell is there for command-line expressions on Unix-like platforms, not full shell scripting. Today it is meant for cases that need &&, ||, or |, plus ordinary redirects handled within the documented boundaries.

That was another intentional choice. I wanted the feature to be helpful without quietly expanding into a much larger, fuzzier surface area.

Installing with-watch

Right now, the documented install paths are:

cargo install with-watch
brew install delinoio/tap/with-watch

If you are already comfortable in Rust or Homebrew-based workflows, getting started is very lightweight.

Why I think this shape matters

I did not build with-watch to replace every task runner or watcher. I built it for a narrower but very common feeling: "I already have the command I want. I just want it to run again when the right files change."

That is why the tool is centered on delegated commands instead of a new config format.

That is why the API tries to stay close to the command you were already going to run.

That is why I keep coming back to the same idea: the user's input often already contains the watch requirement.

That is why safe inference matters.

That is why exec --input exists.

That is why the delegated command stays unchanged, with only the minimum extra syntax needed when you want to be explicit.

And that is why the tool tries to help without pretending it knows more than it does.

Try it

If that workflow sounds familiar, give with-watch a try.

Start with something small like with-watch grep hello input.txt, then move on to a shell expression or an explicit cargo test loop with exec --input. And if you want to see the full recognized command inventory and the exact current CLI shape, check the project documentation or run:

with-watch --help

That help output is the best place to see what the tool currently recognizes and where it expects you to be explicit.

1) cargo-mono

cargo-mono is a tool built to make swc release operations safer. It is implemented as a Rust cargo external subcommand that automates changed, bump, and publish workflows, and it has been used in the swc deployment pipeline since March 2, 2026. Current status: Production use.

2) nodeup

nodeup brings the rustup usage model to Node.js environments as a Rust CLI. From install/remove flows to directory overrides and node/npm/npx dispatching, it is designed to feel familiar to people who already use rustup. Current status: Testing is complete, and release preparation is in progress.

3) derun

derun is a Go-based CLI built to make AI coding agents much easier to use. Humans run commands normally with derun run, while agents keep context through the MCP stdio server (derun mcp) by reading session output and progress logs. Current status: In testing while also preparing for release.

4) ttl

ttl is still in a preparatory phase, but the direction is clear. It aims to express a turbo-tasks-style incremental execution model in a TTL language, then compile it with a Go-based ttlc compiler and back it with SQLite caching. Current status: Active development.

5) devkit

devkit is an internal web platform shell built with Next.js 16 and TypeScript. It is designed to let us attach mini apps quickly under the /apps/<id> convention, and commit-tracker, remote-file-picker, and thenv are already running in practice. Current status: Development is intentionally moving slowly and carefully because we are still getting used to live broadcasting workflows and want to avoid accidental secret leaks.

6) devkit-commit-tracker

devkit-commit-tracker is a tracking tool built for swc use cases. With a Next.js mini app, Go Connect RPC server/collector, and PostgreSQL, it collects and visualizes commit/PR-level metrics such as final binary size so regressions can be caught early.

7) devkit-remote-file-picker

devkit-remote-file-picker is a signed-URL upload mini app built with Next.js and TypeScript. It takes local file or mobile camera input, uploads directly to S3/GCS, and safely returns results back to the host app. Conceptually, it is inspired by Android's Intent model and is similar to launching an Activity to receive a result.

8) thenv

thenv is a secure team system for sharing .env and .dev.vars, composed of a Go CLI, a Go Connect RPC server, and a Next.js web console. It is operated around RBAC, versioning, active pointers, audit logs, and server-side encryption. Current status: Development is intentionally moving slowly and carefully because we are still getting used to live broadcasting workflows and want to avoid accidental secret leaks.

9) devmon

devmon is a local automation tool that combines a Go daemon/CLI, a macOS menu bar app, and LaunchAgent integration. Menu bar control is a key part of the workflow, and it is actively used in day-to-day work and even during streaming for tasks like keeping local main synced with remote main or running periodic cargo clean jobs. Current status: Production use.

10) mpapp

mpapp is a mobile app built with React Native and Expo. Its goal is to let you control an iPhone mounted on a hanger from another smartphone in your hand, without having to raise your hand to the mounted phone itself. Current status: Development is delayed because this workflow requires Android hardware for practical validation.

11) serde-feather

serde-feather is a derive-macro-focused project for Rust. It is split across a Rust proc-macro crate and a runtime support crate, centered on FeatherSerialize and FeatherDeserialize while keeping binary-size overhead low. Current status: Active development.

12) dexdex

dexdex is a desktop app that lightly refines the Codex desktop app workflow. With Rust servers and a Tauri client (React/TypeScript + Rust), it keeps familiar UX while making session flow and PR response loops more seamless. Current status: Active development.

Wrap-up

The shared theme across this repository is straightforward: define contracts first, keep execution observable, and shape automation for real operations. Even when a project starts from learning, the target is still practical tools that people actually use. For the full contract details, oss.delino.io is the fastest way to browse them.

The Challenge

The rspack team had a specific migration task to complete across their codebase. It was the kind of systematic change that seems perfect for AI automation: well-defined, repetitive, but requiring attention to detail and context awareness.

Initial Attempts

GitHub Copilot's Result

The team first tried GitHub Copilot, which generated a pull request (#11966). Unfortunately, the results were unsatisfactory—the PR quality didn't meet the team's standards and wasn't viable for merging.

Testing DevBird (formerly AutoDev)

Note: At this time, DevBird was still named AutoDev before our recent rebrand.

Interested in evaluating alternative AI coding solutions, the rspack team reached out to test DevBird. I ran DevBird on their behalf by:

1. Forking the repository to my personal account

2. Configuring DevBird for the task

3. Letting DevBird process the migration

The initial result: PR #2 on the fork

Note: I enabled CompositeTask feature for DevBird on this task and it produced a single-node task graph. If a task is complex enough,DevBird will create multiple PRs. Still, a single-node task graph generates extremely good prompt for the actual run, and it’s the key.

The DevBird Advantage: Autonomous Error Recovery

Here's where DevBird's architecture proved its value. Like Codex Cloud Web (which was also tested), DevBird's initial code didn't pass CI on the first attempt. However, DevBird's automatic PR fix feature detected the CI failure and autonomously corrected the issues.

After receiving confirmation from the Rspack team member that the PR was "perfect," we submitted it to the main repository: PR #11978

Codex Cloud Web Comparison

Codex Cloud Web was also tested on the same task. While it generated initial code, it encountered CI failures. The team member attempted to recover by commenting @codex Fix CI, which triggered Codex to work on the problem for over 40 minutes. Unfortunately, the CI still failed after this extended attempt.

At this point, the team member concluded that further attempts weren't worthwhile and merged the DevBird-generated PR instead.

Key Takeaways

1. Autonomous Recovery Matters

The ability to self-correct isn't just a nice-to-have feature—it's essential for production use. Both DevBird and Codex failed CI initially, but DevBird's automatic fix capability meant it could recover without human intervention.

2. Time to Resolution

• DevBird: Autonomous fix, ready for merge

• Codex Cloud Web: 40+ minutes of attempted fixes, still failed

• GitHub Copilot: Initial PR not viable

The time difference stems from the design differences between these tools. With DevBird, you can use your existing GitHub Actions code to configure the development environment for AI agents, significantly reducing AI costs and the time required to set up the runtime environment.

3. Production-Ready Results

The Rspack team's feedback was clear: the DevBird PR was "perfect" and ready for merge. This real-world validation from an active open-source project demonstrates DevBird's capability to handle actual development tasks.

Conclusion

This case study illustrates a crucial distinction in AI-powered development tools: generating code is only half the battle. The ability to iterate, test, and fix issues autonomously is what separates tools that assist developers from tools that can actually complete tasks end-to-end.

DevBird's architecture—with its built-in PR monitoring and automatic fix capabilities—proved essential in delivering production-ready results for the Rspack team. While multiple AI coding tools attempted the same task, only DevBird successfully delivered a mergeable solution.

Interested in seeing how DevBird can help your team? Get started today to learn more about autonomous error recovery and other features.

Since launching AutoDev, we've encountered an unexpected challenge: name overlap with Microsoft's AutoDev has made it difficult for users to find us through search engines. This SEO conflict has created unnecessary friction for our community as they attempt to discover and access our service.

After careful consideration, we've decided to rebrand to ensure our users can easily find and connect with us.

Why DevBird?

Our service acts as a bridge between AI development tools and developers—much like a messenger bird delivering essential information. The name DevBird perfectly captures this essence:

• Dev represents our core focus on developers and development tools

• Bird symbolizes our role as a messenger, connecting you with the AI tools you need

Just as birds have served as messengers throughout history, DevBird delivers the power of AI development tools directly to you.

What's Changing (and What's Not)

What's changing:

• Our name: AutoDev → DevBird

• Our branding and visual identity (rolling out soon)

What's staying the same:

• All features and functionality you rely on

• Your account and data

• Our commitment to connecting developers with AI tools

What's Next?

We'll be rolling out our complete rebranding in the coming weeks. You'll see our new logo, updated website, and fresh visual identity—but the powerful service you know and love remains unchanged.

Thank you for being part of our journey. We're excited to soar forward as DevBird!

Have questions about the rebrand? Feel free to reach out to our team.

The Problem We Encountered

Unfortunately, we ran into a significant challenge that made this model unsustainable. The minimum payment processing fees were eating into our margins so severely that we were operating at a loss. Even small transactions meant we were paying disproportionately high fees to payment processors, making it financially unviable to continue offering this option.

Moving Forward

After careful consideration, we've made the difficult decision to discontinue the pay-as-you-go plan. While we loved the concept of usage-based pricing, the economics simply don't work with current payment processing infrastructure.

We're exploring alternative pricing models that can offer similar flexibility while being sustainable for our business. We appreciate your understanding as we make these changes.

What is the proper way to do AI-based coding?

Three core principles:

1. Breaking work into appropriate units - Divide complex tasks into manageable, focused pieces

2. Iterative verification and feedback loops - Continuously validate work across multiple sessions

3. Automated regression prevention - Use CI and automated tests to catch issues early

AutoDev takes vibe coding to the next level with powerful automation and team collaboration features.

Why AutoDev?

Parallel Execution

Unlike traditional AI coding assistants that work sequentially, AutoDev can execute multiple independent tasks simultaneously. When you break down a complex feature into smaller tasks, AutoDev automatically identifies which tasks can run in parallel, dramatically reducing development time.

VM-Based Security - You Have Control

Your code runs in your own GitHub Actions runners, not on our servers. You maintain complete control over:

• Your code and intellectual property

• Compute resources and costs

• Development environment configuration

Easy Customization

Customize your development environment using GitHub Actions workflows. Simply modify your .github/workflows/autodev.yml file to:

• Install custom tools and dependencies

• Configure linters and formatters

• Set up your preferred testing frameworks

• Add security scanning and compliance checks

Transparent, Fair Pricing

$0.01/workflow execution with a minimum price of $10 per month - that's it for the platform fee. No per-user charges.

• Team accounts: $10/month (regardless of team size, and with per-usage cost)

• Personal accounts: $10/month (with per-usage cost)

• AI costs (Claude, OpenAI, etc.): Pay only for what you use. You can even use your fixed-cost subscription.

• GitHub Runner costs: Managed through your GitHub account

This means a team of 10 developers pays the same $10/month as a solo developer - we believe in fair, scalable pricing.

How It Works

Simple Tasks - Quick Automation

1. Select your repository and describe what you want to build

2. AutoDev triggers your workflow using GitHub Actions

3. AI agents create pull requests with the implementation

4. Automatic code review handling - AutoDev responds to feedback and fixes CI failures

5. Merge the PR when everything is ready

Composite Tasks - AI-Powered Planning

For complex features that require multiple coordinated steps, AutoDev can automatically break them down:

1. Describe your complex task in natural language

2. AI creates a task graph - A visual breakdown of all necessary steps and their dependencies

3. Review and approve the plan (or let auto-approval handle it)

4. Parallel execution - Independent tasks run simultaneously

5. Automatic progression - As tasks complete, dependent tasks start automatically

Example: Multi-Page Translation Task

Improve the translation quality for each page in AutoDev.

Create one task per page. Each task should handle a single page. 
If a page's translation has no issues, the task should not create a PR.

Each task prompt must include instructions to manually review and fix 
translations page by page - DO NOT use automated commands like 'pnpm translate'. 
Each prompt must include the complete list of all supported languages.

Example: Security Audit Task

Review all RPC methods in AutoDev and fix any security issues.

Create one task per RPC method. Each task should handle a single RPC method. 
Each task prompt should fix all security issues in the RPC, but should NOT 
create a PR if the RPC already has sufficient test coverage.

Pro Tips for Power Users

Intentional Task Separation

You can strategically control how work is divided through your prompts. For example, when writing tests for API endpoints:

❌ Don't do this:

Write tests for all API endpoints

✅ Do this instead:

Write tests for all API endpoints. Create one task per endpoint. 
Each task should handle testing for a single endpoint.

This approach prevents the common issue where AI coding agents get confused mid-task and start behaving erratically - a problem anyone who's used Claude Code or similar tools for test writing has experienced.

Auto-Approval for Trusted Workflows

Enable auto-approval on composite tasks to let AutoDev automatically execute tasks as soon as their dependencies are met. Perfect for:

• Well-defined, repetitive tasks

• Tasks with strong CI coverage

• Tasks where you trust the AI agent's judgment

You can toggle auto-approval on and off at any time during task execution.

Supported AI Agents

AutoDev currently supports:

• Claude Code

• Codex CLI

Coming Soon

• Opencode CLI

• Gemini CLI

• Crush CLI

• GitHub Copilot CLI

Get Started Today

• Documentation at https://docs.delino.io/autodev

1. Install the AutoDev GitHub App on your repositories

2. Create your first task - Start with something simple

3. Watch the magic happen - AutoDev handles everything automatically

Visit AutoDev to start your free trial.

Join the Vibe Coding Revolution

AutoDev brings professional, scalable AI-assisted development to teams of all sizes. Whether you're a solo developer or managing a large engineering team, AutoDev adapts to your workflow while keeping you in control.

Try AutoDev today and experience the future of automated development.