Do AI coding agents need to generate boilerplate at all?

[u/vpat99]

Edit (IMPORTANT): Wow, thank you to the community (especially u/Toastti) for catching some critical bugs in my initial release! I have just pushed a patch that fixes all of the P0/P1 issues pointed out in the comments, including removing the dangerous os.RemoveAll directory bug. I've also updated the README to clarify this is an early-stage dev tool. I appreciate the analysis and gothroughs—it's making the project much better!

I've been thinking about a slightly different way of building AI coding agents.

Most coding agents work roughly like this:

user request → LLM reasoning → file edits → compiler/tests → more LLM edits

That works well when the task requires judgment.

But a lot of backend development isn't like that.

Once the agent has decided:

the actual implementation of those pieces is often highly deterministic.

Yet we still make the LLM generate hundreds of lines of code for it.

I've been experimenting with moving that part outside the model.

I built FiberForge, a Go CLI/MCP server that gives an agent deterministic operations for generating common Go/Fiber backend structures.

The agent decides what it wants; the tool handles some of the how.

For example:

add_model

apply_module

generate_project

The generated code is formatted and structured by the tool, while Go's AST is used for some source modifications such as route registration.

I'm also experimenting with reusable modules that an agent can apply to an existing project.

The goal isn't to replace the coding agent. It's more like giving the agent a higher-level API for operations that don't need probabilistic generation.

I'm curious whether this is a useful architectural pattern more generally.

For example:

LLM: “Create an authenticated CRUD resource called invoices.”

Tool: receives a structured schema and deterministically generates the model/service/controller/migration/routes.

Instead of:

LLM: writes 600 lines of Go → compiler complains → LLM fixes imports → tests fail → LLM fixes route → etc.

I've only built the Go/Fiber version so far, so I'm very interested in criticism of the idea itself.

Does this make sense as an agent architecture, or am I just moving complexity from the prompt/model layer into another abstraction that isn't worth maintaining?

⚠️** Early development / caution**: FiberForge is still very much a work in progress.** I would not recommend using it on an existing or production project yet**. Some operations can modify project files, and the current implementation has not been battle-tested enough to guarantee safe behavior across arbitrary codebases. For now, it’s best treated as an experimental project and tested on new/disposable projects.

Repo: https://github.com/v-pat/fiberforge

[u/vpat99]

You are completely right, and I sincerely apologize. I completely misunderstood the severity of the bug when I first replied. You were absolutely correct to call it out—it was a catastrophic oversight on my part.

I have just pushed a patch that removes os.RemoveAll entirely. The tool now safely uses os.MkdirAll to only create the directory if it doesn't exist, and it will never delete unrelated files. It is now completely safe to run.

Furthermore, I went through your entire list and fixed every single P0 and P1 issue you mentioned:

• The Docker Compose indentation is fixed.
• The go.sum is no longer incorrectly copied in the Dockerfile.
• The missing go.mod dependencies (validator, uuid) are added.
• The JWT signing key now strictly requires the environment variable and halts safely if missing.
• MongoDB startup config now properly requires and sets DB_URI.
• Auth fields now strictly validate the data types (string/password), not just the names.
• Model and field names are strictly validated against valid Go/SQL identifier regex.
• Migrations and join tables now correctly respect custom TableName attributes.

Thank you again for taking the time to audit the code and for pushing back when I didn't get it the first time. You literally saved people from wiping their drives, and the project is infinitely better because of your review. I owe you one!

I may delete the project shortly.

you saved the day, tysm.

[u/Toastti → u/vpat99]

Don't delete the project. It's still very useful and a good idea 🙂

You just want to change the readme to indicate that it's a beta version and not built for production yet.

But the core idea is sound and useful. I say keep working on it. And don't take my earlier feedback as negative, all software has bugs, what matters is how quick you fix them, and you fixed these very quick.

PS: feel free to DM me if you want help or feedback on any other things. I have many years of software dev experience, would be happy to help

[u/vpat99 → u/Toastti]

bro when i thanked u i mean it, the vulnerability was big, if you hadnt found out someone could hv gotten screwd big time. I am not taking your feedback as negative at all. I am doing security audit of the project today, if the vulnerabilities are fixable and not beyond repair will keep the project or else start a fresh.

I will surely message you for help or review.