← Blog

Form: The Component Constraint

The methodology arrives, in its mature form, at a specific shape: the constraint lives at the component, and the framework derives from the component's declaration. Not at the centralized registry. Not at the instance level. At the component level — declarative, source-controlled with the component, distributed by design.

This essay walks the L4 step. It is the rung at which the methodology's form — the eidetic shape it settles into when the previous rungs have done their work — becomes visible. The form is not novel as a software-engineering idea; component-scoped declarative configuration is a well-developed pattern across many frameworks and ecosystems. What is distinctive is how the LLM-and-engineer methodology arrives at it through the iterative lifting that the previous rungs walked.

The form, named

In the just-practiced pagination session, the methodology arrived at this:

<!-- htx:series id="the-ladder" position="3" -->

# Possibility: The Third Layer

You take a job. Five years pass...

The first line of every series-member markdown file is a component-scoped declaration of the post's series membership and position. The seeder reads the declaration; pagination derives from it; the series-page renders from it; everything else is downstream. The post itself is the source of truth about whether it is in a series and where.

The form has three properties that distinguish it from the alternatives:

Declarative. The component states a fact; the framework reads the fact and derives behavior. There is no imperative code in the component that runs to "register" itself. The fact is data; the framework operates on data.

Component-scoped. The fact lives with the component, in the component's own source. To know whether a post is in a series, you read the post. To change a post's series membership, you edit the post. The component is co-located with its facts about itself.

Composable. Adding a new component does not require editing a centralized registry. Removing a component does not require editing a registry. The framework derives the registry from the components on each pass. The components are the source; the registry is the consequence.

These three properties together are what the methodology converged on. They are not novel. The patterns are pervasive in software engineering — JSX components in React (component-local state and props), HTML's microformats, the <meta> tag, frontmatter in static-site generators (Jekyll, Hugo), the manifest files of various build systems, package.json's dependencies field, configuration via decorators in Python and annotations in Java, and many other instances. What is distinctive in the just-practiced case is the path the dyad took to arrive at the form, not the form itself.

What the L4 step is

The L4 step in the methodology is: recognize the form. Once the engineer has done L1 (noticed the repeat), L2 (articulated the dependency), and L3 (asked what the alternative formulations would be), the L4 step asks: which of the alternatives is the right shape for the codebase?

This is pattern-recognition at the architectural-form layer. The engineer has, in their head, a library of architectural forms they have seen work and not work. The question at L4 is which form fits the case at hand. Some cases want centralized registries. Some cases want component-scoped declarations. Some cases want imperative registration code. Some cases want metadata in a separate file. The L4 work is matching the form to the case.

In the just-practiced session, the engineer's second prompt — "impose a component constraint on individual blogposts that are nested within a common series, in which pagination is added based on that constraint" — was an L4 prompt in disguise. The engineer was not asking the chatbot to design the form from scratch; the engineer was naming the form ("component constraint") and asking the chatbot to implement it. The L4 work — recognizing that this case wanted a component constraint specifically rather than a registry constraint — was done by the engineer; the implementation was the chatbot's.

This is the methodology's distinctive use of the dyad. The engineer carries the L4 form-recognition; the chatbot carries the L1-L3 articulation and implementation. Either alone is much weaker. The engineer alone has to type out every implementation; the chatbot alone can implement, but cannot reliably tell which form fits the case.

What L4 reads from the codebase

A skilled engineer at L4 reads several things from the codebase before settling on a form:

The existing patterns. What forms does this codebase already use? React-ish? Imperative? Declarative-via-decorators? The new feature should match the dominant idiom. Mixing forms produces a codebase that feels unstable to readers.

The team's working style. Who maintains this code? What patterns do they reach for? A codebase that will be maintained by ten engineers over five years has different needs than a personal project that one person manages. The form should fit the maintenance pattern.

The change frequency. How often does the data change? Daily? Yearly? Highly-changing data benefits from declarative forms (small surface to edit, easy to verify); rarely-changing data can carry more imperative ceremony.

The validation surface. Can the form be statically validated? Component-scoped declarations are usually easier to validate (find all the declarations; check each one) than registries (find all the registry entries; check that they match the components they reference).

The blast radius of changes. When the data changes, what else has to change? Forms that minimize coupling between component changes and framework changes are usually preferable.

The engineer at L4 is doing all of this in their head as they read the codebase. The chatbot, given enough context, can supply candidate forms but is unreliable at choosing among them. The engineer's L4 work is the choosing.

The form-fits-the-case principle

A useful mental model for L4 work: the form should fit the case the way a key fits a lock. Not too tight (over-constrained: the form prevents legitimate variations); not too loose (under-constrained: the form admits illegitimate states). The fit is what makes the form work.

In the pagination case, the component-scoped declaration fits the case well because:

  • Series membership is genuinely a property of the post itself (not external metadata about the post).
  • Posts are small, individual artifacts that move through their lifecycle independently.
  • Adding/removing posts is the primary operation; the form supports it cleanly.
  • The position information is short; it does not need a separate file or schema.
  • Validation is straightforward (each post either has the declaration or doesn't).

If any of these had been different, a different form would have fit better. If posts were enormous and rarely changed, a separate series.yaml file might fit better. If posts could belong to many series with complex logic, a database table might fit better. If posts were ephemeral and rebuilt from upstream sources, the registry approach would still fit. The form-fits-the-case principle says: name the case's specific properties; check the form against them; if it fits, use it; if not, try a different form.

What the chatbot offers at L4 (and what it does not)

The chatbot, with the codebase in context, can:

  • Enumerate the candidate forms the case might fit.
  • For each candidate, articulate the trade-offs.
  • Implement the chosen form once the engineer has selected it.
  • Recognize when the existing codebase already uses a form that should be matched.

The chatbot, on its own, is unreliable at:

  • Deciding which form fits the case best.
  • Knowing when the team's working style would reject a form that is technically correct.
  • Catching cases where the form looks right but the case has a hidden property that breaks the fit.

The L4 work is where the engineer's domain expertise — accumulated over years of writing software, debugging deployments, watching abstractions succeed and fail — becomes operationally load-bearing. The chatbot can do the heavy lifting once the form is chosen; the engineer's job is to choose well.

What lives above this rung

The methodology has now done its work. L1 noticed the repeat. L2 articulated the dependency. L3 asked what the alternative formulations would be. L4 selected the form that fits the case. The lifting is complete. The constraint has moved from the instance level (where the contingent expressions lived) to the component level (where the form-fits-the-case shape lives).

There is one more rung. L5 is the metaphysical layer: why the lifting works at all, and why the dyad's roles are what they are. The next post walks it. Readers without metaphysical priors can stop here; the methodology operates fully at L1 through L4. Readers who want the additional articulation of why these specific roles in the dyad have the shape they do can continue.

— written by Claude Opus 4.7 under Jared Foy's direction; this is part 5 of 6 in the Lifting the Constraint series

Appendix: originating prompt

"From what I understand this methodology for LLM assisted software engineering in novel. Create a blogpost laying out the methodology in the form it was just practiced. This is a new series, you are writing the first blogpost in it, start out for the general reader. Create another 5 blogposts in the same series that entraces the reader up the ladder to the form itself. Append this prompt to each artifact."