A candid retrospective from an industrial water optimization project I recently joined.
Executive Summary
- AI made the work more visible, not automatic. Across 19 audited sessions, it helped turn an unfamiliar operational challenge into a sequence of research, calculation, review, and communication tasks that people could inspect.
- Human review remained the quality gate. The history included 411 user turns and 329 completed responses before the audit, showing that progress came through active direction, checking, and revision.
- Iteration carried a real cost in attention. Requests to rerun or recalculate work appeared 43 times, making earlier agreement on definitions a practical priority.
A Project I Recently Joined
The work was about making a complex industrial process easier to understand before trying to improve it.
A project I recently joined is exploring how an industrial evaporation system can measure water production more reliably and identify efficiency opportunities while keeping equipment safety and stable operation in view.
The central challenge was not simply finding a clever model. It was agreeing on what the measurements meant, where uncertainty remained, and how an analytical insight could become a cautious, human-reviewed next step.
A polished answer is useful only when the people closest to the operation understand—and trust—its boundaries.
AI Became a Five-Role Collaborator
AI was most useful when it had a narrow role inside a human-led workflow.
Across 12 main working sessions, it moved between five practical roles:
- Research companion
- Calculation assistant
- Draft writer
- Critical reviewer
- Delivery organizer
Seven additional child sessions handled smaller execution or review tasks.
This division of labor kept the work concrete. A person still chose the question, tested the interpretation, and decided what could be shared. AI helped make each handoff clearer and faster.
That distinction matters: a collaborator is valuable when it clarifies responsibility, not when it blurs it.
The Best Results Came From Human Review
The strongest pattern was review after every meaningful step.
The audit recorded 411 historical user turns and 329 completed responses before the review session. Those exchanges were not background noise. They were where the scope was narrowed, calculations were challenged, language was corrected, and evidence was compared with operating reality.
For readers outside industrial work, consider the idea of a “soft sensor.” It is simply an estimate built from other measurements. It can be useful when a direct measurement is unavailable or unreliable, but it still needs people to test whether the estimate makes sense under real operating conditions.
AI did not independently make operational decisions. It supported the people who remained responsible for them.
More AI Activity Also Created More Rework
Speed made it easier to begin—but it also made it easier to begin before the question was settled.
The audited history contained:
- 28 explicit implementation-plan requests
- 43 rerun, recalculation, or retraining requests
- 11 explicit corrections, reversals, or rollbacks
These categories can overlap, and they should not be treated as failure rates. Instead, they are signals of how the workflow evolved.
In many cases, a rerun was not caused by faulty code. It happened because a definition, assumption, calculation method, or evidence boundary had changed.
This reveals an important weakness of AI-assisted work: a fast collaborator can execute an unclear instruction just as quickly as a clear one. When the underlying question changes, speed can multiply the cost of revisiting everything downstream.
The earlier a team agrees on definitions and evidence boundaries, the less energy it spends circling back.
The Workflow Eventually Became More Trustworthy
Trust improved when AI output was treated as a draft that had to earn its place.
The work gradually became separated into four distinct activities:
Ask → Execute → Review → PublishResearch findings were also divided into clearer categories:
- Verified observations
- Data associations
- Assumptions
- Items requiring field confirmation
- Historical results no longer treated as active evidence
This structure did not remove uncertainty—and it was not supposed to. Instead, it made uncertainty visible and traceable.
That prevented a tentative result from quietly turning into an operational recommendation.
Reliable project work depends less on producing answers quickly than on preserving the reasoning that makes those answers trustworthy.
Five Lessons I Would Carry Into the Next Project
1. Freeze definitions before running expensive work
Agree on the question, calculation method, validation rules, and success metrics before starting a full analysis or model run.
If a definition changes, treat it as a new experiment rather than silently overwriting the previous one.
2. Give each conversation one clear deliverable
A single conversation should not simultaneously handle research, model development, troubleshooting, reporting, and project organization.
Shorter, focused sessions reduce context drift and make it easier to verify what was actually completed.
3. Keep one source of calculation truth
When the same calculation is copied across several notebooks or reports, every change must be repeated—and every copy can drift.
A shared calculation source should produce the results used by all downstream analyses and reports.
4. Validate cheaply before running at full scale
Before launching a long computation:
- Test a few manually reviewed examples
- Run a small sample
- Confirm the output structure
- Only then process the complete dataset
A five-minute check can prevent hours of unnecessary reruns.
5. Publish only after the evidence is frozen
Editing a report while the underlying analysis is still changing creates avoidable rework. Charts, numbers, and explanations quickly fall out of sync.
The safer sequence is:
Freeze definitions
→ Validate the analysis
→ Freeze the evidence
→ Update the reportWhat I Would Ask Next
The next gains depend on confirming what the measurements mean in the real operating environment.
I would ask:
- Which measurement relationships still require field confirmation?
- Which rules must be frozen before the next validation?
- Which findings are strong enough for a small, reversible trial?
- How should the team monitor whether those findings still hold as operating conditions change?
A useful retrospective should improve the next decision, not merely describe the previous one.
Final Reflection
This experience did not show that AI can independently solve a complex industrial problem.
It showed something more practical: AI can make research, calculation, revision, and communication dramatically faster—but only when the surrounding workflow gives that speed a trustworthy direction.
The goal is not to ask AI to do more.
The goal is to build a process in which AI can be trusted to help.