You may already know that I’m a GenAI sceptic. And a general sceptic.
\nDo you know that scepticism comes from the Greek σκέπτομαι (skeptomai), meaning ‘to search, to think about, or look for’? So my intention is not to say no to everything new, but more to think about it first, and understand before I say yes.
\nThere’s a lot of stuff about GenAI that makes me smile, but I still understand that my way is my way, and I won’t stop the world. I won’t even try. Thus, I want to research and consider how those tools can help me. I already wrote that I don’t feel like 10x Dev, but I’m finding more ways to get help from it.
\nOne of the ways that helped me is something I call “Interactive Rubber-Ducking”.
\nInitially, I called it just brainstorming, but that wouldn’t be precise, as I’m not using it to brainstorm ideas, more to challenge and clarify them.
\nMost of the code I write nowadays is done in my OSS projects. I’m grateful to have a great community with people actively contributing in different ways; still, the canonical design and code work is on my side. As I work in an event-driven niche, I’m often alone with my own thoughts. I try to use the RFC process and discuss it with other fellow humans, but they are not always available. Even if they do, to avoid wasting their time, I need to know what to tell or ask them. I need to give some proposals (with alternatives) to have an effective discussion. I may seem organised, but that’s not always the thing. Sitting in your own head is not a great place to be in general. If you’re a technical leader or an architect, I’m sure that you know that solitude too well.
\nGenAI tools are not great sparing partners. They’re Yes men. If they read this article, they’d for sure confirm it. They’d probably do it even without reading it. Of course, you can ask them not to be sycophant. You can ask numerous MUSTS with capital letters and bolded NEVER here and there, and it can help, but it won’t fully beat the way they were trained.
\nAnd talking to yourself is a similar experience: you’ll find numerous ways to justify your own decisions, and looking at the same place for too long will make you miss obvious blind spots.
\nOk, so why would we take those two blind “people” and try to make them help each other?
\nThat’s kinda what “Interactive Rubber-Ducking” is. It takes a blind human with an idea, and another blind not-so-human asking questions. It starts with such a prompt:
\n\n\nAsk me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.
\nOnce we are done, save the spec as spec.md
\nBefore asking another question, store the previous one with the answer in qa.md. Write literally the question and answer, not just a summary.
\nHere’s the idea:
\n
Don’t treat it as “one magical prompt that will change your life”. Most important is why we’re doing it, what happens next, and who’s actually doing the work. Spoiler alert: it’s not LLM.
\nI’m using it as a command in Claude Code, and, most importantly, with beefier models like Opus, which can better reason and ask better questions. Doing it with lower-level models always gave me much worse results.
\nI’m using it with Claude Code, not Claude Chat, because I want the model to scan my codebase. I can ask it to look in certain areas or to reference my answers. I can even ask to search the web or MCPs like Context 7 to check documentation and APIs for popular libraries. Then it’s getting more into brainstorming sometimes, than rubber-ducking, but that’s fine.
\nAs a result, we’ll get two artefacts:
\nIt may look like Specification-Driven Design, but it’s not.
\nMy goal for this exercise is not to get an actionable specification.
\nThe goal is to get our LLM-based Rubber Duck to ask us hard questions and make us think, not to make the LLM think for us. Find blind spots, and challenge our thinking.
\nBut we’re drivers, we need to know what we want to do, we need to know all the WHYs, and we also need to know HOW. LLM is here to help, but not to do creative work for us. It just pulls it out from our heads.
\nIt also helps to see how our design may be seen by others, especially such mediocre thinkers as LLMs.
\nI don’t expect the Agent to be able to start implementing the spec. I expect it to reflect all considerations and summarise findings. I’m always double-checking to make sure it includes all the important points. If not, I’ll keep doing Q&A until I’m satisfied.
\nHaving both of those files will allow us to keep a full discussion without losing important details, and a shorter version. We can feed that to another model for review, or try to work on tasks and develop a more detailed plan. Sometimes I plan on my own; for simpler tasks, I may ask the LLM to do it fully. Usually, I’m driving the LLM step by step, passing just specific asks.
\nThe example? Why not.
\nI recently did such an exercise, trying to narrow down how to introduce the Second-level cache to Pongo and Emmett. What’s Second-level cache? A Second-level cache is a local store of data managed by the persistence provider to improve application performance.
\nWhy do I want to introduce it? Because I got an issue from the user that rebuilding projections with a lot events can take too long. One of the reasons is that applying an event on a projection takes:
\nThose are two operations per event. If we have a batch of 100 events, that’d mean 200 operations; for 1000 events, this would be 2000, so the classical N+1 problem. We could do it differently, and within a batch:
\nThen we’ll get at worst 102 operations for 100 events and 1002 for 1000 events, so a linear increase.
\nStill, I decided to add batching and introduce 2nd-level cache as a solution. I and my experience were a driving force behind that. I could, of course, rubber duck it, but I had that already planned, not just detailed. I also did some initial research before doing the session.
\nLet me show you the result below. Not too bad if you ask me. Of course, the task wasn’t very innovative; it’s a standard way for mature solutions. Still questions were surprisingly good and helped me.
\nI hope this log will show you (besides how bad I’m at typos) some insight into how I think, talk, and consider the design.
\nTell me your thoughts, if that matches your way, if you haven’t done it yet, try it and tell me how it went!
\nI’d like to provide 2nd-level cache to Pongo. I want to either use keyv (https://www.npmjs.com/package/keyv) or lru-cache (https://www.npmjs.com/package/lru-cache) packages.
\nFor now, I’d like to do it by id.
\nI probably need to either extend pongoCollection src/packages/pongo/src/core/collection/pongoCollection.ts with findeOneById and findManyByIds methods, or check if _id is passed in and then try to access the cache.
\nCache should be set up either on the pongo collection, pongo db or pongoClient.
\nOptimistic Concurrency errors should invalidate cache (as that means someone else updated the record in db, e.g. through a different node).
\nInsertMany and insertOne should put it into the cache.
\nI’d also like to expand the handle method to allow passing either an id or an array of IDs to support batch loading of entities and improve performance, and to support batch update/insert/delete.
\nThoughts?
\nWhich defaults should I set? (Of course, allowing users to override it).
\nCheck the related code I pasted. I want to keep it aligned and as non-invasive as possible.
\nQuestion: You mentioned both keyv and lru-cache. They pull in different directions. Which trade-off do you prefer?
lru-cache, optionally let users swap adapters later.keyv so cross-node sharing works out of the box.get/set/delete/clear) and ship lru-cache as the default adapter.Answer: Custom cache interface (option C). No dependency on external APIs — keep it pluggable. Start with an in-memory provider only. Considered writing a custom LRU with me, but wants to ship fast. Key point: don’t stick to any third-party API surface, allow pluggability.
\nQuestion: Three attachment points: A) PongoClient level (shared across all), B) PongoDb level (per database), C) PongoCollection level (per collection). Or configurable at multiple levels?
\nAnswer: Allow defining it at different levels — cascading configuration. Set a default higher up, override per collection if needed.
\nQuestion: For the cascading config — what should the inheritance/override behavior be?
\nTwo sub-questions:
\nAnswer:
\n'disabled'. That’s a proper devex.Claude’s thoughts: The CacheConfig | 'disabled' pattern is clean — discriminated unions play nicely with TypeScript. The inheritance rule makes sense: general params (TTL, max size) cascade, but type-specific params reset to defaults when you switch providers, avoiding leaking nonsensical config (e.g., a Redis connection string bleeding into an in-memory cache). Also worth distinguishing between “I didn’t specify anything” (inherit from parent via undefined) and “I explicitly want defaults” (reset) — undefined vs 'disabled' vs CacheConfig gives a clean three-state: inherit / off / explicit.
Question: Settling the cache interface details:
\nPromise-based from the start keeps it pluggable. Sound right?getMany, setMany, deleteMany) — should the cache interface support batch ops natively, or loop internally?clear() be scoped per collection, or always clear the entire cache?Answer:
\nClaude’s thoughts: MaybePromise<T> (i.e. T | PromiseLike<T>) works — await on a non-Promise just resolves immediately. No overhead for sync providers, no breaking change for async ones. Passing a cache instance is smart: config becomes either settings (Pongo creates the cache) or a pre-built instance (user brings their own). Multiple collections can explicitly share one cache instance. clear() should be internal/advanced — scope by collection prefix internally so a collection-level clear doesn’t nuke another collection’s entries when sharing an instance. For aligning with lru-cache/keyv settings: both support max (max entries) and ttl (TTL in ms). Start with max and ttl as the general params.
Question: Since cache instances might be shared across collections, how to avoid key collisions?
\n{dbName}:{collectionName}:{id}). The cache interface works with plain string keys, namespacing is Pongo’s concern._id. Simpler but only safe with per-collection instances.Answer: A, definitely.
\nQuestion: How should cache interact with different operations?
\n_id filter → cache hit or miss-then-populate. Clear.handle method — should the read inside handle use the cache (risking more concurrency errors on stale data) or always go to DB?Answer: Definitely use cache. We could consider disabling cache through handle options.
\nClaude’s thoughts: Use cache by default — optimistic concurrency is the safety net. If cached version is stale, write fails, we evict, caller can retry. Adding skipCache?: boolean to HandleOptions is a clean escape hatch for high-contention cases.
skipCache be available on read methods too?Question: Should skipCache also be available on findOne and other read methods for symmetry, or keep it handle-only?
Answer: Good point, having skipCache on find methods (also findMany etc.) would be good.
Claude’s thoughts: Consistent API surface. Add skipCache?: boolean on the shared options type (e.g. CollectionOperationOptions) so it’s available everywhere without repeating yourself.
handle — signature and handler shapeQuestion: You want handle to accept an id or array of ids. Two design choices:
handle(id: string | string[], ...)) vs separate method (handleMany)?Also noted: since PongoDocuments always have _version, if someone provides expectedVersion we could compare it against the cached version and decide if it’s stale without hitting the DB.
Answer: Option A for handler shape. handleMany would be consistent with other APIs, but single id or array (string | string[]) is clean enough.
Claude’s thoughts: Version comparison in cache is a cheap short-circuit — if cached _version doesn’t match expectedVersion, we know it’s stale without a round trip. On signature: TypeScript overloads can narrow the return type (string → single result, string[] → array). handle is a higher-level orchestration method, not direct CRUD, so a union input feels natural. Go with handle(id: string | string[], handler, options?).
Question: What defaults to set? Proposed: max: 1000, ttl: 60_000 (1 min), and should cache be enabled by default or opt-in?
Answer: Stick to recommended lru-cache defaults for now. Enable cache by default.
\nClaude’s thoughts: Enabling by default works because: (1) optimistic concurrency is always the safety net, (2) it’s document-by-id only so invalidation is straightforward, (3) users can set 'disabled'. lru-cache requires max to be set (no default) and has no default TTL. Suggested: max: 1000, no TTL (rely on LRU eviction + invalidation on writes/concurrency errors) — most lru-cache-aligned.
Question: No TTL means cached entries live until LRU-evicted or invalidated by a Pongo write. If something updates the DB outside this Pongo instance (another service, direct SQL), the cache won’t know. Options:
\nAnswer: Fine with using TTL and sometimes hitting OC issue. OC assumes rare conflicts.
\nQuestion: Two approaches for minimal invasiveness:
\npongoCollection level — intercept operations inside the factory function, driver/SQL layers untouched.cachedPongoCollection wraps PongoCollection, adds cache logic around delegation.Answer: Leaning more to option 1. Thinks it’ll be easier to make observability precise eventually.
\nClaude’s assessment: Agreed with option 1. Cache decisions depend on internal state (whether filter targets _id, document _version, write success vs concurrency error). A wrapper would need to re-inspect all of that from the outside. For observability, cache hit/miss logic next to the actual DB call enables precise metrics in context. Pongo’s factory functions already compose behavior internally (transactions, schema migration) — cache is another concern at the same level. A decorator would duplicate filter-inspection logic and add indirection that doesn’t carry its weight.
Question: How should cache interact with transactions?
\nAnswer:
\nClaude’s thoughts: Reads within a transaction benefiting from cache is more aggressive but logical — most transactions are short-lived. The narrow case: insertOne then findOne same _id within a transaction — cache won’t have the uncommitted insert, falls through to DB, gets the right answer anyway. No correctness issue, just no perf benefit for that case. Per-session cache settings fit the cascading pattern (e.g., startSession({ cache: 'disabled' }) for batch migrations). Proposed cascade priority: client → db → collection → session → per-operation skipCache.
Question: Does the cascade priority client → db → collection → session → per-operation skipCache feel right? Session overriding collection is the non-obvious part — the argument being that session is the most immediate runtime context, while collection is structural config. Or would you prefer collection always wins over session?
Answer: That’s fine. Session should precede collection, as normally you create session to e.g. share connection, and join the number of operations logically, so it’d make sense actually to also do it to e.g. override settings like caching.
\nClaude’s thoughts: Session as logical grouping of operations with shared context (connection, transaction) — overriding cache settings at that level is extending the same concept. Bulk import in a session? Set cache disabled once on the session instead of skipCache on every call. Final cascade: client → db → collection → session → per-operation.
Question: If the cache provider throws (e.g., Redis connection drops), should Pongo:
\nAnswer: A — yes, when we add observability to Pongo, we need to make it also a metric and trace event/attribute/log entry.
\nClaude’s thoughts: Cache is an optimization, not a correctness requirement. Silent degradation now, observable degradation when the observability layer lands.
\nQuestion: Three remaining areas:
\ndeleteOne/deleteMany should evict from cache. Anything non-obvious there?Answer:
\ndeleteMany deletes by ids.Claude’s thoughts: Cache warming deferred — can add a strategy hook later. Basic event callbacks (onHit, onMiss, onEvict, onError) on the cache wrapper are low-cost and useful for debugging even before full observability. Delete eviction scoped to id-based deletes for now — filter-based deleteMany doesn’t evict (no way to know which ids were affected without querying first).
Add a document-level (by _id) 2nd level cache to Pongo with a pluggable provider interface. Ships with an in-memory provider backed by lru-cache. Enabled by default. Designed to be minimally invasive to existing code.
PongoCacheProvider<T>A thin, Pongo-owned interface. No coupling to any third-party API.
\ntype MaybePromise<T> = T | PromiseLike<T>;\n\ninterface PongoCacheProvider {\n get(key: string): MaybePromise<PongoDocument | null | undefined>;\n set(key: string, value: PongoDocument, options?: { ttl?: number }): MaybePromise<void>;\n delete(key: string): MaybePromise<void>;\n getMany(keys: string[]): MaybePromise<(PongoDocument | null | undefined)[]>;\n setMany(entries: { key: string; value: PongoDocument; ttl?: number }[]): MaybePromise<void>;\n deleteMany(keys: string[]): MaybePromise<void>;\n clear(): MaybePromise<void>;\n}MaybePromise return types: sync providers (in-memory) return values directly, async providers (Redis) return Promises. await handles both transparently.getMany, setMany, deleteMany) are first-class. Default in-memory implementation may loop internally, but the interface allows optimized batch ops for external providers.clear() is internal/advanced — not exposed to typical users. When sharing a cache instance across collections, scoping is handled via key prefixing by Pongo, not by the provider.Pongo manages key prefixing internally: {dbName}:{collectionName}:{documentId}.
The cache provider works with plain string keys — namespacing is Pongo’s concern, not the provider’s.
\nThe Pongo cache wrapper supports basic callbacks:
\nonHit?(key: string): voidonMiss?(key: string): voidonEvict?(key: string): voidonError?(error: unknown, operation: string): voidThese are optional and intended for debugging and future observability integration.
\nCacheConfigtype CacheConfig = {\n type: string; // e.g., 'in-memory', 'redis', etc.\n max?: number; // max entries (general param, cascades)\n ttl?: number; // TTL in ms (general param, cascades)\n // type-specific options live here too, keyed by type\n [key: string]: unknown;\n} | 'disabled';Three states:
\nundefined — inherit from parent level'disabled' — explicitly turn off caching at this levelCacheConfig object — explicit configurationCache config can be set at multiple levels. Each level inherits from its parent unless explicitly overridden:
\nclient → db → collection → session → per-operation
\nInheritance rules:
\nmax, ttl) cascade down.type, type-specific params reset to defaults (not inherited from parent).skipCache?: boolean is the most granular escape hatch.Users can provide either:
\nIf settings are the same across multiple collections, Pongo can reuse the same provider instance internally. When a user passes an instance, multiple collections can explicitly share one cache.
\nmax: follow lru-cache recommended defaults (1000)ttl: follow lru-cache recommended defaultslru-cache)pongoCollection factory functionCache logic is added directly inside pongoCollection, not as an external decorator/wrapper. This gives cache operations access to internal state (filter inspection, _version, write outcomes) and keeps observability precise.
findOne:
_id, check cache first.skipCache?: boolean option available.findMany / other query methods:
_id values, check cache for each._id filters bypass cache entirely (cache is by-id only).insertOne:
insertMany:
updateOne / updateMany / replaceOne:
deleteOne:
deleteMany:
deleteMany does not evict (no way to know affected ids without extra query). Future improvement possible.expectedVersion and the cached document has _version, compare them in memory. If they don’t match, we know it’s stale without hitting the DB — cheap short-circuit.handle methodid: string | string[] (overloaded: string returns single result, string[] returns array).skipCache?: boolean available in handle options.startSession({ cache: 'disabled' }).Cache provider errors are swallowed — treated as cache misses. The application never fails because of a cache failure.
\nonError hook for debugging._id queries. Complex invalidation — deferred.deleteMany eviction: would require querying affected ids before delete.PongoCacheProvider interface and CacheConfig types.lru-cache.pongoCollection: intercept _id-based reads, update cache on writes, evict on deletes and concurrency errors.handle to accept string | string[] with batch support.skipCache to operation options.Cheers!
\nOskar
\np.s. and yes Nano Banana also did pretty well generating the cover of this post!
\np.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.
","excerpt":"You may already know that I’m a GenAI sceptic. And a general sceptic. Do you know that scepticism comes from the Greek σκέπτομαι (skeptomai…","fields":{"slug":"/interactive_rubber_ducking_with_gen_ai/","prefix":"2026-03-16","langKey":"en"},"frontmatter":{"title":"Interactive Rubber Ducking with GenAI","author":"oskar dudycz","category":"Software Architecture","disqusId":null,"useDefaultLangCanonical":null,"cover":{"childImageSharp":{"resize":{"src":"/static/a08c97f5281d31661ba3946fbc3b1ec0/2a4de/2026-03-16-cover.png"}}}}},"authornote":{"id":"f1fb8a26-256d-5b24-9b06-ad19a0c2961b","html":"Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/interactive_rubber_ducking_with_gen_ai/","lang":"en","langKey":"en","prev":{"id":"c97cb0fb-a5d7-5385-aa00-85d9385ec149","fields":{"slug":"/the_end_of_coding_wrong_question/","prefix":"2026-03-09","source":"posts","langKey":"en"},"frontmatter":{"title":"The End of Coding? Wrong Question","category":"Software Architecture"}},"next":{"id":"759c3674-3d52-5530-a074-502fbe9fab4a","fields":{"slug":"/intro_to_example_mapping/","prefix":"2026-03-30","source":"posts","langKey":"en"},"frontmatter":{"title":"The one where Oskar explains Example Mapping","category":"Software Architecture"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}