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, QG programs, data, and site conditions.

Scope: Which Pages, QG programs, 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, QG 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.

Check context usage​

For an existing session, the bottom of the composer shows a context indicator. The bright arc grows clockwise from the top to show used context, while the muted track shows the unused portion. Hover for one second or focus it with the keyboard to see the percentage used, current token count, and model context window. The ring keeps the same theme color at every usage percentage. Immediately after context compaction, exact usage temporarily appears as ? in the hover details and becomes accurate again after the next AI response.

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
  • QG or custom-code changes completed an app Build
  • After a failed Build, AI changed source from Problems diagnostics instead of automatically rebuilding the same saved version
  • 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 QG 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 QG methods, and the current page action first.

Scope: The PackagingStation QG and current Page may change. Do not modify Safety, Pulsar, or external-device configuration.

Constraints: Long waits belong in an object capability or a bounded QG wait. The Page event function remains UI glue.

Acceptance: QG 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 QG 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.