As time progresses, one thing is clear, a single line of code is not that meaningful anymore.
Before, I would spend time thinking about how each line of code would represent best the domain problem, abstracting pieces that I recognized where meant to be abstracted together and applying patterns and conventions by hand.
“”Now that focus has shifted entirely.
A single line of code, in the context of a project where agentic programming is present, is meaningless.
That doesn't mean that we shouldn't care about how we write code, what we should care about is how we tell our agents to code.
#From Designing Code to Designing Agents to Code
I've found across projects that what is going to bring value to Software products is how smart we can be when implementing autonomous agentic loops that understand the architecture, follow team conventions and can validate the project in a trust-worthy way.
We are not going to code directly, we are going to design loops that code up to the standards of the project.
That's why understanding the architecture and best practices, again, is what is going to separate you from any other developer, or AI model.
This is what makes an architect future-proof.
As Addy Osmani has put, intent debt is something that agents can't help you withOpen in a new tab, they are the ones that are causing this intent debt. Software Architecture is all about setting intention about how a system should work. Bringing intention to what we do is key.
And how do we bring intention in Agentic Software Development? For me, the best way is through skills, an human-validated architecture, AI-assisted documentation (not AI-generated) and ADRs.
Now, we need a way to validate what we generate, is what we intend to generate.
#Harness engineering
With agentic development, we do not only need to tell our agents how to code but have a way to validate that the system is working as intended.
Testing has become mandatory (finally!). If you are not writing tests, agents are not going to be as effective as they could be.
I think at some point, when developing features, we are going to be focusing solely on writing specifications. This is also known as Spec Driven Development.
We can also introduce certain validations that can run in a deterministic and automatic way, via CI/CD or Git Hooks:
- Linting
- Formatting
- Unit tests
- Integration tests
- E2E tests
- Type check
- Architecture tests
It's this last point that I'm currently focusing on. Skills are a great way to define what should be the architecture, but having a way to validate the architecture is the most interesting to me.
All of these techniques, which to me are common, now are part of a subset of engineering called Harness Engineering. You create a harness that validates the project automatically and in a deterministic way so that agents have a better understanding if what they are doing is what they should.
#Autonomous loops
Once we have the skills, the harness, and potentially spec documents laying out the features, we can then think about creating autonomous agent loops.
Designing loops means that we need to think about complex abstractions, creating systems that are autonomous can be daunting, and rightly so, we can gain a lot or loose lot. It depends on how we design these type of loops, which is something that we'll be exploring in the next issue of this newsletter.
This is where the future is for Software Development. Come join me.
#Conclusion
Architecture brings intention about the delivery of a Software product. Agents can diffuse the intent of a product, since they are going to make plausible assumptions based on what is already present. We can reduce that drift by being explicit about the system, via skills, conventions and a harness in place.
P.S: Thank you, Victor GuillánOpen in a new tab for the inspiration for the concept of "A line of code is not going to exist anymore" in one of our recent conversations.
P.S 2: Writing this newsletter from el Albir, Alicante, Spain.