The title is a bit of a joke, of course. If you check my LinkedIn or ask my colleagues at Snappfood, my actual role is Frontend Lead.
In my day-to-day work, I lead a large function consisting of three teams and six frontend developers. On paper, my responsibilities are clear: managing people, scoping tasks, resolving bottlenecks, giving feedback, driving architectural decisions, and making sure our frontend delivery runs smoothly.
However, I have never liked confining myself strictly to the boundaries of my job title. Whenever a new shift happens in our industry, I want to get my hands dirty. Over the past few months, as AI started reshaping how we work, I began stepping outside my routine—building custom AI skills, helping make our frontend repositories "AI-ready," and experimenting with internal plugins.
Recently, that curiosity led me into one of the most exciting spaces in software right now: the AI-Native SDLC. And in the process of building a new internal tool for it, I realized my mindset had fundamentally shifted from being a "Frontend Lead" to acting like an AI Engineer, a Product Engineer, and a system architect all at once.
Here is the story of what I built, why the labels are blurring, and how our role as engineers is changing faster than we think.
From Traditional SDLC to AI-Native SDLC
We all know the traditional SDLC (Software Development Life Cycle): Planning, Defining Requirements, Design, Building, Testing, and Deployment.
Right now, most engineering teams are in the AI-Assisted phase. We keep the exact same traditional lifecycle, except developers use Cursor, Copilot, or Claude to write code faster during the "Building" phase.
An AI-Native SDLC, however, is a completely different paradigm—something heavily emphasized in recent engineering playbooks (like Anthropic’s guides on building effective agentic systems and AI-native workflows. read more here). Instead of just using AI to type code faster, an AI-Native SDLC redesigns the entire lifecycle around human-agent collaboration.
At Snappfood, we have been actively exploring how to build this path. When we looked at our own workflows, we noticed an interesting truth: writing code wasn't our biggest bottleneck anymore.
One of our most expensive bottlenecks was the gap between a PRD (Product Requirements Document) and actionable Jira tasks. Turning a product idea into clear engineering tasks usually requires multiple alignment meetings, solution reviews, finding edge cases, fixing ambiguities in the PRD, and manually breaking everything down.
My mission was simple on the surface, but complex underneath: Build a tool that automates the journey from a PRD to structured Jira tasks.
(Note: The architectural patterns shared below are simplified for educational purposes and do not represent Snappfood's proprietary internal infrastructure.)
Wait—Is This AI Engineering or Product Engineering?
To build this tool while still running my day-to-day responsibilities as a Frontend Lead, I had to step into a space where traditional job titles stop making sense.
Was I doing AI Engineering? Yes—I was designing agent workflows, managing context windows, and orchestrating LLM outputs.
Was I doing Product Engineering? Also yes—I was identifying user pain points, defining personas, and designing the end-to-end user experience.
The truth is, the boundaries between these roles are no longer sharp. We can't say with certainty which title will win out in the future. What matters isn't the label; it is the mindset shift required to build software in this new era.
Here are the four biggest lessons I learned while building this system.
1. Developing With AI: Shifting from Code to Full-Cycle Architecture
In the past, if we wanted to build an internal platform like this, we would form a mini-squad: a backend developer, a frontend developer, a product designer, and maybe a QA engineer.
Building with AI changed the economics of execution. As a solo builder working alongside my leadership duties, I wasn't spending my mental energy worrying about syntax or how to write a specific function. AI handled the heavy lifting of implementation.
Instead, my focus shifted entirely to decisions and architecture:
- How do I choose a tech stack that allows rapid iteration today without becoming a maintenance nightmare tomorrow?
- How do I design the data flow, API contracts, and state management across the whole stack by myself?
- How do I verify the system's reliability when I am acting as backend, frontend, and QA simultaneously?
When the cost of writing code drops, your value as an engineer moves up the abstraction ladder. You stop thinking like a specialist in one framework and start thinking like a full-cycle system builder.
2. You Are Building a Real Product (And There Is No Figma File)
As software engineers, we are spoiled by structure. We are used to receiving a refined PRD, opening a polished Figma file, seeing a clear user journey, and knowing exactly how the application is supposed to behave before we write a single line of code.
In this new world—especially when building AI-native tools—all of those product decisions fall back on you.
For this PRD-to-Jira tool, there was no designer or product manager handing me specs. I had to design the software from zero to one. More importantly, I had to realize that my tool had two completely different personas:
- Technical users (Engineers & Tech Leads): People who live in their IDEs, terminal, or Claude desktop apps and want fast, keyboard-driven workflows.
- Non-technical users (Product Managers): People who don't want to touch an SDK or a CLI; they need an intuitive, visual interface to upload a PRD, review the AI's analysis, and push tasks to Jira.
If I had only built a developer-friendly script, PMs wouldn't use it. If I had only built a rigid web form, engineers would find it limiting. Thinking like a product creator meant designing a cohesive User Journey before worrying about the code.
3. Separation of Concerns vs. The Trap of "Vibe Coding"
This brings me to the biggest mistake I see engineers making with AI today: building from the end backward.
Because AI makes development ridiculously fast, it is tempting to skip the engineering discipline. We don't bother understanding the personas, we don't map out the domain boundaries, and we jump straight into a prompt: "Hey AI, build me an app that reads a PRD and creates Jira tickets."
And the AI will do it! You will get a working prototype in an afternoon.
The problem shows up two weeks later. You end up with a tightly coupled monolith where the UI, the LLM prompts, the Jira API calls, and the business logic are all tangled together. Changing the smallest detail breaks three other things, and adding a new interface becomes so expensive you might as well rewrite it from scratch.
An AI Engineer still has to be an Engineer. Speed of code generation does not replace Separation of Concerns.
To avoid this trap, I designed the tool as a modular machine where every layer could evolve independently:
┌─────────────────────────────────────────────┐ │ Core Engine │ │ (PRD Analysis, Context, & Task Breakdown) │ └──────────────────────┬──────────────────────┘ │ ┌─────────────────────┴─────────────────────┐ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ Shell 1 │ │ Shell 2 │ │ Custom Plugin │ │ SDK (API/Webhook) │ │ (Claude / Tech App) │ └──────────┬──────────┘ └─────────────────────┘ │ ▼ ┌─────────────────────┐ │ Custom UI │ │ (For Non-Tech / PM) │ └─────────────────────┘ - The Core Engine: First, I built a pure computational and analytical core. It knows nothing about buttons, web pages, or chat interfaces. Its only job is to take a PRD, analyze ambiguities, apply our engineering standards, and output structured task models.
- Shell 1 (The Custom Plugin): On top of that core, I built a lightweight plugin shell so technical users could invoke the engine directly inside Claude or their existing developer tools.
- Shell 2 (The SDK + Custom UI): In parallel, I wrapped the core in an SDK exposing clean APIs and Webhooks. Later, I built a custom graphical UI on top of that SDK specifically tailored for non-technical users.
Because the boundaries were strict, I could upgrade the reasoning logic in the Core Engine without breaking the UI, or add a completely new integration shell tomorrow without touching the core business logic.
4. Guardrails: Automation Without Blind Trust
There is one important caveat when automating a process like PRD-to-Jira: AI is probabilistic, not deterministic.
If you feed a vague PRD into an LLM and let it blindly create 20 tickets in your team's Jira backlog, you haven't saved time—you have just automated the creation of chaos at scale.
A crucial part of engineering this tool was designing Human-in-the-Loop guardrails. Instead of a black box that dumps tasks directly into Jira, the workflow is designed to surface missing context first, allow the lead or PM to review and refine the proposed breakdown, and only then commit the tasks. AI provides the leverage and speed; humans retain the judgment and accountability.
5. Infrastructure, Git, and Security: Don't Throw Away the Guardrails
There is a hidden trap when AI makes building software feel effortless: people start forgetting how to manage it.
Everyone is building internal tools and scripts right now, but many forget the boring, fundamental truths of software engineering. Just because an AI helped you write the code in ten minutes doesn't mean the system runs in a vacuum. You still need Docker containers, Git workflows, proper CI/CD pipelines, and environment management.
Furthermore, security and operational hygiene become even more critical when AI is involved:
- Credential Management: You cannot hardcode your AI provider API keys or internal service tokens directly into the codebase.
- Access Control & Visibility: An internal tool that analyzes product requirements and interacts with Jira shouldn't be publicly exposed or accessible to everyone without proper authorization boundaries.
- Long-Term Maintainability: Who owns this service next month? How do we monitor its error rates, token usage, or prompt failures in production?
An AI Engineer doesn't just prompt an LLM; they take responsibility for the entire lifecycle of the service—from the containerization and pipeline setup to securing secrets and ensuring it doesn't become a maintenance nightmare or a security liability down the road.
The Paradigm Shift
Looking back at the past few weeks, balancing my routine responsibilities as a Frontend Lead while building this platform taught me something important: the era of being "just a coder" is fading.
When AI lowers the barrier to implementation, our job expands. We are moving toward a paradigm where a single engineer—armed with strong architectural fundamentals, product empathy, and AI leverage—can identify an organizational bottleneck, design a solution, and ship a multi-layered product to solve it.
You don't need to wait for an official title change to become an "AI Engineer" or a "Product Engineer." You just need to look at the friction around your team and ask how you can engineer a system to remove it.
I’m curious about your experience: How is AI changing the boundaries of your role? Are you finding yourself making more product and architectural decisions lately, or are the roles in your team still strictly separated?
