Beyond Notebooks: Human-AI Collaboration in Public Build

Post #4 — ⚙️ Beyond Notebooks — sharpening engineering thinking in the age of AI.

I recently used AI to help me build a Chrome extension that exports LinkedIn connections into CSV. The tool itself was useful. But the more interesting part was what the process taught me about human–AI collaboration when I’m building in a domain I barely know.

What started as a very concrete project gradually turned into a more general way of examining how I work with AI. I found myself mapping the process into four buckets:

Known knowns
I knew the user problem. I wanted a lightweight export tool. I also knew some constraints up front: no backend, no stored credentials, no official API dependency, local CSV only.

Known unknowns
I knew I didn’t really understand Chrome extension mechanics, content-script injection, unpacked extension behavior, DOM fixture design, or how LinkedIn actually loaded more data.

Unknown knowns
This was the most interesting one. I realized I already had engineering instincts that transferred into the new domain, even if I wasn’t naming them consciously: isolate fragile selectors, separate orchestration from parsing, use fixtures as test assets, prefer structural signals over brittle classes, make repeated operations idempotent, and design for testability.

Unknown unknowns
These only surfaced when code met reality: the first fixture wrapper was wrong, the first single-card test was basically vacuous, the declarative injection design broke when the page was already open, and the “correct” auto-scroll loop solved the wrong problem.

What made the process especially interesting was how the collaboration kept moving forward through a few recurring questions:

Why didn’t the initial design go for the more robust solution?
Why didn’t the test actually work, and what would make it a real test?
Can this step be automated realistically?
Can the human be removed from the loop here, or is the human still the one providing critical context?

I used ChatGPT more upstream: to brainstorm, compare approaches, and make the fuzzy parts of the problem more legible.
I used Claude more downstream: to work against repo instructions, fixtures, tests, review loops, and implementation details.

So the workflow didn’t feel like “AI builds, human watches.”

It felt more like:

human brings intent, constraints, partial intuition, and reality
AI helps fill conceptual gaps, accelerate implementation, and tighten the iteration loop

The attached image is my attempt to make that collaboration pattern more visible.

What I’m taking away is that this four-quadrant lens feels genuinely useful for examining AI collaboration itself.

If I keep mapping projects this way, and keep logging the recurring questions that appear in each bucket, I think it can help reveal where context is missing, where tests create false confidence, where experience-based judgment matters most, and where parts of the workflow may be ready for deeper automation.

#BeyondNotebooks #PublicBuild