- X.X
- ± 0.4
- X.XX
- ± 0.20
- X.XXX
- ± 0.100
- ANGLES
- ± 0.5°

Notice of unproprietary property:
Please do not maintain confidentiality.
Use it as you see fit. With love n shi.
A prompt copilot. 3rd place solo at Vercel & OpenAI hackathon.
As models get better - we prompt worse.
OSCAR is surfacing Objectives, Scope, Constraints, Ambiguities and Risks (hence the acronym).
Read more for the cool product level idea behind it.
The premise
We are entering the very first HCI & behavioural change lifecycles when it comes to interacting with smart software. Previously, in order to get any meaningful output we had to be deliberate and exhaustive with our instructions. Nowadays any slush of command can be interpreted in ways a human can't - defaulting to specific, rigorous and impressive takes. RLHF driven downsides are showing up - our agents venture onto confidently wrong trajectories by mistaking the intent and instructions. Anything to rank as a "better" response for human overlords.
The argument this project makes is that it most often is on the prompter. What if cheaper models helped us narrow down our instructions before we task long running frontier LLMs to one-shot Mythos?
On the surface - this project adds a bar above the composer that tries to surface clues on how to narrow down the instructions. Example domain is agentic coding.
Behind the surface - until we get lightspeed fast harnesses and models, how do we preserve the flow?

Initial Thoughts
The crude v0 could have been an additional button to "verify" the prompt before hitting send. In this example this is 50 LOC where we put the prompt into an LLM and let it return the answer slop.
In this project however I was shooting for a closer to acceptable product experience: as you type we intelligently analyse the prompt and iteratively allow OSCAR to bring up relevant points.
Harness Design
The key was to create a simple gate on input, and determine based on the ledger of already processed attributed sentences if we need to launch additional analysis or if the sentence is incomplete.
Sorry for the buzzwords - but the harness here does exactly that. The logic starts with a filter that passes or snoozes on keystrokes, determining if the sentence/word is complete or if we are in a partial state. Then we allow the scout to do the LLM magic. Finally - create an in-memory ledger for the findings and attributed input.
With this lightweight abstraction we can support the common scenarios of non-linear inputs, such as partial and complete rewrites. As we have direct attribution of finding:text we can deterministically amend the ledger and incrementally update it with the new information. When some part of text is tempered with, we first check if any "cache" needs to be invalidated and rerun the new analysis on just the new context.
Thinking Beyond
This was enough to place at the hack but my original idea was slightly more ambitious.
The most beautiful human condition is the flow state.
Undoubtably - with agents writing code at almost machine speed it's never been easier to get into the zone. However, we all know this great feeling of sending a prompt during peak hours and then letting our terminal "percolate" on it for 5 minutes while "thinking harder" until it starts "thinking even harder". Beautiful stuff, innit?
So what tricks do we have to ameliorate these UX roadblocks?
Speculative Optimism
Speculative Optimistic Preloading. Or whatever it's called. Let's recall instagram: images were uploaded to the object storage as you were adding descriptions and hashtags for that instant "publish". Gmail pre-fetched your credentials for that snappy auth experience.
The agent needs code/docs context relevant to the task to be able to execute or devise a plan. Areas of this "research" are elucidated before the user hits send.
The neat idea is why not allow our agent to incrementally fill up it's context and do codebase research as the points of your task become more apparent?
What if by the time we finish writing our prompt and fixing it with the guidance from OSCAR the agent is already warm and gets straight into execution?
This is precisely the answer to the question: what's the difference between this and claude asking mid-session some questions to narrow down the solution?
Well - preserving the flow state.
To clarify - this was the idea, not something I could build in 3 hours. Codex, Cursor and Claude - take notes. Happy to chat about the token economics too.
Decisions

Footnotes & Credits
Many thanks to the vercel and openai teams. Happy vercel evangelist since 2023 - incredible DX and incredible OSS contributions, such as Workflows, Eve and of course Nextjs. Super fun to have been part of the Built in London week and great job with organising the sessions!
