Skip to main content
News

Building an Agentic Engineering Team

By David Judd, CEO of CodeLantern ·

Coding agents can help an individual engineer move quickly from an idea to working software. The next challenge appears when that work becomes part of a team's delivery process.

Can another engineer understand the approach, review the result, and continue the work? Can the team delegate execution while keeping decisions and evidence visible? Does each completed task leave useful knowledge for the next one?

Those questions shape how we work with agents at CodeLantern. We use a shared workflow in which engineers establish intent, shape the approach, and remain accountable for the result. Agents contribute throughout the process, and the work leaves records that teammates can inspect.

This article follows one small feature through that workflow. It shows where human judgment matters, what makes delegation practical, and how knowledge can survive beyond the conversation that produced the code.

In this article

From individual progress to shared delivery

Vibe coding can be an effective way to explore an idea and get something working. The challenges become more visible when someone else needs to extend, review, or maintain it.

Important context can stay with the person who built it. The code is available, but the reasons for decisions may be buried in a private conversation. A teammate inherits the result without the reasoning that would help them assess it.

Each engineer also brings a personal way of working. Different approaches can produce different records and expectations at handoff. One task may have a clear design and test plan, while another requires the reviewer to reconstruct the intent from the changes.

Execution can also get ahead of understanding. As teams delegate more autonomous work, they need ways to stay informed about what is being built, why the approach makes sense, and what has actually been verified.

An agentic engineering team brings people and agents into a shared engineering process. Engineers clarify what matters, weigh trade-offs, and decide what to delegate. Agents can investigate the existing system, explore designs, plan work, and assist with implementation and review.

The team owns the outcome. That includes keeping enough context for someone else to challenge the approach and maintain the software after the original session ends.

A workflow that supports delegation

Two principles guide our workflow.

Convergence means reaching a shared understanding of the intent and approach. Questions, alternatives, and disagreement help expose assumptions before implementation. A recorded design and plan give another engineer something concrete to assess.

Extraction means capturing what is worth keeping as the work progresses. Decisions, departures from the plan, verification results, and reusable lessons become part of the project's records. The team can consult them without replaying an individual conversation.

We organize that work into six stages: Intent, Co-design, Plan, Implement, Review, and Learn.

The operating loop makes responsibilities and handoffs visible. Stages can overlap or repeat as the work requires.

A review may reopen a design question. Learning may emerge during implementation. The stages help explain what the work needs and what each activity leaves for the next person or agent.

How we implement the workflow

At CodeLantern, we support this workflow with reusable skills: instructions that guide the agent's work with the engineer. They help give activities such as specification, planning, and review a consistent structure.

The skills draw on a project knowledge base. It contains shared conventions, decisions, and lessons stored as Markdown alongside the code. People and agents consult this guidance as they work, and they capture useful knowledge for future tasks.

The work also produces shared records. Issues and pull requests hold the specification, design, implementation plan, decisions, and verification evidence. Engineers approve the plan before implementation and review the resulting changes before merging. Within an approved plan, the agent can work through phases with verification while the engineer remains available for decisions.

Skills support the workflow, while shared project knowledge informs the work and grows through it.

This is our implementation of the method. The principles can be applied with other tools. In the example below, skills, knowledge files, and GitHub records provide the context for collaboration between engineers and agents.

The example: from a total to its transactions

Our example application is a budget tracker. Its Budget Summary cards show income and expenses for different periods. The financial data shown in the screenshots is fictional.

The feature request is straightforward: make a summary card clickable so the user can see the transactions behind its total.

I establish the request and review the work. Casey works with an agent to design and implement it. Although the feature is small, it raises questions about date ranges, transaction classification, navigation, and verification.

The feature connects a Budget Summary card to the transactions contributing to its total.

Intent: agree on success

My initial request starts a conversation with the agent. Through questions and refinement, we converge on what needs to be built.

This early part of the loop requires active participation from the engineer. We are shaping the intent together, before delegating implementation. The agent helps expose assumptions and alternatives, while I clarify the outcome and decide what belongs in scope.

Which cards should respond? Which transactions belong in the result? What should happen when the user clears the filter?

In this exchange, I clarify that the user needs a filtered transaction list and a control to clear the filter. Additional filtering controls can wait. That decision gives the immediate feature a clear boundary.

The agent questions the request, and David narrows the scope. Their conversation establishes what needs to be built before implementation is delegated.

This is the purpose of the grilling process: make assumptions visible so the engineer can clarify the intended behavior and scope. The specification records the understanding reached through that conversation.

The discussion becomes a specification with testable acceptance criteria. The list must contain the correct transactions for the selected period, and the user must be able to clear the filter. The list needs to explain the card's total, so a plausible-looking destination alone would not establish success.

Ready for the team

Recorded acceptance criteria

Illustrative sequence: the issue enters Ready with its scope and acceptance criteria recorded, giving the next teammate a shared starting point.

Issue four enters the Ready column on the team board. Opening it gives Casey the request and acceptance criteria she needs to begin, without replaying my conversation with the agent. The work is both visible to the team and defined well enough for someone else to take it forward.

Co-design: understand the consequences

Casey claims the issue, moving it into In Progress. Before proposing an approach, her agent reads the project knowledge base and existing implementation. The design needs to fit the application's conventions and current behavior, including its rules for classifying income and expenses.

That investigation uncovers an existing date-boundary problem. For affected users, the last-month calculation can omit a transaction at the boundary. Correcting it may change a total already displayed on the dashboard.

Casey asks the agent to explain what the correction would change. The answer affects scope: the work would add navigation and also correct existing calculation behavior.

After discussing the alternatives and their consequences, she accepts the correction. The team now has an explicit decision and a reason for extending the change beyond the original request.

Clarifying the consequence

Choosing the approach

Casey makes the scope decision after understanding how the proposed correction could affect existing behavior.

The conversation produces a solution design that records the choices and their rationale. That artifact is available through the pull request, giving teammates a shared place to inspect the approach before implementation.

One recorded decision preserves the selected date range in the URL, so a link retains the dates it was created to show. A teammate can read what was chosen and why, challenge the reasoning, and later check whether the implementation follows it. They can do that without replaying Casey's conversation with the agent.

The pull request makes the recorded design decisions and their rationale available for teammates to inspect, challenge, and use during implementation review.

Co-design leaves the team with an approach it can explain and challenge. The next step is to make that approach ready for execution.

Plan: define the work and its verification

Before laying out the implementation phases, the agent examines the project's existing test patterns. Verification shapes the plan from the start.

The work is divided into five phases:

  1. Create the shared budget-period utility.
  2. Align the card calculations.
  3. Add transaction filtering.
  4. Make the cards clickable.
  5. Add the dismissible filter chip.

This order exposes the dependencies. The underlying behavior comes before the interaction that uses it. The plan also calls out the correction to existing behavior, allowing the reviewer to assess the full scope before execution.

Each phase includes tasks, tests, and completion criteria. The agent has guidance about what to build and what evidence to produce. The developer has checkpoints to inspect, and the eventual reviewer has expectations against which to assess the result.

The five implementation phases

Verification defined before implementation

The plan defines both the sequence of work and the evidence required to consider each phase complete.

Casey asks me to review it. I agree with the correction to existing behavior and add context about why retaining the URL approach fits possible future needs.

Casey invites David to review the plan. His response confirms the proposed correction and adds context about future needs, shaping the approach before implementation.

This review brings another engineer's judgment into the work before implementation. We have a concrete proposal to discuss while changes are still relatively inexpensive to make. Plan approval then records our agreement on the pull request. The completed code and behavior will receive their own review.

Implement: delegate with evidence

With an agreed approach, bounded phases, and verification expectations, much of the execution can be delegated. Casey monitors progress and remains available when a blocker or decision needs attention.

After the first phase, the agent records the changes and checks it ran. It also identifies a potential learning while the context is fresh. A later consolidation step will determine whether that learning belongs in the knowledge base.

Each phase has its own commit, making the progression visible in the pull request. The agent can continue through approved work with its checks without requiring a new human approval at every phase.

Changes and checks recorded together

Progress visible in the pull request

Phase reports and commits give Casey evidence to inspect while delegated work progresses.

Execution also produces decisions worth retaining. In this example, the agent records a test-coverage choice and how test corrections were handled. A passing check tells the reviewer about a result. The explanation of why a test changed helps them assess whether the correction was appropriate.

This way of working can create room for an engineer to consider another task or review a teammate's work. The attention required depends on the task and what happens during execution. The example demonstrates recorded progress and decisions, rather than measuring how Casey spent that time.

The implemented interaction returns us to the original request. The dashboard card responds as a link, and following it opens the Transactions page with an Expense, Last Month filter chip. The user can see the active filter and clear it.

The user can move from a summary total to a visibly filtered transaction list, then clear the filter.

I exercised all six cards and checked that the filter could be cleared. That provides interaction evidence alongside the automated checks. Verifying that the list contains exactly the transactions behind the total also requires checking the filtering rules.

Review: apply team judgment

The pull request brings the implementation back to another teammate for assessment. Its summary describes the change, and the supporting records include the plan, decisions, and verification results.

The knowledge updates are already in the same pull request. Although we explain learning after review in this walkthrough, consolidation happened beforehand, making the code and captured guidance available to review together.

A review agent raises two concerns.

First, a saved link retains its original dates, but its period label can become misleading when the link is reopened later. The stored date range and the label no longer necessarily describe the period in the same way.

Second, the implementation shares the filtering rule less fully than the design describes. The paths currently agree, but separate rules could drift apart after a future change. This finding tests a claim in the design against the code that was actually produced.

Review examines user behavior and whether the implementation fulfills the recorded design.

I accept the chip wording as an interim trade-off in the context of future filter controls. That records a conscious limitation for this version. I choose to raise the shared-filtering concern for consideration because it could strengthen the relationship between the design and the implementation.

The posted comment proposes a shared membership rule and a focused test comparing the contributing transactions. It also acknowledges the additional scope, making this a concrete, non-blocking suggestion for Casey.

The reviewer turns an agent finding into specific feedback with a rationale and an explicit scope trade-off.

The agent helps identify concerns. The human reviewer decides their significance and what feedback to take forward. The captures show the suggestion being posted; they do not show that proposed refactor being implemented.

Learn: retain what future work can use

Learning means deciding what this work has taught us that can help the next task. Some lessons emerge during implementation. Consolidation provides an opportunity to select and organize them while the context is still available.

For this feature, consolidation proposes four knowledge-base changes: two lessons, an update to the component description, and a reusable recipe. It also explains what it leaves out. Some candidates are already covered by existing conventions, while others are too general to provide useful project guidance.

The first retained lesson says to use the same membership rule for a summary and its drill-down. Review also challenged how fully the implementation followed that principle. Keeping the guidance beside the code makes the relationship available for scrutiny.

The second lesson concerns transaction classification. A positive refund can still belong to an expense category. In this application, the display amount's sign alone cannot determine whether a transaction belongs in an expense filter. The category provides the relevant classification.

The retained lessons describe specific project rules and pitfalls that future work can check.

The recipe brings the dashboard drill-down approach together. It gives another engineer or agent a starting point for connecting a summary to a filtered transaction list, preserving the selected period and applying the correct classification rules. They still need to check how that guidance applies to the next task.

The recipe preserves a reusable approach beyond the conversation that produced the feature.

These knowledge updates have their own commit in the same pull request as the code. They can be reviewed together and remain part of the project's history. After the pull request merged, the knowledge changes synced and appeared in the portal as well.

Each work item can contribute guidance that informs later work.

When a future task needs a similar interaction, relevant knowledge can be selected and brought into context. This example shows the capture and availability of that guidance. Assessing its value means examining how it helps future work.

Observe the process and its outcomes

A shared workflow also needs a way to assess whether it is helping the team.

Start with the metrics in the tools the team already uses. Issue trackers, pull requests, and build systems provide information about how work moves and where it waits. CodeLantern can add visibility into knowledge capture and agent activity to help explain that picture.

The useful questions concern delivery and learning. Are we capturing knowledge that helps later tasks? Where does work wait, and what causes the delay?

Illustrative data

Illustrative data: activity and timing signals help teams investigate the process. They are not measured outcomes from this feature.

More knowledge entries alone do not demonstrate improvement. A long wait might reflect unclear scope, a review bottleneck, or a dependency. Interpret those signals alongside quality and delivery outcomes, then use them to decide what to change.

Questions to take back to your team

The walkthrough offers six checks for assessing your own way of working:

  • The work is shared and visible. Another teammate can find the intent, approach, and current state.
  • Collaboration happens before implementation. Engineers can challenge assumptions and consequential decisions while the approach is still taking shape.
  • Delegation is bounded and reviewable. The agent has defined scope and verification expectations, and the team can inspect the result.
  • Knowledge outlives the agent session. Useful guidance remains with the project for future engineers and agents.
  • Performance is observable and connected to goals. The team can examine delivery and quality against its engineering and business needs.
  • Measurement helps the team improve. Evidence informs changes to the working method.

Two questions bring these checks together.

Team ownership: Could another teammate understand, challenge, continue, and maintain this work without depending on the original developer or replaying their agent sessions?

Team performance: Can the team tell whether this way of working is improving delivery against its engineering and business goals?

In this example, interaction with the agent helps us converge on a shared understanding of both what needs to be built and how to build it. Questions, challenges, and refinement make assumptions visible and give engineers opportunities to shape the approach before delegating implementation. Extraction happens throughout that work: alongside the specification, design, and plan, we record key decisions, their rationale, deviations from the plan, and verification results as they arise. Reusable lessons become project knowledge. Together, these records let another teammate understand how the work took shape, assess the result, and carry useful context into the next task.

Getting started with a real project

Spark is CodeLantern's four-week engagement built around a small team and a real software project.

In the first week, we establish the foundation: help the team understand the approach, connect it to the existing development process, and begin building the knowledge base.

In weeks two and three, we apply the workflow to real work items and start establishing a baseline. In the final week, the aim is for the team to take more of the lead, supported by the shared process and accumulated project knowledge.

The starting point could be an agent-built prototype, a modernization initiative, or a new product idea. The project and the team's needs determine whether Spark is a good fit.

To discuss a project or request our Agentic Team Readiness Checklist, contact info@codelantern.com.