A research briefing may require searching, downloading, deduplication, reading, comparison, formatting, and publication. Imagine organizing it through applications: a browser for sources, a spreadsheet for records, a document for the report, then a shared page.
When agents can call tools and write scripts connecting these steps, an interesting question appears: will the unit of organization shift from the application we open to the task we intend to complete?
I have used the idea that work is becoming coding to explore this direction. For an essay, I would make it more precise: more intermediate steps can become executable processes, while deciding what to do, what to trust, and who may act remain separate problems.
There is an unwritten task behind the operations
“Turn these papers into a briefing” sounds clear. Execution still requires a reader, a research question, a search boundary, inclusion criteria, and a way to handle conflicting findings.
A person may supply these conditions silently while moving through applications. Delegation makes their absence visible. An agent can create the correct table with the wrong sources, or fill every section without supporting the reader’s decision.
One requirement of AI-native work, as I see it, is to expose judgments previously hidden inside operations. Goals, inputs, tools, constraints, acceptance criteria, and the next recipient become parts of the task.
This need not produce a long prompt every time. Recurring conditions should live in stable materials and procedures, leaving the conversation to address what differs this time.
Execution, judgment, and authority are separate boundaries
Downloading a file is an execution capability. Judging whether it applies requires evidence, rules, and evaluation. Sending the result to a client also requires authority.
Combining these into one completion action can silently turn technical capability into decision rights. Requiring approval for every routine read, however, can destroy continuity.
I would divide work by its effects. Reversible operations within an authorized scope can proceed continuously. Actions changing external state need appropriate permissions. Important research judgments need inspectable review points.
Human involvement should have a specific purpose. Asking someone to approve a result they cannot understand preserves a person in the sequence without giving them the conditions for judgment.
Temporary code still needs durable working context
On-demand scripts can make small tasks possible without developing a complete application. The next run still needs the reasons for the previous approach, known input problems, and the output expected by its recipient.
Regenerating everything without versions, parameters, or acceptance evidence can turn flexibility into drift. Different results may reflect new sources or different execution; users need to distinguish them.
I would let exploration generate temporary tools and then stabilize the parts that recur and earn continued use. Not every script needs maintenance, and not every established procedure needs to be regenerated.
In my personal AI work system, I am concerned with connecting materials, tools, and task rules. That practice illustrates a direction; it does not establish that every professional task is ready for autonomous execution.
Scripts and agents have different places
For fixed inputs, explicit steps, and limited exceptions, a script may be sufficient. Having a model reconsider the process on every run may add little.
An agent may contribute more where sources differ in form, the next search depends on findings, or a choice among tools is necessary. That flexibility also increases the need to inspect its path.
Using an agent is therefore not an improvement by definition. Compare removed work, introduced errors, and handover quality on the same task.
A useful starting point is a specific gap, such as manual classification after downloading sources. Test whether the agent helps there before expanding responsibility. This makes its contribution easier to locate.
Faster execution can make acceptance the bottleneck
Suppose ten proposals can be produced in ten minutes, while carefully reviewing one still takes half an hour. More output has not made the decision faster; it has created more candidates competing for attention.
People need to decide in advance which differences matter. Does a research proposal ask an answerable question? Do sources cover the intended context? Are implementation conditions available? Clear criteria can prevent unnecessary generation.
I would also expect the system to report missing essential material. Continuing to write an apparently complete result may create more rework than stopping.
Acceptance criteria themselves remain fallible. Passing a checklist can still miss a problem in real use. For new tasks, people must inspect how results are used and revise the criteria, rather than only improve compliance with them.
Locate the human contribution in the actual process
“People do creativity; AI does repetition” is too coarse. Repeated screening may contain consequential professional judgment. Apparently creative generation may mostly rearrange familiar expressions.
I prefer examining each segment: what information it requires, which judgment can be expressed, who bears its consequences, and when new observation is needed. Work may move toward definition, organization, review, and correction, but these require real capabilities.
My claim that every problem deserves technical examination concerns finding actionable conditions. Programmable work is one possible execution route within it. Value choices, relationships, and irreversible facts cannot all be settled by that route.
The next practical questions concern turning research into reusable skills and whether automation reduces the burden on people.