Routine feature work at most software companies begins with translation. A customer tells a CSM what is missing, the CSM writes a ticket, product interprets it, and engineering schedules it.
Every handoff loses context and puts the people closest to the problem at the back of an engineering queue.
We changed that default at LTV.ai. Product, design, customer success, and marketing now ship many regular features themselves through an AI coding agent we built called Elty (named after the company, LTV, said out loud). A human engineer still owns the final merge gate. This is what an AI-native engineering culture looks like when you take it past the product and into how the company itself operates.
The handoff was the bottleneck
Writing code was not the only scarce step. Someone still had to inspect the request, find the right repository, make the change, test it, respond to review, and prove it worked.
Giving a non-engineer a code generator would leave them holding a diff they could not evaluate. That is not leverage. It is a liability with a progress bar.
We moved the full workflow closer to the conversation while keeping merge authority separate.
Slack became the front door to engineering
Elty lives where the request already exists. Mention it in a Slack channel or thread, describe the change, and keep the customer context in the same conversation.
Underneath that interaction is a small runtime. Slack's Socket Mode sends the message to the service over a WebSocket connection. The service maps the thread to a durable job and starts or resumes the agent.
The thread remains the control surface. Elty can research the codebase, propose a plan, and ask for a decision. Buttons handle approval from a phone, while replies steer the same session without losing its history.
The program is mostly English: a working contract plus skills, engineering conventions, and operational memory. Elty sees the same repository guidance that our internal engineering agents see. When the team learns something once, we write it down once.
The agent owns the work between request and merge
After approval, Elty checks out isolated worktrees, changes the code, opens pull requests, and follows every check and review comment. New feedback wakes it on the same branch and context.
Elty does not merge. Its credentials cannot perform that action. GitHub's protected-branch controls provide the familiar review and status-check mechanisms, while our own credential boundary keeps the last production decision with an engineer.
Product, design, CS, and marketing can own a feature from problem to merge-ready pull request. Engineering owns the boundary where it enters production.
In July, Elty opened 84 pull requests and 45 merged into production. The team's award for most features shipped that month went to someone who does not write code. One customer request moved from a CSM conversation to production in roughly two hours.
Speed and quality come from the same system
A pull request can look reasonable, pass a build, and still fail the first time a customer clicks it.
Elty therefore has to demonstrate the feature. Each pull request runs in an isolated environment containing the frontend, backend, operational services, and a PII-purged, production-shaped dataset. The environment uses writable clones created from a golden snapshot, the same copy-on-write property described in the OpenZFS clone model.
Elty then drives a real browser through the change using Chrome DevTools for agents. It records what happened, fixes failures, pushes again, and repeats the loop. The final thread contains a video anyone involved can review without mentally executing a diff.
Nothing is ready to merge until both gates are complete: the feature has been exercised with evidence, and every automated or human review item has been resolved. A polished demo with unresolved review comments is incomplete. A green pull request that nobody ran is incomplete too.
What engineers work on now
Moving regular features out of the engineering queue shifted engineers toward systems that make the whole team more capable.
That includes the machine learning behind LTV.ai's decisioning layer, the proactive email marketing engine that brings verified campaign ideas to customers before anyone writes a brief, and the platforms that make realistic testing routine.
Engineers also improve Elty's boundaries, tools, memory, and evaluation loops. Better infrastructure makes each future feature cheaper.
The result is not a company without engineers. It is a small engineering team working on the few problems where its judgment compounds, while the people closest to a customer can fix today's problem today. It is the same conviction that runs through the product itself: an AI-native platform is not a team with AI features bolted on, it is a team that redesigns its own work around what these systems can now do.
Frequently asked questions
Can anyone at LTV.ai merge code into production? No. Non-engineers can take a request through research, implementation, testing, and a merge-ready pull request. A human engineer retains the final merge authority, and Elty's credentials cannot merge.
Does Elty ship without testing? No. A user-facing change must run in an isolated, production-shaped environment, pass required checks and review, and include delivered browser evidence before it is considered ready.
What happens when Elty gets stuck? It asks in the Slack thread, where a person can clarify the request or choose between options. Review comments and check results wake the same job, so work resumes on the same branch instead of losing its history.
Part of the machine learning behind LTV.ai.
We are hiring engineers who want to work on machine learning, big data, and the systems that make a small team unusually capable.