Im Using AI Development Tools to Boost My Workflow

Hey everyone, Kai Nakamura here, dropping in from clawdev.net! Today, I want to talk about something that’s been on my mind a lot lately, especially as the AI development scene keeps moving at lightspeed. We’re all building, pushing, experimenting, and sometimes… we hit a wall. Or rather, we find ourselves doing the same thing over and over, or struggling with a piece of code that *feels* like it should be simpler.

And that’s where my topic for today comes in: **The Underappreciated Art of “Re-Open Sourcing” Your Own Private AI Projects.**

Now, before you click away thinking this is just another “contribute to open source” post – which, don’t get me wrong, is incredibly important – hear me out. I’m talking about taking code that *you* wrote, for *your* internal project, and strategically making parts of it public. Not the whole secret sauce, not your core IP, but those utility functions, those custom data loaders, those specific training loop abstractions that you’ve poured hours into perfecting. The stuff that, frankly, you probably shouldn’t have to build from scratch every time, and neither should anyone else.

Why Bother? My Own Wake-Up Call

A few months ago, I was knee-deep in a client project. We were building a pretty sophisticated conversational AI for a niche industry, and a big part of it involved dynamic prompt generation and validation. Think complex templating, schema enforcement, and then a whole layer of historical context management. I built this really neat, somewhat opinionated, but ultimately very effective `PromptBuilder` class. It handled everything from token limits to injecting specific metadata based on user roles.

I was proud of it. It worked. And then, a month later, I started a new internal project here at clawdev.net, something completely unrelated to the client, but it also needed a solid way to build and manage prompts. My immediate thought? “Copy-paste, baby!”

I copied the `PromptBuilder` over. Made a few tweaks. And then, it hit me: I just duplicated about 300 lines of code, and now I had two slightly different versions to maintain. What if I found a bug in one? What if I wanted to add a feature? I’d have to do it twice. This wasn’t scalable. This wasn’t smart.

This wasn’t the first time this had happened, either. I’ve got a graveyard of custom `DataLoader` implementations, a whole directory of `ExperimentTracker` classes, and don’t even get me started on the various ways I’ve handled API key rotation across different projects.

That’s when I decided to start “re-open sourcing” my own code. Not to a big public repo initially, but to a separate, internal GitLab group I called `clawdev-utils`. The idea was simple: if I build something useful that isn’t core IP, and it could be used in multiple projects, it goes into `clawdev-utils`. If it’s generic enough, and I don’t mind sharing it with the world, it goes onto GitHub under an MIT license.

The Hidden Benefits: More Than Just Code Reuse

You might think, “Okay, Kai, code reuse, got it. But is it really worth the effort of setting up separate repos, writing docs, and thinking about licensing for my own internal utilities?” And my answer is a resounding YES. It’s about more than just not copying files.

1. Enforced Modularity and Better Design

When you start thinking about extracting a piece of code to be “re-open sourced,” even if it’s just for your own organization, you inherently start designing it better. You think about its dependencies. You think about its interface. You think about how someone *else* (or Future You) might use it without knowing all the internal quirks of the original project.

My `PromptBuilder` example is perfect here. When it was embedded in the client project, it was tightly coupled to their specific logging and error handling. When I extracted it, I had to make those parts pluggable. I swapped out direct log calls for an injectable logger interface. I made error types more generic. The result? A much cleaner, more flexible piece of code that was genuinely more useful.

2. Easier Onboarding and Knowledge Transfer

Imagine a new developer joins your team. Instead of having them dig through the monolithic codebase of your primary AI application to understand how you handle, say, distributed training checkpoints, you can point them to a well-documented, smaller repository called `clawdev-checkpoint-manager`. It’s a focused piece of functionality they can understand in isolation.

This also applies to your own future self! How many times have you looked at your old code and thought, “What was I thinking here?” Separating these utilities forces you to write better comments, more thorough docstrings, and clearer examples, because you’re mentally preparing it for a wider audience, even if that audience is just you in six months.

3. The Path to Genuine Open Source is Smoother

Let’s be real: most of us want to contribute to the open-source community, but the idea of taking a huge chunk of code and making it public feels daunting. By “re-open sourcing” internally first, you’re doing all the hard work of decoupling, documenting, and testing in smaller, more manageable chunks.

When you have a well-isolated utility that’s proven its worth across multiple internal projects, the leap to putting it on GitHub under an MIT license is much smaller. You’ve already got the tests, the docs, and a clean API. You’re not starting from scratch.

For example, that `PromptBuilder`? After a few iterations in `clawdev-utils`, I realized it was generic enough and didn’t contain any client-specific logic. I took the plunge, put it on GitHub as `promptforge`, and now it’s out there. It feels good to give back, and it was only possible because I’d already done the internal groundwork.

How to “Re-Open Source” Your Own Code: Practical Steps

This isn’t about throwing everything over the fence. It’s a strategic process. Here’s how I approach it:

Step 1: Identify the Candidates

Look for code that fits these criteria:

• **Repeated Logic:** Do you find yourself copying and pasting the same function or class between projects?
• **Generic Utility:** Does it solve a common problem that isn’t unique to your core product? (e.g., data loading, API wrappers, utility decorators, specific pre-processing steps, configuration management).
• **Low Coupling:** Can it be easily extracted without dragging along half of your main application?
• **Stable (Mostly):** It should be relatively stable and functional, not something you’re actively experimenting with daily for core features.

Think about things like custom `Dataset` or `DataLoader` classes for specific data formats, a helper for managing distributed training state, a specialized text cleaning pipeline, or a wrapper around a tricky external API.

Step 2: Extract and Isolate

This is where the real work happens. Create a new repository (either internal or public from the start). Move the code there. Then, systematically remove all project-specific dependencies. Replace them with:

• **Abstract Interfaces:** If your utility needs a logger, don’t hardcode `logging.getLogger(‘my_project’)`. Expect a `logger` object to be passed in, or use a simple `print` fallback.
• **Configuration Parameters:** If it needs API keys or file paths, make them configurable arguments or environment variables, not hardcoded values.
• **Generic Data Structures:** Instead of relying on a custom `MyClientData` object, work with standard Python types (dicts, lists, dataclasses).

Here’s a simple example. Let’s say you have a function that loads a specific type of JSON configuration for your AI models:

# Original (tightly coupled)
import os
import json

def load_model_config_original(model_name: str) -> dict:
 config_path = os.path.join(os.getenv("MODEL_CONFIG_DIR"), f"{model_name}_config.json")
 with open(config_path, 'r') as f:
 config = json.load(f)
 # Add project-specific defaults
 config.setdefault("learning_rate", 0.001)
 return config

# Re-Open Sourced (decoupled)
import json
from typing import Optional

def load_json_config(file_path: str, default_values: Optional[dict] = None) -> dict:
 """
 Loads a JSON configuration file and merges with optional default values.
 """
 try:
 with open(file_path, 'r') as f:
 config = json.load(f)
 except FileNotFoundError:
 print(f"Warning: Configuration file not found at {file_path}. Using defaults.")
 config = {}
 
 if default_values:
 # Merge defaults, prioritizing loaded config values
 merged_config = {**default_values, **config}
 return merged_config
 return config

# Usage in your project:
# from clawdev_utils.config_loaders import load_json_config
#
# my_model_defaults = {"learning_rate": 0.001, "batch_size": 32}
# model_config = load_json_config(
# os.path.join(os.getenv("MODEL_CONFIG_DIR"), "my_special_model_config.json"),
# default_values=my_model_defaults
# )

The `load_json_config` function is now entirely generic. It doesn’t care about `model_name` or `MODEL_CONFIG_DIR`. It just loads a JSON file and handles defaults. This is a prime candidate for re-open sourcing.

Step 3: Document, Test, and License

This is crucial. No one, not even Future You, wants to use an undocumented, untested utility. Treat it like a proper open-source project, even if it’s just for internal consumption.

• **Documentation:** Write clear docstrings. Add a `README.md` with installation instructions (if applicable), usage examples, and any caveats.
• **Tests:** Write unit tests for your extracted components. This ensures they work as expected in isolation and helps prevent regressions.
• **Licensing (for public repos):** If you intend for it to be public, choose a permissive license like MIT or Apache 2.0. This makes it easy for others to use your code without legal headaches.

For instance, for my `promptforge` library, I made sure every function had detailed docstrings and I included a `docs/` folder with more extensive examples of how to integrate it with different LLM APIs.

Step 4: Integrate Back (and Maintain)

Once your utility is extracted, tested, and documented, update your original project (and any others) to *use* the new, externalized version. Install it as a dependency (e.g., via `pip install git+https://github.com/your/repo.git` for private repos, or from PyPI for public ones).

Remember, this is an ongoing process. When you discover a bug or need a new feature in your utility, fix it in the utility’s repository, not in the consuming project. Then, update the version in your projects.

Actionable Takeaways for Your Next AI Project

Alright, so what does this all mean for you, the busy AI developer?

1. **Start Small:** Don’t try to refactor your entire codebase overnight. Pick one small, repeatable utility function or class that you know you’ve copied before.
2. **Think Generic:** When you’re writing new code, especially for utility functions, pause and ask yourself: “Could this be useful in another project? How can I make it less specific to *this* project?”
3. **Create an Internal “Utils” Repo:** Even if you’re not ready for public open source, set up a shared internal repository for your team’s common utilities. This is a fantastic first step.
4. **Prioritize Documentation and Testing for Utilities:** Treat these extracted components like mini-products. Good docs and tests reduce friction for everyone, including yourself.
5. **Embrace the “Public-First” Mindset (Where Appropriate):** If a utility has no competitive advantage and solves a common problem, consider open-sourcing it directly. The community feedback and contributions can be incredibly valuable.

Re-open sourcing your own code isn’t just about being a good citizen; it’s about making *your own development workflow* more efficient, your codebases cleaner, and your future self much happier. It’s a habit that pays dividends in maintainability, scalability, and even your peace of mind.

Give it a shot on your next project, and let me know how it goes in the comments below! What are your favorite utilities you’ve extracted?

🕒 Last updated: March 26, 2026  ·  Originally published: March 14, 2026