Embedding GenAI in enterprise delivery
How I embed GenAI in telecom delivery at Systems Ltd without handing scope, risk, or the release decision to a tool.
Since January 2026 I have been a senior technical project manager and delivery lead at Systems Ltd in Islamabad, on site, for a major telecom client. I lead technical delivery and release outcomes, I align engineering, QA, business analysis and product, and the business on scope, risk, and release velocity, and I embed GenAI tooling into how that delivery runs. This note is about that embedding. I will not name the client, the products, or any figure I have not already published. There is no percentage in this post for the telecom programme, because I have not put one on the record, and I am not going to create one for a blog.
The point of writing it down is the boundary. GenAI in an enterprise delivery workflow is a way to shorten the path from a clear requirement to a reviewed increment. It is not a new operating model, and it is not permission to skip the gates a telecom release already has.
What the role actually is
I am accountable for what leaves the release, not for a status colour. Engineering, QA, business analysis and product, and the business disagree about feasibility, proof, priority, and operational risk. That disagreement is the work. My job is to make it specific — scope, risk, or velocity — and to get a decision the next release can absorb.
I walked in with a delivery baseline from TEO / StableLogic, 2021–2025, written up on the enterprise delivery page: CSCS 35 percent faster, 25 percent fewer support queries, and more than £1.5 million on time; Veroxos, dual PM and PO, 60 percent less manual reporting; Firstcom Universe, about 25 percent efficiency, budgets up to $1.8 million, teams of more than 30. GenAI did not create that baseline. It has to earn a place on top of it.
Where GenAI goes in the workflow
I use GenAI where the work is repetitive, specified, and reviewable. Drafting a first cut of acceptance criteria from a decision we have already made. Exploring an implementation slice inside a repository boundary. Summarising a test gap so a human can decide whether it blocks the release. Comparing two wordings of a requirement so engineering and the business are arguing about the same sentence.
I do not use it to invent the requirement, to accept the requirement, or to accept the release. Those three acts are the delivery. A model can propose. The programme has to dispose. On a major telecom client that distinction is not philosophical. Operational risk, customer impact, and the cost of a bad release are already well understood by the people in the room. A workflow that obscures who decided is a worse workflow, even if it feels faster for a week.
The tools I build with myself are Claude Code and, where the product shape fits, Google AI Studio. TaskCue is the clearest public example: React, Node.js, MySQL, and Claude Code, shipped as a free shared task and reminder app at tasks.samikhanapps.com. I keep that practice sharp so I am not asking an engineering team to adopt a way of working I have only seen in a slide. I do not claim that my personal stack is the client's standard. The telecom programme has its own engineering constraints. What transfers is the sequence: boundary, slice, human review, then release. What does not transfer automatically is a tool choice.
What I refuse to speed up
Some parts of delivery get worse when they get faster.
Scope. If a session can generate three viable interpretations of a story, the wrong move is to implement all three and call it optionality. The right move is a decision, recorded, and one interpretation in the release. GenAI makes the three interpretations cheap. Cheap interpretations are how backlogs bloat.
Risk. I will not let a generated test summary close a risk that QA has not actually run. I will not let a generated impact note stand in for the person who operates the service. Embedding a tool means giving it a defined seat in the existing risk conversation, not a parallel one.
Release judgment. "The assistant finished" is not a release criterion. Neither is a green board that nobody has read. My standard is the same one I use on my own apps: the path has been clicked, the non-goals are still out, and a named person is willing to ship. On BarkCrush, AI-assisted delivery across web and mobile coincided with releases 22 percent faster. I will cite that on BarkCrush. I will not export it onto the telecom client as if the same number applies. Different product, different gates, no borrowed metric.
Compliance and auditability, when they are in play, stay human. My healthcare record — Panacea at 100 percent Meaningful Use Stage-2, more than $450,000 in penalties avoided — taught me that the attested outcome has to be in the release plan early. Telecom delivery has its own operational and contractual constraints. A GenAI workflow that cannot explain what changed, and who accepted it, does not survive those constraints. So the workflow I want is boring in the log: what was asked, what was merged, what was rejected, who signed the release.
How this sits next to the free tools
People sometimes collapse the two halves of my work into one claim, so I will separate them.
The enterprise half is Systems Ltd, a major telecom client, delivery leadership, GenAI inside the workflow, no public client name, no invented savings figure. The personal half is three free live tools — TaskCue, Circles Finance, and Medical Claims — plus earlier GenAI product builds such as Dental EHR, where QA effort fell by 35 percent inside a tighter, MU-aware scope, and BarkCrush, with the 22 percent release figure above. The personal products are not commercials for the client, and the client work is not a case study I am freelancing in public. The portfolio at samikhanapps.com is about what I owned and shipped. Where a workplace login carries Systems Ltd branding, that is context, not a transfer of ownership onto a personal write-up.
A practical test I use
When someone proposes a new GenAI step in the delivery path, I ask four questions.
Is the input a decision we have already made, or is the tool being asked to make it? If it is being asked to make it, stop.
Can a human review the output in less time than it would have taken to draft it, and with enough context to reject it? If the review is theatre, the step is not actually faster.
Does the step name an owner when it is wrong? If the answer is "the model", it does not go in.
Does it touch scope, risk, or the release call? If yes, it can inform the call. It cannot be the call.
The rest of the record — programmes, live apps, and the short version of how I work — is at samikhanapps.com. I talk about delivery with other PMs and builders on LinkedIn.