TL;DR: Since January 2026 and the latest wave of Anthropic models, my team's workflow has quietly rewritten itself — and the job has never been this enjoyable. A panel of persona sub-agents now debates every merge request and every incoming issue, flagging blockers we'd never have spotted on our own. Meetings record themselves — phone recorder or Teams transcript — and a skill turns the audio into a structured report, then opens GitHub or GitLab issues assigned to the right people. The technical chores, the meeting minutes, the follow-up emails — gone. What we do all day now is the thing we came here for: business, domain, product. The job we always wanted is finally the job we have.
In March I wrote that the SDLC is dead. A day later I argued that coding was never the job. Six months into 2026, I want to write the third panel of that triptych — not as a manifesto this time, just a report from the floor. What does an AI-native team actually look like on a Tuesday? Mine. Here is what it does.
Nobody decided this. There was no kick-off, no PowerPoint, no "AI strategy". The latest Anthropic models landed in January, we tinkered, something stuck, then something else stuck, and four months later the workflow looks nothing like it did in December. AI didn't replace anyone on my team. It quietly absorbed the parts of the job we hated.
The review panel nobody asked for
Code review used to be the bottleneck. A PR sat for two days. Then a senior reviewed it, missed half of what mattered (it was Friday), approved it. Now it goes through what I call the review panel.
When a merge request is opened, a dedicated skill triggers. It pulls the diff, the linked ticket, the architectural context. Then it spawns a small council of sub-agents with personas — a security reviewer, a domain expert, a performance hawk, a junior playing devil's advocate — and lets them argue. They actually argue. The transcript is brutal, often more rigorous than what three senior engineers would produce in a room. By the time a human looks at the PR, the analysis is structured, the blockers are named, and half the time the developer has already addressed them in a follow-up commit.
"The panel doesn't replace the review. It removes the noise before the review."
The thing that surprised me most isn't the speed. It's the depth. The agents catch the things we don't catch — the edge case nobody thought of, the architectural smell hidden three layers down, the contract that quietly broke. Three senior engineers in a room would have said "looks good to me" and moved on. The panel doesn't have a Friday afternoon.
We use the same panel on incoming issues. Every issue that lands in our backlog goes through it before triage. The output is a structured analysis — what's actually being asked, what's missing, what blockers it implies, what it touches in the codebase. It's the kind of analysis a Tech Lead would do on a good day, except every day, on every issue, in two minutes. The triage meeting that used to take an hour now takes ten because everyone walks in with the panel's notes.
Quality went up. Nobody on the team had to be convinced. It just works, and once you've seen a panel of agents tear apart your PR, you don't go back.
This adversarial-panel pattern isn't unique to code review. Matt Pocock's grill-me skill applies the same idea to raw thinking — an agent that interrogates your reasoning until the thin parts surface. I keep one running on the side for product trade-offs, architectural calls, and the half-formed ideas I'd otherwise walk into a meeting with. It hits, every time. Same medicine, different patient.
The actual skills behind this workflow — meeting (twelve named personas, three rounds: positions, debate, convergence), fast-meeting, issue-review, code-review, meeting-report for the Teams transcripts, grill-me and a few dozen more — are open source in our hexagone-foundation-skills repo. Specialized healthcare, finance and legal personas spawn on demand when the topic asks for them.
The meeting that records itself
Roughly two months ago, something else stuck. Meetings started recording themselves.
In person, on a phone — yes, a phone in the middle of the table, recording, transcribing locally. It became a default — for me first, then for others on the team — the way bringing a notebook to a meeting used to be a default. For remote calls, the Teams transcript already exists. Either way, when the meeting ends, there's a transcript.
We pipe the transcript through a skill that generates a structured report. Topics covered, points of interest, blockers, decisions made, and — this is the part that earned the tool its place — action items assigned to each person. With names. The kind of summary one of us used to spend forty-five minutes writing the next morning, except now it's done before we leave the room and nobody forgets the action they were handed.
Then the magic part. The same pipeline can take those action items and turn them into issues — assigned to the right people, in the right project, via the GitHub or GitLab CLI. The meeting ends. The issues are open. The owners are notified. The Tech Lead didn't have to do anything except attend.
"The 45-minute follow-up email I used to write at 11pm doesn't exist anymore. The work it described is already in the backlog before the meeting ends."
The same pipeline keeps the roadmaps current. Dailies, weeklies — the agent reads the summary, updates the project roadmaps I maintain, moves what shipped, surfaces what slipped, flags new dependencies. The roadmap stops being a document I dreaded updating on Friday afternoon and becomes a live artifact that reflects what was just discussed. Everyone — team, PO, stakeholders — sees the same thing, in sync, without anyone having to merge five versions on Monday morning.
I want to be honest about what's hard here. Not every transcript is clean — names get misheard, sarcasm gets indexed as a decision, sometimes the agent assigns an action to the wrong person. So we review before publishing. The skill produces a draft. The human approves. That's the only ceremony we kept, and it takes thirty seconds.
The product memory we never had
There's a side effect of the meeting pipeline I didn't see coming. Once every meeting becomes a structured report, those reports stop being ephemeral artifacts. They accumulate. They become a history.
A history of product decisions. Not the official decision frozen in a SharePoint — the actual evolution. Why we picked option B in March. What we ruled out. The constraint that surfaced in week 18 and flipped the answer. Who pushed for what, and what changed their mind.
For the first time in fourteen years of enterprise work, my team has a continuous, queryable record of how we got to the product we have. Not a snapshot. A trajectory.
Everyone can interrogate it. The PO. The PM. The testers. The developers. Even the security officer and the compliance team. They ask the agent a question — "why are we still validating this field server-side when the spec moved last quarter?" — and the agent reads the history, surfaces the meeting where the call was made, the trade-off that forced it, and the standard that justified it. Asynchronously. No human had to remember.
"The codebase used to remember what the product was. Now it remembers why."
The knowledge base writes itself. Decisions, debates, regulatory constraints, product standards — everything ends up encoded in the same place the code lives. Every persona on the panel reads from it. Every reviewer is, implicitly, also reviewing against it.
Onboarding got dramatically better. A new joiner used to spend weeks chasing context — pinging seniors, mining old Confluence pages, sitting in shadow meetings. Now they ask the agent. The agent answers from the actual product history, with sources. The senior is freed from being a walking documentation server. The new joiner is productive in days, not months.
In a domain like ours — regulated, full of standards, full of "you can't do that because article 14.3 of the directive says…" — this is transformative. The agents are constantly challenging our choices against the regulations we wrote down and the product standards we committed to. Not as a one-shot audit. As a constant, low-noise hum of "are you sure this still complies with X?" in every PR review, every issue analysis, every architectural decision.
It saves us from going down the wrong path. Daily. That alone is a quiet, deep happiness I didn't expect.
The tests we always promised to write
There's a third workflow that crept in. It might be the one I'm most happy about.
Automated non-regression tests. End-to-end coverage. Business-rule validation. The stuff every team's roadmap contained and no team's roadmap actually delivered. The tests we promised the security committee. The tests we promised the auditor. The tests we promised ourselves three roadmaps in a row, then quietly demoted to "phase 2" because the next feature couldn't wait.
For fourteen years, I've watched teams degrade their own deliverables this exact same way. Not from laziness — from arithmetic. A senior writes a feature in three days. The same senior would write the e2e coverage in another three. So the e2e coverage gets cut. Every time. The deliverable ships with a known quality gap nobody talks about in the steering committee.
That math is broken now.
The agents generate the e2e suite alongside the feature. Same loop, same context, same domain rules. Business non-regression scenarios — the ones that come straight out of the spec, the ones that live in the head of the PO, the ones a user reported in a ticket two years ago — get encoded as tests, automatically, when the feature is built. Not in phase 2. Not in Q3. In the same merge request.
And the panel reviews it. The domain persona checks that the test actually represents the rule. The performance persona flags scenarios that will be slow. The junior persona asks "what about this edge case?" — and the senior persona answers in code.
"We are finally producing the test coverage we owed our applications a decade ago. It feels like clearing a debt I had given up on."
I want to be honest about how big a deal this is. The roadmap-driven quality gap is the single biggest reason most enterprise software is fragile. Everyone knows it. Nobody fixes it, because the fix never makes it through prioritization. Now the fix doesn't need to make it through prioritization — it ships with the feature, by default, because the agent doesn't get tired and doesn't have a deadline.
The applications I'm responsible for have more e2e coverage today than they had after a decade of human effort. I keep saying this out loud and I keep finding it absurd. Crazy is the right word.
What changed inside the team
It would be easy to read this and assume the team got smaller, faster, more individualistic. The opposite happened.
Junior developers ramp up faster. They walk into PRs with the panel's analysis already in hand. They walk into meetings with the previous one's notes already structured. They no longer have to ask "what's important here?" — the agents have already framed the question. Their cognitive energy goes to the domain, not to navigating the process.
Seniors stopped wasting time on review theater. Five years ago, doing a thorough PR review meant blocking out two hours, reading every line, missing things anyway. Now the panel does the first pass. The senior spends ten minutes on what actually requires judgment — architectural choices, business edge cases, the things the agent cannot decide. The time saved goes to mentoring, design, and shipping to production.
Nobody is fighting it. This is what surprised me most. There was no resistance. The team didn't need a training plan or a change-management workshop. They tried the panel once, saw it catch a real issue, and the habit took. Six months in, asking someone on my team to "review without the panel" would feel like asking them to compile by hand.
The job we always wanted
Here's the part nobody tells you about. It's actually fun.
I haven't written meeting minutes in two months. I haven't formatted a follow-up email since March. I haven't spent a Saturday morning fighting with a CI YAML file or hunting down a flaky test. The technical chores I used to dread — they don't exist anymore. The agents handle them, better and faster than I ever did, and they don't complain.
What I do all day now is the work I actually wanted to do. Sit with the PO and stress-test a clinical workflow. Read a field report carefully until I understand what the clinical user actually meant, not just what the ticket said. Sketch a domain model on a whiteboard with two colleagues until it clicks. Read the latest interoperability regulation and figure out what it means for our roadmap. Argue with my Tech Lead peer about whether we're modeling the wrong concept.
In other words: business. The actual problem we are paid to solve.
"My calendar is now full of conversations about the domain. It used to be full of conversations about the process. The shift is the entire job."
The shift is not subtle. It's the thing every senior developer secretly always wanted: more domain, more product, more conversation with the people the software actually serves — and less time spent translating intent into syntax, fighting build tools, or formatting a meeting summary nobody will read.
The team feels it. The juniors feel it more than anyone. They came into the industry expecting to spend years stuck in the technical layer before they were allowed to think about the business. They're not stuck. They're already in the conversations that matter, with the panel handling the technical discipline they haven't built yet. Watching them make their first real domain trade-off in week three of an apprenticeship, instead of week eighty — that's the part I didn't expect to love this much.
I've been doing this job for fourteen years. I have never enjoyed it as much as I do now. The profession has changed under our feet, and the version we landed on is the one I always hoped existed.
What still belongs to humans
I don't want to oversell this. Plenty of things are still ours.
Deciding what to build. No agent has the political read of a project, the customer relationship, or the strategic context that says "we don't ship that even if we can." That's still a Tech Lead, a PO, a person who knows the room.
Catching the panel when it's wrong. The agents argue well. They are also confidently wrong sometimes. Spotting it requires domain expertise — the same kind of judgment I wrote about in the previous article. The panel doesn't replace the engineer. It frees the engineer for the work that actually requires being one.
Holding the architecture. The panel reviews against constraints we wrote. Someone has to write those constraints, keep them current, and make the call when the system needs to bend. That's still us. Garbage context in, garbage debate out.
Talking to the team. A meeting transcribed and turned into issues is not a one-on-one. The hard conversations, the morale check, the "are you actually OK" — those don't go through a transcript pipeline. They never will.
What to do Monday morning
If you want to take one thing from this and try it this week, here's the order I would suggest:
- Start with the issue analysis panel. It's the easiest entry point. Take ten incoming issues, run them through a small council of persona sub-agents, compare the output to what your triage meeting produced. You'll be uncomfortable. Then convinced.
- Add the PR review panel. Same idea, on a single repo, on volunteer PRs first. Don't impose it. Wait for someone to say "wait, the panel caught this and we missed it." That's the moment it spreads.
- Record one meeting. Just one. Run the transcript through a summary skill. Compare it to whatever follow-up email you would have written. Decide whether you can still justify writing the email by hand.
- Wire issue creation last. Don't automate issue creation until your transcript-to-summary loop is trustworthy. Otherwise you spam your backlog. When it's trustworthy, the GitHub or GitLab CLI integration is fifteen minutes of work and saves hours every week.
- Keep the human approval step. Drafts, not auto-pushes. Trust comes from watching the agent be right, not from skipping the check.
Conclusion
I keep waiting for the moment this stops feeling magical. It hasn't come yet.
We've absorbed agents into reviews, into triage, into meetings, into the backlog. None of it was planned. Each piece earned its place by being obviously better than what we did before. The team is bigger than it was a year ago — interns and apprentices joined the headcount — ships more, sleeps more, and complains less. The boring parts of the job are gone. What's left is the work I came into this industry to do — and I haven't enjoyed Mondays this much since I was a junior. We're going to make the most of it.
The profession changed. The change is good. Less syntax, less ceremony, less reporting — more domain, more product, more conversations with the people we build for. That trade is the one I would have signed for ten years ago if anyone had offered it.
If you read the previous two articles and thought I was being theoretical — I wasn't. This is what it looks like in practice, inside a French enterprise, in May 2026. Six months ago none of this existed. Six months from now, I have no idea what we'll have absorbed next. That's the only honest forecast I have.
The tools are here. The reflex is the only thing left to install.
What's the most boring meeting on your calendar this week? Record it. See what comes out.
Read the rest of the series: The SDLC Is Dead — why the process was always waste. Coding Was Never the Job — what the engineer becomes when the syntax layer disappears. The Backlog Was Never the Job — the same argument, product side. Doctrine Compounds. Models Don't. — what makes this team survive a model swap. The Tests Passed. Nothing Happened. — the defect that has no symptom, and what catches it instead of reading.