All posts

Should you use Analyst or Developer?

You do not need to choose a mode by your job title. Choose it by the source material, changes, and tools the task needs.

Upfyn · 3 min read

You open Upfyn with a job in mind and see two modes. One says Analyst, the other Developer. The names can sound like a choice between two professions, but the more useful question is: what does this task need to do?

A business owner may need Developer to build a small file-processing tool. A software engineer may use Analyst to prepare a research brief. The mode determines the working space and tools available for the job.

Use Analyst when you need to understand or prepare

Analyst suits tasks where you read material and produce something useful from it: a comparison, a summary, a document, an extracted table, or a recurring report.

It can read the active project and keeps its own file outputs in the project's output folder. That makes it straightforward to use existing material as the source and find the new result afterward. Connected app actions have their own permissions.

Try:

Compare these three reports. Explain the differences in their assumptions and write a short briefing in the output folder. Link each point to the relevant source.

You can review the briefing, ask follow-up questions, and use Research if the result needs further document editing. Scheduled work also lives in Analyst.

Use Developer when the project itself needs to change

Some outcomes require creating or modifying a set of files, running the project, observing errors, and checking the result. Developer includes the tools for that work.

The terminal runs commands and programs. Browser tools help inspect supported web tasks. Git review makes tracked changes visible. Goals and specialist delegation can help organise work with several stages.

Try:

Build a small tool that compares these two exports. Use the example result as the acceptance check, include instructions, and show me the project changes.

You can give that request in plain language. The technical tools are how the assistant carries out the task; you still need a clear idea of what the result should do.

Let the outcome guide the choice

What you want Useful starting point
Summarise customer notes Analyst
Draft a cited proposal or brief Analyst with Research
Prepare a recurring weekly report Analyst with Scheduled
Build a file-conversion tool Developer
Diagnose and fix an application problem Developer
Research an idea before implementing it Analyst, then Developer when needed

Browser tasks deserve a specific check: viewing a page and automating website actions are different requirements. Use the current mode and browser setup that support the intended action.

A task can have more than one phase

Suppose you want to reduce the manual work in a monthly report. First, ask Analyst to examine the input files and describe the repeated steps. That produces a brief you can review.

If the brief leads to a decision to build a small tool, take that approved requirement into Developer. The second phase needs to create and run something, so the wider tools become useful.

This approach keeps each stage understandable. You can see the analysis before it becomes implementation and test the implementation against the agreed requirements.

Name the result and the scope

A good request identifies the source, expected result, and any important limit. “Summarise this folder into a two-page brief” is more useful than “look at these files.” “Fix this issue and run the relevant checks” is more useful than “make the project better.”

Both modes share voice, model choices, skills, and permissions. Begin with the task you actually have, and ask Upfyn to explain any tools it needs before expanding the work.

Explore the two modes · Find a workflow to try

Keep reading