Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by dzhar11
  • 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.

    by bellowsgulch
  • This approach never worked for me. Explanation here:

    - 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-pytho...

    by meerita
  • 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.

    by Fuzzwah
  • I feel like claude.md is like Asimov's laws of robotics. Whatever you write there ends up eventually messing up everything.
    by Geee
  • 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.
    by jdiff
  • 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.

    by newsomix9xl
  • 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.

    by bityard
  • 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?
    by no-name-here
  • > 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.

    by zbentley
  • 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.

    by Supermancho
  • 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.
    by ghtbircshotbe
  • 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.

    by oumua_don17
  • If we alter the way LLMs talk, will it noticeably affect the quality of code it produces?
    by sha-3
  • Agreed. ASD-STE100 makes automated code reviews tolerable.
    by statenjason
  • 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?
    by bityard
  • 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.
    by mattjoyce
  • 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
    by wpasc
  • This is probably the skill you remembered: https://github.com/AminBlg/SimpleEnglish

    I have been using it for a few weeks, and it significantly improves the quality of the docstrings and code comments, as well as the readability of spec docs.

    I have also added a few key bullet points to my AGENTS.md and have found the results to be very effective and generating plans and code that looks like something I would have written:

    -----------

        ## planning, design and spec docs

    - the highest design goal is simplicity -- in our systems and our mental model -- even if if means edge cases are unaddressed and could potentially fail
    - please practice "ya ain't gunna need it" (YAGNI) do not add unnecessary guardrails
    - do not plan to add caching, many layers of unnecessary abstraction or other premature optimizations
    - look for places where adding or clarifying an invariant would simplify the code or the overall system

    please specifically try to avoid:

    - redundant calculations or duplicated work
    - duplicated conditionals or state-machine logic
    - storing state that can be derived from other state, which could drift and become out of sync over time
    - leaky abstractions across layers of the application
    - multi-line comments explaining a variable name or a single statement. well chosen names and design should makes these unnecessary, as the code is self-documenting
    by hartleybrody
  • 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/

    [2] https://github.com/mattpocock/skills/blob/main/skills/engine...

    by gregwebs
  • anyone have coding stabdards for ruby ob rails code?
    by firemelt
  • 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.
    by getnormality
  • 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.
    by Sammi
  • 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.

    by YuechenLi
  • How often would you say step C happens and the agent stops when it can’t proceed?
    by maccard
  • "honest", "real", "genuine" -- wat.
    by chrisweekly
  • > 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?

    by lelanthran
  • > - 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.CanvasRenderin...

    by andai
  • This is an unfortunate side effect of bridging an API from a language that supports function overloading, into a language that does not
    by swiftcoder
  • I like long function names as long as they're still explanatory and not distracting.
    by BrunoBernardino