Applied AI, Agents, and New Ways of Building Software

1. From Vibe Coding to Agentic Engineering
2. Context Engineering for Project Management
3. ADEs and Skills: The Evolution of Development Tools
4. Sentinel: Agents for Observing, Fixing, Reviewing, and Auditing
5. QA & IAssistance: Testing with Natural Language
6. Agent Commerce: Agents as a New Commercial Channel
7. Conclusion

On June 12, we held an internal workshop at O2O to share some of the workstreams we are developing around artificial intelligence applied across the entire development lifecycle.

The session had a very concrete goal: to bring AI down from the general discourse into real use cases. We did not talk only about models, prompts, or standalone tools, but about how we are integrating agents, context, and automation into our day-to-day work.

Throughout the workshop, we shared six initiatives that come from different areas but share one point in common: AI creates value when it is adopted with method, context, and clear validation criteria.

From Vibe Coding to Agentic Engineering

We began with a key question for any development team: if AI can already generate code faster, how do we know that code is correct?

The answer is not to delegate more, but to work better. The shift we are exploring moves from so-called vibe coding, understood as generating code and accepting it without enough verification, toward a more professional practice of agentic engineering. In this approach, the goal is not for the model to write more code, but for the team to build a working system that can generate and validate changes in a governable way.

To achieve this, we focus on three fundamental elements:

1. Permanent instructions such as CLAUDE.md or AGENTS.md, which act as a working contract for the agent.
2. Skills or specialized rules that capture reusable project knowledge.
3. Verification loops with tests, hooks, and quality gates that allow AI to check the result of its own work.

We also connected this practice with frameworks such as Structured-Prompt-Driven Development (SPDD), which treat prompts and instructions as first-class artifacts that can be versioned and reused.

The underlying idea is clear: the value is not only in the model, but in the harness the team builds around it.

Author: Eric WalterAldas. Architecture

Context Engineering for Project Management

Next, we took that same idea into the field of management. In any digital project, we accumulate a large amount of knowledge scattered across documents, meetings, messages, scope changes, incidents, and informal agreements. If that knowledge is not structured, it degrades over time and ends up depending too heavily on people’s memory.

That is why we are working on context engineering applied to project management: a living structure that helps AI agents understand what a project is about, which decisions have been made, why they were made, and how the different workstreams relate to one another.

The approach is built around three moments:

1. Discovery, to collect and organize the initial information.
2. Planning, to transform that knowledge into actionable plans and tasks.
3. Execution and preservation, to keep the context alive as the project changes.

Here, context is not static documentation; it is a way to preserve the rationale behind decisions and make knowledge remain available when people, priorities, or project conditions change. We also explored the use of graphs to connect scattered information and allow an agent to reason about dependencies between decisions, tasks, bugs, and knowledge handoffs.

AI does not make decisions for the team. It helps us see the map more clearly before deciding.

Author: Jesmir Baloa. PM

ADEs and Skills: The Evolution of Development Tools

The next step is to look at how the tools we work with are changing. Agentic Development Environments (ADEs) are no longer designed only for a person to write code, but for AI agents to understand goals, plan tasks, and collaborate with human developers.

The difference from a traditional IDE is important. While the IDE is organized around code and the developer experience, the ADE is organized around the agent’s work: what it needs to know, which tools it can use, which tasks it can execute, and what limits it must respect.

In this context, skills become an essential piece. A skill is a structured instruction manual that teaches the agent to perform a specific task: auditing security in a project, generating commit messages according to our standard, creating tests, and so on.

Its value lies in three capabilities:

1. Automating instructions that we previously had to repeat manually.
2. Standardizing the way of working across people, projects, and teams.
3. Optimizing context by loading only the knowledge needed for each task.

Author: Nino Ruano. Android.

Sentinel: Agents for Observing, Fixing, Reviewing, and Auditing

With our Sentinel tool, we are building an intelligent automation system that integrates several specialized agents to support development tasks.

The ecosystem is organized around four agents:

• Observer: analyzes logs, categorizes errors, and detects relevant incidents.
• Developer: investigates an incident and proposes patches or technical solutions.
• Reviewer: reviews changes and provides comments on merge requests.
• Auditor: analyzes repositories to identify security and quality risks.

We are not looking to replace technical judgment, but to reduce mechanical work and speed up diagnosis. To do this, Sentinel works with structured sessions, controlled tools, and security guardrails. Human validation remains a central part of the process, especially before bringing changes into production.

And this is where context once again makes the difference. The better the agent understands the project’s architecture, patterns, and constraints, the more precise its recommendations are and the lower the exploration cost becomes.

Author: Pablo Lozano. Backend

QA & IAssistance: Testing with Natural Language

Our QA team is working on two complementary initiatives to reduce friction both in testing and in access to project information.

The first is AI-thana, a way to connect AI assistants with real mobile devices through Appium and MCPs. The goal is for a QA engineer to describe a test in natural language, for example testing a login in a specific environment, and for AI to be able to prepare the session, interact with the application, capture evidence, and move toward reproducible flows.

One technical challenge is converting complex mobile interfaces into compact representations the model can understand. Instead of huge, hard-to-manage structures, we work with lighter, numbered, actionable screen snapshots. This way, the model does not need to interpret the full XML of a mobile application, but a clearer, action-oriented version.

The second initiative is Alexandr-IA, focused on documentation queries and the generation of QA deliverables. The idea is to cross-reference information from technical documentation, tasks, attachments, screenshots, or Figma designs, and turn it into traceable answers or artifacts such as checklists, test cases, or downloadable reports.

Both lines point to the same change: moving from “where is the information and how do I automate this?” to “what do I need to test and with what evidence?” AI acts as an assistance layer that connects context, action, and documentation.

Authors: Javier Corroto & Pablo Nieto. QA

Agent Commerce: Agents as a New Commercial Channel

We are also exploring how AI agents can become a new commercial channel. More and more users discover products, plan trips, compare options, or start purchase processes from conversational assistants. For brands, this opens a strategic question: how can they be present in those channels without building an isolated solution for each assistant, model, or provider?

Our proposal for this scenario is Agent Commerce: a platform that encapsulates the client’s business logic and exposes it channel-agnostically. Instead of creating a client-specific chatbot, we propose a reusable core with business rules, integrations, and adapters for different protocols or interfaces.

In the current scenario, where payments fully delegated to agents still require regulatory maturity, we are working with an intermediate approach: the agent helps the user shape the decision so that, at the moment of purchase, an outbound handoff is generated toward the client’s website or application with the context preloaded. This reduces friction without replacing existing checkout systems.

This approach will allow us to prepare the architecture for future agentic commerce models, while maintaining a clear separation between channels, business logic, and integrations.

Author: Luis Della Chiesa. Data

Conclusion

The workshop leaves us with three important reflections:

• We need a common way of working with AI. It is not enough for each person to test tools separately; we need to turn what works into shared, reusable, and verifiable practices.
• If part of coding, testing, review, or documentation work becomes assisted by agents, the value of teams shifts toward defining problems well and making sound technical decisions.
• Many of these initiatives are not only internal improvements; they can also become value propositions for clients who are experiencing the same transformation.

This workshop is a snapshot of a specific moment, but also the beginning of a conversation that will continue to evolve. At O2O, we continue to explore how to apply AI in a practical, responsible, results-oriented way: not as a fashionable layer, but as a new way to build digital products.