You just turned your Engineers into Engineering Managers — Without Realizing It

Background

My work with language models began years before ChatGPT's public release in late 2022. As an early user of OpenAI's APIs, I built prototypes for agentic conversational systems before today's abstractions and terminology became standard. These systems included schema-constrained JSON generation, reasoning and action loops inspired by emerging research, and retrieval and memory architectures that ranked information by recency, importance, and similarity.

Today, I apply that experience to agentic engineering: designing products and developer tooling that helps humans and software agents plan work, execute it, evaluate the results, preserve knowledge, and continuously improve the engineering process.

Problem - No Process

Few teams have mastered their engineering methodologies enough to incorporate AI tools into their processes successfully. In the competitive technology landscape where productivity is paramount, it's simply just easier to hand team members Claude Code, Copilot, Codex CLIs as a baseline and review the work upstream.

Some engineers find their way to skill plugins, while others just prompt to completion of a task. In general, you may see accelerated feature development in the short-term, but in the long term across an entire team, there is no alignment between agents, and no standard approaches backing the agentic execution which leads to larger and larger technical debt if left unchecked. It directly introduces more rework which can put a drag on your agent costs and overall timelines.

The problem with agentic engineering isn't that agents cannot write enough code. It's that we're giving individual engineers dramatically more engineering capacity without giving them the systems to manage it. In this lies the root of today's productivity and quality problems with AI Coding Tools.

The Evolution of Work

Over the last two years, I have reflected on how I and other team members use these agents, and as most have, developed various prompts, skills, and agents to align with my development methodologies to implement larger and larger products. Hand in hand, agents have improved in their understanding of context, reasoning over that context, and executing on patterns described in that context.

With every general model and system upgrade, we see this improvement move the needle of execution capabilities. In 2022, we could develop functions and classes with ChatGPT, but needed to check and integrate the work because of hallucinations an small context availability, along with poor needle-in-the-haystack performance. There were no deep interfaces into development tooling and integration was custom if you wanted it. In 2026, we see full integration to our work-spaces and IDEs allowing full execution and testing of epics of work end to end.

Engineers have effectively become managers of agentic execution without asking for the role. We gave them additional engineering capacity, but rarely gave them the methodologies, standards, and controls required to manage that capacity consistently and effectively.

The Engineering Execution Lifecycle

Stepping back a bit, we reflect on a massively simplified view of the engineering execution life-cycle when building products. It is important to reflect on what value is lost when handing off user stories to engineers without the proper processes in place to maintain a methodology for your execution.

When you chat with your agents to implement feature sets, you generally lose this process if no structured prompts are provided, or standards are not front-loaded. It can be from lack of trying, or lack of established knowledge or internal processes. Remember to put yourself in the shoes of your engineers – you were an engineer, and you instantly became engineering management as soon as someone gave you access to Claude Code, Copilot CLI, Codex CLI, etc...

Solution – Adopt an Approach

Adopt an opinionated development approach for your team before handing them the keys to Agentic Tooling. What we have seen with Agentic Engineering is that providing standards and guidelines for implementation improves overall agent execution. In-Repo docs, agents and skills can align work to your approaches, methods and repository codebase without verbose searching and compacting up front.

Agents follow implementation guidelines just like humans and can benefit from the same Test-Driven Development and Spec-Driven Development practices. Early structural context can positively impact downstream agentic work when context is preserved. Therefore, below, we reflect on those methodological practices implemented in the form of Agents and Skills for an engineer's agentic loop to improve your team's execution capabilities.

Methodologies

If you do not know how exactly to apply your own workflow, just adopt one. I found that Speckit, while not perfect, gives you an approach to follow while you hone and align your own practices for agentic engineering work. Combining an existing methodology with your practices can yield aligned work quickly and efficiently, without the guesswork on the process.

Speckit

Spec-Driven Development, or specifically the set of agents/skills under spec-kit introduce guardrails for agent thinking to ensure that we have data models, user stories, tasks, and end-to-end tests planned out. Leveraging an approach like spec-kit gets you off the ground establishing a solid plan, while your agents files can reference standards definition which can fill in the structural gaps around architecture, data modeling, integrations, and design. It also establishes an organized documentation approaches to make visible agent plans for reference by the engineer for review, or future review and reference by the agent since the specifications live in the repository. The biggest benefit I found for speckit (and other tooling in general) is that the planned output is explicitly written in markdown, available for review.

Alternatives

Beyond spec-kit, there are numerous other methodology-backed suites of agents/skills such as BMAD, OpenSpec and Superpowers. Pick your flavor.

Alignment and Implementation

Along with the methodology, during the planning and implementation phase, I have adopted a method of alignment that essentially first routes Claude, Codex, [Insert your Agent here], etc... to AGENTS.md, which enforces a usage of coding and application standards.

Once in context, it routes to a refined wiki/docs repository that surfaces an index, which can then, based on the agent's current context, drill in to the appropriate documentation path (where the documentation is surfaced piecemeal).

Below is an example of an alignment approach that I use that consistently produces aligned viable specifications from speckit on mono-repos or cross-repo agentic execution.

<!-- SVDO_STANDARDS_START -->
## svdo Repository Standards
Before making repository changes, read and follow `.svdo/standards.md` when it exists. That index references the active standard definitions under `.svdo/standards/`.
<!-- SVDO_STANDARDS_END -->

## Design Standards
Before applying any design, read and follow `DESIGN.md` when it exists.

<!-- OPENWIKI:START -->
## OpenWiki
This repository uses OpenWiki for recurring code documentation. Start with `openwiki/index.md`, then follow its links to architecture, workflows, domain concepts, operations, integrations, testing guidance, and source maps.

The scheduled OpenWiki GitHub Actions workflow refreshes the repository wiki. Do not hand-edit generated OpenWiki pages unless explicitly asked; prefer updating source code/docs and letting OpenWiki regenerate.
<!-- OPENWIKI:END -->

<!-- SPECKIT START -->
For additional context about technologies to be used, project structure,
shell commands, and other important information, read the current plan
<!-- SPECKIT END -->

Post-Implementation Agents and Processes

Security/Technical Review Agent

While static code analysis may not reveal any explicit security concerns, an LLM-based security agent can scan the git diff on a work-tree/branch and highlight implicit security issues based on documented authorization/business logic guidelines or context clues. These findings can then be pushed back into another agentic loop for correction immediately.

As an example, there may be nothing statically unsafe about this code.

@router.get("/accounts/{account_id}")
async def get_account(account_id: UUID):
    return await account_service.get(account_id)

An LLM would highlight that this endpoint may be user-controlled, and that it needs to include the correct authorization middleware for the correct access control be applied.

Bundled with the security agent, you can also reflect on technical alignment of the completed work through the repo-implemented standards as defined previously. This is up to the size of context you want to front-load into the agent – in general the goal is to escalate gaps found from the implementation and apply corrections before a merge.

Quality Assurance Agent

Like the Security Agent, this agent's work can be scoped to a particular work-tree/branch which allows for a more focused contextual analysis of the changes.

There are a few approaches to this type of agent – it just greatly depends at the level of validation you want to do before merging into an integration branch. In our case, I set up the agent to reflect against the code and original specifications to ensure feature coverage is 100%. With spec-kit (or your own methodology), standards, and documentation, agent alignment should have already been baked into the feature specification, but it is always good to check for logical gaps.

Additionally, adding on a layer of UI validation through a playwright MCP server connected with your agent CLI can validate against UI specifications to ensure features are visibly available in the product.

Knowledge Agent

Lastly, in my opinion, what brings it all together is a knowledge extraction agent. When applied to a modified branch like above (git diff dev..feat/some-feature), this agent builds out the bite-size knowledge segments and alignment documentation with references across the standards and spec-kit definitions.

Leveraging Open Knowledge Format (OKF) specification, the knowledge agent maintains an index.md which acts as a table of contents for the entire wiki, and adds or updates existing reference documentation around recently completed work. It acts as the connective tissue for future agent runs when properly embedded in the spec-kit agents.

For clarity, I have provided some example outputs below that would be stored in the repository.

# Knowledge Index

## System Architecture

- [Provider-native agent artifacts are managed repository derivatives](system/architecture/provider-native-agent-artifacts-are-managed-repository-derivatives.md)
- [Cloud ticket sync preserves remote identity across local rows](system/architecture/cloud-ticket-sync-preserves-remote-identity.md)

...

---
type: Decision Rationale
title: Ticket review workspace state lives on shared tickets
description: PR review branch and worktree state should follow the ticket across Kanban views instead of belonging to a board-specific workflow clone.
tags:
  - tickets
  - worktrees
...
timestamp: 2026-07-24T10:15:00-04:00
status: active
confidence: high
scope: feature
source:
  - specs/b3e3da63-add-isolated-pr-review-workspaces-for-ka/spec.md
  - specs/b3e3da63-add-isolated-pr-review-workspaces-for-ka/plan.md
...
  - packages/server/src/routes/tickets.ts
related:
  - ../product/principles/workspace-kanbans-are-configurable-workflow-views.md
  - ../system/architecture/package-local-repositories-own-product-persistence-boundaries.md
  - ../execution/risks/ticket-worktree-cwd-resolution-must-enforce-workspace-ownership.md
---

# Knowledge

The team decided: ticket PR review workspace state is shared ticket metadata, not Kanban-specific state. A ticket can record an attached branch before a worktree exists, and later record a stable ticket worktree path, readiness, cleanliness, and occupancy.

...

Conclusion

Agentic engineering changes more than how quickly software gets written. It assumes the engineer has the proficient ability to define the right work, with the right context, evaluate outcomes, and continuously improve the system the agents operate within, all in alignment with a business's architectural and development paradigms.

This is why just giving engineers coding agents is simply not enough.

If an individual engineer can direct several agents in parallel, then they are no longer acting as an implementer, they are managing engineering capacity. And giving someone five agents without defining how work is architected, secured, documented, and tested, is not much different than giving an engineer five engineers to manage without those same key process definitions.

The organizations that will benefit most from engineering will therefore be the ones that build the best systems around their agentic tools for their engineers, such as clear methodologies, durable standards, effective quality assurance, and institutional knowledge that compounds over time.

Additional Information

These ideas and approaches have been tested as viable with minimal rework for epic-level specifications with multiple user stories with OpenAI's GPT-5.5 and GPT-5.6 Sol, along with Claude Sonnet 4.6 through Copilot (before June the 1st 2026 token reckoning). Further studies on token usage optimization, rework and cycle time intended in the future.