From “Just Let It Code” to “Build a Plan”: The Weaver Workflow

In the early days of AI coding tools, the vibe was simple: point the model at a problem and let it generate code.

That worked… sometimes. Mostly on small things. Mostly when you were lucky.

But as Viktor Nawrath (who leads Project Weaver at profiq) emphasized: the tooling is moving so fast that “last month’s information is already too old.” The models aren’t always making huge leaps every release, but everything around them is compounding fast: agent harnesses, tool integrations, workflows, and how we actually “drive” agents responsibly.

That’s where Weaver is headed next: not more hype, not more benchmarks.

A better workflow. And the foundation of that workflow is surprisingly unglamorous:

planning.

Not planning as a vague “think before you type” slogan — but planning as a first-class step that produces an artifact you can review, share, critique, and iterate on, before you let an agent loose on your codebase.

Why Planning Became the Industry Standard (Almost Overnight)

Viktor described a useful test for new models and tools:

The question isn’t “is it 5% better on a benchmark?”
It’s “can it do something the previous one couldn’t?”

One of those newer capabilities is planning: the ability for an agent to take a problem, ask the right questions, propose implementation steps, and only then move into execution.

This has quietly become the industry standard for agent-based coding. If you’re not doing some version of plan → execute, you’re likely feeling it already: loops, messy context windows, confusing diffs, half-right implementations, and a lot of “why did it do that?”

Planning doesn’t magically make agents perfect, but it dramatically increases the chances they’ll stay in the “smart zone” long enough to produce code you can ship.

The Weaver Take: Planning Isn’t a Chat Moment. It’s a File.

Most tools now support some form of planning. The difference with Weaver we keep coming back to is where that plan lives.

Many tools keep planning inside the same chat thread as execution. That seems convenient, until you realize what you’ve just done:

• mixed strategy and implementation in one noisy transcript
• inflated the context window with lots of back-and-forth
• made it harder for humans to review what matters
• made it harder to reuse the plan across different runs

Weaver’s approach starts with a simple move that changes everything:

Take the plan out of the conversation and turn it into an artifact.
A real file. A plan you can review and keep.

A Markdown plan in your repo, for example, has superpowers a chat thread doesn’t:

• It becomes portable. You can read it in GitHub, share it in Slack, attach it to a ticket, or use it as a design doc.
• It becomes reviewable. Humans can evaluate the plan without scrolling through an agent transcript.
• It becomes reusable context. The plan can serve as compacted context for later runs, without dragging all the chat noise with it.
• It becomes multi-agent friendly. You can spin up different agents to critique, simplify, or implement the same plan in different ways.

This one shift — “planning as an artifact” — is one of the core design decisions Weaver is built around.

Why This Matters More as Agents Get Faster

Viktor made an observation that feels obvious once you say it out loud:

As agents produce more code, faster, it becomes less practical to deeply review every line as the primary safety mechanism.

You still own the code. You still need to review. But the volume and speed are quickly pushing teams toward a different reality: you need better alignment points.

A planning artifact becomes one of the strongest alignment points you have.

Because if the plan is wrong, the code will be wrong, just faster.

And if the plan is solid, agents are surprisingly good at turning it into solid code.

What Makes a Good Agent Planning Workflow?

In Weaver, planning isn’t just “write steps.” We’ve outlined a set of properties that make the workflow resilient, especially on complex projects.

1) The agent should ask you questions before it proposes the plan

The biggest failures happen when an agent assumes a design choice that you would never accept, a trade-off that’s high-stakes and hard to reverse later. So Weaver’s planning flow explicitly encourages the agent to surface those decisions as questions.

Think: authentication strategy, data boundaries, multi-tenancy, queueing, performance constraints, deployment assumptions, integration surfaces.

Yes, the model might guess correctly. But the cost of guessing wrong is high. So we make it ask.

2) The plan should reflect real codebase touchpoints

If you’re adding a feature to an existing system, the plan can’t be written in abstract. It needs to understand the current codebase and where the new work will plug in. That means exploration, but done carefully.

3) Use sub-agents for exploration so you don’t pollute the main planning thread

Exploration is noisy: reading files, scanning modules, mapping touchpoints. If you do all of this in the same thread as your implementation plan, you waste context and muddy the artifact you actually want to keep.

Weaver’s approach uses sub-agents (or separate threads) to explore the current state, then brings back a clean summary into the plan. This is one of those small workflow tricks that feels minor… until you’ve watched an agent get lost because the context window got filled with irrelevant exploration output.

The “Phase” is a First-Class Citizen

Once you have a plan artifact, the next Weaver decision is how the plan is structured.

Viktor’s take is simple:

Large plans are where agents get weird.
They drift. They loop. They “do stupid stuff,” as he put it.

So Weaver pushes toward implementation plans that are split into phases, with each phase being:

• independently implementable
• roughly similar in size (as much as possible)
• verifiable and testable
• paired with clear acceptance criteria

The plan isn’t just a to-do list. It’s a sequence of small, checkable bets. This matters for two reasons.

First: it’s better for the human-in-the-loop

After Phase 1, you can stop, verify, steer, adjust. You don’t have to wait until the agent has generated thousands of lines of code before you realize it misunderstood something fundamental.

Second: it’s better for the agent

Each phase becomes its own bounded conversation, a smaller trajectory with a higher chance of staying coherent. Instead of “implement the entire plan,” the prompt becomes:

Implement Phase 1. Verify. Then Phase 2. Verify.

That doesn’t just improve quality. It improves predictability.

Verifiable Plans: The Quiet Advantage of NestJS

Our team called out something we’ve seen repeatedly in our NestJS projects:

NestJS makes it unusually easy to design work in a verifiable way. You can pair each phase with concrete checks: tests, endpoints, module boundaries, integration behaviors, observable outputs. That means each phase can end with a practical question:

Did we implement this correctly? If you can’t answer that, the phase wasn’t well designed.

The Real Lesson: The Plan Is the Product (At Least at First)

One of the most important moments is in the recommendation to:

• Don’t treat the implementation plan as something the agent needs, but you don’t care about.
• Treat it as the key alignment document between you and the agent.
• Read it. Edit it. Ask the agent to revise phases. Challenge assumptions. Change technology choices.
• Because once you have a great plan, the agent is in its best zone: turning a clear blueprint into good code.
• But if the plan is weak, you’re not going to get good code out of it, no matter how powerful the tooling is.

The Technical Side of Weaver

This post is the transition into telling the technical side of the Weaver story. Not “here’s a tool.” Not “here’s a benchmark.” More like:

Here’s the process we’re building for a world where AI agents are part of professional engineering.

Planning isn’t revolutionary anymore, it’s becoming standard.

But the details matter:

• Is the plan a real artifact?
• Can it be shared and reviewed?
• Does it force key questions?
• Is it phase-based and verifiable?
• Does it preserve context and avoid thread pollution?

Weaver’s answer is “yes” — because that’s what it takes to keep speed from turning into chaos.

What’s Next

In our next technical deep dive, we’ll explore another uncomfortable but essential topic:

How you provide agents with documentation and context, especially for third-party APIs, libraries, and services, without bloating the prompt and without letting the agent hallucinate its way into your production system.

If planning is the blueprint, documentation is the building code. And we’re learning quickly that both matter.

From Internal Workflow to Design Partners and Pilots

Everything described above is already in active use at profiq. Weaver has been tested on real projects with real constraints, and the workflow has proven solid enough to move beyond internal use.

Weaver supports the full journey — from early validation through production — without forcing teams to throw away demo code or rebuild later. It’s designed to let teams move fast while keeping a foundation they can trust.

In practice, Weaver functions like having a senior backend team working alongside you: architecture, APIs, data models, DevOps, QA, and security are handled through AI-driven workflows and senior engineering oversight. This allows profiq’s engineers to focus on what’s truly unique about each application rather than repeatedly rebuilding infrastructure.

We’re now opening Weaver to a small number of design partners and pilot projects who want to validate, build, and scale quickly and affordably. Weaver is ready for you. Let’s talk!