What is unassisted coding?

Most working developers use documentation, search, teammates, and increasingly AI. That is ordinary engineering. Unassisted coding is useful because it changes one variable for a short time: the assistance disappears and your own reasoning is easier to inspect.

The point is not to prove that you can build a product with one hand tied behind your back. The point is to find out whether a small task still feels automatic when you need to understand a suggestion, chase a production bug, or explain why a change is safe.

A timed exercise can show where you paused, guessed, or lost the thread. It can make a useful next-practice decision. It cannot diagnose the cause of that result. One missed tracing question could reflect unfamiliar syntax, time pressure, or a simple slip as easily as it could reflect a skill that needs work.

That is why repeated, comparable checks are more useful than a single score. A trend gives you context. A one-off result gives you a place to look.

Good unassisted exercises keep the domain small and put the relevant information on screen. Predicting a short program's output, comparing code to its docstring, or finding an inverted condition tests reasoning without turning the task into a memory contest about a framework API.

Start with short work. If you make the exercise large enough to require a codebase, setup, and a stack of documentation, you are mostly measuring endurance and familiarity with the environment.