AI makes me much faster, but I stay accountable for what it builds. Speed only counts when I remain in control and the result is correct, explainable and safe. That gives three goals: stay in control, get deterministic results on a robust data foundation, and make sure guardrails and best practices are always followed. Below are the principles behind each goal, taken from daily practice on the projects in this portfolio, not from theory.
Ask a model the same question twice and you may get two different answers, with no way to check either. Let it generate code from agreed metadata instead: the code can be reviewed, and running it gives the same result every time.
Each principle serves one of the three goals, with how it shows up on this platform.
As a human I am accountable, not the model. So I want to be and stay in control: I keep understanding how things are done, and I avoid depending on one specific model or AI provider.
AI is an accelerator, not a replacement for knowledge. At this stage I must be able to build everything myself, and I fully understand every line of generated code before it goes in. If I cannot explain how it works, it does not go in.
In practice: every change is a git commit that I read, and merge requests are merged by me, not by the agent.
The knowledge lives in my platform, not in a model: standards, glossary, agent instructions and designs are files in git and metadata in OpenMetadata. Agents reach the platform through MCP, an open standard, and I prefer open-weight models. So I can switch model or provider without starting over.
In practice: the text-to-SQL agent runs the same open-weight Llama 3.3 70B on Databricks or on a European API; the RAG embeddings use an open-source model on my own server.
AI may read, explore, propose and prepare on its own. Anything that changes the outside world, such as deploying, publishing, deleting or uploading, needs my explicit approval.
In practice: a blog post is previewed before post_to_blog; before a website upload the live file is downloaded, compared and backed up.
An answer is only worth something if it is reliable: the same tomorrow, and explainable. That takes code instead of free-text answers, agreed definitions, and data that can be trusted.
Instead of asking a model for a number, I let it generate the code (SQL, dbt, PySpark, an Airflow DAG) that produces the number. Code can be read, tested, versioned and rerun, and gives the same result every time.
In practice: for self-service BI, build_query writes the SQL and the database computes the answer. See the semantic layer.
Generated code must follow the agreed business meaning, not the model's guesses. Business terms, formulas and joins live in the OpenMetadata glossary, where both people and agents read them. No definition means no code: the agent stops and asks.
In practice: an undefined term gives ERROR: Glossary does not define … instead of a guess.
AI is only as reliable as the data beneath it. Data is stored in an open table format (Delta) in clear layers, transformations are versioned dbt models with data tests, and tables and terms are described in OpenMetadata. A shaky foundation gives confident but wrong answers.
In practice: dbt builds the staging, silver and gold layers on Spark, with tests in schema.yml; ADS-B flight data lands in Delta and ClickHouse via Kafka.
AI works fast and sounds confident, even when it is wrong. Fixed guardrails and proven engineering practices keep its work safe, reviewable and reversible.
The same best practices apply to generated code as to my own: naming, layering, testing, security. The standards are written down once and searchable for agents (RAG), so every design and every line of code is checked against them.
In practice: the technical-design agent searches the standards for every architectural decision and cites them in its design.
Credentials never go into a prompt, a chat or git. They stay in protected files and inside MCP servers on my own server. Each agent gets only the tools it needs, and query tools are read-only.
In practice: see the MCP servers: tools per agent, credentials inside the server.
Infrastructure, pipelines, dashboards and designs are code (Terraform, Helm, YAML, SQL, dbt, Airflow DAGs), and the work is split into small steps with specialised agents. That makes AI work reviewable, reproducible and reversible, one readable result at a time.
In practice: information-analysis → technical-design → builder, each writing a design document to the repository.
An AI saying “done” is not evidence. Every step is checked against real output: dbt tests, validation after a deployment, a second source to compare with, and looking at the result myself.
In practice: the deploy agents end with a validator; the builder agent verifies each step and writes a build report.
The goal is to run and maintain the platform with AI as much as possible. These are the boundaries.