What engineering work disappears when AI writes the code?
by•
AI tools are changing what counts as engineering work. Writing code may take less time, while reviewing generated changes, tracing failures, correcting assumptions, and making product decisions take more.
The problem is that most of this work disappears. Tickets capture the request, commits capture the final change, and standups capture a compressed summary. The investigation between them is rarely visible.
Meridian is experimenting with capturing that activity locally and turning it into reviewable updates, without asking developers to maintain another reporting habit.
Which signal would be most useful to preserve: failed approaches, debugging context, review decisions, or the reasoning behind what finally shipped?
20 views
Replies
I think the most valuable signal to preserve is the reasoning behind what finally shipped.
Failed approaches and debugging context are useful, but without the final decision logic, future engineers still have to reconstruct the “why.” In an AI-assisted workflow, the code itself becomes less of a differentiator — the important context is the tradeoffs, assumptions, and constraints that shaped the solution.
Capturing decisions like “we chose this architecture because X mattered more than Y” could make future maintenance, onboarding, and AI collaboration much more effective.
@stephanie_t0317 Thats a great insight, we want to capture this knowledge in meridian
This is where I think the conversation gets really interesting.
When AI makes coding cheaper, the bottleneck doesn't disappear, it just moves.
The scarce skill becomes knowing what to build, what not to build, which trade-offs to make, and how to judge whether the output is actually good enough for the real world.
AI may reduce the amount of engineering work. But it could also make good engineering judgment more valuable than ever.
@kailong_20 The hard part shifts from producing code to preserving the reasoning behind it. Which trade-offs, rejected options, and review decisions do you think teams are most likely to lose?
@akarsh_hegde I think rejected options are the easiest to lose, especially the “why not” behind a decision. The final code tells us what was built, but the reasoning tells us what constraints, risks, and trade-offs shaped it. That context becomes incredibly valuable when the system evolves and someone has to revisit the decision months later.
@kailong_20 How do you capture the “why not” without adding another documentation burden for the team?
Strong framing. The signal I’d most want preserved is the link between the customer evidence, the decision, and the result. i.e. not only the reasoning behind the final code.
In product work, the “why” has three parts: what customer signal created the bet, which constraints and trade-offs shaped it, and what evidence would prove or falsify it.
Without those links, people review a plausible diff and still have to reconstruct intent. That is the loop we’re building with Zentrik Loops: carry customer reason into delivery, then bring what ships back as evidence. How's that showing up in your map? Curious whether Meridian is capturing that upstream signal too, or mainly the execution trail?
@jalcantara We’re mainly capturing the execution trail today, including investigation, decisions, constraints, and outcomes. The upstream customer signal is the next important link, so the work can be traced from the original evidence through delivery and back to the result.
@akarsh_hegdeThat's a good seam to sew. Once upstream evidence is linked, the execution trail can answer both “why this bet?” and “what happened after it shipped?” I’d be especially interested in how you keep the original signal inspectable when the decision changes during investigation: the rejected options and constraints are often what make the final result understandable later.
That's where the difference between preserving activity and preserving product intent shows up. Have you found a lightweight shape for that upstream link yet?