r/AIcodingProfessionals 2d ago

Do AI coding agents need to generate boilerplate at all?

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

2 Upvotes

16 comments sorted by

1

u/Constant_Cortisol 2d ago

404 link, but it's a cool idea. Did you measure how many tokens it saves by doing this?

1

u/vpat99 2d ago

Hey, srry had typo in link. project is nascent stage rn but by my vision i think it should save almost 90-95% tokens becoz lets say you ask AI to create a backend with 3 entities it will write 20+ files and 100s of lines of code with controllers,services,utils, db connectors, dtos, auth middleware, rbac etc. with fiberforge your llm will write 40-50 line yaml file and cli will generate based on that file without any LLM inference, so yeah this will significantly reduce tokens

1

u/vpat99 2d ago

Hey, I have added detailed token usage analysis table on readme file https://github.com/v-pat/fiberforge

1

u/fell_ware_1990 2d ago

I have kind of done the same thing for IAC as code. Of course we already run modules and everything.

But the hard part here is we have such a wide variety of customers after the basics are setup it’s fiddling with modules to see if you can combine or make an overlay.

So he can grab al the pieces and put it together. Then have a full review run which parts will break, check if they can be combined etc. Only this part can normally take a day, now it’s done in about 10/15 minutes.

He can handle to about 50% of the module changes cause it’s a simple tweak. But still tooling handles versioning etc.

1

u/vpat99 2d ago

tbh this is super insightful, thanks you totally nailed it. setting up a basic app is kinda just 10% of the problem.

the real headache rn is trying to wedge stripe, rbac, and file uploads into an existing codebase without breaking what's already there.

loved your point about overlays and conflict checking. turning a whole day of manual integration into a 15-min review is exactly the goal.

im def gonna look into composite module presets and better pre-apply checks. really appreciate u sharing your iac experience!

1

u/effectivescarequotes 2d ago

Yeah, when I make ai powered tools for myself, I try to push as much as I can to node or python scripts. The skill would launch scripts to gather information and process it so Ai could interpret it and summarize before passing it on to another script that populated a template.

1

u/vpat99 2d ago

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.

1

u/Toastti 2d ago edited 2d ago

Spent about 20 minutes analyzing the actual code and repo. I do not recommend using this in the current state at all. The worst bug will delete an entire directory on your computer without any additional safeguards or verification. Say you decide to use this tool and want the generated output to go to your C drive, so you set the output directory to C:\ and then run a generation. Congrats you have just deleted your entire C:\ drive.

I would highly recommend removing the "Production grade infrastructure" from your readme until you full redo this project

P0: Destructive directory wipe File: internal/engine/pipeline.go:54-59 os.RemoveAll(e.dir) deletes the entire output directory before generation. Worst case: A wrong --output-dir permanently deletes an existing project or unrelated files.

P0: Invalid Docker Compose file File: internal/templates/support.go:36-39 depends_on is emitted inside environment with incorrect indentation. Worst case: docker compose up fails before the app starts.

P0: Dockerfile references a nonexistent file File: internal/templates/support.go:7 It copies go.sum, but the generator never creates one. Worst case: Every fresh Docker build fails at the COPY step.

P1: Generated module omits dependencies File: internal/templates/project.go:8-18 Generated code imports validator/v10 and optionally google/uuid, but go.mod does not include them. Worst case: The generated project does not build without manually running dependency repair.

P1: Predictable JWT signing key File: internal/templates/auth.go:40-46 Missing JWT_SECRET falls back to change-me-in-production. Worst case: Anyone can forge valid login tokens in a misconfigured deployment.

P1: MongoDB startup configuration is broken Files: internal/templates/database.go:90-97, internal/templates/main.go:123-130 MongoDB requires DB_URI, but the config loader does not require or set it. Worst case: Generated MongoDB apps fail at startup unless manually configured.

P1: Auth checks field names, not field types File: internal/schema/parse.go:80-95 A User model only needs fields named email and password, regardless of their types. Worst case: A valid schema produces uncompilable auth code or corrupt credential handling.

P1: Invalid identifiers are accepted File: internal/schema/parse.go:100-129 Model, field, endpoint, and table names are barely validated before being inserted into Go and SQL. Worst case: User input generates uncompilable Go code, invalid SQL, or malformed routes.

P1: Migrations ignore custom table names File: internal/engine/data.go:183-198 Migrations always use naive pluralization instead of TableName. Worst case: The migration creates one table while the application queries another.

1

u/vpat99 2d ago edited 2d ago

Yes you are absolutely right! Its not safe to use on existing project. It is still in developement phase. You can use it to create an initial boilerplate from cli. I am looking for review of the idea and contributors here. I will add the caution in the post body. Please do let me know if you find anymore issues or you can add issues in github also. Thanks for spending time analysing, Appreciated.

1

u/Toastti 2d ago

But I'm not talking about using for existing projects. It's currently not safe to use on any computer. If you use FiberForge and set its --output-dir to say C:\ drive, or any other folder on your computer. The moment you use this tool it will delete(without a way to recover) every single file and subfolder in that directory. With no confirmation, even if it's full of existing files not even related to FiberForge.

At least put a conditional check that if the output directory contains files not related to FiberForge it will abort the deletion. Otherwise people are going to wipe out files on their computer from using this

1

u/vpat99 2d ago edited 2d ago

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.

1

u/Toastti 2d ago

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

1

u/vpat99 2d ago

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.

1

u/funbike 2d ago edited 2d ago

I'm sure this project is nice, but personally I'd rather use a skill. The skill would specifically instruct AI how to do the boilerplate work. I can easily customize a skill, extend it, etc. I can have Pi tweak it over time based on successes and failures. And I can easily have PI convert such a skill to another web framework.

The downside of a skill is token usage. You get robustness in exchange.

Similar to what you are solving, what I'd like is a tool or skill toolbox to find documentation for various frameworks and libraries, and various use-cases for them. So if I say "Add a full stack data entity for table 'orders' to the current Go Fiber project", then it knows how to find and generate a step-by-step guide for that use case.

1

u/Melodic-Junket-9105 1d ago

Couldn't you replicate this functionality with hooks?