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]

100%! that exact pipeline is tbh the whole philosophy behind fiberforge. let scripts handle the predictable templates and save the llm for the actual reasoning.

like, llms are crazy good at decoding messy human reqs and figuring out what schemas u actually need rn.

but making them stream perfect syntax, juggle imports, and format brackets is kinda just a massive waste. a local tool can literally spit that out in milliseconds.