Object Calisthenics in the AI Era: a Contract That Holds

Object Calisthenics, formalized by Jeff Bay and popularized by William Durand, are eighteen years old. Their nine rules are taught as katas, posted on walls, referenced in onboardings. And in most teams, they end up being “generally followed” — which means applied when you remember, bypassed under sprint pressure.

Generative AI changes something here. Not because it’s more rigorous than developers, but because it’s tireless, free from sprint context, and has no memory of past exceptions. Turned into a custom instruction, an Object Calisthenics rule becomes a machine contract: it applies to every generated line, without implicit negotiation.

TL;DR — Object Calisthenics, designed as a pedagogical exercise, work as generation constraints for AI agents. GitHub Copilot (via .github/copilot-instructions.md) and Claude Code (via CLAUDE.md) let you formalize them as persistent instructions. The benefit: structural consistency in generated code over time, independent of the day, the hour, and the team’s workload.

Why Do Object Calisthenics Break Down Under Everyday Pressure?

The nine rules aren’t hard to understand; they’re hard to collectively maintain over time. That’s not a motivation problem. It’s a cognitive load problem: conscientiously applying nine structural constraints while simultaneously solving a business problem is exhausting. The rules end up internalized as an ideal rather than a strict contract.

In the teams I work with on development tooling strategy, I consistently see the same pattern: quality rules are written in a wiki, championed by one or two senior engineers, and progressively eroded by turnover and deadlines. Not by bad faith; by natural entropy. The developer joining mid-sprint doesn’t have time to internalize nine rules before shipping their first PR.

Code review catches some violations. Static analysis tools (ESLint, SonarQube) cover a subset; not all. Object Calisthenics target design properties that static analyzers don’t check: primitive encapsulation, the Law of Demeter, the two-instance-variable limit per class.

What Does a Custom Instruction Actually Change in an AI Agent?

In 2025, the Stack Overflow Developer Survey found that 84% of developers used or planned to use AI tools in their workflow. What this adoption doesn’t measure yet is the structural quality of generated code over time; that’s precisely where custom instructions come in.

When you pass a rule to an AI agent as a persistent instruction, something structurally different happens: the agent doesn’t weigh it against context. It doesn’t trade off “the rule says X, but Y is more practical here.” It applies.

The key property of Object Calisthenics rules is their machine-readability: unlike “write clean code” or “follow SOLID principles,” each rule is precise and verifiable. “One level of indentation per method” can be audited. “No abbreviations” can be checked against an identifier. These are structural constraints, not value judgments: that’s exactly what a language model needs to honor them reliably.

GitHub Copilot supports repository custom instructions via .github/copilot-instructions.md. Claude Code uses CLAUDE.md at the project root. For teams that have already integrated AI agents into their development workflow, this is a directly applicable evolution of existing tooling.

How to Wire the Nine Rules Into CLAUDE.md and Copilot?

Code on a dark screen — geralt / Pixabay

The condensed form below drops directly into CLAUDE.md or .github/copilot-instructions.md. Density matters: an instruction that’s too verbose is partially ignored; one that’s too vague is completely ignored. Nine rules in nine lines, each with a violation hint, gives enough signal without overloading the context.

## Object Calisthenics

1. One level of indentation per function — extract a method as soon as a loop contains a condition.
2. No `else` — use early return; handle error cases first.
3. Wrap primitives with behavior — create a dedicated type if a string or number carries business logic.
4. First-class collections — a class that contains a collection contains only that.
5. One dot per line — Law of Demeter.
6. No abbreviations — full names, readable without context.
7. Keep entities small — max 150 lines per file, max 10 files per directory.
8. No more than two instance variables per class.
9. No getters/setters for external decisions — Tell, don't ask.

This is the section I use in the CLAUDE.md of my own projects. The specificity of the rules makes them directly actionable by an agent: no ambiguity, no value judgment to interpret.

Object Calisthenics and Code Review: Complementary Levels

Wiring the rules into a custom instruction doesn’t make code review obsolete; it changes its nature. When generated code structurally follows the nine rules, review focuses on what can’t be formalized: business relevance, architectural choices, unanticipated edge cases.

That’s a net gain. Review no longer gets lost on structural remarks everyone knows but nobody wants to raise at the tenth sprint. For teams working with a disciplined source control practice, rules systematically applied by AI also reduce diff noise: smaller PRs, more targeted changes, review discussions that focus on what actually deserves discussion.

Every well-worded rule in a custom instruction becomes a silent reviewer who misses no PR, never tires, and never has a bad day.

Frequently Asked Questions

Do Object Calisthenics apply to all programming languages?

Yes. The nine rules are language-agnostic: they address structure, encapsulation, and separation of concerns, not syntax. Originally formalized in Java by Jeff Bay, they apply equally to TypeScript, Python, Go, or Kotlin. An AI agent adapts its interpretation to the language of the file being edited, making the instructions portable across heterogeneous projects without modification.

Does AI actually respect these constraints reliably?

Not 100%, and that isn’t the goal. A persistent instruction significantly increases conformance in generated code, but an AI agent can still produce violations on complex or ambiguous cases. The value isn’t in perfection; it’s in default consistency that shifts the burden from constant vigilance to targeted review of non-trivial cases.

What is the difference between Object Calisthenics and ESLint or SonarQube rules?

Static analysis tools cover mechanically verifiable rules: line length, cyclomatic complexity, naming patterns. Object Calisthenics cover design constraints that require understanding the code: primitive encapsulation, the Law of Demeter, first-class collections. The two are complementary: linters verify after writing; custom instructions guide generation upfront.

Do you need to rewrite existing code to comply with the rules?

No. Custom instructions apply to code generated or modified by the agent, not to existing code. That’s precisely the point: the codebase gradually evolves toward conformance, file by file, without a massive migration. The most critical code can be prioritized with an agent tasked on a scoped refactoring assignment.