The Exact AI Delivery Stack a CPO Uses to Reduce Rework by 25%
AI can generate code in seconds. But without architecture, it just helps you ship the wrong thing faster. In this interview, a CPO and Director of Engineering shares the architecture-first AI system he uses to cut prototype time in half, reduce rework by 25%, and design guardrails for an AI-powered SDLC.
AI Leadership: AI shifts project management from coordination to system design, reducing manual tasks by embedding AI.
Architecture Role: Robust architecture prevents AI delivery chaos, aligning AI-generated work with quality standards and goals.
Prototype Efficiency: Architecture-guided AI collapses costs, accelerating prototypes from idea to working model in days.
Engineer Value: AI increases senior engineers' value by enhancing architectural design and reducing random coding.
Project Management Shift: Future PM roles will leverage AI for coordination, focusing more on design, strategy, and governance.
Yurii Lozinskyi is the CPO and Director of Engineering at Verysell AI, where he leads AI delivery. With 25 years of experience, turning software and AI initiatives into measurable business outcomes is his bread and butter.
So, we sat down with him to learn how he does it. Here's what he told us.
Making sure AI is not just a shiny toy
I'm a product and engineering leader who lives where AI systems, software delivery, and business reality collide. I’ve spent 15+ years shipping things across banking, insurance, ITSM/MSP platforms, retail, and healthcare. And somehow, I keep coming back to insurance because that’s where complexity and impact are both high.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Right now, I don’t run projects in the traditional sense. I design how projects should run and try to stay hands-on during delivery. That means operating models, AI‑powered delivery patterns, and hypothesis‑validation roadmaps across multiple teams and clients.
In short, my day job is making sure AI is not a shiny toy on the side, but part of how work is defined, executed, and governed end‑to‑end.
How AI shifts project management from coordination to system design
Delivery leadership is switching from calendar management to system design. I spend far less time in status meetings or manually drafting artifacts that machines now produce in seconds. If AI can help me write the first version of a plan or a summary, I'm happy to let it.
Many PMs today still spend 40–60% of their time status chasing, manual reporting, identifying basic risks, and moving information between tools and people. In an AI‑augmented environment, that drops below 10–15%, as embedded agents handle updates, summaries, reminders, and simple escalations across Jira/Linear, Slack/Teams, and docs.
The tradeoff is that my job moved up a layer: I worry about constraints, acceptance criteria, guardrails, and feedback loops. In other words, I design the "rails" on which humans and AI agents run.
I'm architecture‑biased: I use the C4 model and ISO/IEC 25010 as the framework for Architecture Vision Documents, and then I use those as prompts. That's the fun part — treating architecture as an API for AI. Your architecture docs are not shelfware, but fuel for an AI‑powered software development life cycle (SDLC). More on this in a moment.
AI makes it trivially easy to go fast, so my role is to make sure we go fast in the right direction. So, instead of asking, "Who's doing what this week?", I'm asking, "Does our system make it hard to ship the wrong thing fast?"
AI makes it trivially easy to go fast, so my role is to make sure we go fast in the right direction.
Why architecture prevents AI-induced delivery chaos
I like C4, ISO 25010, and Architecture Vision Documents because they form a backbone for integrating AI into delivery. Without that backbone, AI can quickly become yet another source of chaos in delivery.
Specifically:
- C4 gives AI a map of the system. Instead of “Just write some code,” we can say, "Within this context and container, against these interfaces, implement this change." This keeps AI‑generated work within clear architectural boundaries.
- ISO 25010 defines "good" beyond "it compiles." We translate its quality attributes into concrete scenarios — performance, security, maintainability, reliability — and incorporate them into prompts and acceptance criteria. AI then generates PoCs and tests that align with explicit quality expectations, not just functionality.
- Architecture Vision Documents integrate everything. They connect business goals, C4 views, and ISO‑style quality scenarios into a single narrative for both humans and AI. For humans, they serve as the alignment artifact. For AI, they provide the primary context source for generating code, tests, and documentation.
Together, they transform AI from a random superpower into a controlled component of an AI‑powered SDLC, with clear boundaries, traceability, and a shared understanding of what we aim to build.
How to collapse the cost of being wrong with architecture-guided AI prototypes
Here's an example. We had an AI-matching feature that, in the “old world,” would have taken roughly two weeks to go from idea to a clickable prototype.
Instead of starting with Jira tickets and ad-hoc prompts, we first wrote a short Architecture Vision Document. We drew C4-style diagrams: system context, containers involved, key components, plus a handful of ISO-25010-flavored quality scenarios (e.g., latency, auditability, error handling).
Then we treated that architecture as an API for AI:
- We fed the Vision Document and C4 snippets into our coding assistant as the only source of truth for prompts.
- We asked it to generate scaffolding, core flow logic, and first-pass tests within the specified containers and interfaces.
You’re not asking AI to “Write me some code,” but “Implement this specific interaction with these constraints and these quality attributes.” That’s a very different game. And it produced a coherent PoC in a couple of days instead of us hand-coding everything from scratch.
Engineers still reviewed and fixed things, but:
- Time from “we should try this” to “stakeholders can click through a working prototype” dropped from about ten working days to three or four. It feels almost unfair how quickly you can achieve a believable prototype when architecture grounds your prompts instead of vague wishes.
- We saw 20–25% fewer rework cycles, because the AI-generated code already respected the boundaries and patterns baked into the architecture.
- Engineers reported spending around 20% less time on boilerplate and glue code, effectively eliminating a separate “integration engineer” role.
- Test coverage for that slice came out higher on the first pass since the assistant used the documented quality scenarios to suggest edge-case tests we probably wouldn’t have written so early.
In other words, once we made the architecture explicit and structured, AI stopped behaving like a clever autocomplete and started acting more like a junior engineer who actually understands the system map, writes great documentation, and never sleeps.
And most importantly, it collapsed the cost of being wrong, which is precisely what you want in messy domains.
Why AI makes senior engineers more valuable, not less
Despite what you might think, AI makes senior engineers more valuable, not less.
If you plug AI into a weak architecture and weak judgment, you get a faster mess. Put it under a strong architect, and suddenly one senior can explore five designs before lunch and still have time to talk to stakeholders.
AI closes some skill gaps but amplifies the gap between random coding and intentional design.
If you plug AI into a weak architecture and weak judgment, you get a faster mess. Put it under a strong architect, and suddenly one senior can explore five designs before lunch and still have time to talk to stakeholders.
Bye, business analyst — welcome, subject matter expert.
Which delivery tasks should be automated first with AI
Right now, the parts of delivery work that are most ripe for automation are the “context‑heavy, pattern‑rich, low‑ego” activities:
- As mentioned, generating PoC code and tests from Architecture Vision Documents and C4/ISO 25010 specs
- Drafting decision logs, design options, and risk lists
- Turning messy Slack threads into something your future self can read without crying
AI is excellent at suggesting; it’s terrible at taking responsibility. Here's where humans still absolutely own the space:
- Framing the problem
- Trading off risk vs speed
- Handling regulatory and ethical boundaries
- Deciding when “technically correct” is still the wrong thing to ship
The sweet spot right now is compressing the early discovery and design loops. Agents are good at turning a coherent spec into plausible paths. They do not yet understand when a path is politically, ethically, or strategically wrong, so humans stay firmly in charge.
Why PMs should prioritize feedback loops over ceremony
Traditional project management often contains lots of ritual without a clear purpose. I’m moving away from that toward systems that prioritize feedback over ceremony.
In practice, that means:
- Fewer monolithic plans; more small, testable hypotheses
- Fewer big status meetings; more async updates auto-summarized by AI
- Fewer bloated requirements documents; more living Architecture Vision Documents that both humans and AI can act on
We still care about dates, budgets, and risks. But we let AI handle bookkeeping so humans can focus on design, decisions, and stakeholder reality.
The irony is that when you remove half the ritual, people respect the remaining structure more.
The irony is that when you remove half the ritual, people respect the remaining structure more.
How AI integrations streamline project delivery inside GitHub and CI/CD
From a technical perspective, “going lightweight” meant wiring AI directly into the repo and environments, not just adding another dashboard.
Specifically, we integrated an AI coding assistant called Codex into our GitHub repositories and CI/CD pipeline. Engineers work in their usual IDE, but the assistant can see the repo structure and do everything I said above from C4‑style architecture diagrams and an Architecture Vision Document. At roughly $20 USD per engineer per month, this is cheaper than almost any other productivity lever you can pull.
Additionally, we use simple deployment automation (GitHub‑based pipelines) so we can deploy AI‑assisted changes to a dedicated prototype environment with one click.
Even prompt generation is partially automated: A modern GPT‑class model (GPT-5.2) can generate structured prompts for tools like Eraser from our Architecture Vision Documents.
The key is that all of this sits inside standard guardrails: Engineers still review every pull request, CI/CD still runs, and nothing goes to production without human approval. AI accelerates the boring parts; humans stay responsible for design, risk, and the final call.
Why AI prototypes redefine delivery rituals
All of this has had a big impact on our delivery rituals.
Defining scope used to be, “Let’s talk for hours and then write a document we’ll all ignore.” Now, it's, “Let’s get to a prototype fast and argue with something interactive.”
We start with a high‑level outcome, capture it in an Architecture Vision Document, sketch C4 views, and then use AI to generate a PoC or at least a realistic mock-up. Suddenly, everyone has an opinion — because there’s something tangible to react to.
In other words, we achieve alignment around behavior, not bullet points.
We validate using a mix of AI‑generated tests (great for coverage and regression) and human‑designed scenarios (great for judgment and weird edge cases).
And we shift execution management from “assign tasks” to “design flows”: Who or what should see this piece of work next, and with what context?
What a straightforward AI delivery stack looks like
My stack is opinionated but straightforward.
For architecture and alignment, I use C4‑style diagrams and Architecture Vision Documents, drawn in tools like Eraser. This makes them easy to iterate in front of humans and then feed into AI.
For specs, I prefer text‑first documents that describe intent, constraints, and quality attributes in a way an LLM can understand.
On the engineering side, I use modern IDEs with strong AI assistance and tools like Claude Code and Codex to generate PoC implementations and tests directly from those architecture artifacts. I deliberately haven't outsourced full production features to AI. It drafts, scaffolds, and proposes. Engineers — real ones — still decide what lives in production.
Importantly, each of these tools has stopped being an island. They’re now wired into an AI‑powered SDLC: requirements, architecture, coding, testing, and even governance all have an assistive layer.
In practice, I expect this shift to unlock roughly 18-25% productivity gains across delivery. But to be clear, that number is highly dependent on an organization’s starting point — maturity, existing processes, and architecture discipline.
How selective tool adoption enhances AI delivery
Over the last year, we began deliberately swapping and piloting tools, rather than trying to “AI‑enable” everything at once.
On the delivery side, we introduced Miro for lightweight roadmapping and architecture workshops, but only as a pilot on a few small projects. We aimed to assess how well Miro boards, combined with AI‑generated summaries, could replace long slide decks and manual alignment documents. Early signals are good, but we still need to finalize and scale the approach before it becomes a default.
For documentation and specifications, we kept a text‑first documentation tool for Architecture Vision Documents. We added AI assistance on top of it with very lightweight, Custom GPTs — quietly retiring large, static specification documents we weren't maintaining and that didn’t translate well into prompts.
I touched on this above, but on the engineering side, we added Codex as an AI coding assistant integrated with our Git repository and CI pipeline for PoC scaffolding and test generation, while retaining our existing IDEs and deployment tooling. In other words, we’re not ripping out the stack yet. We layer AI on top, where it clearly saves time, doing so in controlled pilots first before rolling anything out company‑wide.
We’re not ripping out the stack yet. We layer AI on top, where it clearly saves time, doing so in controlled pilots first before rolling anything out company‑wide.
Where project management is going in the next five years
Five years from now, “project manager” as a purely coordination role will largely disappear in tech. The work will still exist, but embedded AI agents will handle most coordination, tracking, and reporting within your tools.
The humans formerly known as PMs will either move up into designing AI‑powered SDLCs and governance models or sideways into product and strategy roles.
PM performance dashboards will shift away from “on time / on budget” toward a small set of system metrics they actively shape: lead time for changes, escaped defect rate, decision latency, experiment throughput, and stakeholder trust scores. AI will do most of the counting. PMs will be accountable for whether those numbers move in the right direction — not because they chased more tickets, but because they designed better ways of working.
The PMs who stay in “status shepherding” will be quietly replaced by bots that do it 24/7 and don’t mind updating six dashboards at once.
Why PMs should treat AI like a teammate, not a topic to learn
My advice: Stop trying to “learn AI” as if it's a new framework and treat it as a new kind of teammate with specific strengths and blind spots. We jokingly call ours "gptBuddy."
Pick one workflow, one team, and one metric that matters, and run a ruthless experiment. If you don’t see meaningful improvement, change the setup or stop.
The real value of AI looks boring from the outside. It’s not the sci‑fi stuff people expect. It’s the unglamorous, compounding wins: test generation, doc clean‑up, scaffolding, variant exploration, and so on.
At the same time, lift your eyes from the tools and sketch what an AI‑powered SDLC would look like for your organization. If you don’t do it, someone else will — and their teams will move faster, with fewer meetings and less drama.
Stop trying to “learn AI” as if it’s a new framework and treat it as a new kind of teammate with specific strengths and blind spots.
Follow along
You can follow Yurii Lozinskyi on LinkedIn and Dev.to as he shares his technical know-how on AI, engineering, product, and delivery. And check out Verysell AI.
More expert interviews to come on The Digital Project Manager!
