Skip to main content

Write an AI engineering task that can be accepted

A good task does not prescribe every line of implementation. It makes the final outcome, allowed impact, non-negotiable boundaries, and proof of completion explicit.

Outcome: What must work when the task is complete.

Current facts: Known devices, Pages, Graphs, data, and site conditions.

Scope: Which Pages, Graphs, Objects, Queries, variables, or Scripts may change.

Constraints: What must not change, which values must not be guessed, and whether the app must be stopped.

Acceptance: Which diagnostics, Build, Run, or Debug checks are required and what success looks like.

Output: State the impact and risks before editing; finish with actual changes and anything not verified.

What AI should do before editing​

  1. Read the relevant files you attached with @.
  2. Inspect the current Objects, editor-supported Page controls, Graph methods and nodes, and Query definitions.
  3. Run current diagnostics and separate pre-existing errors from the requested change.
  4. Stop and ask when device semantics are insufficient instead of guessing.
  5. Give a short impact statement: what will change, why, and how it will be verified.

What to check after the edit​

  • Actual changed files match the stated impact
  • Problems contains no new errors
  • AI validated the final files, not only an intermediate draft
  • Graph or custom-code changes completed an app Build
  • Runtime state permits the new assets to load
  • Pages, device actions, permissions, and failure messages match site needs

Example: Page-only work​

Outcome: Add status cards for three axes and an alarm area to the existing home page.

Scope: Change only the home page and one reusable Component. Read existing Objects but do not add device actions.

Constraints: Status labels must come from current object descriptions. Do not guess the physical roles of Axis1, Axis2, or Axis3.

Acceptance: Page and Component diagnostics pass. Tell me which object field each card uses. Do not execute physical motion.

Example: Page and Graph work​

Outcome: Make the “Start cycle” button call the existing PackagingStation object's StartCycle method and show running and fault state on the page.

Current facts: Inspect object descriptions, existing Graph methods, and the current page action first.

Scope: The PackagingStation Graph and current Page may change. Do not modify Safety, Pulsar, or PLC configuration.

Constraints: Long waits belong in an object capability or a bounded Graph wait. The Page Method remains UI glue.

Acceptance: Graph diagnostics and app Build pass; Page diagnostics pass; Debug verifies normal and timeout paths; no physical equipment is connected.

How to split a large task​

Split work along boundaries that can be accepted independently:

  1. Confirm device semantics and object capabilities.
  2. Orchestrate the Graph and its failure paths.
  3. Build the Page and interactions.
  4. Add Queries, permissions, build, and delivery.

Each stage needs its own diagnostics and acceptance result. Avoid using one conversation to rewrite the device, process, interface, and deployment layers together.

When work must stop​

  • Device purpose, address, unit, or process meaning is unclear
  • Safety or physical interlocks may be affected
  • AI would need production credentials, an API key, or a password
  • The app is running while the planned change affects resources used by the running instance
  • The next action is deletion, a production write, or a deployment that is difficult to reverse

A person must provide the missing facts or approve the action before work continues.