AutoScout24's AI-Native Journey: How Codex and Agents Are Reshaping Enterprise Efficiency

When a Car Marketplace Embraces AI-Native

As one of the world's largest automotive marketplaces, AutoScout24's core mission is to connect car buyers and sellers around the globe. Recently, however, the company has been undergoing a deeper transformation—it is striving to become a truly "AI-native" enterprise.

Being "AI-native" doesn't simply mean "using AI tools." Rather, it refers to a form of enterprise that has been rebuilt from the ground up—from organizational structure and product design to engineering culture—with AI as its foundational infrastructure. This concept has a clear technological evolutionary lineage: it draws an analogy to "Cloud-native." The cloud-native movement emerged in the early 2010s, led by companies like Netflix and Uber, redesigning entire tech stacks around containerization (Docker), microservices architectures, service meshes, and continuous integration/continuous delivery (CI/CD).

This historical background itself carries significant strategic insight. The arrival of Docker container technology in 2013 and the open-sourcing of Kubernetes (K8s) in 2014 together laid the technical foundation for cloud-native infrastructure. Netflix's chaos engineering practices, Uber's experience decomposing microservices, and the advocacy of the CNCF (Cloud Native Computing Foundation) collectively transformed cloud-native from the engineering practices of a few internet giants into an industry standard. This history reveals a pattern: every paradigm shift in infrastructure gives rise to a group of "naturally adapted" winning enterprises—companies that don't patch up old paradigms but assume from the outset that the new paradigm is the default environment. AI-native is now replaying this history.

What's worth understanding more deeply is that the cloud-native movement was not merely a change in technology choices, but a fundamental reconstruction of organizational and engineering philosophy. Under the cloud-native paradigm, system design assumes from the very beginning that infrastructure is elastic, distributed, and programmable—meaning failures are the norm rather than the exception (hence the need for chaos engineering and resilience design), scaling is on-demand rather than pre-provisioned (hence the need for horizontal scaling and stateless services), and deployment is continuous rather than periodic (hence the need for CI/CD pipelines). This "disruption at the level of design assumptions" is precisely what distinguishes cloud-native from simply "moving traditional software to the cloud."

The logic of AI-native is entirely analogous: it assumes that intelligent reasoning capabilities are callable infrastructure by default, rather than an add-on module requiring dedicated integration. AI-native enterprises don't move traditional software to the cloud; they redesign entire systems around cloud characteristics like elastic scaling, microservices, and continuous delivery. Similarly, in AI-native enterprises, AI is not a plugin embedded into existing processes, but the default working substrate. AutoScout24's goal is precisely to complete this fundamental paradigm shift.

In conversation with the OpenAI team, AutoScout24's technical lead revealed that the company already uses Codex at scale across the entire organization—Codex being OpenAI's derivative model, specially trained for the code domain based on the GPT series of large language models, and one of the underlying technical foundations for mainstream AI coding assistants like GitHub Copilot.

The technical principles behind Codex are worth understanding in depth: it is based on the unified modeling assumption of "code as language," treating program code and natural language as different forms of expression within the same semantic space. After specialized fine-tuning on billions of lines of open-source code corpus from GitHub, it can flexibly convert between the two. The profundity of this modeling approach lies in its dissolution of the traditional barrier between "natural language" and "formal language"—from the perspective of the Transformer architecture, Python functions, SQL queries, Shell scripts, and English sentences are all essentially "token sequences," whose inherent grammatical rules, logical dependencies, and semantic patterns can all be captured within a unified vector space through the attention mechanism.

From a deeper architectural standpoint, code and natural language share the essential characteristic of "sequential dependency": the grammatical dependencies in natural language (subject-verb-object structures) correspond in code to variable scopes, function call stacks, and type constraints. The attention mechanism can automatically learn such long-range dependencies without relying on hand-crafted features—for example, the gap between a function definition and its call site may span hundreds of lines of code. Traditional RNN/LSTM architectures suffer from vanishing gradient problems when handling such long-distance dependencies, whereas the Transformer's global attention can directly establish these associations. Moreover, the "deterministic semantics" of code (the same function produces the same output given the same input) actually provides the model with a stronger training signal than natural language does—code execution results can serve as an objective reward signal directly usable in reinforcement learning fine-tuning, whereas the quality assessment of natural language text often depends on subjective human annotation. This characteristic of "automatically verifiable correctness" is also one of the technical reasons why code generation capabilities often lead open-domain text generation.

It's worth noting that the coding capabilities of Codex and its successor models don't come from hard-coding "programming rules" but emerge as statistical regularities from massive amounts of code—which also explains why each generation of model iteration brings nonlinear leaps in capability. Codex's abilities are not limited to completing code snippets; it can also generate complete functions from natural language descriptions, write unit tests, explain legacy code, and even perform cross-language transpilation. This is not merely a tool upgrade, but a fundamental shift in the working paradigm. They proposed a rather ambitious goal: to enable every engineer to achieve "hands-off coding"—where engineers drive AI to complete most implementation details through high-level natural language intent, shifting their role from "code writer" to "code reviewer and system designer."

The logic behind this vision is that once engineers are truly freed from tedious manual coding, efficiency gains will be exponential—not only reflected in the quantity of code output, but even more in the improvement of code quality. This is a judgment about the reconstruction of productivity, not a simple automation narrative.

The CapEx Agent Delivered in 48 Hours

What best illustrates the power of AI-native is a real-world implementation case. According to the AutoScout24 team, just 48 hours after OpenAI released its Agents feature, they had already built a "CapEx agent" (capital expenditure accounting agent) for all their product teams.

To understand this case, we first need to grasp two pieces of background.

The first is the technical architecture of AI agents. Unlike single-turn Q&A LLM calls, the core framework of an agent is typically called the "Perceive-Plan-Act loop," composed of three key modules: a large language model serving as the Reasoning Core, responsible for understanding goals, decomposing tasks, and generating action plans; a Tool Use Layer, which enables the model to interact in a structured way with external APIs, databases, file systems, and more; and a Memory & State management layer, responsible for preserving context across steps so the agent can handle complex, multi-turn, multi-step tasks.

The maturity of agent technology underwent a qualitative leap in 2023, driven by several key technical milestones. In June 2023, OpenAI officially released the Function Calling capability, allowing models to invoke external tools in structured JSON format, completely solving the format-adaptation problem between LLM output and program interfaces—prior to this, developers had to rely on fragile string-parsing solutions like regular expressions to extract structured data from model output, and this was a critical step in moving agents from the lab to production environments. At the same time, the popularization of RAG (Retrieval-Augmented Generation) technology enabled agents to dynamically access external knowledge bases, breaking through the limitation of the model's training data cutoff date. The core idea of RAG is to convert the user's query into a vector (embedding) at inference time, retrieve semantically relevant document fragments from a pre-built vector database, and then concatenate the retrieval results into the model's context—this allows agents to "instantly access" private knowledge such as internal organizational documents and real-time data, without expensive fine-tuning of the base model. The rise of orchestration frameworks like LangChain and LlamaIndex greatly reduced the engineering complexity of chaining multiple tools together, compressing agent prototypes that once took weeks to build down to days or even hours—this is precisely the direct technical background that enabled AutoScout24 to deliver the CapEx agent within 48 hours.

The collaborative operation of these three modules gives agents the ability to handle complex, multi-step tasks, fundamentally distinguishing them from the traditional "single query-single response" model. Take the CapEx agent as an example: its workflow involves extracting information across three heterogeneous data sources—the calendar system, Slack, and JIRA—performing cross-source correlational reasoning, and automatically generating structured reports. For traditional rule engines, such tasks would require large amounts of hard-coded logic, whereas for an LLM agent equipped with tool-calling capabilities, they can be flexibly driven by task goals described in natural language.

The second is the financial and compliance background of CapEx accounting. CapEx (Capital Expenditure) is an important item on a company's financial statements. Under the U.S. Generally Accepted Accounting Principles (GAAP) ASC 350-40 standard and the International Financial Reporting Standards (IFRS) IAS 38 standard, the labor hours spent on internally developed software can, once certain conditions are met (such as established technical feasibility and expected economic benefits), be converted from current-period expenses (Opex) into intangible assets on the balance sheet, directly improving current-period profit performance and smoothing the financial impact of R&D costs.

It's worth noting that these two standards involve considerable gray areas in their actual implementation within the software industry, which is precisely why tracking labor hours is so tedious. The standards require distinguishing between the "research phase" (expensed) and the "development phase" (capitalized), yet engineers' daily work often switches frequently between the two phases—the same engineer might be doing technical research (Opex) in the morning and switching to feature implementation (CapEx) in the afternoon. Furthermore, under the agile development model, the specific point in time for "technical feasibility" is often vague and difficult to define; the rapid pace of Sprint iterations means the clear "feasibility establishment point" of the traditional waterfall model has all but disappeared. Traditional manual reporting methods not only suffer from recall bias but also face audit risk—if the finance department and the engineering team disagree on how to categorize the same block of labor hours, it may trigger an accounting restatement, affecting the company's credit rating. By using objective data (calendar records, JIRA ticket labels, Slack discussion content) to automatically infer the nature of labor hours, AI agents significantly reduce audit risk while boosting efficiency.

The practical significance of this accounting mechanism is that every hour an engineer spends on "capitalized projects" can have a quantifiable impact on the company's financial statements. Accurately tracking the allocation ratio of engineers' labor hours between capital expenditure and operating expenditure is both a requirement for financial compliance and an important means of optimizing the company's financial performance. This mechanism gives the precise tracking of engineers' labor hours direct financial significance. Traditionally, this kind of statistics relied on engineers manually filling in time-tracking systems, which was not only time-consuming but also plagued by systematic "recall bias"—people's subjective memories of their own time investment often deviate significantly from reality, thereby affecting the accuracy of financial statements.

The way this agent operates is quite clever: it automatically browses team members' calendars, retrieves Slack chat records, and analyzes JIRA tickets, automatically generating a detailed labor-hour allocation table each week that clearly shows where each person's time is actually being spent—this is precisely a typical multi-tool chained execution pipeline.

For any company that needs to perform capital expenditure accounting, tracking labor hours is often tedious, time-consuming, and error-prone. Traditionally reliant on manual employee reporting and repeated reconciliation by the finance team, it also suffers from inherent problems like recall bias and data inconsistency. Now, an AI agent built in just two days has taken over the entire process.

From Tool to Value: Millions in Cost Savings

This seemingly inconspicuous agent has delivered astonishing economic returns. AutoScout24 estimates that this single agent alone can save the entire organization approximately one million in costs per year, with these savings coming entirely from freed-up working time.

This figure is worth pondering: it reveals the true business value of AI agents—not replacing core creative work, but eliminating those "hidden time losses" that are scattered throughout the organization, negligible when viewed individually but remarkably substantial when added up. The labor-hour accounting process spanning all product teams is a textbook example of such hidden costs.

The Cognitive Shock of Model Iteration Speed

Beyond the concrete efficiency case, the AutoScout24 team also shared an observation with broad industry relevance: AI models change so fast it's hard to keep up.

"These models change so fast," a team member admitted candidly. "Some approach you tried three months ago works completely differently today." This statement captures the shared challenge facing current AI adopters, carrying profound technical and managerial significance.

Looking at the pace of technical evolution, from GPT-3.5 to GPT-4, GPT-4o, and the o1 and o3 series since 2023, each generation of models has made significant progress in dimensions like reasoning ability, code generation, and multimodal understanding, with release cycles compressed from an annual scale to a quarterly or even monthly scale. This rapid iteration has given rise to a new form of technical debt—which can be called "Model Capability Debt": architectural decisions designed around the capability boundaries of older models often embed compensatory designs for those limitations, such as document-chunking strategies introduced because older models couldn't handle long contexts, or manual review checkpoints set up because reasoning ability was insufficient.

This "model capability debt" differs fundamentally from traditional technical debt, and understanding this distinction is crucial for enterprise AI governance. The management framework for traditional technical debt (such as the original concept proposed by Ward Cunningham) assumes that "debt" stems from conscious design compromises—choosing a suboptimal solution for the sake of rapid delivery, with the expectation of paying it back in the future. Model capability debt is entirely different: it isn't caused by design mistakes but by nonlinear leaps in external foundational capabilities. The deeper challenge is that leaps in model capability are often discontinuous—GPT-4's breakthrough in long-context handling and the o1 series' breakthrough in complex reasoning both represent "step-like jumps" on the capability curve rather than smooth transitions—making capability planning based on historical extrapolation nearly impossible to get right. What enterprises need to establish is not a "prevention" mechanism but a "response" mechanism that quickly identifies and refactors obsolete architectural decisions.

The systematic accumulation of such compensatory designs constitutes a special form of technical debt: it arises not because "the original design wasn't good enough" but because "the boundaries of foundational capabilities have fundamentally changed." When a new generation of models expands the context window from 4K to 128K or even a million-token scale, all the chunking strategies, summarization mechanisms, and information-retrieval architectures built around the assumption of "limited context" need to be re-evaluated. This differs fundamentally from the logic of managing technical debt in traditional software, requiring enterprises to establish entirely new capability-tracking and architecture-auditing mechanisms. When a new generation of models breaks through these capability boundaries, these compensatory designs not only become redundant but may even become obstacles to fully leveraging the new capabilities. Prompt engineering strategies and overall workflows may become suboptimal or even redundant months later due to leaps in new model capabilities. When the technical substrate iterates on a weekly or even daily basis, any judgment based on "last quarter's experience" may quickly become outdated.

This rapid iteration is both a challenge and an opportunity. Enterprises need to establish systematic "capability tracking" and "workflow auditing" mechanisms, continuously maintaining sensitivity to new capabilities and being ready to refactor their workflows at any time; that said, it also keeps opening up new spaces of possibility.

A Thought Experiment About the Future of Work

Most impressive of all was the technical lead's strong feelings about the future. He admitted candidly that after diving deep into AI capabilities, "there were several nights I couldn't sleep, because my brain kept exploding with all the possibilities—how we're going to work differently, and how it's going to change our entire industry."

This near-exhilarated insomnia precisely reflects the shock that AI-native transformation stirs in the hearts of frontline practitioners. It is no longer an abstract technology trend but is genuinely reshaping the daily operational logic of a global enterprise.

Three Takeaways of AI-Native for Traditional Industries

AutoScout24's practice offers several ideas worth borrowing for the AI transformation of traditional industries.

Redefine roles rather than simply layering on tools. The core of AI-native is not treating AI as an add-on, but rethinking "who does what." When "hands-off coding" becomes the goal, engineers' role positioning—shifting from code implementer to system designer and quality gatekeeper—and team collaboration methods will change accordingly. This role migration has historical precedents: in the 1970s and 80s, the transition from assembly language programmers to high-level language programmers also triggered similar "skill anxiety," but history proved that this transition, on the whole, expanded the size and influence of the software engineering community. However, the pace of role migration in the AI era is far faster than historical precedents, and the skill span involved is much greater: prompt engineering requires engineers to master a brand-new expressive ability that lies between natural language writing and system specification design; critically reviewing the quality of AI output requires engineers to establish a systematic understanding of common model hallucination patterns—for example, when facing long-tail knowledge rare in its training corpus, an LLM tends to output content in a "confident but wrong" manner (the hallucination phenomenon), and engineers need to develop detection intuitions for different types of hallucinations; and precisely translating vague business goals into executable intent requires engineers to possess cross-disciplinary abilities that in the past belonged only to product managers or business architects. This multidimensional skill reconstruction poses entirely new challenges to enterprises' skill structures and performance evaluation systems.

Start with small, well-bounded scenarios to quickly accumulate experience. That CapEx agent, delivered in 48 hours, chose precisely a scenario with clear pain points (tedious and error-prone labor-hour tracking), accessible data (calendar, Slack, and JIRA all have APIs), and clear boundaries. This path of "rapid trial and error, rapid results" is easier for building confidence than trying to overhaul the core business in one go, and it's also easier to quantify ROI. This strategy of "breaking through from edge scenarios" has another important advantage: well-bounded scenarios have low failure costs—even if the initial solution's results are unsatisfactory, it won't affect the core business, thus providing a low-risk testbed for the team to accumulate real AI application experience. Once the team has built a genuine understanding of AI's capability boundaries in edge scenarios, the probability of success in pushing AI-driven transformation of the core business will greatly increase.

Establish mechanisms for continuous learning and rapid response. Faced with rapidly iterating model capabilities, a solution that's effective today may need updating three months later. This means enterprises cannot treat AI integration as a one-off engineering project, but need to establish a continuous learning mechanism akin to "agile iteration": regularly auditing whether existing workflows are still the optimal design, tracking changes in the capability boundaries of foundational models, and quickly adjusting architecture when new capabilities emerge. In practical terms, this requires enterprises to incorporate "model capability tracking" into the regular responsibilities of technical teams, rather than treating it as an occasional research activity. A continuous learning mechanism is more strategically valuable than a one-off deployment—only by maintaining organizational agility can one continuously reap the technological dividends, rather than having existing workflows interrupted by each model iteration.

For one of the world's largest automotive marketplaces, the AI-native future is no longer a fantasy but a reality being progressively built line by line of code and agent by agent.

Key Takeaways