clement13.net
Original photo: Machine mécanique à prédire les marées, faite de poulies, de câbles et de cadrans en laiton.
Description
Machine mécanique à prédire les marées, faite de poulies, de câbles et de cadrans en laiton.
Source
Steven Fine · original page
Licence
CC0 Public domain
Original photo, unretouched. The background is a version of it stylised by the site.

AI in Planning and Version Control Tools

You will know where AI truly delivers value in tracking tools (writing and breaking down stories, summaries, deduplication, estimation, risk detection) and in version control…

Guide≈ 9 min readPartly checkedPartial checkThe main facts were checked by searching the cited sources. The items below still need checking before relying on them.To re-check
  • Disponibilité de l'agent IA de Linear par palier tarifaire non confirmée par une source primaire.
  • Paliers exacts de GitLab Duo et de GitHub Copilot non revérifiés sur sources officielles.
Written with AI assistance; sources are cited at the bottom of the page. An error? Report it via clement13.net.
Reading
In Brief
  • You will know where AI truly delivers value in tracking tools (writing and breaking down stories, summaries, deduplication, estimation, risk detection) and in version control (code review, commit messages, conflict resolution).
  • You will have a gain / risk / maturity /5 table for each use case.
  • You will know how to set guardrails (confidentiality, hallucinations, accountability, hidden debt) and write useful prompts.
  • AI features evolve very quickly: any dated element “state 2026-10” must be rechecked before making a decision.

Context: team of 5 to 15 people, data/BI project (SQL Server datamart, Power BI reports, TFVC/Azure DevOps Server). Ratings /5 = contextual assessments (RATING). For project management in general, see AI in Service of Project Management (General Then Data); for the cross-functional summary, Cross-Functional Summary — AI Contribution.

On this page

Level: 🟢→🔴

🟢 Novice — What “AI” means here#

In planning tools, “AI” almost always refers to a language model (LLM) connected to the tool's data (tickets, comments, wiki, code). It can rephrase, summarize, classify, propose a draft, search by meaning. It can neither decide, nor guarantee accuracy, nor know your team's unwritten context. An AI draft that is reviewed is a gain; an AI draft that is not reviewed is debt.

Three levels of autonomy:

Level Example Who decides
Assistant (suggests) description draft, summary the human accepts or rejects
Copilot (acts under supervision) applies labels, proposes a breakdown the human validates in bulk
Agent (acts alone within a scope) takes a ticket, opens a pull request the human reviews the result, not the path
✅ Good practice

Start with the assistant level on non-sensitive text, measure quality on 20 real cases, and only then expand.

🟢 Novice — Where to find AI today (state 2026-10)#

Tool AI features (to be rechecked)
GitHub Copilot completion, chat, code review on PRs, coding agent assignable to an issue
Azure DevOps integration with GitHub's coding agent from an Azure Boards work item (preview in 2025, general availability rollout announced in December 2025; GitHub repositories required, therefore unusable with TFVC); extensions and agents via API/MCP
Jira / Rovo (Atlassian) summaries, content generation, search, agents; Rovo credits included per user per month in paid plans (Standard, Premium, Enterprise), beyond that billed by usage according to a cap set by the administrator
GitLab Duo code assistant, ticket/MR summaries, pipeline explanation (depending on tier)
Linear assisted triage, summaries, assignable agents; integrated into paid tiers (to be verified)
Notion, Asana, Monday… summaries, writing, field filling
General-purpose assistants (Claude, ChatGPT, Microsoft Copilot) all of the above, via copy/paste or connectors
⚠️ Pitfall

Symptom: a tool promises “free AI” then usage explodes. Cause: usage-based priced models (credits). Remedy: cap by policy (budget, user group), measure cost per use case, compare with actual time savings.

🟡 Practical — Use cases in planning tools#

Writing and improving stories#

AI turns an informal request (“the North region numbers are wrong”) into a structured story (context, value, acceptance criteria). Real gain on form, risk on substance: it fills gaps with plausible assumptions.

Typical prompt:

You are a BI analyst. Here is a user's raw request: “{text}”.
Context: SQL Server datamart, Power BI reports, measures in euros, offset fiscal calendar.
Produce: (1) a story in the format “As a… I want… so that…”, (2) 5 acceptance criteria
that are verifiable with numeric thresholds, (3) the list of QUESTIONS to ask the requester before starting,
(4) the assumptions you made. Do not invent any business rule: mark it as to be confirmed.
💡 Expert tip

Always ask for open questions and assumptions. The biggest risk is not weak text, it's text that is convincing and wrong.

Work breakdown#

AI proposes breaking an epic into stories or a story into tasks. It is good at listing, bad at sorting by value and at respecting real constraints (source dependencies, delivery windows). Apply the INVEST test to each proposal (see Scrum in Practice); reject “layer-based” breakdowns (one story for the database, one for the report) that do not deliver standalone value.

Ticket and thread summaries#

Summarizing 80 comments into 5 lines, decision changes, people involved. High gain, moderate risk: the summary omits what seems secondary. Use it to orient yourself, not to decide; keep the link to the original.

Deduplication and semantic search#

Meaning-based search finds similar tickets despite different wording. Deduplication is suggested, never applied on its own: two similar tickets may have different conditions.

Estimation#

AI can compare a ticket to history (“6 similar tickets took between 2 and 5 days”). It does not replace team estimation (planning poker is mainly used to surface gaps in understanding). Use AI to provide references, not a number.

Risk and anomaly detection#

Flagging aging tickets, unresolved dependencies, overcommitted sprints, incident keywords. Useful as a safety net, with explainable thresholds; opaque alerts are ignored after a week.

Triage and classification#

Labeling, routing, assessing the criticality of a support request. Strong gain at high volume; check a weekly sample and track the error rate.

Writing reports, release notes, and meeting notes#

From tickets linked to a release package, AI writes readable release notes. Verify facts (numbers, dates, scope): this is formatting, not analysis.

🧪 Example

For a monthly delivered release package, we extract via query the list of tickets linked to changesets, ask AI to classify them (bug fix / enhancement / technical), and draft notes at two levels (user / technical). The team lead reviews in 10 minutes what used to take 90 minutes, but systematically corrects the “impact on figures” section, which AI cannot infer.

🟡 Practical — AI and version control#

Use case Detail Limits
Commit / changeset messages from the diff, propose a clear message describes the what, rarely the why; complete manually
Code review detects common errors, inconsistencies, omissions limited business understanding; false positives; does not replace human review
Diff explanation summarize a large change for the reviewer can hide a critical detail
Conflict resolution proposes a merge the risk is a plausible but wrong merge: always test
Test generation test skeletons, edge cases tautological tests; verify that assertions test behavior
TFVC → Git migration helps script and explain commands does not replace validation of converted history
Coding agent takes an issue, opens a PR human review required, limited scope, no access to secrets

SQL and BI: specifics#

  • T-SQL / DAX generated: syntactically correct, sometimes semantically wrong (join that duplicates, misunderstood filter context). Always replay on a reference figures dataset.
  • SQL script review: explicitly ask to verify idempotence, transactions, missing indexes, NULL in joins, and implicit conversions.
  • Sensitive data: never paste real customer data into an unapproved service; anonymize or work on the schema only.

Example review prompt:

Review the T-SQL script below (SQL Server, compatibility level 130).
Check: idempotence (re-runnable without side effects), error handling, joins that
duplicate rows, behavior with NULL, potential locks, qualified object names.
Respond as a table: line | issue | severity | proposed fix.
Do not rewrite the entire script.
⚠️ Pitfall

Symptom: generated code compiles, passes quick review, but produces a 2% wrong total for one customer. Cause: an undetected one-to-many join that AI judged plausible. Remedy: systematic reconciliation testing (total before/after, by customer) for any SQL/DAX logic change, whatever the code source.

🔴 Expert — Summary table: gain / risk / maturity#

Scales: gain (time or quality improvements), risk (impact of an undetected error), maturity (current reliability of the function). Context: team of 5–15, data/BI. Expert assessments, not measured.

Use case Gain /5 Risk /5 Maturity /5 Prerequisites Guardrails
Rephrase / write a story 4 3 4 clear request open-ended questions + required assumptions
Generate acceptance criteria 4 3 4 business context provided PO validation
Break down epic/story 3 3 3 structured backlog INVEST test, value by slice
Summarize a ticket / thread 4 2 4 readable comments link to original
Deduplicate 3 2 3 clean ticket database human confirmation
Estimate (historical references) 2 3 2 reliable history never a mandated number
Detect risk / delay 3 2 3 reliable metrics explainable thresholds
Sort / classify requests 3 3 3 stable taxonomy control sample
Release notes 4 2 4 tickets linked to deliveries review of figures
Commit message 3 1 4 readable diff complete the “why”
Code review (assisted) 3 3 3 written conventions human review maintained
Conflict resolution 2 4 2 automated tests required tests, never blind
Test generation 3 3 3 behavior targets assertion checks
Generated T-SQL / DAX 3 4 3 reference dataset numeric reconciliation
Coding agent on ticket 3 4 2 robust CI, Git repository narrow scope, review, no secrets
WIQL/JQL/OData queries in natural language 3 2 4 known field schema run on a sample
💡 Expert tip

Risk is not in the visible error, but in the plausible error. Where an error is costly (financial figures, RLS access rights, personal data), the required maturity is higher, regardless of the function's rating.

🔴 Expert — Guardrails#

Confidentiality and compliance#

  • Classify data: what can be shared (generic ticket titles) and what cannot (customer names, personal data, secrets, queries containing connection strings).
  • Choose the contractual scope: does the tool use your data to train its models? Where is it processed (region)? Retention? Check this in the provider's terms and validate with the DPO; GDPR: legal basis, informing individuals, minimization.
  • Log: who used AI to produce what (especially for agents).

Hallucinations and verification#

Risk Countermeasure
Invented fact (a business rule, a reference) require sources; verify figures, names, and references; refuse to produce when information is missing
Apparent consistency, fundamental error reconciliation tests, cross-review
Obsolescence do not rely on model memory for recent versions or pricing; check official documentation
Confirmation bias explicitly request a counterargument

Responsibility and skills#

  • Responsibility remains human: the name in the changeset or the acceptance testing sign-off commits the person, not the tool.
  • Hidden debt: code or text produced quickly but not understood becomes a cost later; enforce “I can explain what I accepted”.
  • Junior skills: AI can short-circuit learning. Plan exercises without assistance and reviews focused on “why.”
  • Dependency: keep the ability to work without the tool (outages, provider changes, costs).

Progressive rollout#

  1. Frame: use cases, authorized data, owner.
  2. Experiment on a limited scope, with quantified success criteria (time saved, error rate, satisfaction).
  3. Measure over 4 to 6 weeks; compare with a period without AI.
  4. Decide: expand, adjust, or stop.
  5. Maintain: quarterly review (functions, cost, incidents, compliance).
⚠️ Pitfall

Symptom: the announced gain (“30% faster”) does not show up in timelines. Cause: measuring text production instead of the end-to-end flow; reviews and corrections absorb the gain. Remedy: measure lead time and escaped defects before/after, not the number of generated characters. See 10 — Metrics.

🔴 Expert — What AI does not replace#

  • Priority judgment: arbitrating between two competing values entails product responsibility.
  • The relationship with stakeholders: understanding what a user says (and does not say).
  • Business acceptance testing: deciding that a number is correct requires business knowledge; see acceptance testing and validation (matrix).
  • Architecture decisions: AI suggests options; the trade-off depends on context, accepted debt, and organization.
  • Team trust: a retrospective written by a machine is not a retrospective.
✅ Good practice

Document an AI usage charter in the wiki: authorized use cases, prohibited use cases, review rule, signature of generated content when published. Review it twice a year.

See also#

✻ Written by Claude Sonnet 5.5