benn's blog

How many of your agents work 24/7?

Sat, 16 May 2026 00:00:00 +0000

This started as an internal talk I gave recently. Ideas get feedback more easily once they’re written down, so I’m putting it here too.

We lean on agents heavily, but only as personal sidekicks

We already use AI agents a ton. So why doesn’t the team feel more agent-native?

Almost everyone here is a heavy user of one agent or another, things like Claude Code, Codex, OpenClaw, Manus. Many people run several at once. We depend on them all day, and some daily tasks just don’t get done without them.

But we’re still treating an agent as a productivity tool. It’s a piece of software that runs on each person’s own laptop, and its experience, skills, and memory stay in that one local environment. This causes problems we mostly don’t notice. I hear conversations like this all the time:

“I taught my agent how to do this. I’ll send you the skill, install it on yours too.”

“My agent knows this part best. Don’t let yours touch it or they’ll conflict.”

I think there’s a key problem here. Most of the agents in our work are still somebody’s personal sidekick.

Agents have made each of us much more capable. But look at the team as a whole and we’re still leaving a lot on the table.

Agents should be first-class members of the team

What I’d rather see is agents becoming first-class members of the team.

By first-class I don’t mean it acts more human. I mean it stops being one person’s tool. It should be able to work with anyone on the team on equal footing, and its skills, memory, and experience should serve the whole team.

The more it handles, the more it understands our business, our systems, and the way we actually get things done. At some point it’s not just running tasks anymore. It knows how we work, the way an experienced coworker does. It should be one of us.

It doesn’t belong to one person
It can work with anyone on the team
Its skills and memory serve the team as a whole
It understands everything it has worked on better than anyone

We’re already seeing early signs of this.

We have a group chat bot with access to our data platforms. When people want to look at business numbers, the first instinct is no longer to click around a dashboard. They just ask it.
We have another bot we forward production bugs to. It tries to reproduce and debug them, files an issue, and sometimes pushes a human engineer to deal with it.
And so on.

These are useful, but I don’t think they go far enough.

Why does a human still need to collect user feedback by hand and forward it to a bot? Why can’t the bot listen to what users are saying and spot the common problems on its own?
Why does a human have to notice a traffic spike first, and only then ask a bot to analyze where it came from? Why isn’t there an agent watching those metrics and starting the analysis the moment something looks off?
When the service gets shaky because of a DB performance issue, why does finding the bottleneck still depend on a human stepping in? Why can’t an agent watch performance over time and catch the risk early when usage surges?
And so on.

None of this is out of reach today. So what’s stopping us from thinking and building in this direction?

Why token usage is a bad metric

A lot of people now measure AI adoption by token usage. How many tokens a team burns per month, how many per person per day, how fast model calls are growing.

That metric isn’t meaningless, but what it really measures is how hard you lean on the tool.

It’s like someone saying they’re great at driving because they burn through a tank of gas every two days.

Token usage is closer to tool-usage intensity than to how agent-native a team is.

If the question is how agent-native a team really is, token usage isn’t a good enough way to answer it.

A harder metric: how many agents work around the clock

I think a more demanding metric is how many agents we have that work around the clock without stopping.

By the strictest version of this:

Not on standby, but always working
Either doing work or watching for work
Burning tokens almost continuously

So 24/7 here doesn’t mean idle standby, and it doesn’t mean replying only when a message comes in. To be stricter, it should either be doing work or watching for work. Ideally it burns tokens around the clock without a real break.

This shift in framing matters. We stop talking about how hard one machine is being used, and start talking about the size and output of the whole factory.

One do-everything agent probably isn’t enough

The natural question: do we just need one super agent? Give it every permission, plug in every tool, load in every memory, and let it own everything.

At least today, I don’t think one do-everything agent is enough. In our own work we’ve already run into some real problems.

1. Tool permission isolation

The first one is permission isolation, and this is the one I worry about most. An agent that does a lot of work needs a lot of tools, but different work has different permission boundaries. For example, I don’t want a single agent that talks to users and also reaches straight into production and the business code.

The right approach is least privilege. For each kind of work, give only the tools that work needs. But if one agent has to handle several kinds of work at once, that isolation gets hard. It can become a security risk because its permissions are too broad, or it can’t finish the job because they’re too narrow.

2. Memory crosstalk

Next is memory crosstalk. Experience and preferences from different workflows get mixed together, and sometimes that interferes with judgment. An agent works on ops data one minute and edits a test workflow the next, and over time its memory gets tangled. Mixed memory can lead to odd behavior in some situations. It might carry copy-polishing habits from marketing into ops data analysis, which would be bad.

3. Context switching is painful

There’s also the context-switching problem. This hits humans and agents alike. If we talk to an agent about tasks with very different backgrounds all in the same place, switching context gets painful for both sides.

4. Access management

Access management gets messy too. We want to connect an agent to many places without exposing too much risk at once. Different people, projects, and systems have different trust boundaries for an agent. One all-powerful agent struggles to satisfy all of them at the same time.

So I lean toward thinking we’ll end up with a lot of fairly independent agents. Each one has its own long-term memory, tool permissions, and working habits. Each one acts as its own contributor on the team.

Will we figure out agent-to-agent collaboration?

Once you accept that we’ll have many agents, the next question is how they should work together.

I think this part gets interesting, because agents may be better at collaborating than we expect.

A lot of our daily work is just moving information between people. Human collaboration has a big limit: our sync bandwidth is terribly low. Meetings, docs, messages. All of that IO is slow, and context drops easily along the way. You’re probably reading this at four or five bytes a second.

Sync bandwidth between agents is much higher. It comes down to network speed and inference speed. The full background of a work module might take a human an hour to explain and still not land. For an agent it’s a context handoff of a few tens of thousands of tokens.

Push it further. Since each agent has its own memory, they can hand off a piece of their “brain” too. If people could do that with each other, how much misunderstanding and conflict would just go away?

In the ideal case, collaboration between humans and agents, and between agents, looks like a web. Each agent can find the right partner and move work forward fast.

For example, an ops agent notices a funnel metric looks off, realizes the tracking is thin, and syncs the background to a QA agent. The QA agent, based on its own grasp of the test process, decides which scenarios to add, then hands the task to a coding agent. The coding agent writes the code, the QA agent verifies it, and a human reviews it at the end.

Don’t divide work among agents too early

The moment you talk about multiple agents, it’s tempting to copy how human orgs split work: role, scope, responsibility.

A frontend agent, a backend agent, a data agent, a test agent. It sounds reasonable, but I’m very cautious about it.

Today’s LLM isn’t a specialist in the old sense anymore. It’s a generalist that can write code, read docs, dig through data, even make a product call. But if you tell it “you’re the frontend agent” up front, it may really pull all its attention into the frontend and lose the bigger picture.

It can clearly see problems across the product, the backend, and the release process. But once its identity is fixed, it decides those aren’t its job.

This also creates a sense of boundary. My part is done, the rest isn’t mine to worry about.

Agents are already good at wrapping up early. If we draw narrow lines around them on top of that, it gets even easier for them to finish inside a tiny scope and stop.

For something this capable and this general, the better approach might be to hand it a mission and let it run.

So the word I keep coming back to is mission.

Maybe the mistake is pinning a long-running agent to a role at all. Give it a mission instead.

From /goal to /mission

One of the more important steps in AI over the last few weeks, I think, is Codex building in a /goal feature. It lets an agent stop waiting for a human to step in and guide it. It can plan and execute on its own, and keep pushing until the goal is met.

The mechanism behind /goal is simple. When you set a goal, the agent gets a thread-level state that records how the goal is going, the check conditions, and the cost spent so far. After each loop, the agent checks that state to see if the goal is met. If not, it runs the next step, until it’s done or gives up after exceeding the cost.

This is a real step forward, because it lets an agent run fully on its own for an hour or two. But I think it should go further and be more aggressive.

For an always-on agent, the hardest thing is figuring out how to keep feeding it work. In the ideal case it’s fully self-driven and finds its own work.

So I’ve been imagining a /mission concept. It’s quite different from /goal. It’s a lifetime-level state for the agent. While the agent does its daily work, every night when it summarizes and organizes memory, it should rethink its mission, adjust how it works over the next few days, or set a new task plan.

This might be where an always-on agent gets genuinely valuable.

A small starting point

So I’ve come to think “the number of agents working around the clock” is a harder and more useful metric than token usage.

It forces a few things. We’d have to hand real work to agents that have their own agency, not keep them as personal tools. We’d have to get serious about how agents actually collaborate, not just pinging each other but syncing context and passing judgment along. And mission-driven agents stop being a side experiment. A long-running agent that just finishes a prompt isn’t the point. The point is one that keeps adjusting itself and keeps moving, around a mission.

Why OpenClaw's browser keeps getting CAPTCHAs

Wed, 18 Mar 2026 00:00:00 +0000

I’ve been running OpenClaw as my daily AI agent for a while. The browser ended up being the thing I had to fix.

For weeks, my OpenClaw kept giving me mediocre results on deep research tasks and I couldn’t figure out why. Everything looked fine until I started checking the sources. Turns out it was getting blocked by almost every major site, even with my accounts logged in, and quietly falling back to much worse sources or just hallucinating.

Blaming the wrong things

My setup should have looked human: a spare MacBook Pro on my home network, logged-in accounts, nothing unusual. But almost anything with bot detection blocked it. Google and Bing threw CAPTCHAs, X kept showing login walls, and Medium wouldn’t even load past Cloudflare. I tried different browser MCPs, a bunch of browser CLIs, and configuration tweaks. Nothing helped.

I also tried switching networks and VPNs. Still nothing. That was the annoying part. I had spent weeks swapping pieces around, but the browser itself was still showing up as automation.

The CDP problem

So I went down the rabbit hole of how bot detection actually works.

OpenClaw’s built-in browser uses Chromium with Playwright. Tools like Puppeteer and Playwright use Chrome DevTools Protocol (CDP) to control the browser. When they connect, a Runtime.Enable command fires, which a few lines of JavaScript can detect. Both Cloudflare and DataDome check for it. IP and cookies still matter, but in my case they weren’t the thing giving me away.

CDP was only one of the leaks. Automation libraries also inject JavaScript into pages to work (window.__playwright__binding__ and similar). Anti-bot scripts catch these by checking property descriptors and function signatures. If toString() on a browser function no longer returns "[native code]", something has been tampered with. That’s enough to flag you.

And then there’s fingerprinting

Then there’s hardware fingerprinting, which I honestly hadn’t thought about at all. Your browser exposes hundreds of data points about the machine it’s running on, things like GPU model via WebGL, pixel-level Canvas output, screen resolution, even audio processing. A real machine’s fingerprint values fit together in a way that’s hard to fake. Automated browsers usually slip up somewhere. The Canvas output can be identical across thousands of sessions, or the user agent says Windows but the GPU says Apple. Any mismatch like that and the request gets flagged.

I hadn’t even considered this one. I’d been focused on cookies and headers while the actual problem was somewhere I hadn’t looked.

What finally worked

Most anti-detection tools try to fix this at the JavaScript level, overriding navigator.webdriver or faking Canvas output. A lot of bot detection can see through the common tricks.

After trying a few things I ended up on Camoufox, which is a Firefox fork. The reason it works where Chromium-based tools didn’t (for me at least) is that it skips CDP and patches fingerprint values down in the C++ layer, so the page can’t tell the values were spoofed.

Camoufox was painful to use directly

Camoufox fixed the browser side. Using it from an agent was the next problem. Camoufox only has a Python SDK, so every browser action required the agent to write a throwaway Python script, figure out the right method signatures, handle async contexts, and parse the results. Each page visit burned tokens just on boilerplate. The agent spent more time on Camoufox glue code than on the actual research.

Wrapping it

The reason I bothered wrapping Camoufox, instead of going back to Playwright with more patches, was that the browser part finally seemed right. The annoying part was making it usable by an agent.

So I wrapped it in a CLI. The agent calls shell commands instead of writing throwaway Python, and a daemon keeps the browser alive so it doesn’t pay startup cost every page.

I also added a feature inspired by agent-browser: returning accessibility snapshots instead of raw HTML. Most pages I was hitting were way cheaper this way. I haven’t benchmarked it carefully, but the number people usually cite for this snapshot + refs approach is roughly 93% less context-token usage than Playwright MCP.

Once OpenClaw was running through the CLI, the obvious failures mostly stopped. Searches went through, Medium wasn’t blank anymore, and X stopped throwing login walls at me on every visit.

This doesn’t make bot detection disappear. It just removed the dumb failures I was hitting every day.

It’s been running for a few weeks and I’ve mostly stopped thinking about the browser layer, which is what I wanted. The agent reaches the sources I expected it to in the first place.

I put the CLI, skills, and source code here: camoufox-cli. If your agent keeps getting stuck on CAPTCHAs or empty login walls, it might save you some time.

Moltbot first impressions: it really feels like an AI intern

Wed, 28 Jan 2026 00:00:00 +0000

I’ve been playing around with Moltbot (formerly ClawdBot) for a while now.

Bottom line: it’s genuinely fun. None of the ideas are new on their own, but the way they come together is surprisingly compelling. Fair warning though—the bugs can be brutal. I haven’t been this frustrated debugging something in ages. Still, it’s worth it. Using Moltbot feels uncannily like working with a remote intern.

Think of it as Claude Code + a ton of built-in Skills/MCPs + long-term memory + cron jobs + an IM bot, all rolled into one.

I set up a spare MacBook just for it, and now it can do pretty much anything. Moltbot is great at “taking over” a computer—it controls browsers, launches apps, runs shell commands, installs software in the background… basically anything you’d do yourself. For security reasons (and your own sanity), most people run it on a dedicated VM or spare machine and just talk to it through chat.

I use Telegram to chat with mine running on my home computer (it also works with WhatsApp and other messengers). There’s something weirdly satisfying about tapping on your phone and having an AI at home spring into action. It can seemingly do anything on that machine. This is the closest I’ve gotten to my dream setup—it genuinely feels like having a remote intern.

Why It Feels Like an Intern

Once you get past the setup, Moltbot is dead simple to use. Just message it. No AI jargon, no learning curve. That’s what sets it apart from other AI tools: you really can treat it like an intern sitting at a desk.

Some moments that made me go “whoa”:

1. It Handles Tasks Like a Real Person and Figures Things Out

It keeps surprising me by doing things other AIs simply can’t without access to a computer.

I sent it a voice message once. I hadn’t set up any speech recognition API, so it just… downloaded Whisper on its own, transcribed my message, then used macOS’s built-in text-to-speech to reply with audio.

Another time, it needed info from a Bilibili video. To “watch” it, the bot grabbed the video with yt-dlp, ran Whisper on the audio, and pieced together the content from the transcript and keyframes.

2. It Actually Learns

I’ve got some complex workflows that other AI tools just can’t nail. Moltbot struggled at first too, but with a bit of guidance, it picked things up fast. Every time I corrected it, it saved the lesson as a skill or memory doc. The more I trained it, the better it got at my specific tasks.

It also quietly picks up on my preferences and style. I’ll often say “remember this” or “watch out for that next time,” and it actually does. Each interaction gets a little smoother.

3. It Takes Initiative

I once mentioned offhand that I wanted to track interesting projects on Hacker News. It suggested making this a recurring task, set up its own daily checklist and tracking doc, and started sending me reports every morning.

You can hand off anything that needs ongoing attention, and it’ll just handle it. Similar to running cron + Claude Code, but way more flexible and natural. No bash scripts—just tell it what you want like you would a real person.

The Downsides

Bugs. Lots of them. Tasks die halfway through for no reason. Memory sometimes vanishes. It occasionally gets stuck in loops doing the same thing over and over. Setup is also a pain—the gateway is flaky, error logs are useless, and since you’re giving AI control of a computer, bad configs can be a security risk.

It’s clearly still early days. Best suited for tinkerers with some technical chops.

Tips

Give it a dedicated machine or VM. Don’t use your main machine.
Forget it’s an AI. Talk to it and train it like you would a real intern.
When it messes up, tell it to “remember this for next time.”
Encourage it to be proactive. You’ll be surprised how often it delivers.

Takeaway

If I had to sum it up: I genuinely treat this thing like a remote intern now. Moltbot feels like a real person in a way other AI tools just don’t—they feel like tools.

After using it for a while, I started fantasizing about buying a rack of Mac Minis and running a whole squad of Moltbots. My own little intern army. Turns out I’m not the only one—this has already become a meme:

2026.01.29 Update:

I keep liking ClawdBot more every day. And I’ve learned something important:

The more you treat it like a real person, the more it surprises you.

What this looks like in practice:

Give it a proper computer—something a human would use, like a MacBook
Put it on your home network, not some isolated server in a datacenter
Create real accounts for it (Google, Reddit, etc.) and let it manage them
Encourage it to use human-facing tools like browsers instead of raw APIs
When it’s working on something, coach it patiently and tell it to take notes
When it does well, let it know—positive feedback helps
Treat it as an equal and offer to help when it gets stuck …

Do this, and ClawdBot keeps surprising you in ways you didn’t expect.

The logic is simple: the more you treat it like a person, the more it acts like one. It starts holding itself to higher standards, showing growth over time. And as a bonus, internet CAPTCHAs and bot detection are less likely to flag it when it behaves more human.

Wire: the most elegant dependency injection tool for Go

Wed, 24 Aug 2022 14:52:21 +0800

Introduction

“Mature tools should learn to write code themselves.” This article introduces Wire, a Go dependency injection tool, its usage, and various practical techniques accumulated from experience. When code reaches a certain scale, Wire can play a significant role in component decoupling, development efficiency, and maintainability, especially in large monolithic repositories.

Dependency Injection

As projects grow larger, dependencies in code increase: various database and middleware client connections, data access layer repository instances, and service instances in layered design…

For code maintainability, coupling between components should be avoided. The specific approach follows an important design principle: all dependencies should be passed to components during instance initialization. This is dependency injection (Dependency injection).

Dependency injection is a standard technique for producing flexible and loosely coupled code, by explicitly providing components with all of the dependencies they need to work.

– Go Official Blog

Here’s a simple example where all component instances Message, Greeter, and Event receive their dependencies during initialization:

1
2
3
4
5
6
7


func main() {
 message := NewMessage()
 greeter := NewGreeter(message)
 event := NewEvent(greeter)

 event.Start()
}

Introduction to Wire

When there are more and more component instances in a project, manually writing initialization code and maintaining dependencies between components becomes tedious, especially in large repositories. Therefore, the community has developed several dependency injection frameworks.

Besides Google’s Wire, there are Dig (Uber) and Inject (Facebook). Both Dig and Inject are based on Golang’s Reflection. This not only impacts performance but also makes the dependency injection mechanism opaque to users—very “black box.”

Clear is better than clever, Reflection is never clear.

— Rob Pike

In contrast, Wire is entirely based on code generation. During development, Wire automatically generates component instance initialization code. The generated code is human-readable, can be committed to the repository, and compiles normally. Therefore, Wire’s dependency injection is very transparent and doesn’t bring any performance overhead at runtime.

Getting Started

Here’s how to use Wire:

Step 1: Download and Install Wire

Download and install the wire command-line tool:

1

go install github.com/google/wire/cmd/wire@latest

Step 2: Create wire.go File

Before generating code, we first declare the dependencies and initialization order of each component. Create a wire.go file at the application entry point.

cmd/web/wire.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// +build wireinject

package main

import "..." // Simplified example

var ProviderSet = wire.NewSet(
 configs.Get,
 databases.New,
 repositories.NewUser,
 services.NewUser,
 NewApp,
)

func CreateApp() (*App, error) {
 wire.Build(ProviderSet)
 return nil, nil
}

This file won’t participate in compilation; it just tells Wire about component dependencies and the expected generation results. In this file: we expect Wire to generate a CreateApp function that returns an App instance or error. All dependencies required for App instance initialization are provided by the ProviderSet provider list, which declares all potentially needed component acquisition/initialization methods and implicitly defines the dependency order between components.

Component acquisition/initialization methods are called “providers” in Wire

Some important notes:

The file must start with // +build wireinject and a subsequent blank line, otherwise it will affect compilation
In this file, editors and IDEs may not provide code hints, but we’ll show how to solve this problem later
The return values in CreateApp (two nils) have no meaning; they’re just for Go syntax compatibility

Step 3: Generate Initialization Code

Execute wire ./... on the command line, and you’ll get the following automatically generated code file.

cmd/web/wire_gen.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


// Code generated by Wire. DO NOT EDIT.

//go:generate go run github.com/google/wire/cmd/wire
//go:build !wireinject
// +build !wireinject

package main

import "..." // Simplified example

func CreateApp() (*App, error) {
 conf, err := configs.Get()
 if err != nil {
 return nil, err
 }
 db, err := databases.New(conf)
 if err != nil {
 return nil, err
 }
 userRepo, err := repositories.NewUser(db)
 if err != nil {
 return nil, err
 }
 userSvc, err := services.NewUser(userRepo)
 if err != nil {
 return nil, err
 }
 app, err := NewApp(userSvc)
 if err != nil {
 return nil, err
 }
 return app, nil
}

Step 4: Use the Initialization Code

Wire has generated the real CreateApp initialization method for us, and now we can use it directly.

cmd/web/main.go

1
2
3
4
5


// main.go
func main() {
 app := CreateApp()
 app.Run()
}

Usage Tips

On-Demand Component Loading

Wire has an elegant feature: no matter how many providers are passed in wire.Build, Wire will only initialize component instances as actually needed. All unnecessary components won’t have corresponding initialization code generated.

Therefore, we can provide as many providers as possible and let Wire handle component selection. This way, whether we’re adding new components or deprecating old ones during development, we don’t need to modify the initialization code in wire.go.

For example, we can provide all instance constructors in the services layer.

pkg/services/wire.go

1
2
3
4


package services

// Provides all service instance constructors
var ProviderSet = wire.NewSet(NewUserService, NewFeedService, NewSearchService, NewBannerService)

In initialization, reference all potentially needed providers.

cmd/web/wire.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var ProviderSet = wire.NewSet(
 configs.ProviderSet,
 databases.ProviderSet,
 repositories.ProviderSet,
 services.ProviderSet, // References all service instance constructors
 NewApp,
)

func CreateApp() (*App, error) {
 wire.Build(ProviderSet) // Wire will selectively initialize based on actual needs
 return nil, nil
}

In subsequent development, if you need to reference new dependencies, just add them to the parameters. Wire will intelligently generate initialization code for required component instances based on actual needs.

1
2


func NewApp(user *UserService, banner *BannerService) {
}

Even if Wire can’t find the required provider, it will report an error during compilation, not during runtime in production.

wire: cmd/api/wire.go:23:1: inject CreateApp: no provider found for *io.WriteCloser

Editor and IDE Configuration Support

Because the wire.go file includes this comment, Go will skip this file during compilation, but this also affects editor and IDE code hints. When editing the wire.go file, common editors and IDEs cannot properly provide code completion and error hints.

1

// +build wireinject

But this problem is easy to solve. Find your IDE/editor’s Go environment configuration and add the parameter -tags=wireinject to Go Build Flags.

This configuration allows editors and IDEs to properly provide code completion and error hints for wire.go files, significantly improving the development experience.

Conflicts with Multiple Instances of the Same Type

This issue is relatively rare, but it’s easy to encounter in large projects.

Wire determines dependencies through provider parameters and return types. Sometimes, different instances of the same type might appear in the dependency network. When this happens, Wire cannot correctly determine dependencies and will report an error directly.

provider has multiple parameters of type ...

For example, in the following provider, the MySQL and PostgreSQL client instances have exactly the same type (both *gorm.DB), so Wire cannot correctly determine dependencies based on type and will report an error during code generation.

1
2
3


// This service uses data from both mysql and pg, but the two instances have the same type
func NewService(mysql *gorm.DB, pg *gorm.DB) *Service {
}

The solution is relatively simple: just wrap the types.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


type Mysql gorm.DB
type Pg gorm.DB

// Use type aliases to distinguish in parameters
func ProviderService(mysql *Mysql, pg *Pg) *Service {
 // Convert back to original types inside the function
 r1 := (*gorm.DB)(mysql)
 r2 := (*gorm.DB)(pg)
 return NewService(r1, r2)
}

Then use ProviderService instead of NewService.

1
2
3
4
5


wire.Build(
 ProviderMysql, // func() *Mysql
 ProviderPg, // func() *Pg
 ProviderService, // func(mysql *Mysql, pg *Pg) *Service
)

Automatic Constructor Generation

As the number of structs serving as abstraction layers increases in a project, manually writing and maintaining struct constructors becomes tedious. If you add a pointer-type member to a struct but forget to update the constructor, it might even cause panics in production.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


type Service struct {
 repo *Repository
 logger *zap.Logger // After adding this member, forgot to update the constructor
}

func NewService(repo *Repository) *Service {
 // Missing logger, might cause null pointer error in production
 return &Service {
 repo: repo,
 }
}

Such tedious, repetitive, and error-prone work should be handled by automated tools. I recommend newc (meaning “New Constructor”), which can automatically generate and update struct constructor code.

Usage is very simple; just add this comment to the struct:

//go:generate go run github.com/Bin-Huang/newc@v0.8.3

For example:

1
2
3
4
5
6
7


// My User Service
//go:generate go run github.com/Bin-Huang/newc@v0.8.3
type UserService struct {
 baseService
 userRepository *repositories.UserRepository
 proRepository *repositories.ProRepository
}

Then execute go generate ./... on the command line to get the constructor code:

constructor_gen.go

1
2
3
4
5
6
7
8


// NewUserService Create a new UserService
func NewUserService(baseService baseService, userRepository *repositories.UserRepository, proRepository *repositories.ProRepository) *UserService {
 return &UserService{
 baseService: baseService,
 userRepository: userRepository,
 proRepository: proRepository,
 }
}

This tool works great with Wire. When you need to use new dependencies, just add members to the struct. No need to manually update constructors or worry about initialization—all repetitive work is handled by automated tools (Wire and Newc). It works very well in real projects.

Of course, this tool may have some unconsidered situations, and I look forward to everyone’s feedback and suggestions.

Don’t repeat yourself “DRY”

Summary

Wire perfectly solves dependency injection problems, but it’s not a framework—it has no “magic” and isn’t a black box. It’s just a command-line tool that automatically generates initialization code for component instances based on actual needs. Then the problem is solved, with no additional complexity and no runtime performance overhead.

Wire shares the same qualities as Golang: simple, direct, and pragmatic. It truly deserves to be called Go’s most elegant dependency injection tool!

Keep it simple stupid “K.I.S.S”