AI made it much easier to produce code.

But producing code is not the hard part anymore. The hard part is deciding what should exist, why it should exist, which rules it needs to follow, which risks it creates, and how the product keeps improving after the first version is shipped.

This is where the visionary part matters.

Ideas now have more leverage. A clear product vision, a strong mental model, and good judgment about the user experience can become working software much faster than before.

But vision alone is not enough. Someone still has to guide the system, define the constraints, notice when the AI is wrong, and keep the product coherent over time.

That is the work I now think of as stewardship.

On June 14, 2024, in my first GenAI workshop, I used this slide:

The slide was called "Why a Framework?" and the bullets were simple:

• Implementation is a detail
• Ideas are important
• UX is crucial
• Mental model and use cases are key

I think this is temporary, but right now we dream and then guide the AI to avoid mistakes and create sustainable products.

That is a huge disadvantage for non-professional developers. They can dream, but they cannot meaningfully guarantee the final result of the product. I believe this is temporary, and I can explain why.

The three pieces

To make this work, I think we need three pieces:

1. Foundation
2. Skills
3. Workflows

Foundation gives the AI the rules of the world. Skills turn repeated instructions into reusable procedures. Workflows connect those skills into a software development cycle.

With those pieces in place, and with humans paying attention to AI decisions, we already have enough to build great features. I want to show how we are doing this in a real complex project: Quave ONE.

How we are doing this in Quave ONE

In Quave ONE, we are treating AI-assisted software development as an operating system, not just as a chat window.

The goal is not only to ask the AI to write code. The goal is to give the AI a strong environment where it can make better decisions, avoid known mistakes, follow the way the team works, and keep improving the product without depending on one human remembering every detail.

Today, our system has three main layers:

1. Foundation
2. Skills
3. Workflows

They are different things, and I think that distinction matters.

1. Foundation

The foundation is the set of decisions that should be true before the AI starts working.

This is where we document the product, the architecture, the commands, the rules, the safety constraints, and the style of the codebase.

In Quave ONE, this starts with a root instruction file that explains what the project is, where each part of the system lives, which commands to run, what is safe, what is forbidden, and which quality gates must pass before finishing.

For example, the AI knows that Quave ONE is the product name, not an older or alternate name. It knows that the repo is a monorepo with the main app, MCP server, docs, website, shared package, and end-to-end tests. It knows that the Meteor app has special constraints, that server code must use async APIs, that enum values should not be loose strings, that public API changes require docs updates, and that Kubernetes access is read-only unless a human explicitly decides otherwise.

This matters because AI is very good at continuing patterns, but it is not automatically good at knowing which patterns are correct for your system.

So the foundation gives it the right starting point.

We also have longer internal docs for areas that need more explanation:

• Frontend structure and design system
• Meteor 3 compatibility
• Coding style
• Enum patterns
• Logging
• Audit events
• Secrets
• MCP tools
• Database apps
• Support automation
• Publishing workflows
• Production and staging references
• App-specific architecture notes

The important idea is that not everything should be in the always-loaded instruction file.

The always-loaded file should stay short. The deeper context can live in internal docs that the AI reads when needed.

A good foundation makes the first big decisions better. It prevents the AI from wasting time rediscovering the system. It also prevents a common failure mode: the AI writes plausible code that does not belong in the actual product.

2. Skills

Skills are repeatable procedures.

They are more specific than foundation docs. A foundation doc says, "This is how the system works." A skill says, "When this kind of task appears, do these steps in this order."

In Quave ONE, we have skills for recurring engineering and product operations.

Some are code-focused:

• Creating MCP tools
• Working with enums
• Running a structured autoreview
• Executing a GitHub issue from plan to PR
• Running a QA pass against an issue checklist
• Creating a PR with the right diff, tests, and body

Some are project-management focused:

• Creating GitHub issues
• Estimating issues with Fibonacci points
• Computing iteration progress
• Moving early-stage issues to the Icebox

Some are business or operations focused:

• Analyzing daily usage and billing changes
• Reading blog posts from Lemeno
• Publishing blog posts through Lemeno
• Watching production errors and operational signals

The value of these skills is that they encode the operational memory of the team.

For example, "create an MCP tool" is not one action. In our case, it can touch shared enums, business logic, REST endpoints, MCP registration, docs, lint, and tests. If the AI treats that as "add one file", it will produce something incomplete. The skill gives it the full path.

The same is true for issue execution. We do not want the AI to silently implement something and then summarize later. The workflow says: create the checklist in the issue first, work item by item, mark progress, run focused tests, review the diff, and link the PR.

That changes the AI from a code generator into a process participant.

A skill does not need to be complicated. It should define when to use it, what inputs are needed, which steps to follow, what proof is required, and what artifact should be left behind.

I think most companies should start building skills as soon as they notice themselves saying the same thing to AI three times.

The first version does not need to be perfect. It just needs to capture the current best workflow.

3. Workflows

The third layer is how the skills connect into a product development cycle.

This is where the steward role becomes very visible.

A single AI task can be impressive. But a product is not built from isolated tasks. A product needs intake, shaping, implementation, review, QA, release, measurement, errors, logs, and feedback.

There is another part that is very important in how I work: passive awareness.

I use Quave ONE, our own cloud system, with automation features to track errors and send them to me on Slack. Even when I am not actively looking at a dashboard, I am aware of the errors that are happening.

This matters because I am very methodical about logs. Logs are not noise to me. Errors are important signals and should be checked.

In an AI-assisted development loop, this becomes even more important. The AI can help write the feature, but the product has to keep talking back after the feature is deployed. Runtime errors, failed jobs, strange logs, customer reports, and usage changes are all part of the product feedback system.

In Quave ONE, the cycle looks roughly like this:

Idea or problem
  -> GitHub issue
  -> estimation
  -> execution checklist
  -> implementation
  -> focused tests
  -> autoreview
  -> pull request
  -> QA pass
  -> bug fix PRs if needed
  -> release
  -> Quave ONE automations watch errors and logs
  -> Slack alerts when something needs attention
  -> iteration progress
  -> usage and billing analysis
  -> new feedback into the backlog

The important part is that the issue body becomes the tracker.

The AI does not just "work on issue 123". It creates or updates an execution checklist. It marks the current item. It adds proof. It links PRs. If QA finds bugs, those bugs are added back to the checklist and connected to fix PRs.

This makes the process auditable.

It also lets humans steward the work without micromanaging every line of code. The human can look at the issue, the PR, the test plan, and the QA notes and decide whether the AI is moving in the right direction.

This is where I think non-professional developers are temporarily disadvantaged.

They can describe the dream. But without foundation, skills, and workflows, they cannot reliably inspect whether the AI is making sustainable product decisions.

The future will probably reduce that gap. Templates will get better. Skills will become more standardized. Agents will understand more about architecture, testing, and production risk by default.

But right now, the steward matters.

The steward is the person who can say:

• This belongs in the app, not infra.
• This needs an audit event.
• This enum should not be a loose string.
• This should be a workflow, not a one-off prompt.
• This issue is too large and needs splitting.
• This PR needs a focused test, not a generic summary.
• This bug should go back into the checklist.
• This production error is a real product signal, not background noise.
• This is a product decision, not only a code decision.

That is the difference between generating software and growing a product.

Externalizing this into a template

That is the Quave ONE version.

The reusable version cannot be "copy Quave ONE". Not every team uses GitHub Projects, Meteor, Slack, Quave ONE, or the same release process.

So the generic extrapolation lives in the template repo. The template is a guided conversation. It helps the AI ask what is true in your reality, inspect the repo when one already exists, and generate the foundation, skills, workflows, and runtime feedback loop that match your context.

We are externalizing these ideas into a reusable template here:
Visionary Steward Template

The simple way to use it is to give the template to an AI agent and ask it to guide you through the setup. If you are starting a new project, it helps create the first structure. If you already have a project, it helps inspect what exists, find what is missing, and add the pieces that make AI work safer and more consistent.

The goal is not to copy our stack, tools, or workflow. The goal is to take the pattern and apply it to your project.