Docendo

The idea #

The Feynman Technique says you don’t understand something until you can explain it simply. Docendo takes that literally: the user is the mentor, an AI is the student.

You explain a concept, and the AI, playing an inquisitive student, asks clarifying questions and points out gaps in the explanation. Articulating the idea well enough for the AI to summarize it correctly is the actual learning mechanism, not a side effect.

How the AI “learns” #

Each explanation gets embedded and added to a vector store scoped to that learning session. Later questions get generated with retrieval against that growing store, so follow-ups get more specific the more you’ve explained.

public void recordExplanation(UUID sessionId, String explanation) {
    var embedding = embeddingModel.embed(explanation);
    vectorStore.add(List.of(
        new Document(explanation, Map.of("sessionId", sessionId))
    ));
}

public List<Document> relevantContext(UUID sessionId, String query) {
    return vectorStore.similaritySearch(
        SearchRequest.query(query).withFilterExpression("sessionId == '" + sessionId + "'")
    );
}

Why scope the vector store per session #

The alternative was one global vector store per user, every explanation ever given, searchable at once. Sounds better on paper, but in practice a question about recursion in week three can pull in an unrelated explanation about database indexing from week one.

The Part I Keep Redesigning #

What makes a good clarifying question is the hardest piece of Docendo, harder than the retrieval plumbing. A student who asks “what does that mean” after every sentence is just noise. A student who never questions anything is worse.

The current approach has the model identify the specific claim that doesn’t logically follow, and question that instead of asking generically. Still needs the most iteration of anything in this project.

Why Java and Spring AI for This One #

Deliberate choice, not a default. I’d just come back to Java and wanted to see whether “boring on purpose” backend discipline holds up for something with a genuinely uncertain core like a tutoring loop.

Mixed results so far. The ChatClient and VectorStore abstractions feel predictable and easy to test, but the tutoring logic itself resists that rigor. Can’t unit test “did the AI ask a good question” the way you unit test “did the record save.”

What a Good Session Actually Looks Like #

Testing this on myself has been the most useful feedback loop. I picked something I half-understood and tried explaining it to the AI student cold, no notes.

Stack #

Spring Boot 3 backend with Spring AI handling ChatClient, EmbeddingModel, and VectorStore. Angular frontend with NgRx and WebSockets. PostgreSQL for session data, PGVector for embeddings, Redis for conversational memory.

Status #

Backend learning loop (explain → embed → retrieve → question) is the current focus. Frontend, auth, and deployment come after, once the core loop is worth building around instead of rewriting.