How we moved from experimenting with AI coding agents to fundamentally changing the way we engineer, collaborate, and deliver software at Madgicx.
Introduction: When Writing Code Became the Easy Part
Over the past two decades, I have witnessed several major transformations in software engineering.
We moved from monolithic applications to distributed architectures, from managing physical servers to cloud computing, and from manual deployments to automated CI/CD pipelines. We embraced Agile development, DevOps, infrastructure as code, and numerous other practices that fundamentally changed how engineering organizations operate.
Each transformation brought improvements in productivity, reliability, and scalability.
But the emergence of AI coding agents has introduced something quite different.
For the first time, we have tools that can actively participate in the engineering process itself.
They can investigate problems, understand existing codebases, propose architectures, develop implementation plans, write code, execute tests, and help validate solutions.
As someone who has spent much of his career building and leading engineering teams, I find this transformation particularly fascinating.
We are moving toward a world where writing code is no longer necessarily the most time-consuming part of software engineering.
And that raises an interesting question.
If writing code becomes significantly easier, what happens to the rest of the engineering process?
That was a question we started confronting at Madgicx earlier this year.
Like many engineering organizations, we began experimenting with AI coding agents to improve developer productivity.
Initially, the objective was straightforward: help our engineers build software faster.
And the early results were remarkable.
Tasks that previously required hours could sometimes be completed in minutes. Engineers could investigate unfamiliar systems more quickly, generate working implementations, and delegate repetitive development tasks to agents.
But as we started using these capabilities on real production systems, we encountered an unexpected challenge.
The faster we could generate code, the harder it became to ensure that everything we generated followed our engineering standards.
An agent could produce a perfectly reasonable implementation that violated an existing architectural decision.
It could introduce a new dependency when the functionality already existed elsewhere.
It could invent API contracts, make assumptions about business logic, or generate code that worked independently but did not fit our existing systems.
And perhaps most importantly, knowledge gained during one engineering session was frequently lost when the next session began.
We were improving the speed of implementation, but we had not established a reliable way to govern the engineering process around it.
That realization changed our direction.
Instead of asking how we could make AI agents write more code, we started asking a different question:
How do we make AI agents work as disciplined members of our engineering organization?
How do we ensure they understand our architecture, follow our standards, respect governance requirements, and validate their work?
And how do we achieve this without introducing so much process that we lose the productivity benefits of AI?
These questions became the foundation of what we now call our Agentic Engineering Playbook (AEP).
What followed was a seven-month journey of experimentation, failures, redesigns, and continuous improvement.
This article is about that journey—what we tried, what went wrong, what worked, and what I believe other engineering leaders can learn from our experience.
1. AI Coding Is Not the Same as Agentic Engineering
Before discussing our journey, I think it is important to establish a distinction.
There is a difference between using AI to write code and introducing AI agents into an engineering organization.
With AI-assisted coding, an engineer describes a requirement and asks an AI assistant to generate an implementation, suggest changes, or help debug an issue.
The engineer remains responsible for managing most of the surrounding development process.
Agentic engineering takes this further.
An agent can investigate requirements, examine existing systems, propose a solution, develop an implementation plan, write code, execute validations, and prepare changes for review.
In other words, the agent participates in the engineering lifecycle rather than simply assisting with individual coding tasks.
But this introduces a new challenge.
A capable software engineer joining an organization is expected to learn its architecture, coding conventions, security policies, business terminology, and development practices.
We do not expect an engineer to start making architectural changes without understanding the systems they are working on.
We also establish controls.
We have code reviews, testing requirements, security scans, CI/CD pipelines, architectural standards, and approval processes.
Why should we expect AI agents to operate without similar boundaries?
An AI agent may be exceptionally capable at generating code, but it does not automatically understand the engineering contracts of the organization using it.
And without those contracts, speed can become a liability.
That was the fundamental problem we wanted to solve.
We needed something that would provide agents with the appropriate knowledge, guide them through our engineering practices, and ensure their work passed the necessary validations.
Not another enormous collection of prompts.
Not another development methodology.
But a practical engineering framework that could operate alongside our existing processes.
That became our AEP.
2. The Early Days: Everyone Had Their Own Way of Working
Our journey began much like it does in many engineering teams.
Individuals started experimenting with AI coding agents.
Some developed elaborate prompts. Others preferred shorter instructions and iterative conversations.
Some asked agents to plan everything before writing code. Others allowed the agents to start implementing immediately.
Everyone was discovering what worked best for them.
Initially, this freedom was useful.
Engineers learned quickly, explored different approaches, and became increasingly comfortable delegating development work to agents.
However, as adoption grew, inconsistencies began to emerge.
Every project developed its own conventions
An agent working with one problem would produce code using one set of conventions.
Another agent working with a different engineer might approach the same problem in a completely different way.
The resulting code could be functional in both cases, but the implementations did not always align with our established architecture.
Agents invented things that did not exist
We encountered implementations that referenced nonexistent API fields, assumed incorrect response structures, or introduced values that were never part of the original requirements.
Sometimes these errors were obvious.
Other times, they appeared entirely reasonable until someone tested the implementation against the actual system.
Existing functionality was recreated
An agent might implement a utility that already existed elsewhere in the repository.
Without sufficient knowledge of the codebase, it solved the immediate problem instead of following established patterns.
This introduced unnecessary duplication and maintenance overhead.
Engineering decisions disappeared between sessions
An important decision might be made after a lengthy discussion with an agent.
But unless someone explicitly documented it, that decision remained buried in conversation history.
When a new session started, the agent could revisit the same problem and reach a different conclusion.
Documentation became difficult to manage
As we tried to preserve context, we accumulated Markdown files containing plans, notes, decisions, and temporary instructions.
Some documents were useful.
Others became outdated almost immediately.
Eventually, agents started consuming stale documentation as though it represented the current state of the project.
We were facing an interesting paradox.
We had tools that could generate software faster than ever before, but we were spending increasing amounts of time ensuring that the generated software was actually suitable for our systems.
For simple tasks, AI coding worked remarkably well.
For larger changes involving existing architecture, business rules, and multiple integrations, the effort required to guide and correct an agent could sometimes exceed the effort of implementing the change ourselves.
Clearly, something needed to change.
3. Our First Mistake: We Tried to Solve Everything with Process
Our first serious attempt at creating a structured approach began around March 2026.
We believed that the solution was to introduce more discipline into how agents worked.
So we created a comprehensive planning and development process.
We introduced an architect-oriented planning session that produced detailed implementation instructions for a separate coding session.
We added risk registers, structured planning documents, and a five-phase development workflow.
The intention was good.
We wanted agents to investigate problems thoroughly, consider architectural implications, and produce well-defined implementation plans before writing code.
In traditional engineering, these are sensible principles.
But we made a mistake.
We tried to apply a heavyweight engineering process to almost every task, regardless of its complexity.
A relatively small change could generate an extensive planning document.
Agents spent considerable time reading instructions and preparing documentation before producing useful work.
Our project folders accumulated more and more planning files.
And as those documents grew, so did the amount of context agents consumed.
We also discovered that documentation created during previous sessions could become misleading.
An agent might load an outdated specification and follow it rather than examining the current implementation.
In some cases, we had created more work for ourselves than we had eliminated.
The process that was supposed to improve engineering productivity had become a bottleneck.
This was one of the most important lessons of our journey.
Too little process creates inconsistency. Too much process destroys agility.
The solution was not to abandon engineering discipline.
It was to make the discipline proportional to the work being performed.
A minor UI change does not require the same level of planning as a payment integration or a major architectural modification.
That may sound obvious, but it is surprisingly easy to overlook when building workflows for autonomous agents.
We needed to simplify.
4. Finding the Balance: A Lightweight Engineering Pipeline
By May, we had started redesigning our approach.
Instead of a large, prescriptive development process, we introduced four core engineering responsibilities:
Research → Plan → Implement → Validate
Each responsibility had a clear purpose.
Research focused on understanding the problem, existing code, dependencies, and relevant constraints.
Planning focused on determining the implementation approach, identifying risks, and defining how the result would be validated.
Implementation focused on developing small, independently verifiable increments.
Validation focused on checking the implementation against requirements, tests, and engineering standards.
The important change was that we stopped trying to prescribe every detail of how the agent should work.
We defined the responsibilities, boundaries, and expected outcomes.
Within those boundaries, the agent could determine how best to perform the work.
We also reduced the amount of persistent documentation.
Instead of allowing every session to create new planning files, we maintained a small number of living documents covering project instructions, current work, and important findings that needed to survive between sessions.
This made session handoffs more effective.
An agent no longer needed to consume an entire conversation history to understand where work had stopped.
It could use a concise handoff containing the important decisions, completed work, and remaining tasks.
We also began developing smaller, focused engineering standards that could be loaded when relevant.
Rather than giving every agent every standard, we wanted to provide the information needed for the specific project and task.
This became a turning point.
The AEP started becoming less about controlling every action an agent took and more about establishing a reliable environment in which the agent could operate.
Humans remained responsible for requirements, architectural judgment, acceptance criteria, and approvals. Agents could take greater responsibility for execution within those boundaries.
This was much closer to the engineering model we wanted.
5. Teaching Agents What the Organization Already Knows
As the workflow became more consistent, another problem became apparent.
Every project was repeatedly teaching agents the same organizational knowledge.
Business terminology was explained again and again.
Architectural decisions were rediscovered.
External API contracts were interpreted independently.
Even when individual project instructions were reasonably complete, important knowledge remained fragmented across repositories and teams.
We started addressing this around June.
We introduced shared organizational knowledge covering areas such as business definitions, architectural decisions, service relationships, and verified external API contracts.
The principle was simple.
If something is already known and agreed upon by the organization, an agent should not have to rediscover it every time.
Consider a business term such as “customer activations“.
That definition may influence reporting, billing, customer segmentation, and product functionality.
If different agents independently interpret the term, they may produce technically correct implementations that are inconsistent with one another.
The same applies to architectural decisions.
If we have already established how services communicate or how particular integrations should be implemented, agents should work within those decisions unless there is a reason to challenge them.
We also learned that external API documentation could not always be treated as a sufficient source of truth.
Where necessary, we verified contracts against actual systems rather than allowing agents to invent structures based on assumptions.
This reduced repeated investigation and helped agents make more consistent decisions.
It also highlighted an important organizational responsibility.
Engineering knowledge must be maintained deliberately.
If knowledge is fragmented, outdated, or contradictory, giving agents access to more of it will not necessarily improve their performance.
Sometimes it simply allows them to make mistakes with greater confidence.
6. From Individual Mistakes to Organizational Learning
By July, our focus began shifting toward another question.
How do we ensure that a mistake made by one agent does not have to be repeated by every other agent?
In traditional engineering teams, knowledge spreads through code reviews, discussions, documentation, mentoring, and shared experience.
We needed an equivalent mechanism for agentic engineering.
We introduced a feedback loop that captures issues encountered during development sessions.
These might include failed validations, incorrect assumptions, invented contracts, or other recurring problems.
However, we quickly discovered another challenge.
If you ask an LLM to review every session and identify what went wrong, it will almost always find something to recommend.
Even when the session was successful.
If every recommendation automatically became a new engineering rule, our playbook would eventually become enormous, contradictory, and difficult to maintain.
We had already experienced the consequences of excessive process.
We did not want to recreate the same problem through automated learning.
So we established an important principle.
Feedback can be captured automatically, but changes to organizational standards require human judgment.
Our feedback loop has been operational since July.
We monitor what gets recorded and identify important or recurring issues.
When we discover something that should be addressed centrally, we update the AEP so the improvement benefits other users.
Sometimes that means clarifying a standard.
Sometimes it means adding a validation.
Sometimes it means fixing the tooling itself.
And sometimes the issue is specific to one project and should not become an organizational rule.
We are now developing the next stage: automating the curation of captured feedback into proposed improvements that can be verified by a human and incorporated into subsequent plugin releases.
The objective is to accelerate organizational learning without allowing agents to independently change the rules that govern them.
I believe this will become increasingly important as engineering organizations rely more heavily on autonomous agents.
7. The Hardest Part Was Not Writing the Standards
As our AEP matured, we discovered that creating engineering standards was relatively straightforward.
Making those standards work consistently across an organization was much harder.
This became particularly evident between August and October.
When standards activated in the wrong projects
We initially used repository and folder names to determine which technology-specific standards should apply.
This seemed reasonable.
But it created problems.
For example, a React-related standard could activate in a project with different framework requirements and provide incorrect guidance.
The agent would then confidently follow a standard that was not appropriate for the project.
We changed the approach to identify technologies through actual project dependencies and configuration files.
Files such as package.json and pyproject.toml provided more reliable evidence than directory names.
The lesson was simple.
An agent should not assume the technology stack when the project itself can tell us what it uses.
When guardrails silently stopped working
This was one of our most important operational discoveries.
Our initial installation process required users to complete some local Git hook configuration manually.
Many did not complete those steps.
As a result, parts of the validation system were not running, even though users believed the AEP was installed correctly.
We went through six pull requests before discovering that part of the local enforcement was inactive.
This was a serious lesson.
A missing control is a problem.
But a control that everyone believes is working, when it is not, can be even more dangerous.
We responded by packaging the AEP so that installation automatically registers the required local components.
We also introduced a health-check command that reports whether the installation is functioning correctly.
When maintainers had a different experience from users
The engineers maintaining the AEP often ran it directly from a local development checkout.
Ordinary users installed the packaged version.
These environments did not always behave identically.
As a result, problems affecting ordinary users could go unnoticed by the maintainers.
We introduced a separate installation profile for release testing, allowing maintainers to verify the packaged version under conditions closer to those experienced by users.
When the audience expanded beyond engineering
Initially, we designed the AEP for engineers.
But as product, marketing, and operations teams started using AI coding agents, we had to reconsider several assumptions.
A process that expects users to understand Git hooks, repository configuration, or complex installation procedures does not scale well beyond engineering.
We needed simpler installation, clearer error messages, and more reliable automation.
This pushed us toward a one-command plugin installation and straightforward health checks.
When rules began accumulating
Every incident created pressure to introduce another standard.
But adding more rules is not always the correct solution.
Sometimes an existing rule needs clarification.
Sometimes a recurring problem should be addressed through deterministic tooling.
And sometimes a proposed rule simply does not belong in the shared playbook.
We introduced stricter criteria for adding standards, including evidence of the problem, clear ownership, and conditions under which a rule should be reviewed or retired.
This helped prevent the playbook from growing into another heavyweight process.
Looking back, many of our most valuable improvements came from addressing these operational issues rather than introducing new AI capabilities.
The engineering system around the agent mattered as much as the agent itself.
8. Moving From Guidance to Enforcement
One of the most important principles we adopted was to distinguish between instructions that guide an agent and controls that enforce engineering requirements.
We can tell an agent not to commit secrets.
We can tell it not to modify protected directories.
We can tell it to follow our package standards or run the relevant code-quality checks.
But instructions alone are not sufficient.
An agent can misunderstand a rule, overlook it, or incorrectly decide that it does not apply.
Where requirements can be checked deterministically, we prefer to enforce them through tooling.
Our AEP provides local validations covering areas such as secret detection using Gitleaks, code quality, package validation, workspace standards, and governance requirements.
These checks operate during the local engineering workflow.
They help engineers and agents detect problems early, before changes reach centralized review.
But there is an important distinction.
The AEP is not our final security or quality boundary.
We also maintain centralized GitHub-level CI/CD, security scanning, linting, and other required checks.
The two layers serve complementary purposes.
The AEP helps prevent problems during development.
GitHub independently verifies the requirements that must be enforced centrally.
This separation allows us to benefit from fast local feedback without relying exclusively on controls running on an individual’s machine.
It also means that our engineering requirements are not dependent on whether a particular developer uses Claude Code, Codex, or another coding agent.
The underlying engineering standards remain applicable.
The tools used to implement them may differ.
I will explore this architecture, including our seven-layer AEP, in the second article of this series.
For this article, the important lesson is that reliable agentic engineering requires more than asking agents to follow instructions. It requires an environment that can verify their work.
9. The Real Transformation: Changing Who Can Build Software
As the AEP became more reliable, something interesting started happening across the organization.
The benefits were no longer limited to the engineering team.
Other departments began using AI agents to build applications, prototypes, and internal tools.
This was perhaps the most significant change in how we viewed agentic engineering.
Marketing began moving at campaign speed
Our marketing team now makes daily changes to websites and landing pages in response to campaigns and observed user behavior.
These include code, data, and website changes.
Previously, many of these activities required engineering involvement.
A marketing request would compete with product development priorities, and even relatively small changes could wait for engineering capacity.
Today, marketing can handle many of these changes independently.
The AEP provides local code-quality and validation tooling, while our centralized controls continue to enforce the relevant repository requirements.
When changes involve areas requiring code-owner approval, engineering remains involved.
The result is a more responsive marketing operation without creating a completely separate engineering process.
Product managers and business analysts began building working prototypes
Product managers and business analysts can now develop functional prototypes rather than relying entirely on specifications and mockups.
They can work with agreed data structures, test ideas, gather feedback, and demonstrate functionality before committing significant engineering resources.
Selected functionality can be released behind feature flags for controlled evaluation.
Engineering teams can then help integrate validated functionality into the main product.
To support this, we also addressed the challenge of accessing data and internal resources safely.
We built a separate platform that provides controlled access to the resources required for development.
For prototyping, we agree on the relevant data schemas and provide data marts that teams can use.
That platform deserves an article of its own, so I will not go into its architecture here.
The important point is that making software development accessible to more people requires both capable agents and appropriate access controls.
Operations began building internal tools
Our operations teams also started building tools to address their own requirements.
Instead of waiting for an engineering team to prioritize every internal request, they could solve some of their problems directly.
This does not mean that everyone suddenly becomes a software engineer.
Nor does it mean that engineering governance is no longer necessary.
It means that the ability to implement software is becoming more widely accessible.
And that changes the role of the engineering organization.
Engineering becomes responsible not only for building software but also for establishing the platforms, standards, and controls that allow others to build safely.
Engineers began spending more time engineering
This has been an important change within our engineering team.
Engineers increasingly focus on understanding problems, designing solutions, making architectural decisions, defining acceptance criteria, and validating implementations.
Agents perform much of the implementation work within the boundaries established by engineers.
We have also seen smaller delivery teams take on larger pieces of work.
In some cases, an engineer working with a product manager can take a substantial development item through planning, documentation, implementation, testing, and staging.
The value is not simply that fewer people can produce more code.
It is that engineers can spend more of their time applying engineering judgment.
The role of the engineer is shifting from being primarily a producer of code toward becoming the architect, director, and validator of software development.
I believe this will be one of the defining changes in software engineering over the coming years.
10. What We Have Achieved So Far
Whenever we discuss AI-driven engineering transformation, I believe it is important to distinguish between measurable outcomes and observations.
AI coding tools can create an immediate impression of productivity.
But generating code quickly is not necessarily the same as delivering software efficiently.
We have therefore been looking at changes in our development process, delivery cadence, and resource consumption.
Approximately 50% reduction in token usage
One of our clearest measured improvements came from reducing the amount of context consumed during development.
Our initial heavyweight process required agents to read extensive planning instructions and documentation.
This increased token consumption and often introduced unnecessary context.
We subsequently introduced smaller, more focused standards, specialized skills, and structured session handoffs.
Using Claude token-usage measurements before and after these changes, we observed an approximately 50% reduction in token usage.
This was an important result.
It demonstrated that adding engineering discipline does not necessarily mean increasing the cost of using AI.
In fact, a well-designed process can reduce unnecessary work.
The lesson was not simply to minimize tokens.
It was to provide the right context at the right time.
More context does not always produce better engineering. Relevant context does.
From two-sprint release cycles to four development releases per week
Our development delivery model has also changed significantly.
Previously, a set of development releases typically moved through approximately two sprints.
Today, our product team delivers around four development releases per week, excluding bug fixes.
This transformation has accompanied a broader shift in how we organize development.
We have moved away from a Scrum-based approach toward Kanban-style development, allowing work to flow continuously through smaller deliverable increments.
I would not attribute this improvement entirely to the AEP.
AI coding agents, changes in engineering practices, delivery processes, and organizational alignment have all contributed.
However, the AEP has played an important role in making agent-assisted development more consistent and predictable.
When teams can investigate, implement, and validate smaller changes reliably, continuous delivery becomes easier to sustain.
Improvements in code quality
We have also observed improvements in the quality and maintainability of agent-generated code.
Earlier implementations frequently contained excessive comments, duplicated functionality, unnecessary abstractions, and oversized files.
We introduced more focused coding standards and pre-commit audits to address these issues.
For example, we established a simple principle for code comments.
A comment should explain something useful that is not already evident from the code.
If removing the comment does not remove meaningful information, the comment may not be necessary.
Our validation process also examines changes for dead code, duplication, oversized functions, invented values, and incomplete implementations.
These changes have helped produce smaller, more readable implementations.
Unlike our token-usage improvement, we have not yet established a formal comparative measurement for all these code-quality outcomes.
They are observations from our engineering workflow.
We intend to improve our measurements as the system matures.
A broader definition of productivity
Perhaps the most meaningful outcome is difficult to express as a single number.
Marketing can respond to campaigns more quickly.
Product teams can validate ideas through working prototypes.
Operations can address some of their own tooling requirements.
Engineers can concentrate more heavily on architecture, design, and validation.
These are organizational outcomes rather than simply coding metrics.
And they are why I believe the transformation is much larger than developer productivity.
11. What I Would Do Differently If I Started Again
Looking back over these seven months, there are several things I would approach differently.
Start with the smallest useful framework
Our first mistake was trying to build a comprehensive engineering process before we fully understood how agents behaved in everyday development.
If I were starting again, I would begin with a simple research, plan, implement, and validate workflow.
I would add one universal engineering standard and a small number of stack-specific standards.
Then I would test the approach against real development work.
Only after identifying recurring problems would I introduce additional controls.
Build enforcement before expanding adoption
We initially concentrated on standards and instructions.
In hindsight, local validation and centralized enforcement should have been priorities from the beginning.
A standard that tells an agent not to commit secrets is useful.
A secret scanner that detects those secrets is essential.
And centralized verification provides an independent control when local checks are missing or misconfigured.
Treat installation as part of the product
We underestimated the difficulty of distributing the AEP consistently.
Manual installation steps were skipped.
Hooks were missing.
Different users ran different versions.
Maintainers tested environments that did not match ordinary installations.
If I were starting again, I would design the installation process and health check much earlier.
A playbook that works perfectly on the maintainer’s machine is not enough.
Preserve knowledge without creating documentation overload
We learned that agents need persistent project knowledge.
But we also learned that generating documentation for every decision creates a different problem.
I would keep the number of persistent project documents small and clearly define what belongs in each.
Important decisions should survive between sessions.
Temporary reasoning should not automatically become permanent documentation.
Make governance part of the workflow
Engineering standards should not exist independently of organizational governance.
Business definitions, security requirements, and architectural decisions must have authoritative sources.
Our canonical governance integration is now operational, with the AEP team using tooling to retrieve and incorporate approved standards.
We are currently improving the automation around detecting changes and notifying the AEP team.
If I were starting again, I would establish this relationship between governance and engineering standards earlier.
Build a learning system, not a rule-generation system
Capturing agent mistakes is valuable.
Automatically converting every observation into a new standard is not.
I would establish a feedback mechanism early, but retain human review for changes that affect shared engineering practices.
A good playbook should become more effective over time.
It should not simply become larger.
Measure the engineering outcome, not the amount of code
I would also establish baseline measurements earlier.
Token usage, delivery lead time, deployment frequency, defects, review effort, and change failure rates provide more meaningful information than the number of lines an agent generates.
An agent that writes twice as much code is not necessarily twice as productive.
An agent that helps deliver a reliable solution with less effort and less complexity is far more valuable.
Final Thoughts: The Real Transformation Is Not About Coding
When we began experimenting with AI coding agents, our objective was to make engineers more productive.
We wanted to reduce repetitive work, accelerate implementation, and allow engineers to concentrate on more complex problems.
Seven months later, my perspective has changed.
I no longer see AI coding agents simply as productivity tools.
I see them as participants in a changing engineering operating model.
An operating model in which agents can investigate, plan, implement, and validate software.
Where engineers increasingly concentrate on architecture, judgment, and accountability.
Where business teams can build and experiment without waiting for every change to be implemented by an engineering department.
And where governance, standards, and validation become even more important because the speed of software creation has increased dramatically.
There is a temptation to believe that as AI models become more capable, the need for engineering discipline will diminish.
My experience suggests the opposite.
The more capable the agents become, the more important it is to establish the boundaries within which they operate.
A highly capable agent working without appropriate standards can create problems very quickly.
A highly capable agent working within a well-designed engineering environment can create enormous value.
That is the distinction we have been working toward.
Our journey has reinforced three principles that I believe will remain relevant as AI continues to evolve.
First, speed without engineering discipline does not scale.
Generating software quickly is useful only when the resulting software is reliable, maintainable, secure, and aligned with the organization’s requirements.
Second, engineering discipline must be proportional to the work.
Too little structure creates inconsistency. Too much structure destroys the productivity gains that made agentic development attractive in the first place.
Third, the engineering system must continuously learn.
Standards, knowledge, governance, and tooling must evolve through real engineering experience. But that evolution must remain deliberate and accountable.
Perhaps the most important realization for me has been that AI agents do not eliminate the need for experienced engineers.
They change where engineering expertise is applied.
Someone still needs to understand the business problem.
Someone needs to make architectural decisions.
Someone needs to establish security and governance boundaries.
Someone needs to define what good looks like.
And someone needs to remain accountable for what reaches production.
The AEP is our attempt to make those responsibilities explicit while allowing AI agents to take on more of the implementation work.
AI agents changed how we write software. The Agentic Engineering Playbook is changing how we engineer, govern, and deliver it.
And I believe we are only at the beginning of that transformation.
Coming Next: Inside Our Agentic Engineering Playbook
In the second article of this series, I will explore the technical architecture behind our AEP.
I will explain the seven layers that make up the framework, how we structure agent roles and engineering standards, how GrillMe-with-Docs challenges plans against organizational requirements, and how local validation works alongside centralized GitHub controls.
I will also discuss our approach to canonical governance, continuous learning, plugin distribution, and the practical considerations involved in implementing a similar framework within another engineering organization.
The first article has been about why we changed our engineering approach and what we learned along the way.
The next will be about how we built the system that makes it possible.
If you are leading a similar transformation, experimenting with AI coding agents, or developing an agentic engineering framework within your organization, I would be interested in hearing about your experiences. Particularly the things that did not work as expected—because those are often where the most valuable lessons emerge.