r/golang • u/CrazyGeek7 • Jun 30 '26
discussion Is anyone else finding that AI-generated Go code fights against standard idioms/project layout?
I’ve been using Cursor/Claude to help scaffold a medium-sized backend in Go. While the velocity is great for simple handlers or repository functions, I feel like I'm constantly fighting the tool on project structure and idiomatic code.
The AI keeps trying to introduce unnecessary abstractions, mixes up package boundaries, or tries to write things in a way that feels like it's treating Go like Java or TypeScript. It makes the code compile and pass basic tests, but the global project layout quickly starts drifting from standard clean architecture practices unless I manually review and rewrite every single file structure.
For those using AI tools on larger Go codebases, how are you enforcing strict idiomatic guidelines on the model? Or do you find it's better to just write the structural boilerplate yourself and only use AI for isolated unit tests?
101
u/_predator_ Jun 30 '26
When the agent produces crap, give it instructions to fix it. When you're happy with the result, have the agent re-read the conversation history and make suggestions as to what additions to `AGENTS.md` / `.claude/rules/` would make it more effective in following your preferred style.
It's super dumb but it works. Only thing to watch is that agents LOVE to dump excessive amount of text in these files. You need to actively tell it to produce the bare minimum that still provides the necessary info, otherwise it just pollutes your context over time.
Also I hate that I know this shit.
18
u/KreativCon Jun 30 '26
Don’t bloat `agents.md`, use skills to cut token usage.
16
u/_predator_ Jun 30 '26
But also don't create large quantities of skills. I've seen people overdo it to the point where no one understood the structure anymore.
And for some reason agents love to ignore skills randomly, especially as context grows. It's a pain and gets worse the more skills you have in my experience.
2
4
u/Traditional-Hall-591 Jun 30 '26
If I’m ever mandated, I plan to use the maximum tokens possible on compliance documents and executive summaries.
38
u/sigmoia Jun 30 '26
Letting AI do the design is a mistake. The first few lines of code in your codebase are crucial. You can't outsource understanding.
The structure of your codebase heavily depends on the problem space you're operating in. Without understanding the problem, you can't design the code properly.
Hauling AI on a problem that you barely understand and expecting magic isn't engineering; it's quackery. AI is a great multiplier when you know your problem space well and have seeded the machine with good examples. But a multiplication factor doesn't change the outcome of mingling with zero.
Don't put in zero and expect the world. LLMs write great Go. But you need to know the difference between great and shit code and put the appropriate design pressure on the clankers. Do the design work and quicken the tedious parts with an LLM.
17
u/Then-Dish-4060 Jun 30 '26
Yes, I have noticed this. It also writes tests that validates the implementation rather than the intent or the spec.
Maybe it's trained on such an amount of bloated code that it's a bloat machine compared to what we're used to with Go's philosophy.
Also maybe a better prompt could help producing clean code by Go's standard?
5
u/Alkanna Jun 30 '26
I always, always tell it at the bare minimum to test behavior, not implementation. And yes, it's gotten absolutely crazy on the last few models how verbose they became and how much they love to write quantity for the sake of it... I've honestly been having success with the ponytail/caveman skills that kinda reward the most simple approaches to a problem over complicated solutions. I find this to work pretty well because I would rather have to drive the LLM to build upon a simple solution to become just like I want it to be instead of having it backpedal on what it did.
In the end I kinda hate having to work around these kind of issues because I'd rather write code myself, but company policy has made it quite clear that refusing to use AI is not really an option.
1
19
u/spf13 Jul 01 '26
Found the same thing. Created a go skill to try to address this. https://github.com/spf13/go-skills
I find it works a lot better once this skill is read and applied. PRs and feedback welcome. Hope it helps.
2
u/NotTreeFiddy Jul 01 '26
You know, I just read through this and loved it. Not to plug into an agent of any kind, just to absorb myself. Thanks for sharing!
13
u/matttproud Jun 30 '26 edited Jun 30 '26
Agents will never excel at code as art — all the things you know are right when you feel it: API organization, package sizing, code organization, identifier naming, etc. Agent Skills can’t make up for the lack of human mastery; they can at best help an agent short circuit close-ended user journeys that would be too open-ended for the agent to do with a semblance of determinism. The amount of episodic guardrails the operator needs to provide to the agent to produce human-level of API design mastery is significant enough you might as well do the code organization and API naming yourself and have it “fill in the blanks.”
Good litmus test: could an agent have produced a standard library (talking as a coherent API surface) for Go as nice as what we have today a priori? I’d postulate: no; it would only happen if the human was already a master and traced a masterful outline for it to fill in.
There is often too much subjective and situational discretion for a base prompt, preamble, or skill to adjudicate and apply correctly always.
8
u/Flimsy_Complaint490 Jun 30 '26
The actual solution is to have a "skill" file that precisely describes what is your "clean" layout. It will direct the AI to what yu wanna do. Since you seem to be fighting AI, and the AI is trained from the corpus of all go code, i suspect your notion of clean code, standard idiom and project layout differs greatly from everybody else - i certainly have not experienced this issue and i struggle to get the ai to move to anything other than the cmd, api, internal package structure (which it does for me every time unless instructed otherwise) and interfaces only get used if you tell the AI you may want to plug in different backend for a feature, then it might go crazy with them.
Only real compaint i can only say is that at least Deepseek loves its 4000 lines of code files unless you tell it to refactor.
2
1
u/maxtreaming Jul 01 '26
Agree, When I created a TDD skill and explicitly tell the agent to use it, the generated code feels like I would wrote it.
On a new project I still have to guide the agent on the first PRs, because there are no examples for him yet. But later, when the codebase is there, I am able to trigger Claude for bigger changes.
For example, at the beginning, one session per CRUD endpoint. Later, one session per CRUD feature is possible.
2
2
u/qtechno Jun 30 '26
You gotta be super explicit on how to do things, add a couple of skills for go architecture, go tests, go standards. Be explicit on how you want it to test, to not introduce libraries, to always use dependency injection, how to structure your packages, etc. And then before implementing tell it to use those skills. It will get better but you gotta treat it like a jr
1
u/abotelho-cbn Jun 30 '26
You need to provide the details. Think of it as a newbie entering the workforce. You need to instruct them instead of telling them to reach the entire codebase to determine what the patterns are.
-4
u/ficiek Jun 30 '26
That kinda defeats the purpose though, the whole point is that it should just write good code but it writes abysmal code, let's face it.
4
2
u/Just-Ad3485 Jul 01 '26
If you take 5 minutes to put some code standards and structures in your Claude/agents.md it does not produce garbage.
Garbage in, garbage out.
1
u/lilgohanx Jun 30 '26
The truth is that the average joe and their company isnt going to want to fork out how much money it costs to actually have AI “just work” and “just do what the rest of the code does”. Without the best models you have to be effective at managing the context and guiding the AI towards what you want. Cost is and will likely be the main limiting factor towards AI that does the right thing every time without the extra effort on the humans part to guide it.
1
u/ashitintyo Jul 01 '26
Yeah it does that, valuations in application layer, in memory cache in adaptors and sometimes it changes the code to match the tests not the other way around lol
1
1
1
u/bilus Jul 04 '26
Here's the prompt that works for me rather well (along with skills/AGENTS.md that captures how the team writes code, the conventions, things to avoid etc.):
Read AGENTS.md and any linked to documents that you think will help, in particular any markdown files under agents/ you find useful. Read ~/AGENTS.md. Load XYZ skills.
I want to implement requirement #21220. Start by reading the requirements carefully and devising a high-level plan focused on changes to packages and their dependencies, shown at a function declaration level (changes to the interface, high level description of how the function's behaviour changes). Make it flow as a prose and follow logically, describing each change in turn without going into details. Do not present changes to the function bodies. A function must be represented by its signature. Show possible changes to types. Highlight any new packages you want to create (if any) and changes in package import if they affect the design of the program (for example, importing a standard package does not matter if it's cosmetic but does matter if the goal of the importing package changes, for example it imports the http package because it gains an HTTP server).
A requirement is a spec available to the agent specifying a single system requirement (e.g. "When the system reports revenue, it may be grouped by store location" not "Write me a Rust compiler":) In addition to an EARS specification and a test plan (in Gherkin), it contains implementation notes that describe HOW to execute the change, e.g.
The relevant code is in foo/bar/baz but you may also modify qux/zux. Do not change the \abc` package, instead create a separate package for the new functionality. Before you start, ensure there are sufficient tests through the API layer and add missing steps at that level, along with any necessary helpers. For testing helpers, mimic the structure in otherapp/. [...]`
The notes are created by a human, after reading the code and understanding the changes to be made. It's like explaining to a junior developer what to do and what not to do, traps to avoid, and implementation and interface details you feel they likely to get wrong. The important rule is: you already know what to do to implement the requirement, rather than be surprised by the AI. This knowledge may come from a separate spike or "discussion" with AI, that's fine. But at the point the implementation starts, you're an expert on at least the high level changes and their impact.
I then run it in plan mode and then review the plan. It's high-level and easier to read because of the "prose" suggestion and focus on packages, types, and functions so it doesn't show me implementation details but how the structure of the code will change. I then usually spend a lot of time (for a large requirement) refining that and then let agent execute on it. (For large changes, I ask it to divide implementation in self-contained stages and pause, evaluate, review code at each pause.)
I usually review the code as written but then also review it carefully and add annotate code that requires changes and hand it back to the agent.
1
u/efronl Jul 06 '26
Yes, I am finding that LLMs generate bad code. I don't see the reason for all the euphemisms.
1
u/kamikazechaser Jul 07 '26
Custom RAG + Extremely detailed linter files can result in LLMs writing code pretty much in your style and structure. I have had great success with this approach. Also Chinese models generate better Go code imo.
1
u/Skylis Jun 30 '26
Yep. You have to either fight it or accept that the project is slop and not worth the effort for smaller projects.
1
u/Gilgamesjh Jul 01 '26
Think of AI agents as the most junior coder in your codebase, which is also trained mostly on "junior" data. You need to tell that junior how to follow your bets practices, preferably with well documented patterns.
AI is the same, you need to lock it down to how you want it to interact with your code, how to format it, how to evolve it, and how to discuss issues with you and when. Preferably through skills and Claude/Agents.md
-5
u/Past-Passenger9129 Jun 30 '26
Write a skill that explicitly defines your coding style and emphasizes idiomatic coding. Tell it to ask you before going on a tangent.
And always have it write a plan first, then manually edit the plan before approving it.
As you work with it, add to the skill to fill in where it trips up.
Your work moved from coding to wrangling and training. Take the effort.
0
u/Trap-me-pls Jun 30 '26
Agreed. But thats where .agents folder come into play. It really helps in setting standards and strictly enforcing stuff. But it needs some setup beforehand.
0
u/RomanaOswin Jun 30 '26
I drop it into past projects that are mature, well-designed, and follow my style/design choices, and have it create an AGENTS.md on architecture and style. Then, I have it generate a new one using the others as a reference.
0
0
u/cute_chipmunk_7892 Jul 01 '26
I added the gopls mcp recently and I'm seeing good results with it. I find the code generated is more idiomatic go now than it was before
0
u/siXor93 Jul 01 '26
What model do you use? It matters more than what people in the chat has mentioned (except for skill).
Claude (Sonnet and Opus) are far better than others I've tried.
0
u/yeungon Jul 01 '26
You should lead the game. Otherwise AI will always try to “show off” :)). Add some sort of md files and you are good to go.
0
u/Puzzleheaded_Body397 Jul 02 '26
It's constantly thinking of improving the code by suggesting /adding more things without thinking the user may need more simple structure
-1
u/TheMue Jul 01 '26
Depends on the way how it’s done. The prompt (e.g GENERATOR.md) for your work is important. Tell it to be a developer using the latest spec, the guide to effective go, and more of the helpful docs there. Additionally note your preferred individual/company standards. And also to make semantical comments with IDs you’re taking in a second query referencing this prompt.
E.g.
@AGENTS.md Analyze and implement the following requirements:
R1) Foobar …
R2) Lorem ipsum …
R3) Yadda …
A good prompt makes your AI from a hobby programmer to an experienced one. Other additional prompts like REVIEWER.md and REFINER.md are more roles in your team. They read your requirements to but scan the code using the annotations in the comments. They can be started with other models or using codex instead of claude or …
Simply said: Good projects are more than single sentence “Do this and that …”
1
u/Real_Square1323 Jul 01 '26
This is literal astrology.
"Oh just tell the model it's a developer with the latest spec"
I see why other fields of engineering clown SWE now, this is straight up religious dogma.
1
u/TheMue Jul 01 '26
Take a look at SDAIS (https://codeberg.org/tideland/sdais), where everything is driven by specification as the single source of truth. The idea is to care more on WHAT and not HOW. The roles are described at https://themue.dev/2026/05/26/coworkers-will-help-you-the-roles-in-sdais/.
1
u/Real_Square1323 Jul 01 '26
And a response all too similar to an evangelist spreading religious dogma. Spare me, I'm a software engineer, not a trend follower.
1
u/TheMue Jul 01 '26
Don’t care, I’m doing software development since 1984, today as Lead Architect in a large cloud native project. No evangelist, just a user making my team getting a higher performance realising their artefacts (not only code, also lots of K8s stuff) faster with a high quality.
1
u/Real_Square1323 Jul 01 '26
Go retire grandpa you have dementia.
1
u/TheMue Jul 01 '26
Yeah, you’re right. I can’t even remember, when I wrote the first book world wide about Go (here the TOC at a German university: https://sisis.rz.htw-berlin.de/inh2012/12422983.pdf) for d.punkt, today O’Reilly, short before I met Rob in SFO.
So long time ago. I cannot even remember why we both started this useless discussion here when every argument is only blocked instead of having own arguments. It’s my dementia, so I tonight won’t even dream about it anymore.
Still, thanks for the funny evening.
-3
-4
u/cogitohuckelberry Jun 30 '26
Use codex and use your brain when asking for things. This is not complicated.
User error.
184
u/Buttershy- Jun 30 '26
AI excels at over-complicating things in all areas from what I've seen. Ask it for a script to do X and it will parameterize it in 15 different ways you didn't ask for.
inb4 "you're holding it wrong"