Design Pattern Evangelist Blog

Smart pointers about software design

Maintained by Jim Humelsine | Table of Contents | RSS Feed | Edit on GitHub

WORK IN PROGRESS – Agentic Coding

Thoughts on AI agents, software engineering, and the changing role of developers

Introduction

In my previous blog, The End of Coding as Toil, I discussed how Generative AI is changing software development and the role of software engineers. I want to continue that theme, but this time focus specifically on Agentic Coding.

I do not believe software engineering is disappearing. I think the role of software engineering is changing.

The toil of hand written code is decreasing through AI. However, the architecture, decomposition, boundaries, communication and judgment by humans is increasing. Humans and agents will increasingly work together to architect, design and implement software systems faster and better than either could do alone.

AI Is a Tool

Generative AI is a tool. It is a force multiplier.

The concern is not whether AI can generate code. It clearly can.

Generative AI will make good software engineers better and bad software engineers worse. A power saw in the hands of skilled crafters allows them to build cabinets quicker. A power saw in the hands of knuckleheads allows them to saw their thumbs off quicker.

Developers tend to fall along a spectrum of:

Both are important. AI will accelerate makers, but this should not come at the expense of the clarity and structure of the code desired by menders.

Prompts vs Agents

AI has two primary types of interaction models: Prompts and Agents

Prompts

Prompting is how most people first experience AI such as with ChatGPT. They interact with it as if in a conversation. Ask AI a question or give it a task, and it responds. It will wait indefinitely until you continue.

An AI session tends to be a blank slate until prompts are provided. Prompts provide context, which will be retained with the session, baring Context Window (TBD) limitations.

My previous LLM/GenAI blog entries featured this type of interaction, except that I didn’t explore engineering prompts in the context of generating code.

I have used this technique to generate code, but it tends to be small well scoped and bounded requests. I feel like this is mostly vibe coding. Vibe code prompting is probably satisfactory for the following:

Agents

All AI assistants are agents. Prompting AI platforms, such as ChatGPT, are agents too.

Agents in the context of this blog entry will focus upon writing and confirming softare. Rather than being conversational, coding agents will design and create code. They will write test cases. They will refactor the code.

What they do will be based upon a workflow I suspect not too unlike current software development workflows. The main distinction will be that agents will take on more of the responsibilities that have previously been the responsibilites of individual contributors.

The challenge becomes in how we reach a level of confidence in the code that’s created.

These are not new questions. Theses are the same questions we have had with human softare developers as individual contributors.

Though we had testing and other processes to confirm the software, much of the confidence we had in our softare depended upon on the trust we had with experienced developers. AI is good, but it’s not the same looking a human developer in the eye. AI will also generate much more code at a faster rate than humans can review.

We will need processes that provide sufficient level of confidence on their own. We can’t depend upon AI to tell us the truth about the veracity of the code it writes. It has a tendency to confabulate. For example, it may decide that the best way to get all tests to pass is to remove all of the asserts. But then again, this isn’t necessarily a problem with AI. Plenty of humans have gotten failing tests to pass using similar techniques.

Knowledge vs Wisdom

AI possesses enormous amounts of knowledge, but knowledge is not wisdom.

Knowledge is knowing the rules of the game. Wisdom is understanding the strategies and tactics required to play the game well.

The rules of chess fit on a single sheet of paper. The strategies of chess fill volumes.

In software engineering, knowledge is knowing the syntax and semantics of a programming language. Wisdom is understanding how to use that language well.

Many developers know object-oriented syntax. Far fewer understand the wisdom behind:

This is probably more greatly magnifided with agents. Agents possess knowledge about coding. Agents may even posses knowledge about the wisdome topics I listed above. However, they may not apply that wisdom unless directed to do so.

Team Leads

Software developers will become more like a tech lead, systems engineer or conductor overseeing a team of AI agents. Agents will perform most of the duties that human Individual Contributors had performed before. People won’t write much code, possibly none, but they may review and correct generated code.

The agents may:

Orchestration

The future software engineer may increasingly become an orchestrator. The role resembles the conductor of an orchestra. The conductor does not directly produce the music. The conductor coordinates the musicians so the orchestra can produce the music together.

The agents become the musicians. The human becomes the conductor.

Orchestrating agents is different than being the team lead of human individual contributors. There will be more interaction and discussion with people. There may not be as much interaction with agents once they start working on a task.

A team of agents has a few attributes that aren’t as convenient than with a team of individual contributors. A team of agents can be more easily configured and scaled as needed.

Different problems may require different compositions of agents. Different problems may have a different agents with different skills. The orchestrator may also manage different sets of agents for different sets of problems.

Returning to our musical example, some problems may require teams of agents that resemble:

The composition depends upon the nature of the problem being solved.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Agentic Checks and Balances

I do not think a single monolithic agent should build entire systems alone.

I suspect successful agentic coding will resemble systems of specialized agents collaborating through artifacts, constraints and feedback loops.

For example:

Artifacts flow between agents:

The process resembles the feedback loops already present in good software engineering practices.

The difference is that the loops can execute dramatically faster.

Stable States and Human Guidance

Agentic systems will not always converge cleanly.

Sometimes the agents may fail to reach a stable state.

Perhaps:

At that point, the agents may need to stop and request human guidance.

The human increasingly acts less like an implementer and more like a systems-level problem solver.

Why Decomposition Is Hard

One of the hardest problems in software engineering is decomposition.

Finding the correct boundaries is difficult even for experienced humans.

Determining:

is difficult.

Historically, large-scale refactoring has often been avoided because the implementation cost was too high.

Teams became trapped by sunk-cost fallacy.

Agentic coding may change that equation.

If AI absorbs much of the implementation toil, organizations may become more willing to:

I suspect ideas from Domain-Driven Design will become increasingly important for decomposing systems effectively.

Dependency and Knowledge Management

Years ago, while writing about Hexagonal Architecture and boundaries, I began thinking about what deeper principle connected many software engineering ideas together.

I increasingly suspect that many software engineering practices are fundamentally forms of dependency and knowledge management.

This includes:

The goal is controlling:

I suspect these same principles may become equally important for managing systems of AI agents.

Transparency Matters

I believe transparency is extremely important in agentic systems.

We do not fully understand how large language models arrive at many of their outputs.

That makes visibility critical.

The artifacts produced by agents should remain reviewable:

Black-box autonomous systems without transparency concern me far more than collaborative agent systems operating through observable artifacts and boundaries.

Constitutions and Constraints

I believe organizations will eventually maintain constitutions for AI agents in much the same way they maintain coding standards and architectural guidelines today.

In some ways, constitutions may prove even more important.

A constitution can define:

The goal is not merely consistency.

The goal is preventing architectural decay at machine speed.

The Inversion of the T-Shaped Developer

For years, the industry promoted the idea of the T-shaped developer.

A developer should:

Agentic AI may invert this model.

The AI increasingly supplies depth.

Humans may instead require broader systems-level understanding across:

The human increasingly supplies breadth. The AI increasingly supplies depth.

Mentoring the Next Generation

One unresolved challenge is how junior developers mature into senior developers.

The traditional growth path centered heavily around implementation experience.

Agentic systems may disrupt that progression.

Yet organizations will still need future senior engineers.

I suspect mentoring will become even more important.

But the emphasis may shift away from implementation details and toward:

Architecture as Craftsmanship

Software craftsmanship will not disappear.

But craftsmanship may move upward to a higher level of abstraction.

Much of the implementation craftsmanship developed throughout my career is becoming less critical as AI becomes better at implementation itself.

The craftsmanship increasingly becomes architectural craftsmanship.

How well can the system be decomposed? How well are the boundaries defined? How effectively are dependencies managed? How maintainable and adaptable is the overall design?

Conclusion

I do not believe software engineering is disappearing.

I believe the center of gravity is shifting.

Software engineering is becoming more like systems engineering.

Implementation is increasingly automated.

Architecture, decomposition, orchestration, dependency management and judgment are becoming more important.

Humans and agents will increasingly collaborate together.

The agents become the musicians.

The human becomes the conductor.

References

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

https://x.com/plainionist/status/2065460998668972188 - How I Made My Brownfield Codebase AI-First

From Suril:

Give the agents the persona of a mentor and ask it to explain its decisions so you can better understand and learn more about the decisions it made.

https://www.cnet.com/tech/services-and-software/amazon-ai-leaderboard-tokenmaxxing/ - Token maxxing. Too much of a good (and expensive) thing.

Add the concept of workflow.

Add https://www.thoughtworks.com/en-us/insights/podcasts/technology-podcasts/what-is-spec-driven-development

Lots of terms. We don’t have solid definitions yet.

https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

https://www.lucavallin.com/blog/ai-engineering-for-developers - A tour through AI engineering for developers who already know how to ship software. Fourteen chapters, no LinkedIn voice, no slow warm-up. We will go from ‘what is a foundation model’ to ‘how do you run agents in production on Google Cloud’ without skipping the parts that matter.

https://github.com/github/spec-kit - Toolkit to help you get started with Spec-Driven Development

https://blog.jetbrains.com/dotnet/2026/05/22/claude-codex-ai-agent-skill-for-writing-tests/ -

Description of Bob Martin’s workflow - https://x.com/unclebobmartin/status/2061482997610610863

Need to add terminology:

“T” shaped developers - https://thetshaped.dev/p/the-t-shaped-software-developer. Maybe need to become Dash “-“ shaped developers.

https://www.youtube.com/watch?v=hgZj02hPZuw - We explore a powerful concept called Meta Automation—the process of automating the feedback loop for your ai agents. Whether you are using Claude Code, GitHub Copilot, Cursor, or ChatGPT, relying on markdown guidelines (or “markdown prayers”) isn’t enough. To achieve true efficiency in software development, you need to move toward deterministic, automated checks.

Introduction

Since the AI is taking over the toil of writing the code, this give people more time to think. Think about the product, design, structure, etc.

We are free from the sunk cost fallacy. When we realize the architecture, design or implementation does not match the design, it’s easier for the AI to change it.

Constant companion to bounce ideas off of, but be careful. AI is sychophantic. It will tell you that all of your ideas are great.

Use existing tools, such as Git, Jenkins, xUnit, SonarCube, etc. Gen AI can be used to create scripts and other automated procedures to stitch these tools together, but you don’t need to use Gen AI to recreate an entire workflow from scratch.

Do agents have memory/state?

Oh. That’s a very good question. I’m not sure of the answer. I think I could argue it either way. I guess like most software engineering problems: It depends.

I imagine a group of agents as a state machine, which is why I used the term event. Classically, they would be stateless.

But I can also imagine a set of agents being like a set of Bounded Contexts interacting as defined by a Context Map, and the BCs could have state.

State could be useful, but it introduces a lot of issues.

Maybe we treat agents as semi-short lived transient elements. The come into existence when summoned/triggered for a specific task, such as adding a new use story feature. The maintain memory during that task. Then once the task is completed they go away and that memory is deleted. It would be similar to object. They have state but only between within their lifecycles between the Constructor and Destructor.

Vibe Coding

The term Vibe Coding entered the lexicon a little more than a year ago, but it took off like wildfire.

Describe what you want from the LLM, and let it create the code for you.

Do we even need software developers anymore? Let the Product Managers vibe the code by talking to the AI and telling it what they want. This is basically what I did with my Advent example above.

“There is a new programming language—it’s called Human.” — Jensen Huang, Nvidia CEO

“From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues… are as damned difficult to make as they would be to use.” — Edsger W. Dijkstra

Agentic Coding

With Agentic Coding the human becomes the tech lead or manager who oversees a set of agents that will handle the toil of writing code and other tasks.

The agents will be a team specified and managed by the human.

The agents will have knowledge, but they may not have wisdom.

The agents will have to be specified/prompted with sound software engineering techniques. You’ll need to learn Software Engineering skills, such as Design Patterns, Practices/Procedures like TDD, BDD, etc. Organization such as DDD. You may not have to know how to do these directly, but you may need to know how to do them well enough to direct the AI and evaluation what it has produced. I suspect you’ll need these, in which case most of my blog entries will be useful and possibly even more important. However, if AI learns and understands these on its own, much like Data Structure implementation specifics or details lower in the stack, they may not be as important day-to-day. Maybe instead of supporting future software engineers, my blogs become an archive of what we used to do before Ai took over.

Here are a few references:

The agent team harkens back to The Mythical Man-Month (MMM) Surgical Team - https://herbertograca.com/2018/09/10/3-the-surgical-team/. However, rather than trying to find individuals who can support the team, we can define agents for the team.

But here’s the problem with agents. While we have knowledge, they don’t have wisdom, as was discussed in the previous blog. Therefore, we have to specify them with prompts, mainly defining their abilities, responsibilities and constraints. This requires human experience and wisdom. Agents can be specialized, as was suggsted by the MMM Surgical Team. Specialized agents will have specialized specifications. There may also be global specifications for all agents, such as maintaining a consistent Ubiquitous Language. These global specifications are sometimes called a Constitution.

Examples of abilities, responsibilities and constraints include:

Most of these should be known via training data. However, it may need to be specified so that the agents know to use it. I.e., for the most part, we won’t need to teach the agents about a concept from scratch. It probably knows about it. It just needs to know that we want it to use it.

No one agent should do it all. There should be a set of agents working together. They should probalby communicate via artifacts, such as requirements, tests, implementation, etc., as well as communicating via text.

They should work iteratively. Don’t solve everything. Do it in small steps.

They should not go off into the weeds. If they get too lost, they should stop and ask the human team lead/manager for help.

It’s not that much different that the instructions that you would give to human developers; however, you probably need to be more specific for agents.

In time, agent specs might be provided by vendors.

Some are posting their agent specs online, such as Bob Martin’s swarmforge.

The main difference is that the team lead can build a team of as many AI agents as needed and as narrowly focuses as desired. For example, one AI agent could have a single responsibility for mutation testing. Teams can be a different composition of AI agents. And scale is not an issue. An agent team could be defined for just one class, which is something you wouldn’t do with human developers.

Agents are limited to the toil. Here are a few more ideas as to what agents can do:

Context Window

LLMs are amazing. I know there’s no real thought process within them, but they certainly present the illusion of thought.

With all of their training, they have one limitation. They know everything and nothing at the same time. Their responses only make sense within the context of the current task, which is their context window. It’s their working memory.

Context windows may be large, but they are finite. When context is at capacity, you don’t know what important knowledge will be jettisoned to make room for new context being added.

It may remove some of its constraints about how to design and implement code. It may remove domain knowledge. It may remove design and implementation knowledge. It won’t remember what it forgot.

It’s similar to attention spans in people, but there are differences. Short term memory is humans is limited to about Seven Chunks. Context will eventually fade. But we forget something, we tend to remember that we knew it at one point, and we know that we may need to refresh our memories.

When AI forgets something from its context window, it’s pretty much gone.

There’s a limit to how much the AI can remember. It’s context window is a bit like an attention span or short term memory. People have limited attention spans and short term memory too, but we have the ability to build long term memory for a specific context. I don’t know that AI has that type of long term memory.

I have a feeling that AI has complete general knowledge of its training date, and then short term memory in the context window for what’s prompted or stored in context.md files.

When the context window capacity is maxed out, some knowledge is ejected, and we don’t control what it is. It could be very important knowledge that becomes jetsam. It could be something that’s domain specific. It could be an architecture, design or implementation rule. It could be something with behavior. I think that’s when AI goes off the rails.

Context windows will continue to get larger, probably for a price, but there will always be a limit and there might even be diminishing returns. For example, doubling the context window’s capacity might require four times the cost.

Token Management

Cleaner code => fewer tokens. Reference: https://beyond.minimumcd.org/docs/agentic-cd/operations/tokenomics/

Tokenomics: Optimizing Token Usage in Agent Architecture

How to maintain context better. https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html

AI conversations are ephemeral by design — decisions made early fade as sessions lengthen, and nothing survives the session boundary. Developers hold on to long conversations not because long sessions are productive, but because the context lives nowhere else. I propose externalizing decision context into a living document — external memory that persists what the context window cannot, turning transient alignment into durable shared understanding.

I think that leveraging AI to remove that toil successfully will be about the context window and token management.

We have two issues with AI:

Token cost Limited context window

We don’t want to blow through our token budget. We also don’t want agents to forget important things, just because their context window is full.

We have the same issues with human developers. We manage this with systems will well defined boundaries … or at least we should do that. My gut feeling is that the practices we’ve used for humans to develop software will be useful for agents too.

I also think there are some practices that will help with hallucinations, such as mutation testing.

I suspect that good boundaries, such as Bounded Contexts, or Deep Classes in using Ousterhout’s terms, will be key to this. Just as these boundaries protect the human mind from having to know about too many details, they also shield the AI from those details it doesn’t care about either.

For example, the AI should only know about the contracts of other classes. It shouldn’t know about the entire design. This will help keep the number of tokens and the size of the context window manageable … I think.

However, this does introduce some degree of duplication risk. Different Bounded Context agents could develop classes with similar behaviors. Maybe a good design includes a rover agent whose job is to look for duplication candidates and return findings back to the human designer. I would not trust them to make the changes, but I would consider their findings.

If one creates an army of agents, how do they communicate? I don’t think it would be wise for agents to know about another. However, I could see them sharing artifacts. For example, the code generated by developer agents as output could be the input to the mutation testing agent. It feels cleaner, and all artifacts would be viewable for human confirmation too.

I’ve also heard of prompts along the lines of: Write code like Kent Beck.

Add the concept of a chunk. It’s more efficient with memory.

Reference good software practices. You don’t need to invent, design or implement practices. You only need to reference them.

Boundaries

This is where I think boundaries could play a role. Don’t force the AI to know the entire system. Define bounded contexts with a limited number of external resource dependencies. Give AI its guardrails and limitations and let it solve that isolated problem.

I don’t think this is uniquely an AI approach. I think it works well for teams of people too. It was the theme of: Hexagonal Architecture – Why it works. Though this was part of my Hexagonal Architecture series, it doesn’t apply to HexArch exclusively. It about dependency/knowledge management.

I introduced the concept of an Event Horizon. The idea is that these boundaries allow information to flow in only one direction, and it may be in or out depending upon the nature of the boundary. For stable/fixed boundaries, they have no knowledge or dependency of the outside world. Neither teams nor people need to be concerned outside the boundary. For unstable/flexible boundaries, the outside world has no knowledge or dependency upon them. This means that the design/implementation inside the unstable/flexible boundary can be anything from one class to thousands of classes. It won’t affect the elements outside the boundary.

I described this a bit more two blog posts later with Nested Hexagons.

Jump forward almost a year and I Summarized the Test Double blog with this:

Future blogs will introduce additional concepts that will coalesce as well. I feel there may be a grand unified theory of software engineering that’s still just a bit beyond my grasp. If there is such a grand unified theory, I’d be willing to bet that Dependency and Knowledge Management is part of it.

Then a few months after that I Summarized in the Coupling and Cohesion that they are part of that grand unified theory as well.

The grand unified theory is starting to come together in my mind, but it’s a ways down the road. I need to finish the Design Patterns and introduce and write about some design principles, such as SOLID. Think I think I can get into how and why this all works.

In order to have bounded contexts, you’re going to need to architect and design the system with bounded contexts in mind and the Context Map that documents their interaction.

I suspect that AI could help with this too. The trick is to limit it to the bounded context and its contract. Don’t allow it to cross the Bounded Context Event Horizon.

Then we have something sort of interesting. We have the higher level system at the Bounded Context and Context Map level, and then we have the individual lower level Bounded Contexts. We can use AI to craft each, but I think these should all be separate AI sessions.

Notes

Dave Farley podcast with AWS guy - https://rss.com/podcasts/theengineeringroom/2787831/ and a video snippet -https://www.youtube.com/watch?v=SnIUUTdIFMM

Join Dave Farley and David Yanacek as they discuss the intricacies of compiler design and large language models. This programming discussion explores how computers process information, contrasting traditional compilers with the sophisticated layer added by LLMs. Understanding these concepts is vital for anyone in software development.

https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html

It was very interesting to read OpenAI’s recent write-up on “Harness engineering” which describes how a team used “no manually typed code at all” as a forcing function to build a harness for maintaining a large application with AI agents. After 5 months, they’ve built a real product that’s now over 1 million lines of code.

https://martinfowler.com/articles/harness-engineering.html

The term harness has emerged as a shorthand to mean everything in an AI agent except the model itself - Agent = Model + Harness. That is a very wide definition, and therefore worth narrowing down for common categories of agents. I want to take the liberty here of defining its meaning in the bounded context of using a coding agent. In coding agents, part of the harness is already built in (e.g. via the system prompt, or the chosen code retrieval mechanism, or even a sophisticated orchestration system). But coding agents also provide us, their users, with many features to build an outer harness specifically for our use case and system.

https://martinfowler.com/articles/sensors-for-coding-agents.html

There are multiple dimensions we usually want to achieve and monitor in our codebases: Functional correctness (works as intended), architectural fitness (is fast/secure/usable enough), and maintainability. I define maintainability here as making it easy and low risk to change the codebase over time - also known as “internal quality”. So I don’t only want to be able to make changes quickly today, but also in the future. And I don’t want to worry about introducing bugs or degradation of fitness every time I make a change - or have AI make a change. I usually see the first signs of cracks in the maintainability of an AI-generated codebase when the number of files changed for a small adjustment increases. Or when changes start breaking things that used to work.

https://www.youtube.com/watch?v=utBeUmDPApk - Agentic Workflows Have Changed EVERYTHING in 2026 (DEATH Of The Senior Dev?)

Previous: The End of Coding as Toil

Next: WORK IN PROGRESS – Communication Patterns

Home: Design Pattern Evangelist Blog