🧠 AI-First in Project Management: when AI takes a seat on the team

When we talk about project management with AI, the conversation usually drifts to the wrong place. Toward artificial intelligence projects. Toward models, datasets, ML pipelines. But that is not what this article is about.

Today I want to talk about something more everyday and more disruptive at the same time:

What happens when you have a normal project — SQLRPGLE modules, Java services, Python scripts — and suddenly you have an AI agent sitting on your team?

Because that is already happening. And neither Waterfall nor classic Agile has an answer for that.

⚙️ The real problem: speed collapsed

In classic Scrum, the two-week sprint makes sense because the bottleneck is writing code. A module that used to take three days is now generated by IBM Bob or some other AI agent in two hours.

So the uncomfortable question arises:

👉 Why do we plan for two weeks if we deliver in two days?

And the answer is not “we do more in the same sprint”. The answer is that the entire management model needs to be rethought. Because time did not disappear. It was redistributed.

Before: 80% building, 20% reviewing.
Now: 20% orchestrating, 80% validating, contextualizing, and deciding.

🧩 What changes is not the phases — it’s the activities

The SDLC phases remain the same:

• Analysis.
• Design.
• Development.
• Testing.
• Deploy.

But what happens within each phase is completely different when there is an agent on the team. And this applies regardless of the language, the platform, or the architecture. This is one of the most profound transformations that AI brings to development:

For the first time, a truly multi-technology team is possible.

You no longer need the RPGLE expert, the Java expert, and the Python expert as separate silos. The agent lowers the technical entry barrier. What unites the team now is the business domain — not the stack.

👨‍💻 The new role: from the one who writes to the one who orchestrates

The developer does not disappear. They transform. They stop being the one who produces the code and become the one who has the judgment to assess it. But here there is a paradox worth naming:

To orchestrate well you need to know enough about each technology to detect errors, but not so much that you fall into the trap of doing yourself what the agent can do.

The AI-First orchestrator has five competencies that did not exist as a unified profile before:

• Prompt Engineering — knows how to build precise instructions with real business context.
• Critical Output Review — validates that the code is correct in logic, not just in syntax.
• Domain Knowledge — carries the context that AI does not have and never will have on its own.
• Architectural Awareness — detects when the output breaks the global coherence of the system.
• AI Accountability — signs off on the code even if they did not write it. There is no “the AI generated it” as an excuse.

🔄 The ceremonies that change

Scrum does not die. It adapts. The ceremonies still exist, but the object of conversation changes completely.

Before, the team talked about what they were going to build.
Now they talk about what they validated, what they rejected, and what decision cannot be delegated to the agent.

Daily Sync — the new three questions

Before	Now
What did I do yesterday?	What did I approve / reject from the agent?
What will I do today?	What am I going to orchestrate today?
Do I have blockers?	What decision needs a human?

The new ceremony: AI Code Review

This did not exist in classic Scrum. And it is the one that changes the team dynamic the most. In the traditional model, code review was private — between the author and a technical reviewer. Here the agent’s output belongs to the whole team, because nobody wrote it.

That creates something powerful:

👉 The PO can point out a business logic error without knowing how to read the code.
👉 The architect can detect a broken pattern without knowing the domain.
👉 The QA can identify uncovered cases before a single manual test is written.

AI-generated code becomes the team’s common language.

Retrospective — new questions, new artifact

The AI-First retro does not only produce process agreements. It produces something tangible:

The team’s prompt library.

Validated prompts. Contexts that worked. Instruction patterns proven in production. That library is the equivalent of the team’s accumulated knowledge — and it is what makes each micro-sprint faster than the previous one.

The key questions of the retro change:

• Which prompts worked? → they are added to the team’s library.
• Where did AI fail us? → was it the prompt, the context, or a real limit of the agent?
• What decision did we make that AI could not have made on its own?
• Should the micro-sprint be shorter or longer for the next module?

⏱️ The micro-sprint: 3 days, not 2 weeks

When the generation speed collapses, the natural delivery cadence also changes.

An AI-First micro-sprint has three clear moments:

Day 1 — Planning and kickoff

AI proposes the technical breakdown. The team decides who orchestrates what. Not by language specialty — by domain knowledge. Sprint Planning does not end with tasks assigned to people by their stack. It ends with an orchestration map: who gives context to the agent in each module and with what criteria they validate the output.

Day 2 — Validation and refinement

The Daily reports approved and rejected outputs — not completed tasks. The AI Code Review brings the team together over the same output generated by the agent. Whatever did not pass the review is re-orchestrated.

Here something happens that had no equivalent in classic Scrum:

The rejection of an output is not a blocker — it is part of the process.

Re-orchestrating with a better prompt is faster than fixing code by hand.

Day 3 — Closing and retrospective

Demo to the stakeholder. What matters is that the increment meets the acceptance criteria — not how it was generated. The retro extracts the prompts that worked and adds them to the team’s library.

📊 What is measured now

Speed is no longer measured in story points. It is measured in validated and delivered modules. And new metrics appear that say much more about the team’s maturity:

• AI acceptance rate — the percentage of outputs approved without re-orchestration. Too high means superficial review. Too low means the context given to the agent is insufficient.
• Review cycle — the time between when the agent generates and the human approves. That’s where the team’s real work lives.
• Growth of the prompt library — the most honest indicator of collective learning that exists in this model.

🔥 Conclusion

AI does not replace the team. It changes what the team does.

And that change is not minor: we go from executing technical tasks to making decisions about outputs generated by an intelligence that has no business context, that does not know the system’s history, and that is not responsible for what it generates.

That responsibility remains human.

The orchestrator is not the developer of yesterday with Copilot on top. It is a new profile, with a more demanding judgment, who carries what AI will never be able to have on its own: the context.

And the project management that accompanies that profile is neither Waterfall nor pure Agile.

It is Orchestrated Agility — the same Scrum structure, with completely different activities inside.

👉 It’s not about managing projects with AI.
👉 It’s about managing projects where AI is just another member of the team.

It’s not just about modernizing the code, but about modernizing the way we think and work.