Old Wisdom in Agentic Engineering

Software engineering is entering a strange new phase.

For decades, writing code has been seen as a key limiting factor for speed in delivery. But with coding agents, we now find ourselves in a situation where at least typing the code is no longer the main budget concern.

Let's imagine a world where we know exactly what we want, and we write that down in a specification and tell the agent to go build it. If done right, the agent will hit the mark pretty well. The promise is a huge productivity boost.

However, in this imaginary world, finding out what problem to solve is assumed away. This effectively slows us down, because even if we can write code fast and hit the specification, the specification itself might not be the right target. And so we end up having to go back to start. It is essentially a game of trying to match code with the needs of the users.

But writing code faster isn't enough to get faster delivery. We know this and we have known for a long time.

The two paradigms

In the last decades, the industry has developed a set of practices around software engineering to improve the speed of delivery. Roughly, there are two paradigms.

1. Improve the environment the developers work in to set them up for success. Developers are assumed to know what problems to solve, usually because that is a top-down process like a ticket system. Now all they need are the right tools and documentation available to make it happen and complete the ticket.

2. Improve the feedback cycle to ensure relevant feedback guides what code to write. Developers are assumed NOT to know what problems to solve, but to know what methods to use to find out what and how. Now what they need is autonomy to act on the feedback coming from relevant sources, usually end users of the system.

Developer Experience, DevOps, Continuous Delivery, platform engineering, automated testing, observability, and CI/CD pipelines all emerged from these two paradigms applied to software delivery.

The paradigms of course overlap and aren't mutually exclusive. What they both realise is that writing the code was never the bottleneck.

---

Speed Was Never About Writing Code Faster

The software industry has repeatedly rediscovered the same lesson under different names.

Agile emphasised short iterations and frequent feedback. DevOps emphasised ownership, automation, and faster recovery. Continuous Delivery emphasised the ability to release safely at any time. Developer Experience focused on removing friction from the daily work of engineers. Platform engineering turned common delivery capabilities into reusable internal products.

These movements were not primarily about increasing the raw amount of code written per day.

They were about reducing the time between action and learning.

A strong engineering environment allows a developer to quickly answer important questions. Does the code compile? Do the tests pass? Did we break an important workflow? Is the system behaving correctly in production? Can we safely roll back? Can we understand what went wrong?

Answers to these questions matter more than the speed at which the original code was written.

A senior engineer is not valuable because they type faster than everyone else. They are valuable because they can reduce uncertainty faster. They make better decisions, notice risks earlier, validate assumptions more effectively, and recover from mistakes more safely.

Fast feedback systems have always been very valuable. A reliable test suite, a good local development environment, a fast CI pipeline, clear logs, useful metrics, feature flags, reproducible builds, and automated deployments all serve the same purpose. They help engineers learn whether a change is correct or not.

The real productivity multiplier was never code generation. It was the learning velocity.

---

Agents Make Existing Bottlenecks Impossible to Ignore

Coding agents did not create the bottlenecks in modern software delivery.

They exposed them.

In the traditional development workflow, writing the code itself often consumed a large part of the total cycle time. The surrounding feedback system could be slow, inconsistent, or partially manual, but the human implementation step still acted as a natural rate limit.

flowchart LR
    A[Human writes code] --> B[Build and test]
    B --> C[Review]
    C --> D[Deploy]
    D --> E[Production feedback]

With coding agents, the implementation step can shrink dramatically.

An agent may be able to produce a plausible implementation in seconds or minutes. But the rest of the delivery system usually does not become faster at the same rate. Builds still take time. Tests still take time. Review still takes time. Deployments might still be slow due to inefficient separation between organisational units, etc.

flowchart LR
    A[Agent generates code quickly] --> B[Build and test]
    B --> C[Review]
    C --> D[Deploy]
    D --> E[Production feedback]

    F[Code output time decreases] -.-> A
    G[Feedback cycle time remains] -.-> B

Assuming the feedback cycles and barriers are held constant, what we see now is that those same feedback cycles and barriers look so much slower compared to code generation.

This changes the perceived economics of software delivery.

Although code probably did not take up as much time in the past as we think it did, organisations could tolerate many inefficiencies around it because it looked like writing the code was the main bottleneck. Slow CI pipelines were painful, but didn't add that much extra time. Manual QA was costly, but manageable. Missing tests were risky, but often absorbed by experienced engineers. Poor observability was frustrating, but not always immediately blocking.

With agents, the weakness of not being able to tell whether the output is safe to release becomes much more visible.

If barriers and feedback cycles are held constant, there is the uncomfortable paradox many teams will encounter in the near future. Code generation becomes faster, but delivery does not. Pull requests pile up. Reviewers become overloaded. Regression risk increases. Confidence drops. Engineers spend more time checking, debugging, and containing changes than they save during implementation.

The issue is not that agents write code.

The issue is that most development environments were designed for a world where code generation was much more scarce and slow code output could be managed by engineers without automation.

We are now moving into a world where this is no longer true. Automating pipelines, feedback, and testing is essential.

---

The Work Moves Toward the Feedback System

When code generation becomes faster, engineering attention must move elsewhere.

We must shift our attention from writing application code by hand to improving the systems that validate, constrain, and deliver application code safely.

That means investing more deeply in things like Continuous Delivery. It means making test suites faster, more reliable, and more representative of expected behaviour. It means improving static analysis, type systems, contract tests, architecture checks, security scanning, deployment automation, runtime assertions, observability, and rollback mechanisms.

It also means treating the development environment itself as a product. Agents need many of the same things human engineers need. They need fast setup, clear project structure, deterministic commands, reliable tests, useful error messages, observable behaviour, and well-defined boundaries. When these things are missing, the delivery process suffers.

This is why the old lessons matter even more now.

Continuous Delivery was always about making change safe. DevOps was always about shortening the distance between development and production learning. Developer Experience was always about reducing friction in the daily loop of understanding, changing, validating, and shipping software.

Agentic Engineering does not replace those ideas. It simply raises the cost of neglecting them.

---

Harness Engineering is not new

As you have probably noticed by now, I don't think the ideas behind Harness Engineering are new.

They are a new expression of old software engineering wisdom.

The technical details are different, though, because agents work differently from humans. They need different interfaces, different constraints, different evaluation mechanisms, and different ways of receiving feedback. But the underlying purpose is the same. The good news is that, since generating code is no longer the problem, we can use the productivity gains from that to focus our attention on ensuring that agents have the best possible setup for success.

We cannot scale if we do not shift our attention. If the rest of the pipeline stays constant, the productivity gains from adopting coding agents will not manifest in faster and better software delivery.

Engineers must increasingly focus on making software easier to validate. That may mean writing fewer feature implementations directly. It may mean spending more time on tests, tooling, pipelines, environments, observability, architecture boundaries, automated checks, and last but certainly not least, ensuring the quality of the codebase stays healthy.

This work may feel indirect, but it is what makes higher delivery speed sustainable.

---

Conclusion

The rise of coding agents does not invalidate decades of software engineering practices. It only reinforces them.

Agents make this more obvious because they reduce the cost of producing code and show that validation is now the constraint. The organisations that succeed will not simply be the ones that generate the most code. They will be the ones that can establish confidence in changes quickly, safely, and repeatedly.

One of the goals of computerlove.tech is to enable teams to succeed in Agentic Engineering, and I hope that all the engineers out there feel a sense of relief and realise that your craft is more needed than ever!