Minimum AI Knowledge for Practical Use, Part 4: A Good Input Package Beats a Good Question

A practical template for giving AI coding tools the right input package: goal, scope, constraints, evidence, and done criteria.

Contents

In the previous post, I covered tokens and context windows: the model has a limited space to work with.

That leaves the practical question:

What should we put into that space?

When asking AI to help with coding, the request often starts like this:

Build this.
Fix this.
Solve this error.

That is simple, but it does not always produce stable results.

The model may interpret the task too broadly, miss a constraint, or stop before the work is actually verified.

That is why I think a good input package matters more than a clever question.

An Input Package Is a Small Task Spec

It does not need to be formal.

It just needs to contain the minimum information the model should know before it starts.

Goal:
- What should be built or fixed?

Scope:
- Which files, screens, APIs, or flows are related?

Constraints:
- What must not change?

Materials:
- Logs, errors, examples, existing code

Verification:
- How do we know the work is done?

This alone improves output quality.

The most important parts are constraints and verification.

Humans often assume constraints are obvious. AI does not always share those assumptions.

A Bad Request and a Better Request

Suppose I want to add likes to blog posts.

This is not a bad request:

Add a like button to each post.

But it leaves many questions open:

• Can the same visitor like multiple times?
• Should previews call the like API?
• Should likes appear on the homepage?
• What happens when the API fails?
• What is the cost impact?

A better input package looks like this:

Goal:
- Add a like button to each blog post.
- Show like count on the homepage post summary too.

Policy:
- Private review screens must not call the like API.
- Only public posts should record likes.
- Prevent repeated clicks in the same browser with localStorage.

Related areas:
- Article HTML
- Homepage post cards
- Storage API
- Likes store or existing stats store

Verification:
- Clicking like on a public post increments the count.
- Private review posts do not call the API.
- Static page generation passes.
- Non-public post URLs stay unavailable externally.

Now the model is not just adding a button. It has the behavior and boundaries.

Always Define Done

One of the most useful habits is defining what "done" means.

Without that, the model may stop at "code changed."

But in real development, code changed is not done.

Done when:
- Typecheck passes
- Tests pass
- Local page is verified
- Production preview URL responds correctly
- Draft posts do not leak into public surfaces

This matters even more when deploys, data, auth, or billing are involved.

I like to split done criteria into command, screen, data, and operations checks.

This makes it harder for the work to stop at "the code changed."

"Do Not" Is Part of the Spec

AI needs negative constraints too.

Examples:

Do not:
- Add a blog link to the main homepage yet
- Break existing notification or automation commands
- Include draft posts in RSS
- Change an app client before checking whether the task needs it
- Print secrets or external integration URLs

These rules are mostly about safety.

Even in personal projects, production systems need clear boundaries.

Ask for a Plan First

Once the input package is ready, I usually ask for a short plan first:

Make a short plan first.
Include files to change, verification steps, and risky points.

The plan shows how the model understood the task.

If the direction is wrong, I can correct it before implementation starts.

This becomes more important as task risk increases. A small CSS tweak may not need much planning. Database, deploy, auth, cost, and security work should.

Input Package Review Checklist

Before handing off the task, I check these:

When this checklist passes, the model has less room to guess.

It also helps the human. After the work is done, there is less ambiguity about whether it is actually done.

A Reusable Template

This is the template I would keep:

Goal:
-

Background:
-

Related files/screens/APIs:
-

Constraints:
-

Do not:
-

Done when:
-

Process:
- Make a short plan first.
- Implement after the plan.
- Finish with changes, verification, and remaining TODOs.

Not every field needs to be filled every time.

For small work, goal and done criteria may be enough.

For a small UI fix, this may be enough:

Goal:
- Prevent post cards from causing horizontal scroll on mobile.

Constraints:
- Keep the desktop layout as close as possible.
- Do not add a new homepage menu.

Done when:
- No horizontal scroll at 390px width.
- Title and button text do not overlap.
- Report changed files and verification result.

Process:
- Make a short plan first, then proceed.

For deploys or data changes, the template should be filled in more carefully.

The important shift is this:

Do not ask the model to guess the work. Give it the work boundaries.

Summary

For AI coding work, a good input package is more reliable than a single good-sounding question.

Good input package:
- goal
- background
- related files/logs
- constraints
- do-not list
- done criteria
- report format

This reduces guessing and makes verification easier.

In the next post, I will cover RAG and search indexes: how AI can find documents or code for us, instead of requiring us to manually build every input package.