Engineering for AI: How to Move Fast Without Losing Control

These days, everyone is talking about the AI era and the end of traditional software development and coding. Wherever you look—new articles, engineering reports from leading teams, technical discussions—you run into terms like Context Engineering, Harness, Skills, Agents, and many other emerging concepts.

But once you move beyond individual usage and look at real software development processes in medium-sized or large teams, things become much more complicated.

Any individual or team can sign up for one or more AI-powered services and quickly start using AI to build software. But as the number of people working on the same software ecosystem grows, differences in how people use AI, the variety of tools and agents they rely on, the sheer volume of code generated in a short period of time, and the inconsistent behavior of different models can gradually make software bloated, lower-quality, and less reliable.

The challenge is that many of our traditional software development processes were not designed for this level of speed and volume either.

Traditional code reviews, older testing practices, and many established SRE processes do not necessarily align well with the pace of change and the amount of code that AI agents can produce. Relying too heavily on these approaches can eliminate a large part of AI’s main benefit: dramatically increasing development speed.

On the other hand, simply abandoning these practices is not a realistic option either—especially for critical systems where high reliability is non-negotiable.

So the real question is:

How can we use modern tools and practices to preserve the speed enabled by AI without sacrificing software quality, consistency, and reliability?

Knowledge That Lives Only in People’s Heads Is No Longer Enough#

In the past, it was acceptable for many teams to keep part of their project knowledge in people’s heads.

Sometimes documentation was created as well, but much of it eventually became something that people rarely referred to during the day-to-day development process.

If a significant part of software production is going to be delegated to AI and coding agents, this model no longer works.

One of the most fundamental requirements in this new environment is achieving the highest possible level of consistency in quality, implementation style, and software engineering standards.

Without that consistency, increasing development speed is more likely to increase bugs, create unmaintainable code, and reduce confidence in the software than it is to increase meaningful output.

That means AI-driven workflows must always be able to access the right documentation at the code, architecture, and even product level.

The Goal Is Not More Context. It Is Better Context.#

At first glance, the solution may seem simple: give the agent access to everything.

But more context does not necessarily mean better context.

Giving a coding agent too much irrelevant information can reduce the quality of its output and, in some cases, disrupt its ability to perform the task effectively.

The goal is not for an agent to have access to all information.

The goal is for it to have access to all the information it needs—and only the information it needs—at the exact moment it is doing the work.

That information may include:

• the architecture and technical structure of the system
• coding standards
• previous team decisions
• product requirements and constraints
• testing standards
• expected types of tests
• validation procedures
• release-readiness requirements and checks

This is where concepts like Context Engineering start to become critical.

Humans Are Still Part of the Loop#

Despite the rapid progress of language models and coding agents, these processes should still not be designed as if humans were no longer involved.

Software engineers must remain responsible for validating the work that has been done, reviewing the overall quality of the output, and ensuring that every expected step has actually been completed correctly.

What is changing is the nature of the engineer’s role.

Over time, it is shifting away from being the direct producer of every implementation detail and toward designing the process, defining constraints, making decisions, reviewing results, and validating outcomes.

The more capable agents become, the more important it becomes to design the environment in which they operate correctly.

How Do We Give Agents the Right Context?#

Reaching the right balance in how information is shared with coding agents requires several different layers.

One layer is the use of technologies such as RAG and Knowledge Graphs, which can make it cheaper and more precise to provide agents with the information that is actually relevant to the task.

Another layer is building standardized technical documentation—not documentation that exists only for archival purposes, but documentation that can automatically become part of an agent’s context whenever a related task is being performed.

Alongside this, tasks themselves need to be defined accurately and connected to past decisions, future plans, and the right project context.

If the input to the work is vague, incomplete, or disconnected from the project’s existing knowledge, there is no reason to expect the agent’s output to be consistent or reliable.

How Can Pulse Help?#

As a project management platform, Pulse can help teams across all of these layers.

Using the Pulse documentation graph, teams can keep foundational project knowledge available throughout different stages of work—from project definition to task definition and finally execution.

Instead of allowing critical information to remain scattered across tools, files, and people’s memories, teams can preserve the relationships between product decisions, technical documentation, tasks, and execution.

With Pulse Agent, teams can structure information more precisely while defining work and eventually provide the right context to a coding agent, design agent, or any other agent participating in the workflow.

And with Pulse MCP, teams can design repeatable workflows with minimal operational overhead, allowing different agents to perform execution work in a more efficient, standardized, and predictable way.

The ultimate goal is to move from AI usage as a collection of scattered individual behaviors to an engineered, reliable system operating at the organizational level.

Speed Alone Is Not an Advantage#

The transition to AI-driven software development is one of the most exciting and important changes happening in the software industry today, and it has the potential to reshape the future of the entire field.

But moving too quickly and without enough long-term thinking can create serious risks for both software systems and the companies building them—even if the short-term gains look attractive and efficient.

Language models, and the coding agents built on top of them, are becoming more capable every day. But using them without clear standards can turn that same speed and capability against your organization, your team, or your software.

In the end, we should not forget that humans and human decisions still play a critical role in whether this transition succeeds or fails.

In the AI era, the importance of decision-making, process design, standardization, and quality control has not decreased. If anything, it has increased.

Teams need to continuously review and validate the quality of outputs and the final product, while repeatedly asking themselves:

How can we use AI to make this step faster, more accurate, and less expensive—without losing control or reliability?

In the Pulse blog, we will continue writing about product management, project management, and the structures and processes required to build software effectively in the age of AI.