Project Weaver: Building an AI Engineer in Three Phases

When we started Project Weaver at profiq, we set ourselves a goal that would have sounded unrealistic just a few years ago:

Build an AI-powered “engineer” that can help us design and implement serious, production-ready backend applications.

Not a toy demo. Not a one-off script. Something that can actually support real teams building real products.

Because we’re a software services company first, Weaver also has a second job. It needs to:

• Make our own engineers faster and more effective.
• Codify what we’re learning about AI-powered development.
• Eventually, test if this becomes a product we can offer to our customers as well.

That’s a big surface area. To make it manageable, we broke Weaver down into three phases and a clear six-month initial timeline. Each phase builds on the previous one, almost like a flywheel: once the first turns reliably, it powers the next.

This post is about those three phases, how they connect, and where we are right now.

Why We Needed Phases at All

“Build an AI engineer” sounds exciting, but it’s too vague to execute on.

We needed a way to answer very concrete questions:

• What should we build first that delivers value today?
• How do we know we’re moving in the right direction?
• How do we avoid over-engineering something that doesn’t work in practice?

Phasing the project gave us three things:

1. Incremental milestones – each phase has a tangible outcome we can use internally.
2. A learning pipeline – what we learn in Phase 1 directly shapes Phases 2 and 3.
3. A way to stay aligned with our services business – we can use each phase to upgrade how we deliver projects for clients, even before Weaver is “done.”

With that in mind, here’s how the phases break down.

Phase 1: The Cookbook – Best Practices for AI-Powered Development

Phase 1 is intentionally unglamorous: it’s “just” a cookbook. The goal is to write down the best workflows, prompts, and patterns for working with coding agents (like Claude Code, Cursor, etc.) so that our engineers can reliably get value from them on real projects.

Right now, using AI for coding is still a bit of an art. Some days you feel like a 10x engineer, other days the model gets lost and you spend more time cleaning up than you saved.

Phase 1 asks a simple question:

If you sit down with a coding agent to build or extend a serious backend, what is the most effective way to do that, step by step?

In practice, that means documenting things like:

• How to break a feature into a planning step and implementation steps the agent can follow.
• How to provide documentation (third-party libraries, APIs, external services) so the agent can actually use it.
• How to help the agent understand an existing codebase without overloading its context window.

Under the hood, a lot of this is about “specs” as a tool for context management. The agent creates and uses small, focused documents – plans, notes, summaries – that compress what it has learned so far into fewer tokens. Those specs are often throwaway, but they:

• Keep the context window from bloating.
• Let the agent “remember” what matters for the next step.
• Make the overall workflow more predictable.

Phase 1’s output is not code. It’s knowledge:

• A cookbook of workflows.
• Prompts and formats that work reliably for our stack.
• A set of patterns we can teach our engineers and, eventually, our clients.

We’re building this mostly stack-agnostic, but we already bias it toward the world Weaver will live in: API backends built with NestJS and a predictable architecture.

Where Phase 1 is today

At the moment, Phase 1 has three main pillars:

1. Plan & execute: How to break a task into an implementation plan and then guide the agent through the steps.
2. Working with external documentation: How to make the agent effective with libraries and services we don’t control.
3. Understanding the existing codebase: How to have the agent research the code, build focused summaries, and stay on track.

Two of those pillars are in good shape; the third is actively evolving. And the truth is: Phase 1 never really ends. Models change, tools change, and “best practices” keep shifting. But we’re close to a solid v1 that’s good enough to feed into the next phase.

Phase 2: Automation – From Cookbook to Background Agents

Phase 1 still assumes a human engineer is “driving.”

You have your IDE open. You have a coding agent on the side. You follow the cookbook:

• Ask the agent to draft a plan.
• Iterate on the plan.
• Ask it to implement the first part.
• Review, adjust, repeat.

Phase 2 asks a different question:

What if the agent could follow that cookbook by itself, in the background, and only pull us in when our judgment is actually needed?

In Phase 2, we take the workflows from the cookbook and automate them:

• Instead of sending many small prompts, the engineer sends a single high-level request: “Implement feature X as described in this ticket.”
• The agent uses the patterns from Phase 1—planning, context management, documentation, codebase understanding—to do the work mostly on its own.
• The human becomes a sparser, higher-leverage “human in the loop”:
  • Clarifying requirements.
  • Making design decisions.
  • Reviewing key changes.
  • Approving or rejecting results.

You can think of Phase 2 as turning the agent into a remote teammate:

• It runs on its own.
• It follows agreed-upon workflows and conventions.
• It pings you when it needs feedback, not on every keystroke.

This is where Weaver starts to feel less like “autocomplete on steroids” and more like a background worker that happens to write code.

We’ve already started experimenting here, partly to validate that the cookbook from Phase 1 is solid enough to automate. But automation remains Phase 2’s main focus.

Phase 3: Orchestration: Project-Level Partner, Not Just a Coder

If Phase 2 is about automating work inside a ticket, Phase 3 is about the level above that:

Given a product vision, how do we break it down into epics, user stories, and work items that agents can reliably execute?

By Phase 3, we assume a few things:

• We trust the workflows from Phase 1.
• We have agents that can execute those workflows in the background (Phase 2).
• We know how to express work in a way that agents can actually succeed with.

Now Weaver can start helping with project management and architecture, not just implementation:

• Taking a high-level description of an application and proposing a structure of epics and user journeys.
• Breaking those down into work items that are precise enough for agents to implement.
• Keeping the whole thing coherent so you end up with a scalable, robust, production-ready app, not a pile of loosely related features.

There is still a very important human role here. Phase 3 is not about removing humans from planning. It’s about:

• Helping humans think through the system more clearly.
• Capturing that thinking as explicit specifications instead of “in someone’s head.”
• Giving the background agents high-quality input so they can execute safely.

Done right, it becomes a flywheel:

1. High-level specs and plans (Phase 3)
2. Feed into background agents (Phase 2)
3. Which use well-designed workflows (Phase 1)
4. Which generate insights that improve how we plan the next iteration.

We’re still early on this part, but this is where Weaver starts to look less like a tool and more like an AI collaborator for the entire lifecycle of a backend project.

The Timeline: Six Months, Three Phases, Lots of Overlap

For the initial run of Project Weaver, we set a six-month horizon. Roughly:

• Months 1–2: Focus on Phase 1 (the cookbook).
• Months 3–4: Shift primary focus to Phase 2 (automation).
• Months 5–6: Start investing more heavily in Phase 3 (project-level orchestration).

This is not a strict waterfall. In reality:

• We jump between phases when needed to validate ideas.
• Work in Phase 1 continues even as we start automating parts of it.
• Early experiments in Phase 3 help us sanity-check decisions we’re making in Phases 1 and 2.

Right now, most of our energy is still in Phase 1: getting the workflows right, making sure agents are reliable, and understanding where they fail. That foundation matters more than anything else. If we don’t trust the workflows, there’s no point in automating them or scaling them up to project scope.

Why This Matters (Beyond Weaver Itself)

One thing I want to emphasize: Weaver is not just a product experiment.

Because profiq is a services company, each phase is designed to give us immediate, practical value:

• Phase 1 makes our engineers better at using AI agents today.
• Phase 2 lets us start handling parts of projects more efficiently and consistently.
• Phase 3 paves the way for taking on more ambitious work with smaller, more focused teams—humans plus AI.

It also puts us in a good position to help other teams think about AI-powered development:

• How to adopt coding agents in a sane way.
• How to pick the right workflows for their stack.
• How to move from “copy-paste prompts” to something that looks more like a real engineering discipline.

We’re still early. We don’t have all the answers. But we’re committed to doing this in a way that is honest, transparent, and grounded in actual production work—not just demos.

What’s Next

Over the next posts, we’ll go deeper into:

• How we’re using specs and context management in Phase 1.
• What our “plan and execute” workflow looks like in practice.
• How we’re thinking about automation in Phase 2.
• And later, how Phase 3 starts shaping real project roadmaps.

For now, we hope this three-phase view gives you a clearer picture of what Project Weaver is, why we structured it this way, and how it fits into the future of AI-powered backend development at profiq. Thanks for following along, we look forward to your feedback. Let us know if you’d like to be one of the first to test out rapid AI product development.