A week of building, teaching, dashboards, and a television with a Jarvis button. What an AI review of my work history revealed about how I work—and where the roast was fair.
I asked Codex for a fun recap of my recent work history. Work patterns, distractions, favourite shortcuts, writing style. A light roast was explicitly part of the brief.
The answer described a startup studio, a live classroom, and a gadget lab sharing one slightly overwhelmed Mac. Fair. Over the recorded week, I moved between product dashboards, AI workshops, course-video reviews, a TV customisation project, and 3D-printing experiments. Seeing those activities together was more revealing than reading my task list.
This is a reflection on the available activity from October 12–19, 2026. It is a partial record of work across applications, interpreted with AI and edited for publication. An open window does not prove focused effort, and a busy-looking history does not prove useful output. What interested me was the repeated behaviour.
Apparently, I teach by building another tool
The strongest pattern was how often a teaching problem became a software project. Preparing an AI marketing workshop led into interactive analysis tools, a campaign workspace, and dashboards for exploring example data. During another workshop, an explanation of vertical harnesses expanded into a reusable repository and a 3D-printing example.
I find it easier to explain a system when someone can change an input and see what happens. A slide can describe a workflow. A working example makes the decisions visible: what information goes in, what the tool calculates, what it cannot establish, and what the person should inspect next.
There is a trap here. Building the teaching aid can become more interesting than teaching the lesson. The useful question is whether the tool makes one idea clearer. If it takes ten minutes to explain the interface before reaching the idea, I have created another lesson to prepare.
My brief gets sharper once something exists
One presentation grew to 44 slides. I asked for a maximum of 15, a practical demonstration-led structure, and the car analogy I wanted to use to explain the concept. The problem was visible as soon as I moved through the actual deck.
That is how a lot of my product feedback works. I can discuss an assistant panel in the abstract for a while. Put it in a dashboard and I immediately have opinions about where it sits, how it expands, what survives navigation, and whether its language helps the person using it.
A rough artifact gives everyone a shared object to disagree with. I want to use that deliberately: make a small version, inspect the experience, and tighten the brief around what the review reveals. The small-version part matters. A polished implementation of an unclear idea is an expensive way to discover the brief.
My distractions tend to require a repository
There were ordinary detours: social feeds, movie searches, gadget videos, travel comparisons, and 3D-print models. The funny part was how quickly an interesting object could become a build.
The television is the clearest example. I wanted a simpler home screen. That turned into customising an open-source launcher, adding a Jarvis button, and writing up the project. The public build story credits the launcher I started from and distinguishes the TV interface from the computers doing the agent work.
Most people watch television to stop working. I apparently inspect its integration potential.
Curiosity supplies useful examples and ideas. It also makes everything look like a reasonable next task. The history did not prove that every detour was wasteful or worthwhile. It made the switching visible. I can decide whether to capture an idea for later or let it interrupt the thing I already intended to finish.
My clipboard has a very busy job
The recent keyboard record included 191 copy events and 188 paste events. Shift + Return appeared 733 times. Those are captured events from October 17–19, rather than a complete measure of my typing habits, but the pattern fits a week spent moving context between conversations, documents, tools, and drafts.
It also fits my writing. My instructions often begin with the outcome and grow as I think through the details. Then I review the result and get very specific. Use the actual data. Show the working thing. Make the explanation practical. That paragraph has too much text. Why is that panel brown?
That last sequence is an affectionate reconstruction of the style, not a transcript. The underlying preference is consistent: a concrete object, a clear purpose, and enough evidence to assess the result.
A long list of activity can conceal unfinished work
The less flattering pattern was returning to multiple active builds, renders, and release checks. A history full of terminals and dashboards can look impressive while leaving a basic question unanswered: what can someone actually use now?
For my own reviews, I want to ask three questions. What changed? Where can I inspect it? What remains unfinished? A prototype demonstrated with example data needs to be described that way. A rendered video still needs review. A release message needs to agree with the live page.
The useful distinction is between exploration, progress, and completion. Each has a place. Problems start when the vocabulary makes them sound interchangeable.
How I would run this review again
Start with a bounded period. Choose a week and use the activity that is actually available. Leave gaps as gaps. Look for repeated decisions. Which activities turned into usable artifacts? Where did I keep returning? Which interruptions became new commitments? Check the interpretation. A visible page is evidence that it was open. Claims about what shipped need the artifact or publication itself. Choose one adjustment. For me, it is making the finish condition explicit before opening the next build. Another dashboard is rarely the missing ingredient.
I would also keep the roast. Humour makes a pattern easier to recognise without turning the exercise into a performance review. Apparently I can insist on a 15-slide presentation while attempting seven careers in the same week. That is useful feedback, delivered efficiently.
The part I want to keep is the habit of making ideas tangible. The part I want to improve is deciding which ideas deserve to become projects today. Somewhere between those two is a more useful work week. Preferably with enough time left to watch the television.
Related build: I hacked my TV. Then I added Jarvis.
Subscribe free to Harshith's Newsletter to read every article in the interactive edition.
Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.