My curiosity has gotten the best of me and I have been diving into using A.I. coding agents after holding off on it well after they started to become popular and trending in the industry. I’d like to share some things I’ve learned after using a couple agents to build a non-trivial Python application. I think I have developed some informed opinions at this point about how to work with them, how to avoid A.I. slop in addition to using them in a secure and safe way.

Spoiler Alert: A.I. Coding Agents cannot be used to replace any software engineer in my opinion. I suspected this from the beginning, but after actually using them for a bit now to see for myself, I feel more confident in this assertion.

As soon as you try to get them to do anything truly complex, the reliability tanks and the chances of them making mistakes or building something (even if without mistakes) which you didn’t want or intend in the first place increases (see my post on Chaos Theory and how the longer that dynamical systems run, the less you can predict or forecast their trajectory – it is the same with “letting the A.I. go” – small deviations accumulate and compound over time which ruins the final result).

You need “humans in the loop” constantly to get any meaningful or quality results. A.I. agents are tools that we can leverage with our knowledge and know-how as software engineers which can make our lives and work a little easier and a bit better.

Terms:

• Token:  A character or set of characters (potentially a word, but not always). The question or sentence you give to an LLM as input is broken down into smaller chunks and pieces called tokens for processing.
• Context: A window of “memory” which an LLM retains which contains contextual information about the problem domain or project you are asking about. When an LLM has information it needs in it’s context window, you are more likely to get a relevant and helpful response.
• LLM: Large Language Model – these are programs that are essentially a long mathematical equation that predicts the next probable token given a set of previous tokens. If you give it, “Complete the following greeting: How are ___”, there’s a high chance it will guess “you?” as the final part. These systems are pattern-matching probabilistic machines. They do not understand anything like humans do, they are using statistics and probability along with the natural rules and statistical nature of language to predict the next token. (That is over-simplified, but it is the most important idea about how to think about them, IMO).
• Coding Agent: A software program that leverages an LLM as an interface to use natural language (plain conversational English) to give coding instructions to, and carries out these instructions by manipulating files on your system, including source code files and folders.
• A.I.: Artificial Intelligence – I only include this because when people say “A.I.” now, what they really mean usually is LLMs which are a particular incarnation of “A.I.”, but there are other branches of A.I. that are not natural language based.
• Frontier Models: These are models that are the “latest and greatest” offered by companies such as OpenAI, Google, Anthropic and DeepSeek.

Why Use a Coding Agent?

• It helps with some of the tedious tasks, saves time and speeds up development. By how much, you ask? Certainly not “10X”,  but by a bit.

Coding Agents can handle the simple tedious tasks such as “typing” and remembering syntax details for a particular programming language. This alone contributes to significant time savings that accumulate, saving you the time of looking up some syntax detail that you forgot or making typos which you have to later hunt down, correct and fix. Note, that you still need to know the syntax and language because you have to review the code and read it at every step to prevent bloat, entropy and divergence the agent will inevitably tend towards.

• You can also use the coding AI agent as a pair. You can have it function as a more interactive “rubber duck“, so to speak, and have conversations about implementation, design and product planning, bouncing ideas off of it, have it bounce ideas off of you, and help with iterating towards refining a design and product plan.
• If you’re working with a code base that is very difficult to understand, an agent can function as an aid to help break down and explain the code to you.
• It can write the documentation. It will update and format the README to generate usage instructions, update notes on application structure or new feature sets, generate and format specifications and all the tedious extra tasks like that so you can spend more time on actual feature development.
• You can use it to augment your effort by leaning on it for highly domain-specific knowledge. For example, some features I developed for my program depended on geological phenomena which I only have cursory knowledge of. I would have had to spend a lot of extra time reading up on geological processes and mathematical formulas I just don’t know currently. The coding agent was able to fill in that gap for me (and teach me some things about an interesting subject).

Besides the practical implication of the time savings, you might just find it fun.

Where Should You Start?

If you’re looking to dip your toes in the water and get going, I would recommend you first take at least one agentic A.I. course. I can recommend Anthony Alicea’s A.I. Assisted Development or Bob Martin’s Clean A.I.: Agentic Discipline. After going through these courses I felt like I had enough foundational knowledge to help me get started and catch me up on the basics of these tools.

A.I. Coding Agents

There are a number of different agents you can use. Some are integrated directly into your IDE (like GitHub Copilot in VS Code or Cursor) and some are used in the Terminal. I prefer agents in the Terminal because this slows me down and makes me converse with the agent as if it were someone I was pairing with.  I can leverage the agent for brainstorming on planning and implementation before just editing the code in place like an IDE integrated agent would inevitably tempt you to do. It encourages me to THINK first about the software and what I want to do more thoroughly.

The most “famous” of these agents is probably Claude made by Anthropic, but I primarily used these two:

• Aider: This is one of the “older” agents that has been around longer than others and you use it in the terminal. It simulates working in a Paired Programming fashion and is free to use.
• OpenAI Codex: This requires signing up for a subscription with OpenAI. I have a Plus subscription which does come with rate limits, but I’ve been able to get work done even with that in place. With Codex you can use OpenAI’s Frontier Models like GPT-5.5 at the time of writing.

How To Setup and Use A.I. Agents Safely

Security and privacy are a concern when using agentic A.I., especially if using Cloud models which may use or log your input for further training the models. Not to mention A.I. agents can sometimes have a “mind of their own” and make damaging changes to your system. Below are some things I learned and think are useful to keep in mind in light of this.

• Usually, companies like OpenAI and Google offer a guarantee that they will not use your data as long as you purchase a paid plan or use the product under a paid tier.
• Disable telemetry in whatever tool you are using.  For example, in Aider you can pass an argument --analytics-disable which will stop the program from sending any information in the background.
• Use Docker Sandbox in Lockdown mode. This is a relatively new tool offered from Docker which is made specifically for running agentic A.I. in a sandboxed environment. The sandboxes are different from Docker Containers because they don’t share the system kernel like normal containers do. They are a microVM (Virtual Machine) that has its own kernel and separate resources providing a higher level of isolation. I recommend installing sbx which is the CLI tool for managing Docker Sandboxes, and make sure you start a sandbox in “Locked Down” mode. I personally would not use an agent outside of a sandbox like this to protect my system and control outbound/inbound connections.
• Simply don’t grant agents access to sensitive parts of your system or application. For example, don’t allow access to the database or other critical infrastructure, files and folders. You can specify which files and folders are accessible with configuration in the agent and by using sandboxed environments which allow you to manage access control explicitly.
• You can also host models locally with Ollama inside a Docker Sandbox for maximum privacy and control of your data. This requires a very powerful machine and hardware, however, and personally I was not impressed with the capability and results using local models vs. Cloud Frontier models.

Which Models Should You Use?

A good place to start is to explore online “Leaderboards” for A.I. coding models. You can Google search for these leaderboards to get an idea of how different models compare in benchmark testing and use cases. It’s good to overweight community leader boards as some “official” ratings might be biased because of the major A.I. companies funding some of these boards.

Models come in two flavors (there are also subtypes like “reasoning” and thinking, but topic for another day): Cloud and Local. I prefer using Cloud models because they are faster and more capable generally speaking. If you have a very powerful machine and graphics card, then you might be able to get sufficient performance with local models.

Below is a short list of ones to try at first, but is by no means complete. I may try to write a separate blog post exploring models and what I’ve found trying different ones out.

Frontier Models:

• OpenAI GPT-5.5
• Anthropic Claude Opus 4.7
• Google Gemini 3 Pro
• DeepSeek R1

Cheaper Models for Implementation (after planning):

• GLM-5
• MiniMax M2.5
• Kimi K2.5
• DeepSeek 3.2

Local Models:

In order to use local models, you can install Ollama for downloading the models to your machine and hosting them locally. You can check out my repo with a basic setup using Ollama and Docker Sandbox with Aider.

• Ollama Qwen 3.6
• Ollama Qwen 2.5 Coder

Useful Practices

Plan then Implement:

Generally, the pattern I’ve found cost effective is to use Frontier Models for planning out design and implementation of a feature, and then use a lesser powered cheap model for the actual implementation and coding.

For example, to plan out a new feature I’d like to add, I will use OpenAI’s GPT-5.5 or Gemini’s 3-Pro models to have a brainstorming session, hammering out details of the feature and having the agent record design decisions and implementation steps in a markdown file.  Once that markdown file is refined to a degree of specificity I’m happy with, I switch to a lower powered model like OpenAI’s GPT-5.4-mini or Google’s Gemini-2.5-Pro perhaps.

You can experiment with other models to find which one works best for you. I particularly like GLM-5 for implementation – it is fast, does not do too many non-sensical things and generally produces reasonable code following the instructions (not always).

Iterate, Iterate, Iterate:

If there is one thing I hope to pass on to anyone who wants to use these agents and tools effectively, it is to work towards the program and feature you’re building in small, highly managed and monitored iterative steps. I have found this to be the most effective approach and I can get good results developing a complex feature making sure it’s done slowly and carefully in small steps.

The agent can go fast. Too fast. The goal in my opinion with these tools is to get them to slow down. To get yourself to slow down. In the end, as the saying goes, you need to “go slow to go fast”. Trying to “vibe code”, or “one-shot” the implementation of a feature in steps that are too big and letting the agent go while you walk away, in my experience will get you bad results and in the end will slow you down when the product and software is bug-ridden, does not follow good maintainable software design and just doesn’t work as you intended.

• Use good software design principles and keep the code clean, readable and maintainable just as you would if writing it yourself.

I also want to stress this. Don’t let the agent write bad code. It will, and it will bite you in the end. If the code is developed with the agent in very small iterative steps, stopping after each to check quality and actual behavior, then you’ll be in much better shape.

I stop after every small change and review every line of code the agent wrote. I make sure the agent writes tests covering observable behavior for every change made along the way. I make sure the tests make sense and pass before moving on to the next small step. I make sure the names the agent chose make sense, are descriptive and are easy to understand expressing intent clearly. I make sure I understand the code and know what it’s doing.

Don’t let the agent bloat the codebase with poor implementation choices. Check the names it chooses, check the decisions it’s making and correct and guide them along the way. This has kept me out of trouble and when I look at the software produced, I can be proud of it and would be able to debug or update it myself in the future if I wanted to.

How to talk to LLMs which the agents use:

• • Use Markdown files (.md)

There are conventions, including an open standard for Skills developed by Anthropic which is worth reviewing, but generally I create markdown files in strict markdown format (similar to how a standard project on GitHub has a README.md file), and then make sure the agent has them in their context window. Some markdown files are read-only, like coding conventions and instructions. (In Aider, for example you can add read-only files to the context with the /read command).

So I will have a Markdown file containing the Project Goal and vision for the program. A Markdown file for a feature I want to plan out and implement. A Markdown file with Coding Conventions I want the agent to follow. The agent can only read some of these files, or can edit others like the feature planning document. It’s important to keep in mind that an agent may not remember all the things you write in these, but the files serve as a good “reminder” or loose guidelines which the agent will sometimes follow (this is just due to the probabilistic non-deterministic nature of these systems).

Make sure you include EXAMPLES for the agent. See the examples provided for what a good comment looks like and a bad comment looks like HERE.

• Nudge it in the right direction within it’s Corpus.

LLMs have a “Corpus” which is the library of text it has been trained on. This Corpus, under the hood, is basically numbers spread out in “vector space” which means it’s like putting words and text on a graph. Related words are closer together, non-related words and contexts further apart in the space. You want to try to get the LLM to get into the right “space” in the graph to get better results.

So if you wanted the LLM to correctly guess “How are you?” in the following scenario, instead of asking:

“Complete the following sentence: ‘How are ____’,”,

what would get a more predictable result would be to “nudge” it towards the right space in the Corpus by saying,

“Complete the following greeting: ‘How are ___'”.

Using “greeting” instead of “sentence” nudges the LLM to look in the space where text related to greetings are, which will much more likely give you the result you were looking for. Keep this in mind when asking the agent about the code in the project or asking it to make updates to the program.

Some other general tips:

• Have the agent write tests and run them after every change. Check the tests and make sure they cover behavior and make sense. Also use a test coverage tool and get the agent to write more tests for modules with low coverage.
• Use linting tools on the codebase and give the errors to the agent to fix, keeping the code in tip top shape along the way.
• Instruct the agent to use type annotations if you are working with a non static-ly typed language like Python.
• Use a Cyclomatic Complexity checker (like radon with Python) which will measure how much nesting and branching there is in your functions with a score. Give the functions with the highest score to the agent and ask it to refactor to reduce the complexity score. This keeps the codebase lean and clean and not a mess of if/else conditionals or nasty switch statements.
• Periodically clear your context window and start over. This helps with a couple things:
  • 1) Compaction – the window is cleared automatically when it grows very large to save space, but that will result in the LLM getting confused all of the sudden with missing context it had before compaction took place.
  • 2) As context gets larger and larger, there is more of a chance that the LLM will make “too many connections” in the giant wall of text and words, potentially producing convoluted or non-useful answers and responses.

Usage Examples

These are actual examples to show how I worked with the coding agents developing a Python program that accepts a series of one or more groups of tone frequencies (akin to musical phrases or melodies) as input and runs them though a functional pipeline to get a transformed version of the musical composition at the end. The program was not trivial – it was designed to handle:

• both monophonic and polyphonic voices in a composition
• application of transforms to one or more targeted voices, phrases or the entire score
• a variety of complicated transforms involving stochastic side effects among other things (I really tried to get creative with the transformation algorithms, which was a big part of the fun developing this)

I used the agents to first plan out product goals, features and implementation steps (in an iterative fashion!), and then had a model implement the changes in small steps with constant checkpoints at each step to verify and review changes.

This iterative progress with constant checks and reviews produced very good results with the end product being a functional program that did exactly what I wanted it to, and also wasn’t a hot mess.

I provided the agent with some markdown files, for example a CONVENTIONS.md file, which reminded the agent of good software design principles I wanted it to follow.

Planning a Feature:

The above exchange has the agent recommending a “Track” data structure as a domain object abstraction representing a phrase in a group of polyphonic phrases. We went with that initially and later as we continued to iterate, eventually wound up with a “Voice” abstraction instead which is following the Domain Driven Design idea of ubiquitous language matching terms of the domain (musical composition in this case). I’m just pointing that out because, this process unfolds just like real software development – in iterations, in sprints, in constantly adjusting course as the design unfolds and is discovered by iterating towards it! Again, forget about “one shot”-ing anything. That is just not how real-life development of sophisticated systems works.

Breaking down the steps into further smaller iterative steps (I highly recommend this approach – in a fractal fashion, continue to break down steps recursively):

Back and forth brainstorming and using the agent as a pair to flesh out a simpler implementation (it makes for a great rubber duck!):

Implementation refactoring and guidance on comments (note how the agent did NOT follow instructions in the CONVENTIONS.md file about comments and I have to remind it):

Now this is with Codex (the above was Aider). I’m now telling the agent working on the same codebase that I want the names of functions to be different and more expressive. This is a great example of how you, the Software Engineer, need to bring your good instincts and guidance into the picture constantly to direct the agent:

This is a good example of reigning the agent in and preventing the inevitable bloat and over-engineered complexity it will try to introduce. I’m working with it to reduce the complexity of a proposed Data Structure to keep the program simple as possible. Note that its response then must be evaluated by you, the real software engineer, using your judgement and experience to determine if the change is a good idea and truly an improvement or not.

These are also some things you have to watch for – the agent just doing nonsensical things like here where it made an unnecessary and redundant assignment with phrase_transform = transform-function . That is just adding bloat, so I asked it afterwords to undo that change and just use transform_function directly.

The agent might (probably will) write magic strings and magic numbers all over the place. Here I’m catching them and asking Aider to do the right thing:

You can ask the agent to produce output or some kind of material as a checkpoint. I recommend doing this regularly to make sure the program is behaving as expected:

Using the agent to clarify the code. I want to understand the code being produced and read it, every line. Besides just reading it, I can also ask the agent to explain and break down the code if I still have questions to clarify any misunderstanding. Here the agent reminds me that a previous update introduced a closure which bakes in an argument that I thought was missing in the pipeline at that point.

Managing Spend and Cost

• Tokens are expensive. Most of the companies offering the LLMs charge by the token, particularly if you are using API Keys and pay-as-you-go plans. I would recommend looking at purchasing subscription plans which are a flat rate and prevent the mounting cost of sending more and more tokens on a pay-as-you-go plan. OpenAI Plus, for example is a subscription that allows using Codex. You do have to keep in mind usage limits and rate limiting, but so far it hasn’t been a huge issue with Codex for me.
• AWS Bedrock: You can also consider using services like this one AWS offers which might give you access to more cheaper models compared to what the big A.I. companies like Google, Anthropic or OpenAI offer.
• Lastly, I would caution against “too good to be true” deals. I have seen some recommendations for services that offer “free” Frontier-level model usage, but my understanding is that if you use a free model, you are agreeing to have that company intake your data and lose privacy or control over what is sent and used to train the model or retained on accessible servers.

Final Thoughts

There is a public stigma and general negative sentiment about A.I. currently. This is due to the belief that this technology will be able to replace people and put them out of work. This has become a concern among some in the software industry as well.

Having used “A.I.” now both professionally and for personal projects, in my opinion this fear is unjustified. While I wasn’t sure at first, now having tested out coding agents, I am excited about this new technology and think it can be used as a tool to leverage, making my job easier, less tedious and I think the agents are fun to use.

And to be clear, these are TOOLS, meant to be used by people, which can maybe make our lives a bit better. I think you NEED people for these tools to be useful at all in the first place.

One thing that struck me during this learning process was how much I had to monitor, correct and guide the agent.  It was nonstop – I could not just get up and walk away for any significant period of time. This means the agent and myself did not produce “2X” the work (forget “10X”). I think with the agent I produced the same amount of work, it just cut out some of the tedium like typing and syntax issues, and helped me with some domain-specific knowledge and high level math.

I still had to design the software, think about how the functions and components related to each other, manage and decide on boundaries and abstraction levels, figure out good architecture, think about tradeoffs and change course as needed along the way as iterations unfolded – all the stuff that’s still really hard in software, was still really hard using the agent.

The future is unknown, but based on my experience so far diving into actually using these agents to see what all the buzz is about, these are the conclusions I’ve come to.

Further Resources

• Andrej Karpathy Neural Network YouTube Series – a great series on YouTube (free!) which walks you through implementing a neural network with Python from scratch. It is a great resource for getting some understanding of the main mechanical, technical and mathematical techniques fundamental to how these systems work.
• AI Coding Agent GitHub repo – My repo with a small setup of Aider with Docker Sandbox for reference.
• Anthony Alicea free first hour of A.I. course – This is the first hour of the A.I. Assisted Development course recommended as a good starting resource. Besides being a sample of the course, it explains a great high-level mental model and framework for how to view and think about LLMs and how they work under the hood.

In a previous blog post I covered a basic overview of Custom Resources in AWS Cloud Development Kit (CDK) and in keeping with the same theme, I ran into a scenario which I thought would be more straightforward than it actually was: parsing a response containing a JSON object from a Lambda backed Custom Resource.

The problematic context was using a Custom Resource to fetch a secret from Parameter Store which was a JSON object. This object contained some setting and configuration details for AWS resources being deployed in a CDK Stack.  I thought I could simply create a Lambda backed Custom Resource which fetched the secret and returned it, so I could use it in the Stack and pass it to the resources which required that information. It turned out that it  was not so simple.

The Problem:

When you deploy your infrastructure with CDK and need to reference data stored in AWS Parameter Store, for instance, you cannot get direct access to the data in raw form at runtime. This is called “synthesis time” in CDK speak and it means that when you run a deployment, CDK synthesizes an AWS CoudFormation template (a YAML file) for the desired state of your infra with placeholder tokens for pieces of data which are not resolved until later in the physical resource creation process.

The two hurdles to get over were, as mentioned:

• The value retrieved at synthesis time during deployment was an unresolved token, not the actual secret value.
• The configuration stored in Parameter Store was not a simple string. It was in the form of a JSON object, and I needed to dig into the object to access specific properties off of it.

This meant that I could not leverage code constructs such as built-in parsing APIs for JSON or simple dot notation for property access with JavaScript, or easily work with in-memory data in an object type form as you normally would when writing application code.

The Solution:

CDK comes with AWS CloudFormation’s Intrinsic Functions, which you can use to work with and parse these unresolved placeholder tokens at synthesis time as if they were the resolved actual values at resource creation time.

In particular, the functions to use are cdk.Fn.split and cdk.Fn.select, which can be used to split the JSON string and select the value. This may not be the most elegant or robust way to handle parsing unresolved objects at synthesis time, but it worked, is practical and saved me further lost time exploring other solutions which just didn’t wind up working out (such as building a custom Lambda to use with a non pre-baked standard Custom Resource which parses and returns the object).

I also used the built-in Custom Resource AwsCustomConstruct constructs provided by CDK to fetch the parameter from Parameter Store.  What’s great about these built-in Custom Resources, is that you don’t have to create a Lambda, manage dependencies, or write any custom logic to accomplish common use case tasks. The pre-built Custom Resource is automatically backed by a Lambda or functionality to accomplish a given action (in this case, ‘getParameter’ to retrieve a parameter from AWS Parameter Store).  This saves you extra overhead and reduces moving parts in your IaC code.

In case it is helpful to others running into the problem, the code for the approach is below (using this example from the AWS CDK documentation as a reference):

As an example, the kind of data I was storing and retrieving from Parameter Store was something like:

{ "prop1": "prop1Value",  "prop2": "prop2value" }

// cdkProject/lib/myStack.ts

import * as cr from "aws-cdk-lib/custom-resources";

const JSON_PARAM_NAME = "/myapp/secrets/jsonsecret";

// Using the built-in AwsCustomResource construct with the action "getParameter":
    const getParameter = new cr.AwsCustomResource(this, "GetParameter", {
      onUpdate: {
        service: "SSM",
        action: "getParameter",
        parameters: {
          Name: JSON_PARAM_NAME,
          WithDecryption: true,  // Needed for SecureString parameters
        },
        physicalResourceId: cr.PhysicalResourceId.of(Date.now().toString()), // Forces fetch to parameter store on each deploy
      },
      policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
        resources: [
    `arn:aws:ssm:${cdk.Aws.REGION}:${cdk.Aws.ACCOUNT_ID}:parameter${JSON_PARAM_NAME}`,
        ],
      }),
    });

// Parameter Store values are by default available on the Parameter.Value property of the response from SSM:
const paramValue = getParameter.getResponseField("Parameter.Value");

// Here we need to use intrinsic functions to dig into the future resolved actual value of the retrieved secret (which is a placeholder token at synth time):
    const prop1Split = cdk.Fn.split('"prop1"', paramValue);
    const afterKeyPart = cdk.Fn.select(1, prop1Split);  // Part after "prop1" key
    const afterColon = cdk.Fn.split(':', afterKeyPart);
    // the value part after the colon
    const valuePart = cdk.Fn.select(1, afterColon);
    const valueSplit = cdk.Fn.split('"', valuePart);
    const prop1Value = cdk.Fn.select(1, valueSplit); // First split part is the value for the property

    new cdk.CfnOutput(this, "TheParamValue", {
      value: prop1Value,
      description: "Parsed value from the custom resource",
    });

A common problem in software development is how to deal with multiple but generally similar objects that differ in some way requiring handling, processing and application behavior specific to their subtype.  After going through a free MIT lecture series taught by  Hal Abelson and  Gerald Jay Sussman on the Structure and Interpretation of Computer Programs, I came away learning a very useful software design pattern that I have used in multiple projects now to deal with this situation.

In the lectures, it is sometimes called “Data Directed Programming” or “Dispatch on Type”, which is a way of handling multiple objects that may be related and the same in some general sense, but differ slightly requiring targeted processing and handling for them.  Think of cars like Hondas, Toyotas and Fords;  They are all cars and similar in a general sense – they all have brakes, transmissions and tires etc., but you might need to take a specific make to a specialized mechanic to perform certain repairs, because the specifics (i.e. the implementation) of those components can differ requiring special knowledge in order to work on them.

In software development you will at some point inevitably run into a situation where you are dealing with objects of a general type that require different processing based on their subtype.  This usually leads to all sorts of conditional gymnastics and if/else branches that can become complicated and difficult to understand and maintain.  That’s where this pattern can come in to save the day, keep your code clean and get you out of that mess.

Data Directed Programming – The Basic Pattern:

• Keep a table or dictionary of types that map to procedures.
• When you call a general procedure that would apply to a series of related objects with different subtypes, use the type as a lookup to find the corresponding behavior.

Let’s try to make the pattern concrete with an example (forgive me if it’s a little contrived, but it will get the point across and you will recognize when to use this pattern in the real world).  Imagine we have a chat app and we want to process messages that have the same overall shape, but can fall into subtypes such as Private, Broadcast or Group typed messages which differ in a relatively small way and require different handling.

We want to have a single re-usable procedure (or function) that handles message processing – one that we can call when a message comes in.  Let’s see how this looks without using Data Directed Programming (we’ll use vanilla JavaScript for the examples):

// General reusable message processing procedure
const onMessageSent = (message) => {
  // check if message subtype is private and handle that specific processing:
  if (message.type === 'private') {
    ...private message specific processing
  } else if (message.type === 'broadcast') {
    ...broadcast message specific processing
  } else if (message.type === 'group') {
    ...group message specific processing
  } else { 
    throw Error('Message type not recognized.');
  }
};

Note the multiple conditional branches we need to handle the different subtypes of messages appropriately.  It’s not horrible in this contrived example, but it can quickly get out of hand in real world situations and is generally just a bad idea to have complex if/else chains if they can be avoided.  This is where our pattern helps out to eliminate that.

If we make a table and use the message subtype as a primary ID key, we can just pass in the subtype and use the procedure that maps to it directly without having to make conditional branches in our code.

// Make a table, i.e. a dictionary, with keys of message subtypes that map to specialized procedures for that type:
const processMessage = {
  private: (msg) => ...private msg processing,
  broadcast: (msg) => ...broadcast msg processing,
  group: (msg) => ...group msg processing
};

// Our general message processing handler uses the dictionary and looks up the processing we want by subtype, then calling the processing procedure:
const onMessageSent = (message) => {  
  processMessage[message.type](message);
};

As you can see, this is quite a bit cleaner and we’ve gotten rid of all those conditional branches that can be difficult to read and understand.  In my opinion,  good software design and clean code can be based on this one question: Will someone who has never seen this code before be able to understand it quickly and easily?

I can’t stress enough how useful this pattern has been in many of the applications and products I’ve worked on.  This is a common scenario that too often ends up with complicated conditional branching. Obviously you don’t want to overuse any one pattern, but I have found it works well when this common situation arises.

Further Resources:

•  Structure and Interpretation of Computer Programs – a.k.a. SICP: A classic book on good software design principles by Gerald Sussman and Harold Abelson.
• MIT Video Lecture Series on SICP (Free): This post was based on lecture 4B: Generic Operators.