AI-assisted engineering that keeps humans accountable

The useful version of AI-assisted engineering is not a free-form chat window next to a codebase. It is a workflow with source context, narrow permissions, reviewable outputs, and explicit verification.

The AI should help gather context, summarize state, propose implementation paths, write boring glue, and catch review issues. The engineer still owns the judgment: what should exist, what risk is acceptable, and whether the result actually works.

The difference sounds small until the system touches real work. A model that can read an Asana task, inspect a branch, summarize a pull request, draft a support note, and run tests is useful only if the human can see what it read, what it changed, and what remains uncertain. Without that trail, AI becomes another source of unreviewed work.

The pattern I use

• Start from the real system of record: repo, task, issue, incident, or customer thread.
• Ask for structured output instead of vibes.
• Keep verification commands attached to the change.
• Preserve links to PRs, tasks, and source material.
• Use AI comments and summaries as traceable work records.

This is how AI stays useful instead of becoming a second pile of unreviewed work.

What the workflow needs

The useful workflow is source-first. If the question is about a bug, the model should start from the ticket, reproduction notes, code, logs, and comments. If the question is about a release, it should start from the branch, pull requests, release notes, risk register, support context, and deploy history. If the question is about planning, it should start from the roadmap and the real engineering constraints.

From there, I want the model to produce something a human can inspect quickly:

• A short statement of the problem in its own words.
• The source material it used.
• The relevant files, tasks, or threads.
• A proposed next action.
• The verification command or manual check that would prove the next action worked.
• The uncertainty it could not resolve.

That last line matters. A good AI workflow should make uncertainty visible. It should not round a weak inference into a confident update just because the output looks cleaner.

A concrete example

My public Asana Agent Skill is built around this idea. It gives coding agents a local CLI for Asana instead of asking them to improvise against a web UI. The commands are deliberately concrete: fetch a task bundle, inspect comments, list assigned project work, create a daily briefing snapshot, organize My Tasks, summarize follow-up work, or prepare a project working set.

That shape matters because it gives the model a constrained job. It can pull task fields, comments, attachments, section context, tags, and project membership, then produce a reviewable plan. For write operations, the workflow requires clear AI attribution and a rendered Asana comment format, so the system of record shows what was authored by a model and why.

The point is not that Asana is special. The point is that AI needs a disciplined boundary around whatever system it touches. GitHub needs the same treatment: inspect the diff, name the risk, run the check, explain what remains. Support systems need the same treatment: cite the known facts, separate reproduction from theory, and give the next person a useful escalation path.

Where it helps

AI-assisted engineering is most useful at the edges where context usually leaks:

• Turning a messy task thread into an implementation-ready scope.
• Summarizing a large pull request for review.
• Converting release work into clear support and documentation notes.
• Finding stale assumptions across a project board.
• Drafting follow-up tasks after a review or incident.
• Comparing what shipped against what the roadmap promised.
• Keeping management updates tied to actual code, tasks, and risks.

These are not glamorous tasks, but they are where teams lose time. They are also where a model can help without pretending to own the final decision.

Guardrails

I use a few rules to keep the workflow honest:

• The model should show its source context.
• The model should prefer small, reversible changes.
• Any customer-facing or source-of-truth write needs human review unless the workflow is intentionally automated.
• Summaries should include risk and uncertainty, not only progress.
• Verification belongs beside the change.
• AI-authored comments should be labeled as AI-authored comments.

The goal is not to make AI feel magical. The goal is to make good engineering work less lossy. A teammate should be able to read the AI output and understand the state of the work faster than they could by opening every linked task, branch, and thread from scratch.