The mindset needed for the new role

The guidance in this section is an applied synthesis. It connects the manifesto with the evidence and with engineering principles.

3.1. Professional identity anchored in outcomes

The engineer needs to be able to recognize their contribution even when they did not type a single line of the result. Discovering the decisive requirement, designing an experiment, choosing a simple architecture, or creating a verification mechanism can demand more competence than producing the corresponding implementation.

This changes the source of professional pride. A good sign of growth is being able to say: “the system solves the problem, we know under which conditions it works, we monitor its effects, and we can change it safely.” The amount of visible effort is no longer a good measure of how important a contribution is.

This orientation also makes it possible to reject unnecessary work. If a request can be solved with a process change, a configuration, or the removal of a step, the ease of generating code does not oblige anyone to build a new application. Knowing how to cut scope is still a form of engineering.

3.2. Expanded responsibility

Responsibility includes the outcome and the mechanism that produced it. When a failure repeats, it is worth investigating whether requirements, documentation, access to evidence, tools, tests, or a better division of work are missing.

A simple example: the agent repeatedly calls a deprecated API. Correcting each response solves the immediate task. Making the correct version explicit, providing current documentation, and adding a relevant check can eliminate the whole class of error. The second intervention changes the capability of the working system.

Not every problem needs to become a platform. The point is to choose the smallest improvement that verifiably reduces recurrence: sometimes an example; sometimes a command; sometimes a test; sometimes an organizational decision.

3.3. Evidence-based trust

Useful trust is specific. One can trust an agent quite a lot to update documentation for a well-defined interface and demand stronger evidence when it changes authorization, concurrency, or a data migration.

The engineer should learn to ask: what claim am I accepting, what evidence does it rest on, and what could show it is wrong? The confident appearance of an explanation is no substitute for a test, a measurement, or an inspection of the real state.

A study presented at CHI 2025, with 319 workers and 936 self-reported examples, found associations between trust in AI and critical effort, along with a redistribution of that effort toward verification, integration, and responsibility for the task. The design is correlational and does not demonstrate loss of cognitive ability. It reinforces the value of making these evaluation habits explicit. F16

3.4. Ambition with scope discipline

AI expands the set of problems an engineer can explore. This favors initiative: testing hypotheses, building prototypes, investigating unfamiliar systems, and automating work that previously seemed too expensive.

This capability also changes the relationship with personal initiative. An opportunity that would once have waited for several people to become available can start as an investigation run by one engineer with agents. They gain room to cross boundaries between product, data, and implementation, making an idea concrete enough to be examined. Exercising this freedom with good judgment is part of the excellence proposed here.

The corresponding discipline is choosing experiments that answer important questions. A prototype should make it possible to learn something: whether the flow is understandable, whether the integration is feasible, whether the latency fits the budget, whether the user needs the feature. An impressive prototype that does not reduce uncertainty consumes attention and can create premature commitment to a solution.

It is useful to explicitly distinguish exploration, candidate implementation, and change ready to operate. The level of polish and evidence changes between these stages. The speed of generation makes this distinction even more necessary.

3.5. Thinking about the whole system

The excellent engineer follows the path from need to effect. If the code is ready early and waits days for an environment, integration, or a decision, there is a flow problem to solve.

This view requires talking with product, design, security, operations, and other teams. It also requires noticing capacity constraints: increasing work in progress can increase queues, conflicts, and integration cost. The competence includes choosing how many fronts to open and where human intervention really unblocks the process.

The DevEx framework proposes looking at developer experience together with data from engineering systems. Its application highlights feedback, cognitive load, and flow. These concepts help assess whether agents are freeing up attention or creating a new queue of interruptions. F12

3.6. Knowledge as a shared capability

A decision that exists only in someone's memory forces people and agents to rediscover it. Documenting reasons, constraints, and lines of investigation increases the capacity for independent work.

The knowledge-sharing chapter of Software Engineering at Google describes the costs of concentrated expertise and fragmented information, as well as the need to maintain documentation and train people. That foundation remains relevant: knowledge needs to be accessible, up to date, and interpretable. F36

Applied to the present, the guidance is concrete: a recurring discovery should find a stable home. That home might be the code, a test, an architectural decision, or a procedure. The criterion is its usefulness for the next piece of work, including when the author is not available.

3.7. Technical humility with decision-making ability

Working well with AI requires admitting gaps without outsourcing every decision. The engineer can investigate a new technology with the model's help and still distinguish what they have verified from what they are merely assuming.

It is particularly valuable to be able to say: “this was tested under these conditions; this property comes from the platform's contract; this point is still a hypothesis; this consequence needs a decision from the domain owner.” That precision makes it possible to move forward with less ambiguity.

The manifesto's analogy with leading a team is useful for delegation and coordination. In practice, the engineer also needs to design memory, access, continuity, and operational limits: these elements depend on the system that runs the agents. One cannot assume that an intent communicated once remains available in every run.