The Config-as-Code Multiplier: A Full Marketing Data Stack. Solo. In Weeks.
How I used config-as-code tools and AI agents to build a marketing data platform alone in six weeks.
My previous post defines cognitecture as bounded delegation: AI agents move from context to outcomes under independent checks, a named owner, and recourse. This case is a demonstration, not proof. The traditional-team estimate below is mine; I never ran the counterfactual.
One client: an entertainment venue with fifteen data sources, including ticketing, ads, POS, web analytics, and tourism. It needed a data team it could not afford. I had AI agents and myself.
- 22 repos: pipelines, transformations, infra, monitoring
- 50 dbt models across 6 domains: 28 staging, 5 intermediate cross-domain aggregations, 17 mart-layer fact tables
- 8+ dashboards and counting
- Under $100/month infrastructure (all serverless: Cloud Run, BigQuery, Cloud SQL)
I delivered in 6 weeks what a 3-person team would deliver in 4–5 months, while serving other clients. Agents ran full-time: nights, weekends, and in parallel. I reviewed, verified, and steered.
Tool choice determines how powerful the agents become.
Why config-as-code is the multiplier
Imperative code requires understanding. The agent must grasp the architecture, patterns, and hidden contracts. An error can run yet return the wrong result.
Declarative config gives the agent a structure to fill. A dbt model is a SQL SELECT and a YAML schema. A dlt pipeline pairs TOML with a Python source. Terraform describes the end state in HCL.
The config format enforces the architecture for the agent.
- Fewer errors: structure limits what the agent can produce
- Built-in documentation: YAML, HCL, and TOML are readable
- Concrete checks: does it parse? Do the numbers match? Do the tests pass?
For agent-assisted work, declarative tools are my highest-impact choice.
the multiplier effect
The stack
Every layer uses declarative config that agents can read, change, and extend without grasping the whole system.
Ingestion: dlt
dlt moves data from APIs to a warehouse. Python sources pair with TOML for endpoints, auth, incremental cursors, and merge dispositions.
dltHub builds for LLM-native workflows. Its guide assumes an AI-assisted IDE. dlt init ships AGENT.md files and YAML scaffolds. Its workspace indexes 10,000+ REST APIs as context packages. LLM-assisted development drove a 20x increase to 50,000 custom connectors in one month.
Give an agent the API docs and destination schema, and get a working pipeline. I checked row counts and timestamps, catching config errors in 3 of 15 sources: date formats and pagination. Fixes took minutes. Credentials were the real bottleneck. TikTok trapped me in 2FA for three days. No agent can sweet-talk a support chatbot.
dlt’s own docs say it plainly: “The LLM doesn’t know how many records your source should have, whether the schema matches your business needs, or if incremental loading is actually working.” That’s your job.
Transformation: dbt
dbt makes each model a SQL SELECT and each schema a YAML file. Its structure enforces names and dependency order. An agent that built one staging model knows how to build the next.
dbt Labs released open-source Agent Skills to specialize general agents. Their framing: “Agents can see your dbt project as a graph, not a pile of files.” dbt also supplies structured context through lineage, semantic definitions, and contracts. SQL becomes a governed system.
Across 50 models and six domains, work flows from staging to intermediate to mart. Agents generate SQL, Lightdash schema YAML, and tests in one pass. The YAML ships with the model as its documentation.
Visualization: Lightdash
Lightdash reads dbt YAML directly. Meta tags define dimensions, metrics, and formatting. An agent that adds proper meta tags has done 80% of the dashboard work.
Lightdash calls this Agentic BI: “Most AI agents in BI tools are just chatbots on top of SQL. No consistency, no governance. We started with a semantic layer.” Dashboards live as YAML in git. The semantic layer can improve itself: when a metric is missing, an agent proposes it for human review.
Eight dashboards and counting. Agents build charts; I check them against source systems. The result is a self-service analytics platform. The client can explore a well-described dbt model in Lightdash, ask new questions, slice dimensions, and save charts without me. Governed definitions in code prevent accidental changes to “revenue” or double-counted conversions. The work delivers capability, not a pile of dashboards.
Infrastructure: Terraform
43 resources via Terraform: Cloud Run, Cloud SQL, networking, IAM, secrets. All HCL.
HashiCorp ships Agent Skills with HCL rules for coding assistants. Its Terraform MCP Server supplies current provider docs, helping generated HCL use current resource definitions. Project Infragraph aims to give agents a live knowledge graph of actual infrastructure.
Models and infrastructure share one abstraction: edit config files.
Where it breaks
Verification bottleneck. Agents outpace review. Five agents mean five outputs. Tests catch structural errors; domain experts must catch business logic errors. I haven’t solved this.
Historical data migration. Three ticketing eras use different schemas, IDs, and meanings. Agents wrote the SQL and dedup logic. Client conversations and domain judgment had to resolve duplicates and contradictions. CLAUDE.md cannot do that.
Attribution. Ad platforms and GA4 disagree because their models, counts, and cookie windows differ. Choosing the right number is a business decision. Agents can show both; I choose.
The 2 AM test. If Claude is down, can you read the config and fix the pipeline? YAML and SQL are debuggable at 2 AM; imperative generated code often is not. I stop whenever I catch myself approving work I do not understand.
Explain why the output is good in your own words. If you cannot explain agent work, do not approve it.
What I threw away
The alternatives failed, confirming the declarative-first principle.
Metabase. Agents choked on it. Without config-as-code or a semantic layer, charts became one-off definitions that could not be versioned or templated.
Evidence.dev. Its markdown and SQL worked well with agents, but it lacked the interactive features needed for self-service. Good for reports; wrong for exploration.
GCP Dataform. I switched to dbt because agents work better with its larger training corpus, community, and Lightdash integration.
Taste sets scope. I replaced tools that blocked declarative agent work.
How context compounds
Each repo has a CLAUDE.md with its structure, rules, key files, and deployment process. Agents start with full context.
Each task adds context. Ticketing staging models help build marts; the CLAUDE.md grew from three domains to six. By repo fifteen, the agent built full pipelines from templates to production in one session.
Governed, current, verified context cut repeated setup across these repos. The gain is case-bounded. It needs an owner and regular checks because context decays and conflicts.
Agents freed me to try ideas I could not justify before. I reverse-engineered an internal API with no public endpoint to recover years of data through network-tab archaeology. I also built a scraper for a dataset without a public API. Both were Claude-assisted, duct-tape-and-determination projects I had considered but could not defend. An evening’s work turns “probably not worth it” into “let’s find out.”
The takeaway
The stack choice creates the advantage.
Config as code multiplies force. Imperative code can multiply untrusted output until review costs more than it saves.
One person delivered fifteen sources, 50 models, 8+ dashboards, and 22 repos for under $100/month. A client that could not justify a data team now has a self-service analytics platform with better infrastructure than most companies that can afford one.
The tools made my judgment reusable.
What’s next
Because dbt + Lightdash works so well, I am considering OpenClaw. The client could ask an agent on WhatsApp for a model or dashboard: “Hey, can I get a breakdown of ticket sales by tourism segment?” The agent would scaffold the dbt model, add the Lightdash metrics, and open a PR. No middleman.
If the client gets an agent that does my work, what do I bill for? Taste, apparently. And TikTok 2FA.