Investigate Excel TABLE() array formula support via Office.js API
Takeaway: I went in assuming there might be some Office.js trick to trigger TABLE(), but the honest answer was no — it's genuinely UI-only.
16 sessions on office.js with a coding agent: the agent failed at least once in 5, and 9 finished without a human stepping in.
Takeaway: I went in assuming there might be some Office.js trick to trigger TABLE(), but the honest answer was no — it's genuinely UI-only.
Takeaway: Next time I'd open with the real requirement up front: 'agent writes and runs arbitrary VBA like it does Python' instead of letting the conversation drift into macro-allowlist framing first.
Takeaway: I'd start by pointing the agent straight at the README and install docs since that's where the real architecture explanation lives, rather than letting it grep around first.
Takeaway: I'd start by asking directly whether Office even supports dynamic taskpane resizing before digging into the code, since that's a platform limitation no amount of code archaeology would fix.
Takeaway: I'd start by pointing the agent straight at the taskpane entrypoint and init files instead of letting it wander the whole src tree first — it got there anyway but took a lot of exploration turns.
Takeaway: Next time I'd front-load the exact list of window.confirm call sites in the first prompt so the agent doesn't have to rediscover them twice across two PRs.
Takeaway: Next time I'd front-load the positioning (who this is for, what makes it different from a generic AI chatbot) before asking the agent to build anything, since the whole first landing page draft got mostly replaced once I explained the 'coding agent, but native to Excel' angle.
Takeaway: Next time I'd open by asking for a concrete UX audit with a prioritized list before jumping into changes, since the iterative 'please do' loop worked but cost a lot of exploration turns per round.
Takeaway: Next time I'd start by telling it to actually load the running page with agent-browser instead of trusting typecheck/build passing as proof the UI worked — that's what actually surfaced the real state and let it self-verify.
Takeaway: Next time I'd open with the constraint I ended up stating later: reuse the existing Files UI/tool, no separate assistant-only flow — that would've saved a full exploration-and-pitch round trip.
Takeaway: Next time I'd tell the agent up front to check I'm on the right branch before it commits, since the push-to-main step turned into an unplanned rebase/cherry-pick conflict resolution.
Takeaway: Next time I'd ask upfront for the fix to include a manual verification step (actually reload and check tabs) before calling it done, since the first commit passed all checks but never actually wired the restore into the boot path.
Takeaway: I'd start next time by asking directly for a fetch()/network audit of tools and extensions before discussing CSP in the abstract - that grep for zero outbound fetch calls was what actually let me lock down connect-src confidently instead of guessing.
Takeaway: Next time I'd give the agent my full list of ideas up front, including the file-storage and multi-workbook points I only added later, so it doesn't have to file issues in two separate batches.
Takeaway: Next time I'd open with both threads at once — the distribution manifest question and the view tool scope — since neither ended in code changes, just investigation and a filed issue.
Takeaway: Next time I'd ask upfront for a screenshot-driven audit at the actual sidebar width before any rebuild, since the real bug (an unlayered CSS reset clobbering Tailwind's @layer utilities) was hiding under a much bigger 'replace the whole layout shell' rewrite.