1DevTeam's development method is designed around a simple constraint: software cannot be changed reliably when the reasoning scope is smaller than the architecture affected by the change. AI increases the amount of implementation and analysis that can be performed, but it does not eliminate the requirement for context, ownership, verification, and proof.
PRIDE development cycle
The seven stages define the operating sequence. They keep implementation attached to sufficient reading, explicit reasoning, proof, and review rather than treating code generation as completion.
Inspect the relevant code, configuration, contracts, tests, runtime behavior, and surrounding architecture before selecting a solution.
Determine what owns the behavior, why the current system behaves as it does, which assumptions are supported, and which information remains unresolved.
Define the required change, affected dependencies, invariants, failure paths, tests, and downstream consequences.
Implement the complete repair or capability at the correct ownership boundary rather than distributing patches around the visible symptom.
Verify direct behavior, regression surface, edge cases, integration boundaries, and relevant system invariants.
Record the resulting behavior, architectural decisions, evidence, unresolved constraints, and any material change in system understanding.
Evaluate whether the implementation solved the actual problem and whether the reasoning process met the required development standard.
PRIDE Protocol
PRIDE = Proper Actions ÷ Total Actions
Working target: 95% or greater proper actions
PRIDE measures the development process by whether the actions required for reliable engineering were actually taken. The metric does not treat fast output, confidence, or apparent completion as substitutes for the work needed to establish system understanding and proof.
When the process falls below the standard, recovery is explicit: Acknowledge → identify the missed proper action → redo the work correctly → incorporate the result into the next cycle.
View the preserved PRIDE working artifact →Supporting systems
Snapshot transfers structured repository and project state into model working context. It reduces repeated reconstruction, but it does not replace direct repository inspection or determine the architecture surrounding a change.
The Ajenda Architectural Graph represents mapped software entities and relationships used for dependency reasoning, decision ownership, change impact, proof selection, completeness auditing, and selected function-level diagnosis. It is an active development and CI capability, not customer-facing Ajenda runtime functionality.
Relationship between the three systems
PRIDE defines how the work should be performed.
Snapshot increases the project context available to the model.
The Architectural Graph externalizes system structure for architecture-aware reasoning and proof.
Each addresses a different source of error in AI-assisted software development. None substitutes for the others, and none is treated as a complete solution to software-development quality on its own.
