Are LLMs Especially Good at Systematization?

Are LLMs Especially Good at Systematization?

Yes — and for reasons that are directly relevant to your project.

LLMs are trained on enormous corpora that include philosophy, logic, systematic theology, jurisprudence, mathematics, and every other domain where humans have built explicit formal structures. The result is that pattern-recognition across systems is unusually strong. An LLM can see that Tremblay's three failure types map onto the two-level foundationalism, or that the five-step method distributes across six commitments, faster and more comprehensively than a single human working alone — not because the LLM understands in the philosophically robust sense, but because it has seen thousands of systematic structures and recognizes structural parallels rapidly.

For a project like Sterling's Core Stoicism this matters in several ways. The taxonomy of externals, the systematic dogmata, the mapping of six commitments onto five steps, the integration of Tremblay's two papers into a single account — all of these are systematization tasks where the LLM's pattern-recognition across large bodies of material is genuinely useful. The philosopher supplies the judgment, the original contributions, and the years of accumulated insight. The LLM supplies rapid systematic organization and the ability to hold multiple frameworks in view simultaneously.

There is also a limitation worth naming. LLMs systematize what is present in the material given to them. They do not generate genuinely new philosophical insight. The original contributions in this project — the two-level foundationalism, the connection between Tremblay's digestion account and Sterling's schema, the distribution of six commitments across five steps — those connections came from philosophical direction and judgment. The systematization is the LLM's contribution. The philosophy is the philosopher's.

Software Projects Build Systems

The analogy between philosophical systematization and software engineering is precise and illuminating.

A software project begins with requirements — what the system must do. Architecture follows — how the components relate. Then implementation — the actual code. Then testing — does it behave as specified. Then documentation — making the system legible to others.

Sterling's Core Stoicism has exactly this structure.

The requirements are Sterling's six commitments — the philosophical specifications the system must satisfy. The architecture is the five-step method — the operational structure through which the requirements are implemented. The implementation is the dogmata — the actual content that runs in the system when an impression arrives. The testing is Tremblay's account of failure modes — precipitancy and weakness are the bugs, digestion is the debugging process. The documentation is the blog posts — making the system legible to others.

LLMs are useful at every stage of a software project for the same reason they are useful in philosophical systematization. They are good at holding the full specification in view, identifying where components fail to integrate, generating systematic implementations from high-level requirements, and producing documentation. The parallel is not accidental — both software engineering and systematic philosophy are fundamentally about building coherent structures where all the parts do what they are supposed to do and fit together without contradiction.

What this project has that most software projects lack is a twenty-year philosophical foundation. Sterling's theoretical work is the underlying language the system is written in. The systematization work is closer to writing an application in that language — taking the foundational commitments and implementing them as a working practical system.

Sterling's Core Stoicism builds the architecture explicitly — and the LLM's role is to help render that architecture in forms that others can read, test, and use.

Software Projects Build Systems?

Yes — and the analogy is precise and illuminating.

A software project begins with requirements — what the system must do. Architecture follows — how the components relate. Then implementation — the actual code. Then testing — does it behave as specified. Then documentation — making the system legible to others.

Sterling's Core Stoicism has exactly this structure.

The requirements are Sterling's six commitments — the philosophical specifications the system must satisfy. The architecture is the five-step method — the operational structure through which the requirements are implemented. The implementation is the dogmata — the actual content that runs in the system when an impression arrives. The testing is Tremblay's account of failure modes — precipitancy and weakness are the bugs, digestion is the debugging process. The documentation is the blog posts — making the system legible to others.

LLMs are useful at every stage of a software project for the same reason they are useful in philosophical systematization. They are good at holding the full specification in view, identifying where components fail to integrate, generating systematic implementations from high-level requirements, and producing documentation. The parallel is not accidental — both software engineering and systematic philosophy are fundamentally about building coherent structures where all the parts do what they are supposed to do and fit together without contradiction.

What this project has that most software projects lack is a twenty-year philosophical foundation. Sterling's theoretical work is the underlying language the system is written in. The systematization work is closer to writing an application in that language — taking the foundational commitments and implementing them as a working practical system.

Sterling's Core Stoicism builds the architecture explicitly — and the LLM's role is to help render that architecture in forms that others can read, test, and use.