Subjective Wine

Applied AI, Mobile Architecture, and Agentic Software Engineering

The Project

Subjective Wine started with a simple question: Will I enjoy this wine?

The goal is to help people make wine selections based on their individual preferences rather than relying exclusively on general ratings or reviews.

A user can photograph a bottle, have the application identify the wine, and receive a personalized recommendation. As users rate wines, the system incorporates those preferences and experiences into future recommendations.

The application is functional and has been used regularly for real-world field testing. It remains under active development as I refine the mobile experience and expand its human review and feedback capabilities.

I am responsible for the product's architecture, technical direction, and engineering decisions.

An AI Application, Not Just an AI Response

One of the central architectural decisions was determining where AI adds value and where conventional application logic is more appropriate.

Identifying a wine from a photograph involves uncertainty. Labels can be incomplete, difficult to interpret, or ambiguous. Information about a particular wine may also be missing from the catalog.

The application uses AI to interpret bottle information and acquire structured wine characteristics when needed.

Identification, catalog matching, and information acquisition are handled separately from personalized scoring.

For recommendations, I chose a content-based approach rather than relying on an LLM to generate individual scores.

The scoring system compares wine characteristics with a user's preferences and rating history. Positive, neutral, and disliked experiences influence the recommendation, while onboarding preferences provide an initial basis until the user has established more history.

This separation offers several advantages:

  • Wine information can be acquired once and reused.
  • Personalized recommendations can be calculated without another AI inference.
  • Results are deterministic and repeatable for the same inputs.
  • Identification, information quality, and scoring can be investigated independently.
  • Individual stages can evolve without replacing the entire system.

The objective is to make probabilistic AI useful within an application that remains understandable, testable, and cost-conscious.

Recommendation quality and calibration are still being evaluated as the product develops.

Making AI Behavior Observable

A challenge with AI-powered applications is that a technically successful response isn't necessarily a correct one.

A model might identify the wrong wine, return incomplete characteristics, or produce information that leads to an unexpected recommendation.

I wanted to understand not just the final result, but what happened along the way.

The application retains structured diagnostic information about individual evaluation steps, including provider context, model and prompt versions, intermediate results, execution details, and relevant errors.

That makes it possible to investigate where a problem originated rather than treating an AI response as an opaque result.

The development environment also includes a Kubernetes-based observability stack with Grafana, Prometheus, Loki, Tempo, and Alertmanager.

The backend uses Pino for structured logging and OpenTelemetry instrumentation, with configured metrics and trace export. The observability services have been confirmed running in the development environment.

These capabilities provide a foundation for investigating application behavior and improving the system over time.

Human review and correction workflows are also being developed to support that process.

The objective is an observable, reviewable AI application—not an autonomous self-healing system.

Security and Privacy by Design

Security and privacy have been priorities from the beginning, not features intended to be added after the application is complete.

The architecture includes Google and Apple authentication, application-managed sessions, secure mobile credential storage, and authorization checks around user-owned resources.

On the backend, session credentials are stored using hashed representations, and access to application data and diagnostic information is controlled through authentication and authorization.

Structured logging includes safeguards intended to limit sensitive information exposure, with attention to what is collected and retained for troubleshooting.

These decisions reflect my preference for establishing appropriate security and privacy boundaries early, particularly in applications that handle personal preferences, account information, photographs, and AI-generated diagnostic data.

The intent is to build security and privacy into the architecture while continuing to evaluate and improve the controls as the product evolves.

Developing the Application Through Coding Agents

Subjective Wine has also been an important environment for developing my approach to agentic software engineering.

The application has been built through AI coding agents, with my role focused on requirements, architecture, technical direction, review, and decisions.

As the project developed, I introduced more deliberate controls around how agents work.

These include:

  • Defined responsibilities and bounded implementation tasks
  • Architectural standards and explicit ownership of technical contracts
  • Approval requirements for consequential changes
  • Automated testing and deterministic verification
  • Separate implementation, review, and quality-assurance responsibilities
  • Retained engineering decisions and review records

One particularly useful capability is source-aware verification.

The tooling associates verification results with the source state that was tested. When the source changes, an earlier successful result cannot simply be treated as evidence that the current code is valid.

This is one example of addressing problems that arise when agents generate code faster than traditional review and verification processes can comfortably accommodate.

The workflow continues to evolve as I identify weaknesses, improve verification, and refine the balance between agent autonomy and human oversight.

The goal isn't simply to generate more code. It's to establish an engineering process where agents can perform substantial implementation work while architectural judgment and accountability remain clearly defined.

Architecture and Technology

The application consists of a React Native mobile client, a TypeScript/Express backend, and a PostgreSQL database managed through Prisma.

The mobile application handles bottle photography, recommendations, ratings, history, and user interactions.

The backend coordinates wine identification, catalog lookup and enrichment, user preferences, deterministic scoring, and workflow diagnostics.

OpenAI models support selected identification, parsing, and information-acquisition tasks.

The engineering environment includes automated tests, source-aware verification, structured logging, observability instrumentation, and agent-development workflows.

Docker, Kubernetes, and Helm support local development.

The architecture favors a relatively straightforward application structure rather than introducing distributed infrastructure before the requirements justify it.

Current State

Subjective Wine is a functional application that I continue to use for field testing.

The core identification and recommendation workflows are implemented. Current work focuses on improving the mobile user experience, expanding human review and feedback capabilities, and strengthening the engineering processes used to develop the application.

The product remains pre-beta. Recommendation quality is still being evaluated, and there are additional capabilities to complete before broader testing.

For me, the project brings together several areas of engineering that I find particularly interesting: applied AI, software architecture, product development, observability, security, and agentic engineering.

It's both a working application and an opportunity to continue improving how software is built.

Technical Stack

  • Mobile: TypeScript, React Native, Expo
  • Backend: Node.js, TypeScript, Express, OpenAPI
  • Database: PostgreSQL, Prisma
  • Applied AI: OpenAI API, structured outputs, deterministic content-based recommendations
  • Infrastructure: Docker, Kubernetes, Helm
  • Testing: Vitest, Jest, PGlite
  • Agentic engineering: AI coding agents, structured reviews, source-aware verification
  • Logging and telemetry: Pino, OpenTelemetry
  • Observability: Grafana, Prometheus, Loki, Tempo, Alertmanager
  • Authentication: Google and Apple identity providers, application-managed sessions

Back to Selected Work