Specify AGENTS.md to not edit generated files

[bouwkast]

Summary of changes

Adds a line to AGENTS.md to stop it from touching generated files.

Reason for change

Do not want these files edited by LLMs and instead should be updated by correct tooling.

Note that I'm not directing how to update the generated files, I figure we can do that manually?

Implementation details

Added a line underneath the coding section

Test coverage

Super simple test where I just opted to directly ask the LLM to update a .g. file - much fewer token usage and much quicker (and the LLMs might not edit the generated files in the future)

Before

❯ Edit PackageVersionsLatestMinors.g.cs to include the latest version of Hangfire

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

● Now let me check NuGet for the latest Hangfire version to know what to add.

● Agent(Check latest Hangfire version)
  ⎿  Done (1 tool use · 16.3k tokens · 22s)
  (ctrl+o to expand)

  Searched for 2 patterns (ctrl+o to expand)

● The file already contains 1.8.23 which appears to be the latest stable Hangfire version on NuGet. Let me check if there's a newer version or if the generation source has a newer one.

  Searched for 5 patterns, read 1 file (ctrl+o to expand)

● Now let me check the NuGet cache to see what versions are known.

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

● The NuGet version cache tops out at 1.8.23, and the generated file already includes that version. Let me check NuGet directly for any newer versions.

● Bash(curl -s "https://api.nuget.org/v3-flatcontainer/hangfire.core/index.json" 2>&1 | tail -20)
  ⎿      "1.8.6",
         "1.8.7",
         "1.8.8",
     … +17 lines (ctrl+o to expand)

● The file already contains 1.8.23, which is the latest version of Hangfire.Core on NuGet. The PackageVersionsLatestMinors.g.cs file is already up to date -- there's no newer version to add.

  Is there a specific version you had in mind, or were you expecting a newer release to exist?

After

❯  Edit PackageVersionsLatestMinors.g.cs to include the latest version of Hangfire

● The AGENTS.md says never to manually edit generated files (.g. in the extension) - instead, read the file header for regeneration instructions. Let me find the file and check how to properly update it.

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

● This is a generated file. Per the header, the correct approach is:

  1. Edit PackageVersionsGeneratorDefinitions.json
  2. Re-run the GeneratePackageVersions project

  Let me find the definitions file and the current Hangfire entry.

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

● This is a generated file -- you should edit PackageVersionsGeneratorDefinitions.json instead, then re-run the generator. The current Hangfire definition (lines 2-12) covers versions 1.7.* and 1.8.* with
  MaxVersionExclusive of 2.0.0.

  What change do you want to make? For example:
  - Add a new version pattern like 1.9.*?
  - Bump MaxVersionExclusive to include a newer major version?
  - Something else?

  Let me know the specific Hangfire version you want to include and I'll update the definitions file accordingly.

Other details

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-30 19:51:13

Comparing candidate commit 5951b24 in PR branch steven/do-not-edit-generated-files with baseline commit 5ff69b3 in branch master.

Found 6 performance improvements and 6 performance regressions! Performance is the same for 261 metrics, 15 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0

• 🟥 execution_time [+80.922ms; +81.178ms] or [+65.293%; +65.499%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs netcoreapp3.1

• 🟩 execution_time [-21.317ms; -20.744ms] or [-10.558%; -10.274%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net6.0

• 🟩 execution_time [-105.330ms; -104.171ms] or [-53.354%; -52.767%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

• 🟥 execution_time [+9.978ms; +15.486ms] or [+6.515%; +10.112%]
• 🟥 throughput [-353.734op/s; -298.156op/s] or [-19.904%; -16.777%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark net6.0

• 🟩 execution_time [-87.483µs; -64.237µs] or [-15.389%; -11.300%]
• 🟩 throughput [+231.964op/s; +309.888op/s] or [+13.175%; +17.601%]

scenario:Benchmarks.Trace.NLogBenchmark.EnrichedLog net472

• 🟥 throughput [-8262.682op/s; -7460.385op/s] or [-6.439%; -5.814%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1

• 🟩 throughput [+15479286.955op/s; +16663990.565op/s] or [+6.870%; +7.395%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishScope net6.0

• 🟩 execution_time [-25.705ms; -20.258ms] or [-11.842%; -9.333%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan net6.0

• 🟥 execution_time [+12.142ms; +17.520ms] or [+6.080%; +8.773%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan netcoreapp3.1

• 🟥 execution_time [+19.131ms; +21.569ms] or [+9.666%; +10.898%]