A walkthrough of a real Levi9 project, numbers included
For most of software development history, the lifecycle followed a well-established shape. A client comes with requirements. A team collects them across interviews and meetings, documents everything, and starts planning. Architecture gets designed. Tasks get written into tickets. A developer picks up a ticket, does the work, someone tests it, and it gets closed. QA runs end-to-end tests, a code review happens, and the build gets deployed. Monitoring begins. Feedback comes in. The cycle continues.
It is a proven process, one that has delivered complex, high-quality software for decades.
The question Levi9 Software Engineer Nemanja Pavlovic and his team started asking was not whether this process was good, but whether AI could make it even better: faster, more consistent, and more resilient at every stage.
The answer showed up in a penetration test.
The same type of application, built the traditional way, had returned a 30-page report with 40 identified issues, several of them critical. The rebuilt version, developed using an AI-first software development lifecycle with guardrails embedded throughout, returned a 5-page report. Five issues. None critical.
Same team. Same standards. Fundamentally different process.
At Hack9 2026, Nemanja Pavlovic walked through exactly how that process works, a live internal project, running in production, built from scratch using what the team calls an AI SDLC. Here is what that actually looks like.
Why the Classic SDLC Needed Rethinking
The traditional software development lifecycle was built around a fundamental constraint: humans are the bottleneck at every stage. Requirements get collected in meetings. Specifications get written by hand. Tickets get created one by one. Code gets reviewed line by line. Documentation gets written, or more often, does not get written, after the fact.
AI does not remove the need for human judgment. But it does remove many of the bottlenecks.
The question the Levi9 Belgrade team started asking was not “how do we use AI to write code faster?” It was a more fundamental one: if AI can read, reason, and generate structured output – what parts of our process can we rebuild around that capability?
The answer turned out to be: most of it.
How It Works: Stage by Stage
Requirements
The project had six or seven stakeholders, each with their own perspective on what the product needed to do. In the traditional approach, collecting and reconciling those requirements would take weeks of meetings, documents, and back-and-forth.
Instead, the team used voice recording to capture every stakeholder interview. The recordings were transcribed automatically and stored as structured markdown files, a knowledge base that became the project’s source of truth.
AI agents then analysed those transcriptions to extract requirements, identify conflicts between stakeholders, and generate structured epics and Jira tickets, complete with acceptance criteria, test scenarios, technical notes, and dependency links.
Every ticket on the board was AI-generated. The process that typically takes weeks of product owner time was compressed into days.
Design and Prototyping
A designer on the team used Claude to generate a fully functional, clickable React Native prototype, built from the requirements already stored in the knowledge base. The prototype was deployed to a staging environment and in the hands of stakeholders within the first two weeks of the project.
Before AI, getting to a testable prototype typically took two to three months.
The difference matters because stakeholder feedback at the prototype stage is fundamentally different from feedback on a written specification. People react to something they can click through. Misalignments surface earlier. Rework happens at the cheapest possible point in the process.
Development
Each Jira ticket was structured with a clear division: the first section written for human review (business logic, context, user story), everything below it written for the AI agent that would implement it. When a developer – human or AI – picked up a ticket, the agent read the full context, checked whether dependencies were completed, created an implementation plan, built the feature, and ran tests.
One important guardrail: if a dependency ticket was not yet implemented, the agent flagged it and asked whether to switch focus rather than attempt to build on an incomplete foundation. Nemanja Pavlovic described the principle simply: spend more time on preparation so the final results come faster.
That preparation is what keeps the process in flow rather than in loops.
Pull Requests and Code Review
Once implementation was complete, a separate agent collected evidence, running Playwright to click through the feature, taking screenshots, verifying the UI against design mockups, before automatically creating a pull request. Every pull request across the project followed the same format: affected areas, related tickets, integration test results, visual evidence.
A code review agent running on AWS Bedrock analysed each pull request against the team’s defined standards and posted review comments. A human developer then did a final pass, not to catch obvious issues, which the automated review had already flagged, but to assess business logic and context that required human judgment.
Testing and Deployment
The team maintained a minimum 90% test coverage requirement. End-to-end tests ran on every pull request for the critical user flow. Full regression tests ran automatically on every release, catching regressions that individual PR tests would miss. The CI/CD pipeline handled the rest.
Measuring AI-First Development: Speed, Quality, and Team Resilience
Development speed improved by approximately four times compared to the team’s pre-AI baseline for equivalent features. The pen test comparison – 40 issues down to 5; 30 pages down to 5 – is the clearest signal of what embedded security guardrails throughout the process produce.
Onboarding improved significantly too.
The team’s composition changed three times over three months, a common reality for internal projects where engineers rotate onto commercial work. Because the knowledge base was externalised and the process was defined, each new team member could become productive in days rather than weeks.
Nothing critical lived only in someone’s head.
What This Requires to Work
The honest part of this story is the setup cost.
The preparation phase, building the knowledge base, defining ticket templates, creating the skills and agent configurations, establishing the guardrails, is a real investment. The team spent significant time on it before the process started running smoothly.
A second insight worth noting: design the system for the AI that will be reading it, not for the humans who built it.
As Pavlovic put it: “Leave AI to develop in a way it means best, because it will read the code tomorrow, not you.” Naming conventions, file structures, and organisational choices should serve the agent’s ability to understand and navigate the codebase.
The Wider Hack9 Picture: Three Workshops, One Direction
The AI SDLC session was the first in a three-part workshop series Levi9 ran in the week before Hack9 2026, and each one extended the same underlying argument.
The second workshop, led by Gabriela Hanganu, went deeper into the architecture of skills and agents: how to encode team knowledge into reusable instructions that AI applies consistently, how to decide when a repeatable task becomes a skill and when a skill needs to become an agent, and how to build systems that get more reliable over time. Her key insight is start with a skill, promote it to an agent only when you need autonomy. Complexity for its own sake creates loops, not speed.
The third workshop, led by Kosta Aćimović, addressed something that becomes important as soon as teams start operating at this scale: cost. Not all tasks require the most capable, and most expensive model. Using a more powerful model for planning and complex reasoning, a lighter one for implementation and routine tasks, can reduce AI costs significantly without reducing output quality. One practical example: analysing a PDF costs roughly 3,000 tokens. Extracting the same content as plain text costs a fraction of that. These choices compound across a project.
Together, the three workshops mapped the same territory from different angles: how to build with AI in a way that is fast, consistent, and economically sustainable.
What Changes When You Build With AI
The pen test numbers are striking, but they are a symptom of something deeper. When security review is not a gate at the end of the process but a guardrail running throughout it, security improves, not because the team got better at security, but because the process made it structurally harder to ship insecure code.
The same logic applies to documentation, to test coverage, to code review consistency, to onboarding. When these things are encoded into the process rather than dependent on individuals remembering to do them, they happen reliably.
That is the real promise of an AI-first software development lifecycle.
Not just speed.
A process that is more consistent, more secure, and more resilient than the one it replaced, by design, not by discipline.
This is the second article in a series on Hack9 2026 and AI-first software development at Levi9.
