Curiosity.
With a paper trail.

Choose a task with a clear result and a recognisable cost. A bug that must be fixed is a better starting point than an open-ended invitation to build something impressive. Write down what a satisfactory outcome means before the run begins.

Specify which files, tools, and services the system can reach. Set a spending limit and a stopping condition. Keep production access separate. A failed experiment should teach something without becoming an incident.

Save the patch, test results, tool activity, elapsed time, and human interventions. The final summary is not the result. Include abandoned attempts and repairs, because those are part of the cost of getting useful work done.

Compare a new model, workflow, or permission policy against a stable reference. Repeat tasks where practical. If everything changes together, a better result may be welcome, but its cause is still unknown.

Separate an observation from an interpretation and a proposal from a completed experiment. These field notes are analytical essays, not a claim that a fully autonomous company already exists. When measured results are available, they should come with their conditions and limitations.