A 2026 standup can already sound like a joke: one developer says they finished the feature; another says they finished convincing the agent to finish the feature. Then the manager asks how long it took, and both answer: “Depends how you count.”
The joke works because the workflow split is real. In many engineering teams, two people with the same title may now do very different work. One mostly writes code. Another mostly manages AI output: prompts, diffs, tests, hallucinations, context, reviews, and cleanup.
AI changes the role, not only the tool
The uncomfortable part is that most teams still manage both workflows with the same old process. This is why the problem with AI-first is often the word “first”: process and accountability still have to come before tool worship. Estimation assumes the work is mostly writing. Code review assumes the author personally formed the design. Knowledge sharing assumes the person who opened the pull request understands every decision. Those assumptions are weaker now.
This does not mean AI-assisted development is bad. It means the operating model has to catch up. The real engineering question is not whether developers should use AI. It is whether the team can preserve understanding, accountability, and production quality when AI materially contributes to the code. That is part of the broader shift in AI engineering and software-development workflows.
Where the old process breaks
- Estimation: Are we estimating writing time, verification time, or production-readiness time?
- Code review: Are reviewers checking the code only, or also the assumptions and generated decisions behind it?
- Knowledge sharing: Who actually understands the architecture choices when a large chunk arrived through an agent?
- Hiring: Are we looking for a coder, reviewer, orchestrator, debugger, or a mix of all four?
- Accountability: Who owns fast-generated code when it fails slowly in production?
The checklist I would add to the team process
- Mark pull requests where AI materially contributed. Not for shame — for transparency and review depth.
- Require a human owner for every non-trivial decision. The model can propose; a person must own the trade-off.
- Measure time to production, not only time to PR. Faster diffs do not matter if verification and incidents move downstream.
- Separate acceleration from replaced understanding. “AI helped me move faster” is different from “I no longer understand the implementation.”
- Teach review of generated code, not only prompting. Teams need habits for validating assumptions, edge cases, dependencies, and security boundaries.
The practical leadership question
Engineering leaders do not need a moral debate about whether AI is “real development.” They need a process that describes how the work actually happens. If half the team uses agents heavily and half does not, the team may already have two delivery systems — but only one set of ceremonies, metrics, and review norms.
That gap is where quality problems hide. The fix is not banning tools or blindly celebrating speed. The fix is making the invisible parts of AI-assisted work visible enough to review, own, and improve.
Originally posted on LinkedIn: Hebrew version
