Takehome Studio — AI Without Outsourcing Judgment

Turn ambiguous product take-home assignments into defensible presentations faster—using AI for structure, suggestions, and acceleration while keeping every key judgment human-owned.

Comment

Inspiration

Product take-home assignments are meant to test judgment, but AI can now generate polished answers faster than candidates can explain or defend them.

That creates a new problem: the output may look complete even when the reasoning underneath it is weak, assumptions remain hidden, and the candidate no longer owns the key decisions.

This problem became personal during my recent job search. I found myself returning to take-home assignments and confronting the same tension from both sides: candidates are under pressure to move faster, while hiring managers still need to understand how the candidate thinks, what they chose, and what they can defend.

At the same time, I had been developing and sharing a broader methodology for using AI without outsourcing product judgment. That work became the foundation for Takehome Studio.

AI should accelerate product work without outsourcing product judgment.

The goal is not to generate the candidate’s answer automatically. It is to help a product manager move from an ambiguous assignment to a clear, defensible presentation while keeping the important decisions explicit and human-owned.

What it does

Takehome Studio guides a product manager through a structured workflow:

  1. Interpret the assignment and surface ambiguity.
  2. Review evaluation signals, stakeholder hypotheses, and open questions.
  3. Build a PM-owned Product Frame.
  4. Receive bounded AI suggestions for individual fields.
  5. Apply, add, edit, or dismiss those suggestions explicitly.
  6. Produce a deterministic Discovery Summary from accepted state.
  7. Optionally use AI to polish wording without changing the underlying structure or strengthening claims.
  8. Export the final result into a presentation-ready format.

The product shortens the path to a completed take-home assignment by reducing avoidable rework, hidden assumptions, and premature certainty—not by skipping judgment.

How I built it

Takehome Studio began as an AI-assisted, vibe-coded prototype built primarily through Lovable.

That approach was valuable at first because it helped turn an initial product idea into a working application quickly. It was especially useful for early interface creation and product shaping.

But as the product became more complex, the economics and reliability changed.

Broad iterative prompts sometimes affected unrelated behavior, partial fixes introduced regressions, and repeated attempts consumed credits without resolving the underlying issue. I eventually reached a point where the marginal value of another Lovable iteration became negative: I was spending more time, more credits, and more attention while getting less predictable progress.

That was the point where I realized I could move faster and produce more reliable results by shifting repository-level work to Codex.

I changed the operating model rather than simply writing longer prompts.

I created a small set of canonical product and engineering documents that defined:

  • product intent and scope;
  • workflow and state authority;
  • accepted product decisions;
  • implementation constraints;
  • testing and validation expectations;
  • what AI could propose versus what required explicit human approval.

This approach grew directly from the methodology I documented in my case study, Using AI Without Outsourcing Product Judgment.

Codex then became the primary engineering agent for work that required repository-wide reasoning, state consistency, debugging, and reliable validation.

I used Codex to:

  • inspect the existing repository;
  • trace behavior across UI, state, and provider boundaries;
  • translate bounded requirements into code changes;
  • add regression coverage;
  • diagnose cross-layer failures;
  • validate assumptions;
  • preserve implementation evidence through commits and pull requests.

GPT-5.6 supported product reasoning, task definition, prompt and schema calibration, semantic review, acceptance criteria, demo design, and evaluation of the resulting implementation.

Lovable remained useful for selected UI-oriented work, but Codex became the lead for changes that required stronger control, broader repository context, and evidence-based validation.

Build Week extension

The product existed as a working prototype before OpenAI Build Week.

I discovered Build Week by chance after the event had already started. Fortunately, the product and operating model were already moving in the right direction, so the pivot was relatively natural rather than disruptive.

The core product thesis already aligned with the event:

  • use AI to accelerate meaningful work;
  • make human judgment explicit;
  • preserve evidence;
  • keep authority boundaries enforceable;
  • use Codex for repository-level implementation and validation.

During Build Week, I meaningfully extended the product using Codex and GPT-5.6 through work including:

  • Live AI integration;
  • typed operations and structured outputs;
  • PM-owned proposal and state authority;
  • stale-suggestion and stale-response protection;
  • runtime provenance;
  • asynchronous request lifecycle safety;
  • deterministic fallbacks;
  • deterministic-first presentation generation;
  • regression testing;
  • prompt and schema calibration;
  • repository-wide debugging and refactoring.

The running application uses the Google GenAI SDK for Live AI operations. This runtime provider is separate from the OpenAI tools used to reason about, implement, validate, and document the Build Week extension.

The result was not only more functionality.

The product became more explicit about:

  • which content belongs to the PM;
  • which content is only an AI suggestion;
  • when older AI output must lose authority;
  • when deterministic behavior remains authoritative;
  • how accepted state is protected from later model output.

Key product decision

The most important design decision was to keep the Product Frame PM-owned.

AI suggestions remain separate from accepted content and attach only to individual fields.

Depending on the suggestion type, the user can explicitly:

  • Apply;
  • Add;
  • Edit;
  • Dismiss.

No suggestion changes accepted state without an explicit user action.

If the PM edits a field after suggestions were generated, older suggestions become stale and cannot overwrite the newer human decision.

This turns “human in the loop” from a slogan into enforceable product behavior.

Challenges

One major challenge was learning where different AI development tools were most effective.

Lovable was excellent for rapid product shaping and early interface creation, but repeated structural edits became increasingly expensive and unpredictable. Broad prompts sometimes produced partial fixes, introduced regressions, or required several attempts without addressing the underlying issue.

The problem was not solved by writing longer prompts.

The solution was to reduce ambiguity:

  • freeze accepted product decisions;
  • break work into bounded changes;
  • document authority and invariants;
  • validate every meaningful change;
  • stop repeating the same unsuccessful editing mechanism;
  • use Codex for repository-level implementation and evidence-based debugging.

Another challenge was that technically valid model output could still be semantically wrong.

Some responses:

  • returned valid JSON;
  • matched the schema;
  • completed successfully;
  • still misunderstood the actual product decision.

One calibration case interpreted a single portfolio decision as multiple independent assignments.

That exposed a harder class of AI failure: output that passes technical checks while remaining conceptually wrong.

This led to stronger prompt calibration, provenance handling, deterministic safeguards, and semantic evaluation.

What judges can verify

Judges can verify that:

  • AI suggestions remain separate from accepted PM-owned content;
  • manual edits invalidate older suggestions;
  • deterministic Demo mode works without provider access;
  • Live AI is invoked only through explicit user actions;
  • reviewed content produces a deterministic Discovery Summary;
  • presentation-ready Markdown can be downloaded and imported into Gamma;
  • reset clears the prior assignment and workflow state.

What I learned

The most important lesson was that successful AI-assisted development requires an operating system for judgment.

AI tools became more effective when I supplied:

  • clear canonical context;
  • bounded scope;
  • explicit acceptance criteria;
  • stable product decisions;
  • evidence and tests;
  • a defined owner for every important decision.

The shift from loosely directed vibe coding to Codex-led, canon-guided engineering improved reliability, reduced wasted attempts, and made the final implementation easier to explain and defend.

It also improved speed. Once the work moved from broad iterative prompting to bounded repository-level implementation, I was able to diagnose problems more precisely, preserve accepted behavior, and complete changes with less rework.

That development lesson became the product thesis:

AI should shorten the path to a finished artifact without taking ownership of the judgment behind it.

I also learned that the most important AI-product work often happens around the model:

  • defining authority boundaries;
  • protecting user edits;
  • preserving provenance;
  • separating suggestions from accepted state;
  • designing deterministic fallbacks;
  • testing semantic behavior, not only technical validity.

Codex was especially valuable as an engineering collaborator across the repository, while the product strategy, prioritization, design choices, and acceptance decisions remained mine.

What’s next

Next steps include:

  • further usability refinement;
  • stronger synthetic evaluation fixtures;
  • improved presentation export and Gamma handoff;
  • broader calibration against ambiguous real-world assignments;
  • clearer judge-facing and portfolio documentation;
  • continued refinement without expanding AI decision authority.

The broader build process, tradeoffs, failures, and implementation evidence will be documented in the accompanying public case study.

Built With

Share this project:

Updates

Submission history