The Three Pillars of Future Engineer Value

Before we build, we need to listen

Imagine that a customer asks us to add a download button.

An AI agent can help us build it. We describe the screen, ask for the code and check that the button works. The customer can now download a report.

But why did they ask for it?

Perhaps they need to tell their team which tasks are late before a Monday meeting. The report arrives too late. It includes old information. Someone has to read several pages to find the few tasks that need attention.

The button may be useful. It may also leave the real problem untouched.

This is what I keep coming back to when I think about the future of engineering. If we can build faster, we need to become better at understanding what is worth building.

I do not want to reduce engineering to supervising generated code. I want us to use the time we gain to listen more carefully, consider better options and check whether our work helps people.

For me, that requires three kinds of knowledge:

1. Engineering knowledge: understand how the system works.
2. AI knowledge: understand the tools we are asking to do the work.
3. Institutional knowledge: understand the people, purpose and rules behind the work.

These are not separate career paths. We need them together. They do not guarantee anyone a job, but they give us a useful direction for learning.

1. Engineering knowledge: know what you are building

AI can help write code and tests. I still need to understand whether the result is right.

That means learning languages, frameworks and infrastructure. It also means understanding the ideas beneath them: how data is stored, how systems communicate, how access is controlled and what happens when something fails.

Take our weekly report. Before calling it finished, I need to ask:

• Does it show the latest information?
• Can the person opening it see only the information they are allowed to see?
• What happens if the data changes while the report is being prepared?
• If the work stops halfway, can we continue safely?
• Can we find out why a report was wrong?

A working button answers none of these questions. Tests help, but only if we test the things that matter.

Understand state and change

Suppose the report moves through these stages:

Requested → Being prepared → Ready for review → Approved → Sent

This is a simple state machine. It describes the stages and the changes we allow between them. “Ready for review” must not mean “safe to send.”

An event records something that happened, such as a reviewer approving the report. Event sourcing is one way to store changes as a history from which we can rebuild the current state. Not every application needs it, but we should know when that history is useful.

We also need data modeling: deciding what information to store and what each field means. If we change that structure later, old records must remain understandable. That is the problem of schema evolution.

And we need to know where the information came from. A report based on yesterday's records is different from one based on today's records. Recording the source and time helps us check it. This is provenance.

These are not just technical terms to remember. They help us answer ordinary questions: what happened, what is true now, and what may happen next?

Know whether the system is working well

A report may be quick to generate and still take days to reach the customer.

I need ways to see errors, delays and repeated work. Observability means having enough information about the system to understand its behavior. Logs, measurements and traces can help.

I also need to measure the whole job. How long did the customer wait? How many reports needed correction? How much time did people spend checking them?

Cost includes more than the model call. Review time, failed attempts and recovery all count.

I do not need to use every technique on every project. But I need enough understanding to choose well and notice when an AI-generated solution leaves something important out.

2. AI knowledge: know what you are asking the tools to do

Writing a good prompt is useful. It is not the whole skill.

An AI agent works inside other software. That software manages its instructions, information, tools and progress. This surrounding system is often called an agent harness.

I need to understand both the model and the harness. What can they read? What can they change? What do they remember? What happens when a tool fails?

The Model Context Protocol, or MCP, is a standard way to connect AI applications to tools and information. A connection does not, by itself, make an action safe or permitted.

For our report, I might let an agent read approved task records and prepare a summary. I would not give it permission to send that summary to anyone it chooses.

Coordinate execution, not just conversations

Suppose two agents pick up the same report request. Both prepare it. Both try to send it.

This is not mainly a prompting problem. It is a coordination problem.

We need to decide who owns the task and prevent conflicting actions. That is part of concurrency control: managing work that happens at the same time.

If sending fails, we need a clear retry rule. Did it fail before the message was sent, or did the message go out before the connection was lost? Sending it again could create a duplicate.

Idempotency means that repeating an operation does not create an additional effect. Where that is not guaranteed, we need another way to check the outcome before retrying.

Checkpointing saves progress so we can continue after an interruption. Scheduling decides when work runs. Dependencies tell us what must finish before the next step starts.

We also need to think about queues. If agents prepare fifty reports while a person can review only ten, faster generation has not solved delivery. It has created more waiting. Limiting incoming work when the next stage is full is called backpressure.

These concepts help us build a workflow that continues reliably, not just an impressive single run.

Give an agent a clear job and clear limits

For the report, the job could be:

Find the tasks that are late. Summarize the available evidence. Flag missing information. Prepare a draft for review. Do not send it.

That instruction has a goal, inputs and a stopping point. The tool permissions must enforce the limits too. This is bounded autonomy: the agent can proceed on its own within a defined scope.

The agent may need to break the work into steps, gather information and compare possible answers. Those are planning and reasoning tasks. It also needs the right context: the information relevant to this job. More information is not always better. Old or unrelated information can mislead it.

Memory, planning, tool use and human review are parts of an agent's design. Adding more agents does not automatically improve it. They can all make the same mistake.

Asking a model to check its answer can help. It is not independent proof that the answer is correct. I still need checks against records, rules or a competent reviewer.

Choose the right kind of help

Some work is better handled by ordinary code. Counting late tasks from agreed dates and rules should not require a model to guess.

Deterministic code gives the same result for the same specified inputs under the same conditions. Model output can vary; this is often described as stochastic behavior. Even an output that repeats consistently can still be wrong.

For our report, I would start with this division:

Work	Who or what should do it?
Count tasks using agreed rules	Code
Check who may read the report	Access-control code
Draft a readable summary	AI, using the task records
Resolve unclear or conflicting information	A person who knows the work
Approve a sensitive report	The person with that responsibility
Send the approved version	A controlled system with a recorded outcome

I think of the pilot in an automated aircraft. Automation can do a great deal, but the pilot must understand it and be ready to intervene.

The comparison is about responsibility, not equal reliability. If I cannot explain what an agent changed or how we would recover from a mistake, I need to supervise that work more closely.

3. Institutional knowledge: know the people and purpose behind the work

Institutional knowledge is what an organization knows about its own work. It includes its customers, product, market, rules and history. It includes why people make certain decisions, not only what the written process says.

Some of this knowledge is in documents. Some is in people's experience. Knowledge that people use but have not fully written down is called tacit knowledge.

In our example, one team member may know why the report is needed before Monday. Another may know that “late” means different things for different tasks. Someone else may know that a delay is already resolved but has not yet been recorded.

I cannot expect a model to know these things unless we give it reliable information. A fluent explanation is not evidence that it understands our organization.

This is why talking to people remains part of engineering. We need to listen to customers, the people doing the work and the people responsible for its consequences. We also need to make what we learn available to others, rather than leave it with one experienced person.

The bridge to workflow design

A workflow is how work moves from a request to a result. Designing it means deciding what information is needed, who does each part, what must be checked and what happens when the normal path does not work.

Institutional knowledge helps us understand those decisions. Workflow design turns that understanding into something people and software can follow.

Our first sketch might be:

Understand what the customer needs
    → gather the right information
    → prepare a draft
    → check unclear points
    → approve it when required
    → share the result
    → ask whether it helped

We should not automate this sketch immediately. First, we need to understand how the work actually happens.

Look at the whole work system

Systems thinking and system boundaries

Systems thinking means looking at how the parts affect one another. The report generator is one part. The people updating task records, the reviewer and the customer are other parts.

If the records are old, a faster generator produces an old report faster. If the reviewer is overloaded, a faster draft waits longer.

We need to decide what our system includes. This is its system boundary. We may control how we prepare the report. We may depend on another team to provide information. We must make that dependency clear and agree on what to do when information is missing.

The question is not only “does my code work?” It is “does the whole process help the customer?”

Domain-driven design: agree on what words mean

Domain-driven design starts with understanding the work and building software around that understanding. A domain is simply the area of work the software serves.

Consider the word “done.” The author may mean “I finished the draft.” The reviewer may mean “I checked it.” The customer may mean “I received what I needed.”

Those are different facts. One done field cannot describe them clearly.

We need agreed words and separate states. A bounded context is an area where a set of terms and rules has a consistent meaning. When information moves between such areas, we must translate the meanings carefully.

This is not about making the vocabulary complicated. It is about preventing software, people and agents from misunderstanding one another.

Socio-technical systems: design the human work too

A socio-technical system includes people and technology together. Introducing AI changes both.

If an agent prepares reports, what does the reviewer now need to do? What evidence can they see? Do they have time to check it? Can they say no?

We need to observe the real process, not only read the documented one. A private checklist or an informal conversation may be doing important work that the software does not capture.

We should preserve useful practices and question unsafe ones. We should also keep people able to do the work needed when automation fails. Training and recovery practice still matter.

I do not want a system that makes people approve answers they no longer understand.

Design human–AI collaboration around consequences

AI can help prepare an answer. Institutional knowledge helps us decide whether that answer is good enough and who may act on it.

Decision, evaluation and uncertainty

Suppose the report marks a task as late. What happens if that is wrong? A team may waste time investigating it. If a genuinely late task is missed, a customer may not get help in time.

These are two different errors. We need to understand their costs. Decision theory and risk analysis help us compare choices under uncertainty.

We also need evaluation: checking the system against examples that represent the real work. A single accuracy score may hide the error we care about most.

A model's confidence does not decide whether an action is acceptable. We must define when it can proceed, when it must ask for help and when review is always required.

This is where human–AI collaboration matters. People can add missing context, question an assumption and make a judgment that the current rules do not cover.

But people can also be wrong. They can trust a polished answer too quickly. Review must give them the original evidence, unclear points, enough time and real authority to reject the answer.

A human approval button alone does not make a system safe.

Authority, constraints and safety

There is a difference between being able to do something and being allowed to do it.

Capability is not authority. An agent may be able to send a report. That does not mean it may choose its recipients or share private information.

Authorization checks what an actor is allowed to do. Least privilege means giving it only the access needed for that job. Separation of duties can keep preparation and approval with different people or components.

Some rules must always hold. These are invariants. For example, a person must not receive task records they are not allowed to read. We must enforce that in software, not just describe it in a prompt.

For sensitive work, a person may need to review the exact version before it is sent. For lower-risk work, the system may proceed within agreed limits while people monitor it. These are often called human-in-the-loop and human-on-the-loop designs.

The choice depends on the possible harm, whether we can undo the action and the organization's rules. AI can help explain options. People responsible for the work must approve the limits, and the system must enforce them.

Improve the outcome, not just one step

Value stream thinking: follow the request to a useful result

Value stream thinking follows the whole path from a request to the result the customer needs.

Suppose preparing the report takes fifteen minutes, but review takes two days. Reducing preparation to one minute does not remove the two-day wait. These are example numbers, not measured results.

Measure the time spent working and the time spent waiting. Also measure corrections and missing information.

The customer does not benefit from a fast draft they cannot use. They benefit from accurate information arriving when they need it.

Theory of constraints: find what is holding the work back

The Theory of Constraints asks which part currently limits the result we want.

Perhaps one reviewer has too much work. Perhaps drafts arrive without the information needed to check them. Perhaps a rule requires approval for reports that do not need it.

A long queue tells us where to investigate. It does not, on its own, tell us the cause.

We should improve how the limiting step works, adjust the surrounding work and add capacity if needed. Then measure again. The limiting step may change.

Sometimes the useful engineering decision is to send less work into a full queue, not to make more agents produce more drafts.

Learn from what happens

Organizational learning and feedback

Organizational learning means turning experience into changes the organization can keep using.

Suppose several reports use old information. We could tell the authors to be more careful. Or we could ask why the workflow allows old records to reach them without a warning.

The first response improves an action within the current rules. This is single-loop learning. The second questions the rules themselves. This is double-loop learning.

A useful lesson should lead to something concrete: a clearer rule, a changed screen, a checklist or a test. Give it an owner. Check later whether it helped.

AI can help find patterns and draft those changes. A pattern is a reason to investigate, not proof of what caused the problem.

People must feel able to report mistakes. If we hide bad results to make the automation look successful, we lose the chance to improve it.

Bring the three pillars together

Engineering knowledge helps us build a reliable system. AI knowledge helps us use the tools well. Institutional knowledge helps us understand what the system should do and why.

Workflow design brings them together.

It is not enough to build the wrong thing well. It is not enough to automate a process we do not understand. It is also not enough to understand the problem if we cannot deliver a dependable solution.

No one needs to know everything alone. We need to work with others, ask good questions and share what we learn.

How this changes the software development lifecycle

The software development lifecycle, or SDLC, is the work of understanding a need, designing a solution, building it, testing it, operating it and improving it.

This has never needed to be a one-way sequence. We learn, return to earlier decisions and revise them. AI can change how quickly we move through parts of that cycle.

I see two important changes.

1. Faster implementation increases the importance of discovery and learning

For some tasks, coding may no longer take the most time. Difficult code, testing and integration can still take substantial effort. But when implementation becomes faster, we should use that advantage to understand the problem better.

In our example, there are several possible solutions:

• Add the download button.
• Show the few tasks that need attention directly on the screen.
• Improve how people keep the task records up to date.
• Send a short, reviewed summary before the Monday meeting.

We should not choose only by asking which one AI can build fastest.

We need to talk to customers and stakeholders: the people who use, maintain, approve or are affected by the solution. We need to understand their needs and the limits they work within.

Then we can design a small experiment. A hypothesis is an idea we can test. Ours might be: “Showing late tasks clearly on the screen will help the customer prepare for the meeting in less time.”

Agree on what we will measure before we start. Does preparation take less time? Do people still find important problems? What does the customer say after using it?

Analytics helps us examine what happened: usage, delays, errors and other recorded results. It belongs in the design conversation, not only in a dashboard after release.

Check the explanation too. Perhaps results improved because the team had fewer tasks that week. Perhaps the new screen helped one group but confused another. We should compare carefully and be willing to change our design.

The cycle becomes:

Listen and understand
    → consider several solutions
    → decide what to test
    → build a small version
    → study the results
    → improve the solution or rethink the problem

The engineer's contribution is not only the code in the middle. It is helping the team make better decisions throughout.

2. Look for AI opportunities throughout the lifecycle

We can also ask where AI could help the work itself.

It might help organize interview notes, compare designs, build a prototype, draft tests or investigate an error. It might prepare the weekly summary while we review the unclear points.

Start with the work, not the tool. What repeats? What takes time? Which parts have clear rules? Which parts need interpretation? What would happen if the answer were wrong?

Use ordinary code where rules are clear. Use AI where it can provide useful assistance. Keep human judgment where context, uncertainty or consequences require it.

Then check the whole result. Did people spend less time? Did quality improve? Did we create more review work? Could the team recover when something failed?

The aim is not to put AI everywhere. It is to find good opportunities to accelerate work and automate suitable parts.

These two changes belong together. Faster building lets us explore more possibilities. Better understanding helps us choose which possibilities are useful.

Where I would start

Choose one small piece of work you can observe. Talk to the person who needs the result and the people who produce it.

Write down what happens, where people wait, what goes wrong and who makes the important decisions. Then choose one change to test.

You might use AI. You might change a rule, remove a confusing step or ask for better information earlier. What matters is whether the work becomes better for the people it serves.

I still care deeply about learning to build software well. I do not see AI as a reason to care less.

I see it as a reason to widen our responsibility: understand the engineering, understand the tools, and understand the people whose work we are changing.

Building faster is useful. Understanding what helps is what gives that speed meaning.

Related reading

• From Chat Sessions to Proactive Agents
• Decision Models: History, Evolution and Practical Uses
• Introduction to Software Development Lifecycle
• Explore workflow design courses

Sources and further reading

• Martin Fowler: Bounded Context