Across many sessions on Linux kernel patch series, Auto mode selects models in
the gpt-5.6-sol class that consistently fail at the core skill this work
requires: respecting commit boundaries and scope. This is a recurring pattern,
not a one-off. Stronger models handle the same tasks reliably.
Typical failure modes, all occurring with explicit standing instructions in
context ("fold changes into the relevant commit", "keep history bisectable",
"no functional change intended"):
-
Scope creep inside code-motion commits. A commit meant to relocate code also
introduces new abstractions or refactors. Correcting this usually takes
several rounds, because the model re-expands scope after being told to
narrow it.
-
Silent deletion or open-coding of helpers. Existing static helpers get
inlined away during "no functional change" commits - unrequested and
unmentioned, discoverable only by manual diff review.
-
Incomplete renames. A requested rename is applied to the obvious symbols but
leaves related identifiers behind, often in other architectures or headers.
-
Architecture-correctness misses. Code carrying one architecture's semantics
is lifted into generic code and applied to others, without recognizing the
semantics were not universal.
-
Misread API shape. Instructions about where code should live (per-architecture
copies vs. a shared implementation with wrappers) are inverted.
-
Changing established semantics to fit the model's design. Long-standing
function behavior is altered to make a new abstraction fit, instead of
preserving behavior.
The common thread: these models optimize for a plausible-looking final tree and
treat the commit series as an implementation detail. For kernel work the series
is the deliverable.
Requests:
- Weight Auto model selection toward stronger models for kernel/systems C work,
especially sessions involving git rebase, commit splitting, or
cross-architecture code.
- Surface which model Auto selected, so a mismatch is visible before hours are
spent.
- Treat "fold into the relevant commit" and "no functional change intended" as
hard constraints, not stylistic hints.
Kernel maintainers evaluating Copilot CLI judge it on whether a series is clean,
bisectable and correctly scoped. A model that quietly reshapes commits fails
that bar regardless of how good the final tree looks.
Across many sessions on Linux kernel patch series, Auto mode selects models in
the gpt-5.6-sol class that consistently fail at the core skill this work
requires: respecting commit boundaries and scope. This is a recurring pattern,
not a one-off. Stronger models handle the same tasks reliably.
Typical failure modes, all occurring with explicit standing instructions in
context ("fold changes into the relevant commit", "keep history bisectable",
"no functional change intended"):
Scope creep inside code-motion commits. A commit meant to relocate code also
introduces new abstractions or refactors. Correcting this usually takes
several rounds, because the model re-expands scope after being told to
narrow it.
Silent deletion or open-coding of helpers. Existing static helpers get
inlined away during "no functional change" commits - unrequested and
unmentioned, discoverable only by manual diff review.
Incomplete renames. A requested rename is applied to the obvious symbols but
leaves related identifiers behind, often in other architectures or headers.
Architecture-correctness misses. Code carrying one architecture's semantics
is lifted into generic code and applied to others, without recognizing the
semantics were not universal.
Misread API shape. Instructions about where code should live (per-architecture
copies vs. a shared implementation with wrappers) are inverted.
Changing established semantics to fit the model's design. Long-standing
function behavior is altered to make a new abstraction fit, instead of
preserving behavior.
The common thread: these models optimize for a plausible-looking final tree and
treat the commit series as an implementation detail. For kernel work the series
is the deliverable.
Requests:
especially sessions involving git rebase, commit splitting, or
cross-architecture code.
spent.
hard constraints, not stylistic hints.
Kernel maintainers evaluating Copilot CLI judge it on whether a series is clean,
bisectable and correctly scoped. A model that quietly reshapes commits fails
that bar regardless of how good the final tree looks.