Structured Languages Are Thinking Tools in the AI Era

Structured languages help you think by forcing some decisions into visible forms. A heading names a section. A table requires columns. A schema defines allowed shapes. A program turns a procedure into operations that can be run.

None of these forms guarantees a correct result. They make selected assumptions, boundaries, and failure cases easier to inspect. Use natural language for intent, context, uncertainty, and negotiation. Add structure where explicit rules and mechanical checks improve the work.

Structure changes the questions you must answer

Consider this natural-language request:

Make a study plan for next week. Include two courses, keep each session under an hour, and leave Friday evening free.

A person can understand the general intent, but several decisions remain open:

• What dates count as next week?
• Does “under an hour” mean at most 59 minutes?
• How many sessions should each course receive?
• Is an empty Friday evening a hard constraint or a preference?
• What information does another program need?

Adding structure does not answer those questions automatically. It makes them harder to ignore.

Use a ladder of representations

Different representations expose different kinds of decisions.

This is not a ranking from weak to strong. Each representation has a job. A program can calculate session duration precisely while saying nothing about whether the plan is humane or educationally useful.

The related guide on choosing text and data formats owns the format-selection decision. Here, the question is different: what does each level of structure force you to decide while reasoning?

Begin with prose for intent

Write the purpose before designing fields:

I need a realistic plan for two courses. I want focused sessions short enough
to sustain attention. Friday evening should remain unplanned unless a deadline
makes that impossible. If the constraint cannot be met, report the conflict
instead of silently moving work.

This version expresses priority, a possible exception, and expected behavior when the request is infeasible. Those details are difficult to infer from a bare schedule.

Natural language remains useful when you need to:

• explain why a rule exists;
• distinguish a preference from a requirement;
• record uncertainty or missing information;
• negotiate competing goals; or
• describe an exception that has not been formalized.

The cost is that different readers can interpret the same sentence differently. When a detail controls software behavior or verification, make it explicit.

Add document structure for review

The same task can become structured Markdown:

# Weekly study plan

## Hard constraints
- Each session must be shorter than 60 minutes.
- No session may begin Friday after 17:00.

## Preferences
- Use two sessions per course.

## Missing information
- Assignment deadlines
- Existing calendar events

## Conflict behavior
- Report an unmet hard constraint. Do not silently override it.

Headings separate requirements, preferences, missing information, and conflict behavior. A reviewer can now ask whether each statement is in the correct section. A simple document check could confirm that every required heading is present.

The document is still mostly prose. “Two sessions per course” does not define dates or duration. That is appropriate if the task is still being negotiated.

Use data structure for a contract

After the decisions are made, JSON can carry a plan to software:

{
  "week_start": "2026-09-07",
  "sessions": [
    {
      "course": "CHEM 101",
      "date": "2026-09-08",
      "start": "16:00",
      "minutes": 45
    },
    {
      "course": "CS 101",
      "date": "2026-09-10",
      "start": "15:30",
      "minutes": 50
    }
  ]
}

A schema or validation function can require:

• a date and start time for every session;
• a positive integer duration below 60;
• a course from an allowed list;
• no duplicate session identifier; and
• no Friday start time after the stated boundary.

These checks are useful because they are repeatable. They are also limited. A validator cannot determine whether 45 minutes is enough preparation for an exam unless that judgment has been converted into a defensible rule with suitable inputs.

Use code when the procedure matters

A small function can express one rule:

def valid_session(session):
    if not 0 < session["minutes"] < 60:
        return False
    if session["date"] == "2026-09-11" and session["start"] >= "17:00":
        return False
    return True

Now you can test boundary cases:

minutes = 45  -> accepted
minutes = 59  -> accepted
minutes = 60  -> rejected
Friday 16:59  -> accepted
Friday 17:00  -> rejected

Writing the tests exposes the precise interpretation of “under an hour” and “Friday evening.” The code may still encode the wrong date, compare times incorrectly, omit another constraint, or implement a policy the student did not intend. Executability is evidence about behavior, not meaning.

Combine representations in one working document

AI-assisted work often benefits from a hybrid document:

## Objective
Create a realistic weekly plan without moving work into Friday evening.

## Rules
```json
{
  "maximum_session_minutes": 59,
  "friday_latest_start": "16:59"
}

Required output

• A short explanation of any conflict
• A JSON schedule that passes the validator

Verification

• Parse the JSON
• Run boundary tests
• Compare the result with the objective

The prose explains the task. The JSON gives software a stable interface. The
verification list connects the two.

Use clear boundaries, but do not mistake visible delimiters for control. An AI
system can still omit a field, invent a value, or return well-formed data that
violates the real situation.

## Compare the four versions

Choose one non-sensitive task with a small output. Represent it as:

1. one paragraph of prose;
2. structured Markdown with named sections;
3. JSON with required fields; and
4. a short program or validation rule.

Do not fill in a Markdown table. Give the comparison a short title and answer
these questions in short paragraphs, one for each representation:

- What decisions did this representation force you to make?
- What meaning became clearer?
- What information became awkward or disappeared?
- What can a tool check mechanically?
- What still requires human judgment?
- What happens when one value or delimiter is wrong?

Use `unknown` when the experiment does not answer a question. Keep the prose
close to the representation it describes so the comparison remains readable
without a visual editor.

Introduce one controlled failure. Set a duration to `60`, delete a required
field, or create a Friday conflict. Run the available parser, validator, or
test. Then inspect whether the error message helps you correct the underlying
problem.

## Common mistakes

- **Adding syntax before defining intent.** Begin with the decision or outcome.
- **Calling valid data correct data.** Validation covers only encoded rules.
- **Treating a schema as complete.** Unwritten requirements remain unchecked.
- **Assuming code is unambiguous.** Code has precise execution semantics, but
  its relationship to the intended problem can still be wrong.
- **Forcing uncertainty into false precision.** Keep unresolved judgment in
  prose and mark it clearly.
- **Choosing structure to impress an AI system.** Choose it for the people,
  software, checks, and recovery process that actually matter.
- **Skipping the human review.** A parsed schedule can still be a bad plan.

## Do this now

Represent one small current task in prose, structured Markdown, JSON, and one
validation rule. Introduce a known error. Record which form detects it, which
form explains it best, and which decisions remain yours.

## Log what you learned

Record only:

- **Result:** What did the action produce?
- **Evidence:** What observation, test, or source supports that result?
- **Next action or unresolved question:** What should happen next?