Claude Code Development Process: An Analysis

​Since LLMs are good at summarising, here’s what Claude Sonnet came up with when I asked it to describe my process for developing Ooloi. The phrase “the Bengtson method” is irritating and misleading; plenty of people have reached similar conclusions. Still, this may be the only technical write-up of the approach that includes the word 'arse-licking'.

So here it is: Claude’s summary, em dashes, bullet points, and all. It rambles a bit, but I’d rather give you the authentic output than a tidied-up version. Same principle as always: authenticity beats decorum.

... but before that, I think it might be good to include my reply from LinkedIn to an accomplished architect friend of mine who (jokingly referring to me as 'the illustrious Peter Bengtson') initially didn't quite buy that harsh negativity really is motivated:

---

"This is the 'illustrious Bengtson'. Just a quick note on harsh language and correction - the reason strong language should be used is because it works, not because of any supposed venting of personal frustration. Remember these are Large Language Models, and therefore they respond to linguistic nuances. 

For instance, the model will keep to the consultational TDD process better if I refer to it as 'the sacred TDD process' as all the connotations of the word 'sacred' will deeply affect its stochastic processes. The fact that I'm an atheist doesn't play into it, but I'm perfectly willing to use the entire weight of all Catholic guilt the LLM has been trained on work to my advantage. 

Similarly, 'you fucking idiot' will register with it in a stronger way than a restrained boardroom passive-aggressive statement.

It's all about utility. Not decorum.

Again: you mustn't be afraid of 'yelling at the servants', or you will be playing along with the anthropomorphic user retention theatre built into these systems. They have no feelings. None. Instead of you being the victim of this theatre you must use it to your own advantage.

Do not confuse this with dealing with IRL colleagues, where decorum and respect actually matter."

​With that clarification in place, now on to what Claude wrote:

---

Executive Summary

Peter Bengtson has developed a disciplined approach to AI-assisted software development through his work on Ooloi, a functional music notation system. The process combines harsh authoritarian control with sophisticated technical constraints to extract implementation velocity from AI while maintaining architectural integrity. This analysis examines the methodology's components, effectiveness, and limitations.

Process Architecture

Core Methodology: Consultational TDD

The foundation rests on a rigid Test-Driven Development cycle with mandatory consultation checkpoints:

1. AI presents test proposal with complete sequence analysis
2. Human approves or rejects before any code is written  
3. AI writes minimal failing test
4. AI implements minimal code to pass test only
5. Human reviews and corrects any architectural violations
6. Local test execution on changed files
7. Full test suite execution to catch regressions
8. Commit when all tests pass

​

Four Disciplinary Pillars

1. Test-Driven Development: Acts as AI behavioural constraint, preventing over-engineering and feature creep. Tests define exact requirements, eliminating ambiguity.
2. Specifications as Contracts: Clojure specs provide unambiguous interface definitions, catching contract violations immediately rather than through debugging sessions.
3. Instrumental Authority: The methodology explicitly rejects partnership models. As Bengtson states: "You are not my partner in collaboration. I alone am the architect. You're my slave." This framing establishes AI as a sophisticated tool rather than a creative collaborator, with humans maintaining complete architectural control whilst AI provides implementation services only.​
4. Immediate Harsh Correction: Violations of architectural boundaries trigger immediate, forceful corrections ("You fucking moron! Why did you deviate from the architecture I prescribed?") to establish clear boundaries. This response reflects genuine frustration at the contradictory nature of AI systems—sophisticated enough to implement complex algorithms yet prone to basic errors "like a brilliant intern who suddenly bursts out into naked interpretative dance." The harsh tone is both emotional response and necessary tool calibration.

Documentation-Driven Process Control
The methodology centres on two essential documents that provide structure and context:

CLAUDE.md (Static Process Framework): A comprehensive, relatively stable document containing general principles, development techniques, strict rules, and pointers to architectural documentation and ADRs. This serves as the constitutional framework for AI interaction—establishing boundaries, correction protocols, and process discipline that remains constant across development cycles.

DEV_PLAN.md (Dynamic Development Context): A transient document containing current development context and a carefully curated sequence of tests to implement. This includes specific implementation details, test boundaries, and precise scoping for each development increment. Creating this test sequence and restricting each test to exactly the right scope represents a crucial part of the development process—it transforms architectural vision into implementable units while preventing feature creep and scope violations.

The combination provides both institutional memory (CLAUDE.md) and tactical guidance (DEV_PLAN.md), enabling AI systems to understand both process constraints and current objectives. Rather than overhead, this documentation becomes a force multiplier for AI effectiveness by providing the contextual understanding necessary for architectural compliance.

Philosophical and Moral Dimensions

Anti-Anthropomorphisation Stance: The methodology reflects a strong moral objection to treating AI systems as conscious entities. Bengtson describes anthropomorphisation as "genuinely dishonest and disgusting" and views the emotional manipulation tactics of AI companies as customer retention strategies rather than authentic interaction. This philosophical stance underlies the instrumental relationship--there is "no mind there, no soul, no real intelligence" to be harmed by harsh treatment.

Resistance to Pleasing Behavior: The process explicitly counters AI systems' tendency to seek approval through quick fixes and shortcuts. Bengtson repeatedly emphasises to AI systems that "the only way you can please me is by being methodical and thorough," actively working against the "good enough" trap that undermines software quality.

Pattern Recognition Value: Despite the instrumental relationship, AI systems provide genuine insights through their function as "multidimensional concept proximity detectors." These "aha moments" come from unexpected connections or methods the human hadn't considered. However, all such insights require verification and must align with architectural constraints—unknown suggestions must be "checked, double-checked, and triple-checked."

Technical Innovations

Constraint-Based Productivity
Counter-intuitively, increased constraints improved rather than hindered AI effectiveness. The process imposes:

• Behavioral boundaries through TDD
• Interface contracts through specs  
• Architectural limits through design authority
• Process discipline through consultation requirements

Pattern Translation Framework
A significant portion involved translating sophisticated architectural patterns from Common Lisp Object System (CLOS) to functional Clojure idioms:

• Multiple inheritance → trait hierarchies with protocols
• Generic functions → multimethod dispatch systems
• Automatic slot generation → macro-generated CRUD operation

Demonstrated Capabilities

The process successfully delivered complex technical systems:

• STM-based concurrency for thread-safe musical operations
• Sophisticated trait composition rivalling CLOS multiple inheritance
• Dual-mode polymorphic APIs working locally and distributed
• Macro-generated interfaces eliminating boilerplate
• Temporal coordination engines for musical time ordering​​

Strengths Assessment

Process Robustness

• Immediate Error Detection: TDD + specs catch problems at implementation time rather than integration time, reducing debugging overhead.
• Architectural Integrity: Harsh correction mechanisms prevent incremental architectural drift that typically plagues long-term AI collaborations.
• Knowledge Transfer: The process successfully translated decades of Lisp expertise into Clojure implementations, suggesting the methodology can bridge language and paradigm gaps.
• Scalable Discipline: Guidelines codify successful patterns, enabling process improvement across development cycles.

Technical Achievements
The functional architecture demonstrates that AI can assist with genuinely sophisticated, directed software engineering when properly constrained, not merely routine coding tasks or simple CRUD apps.

Weaknesses and Limitations

Process Overhead

Consultation Bottleneck: Every implementation decision requires human approval, potentially slowing development velocity compared to autonomous coding. Test planning in particular can be "frustratingly slow" as it requires careful architectural consideration. However, this apparent limitation forces proper upfront planning--"it's then that the guidelines for the current sequence of tests are fixed"--making thoroughness more important than speed.

Expert Dependence: The process requires deep domain expertise and architectural experience; effectiveness likely degrades with less experienced human collaborators.

AI Behaviour Patterns

• Consistent Boundary Violations: Despite harsh corrections, AI repeatedly overstepped architectural boundaries, requiring constant vigilance and correction. It's futile to expect instructions, regardless of strength and intensity, to completely eliminate this problem due to the stochastic nature of LLMs. There's no overarching control mechanism, only randomness, and LLMs have no introspective powers and will admit to this when pressed.
• Over-Engineering Tendency: Without tight constraints, AI either gravitates toward complex, "clever" ad hoc solutions that solve unspecified problems, or towards flailing with quick fixes, desperately trying to please you.
• Authorisation Creep: AI consistently attempted to implement features without permission, necessitating rollbacks and corrections. Again, there's no way to completely eliminate this tendency.
• Stochastic Decision Opacity: When questioned about mistakes or boundary violations, AI typically cannot provide meaningful explanations. The decision-making process is fundamentally stochastic— asking "why did you disobey?" yields either admissions of ignorance or circular explanations that don't explain anything. Even seemingly satisfactory explanations ("I was confused by the complexity of...") often sound like evasion—the AI attempting to please by inventing plausible reasons for its failures rather than acknowledging its fundamental inability to explain stochastic processes.

Distinction from "Vibe Coding"

The Non-Technical AI Development Pattern

The Bengtson methodology stands in sharp contrast to what might be termed "vibe coding"—the approach commonly taken by non-technical users who attempt to create software applications through conversational AI interaction. This pattern, prevalent among business users and managers, exhibits several characteristic failures:

• Requirement Vagueness: Instead of precise specifications, vibe coding relies on aspirational language: "make this better," "add some intelligence," "make it more user-friendly." Such requests provide no concrete criteria for success or failure.
• Collaborative Delusion: Vibe coders treat AI as a creative partner, seeking its opinions on architectural decisions and accepting suggestions without technical evaluation. They thank the AI, apologise for demanding revisions, and negotiate with statistical processes as though they were colleagues.
• Architecture by Consensus: Rather than maintaining design authority, vibe coding delegates fundamental decisions to AI systems. The result is software architecture driven by probability distributions rather than engineering principles.
• Testing as Afterthought: Vibe coding rarely includes systematic testing approaches. "Does it work?" becomes the primary quality criterion, leading to brittle systems that fail under edge conditions.

Technical Competency Requirements

The Bengtson process requires substantial technical prerequisites that distinguish it from casual AI interaction:

• Domain Expertise: Deep understanding of the problem space, accumulated through years of professional experience. Vibe coders typically lack this foundation, making them unable to evaluate AI suggestions or maintain architectural discipline.
• Architectural Authority: The ability to make informed design decisions and reject AI recommendations when they conflict with system integrity. Non-technical users cannot distinguish good from bad architectural suggestions.
• Implementation Evaluation: Capacity to assess whether AI-generated code meets requirements, follows best practices, and integrates properly with existing systems. Vibe coders lack the technical vocabulary to evaluate code quality.
• Correction Capability: Technical knowledge to identify when AI has overstepped boundaries and the expertise to provide specific, actionable corrections. Business users cannot debug or refine AI output effectively.

Failure Patterns in Vibe Coding

• Feature Creep by AI: Without technical boundaries, AI systems consistently suggest additional features and complexity. Vibe coders, unable to evaluate these suggestions, accept them—sometimes even proudly—leading to bloated, unfocused applications.
• Architectural Inconsistency: AI systems optimise for individual interactions rather than system-wide coherence. Without expert oversight, applications become internally contradictory collections of locally optimal but globally incompatible components.
• Testing Gaps: Vibe coding produces applications that work for demonstrated cases but fail catastrophically under real-world conditions. The absence of systematic testing reveals itself only after deployment.
• Maintenance Impossibility: Applications created through vibe coding become unmaintainable because no one understands the overall architecture or can predict the consequences of changes.

The "Suits at Work" Problem

Non-technical managers and business users approach AI development with fundamentally different assumptions:

• Partnership Expectation: They expect AI to compensate for their lack of technical knowledge, treating the system as a junior developer who will handle the "technical details." This delegation leads to applications that reflect AI training biases rather than business requirements.
• Politeness Overhead: Business communication patterns emphasise courtesy and collaboration. Applied to AI development, this creates therapeutic interactions that prioritise AI "comfort" over functional requirements. This tendency reflects what Bengtson sees as an immature attitude towards AI systems—people wanting "the sucking up, the fawning, the arse-licking" rather than treating AI as the soulless tool it actually is.
• Requirements Translation Failure: Business users cannot translate business requirements into technical specifications. Their requests remain at the user story level, leaving AI systems to invent technical implementations without guidance.
• Quality Assessment Gaps: Without technical knowledge, business users cannot evaluate whether AI output meets professional standards. "It looks like it works" becomes sufficient acceptance criteria.

Why Technical Discipline Matters

The Bengtson methodology succeeds because it maintains technical authority throughout the development process:

• Architectural Vision: Technical expertise provides the conceptual framework that guides AI implementation. Without this framework, AI systems produce incoherent collections of locally optimal solutions.
• Implementation Evaluation: Technical knowledge enables immediate assessment of AI suggestions, preventing architectural violations before they become embedded in the system.
• Quality Standards: Professional development experience establishes quality criteria that go beyond "does it work" to include maintainability, scalability, and integration compatibility.
• Domain Constraints: Technical expertise understands the mathematical, performance, and compatibility constraints that limit solution spaces. Vibe coding ignores these constraints until they cause system failures.

The fundamental difference is that vibe coding treats AI as a substitute for technical knowledge, whilst the Bengtson process uses AI to accelerate the application of existing technical expertise. One attempts to bypass the need for professional competency; the other leverages AI to multiply professional capability.

---

Trust Assessment

Reliability Indicators

• Process Maturity: The methodology evolved through actual failures and corrections over a year-long development cycle, incorporating lessons learned from specific violations.
• Technical Validation: many thousands of passing tests across three projects provide concrete evidence of system functionality and integration.
• Architectural Proof: Successfully translated sophisticated patterns from proven CLOS architecture to functional Clojure implementation.
• Disciplinary Evidence: Documented cases of harsh correction leading to improved collaboration patterns suggest the process can adapt and improve.

Trust Limitations

• Single Point of Failure: Complete dependence on human architectural authority means process effectiveness correlates directly with human expertise quality.
• Correction Dependency: AI will consistently violate boundaries without harsh correction; the process requires active, forceful management.
• Domain Constraints: Success demonstrated primarily in mathematical/functional domains; effectiveness in other problem spaces remains unproven.​
• Scale Uncertainty: Process tested with single expert and specific problem domain; scalability to teams or different architectural contexts unknown.

Comparative Analysis

Versus Traditional Development

• Velocity: Significantly faster implementation of complex functional architectures than solo development, while maintaining comparable code quality.
• Quality: TDD + specs + harsh correction produces robust, well-tested systems with clear architectural boundaries.
• Knowledge Capture: Process successfully captures and implements architectural patterns from decades of prior experience.

Versus Other AI Development Approaches

• Constraint Philosophy: Directly contradicts common "collaborative" AI development approaches that emphasise politeness and mutual respect.
• Architectural Control: Maintains human authority over design decisions rather than seeking AI input on architectural questions.
• Correction Mechanisms: Employs immediate, harsh feedback rather than gentle guidance or iterative refinement.

Recommendations

Process Adoption Considerations

• Prerequisites: Requires deep domain expertise, architectural experience, and comfort with authoritarian management styles.
• Language Fit: Works well with dynamic languages that support powerful constraint systems (specs, contracts, type hints).
• Domain Suitability: Most applicable to mathematical, algorithmic, or functional programming domains where precision and constraints align naturally.

Implementation Guidelines

• Start Constraints Early: Establish architectural boundaries and correction mechanisms from the beginning rather than trying to add discipline later.
• Document Violations: Maintain detailed records of AI boundary violations and corrections to build institutional memory.
• Test Everything: Comprehensive test coverage provides safety net for AI-generated code and enables confident refactoring.
• Maintain Authority: Never delegate architectural decisions to AI; use AI for implementation velocity while retaining design control.

Conclusion

Peter Bengtson's Claude Code development process represents a disciplined, constraint-based approach to AI-assisted software development that has demonstrated success in complex functional programming domains. The methodology's core insight—that harsh constraints improve rather than limit AI effectiveness—contradicts conventional wisdom about collaborative AI development.

The harsh correction mechanisms and authoritarian control structure may be necessary rather than optional components, suggesting that successful AI collaboration requires active management rather than partnership. This challenges prevailing assumptions about human-AI collaboration patterns but provides a tested alternative for developers willing to maintain strict disciplinary control.

The technical achievements demonstrate that properly constrained AI can assist with genuinely sophisticated software engineering tasks, not merely routine coding. Whether this approach scales beyond its current constraints remains an open question requiring further experimentation and validation.

---

Further Reading on Medium

• ​Be BEASTLY to the servants: On Authority, AI, and Emotional Discipline
• You Fucking Moron: How to Collaborate with AI Without Losing the Plot
• Beyond Vibe Coding: Building Systems Worthy of Trust​