Your Coding Agent Should Maximize 'Youness'

Creative vs Assertive

This is not really a hot take, but I was just thinking about how in The Before Times we already had different developer setups when we did work. I’m pretty basic and just raw dog VS Code without any meaningful extensions. Plenty of coworkers have used JetBrains flavors, Vim, EMacs, some even use Sublime Text because they like the simplicity.

The human aspect of the code creation was also very different person to person. Each team member had their own affinity for certain design patterns, and as long as it was understandable to the others pretty much anything goes. Names of Things are also relatively arbitrary, so variance there was to be expected as well.

However, on any given project we would usually commit to one linter tool (or at least ruleset) so all the code would stay consistent and we didn’t have to Nit syntax at review time. We needed to use one testing framework, CI runner, and code doc format. So already we have this split between the Creative bucket where variance is acceptable (and maybe even beneficial a-la “diversity is our strength”), and the Assertive bucket where rules are required because the system will not work without it.

But we were still largely un-opinionated in how the code was created, just that it produced the correct result (accuracy) and the shape of it was consistent with the rest of the code and the team’s expectations (precision).

“I don’t really care how you create the code, just that the code is Good.”

Agents as an Extension of You

It seems to me that Agentic tooling for the purpose of code generation probably staddles both Creative and Assertive buckets, although certainly less assertive than one might think.

If you use a local indexer to chunk and vectorize your code, or if you use an LSP to traverse your code with graphs, or if you are just a token burning grep-aholic, its not really anyone elses concern how you and your Agents work your way around the repo. You can likely plan the way you want to (as long as you use the required ticket fields/tags), you can steer the model to generate code the way you prefer, and you can build your own review skills and tooling however it is that suits you.

Now some teams may focus more on persisting the knowledge and guidance and workflows into the common repo instead of the personal harness. This is probably better for anything that the team can agree upon. If one team mate discovers some external context in the course of doing work, its certainly better for everyone else to have their context updated so they don’t have to rediscover it on their own. I think this is especially true as a way to improve the onboarding experience. You could say then the Agent should also be an extension of Your Team.

You could probably extend that out even further to Your Company. Personally, I think the value in using Model based workflows is that they allow for interfacing using Associative Processes that don’t need to match each other exactly.

So if we treat PRs like an API, where the provider doesn’t care what you do with the data, as long as you pull and push according to the schema, we really aren’t in that much of a different place than we used to be. The primary difference is that a larger proportion of the teams automative capacity is the sum of the individual team members’ capacity.

Glossary

Model

I just get sick of saying L-L-M all the time.

Agent

LLM (decision) + Context (direction) + Tools (action). Easy-as.

The Before Times

Prior to the proliferation of LLMs, the software world had very different unit economics, bottlenecks, and operating procedures. There was always a backlog of requests that grew faster that you could chew through them. Humans wrote documentation only for other humans. Internal tooling was rarely bespoke and was delegated to awkwardly duct-taping together pieces of different SaaS vendors. Everything was done by hand, even the things we didn’t want to do by hand. If you wanted to automate some of that hand-doing, the automation had to be done by hand.

Associative Processes

As long as my planning tickets contain roughly the same information as your planning tickets, they don’t have to have exactly the same static formatting or schema as each other. I think this is really great because it allows for increased customization on a person-to-person or group-to-group basis but still allow for interoperability without having to design everything up-front. The downside is it also allows for less thought to be put into your processes and still get Something That Works.

Something That Works

What you have when you limit the success criteria to “I get what I want most of the time”. This is the cousin to “this works on my machine”. This is mostly an illusion, because if you are building a product, you certainly are not the only user. Even if you were the only user, what you want is likely to change over time.

The Gap between this state and a real deliverable is

Durability (is the current functionality reliable?)
Extensibility (can I chage this without redesigning it?)
Comprehensability (do you understand this, or is it a black box?)

Gap

The difference between what you need and what you have. Gaps identify a need for Reflection. In the case of using LLMs, Gaps are a great chance for you to theorize what is going wrong (a core skill of Software Engineering), and encode your learing in a way that will steer the LLM. If you do this right, you will have improved Convergence and will be much better off the next time the same situation arrives.

Convergence

The distance between what you know and what an Agent can reliably act on. Through your (or your users’) interactions with an Agent, you should aim to reduce the distance between “what I would have done” and “what it did”. When using Agents as a primary control plane (like code assistance) this is critical, because the LLM is a static model. It does not ever update or learn by interacting with you in the way that you learn from interacting with it. In order to continue to have the LLM “follow” you as you learn what good and bad outcomes look like, you have to provide that signal to the LLM in a durable and accessible way. Until something like continuous fine tuning or self adaptive world models exist, this is about the best you’ll get.

Software Engineering

The act of:

theorizing a model of a business and technical domain
abstracting that theory into automations
updating those automations congruous with external feedback

All while maintaining or improving system coherence. Generally speaking, writing code is the lowest leverage task in the stack.