Skip to main content

AI and human responsibility

Theseus recommends AI-first, not AI-only. Start by asking AI to understand the goal, inspect the current App, and complete work that can be automated. People define the boundaries, understand the result, validate real behavior, and approve high-impact actions.

Core concepts are not a requirement to hand-edit low-level files. They give you enough control to tell AI what to change, inspect what it changed, and take over when needed.

Why this matters​

AI can accelerate screen, workflow, query, and code work, but it cannot infer the real process, wiring, equipment limits, or organizational responsibility from nothing. Clear ownership makes everyday work faster without turning “generation finished” into “ready for production.”

When you will encounter it​

  • asking AI to create a Page, Graph, Object, Query, or Script;
  • asking AI to fix Problems, build errors, or runtime faults;
  • changing PLC, motion, Vision, Safety, permissions, or external-system writes;
  • preparing Run, Debug, Deploy, Stop, deletion, or release;
  • answering an AI question about goals, constraints, file scope, or acceptance criteria.

One shared workflow​

Use the same closed loop whether AI or a person does most of the implementation:

  1. State the goal: describe the business outcome you need.
  2. Set the scope: name the resources AI may change, what must remain untouched, and the intended Runtime target.
  3. Ask AI to inspect the current App: base the impact assessment on existing Pages, Objects, Graphs, Variables, and Queries.
  4. Create or modify: AI completes the authorized work and lists the affected resources.
  5. Review in the editor: inspect Resources, properties, connections, and Problems instead of relying only on the AI completion message.
  6. Build and validate at runtime: run Build, Run, or Debug as appropriate, including the normal, error, and timeout branches.
  7. Approve: the responsible person approves high-impact changes before commit, deployment, or delivery.

A clear request can look like this:

Goal: Add a pre-start check to the current station.
Scope: You may change the startup Graph and related Page messages. Do not change Safety or device addresses.
Constraints: A failed check must block the start action and show a clear reason.
Acceptance: Build passes, and Debug verifies the success, failure, and timeout paths.
When finished: List changed resources, validation results, and items that still require human confirmation.

Who is responsible for what?​

TaskAI is well suited toA person must confirm
Pages, Components, text, and layoutCreate, adjust, and check bindings and consistencyOperators can understand the screen and avoid unintended actions
Page methods, Graphs, and general workflowsArrange steps, complete parameters, check types, and diagnose errorsProcess order, error branches, timeouts, and recovery policy
Objects, Queries, and custom codeGenerate structure, wrap calls, and fix diagnosticsReal protocols, addresses, units, authentication, and external write destinations
PLC, motion, and VisionAssist with configuration, generate candidate implementations, and analyze test resultsSite parameters, equipment limits, sample coverage, and trials on real equipment
SafetyExplain configuration, check consistency, and identify risksQualified engineers design and approve it; hardware safeguards remain independent
Users, roles, and permissionsSuggest a setup and find omissionsActual responsibilities, least privilege, and production accounts
Build and diagnosticsExecute available checks, collect errors, and help locate faultsBuild results are expected and runtime validation may begin
Run, Debug, Deploy, Stop, deletion, and releaseExplain impact, prepare test or operation steps, and analyze returned resultsAn authorized person starts and monitors the real runtime and explicitly approves high-impact actions

Enter API keys, passwords, and other credentials through the appropriate settings UI. Do not place them in ordinary conversations, prompts, Pages, Graphs, or source control.

Minimum human acceptance checklist​

  • AI's change list matches the scope I authorized.
  • I can find and explain the key Page, Object, Graph, Variable, or Query in the editor.
  • Problems contains no blocking error, and every required Build passes.
  • The correct Runtime target is selected in the Navbar.
  • Run or Debug covers the normal, failure, timeout, and recovery paths.
  • A responsible person confirmed real device addresses, units, motion parameters, external writes, and permissions.
  • Safety changes received independent engineering review and do not rely on an AI conclusion in place of hardware or certified safeguards.

Common misconceptions​

  • AI completion does not mean the runtime was updated. A save changes authoring state; the new runtime version still needs lifecycle validation.
  • Understanding concepts does not mean hand-editing JSON. You only need to recognize resource ownership, runtime stage, and acceptance evidence.
  • A correct-looking screen does not prove that device logic is safe. Real actions, errors, and interlocks require separate validation.
  • A successful Build does not mean ready for production. It only proves that required build outputs can be generated.
  • AI is not only for generation. It is also useful for explaining an existing App, comparing options, checking impact, and diagnosing problems.
  • People who do not use AI still use the same editor and acceptance workflow. AI is a collaboration entry point, not a separate engineering format.

Next step​