The spec review prompt is the cheapest win on the list. Asking for unclear assumptions and edge cases before any code exists moves the expensive change you describe to the cheapest moment, and the lead still decides which of the flagged gaps actually matter.
Missing product context is the same reason human specs come back with questions. The fix works for both: the full picture, an example of good, and the constraints up front. Great topic, Gregor.
I appreciate the point about not recording one-to-ones. Someone should be able to try out a thought with their manager without wondering how a transcript will read later. A note about what you agreed to do next can preserve the follow-through without preserving every unfinished sentence.
This matters even more for new grads. Before I build, I have the model grill me on the plan and quiz me on the codebase and business logic. The pushback I keep repeating, like "don't over-engineer this," becomes a reusable skill.
The part about meeting transcripts and turning action items into Jira tasks hit close. Notes from our client meetings always missed something, so I built a small tool for it, Nytka. It takes the call recording, makes a transcript and builds business tasks from it that land in Jira as tickets. Even when the tasks need some editing, you at least have the real words from the call to go back to, not someone's memory of it.
Curious if Anton's team had the same problem with things getting lost between the transcript and the tracker.
The incident report part matches what I've seen, with one catch. An agent with access to almost everything (chat channels, old threads, notes) once gave me a clean root cause, and one step in the middle had no query and no log behind it. It was plausible filler, and I signed off on it. Someone else caught it before it reached the customer. To the model, a message someone wrote in a channel and a line the system logged weigh about the same: both are text. What fixed it for me was requiring a label on every claim: proven (query or log attached), hypothesis (with the command that would check it) or not verifiable (and what access is missing). Only the first kind goes into the root cause.
The point that your impact slides off the keyboard as you get more senior is correct, and it's the bit people nod at in the meeting and then go back to writing code. Drafting the design doc from the messy thread where the decision actually got made — yeah, that beats staring at a blank page and pretending it's thinking time.
"#1 New Release in three categories" before the print edition exists is a lovely piece of publishing arithmetic. Enjoy it, genuinely — just maybe don't put the badge in a design review.
AI won’t fix slow engineering teams if leaders keep making unclear decisions.
The biggest gains may happen before code is written: clearer specs, surfaced risks, and faster alignment across teams.
AI can accelerate execution. Leadership determines whether you’re accelerating in the right direction.
The spec review prompt is the cheapest win on the list. Asking for unclear assumptions and edge cases before any code exists moves the expensive change you describe to the cheapest moment, and the lead still decides which of the flagged gaps actually matter.
Missing product context is the same reason human specs come back with questions. The fix works for both: the full picture, an example of good, and the constraints up front. Great topic, Gregor.
I appreciate the point about not recording one-to-ones. Someone should be able to try out a thought with their manager without wondering how a transcript will read later. A note about what you agreed to do next can preserve the follow-through without preserving every unfinished sentence.
This matters even more for new grads. Before I build, I have the model grill me on the plan and quiz me on the codebase and business logic. The pushback I keep repeating, like "don't over-engineer this," becomes a reusable skill.
The part about meeting transcripts and turning action items into Jira tasks hit close. Notes from our client meetings always missed something, so I built a small tool for it, Nytka. It takes the call recording, makes a transcript and builds business tasks from it that land in Jira as tickets. Even when the tasks need some editing, you at least have the real words from the call to go back to, not someone's memory of it.
Curious if Anton's team had the same problem with things getting lost between the transcript and the tracker.
The incident report part matches what I've seen, with one catch. An agent with access to almost everything (chat channels, old threads, notes) once gave me a clean root cause, and one step in the middle had no query and no log behind it. It was plausible filler, and I signed off on it. Someone else caught it before it reached the customer. To the model, a message someone wrote in a channel and a line the system logged weigh about the same: both are text. What fixed it for me was requiring a label on every claim: proven (query or log attached), hypothesis (with the command that would check it) or not verifiable (and what access is missing). Only the first kind goes into the root cause.
The point that your impact slides off the keyboard as you get more senior is correct, and it's the bit people nod at in the meeting and then go back to writing code. Drafting the design doc from the messy thread where the decision actually got made — yeah, that beats staring at a blank page and pretending it's thinking time.
"#1 New Release in three categories" before the print edition exists is a lovely piece of publishing arithmetic. Enjoy it, genuinely — just maybe don't put the badge in a design review.