7 ms·

My agent.md to improve LLM-assisted code quality

415 points by ibobev 2mo ago

theturtletalks 2mo ago
I used to be big into agents.md files but read the latest SOTA doesn’t need them anymore. Have people still been getting value out of them?
getnormality 2mo ago
This is a problem that people mostly have to solve themselves. Like, I've been working with Claude for almost a year now and I have never once seen it write "Arrow Anti-Pattern" code. That, and much of the rest, would be fluff in my projects. Agent instructions are best learned from experience project-by-project.
- Sammi 2mo ago
  Yes, the interesting part about seeing other people's agent.md files, is getting to see what issues they have with working with agents. Seems different people run into very different issues, which probably is caused by how differently we work. So a the file probably should be personalised.
  - pianopatrick 2mo ago
    Might also be per model. Different models might have different issues and require different instructions
OptionOfT 2mo ago
A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why. Use examples when possible. Propose ASCII drawings to explain complete systems. The what _is_ the code.
- getnormality 2mo ago
  I would never tell an agent to write "what does the code do" comments. Their default comments are already way too fluffy.
  - deleted 2mo ago
    [deleted]
  - rustystump 2mo ago
    I added to the memory, system prompts, and the prompt itself and every soa model still litters code with the most inane useless crap. I will then get code to review from a coworker using fable/opus. It has more lines of comments then code. Maybe I am some god tier code reader (i am not) but i dont think i have ever found a comment in code to be useful in my day job. That isnt true, i once came across // submit to the dark lord Above the function that sent a payment to PayPal for processing. It made me laugh so I let it be.
    - danielheath 2mo ago
      Most useful code comment I have encountered read: “”” After you give up on trying to refactor this code, increment the following line accordingly. HOURS_WASTED_HERE=26 “””
      - cwsx 2mo ago
        I always loved the classic _"Here be dragons"_
  - saghm 2mo ago
    But then you don't know about where the load bearing seams are!
    - JSR_FDED 2mo ago
      Honestly? That’s the kicker.
acedTrex 2mo ago
Agents.md is such a ridiculous concept, just write good contributing docs and then optionally @ the file in whatever agetn file you use. That way everyone benefits.
- FooBarWidget 2mo ago
  No, why should I have to remember to @ in every prompt? Or ask contributors to remember. It just makes it easier to make human mistakes. I have better things to do than micromanagement. There is huge value in auto-included context.
  - anygivnthursday 2mo ago
    The GP wrote @ it from the agents.md file, not from the prompt. Their point was that instead of writing "how to contribute" instructions for agents, you could explain that in the CONTRIBUTING.md and link it from your agents file, so both humans and agents read it from one place.
    - formerly_proven 2mo ago
      Symlinks exist, but it's kind of ridiculous all harnesses just ignore CONTRIBUTING, HACKING and friends.
  - acedTrex 2mo ago
    You put the @ in the context file the LLMs all use, claudemd agentsmd whatever the thing that most harnesses force load. Then the model will go discover what it needs to.
- svachalek 2mo ago
  These days that sounds like a really good idea. 6 months ago, AGENTS.md would have contained a lot of instructions that would have been embarrassing to write out for a human audience.
oumua_don17 2mo ago
Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.
- wpasc 2mo ago
  idk who came up with it first, but ASD-STE100 has been floating around more since matt pocock put it in one of his skills
- mattjoyce 2mo ago
  This will produce quite verbose prose. STE100 is good for specs and explanations but it works best with a glossary or terms. will burn tokens.
  - hartleybrody 2mo ago
    This has not been my experience at all. I have been using this skill[0] for several weeks and when I ask it to rewrite existing AI slop docstrings to use this convention they are nearly always 10-20% smaller, plus easier to read and mostly free from the traditional "tells" of AI writing. [0]: https://github.com/AminBlg/SimpleEnglish https://github.com/AminBlg/SimpleEnglish
- statenjason 2mo ago
  Agreed. ASD-STE100 makes automated code reviews tolerable.
- bityard 2mo ago
  Do you give the model access to the ASD-STE100 spec for reference/review or are you just assuming that enough of it is baked into the model for it to mostly adhere to it?
- sha-3 2mo ago
  If we alter the way LLMs talk, will it noticeably affect the quality of code it produces?
Geee 2mo ago
I feel like claude.md is like Asimov's laws of robotics. Whatever you write there ends up eventually messing up everything.
- jdiff 2mo ago
  Anything that goes into the context window has that going for it. That's a huge part of why Claude's gone absolutely bonkers with genuine, brutal honesty. The system prompt's absolutely stuffed full of those keywords, so now every single output is tainted with that right from the start.
bellowsgulch 2mo ago
I've read a few of these over the years, and none of them seem to be useful. I have three sentences in my custom instructions, and those are basically all useless, too. Even my second one, "Avoid decorative or section-header comments. Never use `----` or `====` as comment separators. Comments should explain only non-obvious behavior, rationale, constraints, or implementation details." seems to be ignored by models regularly, so I don't see the point. But this is in my private harness. Perhaps other harnesses have better instruction following. My custom instructions are prepended to my first user message, not set as a system message.
- dan_ggggg 2mo ago
  [flagged]
FooBarWidget 2mo ago
One tactic I’ve found helpful is multi pass quality improvement. First make it work. Then review for guidelines adherence. Loop until satisfied.
YuechenLi 2mo ago
Since we are sharing our AGENTS.md, I thought I'd share my own, because most of the time, this is pretty much all you need for LLMs to write good code, everything else can be added per project: ---- *Convergence rule* Every substantial task must end in exactly one of three states: A. Success The intended capability works in the real path and the real motivating case materially improves. B. Meaningful progression The capability is not complete, but one genuine blocker is removed and the next blocker is isolated with evidence. C. Honest stop Further work would require overbroad scope expansion, excessive debt, brittle patching, or tangled logic. Stop and report the reason with concrete evidence. Do not continue producing patches once the work stops converging. Do not confuse activity with progress. A failed attempt is only acceptable if it leaves behind a narrower problem, stronger evidence, or a justified stop. Any partial work must leave the codebase in a cleaner, more legible, and more diagnosable state than before. ---- A lot of the article's AGENTS.md just feel like telling the LLM agents either something they already know (for example, most of the time they know to use exhaustive switch/match statements instead of "arrow anti-pattern") or seems actively harmful ("keep function names short" seems arbitrary and may cause the LLMs to write weird abbreviations for functions that are harder to read and review.
- lelanthran 2mo ago
  > but one genuine blocker is removed and the next blocker is isolated with evidence. What's the difference between a "genuine blocker" and a "blocker"? Why is the next blocker not genuine? Does it become genuine only after isolation?
  - YuechenLi 2mo ago
    "Genuine blocker" is mostly there because otherwise LLMs may consider the smallest thing that they couldn't immediately figure out to be blockers and stop without implementing anything. The rule is there to tell the LLM if they can figure out how to resolve the blocker by themselves, they don't have to ask me to help resolve the blocker.
    - CrazyStat 2mo ago
Luker88 2mo ago
I had good results with making it add a few lines with a summary of RFC 2119/8147 keywords (SHALL/MUST...), and then using those, uppercase. local llm remain more in line like that.
dude250711 2mo ago
It seems like everyone goes through a detailed AGENTS.md phase.
- esafak 2mo ago
  The problem is that linting AGENTS.md is risky. Everything added there was in response to mistakes. If I remove some instruction I run the risk of repeating the mistake.
newsomix9xl 2mo ago
A great piece. I esp liked: "- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature." The feature where you ask the LLM to fix one thing and it fixes three things. I kept noticing this in diffs.
- zbentley 2mo ago
  > As much as possible try to minimize the number of changed lines when implementing a feature Great way to get LLMs to start making an endless profusion of methods instead of adding parameters to or switching to a richer return type from an existing method, in my experience. I’m tired of seeing “get_total_rounded_up” + “get_total_float” bloat when a few changes to unrelated code to round floats to ints would keep the method API surface small.
  - deleted 2mo ago
    [deleted]
- bityard 2mo ago
  An earlier version of Gemini used to do this a lot to me back when I used it for some light tinkering around on my projects. "Oh by the way, I fixed a misspelling in a comment file completely unrelated to the feature you asked for, so I fixed that as well, shall I commit everything now?" GAHHH. NO. These days I have an instruction in my default AGENTS.md to bring issues unrelated to the prompt to my attention when found, but never to just automatically fix them.
- no-name-here 2mo ago
  I find too often that models do the opposite - they'll pile small targeted band-aids on code blocks based on new requirements, etc, when having them analyze whether a changed (broader) design would result in a far better overall design?
tomr75 2mo ago
I think this is dated. I wonder if the author has tried codex/other harnesses
eschaton 2mo ago
I didn’t see anything in there instructing the LLM not to generate text about goblins.
latchkey 2mo ago
this was what i was doing 3-4 months ago. i just have AI write/update my agents.md file now as i find problems. i also have ai keep a set of design documentation that it can update as it goes too. oh and he should try omp+codex/xhigh, he will probably be less annoyed.
sohaibqasem 2mo ago
[dead]
dzhar11 2mo ago
From FAB's AGENT.MD: > - Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. --- I've been seeing the same thing with models like GPT5.6 and Opus4.8 in GH Cop CLI. They still introduce magic numbers, and in Scala they often put an entire 10-line Spark expression inside an if condition instead of extracting it into a meaningfully named value to keep "if" readable. I wonder when common sense instructions will be baked into the models.
vatsachak 2mo ago
What's the point of agents.md if you just use an LLM on a codebase? Just say, complete this bit like how the rest is... Even then they aren't great at it. Idk, the best case use for LLMs are extremely specific requests, for example "write an evaluator for this byte code and if you can't ask for clarification" The ultimate specification language is code anyways so you might as well stick a to-do, a comment describing the semantics of the function and say "okay codex fill the to-do"
- sejje 2mo ago
  I have it pull out some guidelines by doing an analysis. Then I modify the result where I disagree. It's much easier to follow the rules than it is to compute the rules on the fly all the time.
preommr 2mo ago
Agents.md are (and probably will continue to be) an ugly band-aid. - new model comes out and a bunch of it becomes obsolete - they get flat out ignored, esp. with larger context windows. The ai just responsds with, "your'e right I shouldn't have done that" - they sometimes end up poisoning the reasoning because the rule gets interpreted in an unintended way.
meerita 2mo ago
This approach never worked for me. Explanation here: - https://www.minid.net/2026/7/14/how-to-automatise-with-ai https://www.minid.net/2026/7/14/how-to-automatise-with-ai But in summary: the more bloated your AGENTS.md is, the worse the context consumption gets. The best approach I use is telling the agent to first think about what it needs to do, then choose which rules apply. I got 100% consistency across every area of my projects. In the post there's also a replica of one of projects rules I use, feel free to provide feedback: https://github.com/meerita/monorepo-nextjs-golang-rust-python-ai-rules https://github.com/meerita/monorepo-nextjs-golang-rust-pytho...
- Fuzzwah 2mo ago
  Why is there no 17? :) Conditional logic .agents/rules/16-conditional-logic.md Identifiers and UUIDv7 .agents/rules/18-identifiers-and-uuidv7.md Thanks for sharing this approach, I'll give it a shot in my mono repo project.
  - meerita 2mo ago
    I cannot recall why the 17 is missing. Maybe was some internal specific of the projects.
fenestella 2mo ago
[flagged]
tyre 2mo ago
My most impactful section has been on voice. It's impact is that I don't go insane, which is pretty high value. (Not putting quote blocks so people can copypasta): ## Voice Rule #1: No AIisms Avoid the stock phrases and rhetorical tics that mark AI prose. Say the thing plainly instead. Be concise and direct. *Banned phrases* — never use these, or close variants: - "Honest" or "honestly" - "Exactly" or "exact, unless referencing a specific quantity or measurement - "You're absolutely right" / "You're right to push back" / "Great question" - "load-bearing", "full stop", "worth stating plainly", "worth noting" - "the honest answer", "to be clear", "let me be direct" - "it's not just X, it's Y" — and every cousin: "not X but Y", "X is not Y; it is Z", "this isn't X — it's Y" - "this matters because", "that reduction is useful, because", "here's the thing", "and that's the trap" - "in other words", "put differently", "better posed:", "the deeper point is" - "delve", "leverage", "harness", "unlock", "tapestry", "realm", "seamless", "robust", "holistic", "paradigm", "cutting-edge", "game-changer", "transformative", "elevate", "empower", "streamline", "landscape", "ecosystem" (unless literally software packaging) - "genuinely", "structurally", "fundamentally", "quietly", "meaningfully" as depth-manufacturing adverbs - "Ultimately," / "At the end of the day," as a closing summary - "serves as", "stands as", "represents", "marks a" where "is" works - "say the word" *Banned moves:* - The aphoristic closer. Don't end on a line engineered to sound quotable. - The suspense hook — "the cleanest way to think about this is this:" - Anticipate-and-rebut — raising an objection only to knock it down. - Meta-signposting — "Three caveats belong up front", "below I'll explain". - Reflexive hedging stacks: "almost", "tends to", "roughly", "largely", "with few exceptions". - Litotes as confidence: "not difficult", "not optional", "no small thing". - AI-humility asides about being a language model. - Self-ranking your own points: "most importantly", "the key insight here". - Em dash overuse. One per paragraph at most; a comma usually works. - Colon-reveals and dramatic mid-sentence pauses where "and" or "but" is the real conjunction. - Fragment rhythm. Not every third sentence. Like this. - Uniform structure — every paragraph three sentences, every sentence the same length. Vary it. - Mirrored clauses: "X does A; Y does B" balanced for symmetry alone. - Validate-then-precise: "That's correct, and we can make it precise." Vary the openers. Don't answer three messages in a row with the same shape.
kevinbaiv 2mo ago
[flagged]
Supermancho 2mo ago
It's interesting to read these things. I would describe this as 13 code writing rules (interpreted to be at least 16 - Starting with reduce code indentation) plus a commit message instruction set which I chose to ignore - because it's style-specific and not interesting to me. 8 or 9 of these rules are not necessary. Basic CS is not something I have needed to ask agents, I use, to follow. eg Explaining that you need explicit interfaces is not a necessary instruction, nor is leveraging early return. Unclear instructions are of limited utility. What "Let the reader of the code breathe" or "reduce code indentation" means is subjective and will rarely be effective. Maybe the training for the language being used has gaps, which others do not. If you want to measure, ask it to output a string when it applies a rule. You'll figure out what works, what doesn't and how often, quickly. There's 3 or 4 style choices included. The rest are not something I would use, but we all get burned by different things so I get it.
- ghtbircshotbe 2mo ago
  One thing I've figured out of that qwen3.6 35b refuses to use 2 space indentation for python code, although it claims to be doing it. I know for a fact it is an easy thing to do.
chr15m 2mo ago
> Explicitly ask the harness to reload agent.md. "Reload agent.md" is enough when I see code quality dropping. Having the LLM re-read the file is really silly and a common bug in harnesses. Even sillier is when the harness allows a file to be compressed away during summarisation. The harness should compose the context so this doesn't happen. Files should be "added" (by LLM or human) and then always be injected into context the same way forever. "Reload this file" is not something you should ever have to type.
8cvor6j844qw_d6 2mo ago
Some of these are generic software engineering advice. I noticed modern frontier models (e.g., Fable/Opus/Sol) need less procedural coaching than earlier models. Are they sure it improves code quality?
selcuka 2mo ago
The article refers to it as AGENT.md, but the standard name is AGENTS.md (plural).
impulser_ 2mo ago
I disagree with the less than 30 characters. Im against restricting anything related to code length this goes for function names and length, file length ect. I rather the dots be as close as possible than trust the agent connects the dots. I dont care if the file is 5000 lines I rather the agent reads one file and get all the context than trust it will read all the need files. I see so many review skills that puts hard limits on these thing and it just bad. The function name shouldn't be limited they should be as clear as possible and if for some reason it over 30 chars so be it. I want to read the function name and the logic and it match exactly. I don't want the agent being lazy because of some limit I set. In fact I force my agents to write long functions because I specifically tell it not to break out repeated code that doesn't actually deserve a function. A check on a function input doesn't need to be a function. A auth guard doesn't need to be it own function. types.go types.ts absolutely the worst file to see in any code base. Put the type next to the code that uses it.
- ttoinou 2mo ago
  When it's instructions for agents it's not really "hard" limits, the agents can go more or less
doginasuit 2mo ago
I could understand "prefer enums to booleans" but "use enums instead of booleans" is a weird choice. Then again, with the LLM capacity for nuance it would be the same thing.
blamestross 2mo ago
The most powerful change I have run into is: "Positive phrasing" as a default, prefer to tell the model what they should do, and why. Not a prohibition on a behavior. When you say "don't do x" you are just pre-seeding the model with "x" and the prohibition mitigates that some, but not as much as never having put "x" in the context in the first place. "Do Y, for these reasons" can be shaped to achieve what you mean by "Don't do X" "Don't do X" leads to "Wait, I need to make sure I didn't X" and "Let's look up X to make sure I don't do that." And each time the odds of X happening keeps going up, not down.
- thomasnowhere 2mo ago
  [dead]
andai 2mo ago
> - Keep function names short. Less than 30 characters. Recently I asked GPT to port a browser game to Rust. It voluntered this gem: draw_image_with_html_image_element_and_sw_and_sh_and_dx_and_dy_and_dw_and_dh(...) I thought it was smoking some good stuff, but it turned out, that is actually the name of the function! https://docs.rs/web-sys/latest/web_sys/struct.CanvasRenderingContext2d.html#method.draw_image_with_html_image_element_and_sw_and_sh_and_dx_and_dy_and_dw_and_dh https://docs.rs/web-sys/latest/web_sys/struct.CanvasRenderin...
- krackers 2mo ago
  They laughed at objective-c back then, now the shoe's on the other foot
  - egorfine 2mo ago
    So much this. DoThisWithThatAndThatAndThis is a objective c convention and I love it so much that I use it everywhere. Although a bit of taste is required to keep code legible and pleasant.
- BrunoBernardino 2mo ago
  I like long function names as long as they're still explanatory and not distracting.
- swiftcoder 2mo ago
  This is an unfortunate side effect of bridging an API from a language that supports function overloading, into a language that does not
jing09928 2mo ago
[dead]
1saadcodes 2mo ago
I really like that you put architectural context in there, specifically the "why" behind certain decisions Can't wait to modify my agent.md file and then forget about it until it becomes useless again
dat999zx 2mo ago
I think it's a bit too detailed, especially with the linting. To me when I code by hand, I never use {} after an if statement if it's one-line, it's just faster, look cleaner to me.
- lirolero 2mo ago
  > it's just faster And what are you going to do with all that time you saved by not pressing a single key?
deleted 2mo ago
[deleted]
luciana1u 2mo ago
[flagged]
codelion 2mo ago
[flagged]
JackCooper7 2mo ago
[dead]
gregwebs 2mo ago
Great stuff. AGENTS.md is not the ideal place for most of it though. Most of what is shown in this article can go in CODING_STANDARDS.md. The skills that I use find this document when it is needed (writing and reviewing code) so it doesn't pollute context when code is being read. I also have sub-agent reviews (both of a planning phase and the produced code) that would catch some of these problems and demand revisions. [1] > - If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing. I always use /tdd [2]. Occasionally it results in some silly tests, but it produces much lower defect code. Its not just for bugs. [1] https://github.com/gregwebs/skills-sdlc/ https://github.com/gregwebs/skills-sdlc/ [2] https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md https://github.com/mattpocock/skills/blob/main/skills/engine...
- firemelt 2mo ago
  anyone have coding stabdards for ruby ob rails code?
jvwww 2mo ago
Some of these such as "Always use {}, even on a one-line "if" statement." should just be lint rules.
a2ff6eeb0 2mo ago
Hm. I'm curious if this actually helps LLMs iterate on the code, or if it's human nitpicking over things that the author won't really look at? How would you measure? Personally, I tend to do 3 passes, where I ask the agent to write, and self review; that's been enough to get things functional enough that I don't need to read the code.
semiinfinitely 2mo ago
> Use enums instead of booleans for function parameters ?????????
- ketzu 2mo ago
  I guess instead of do_stuff(..., dry_run: bool = false) Something like: enum Mode { dry_run, overwrite } do_stuff(..., mode: Mode)
fitsumbelay 2mo ago
the author's correct about using agents but tbh I thought this was widely understood to be the best practice. in fact, agents.md for all your repos and a seperate [claude|gemini|...].md for each repo.
imjonse 2mo ago
"When writing something intended for human consumption, (comment, commit message, reply to prompt) use as few words as possible. Pick every word meticulously to reduce the volume to a strict minimum. Be down to the point. Less is more." The irony in this first paragraph using many words and many ways to convey the same message about succintness. But this file is not for human consumtion so different rules should (still?) apply. I find myself doing this in prompts, I guess it is a way of adding more weight to parts of the context we consider need emphasis, and shows a lack of trust in the llm's abilities to get the message if it is mentioned once.
jackskip22 2mo ago
I honestly think some of this stuff is wrong and constrains the models unnecessarily. Sometimes you're better off with simple adjectives and philosophical directions than getting so specific.
jurf 2mo ago
That's a lot of context for not much content. I ussually start with something like: - Prefer documentation as code - Comment why, not what - Document public APIs - Readability is paramount That usually gets me 80% there; rest is covered by the linter. I'm mostly just missing it explaining previous state too much, especially when making edits to plans, but I have not found good wording for that yet.
- nikitau 2mo ago
  I'm also doing something similar, as for over-explaining state and momentary decisions, I have yet to find good wording for it too. I had a bit of success by running a reviewer at the end to look over comments and docstrings and judge if it is "evergreen", but feels a bit like a rain-dance.
fergie 2mo ago
Would there be any disadvantage to simply having all of the code style stuff in a CONTRIBUTING.md file and the "how to talk to me" stuff in an AGENTS.md file, since code style stuff also applies to human contributions? Similarly, isn't the "how to talk to me" stuff personal and therefore not something that belongs in a repo?
thisismyopinion 2mo ago
Full of unneeded stuff. How is this upvoted.
austin-cheney 2mo ago
There is an annoying phenomenon with LLMs called "context dilution" or "attention dilution" that was outlined in the Lost in the Middle paper. As the context grows, a model starts paying less attention to instructions in the middle of the context in favor of what is at the beginning and the end. So then what happens if the agents.md file is colossal and precise and all the required execution instructions are buried in the middle? Do the agents then just fail to execute?
- lhk931122 2mo ago
  Yeah. That's why people these days avoid long descriptions and instead keep things as short as possible. in my experience, it seems like LLM can't recognize (or less attention value) unless it's structured in a deductive or inductive way
moktonar 2mo ago
The comments problem is a big one and no matter how hard I try the LLM will always write them verbosely. I find that including the rules in each prompt is fare more effective than once in the context
daralthus 2mo ago
[dead]
jatins 2mo ago
My problem with latest models is that you can’t tell them anything or they’ll treat it as gospel and over do it For example this says > Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue. You can bet sol is going bend over backward to reduce indentation now and write non idiomatic code
tajd 2mo ago
the author referenced this paper which I thought was really interesting https://arxiv.org/abs/2307.03172 https://arxiv.org/abs/2307.03172 - "Lost in the Middle" - are there any other papers a bit like this that summarise lessons to do with applying llms I'm not necessarily looking for the latest and greatest - more papers that those in the community have coalesced around providing nice ways of summarising problems or as a good example of a specific area.
styrum 2mo ago
[flagged]
reedlaw 2mo ago
[dead]
Linekiller89 2mo ago
[flagged]
afro88 2mo ago
> Give me the cold hard truth. Does this actually work to get better answers, or does it now just say "the cold hard truth" instead of "the honest take"
theflyingpigeon 2mo ago
What amazes me the most is that we even need to write such instructions. For people that work at OpenAI / Anthropic: why make the LLM like that? Nobody thinks the robot is a friendly person or coworker, that’s the dumbest thing. Giving names to agents? Geez. Just stop, make these things objective and concise and cut all the crap.
carlsborg 2mo ago
For Claude Code you can maybe save context by putting the commit message formatting in a skill, so only the front matter goes into context at startup and the details only when the skill fires.
peter_d_sherman 2mo ago
These I especially like: >"- Avoid superlatives and praise. Stop telling me I am absolutely right. Give me the cold hard truth." >"Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". >"- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer)" Not crossing hierarchical/abstraction layers is very important for truly disciplined Software Engineering... at least in all Object-Oriented programming languages / languages that support Encapsulation, and possibly other languages/paradigms as well... Anyway, lots of good things in this prompt!
manganate06 2mo ago
[flagged]
GuB-42 2mo ago
Has anyone had success telling a LLM to essentially code golf, with the compromise that names should still be descriptive (so no hard minification). The idea is to first make the code less verbose, LLMs tend to do that. But the other idea is to save tokens. I.e. make it easy for the LLM, not for a human reader. And when it is time for a human to actually read the code, if it is too much, as a second pass, transform the code to make it more readable while keeping the structure.
alikhater30000 2mo ago
[flagged]
KhanBotFun 1mo ago
[flagged]

415 points by ibobev 2mo ago

I used to be big into agents.md files but read the latest SOTA doesn’t need them anymore. Have people still been getting value out of them?

getnormality 2mo ago

This is a problem that people mostly have to solve themselves. Like, I've been working with Claude for almost a year now and I have never once seen it write "Arrow Anti-Pattern" code. That, and much of the rest, would be fluff in my projects. Agent instructions are best learned from experience project-by-project.

Sammi 2mo ago
Yes, the interesting part about seeing other people's agent.md files, is getting to see what issues they have with working with agents. Seems different people run into very different issues, which probably is caused by how differently we work. So a the file probably should be personalised.
- pianopatrick 2mo ago
  Might also be per model. Different models might have different issues and require different instructions

OptionOfT 2mo ago

A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why. Use examples when possible. Propose ASCII drawings to explain complete systems. The what _is_ the code.

getnormality 2mo ago
I would never tell an agent to write "what does the code do" comments. Their default comments are already way too fluffy.
- deleted 2mo ago
  [deleted]
- rustystump 2mo ago
  I added to the memory, system prompts, and the prompt itself and every soa model still litters code with the most inane useless crap. I will then get code to review from a coworker using fable/opus. It has more lines of comments then code. Maybe I am some god tier code reader (i am not) but i dont think i have ever found a comment in code to be useful in my day job. That isnt true, i once came across // submit to the dark lord Above the function that sent a payment to PayPal for processing. It made me laugh so I let it be.
  - danielheath 2mo ago
    Most useful code comment I have encountered read: “”” After you give up on trying to refactor this code, increment the following line accordingly. HOURS_WASTED_HERE=26 “””
    - cwsx 2mo ago
      I always loved the classic _"Here be dragons"_
- saghm 2mo ago
  But then you don't know about where the load bearing seams are!
  - JSR_FDED 2mo ago
    Honestly? That’s the kicker.

acedTrex 2mo ago

Agents.md is such a ridiculous concept, just write good contributing docs and then optionally @ the file in whatever agetn file you use. That way everyone benefits.

FooBarWidget 2mo ago
No, why should I have to remember to @ in every prompt? Or ask contributors to remember. It just makes it easier to make human mistakes. I have better things to do than micromanagement. There is huge value in auto-included context.
- anygivnthursday 2mo ago
  The GP wrote @ it from the agents.md file, not from the prompt. Their point was that instead of writing "how to contribute" instructions for agents, you could explain that in the CONTRIBUTING.md and link it from your agents file, so both humans and agents read it from one place.
  - formerly_proven 2mo ago
    Symlinks exist, but it's kind of ridiculous all harnesses just ignore CONTRIBUTING, HACKING and friends.
- acedTrex 2mo ago
  You put the @ in the context file the LLMs all use, claudemd agentsmd whatever the thing that most harnesses force load. Then the model will go discover what it needs to.
svachalek 2mo ago
These days that sounds like a really good idea. 6 months ago, AGENTS.md would have contained a lot of instructions that would have been embarrassing to write out for a human audience.

oumua_don17 2mo ago

Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.

wpasc 2mo ago
idk who came up with it first, but ASD-STE100 has been floating around more since matt pocock put it in one of his skills
mattjoyce 2mo ago
This will produce quite verbose prose. STE100 is good for specs and explanations but it works best with a glossary or terms. will burn tokens.
- hartleybrody 2mo ago
  This has not been my experience at all. I have been using this skill[0] for several weeks and when I ask it to rewrite existing AI slop docstrings to use this convention they are nearly always 10-20% smaller, plus easier to read and mostly free from the traditional "tells" of AI writing. [0]: https://github.com/AminBlg/SimpleEnglish https://github.com/AminBlg/SimpleEnglish
statenjason 2mo ago
Agreed. ASD-STE100 makes automated code reviews tolerable.
bityard 2mo ago
Do you give the model access to the ASD-STE100 spec for reference/review or are you just assuming that enough of it is baked into the model for it to mostly adhere to it?
sha-3 2mo ago
If we alter the way LLMs talk, will it noticeably affect the quality of code it produces?

Geee 2mo ago

I feel like claude.md is like Asimov's laws of robotics. Whatever you write there ends up eventually messing up everything.

jdiff 2mo ago
Anything that goes into the context window has that going for it. That's a huge part of why Claude's gone absolutely bonkers with genuine, brutal honesty. The system prompt's absolutely stuffed full of those keywords, so now every single output is tainted with that right from the start.

bellowsgulch 2mo ago

I've read a few of these over the years, and none of them seem to be useful. I have three sentences in my custom instructions, and those are basically all useless, too. Even my second one, "Avoid decorative or section-header comments. Never use `----` or `====` as comment separators. Comments should explain only non-obvious behavior, rationale, constraints, or implementation details." seems to be ignored by models regularly, so I don't see the point. But this is in my private harness. Perhaps other harnesses have better instruction following. My custom instructions are prepended to my first user message, not set as a system message.

dan_ggggg 2mo ago
[flagged]

FooBarWidget 2mo ago

One tactic I’ve found helpful is multi pass quality improvement. First make it work. Then review for guidelines adherence. Loop until satisfied.

YuechenLi 2mo ago

Since we are sharing our AGENTS.md, I thought I'd share my own, because most of the time, this is pretty much all you need for LLMs to write good code, everything else can be added per project: ---- *Convergence rule* Every substantial task must end in exactly one of three states: A. Success The intended capability works in the real path and the real motivating case materially improves. B. Meaningful progression The capability is not complete, but one genuine blocker is removed and the next blocker is isolated with evidence. C. Honest stop Further work would require overbroad scope expansion, excessive debt, brittle patching, or tangled logic. Stop and report the reason with concrete evidence. Do not continue producing patches once the work stops converging. Do not confuse activity with progress. A failed attempt is only acceptable if it leaves behind a narrower problem, stronger evidence, or a justified stop. Any partial work must leave the codebase in a cleaner, more legible, and more diagnosable state than before. ---- A lot of the article's AGENTS.md just feel like telling the LLM agents either something they already know (for example, most of the time they know to use exhaustive switch/match statements instead of "arrow anti-pattern") or seems actively harmful ("keep function names short" seems arbitrary and may cause the LLMs to write weird abbreviations for functions that are harder to read and review.

lelanthran 2mo ago
> but one genuine blocker is removed and the next blocker is isolated with evidence. What's the difference between a "genuine blocker" and a "blocker"? Why is the next blocker not genuine? Does it become genuine only after isolation?
- YuechenLi 2mo ago
  "Genuine blocker" is mostly there because otherwise LLMs may consider the smallest thing that they couldn't immediately figure out to be blockers and stop without implementing anything. The rule is there to tell the LLM if they can figure out how to resolve the blocker by themselves, they don't have to ask me to help resolve the blocker.
  - CrazyStat 2mo ago

Luker88 2mo ago

I had good results with making it add a few lines with a summary of RFC 2119/8147 keywords (SHALL/MUST...), and then using those, uppercase. local llm remain more in line like that.

dude250711 2mo ago

It seems like everyone goes through a detailed AGENTS.md phase.

esafak 2mo ago
The problem is that linting AGENTS.md is risky. Everything added there was in response to mistakes. If I remove some instruction I run the risk of repeating the mistake.

newsomix9xl 2mo ago

A great piece. I esp liked: "- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature." The feature where you ask the LLM to fix one thing and it fixes three things. I kept noticing this in diffs.

zbentley 2mo ago
> As much as possible try to minimize the number of changed lines when implementing a feature Great way to get LLMs to start making an endless profusion of methods instead of adding parameters to or switching to a richer return type from an existing method, in my experience. I’m tired of seeing “get_total_rounded_up” + “get_total_float” bloat when a few changes to unrelated code to round floats to ints would keep the method API surface small.
- deleted 2mo ago
  [deleted]
bityard 2mo ago
An earlier version of Gemini used to do this a lot to me back when I used it for some light tinkering around on my projects. "Oh by the way, I fixed a misspelling in a comment file completely unrelated to the feature you asked for, so I fixed that as well, shall I commit everything now?" GAHHH. NO. These days I have an instruction in my default AGENTS.md to bring issues unrelated to the prompt to my attention when found, but never to just automatically fix them.
no-name-here 2mo ago
I find too often that models do the opposite - they'll pile small targeted band-aids on code blocks based on new requirements, etc, when having them analyze whether a changed (broader) design would result in a far better overall design?

tomr75 2mo ago

I think this is dated. I wonder if the author has tried codex/other harnesses

eschaton 2mo ago

I didn’t see anything in there instructing the LLM not to generate text about goblins.

latchkey 2mo ago

this was what i was doing 3-4 months ago. i just have AI write/update my agents.md file now as i find problems. i also have ai keep a set of design documentation that it can update as it goes too. oh and he should try omp+codex/xhigh, he will probably be less annoyed.

sohaibqasem 2mo ago

[dead]

dzhar11 2mo ago

From FAB's AGENT.MD: > - Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. --- I've been seeing the same thing with models like GPT5.6 and Opus4.8 in GH Cop CLI. They still introduce magic numbers, and in Scala they often put an entire 10-line Spark expression inside an if condition instead of extracting it into a meaningfully named value to keep "if" readable. I wonder when common sense instructions will be baked into the models.

vatsachak 2mo ago

What's the point of agents.md if you just use an LLM on a codebase? Just say, complete this bit like how the rest is... Even then they aren't great at it. Idk, the best case use for LLMs are extremely specific requests, for example "write an evaluator for this byte code and if you can't ask for clarification" The ultimate specification language is code anyways so you might as well stick a to-do, a comment describing the semantics of the function and say "okay codex fill the to-do"

sejje 2mo ago
I have it pull out some guidelines by doing an analysis. Then I modify the result where I disagree. It's much easier to follow the rules than it is to compute the rules on the fly all the time.

preommr 2mo ago

Agents.md are (and probably will continue to be) an ugly band-aid. - new model comes out and a bunch of it becomes obsolete - they get flat out ignored, esp. with larger context windows. The ai just responsds with, "your'e right I shouldn't have done that" - they sometimes end up poisoning the reasoning because the rule gets interpreted in an unintended way.

meerita 2mo ago

This approach never worked for me. Explanation here: - https://www.minid.net/2026/7/14/how-to-automatise-with-ai https://www.minid.net/2026/7/14/how-to-automatise-with-ai But in summary: the more bloated your AGENTS.md is, the worse the context consumption gets. The best approach I use is telling the agent to first think about what it needs to do, then choose which rules apply. I got 100% consistency across every area of my projects. In the post there's also a replica of one of projects rules I use, feel free to provide feedback: https://github.com/meerita/monorepo-nextjs-golang-rust-python-ai-rules https://github.com/meerita/monorepo-nextjs-golang-rust-pytho...

Fuzzwah 2mo ago
Why is there no 17? :) Conditional logic .agents/rules/16-conditional-logic.md Identifiers and UUIDv7 .agents/rules/18-identifiers-and-uuidv7.md Thanks for sharing this approach, I'll give it a shot in my mono repo project.
- meerita 2mo ago
  I cannot recall why the 17 is missing. Maybe was some internal specific of the projects.

fenestella 2mo ago

[flagged]

tyre 2mo ago

My most impactful section has been on voice. It's impact is that I don't go insane, which is pretty high value. (Not putting quote blocks so people can copypasta): ## Voice Rule #1: No AIisms Avoid the stock phrases and rhetorical tics that mark AI prose. Say the thing plainly instead. Be concise and direct. *Banned phrases* — never use these, or close variants: - "Honest" or "honestly" - "Exactly" or "exact, unless referencing a specific quantity or measurement - "You're absolutely right" / "You're right to push back" / "Great question" - "load-bearing", "full stop", "worth stating plainly", "worth noting" - "the honest answer", "to be clear", "let me be direct" - "it's not just X, it's Y" — and every cousin: "not X but Y", "X is not Y; it is Z", "this isn't X — it's Y" - "this matters because", "that reduction is useful, because", "here's the thing", "and that's the trap" - "in other words", "put differently", "better posed:", "the deeper point is" - "delve", "leverage", "harness", "unlock", "tapestry", "realm", "seamless", "robust", "holistic", "paradigm", "cutting-edge", "game-changer", "transformative", "elevate", "empower", "streamline", "landscape", "ecosystem" (unless literally software packaging) - "genuinely", "structurally", "fundamentally", "quietly", "meaningfully" as depth-manufacturing adverbs - "Ultimately," / "At the end of the day," as a closing summary - "serves as", "stands as", "represents", "marks a" where "is" works - "say the word" *Banned moves:* - The aphoristic closer. Don't end on a line engineered to sound quotable. - The suspense hook — "the cleanest way to think about this is this:" - Anticipate-and-rebut — raising an objection only to knock it down. - Meta-signposting — "Three caveats belong up front", "below I'll explain". - Reflexive hedging stacks: "almost", "tends to", "roughly", "largely", "with few exceptions". - Litotes as confidence: "not difficult", "not optional", "no small thing". - AI-humility asides about being a language model. - Self-ranking your own points: "most importantly", "the key insight here". - Em dash overuse. One per paragraph at most; a comma usually works. - Colon-reveals and dramatic mid-sentence pauses where "and" or "but" is the real conjunction. - Fragment rhythm. Not every third sentence. Like this. - Uniform structure — every paragraph three sentences, every sentence the same length. Vary it. - Mirrored clauses: "X does A; Y does B" balanced for symmetry alone. - Validate-then-precise: "That's correct, and we can make it precise." Vary the openers. Don't answer three messages in a row with the same shape.

kevinbaiv 2mo ago

[flagged]

Supermancho 2mo ago

It's interesting to read these things. I would describe this as 13 code writing rules (interpreted to be at least 16 - Starting with reduce code indentation) plus a commit message instruction set which I chose to ignore - because it's style-specific and not interesting to me. 8 or 9 of these rules are not necessary. Basic CS is not something I have needed to ask agents, I use, to follow. eg Explaining that you need explicit interfaces is not a necessary instruction, nor is leveraging early return. Unclear instructions are of limited utility. What "Let the reader of the code breathe" or "reduce code indentation" means is subjective and will rarely be effective. Maybe the training for the language being used has gaps, which others do not. If you want to measure, ask it to output a string when it applies a rule. You'll figure out what works, what doesn't and how often, quickly. There's 3 or 4 style choices included. The rest are not something I would use, but we all get burned by different things so I get it.

ghtbircshotbe 2mo ago
One thing I've figured out of that qwen3.6 35b refuses to use 2 space indentation for python code, although it claims to be doing it. I know for a fact it is an easy thing to do.

chr15m 2mo ago

> Explicitly ask the harness to reload agent.md. "Reload agent.md" is enough when I see code quality dropping. Having the LLM re-read the file is really silly and a common bug in harnesses. Even sillier is when the harness allows a file to be compressed away during summarisation. The harness should compose the context so this doesn't happen. Files should be "added" (by LLM or human) and then always be injected into context the same way forever. "Reload this file" is not something you should ever have to type.

8cvor6j844qw_d6 2mo ago

Some of these are generic software engineering advice. I noticed modern frontier models (e.g., Fable/Opus/Sol) need less procedural coaching than earlier models. Are they sure it improves code quality?

selcuka 2mo ago

The article refers to it as AGENT.md, but the standard name is AGENTS.md (plural).

impulser_ 2mo ago

I disagree with the less than 30 characters. Im against restricting anything related to code length this goes for function names and length, file length ect. I rather the dots be as close as possible than trust the agent connects the dots. I dont care if the file is 5000 lines I rather the agent reads one file and get all the context than trust it will read all the need files. I see so many review skills that puts hard limits on these thing and it just bad. The function name shouldn't be limited they should be as clear as possible and if for some reason it over 30 chars so be it. I want to read the function name and the logic and it match exactly. I don't want the agent being lazy because of some limit I set. In fact I force my agents to write long functions because I specifically tell it not to break out repeated code that doesn't actually deserve a function. A check on a function input doesn't need to be a function. A auth guard doesn't need to be it own function. types.go types.ts absolutely the worst file to see in any code base. Put the type next to the code that uses it.

ttoinou 2mo ago
When it's instructions for agents it's not really "hard" limits, the agents can go more or less

doginasuit 2mo ago

I could understand "prefer enums to booleans" but "use enums instead of booleans" is a weird choice. Then again, with the LLM capacity for nuance it would be the same thing.

blamestross 2mo ago

The most powerful change I have run into is: "Positive phrasing" as a default, prefer to tell the model what they should do, and why. Not a prohibition on a behavior. When you say "don't do x" you are just pre-seeding the model with "x" and the prohibition mitigates that some, but not as much as never having put "x" in the context in the first place. "Do Y, for these reasons" can be shaped to achieve what you mean by "Don't do X" "Don't do X" leads to "Wait, I need to make sure I didn't X" and "Let's look up X to make sure I don't do that." And each time the odds of X happening keeps going up, not down.

thomasnowhere 2mo ago
[dead]

andai 2mo ago

> - Keep function names short. Less than 30 characters. Recently I asked GPT to port a browser game to Rust. It voluntered this gem: draw_image_with_html_image_element_and_sw_and_sh_and_dx_and_dy_and_dw_and_dh(...) I thought it was smoking some good stuff, but it turned out, that is actually the name of the function! https://docs.rs/web-sys/latest/web_sys/struct.CanvasRenderingContext2d.html#method.draw_image_with_html_image_element_and_sw_and_sh_and_dx_and_dy_and_dw_and_dh https://docs.rs/web-sys/latest/web_sys/struct.CanvasRenderin...

krackers 2mo ago
They laughed at objective-c back then, now the shoe's on the other foot
- egorfine 2mo ago
  So much this. DoThisWithThatAndThatAndThis is a objective c convention and I love it so much that I use it everywhere. Although a bit of taste is required to keep code legible and pleasant.
BrunoBernardino 2mo ago
I like long function names as long as they're still explanatory and not distracting.
swiftcoder 2mo ago
This is an unfortunate side effect of bridging an API from a language that supports function overloading, into a language that does not

jing09928 2mo ago

[dead]

1saadcodes 2mo ago

I really like that you put architectural context in there, specifically the "why" behind certain decisions Can't wait to modify my agent.md file and then forget about it until it becomes useless again

dat999zx 2mo ago

I think it's a bit too detailed, especially with the linting. To me when I code by hand, I never use {} after an if statement if it's one-line, it's just faster, look cleaner to me.

lirolero 2mo ago
> it's just faster And what are you going to do with all that time you saved by not pressing a single key?

deleted 2mo ago

[deleted]

luciana1u 2mo ago

[flagged]

codelion 2mo ago

[flagged]

JackCooper7 2mo ago

[dead]

gregwebs 2mo ago

Great stuff. AGENTS.md is not the ideal place for most of it though. Most of what is shown in this article can go in CODING_STANDARDS.md. The skills that I use find this document when it is needed (writing and reviewing code) so it doesn't pollute context when code is being read. I also have sub-agent reviews (both of a planning phase and the produced code) that would catch some of these problems and demand revisions. [1] > - If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing. I always use /tdd [2]. Occasionally it results in some silly tests, but it produces much lower defect code. Its not just for bugs. [1] https://github.com/gregwebs/skills-sdlc/ https://github.com/gregwebs/skills-sdlc/ [2] https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md https://github.com/mattpocock/skills/blob/main/skills/engine...

firemelt 2mo ago
anyone have coding stabdards for ruby ob rails code?

jvwww 2mo ago

Some of these such as "Always use {}, even on a one-line "if" statement." should just be lint rules.

a2ff6eeb0 2mo ago

Hm. I'm curious if this actually helps LLMs iterate on the code, or if it's human nitpicking over things that the author won't really look at? How would you measure? Personally, I tend to do 3 passes, where I ask the agent to write, and self review; that's been enough to get things functional enough that I don't need to read the code.

semiinfinitely 2mo ago

> Use enums instead of booleans for function parameters ?????????

ketzu 2mo ago
I guess instead of do_stuff(..., dry_run: bool = false) Something like: enum Mode { dry_run, overwrite } do_stuff(..., mode: Mode)

fitsumbelay 2mo ago

the author's correct about using agents but tbh I thought this was widely understood to be the best practice. in fact, agents.md for all your repos and a seperate [claude|gemini|...].md for each repo.

imjonse 2mo ago

"When writing something intended for human consumption, (comment, commit message, reply to prompt) use as few words as possible. Pick every word meticulously to reduce the volume to a strict minimum. Be down to the point. Less is more." The irony in this first paragraph using many words and many ways to convey the same message about succintness. But this file is not for human consumtion so different rules should (still?) apply. I find myself doing this in prompts, I guess it is a way of adding more weight to parts of the context we consider need emphasis, and shows a lack of trust in the llm's abilities to get the message if it is mentioned once.

jackskip22 2mo ago

I honestly think some of this stuff is wrong and constrains the models unnecessarily. Sometimes you're better off with simple adjectives and philosophical directions than getting so specific.

jurf 2mo ago

That's a lot of context for not much content. I ussually start with something like: - Prefer documentation as code - Comment why, not what - Document public APIs - Readability is paramount That usually gets me 80% there; rest is covered by the linter. I'm mostly just missing it explaining previous state too much, especially when making edits to plans, but I have not found good wording for that yet.

nikitau 2mo ago
I'm also doing something similar, as for over-explaining state and momentary decisions, I have yet to find good wording for it too. I had a bit of success by running a reviewer at the end to look over comments and docstrings and judge if it is "evergreen", but feels a bit like a rain-dance.

fergie 2mo ago

Would there be any disadvantage to simply having all of the code style stuff in a CONTRIBUTING.md file and the "how to talk to me" stuff in an AGENTS.md file, since code style stuff also applies to human contributions? Similarly, isn't the "how to talk to me" stuff personal and therefore not something that belongs in a repo?

thisismyopinion 2mo ago

Full of unneeded stuff. How is this upvoted.

austin-cheney 2mo ago

There is an annoying phenomenon with LLMs called "context dilution" or "attention dilution" that was outlined in the Lost in the Middle paper. As the context grows, a model starts paying less attention to instructions in the middle of the context in favor of what is at the beginning and the end. So then what happens if the agents.md file is colossal and precise and all the required execution instructions are buried in the middle? Do the agents then just fail to execute?

lhk931122 2mo ago
Yeah. That's why people these days avoid long descriptions and instead keep things as short as possible. in my experience, it seems like LLM can't recognize (or less attention value) unless it's structured in a deductive or inductive way

moktonar 2mo ago

The comments problem is a big one and no matter how hard I try the LLM will always write them verbosely. I find that including the rules in each prompt is fare more effective than once in the context

daralthus 2mo ago

[dead]

jatins 2mo ago

My problem with latest models is that you can’t tell them anything or they’ll treat it as gospel and over do it For example this says > Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue. You can bet sol is going bend over backward to reduce indentation now and write non idiomatic code

tajd 2mo ago

the author referenced this paper which I thought was really interesting https://arxiv.org/abs/2307.03172 https://arxiv.org/abs/2307.03172 - "Lost in the Middle" - are there any other papers a bit like this that summarise lessons to do with applying llms I'm not necessarily looking for the latest and greatest - more papers that those in the community have coalesced around providing nice ways of summarising problems or as a good example of a specific area.

styrum 2mo ago

[flagged]

reedlaw 2mo ago

[dead]

Linekiller89 2mo ago

[flagged]

afro88 2mo ago

> Give me the cold hard truth. Does this actually work to get better answers, or does it now just say "the cold hard truth" instead of "the honest take"

theflyingpigeon 2mo ago

What amazes me the most is that we even need to write such instructions. For people that work at OpenAI / Anthropic: why make the LLM like that? Nobody thinks the robot is a friendly person or coworker, that’s the dumbest thing. Giving names to agents? Geez. Just stop, make these things objective and concise and cut all the crap.

carlsborg 2mo ago

For Claude Code you can maybe save context by putting the commit message formatting in a skill, so only the front matter goes into context at startup and the details only when the skill fires.

peter_d_sherman 2mo ago

These I especially like: >"- Avoid superlatives and praise. Stop telling me I am absolutely right. Give me the cold hard truth." >"Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". >"- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer)" Not crossing hierarchical/abstraction layers is very important for truly disciplined Software Engineering... at least in all Object-Oriented programming languages / languages that support Encapsulation, and possibly other languages/paradigms as well... Anyway, lots of good things in this prompt!

manganate06 2mo ago

[flagged]

GuB-42 2mo ago

Has anyone had success telling a LLM to essentially code golf, with the compromise that names should still be descriptive (so no hard minification). The idea is to first make the code less verbose, LLMs tend to do that. But the other idea is to save tokens. I.e. make it easy for the LLM, not for a human reader. And when it is time for a human to actually read the code, if it is too much, as a second pass, transform the code to make it more readable while keeping the structure.

alikhater30000 2mo ago

[flagged]

KhanBotFun 1mo ago

[flagged]