AI-native engineering
The software-production organization itself is structured around agent teams with delegated authority, explicit responsibilities, deliberation, routing, independent review and governance.
I’m Ali Babaei, CTO at MelkOnline and solo architect & builder of a human-governed, agent-executed AI-native engineering organization.
I design engineering organizations and products in which AI is foundational—not a bolt-on feature and not just a coding assistant.
My work sits first in AI-native engineering organization design, and also in AI-native product design. Humans retain purpose, strategic authority and governance boundaries. Within those boundaries, AI-agent teams can deliberate, decide, plan, build, review and operate; owner intervention is reserved for structural choices, policy changes and true escalations.
At MelkOnline, I initiated the AI-first direction before we adopted the term AI-native, then architected and built the engineering organization behind that transition from first principles.
The resulting system treats software production as an organization: responsibilities, context, memory, decision processes, routing, independent review, quality gates, lifecycle, authority and feedback loops are designed as first-class parts of the system.
The current AI-native direction at MelkOnline began before we were using the term “AI-native.”
I had built the earlier conventional version of MelkOnline myself. In April 2025, I proposed an AI-first direction for MelkOnline: AI should be foundational both in the product and in the way the product was engineered.
The proposal then went through a period of consideration and preparation. From July into August 2025, we continued building the conventional product and launched its pilot.
In August 2025, the AI-first direction was adopted for MelkOnline. We began using AI directly in development, initially including work on the existing application. In the same month, I proposed the architecture for the new AI-first product—conversational for users and AI-centered across core workflows such as data understanding and matching—and began architecting the agentic engineering organization that would support end-to-end software production.
In today’s terminology, that direction was AI-native in intent across both product and engineering.
The software-production organization itself is structured around agent teams with delegated authority, explicit responsibilities, deliberation, routing, independent review and governance.
AI belongs in the core user journey and decision/workflow architecture—not as a feature attached to a conventional product.
Defects and observations can feed back into design, mission structure or execution strategy—not merely into another patch.
The proposal was broader than adding AI features: AI would become foundational to the product experience and to how the product itself was built.
This was an interim period rather than the start of the new architecture in production.
The existing product path remained active while the larger AI-first direction had not yet become the operating direction.
We first used AI directly in development, including work on the existing application. In the same month, I proposed the new AI-first product architecture—AI-native in today’s terms—and began architecting the agentic engineering organization for end-to-end software production.
The work moved beyond using AI tools toward designing continuity, delegation, coordination and explicit operating rules across agent roles.
The system moved toward defined team roles, agent nodes, routing and role-specific operating procedures, turning the AI-first direction into an operating engineering architecture.
The focus became delegation, durable coordination and management across specialized agents rather than manually driving individual implementation sessions.
Persistent responsibilities, delegation, reporting paths and independent review became organizational concerns rather than ad-hoc session behavior.
The system was designed to reframe problems, compare alternatives and resolve decisions inside delegated scope without defaulting to owner intervention, while preserving a clear escalation boundary for owner-level choices.
My role is concentrated on purpose, structural choices, governance boundaries and true escalations; within delegated scope, agent roles can plan, decide, build, review and operate without waiting for implementation-level direction.
Governance defines purpose, authority and escalation boundaries. Within them, agent roles can deliberate, decide and execute without waiting for human approval on every step.
The human role moves up to purpose, boundaries and structural choices; lead and specialist decision roles can handle planning, coordination and delegated decisions below that line.
If implementation and review share the same context and incentives, review can collapse into self-confirmation. Independence has to be designed.
More field notes will follow as the product and engineering organization evolve.
My work treats the engineering organization itself as a system to be designed: authority, decision processes, context, memory, coordination, verification and escalation paths—so AI-agent teams can decide, build, review, operate and improve software inside explicit boundaries.
The unit of engineering is no longer only code. It is also the AI organization that can decide, build, review and operate it.