An application contains two different kinds of decisions. Some are the product itself: how a search works, what a user sees, how a calculation is made. Other decisions are settings: which model to use, which API endpoint to call, whether a feature is enabled, or how often a job runs.

Configuration is where those settings live.

Code versus configuration

Here is the practical difference:

The exact boundary varies by project. The useful question is: Should this value be easy to change without editing the product’s logic? If yes, it is probably configuration.

Common configuration formats

You will encounter several formats:

You do not need to choose a favorite. The tool you are using often chooses for you. Your job is to recognize that the file is changing settings, not teaching the system how to think.

A simple example

Imagine a research application. You might configure it like this:

research:
  default_model: "fast-analysis-model"
  reviewer_model: "reasoning-model"
  freshness_days: 14
  require_sources: true

features:
  saved_reports: true
  email_alerts: false

The application logic can stay the same while you change a model, tighten the freshness requirement, or turn on a finished feature.

Code: how the product worksApplicationConfiguration: settingsBehavior in this environment

Why configuration matters for AI builders

AI makes changes quickly. That is helpful until a small experiment requires editing the same value in five code files. Configuration creates a clear control surface: these are the values we expect to change.

It also lets the same application behave differently in different places. Your computer may use test data. A preview deployment may use a staging database. Production may use real customers and real billing. The code can be largely the same; the settings cannot be.

Sonariq as an example

Sonariq may need to select a research model, a validation model, a financial-data provider, a report freshness rule, or an enabled research module. Those are operating choices. They should not be hidden in an agent prompt or permanently welded into the application code.

Again, the deeper lesson is general: any AI project needs a place to change its settings safely and visibly.

A useful rule: do not over-configure

Beginners sometimes turn every sentence in their application into a setting. That creates a dashboard nobody can understand. Keep configuration for values that genuinely vary by environment, customer, provider, or operating decision.

If a value is central to the product’s meaning and should almost never change, it may belong in code or in the specification instead.

Practical exercise: find three settings

Look at a project you want to build. List three values that you may want to change later without redesigning the product. Examples:

• the AI model
• a public site URL
• a feature that is not ready for everyone
• a limit on report length
• a schedule for a daily task

Put them in a simple config.yaml file. Then explain, in one sentence each, why they are settings rather than core product logic.

Check your understanding

1. What is configuration for? 2. Name two common configuration formats. 3. Why might preview and production use different configuration values? 4. What is the danger of turning every product decision into a setting?