I want to share how I've been approaching agentic development as a freelancer.
#The Terminal
“”Everything starts with the terminal.
I recently made the switch from WarpOpen in a new tab to GhosttyOpen in a new tab. I made the switch since I wanted a more minimal, yet faster terminal. I feel Warp lately has been pushing too many AI-related features that makes the terminal feel bloated and slow.
#Multiplexers
I've also been trying tmuxOpen in a new tab, which allows me to run persistent sessions and gives me more control over windows and panes, which helps with context switching. tmux is widely available and highly customizable.
For all my machine setup I use dotfilesOpen in a new tab.
However, I'm also trying out HerdrOpen in a new tab which seems promising. Feels modern, well-designed and agentic-oriented. It also has mouse support! If you know me, I love shortcuts, but sometimes in the beginning, using the mouse here and there doesn't hurt anybody!
Next week I'll completely make the switch (it's been quite some intense weeks of work!).
#Gathering Context
When tackling work I start with the issue. In some projects I use GitHub Issues, in others I use GitLab Issues or some sort of ticketing system. To me the Issue is where we detail what the problem is. I find issues more relevant when they follow this template:
- Summary: a simple one-line explanation of the issue
- Problem: a detailed exploration of what the problem is. Here I try to avoid providing concrete solutions; that should be part of the PR
- Impact: how impactful solving this issue would be
- Acceptance: what is considered done
As you can see nothing too fancy.
Then, after understanding the issue at hand, I reach out to coworkers who might have more context or experience with it if needed. Being proactive when communicating is essential. Also, for personal communications I avoid using AI tools. I find that the message can be perceived as less intentional if the receiver can tell AI was used to write it.
I think it's a smart move to define what areas in a project should be AI-free, where we know it's humans behind the keyboard. For me, messaging tools like Slack, email or PR comments feel like a natural fit. In essence any place where I need to communicate to other humans. Using AI for reporting, however, is fine by me. What's your take on this?
Once I've gathered the context, I start reading relevant code. Understanding where this new feature is going to land helps me find more robust solutions. I use this information to then guide the AI.
#AI Coding
When I understand the relevant code and have gathered all the context I start with the /interview skill. I give it all the context I've gathered and a proposed solution, along with the issue.
I find it quite useful to connect coding tools with CLIs like ghOpen in a new tab for GitHub or glabOpen in a new tab for GitLab. That way your agent can search issues and previous PRs that you might have missed.
The interview skill is there to help me translate the context into a plan. I find this in-between step extremely valuable. I often find that you lose visibility of the changes you are making when tweaking a plan too much. When you use /plan it gives you back the whole plan, not the changes you just made, which then you need to re-read again. I'm working on a /concise-skill to tackle this.
Once the interview is done, then I jump to /plan. Usually by this step I don't need to tweak too much. Once I'm happy with the plan I hand it off to the agent using the auto mode.
I have skills for each point of the process, and each skill points to the next step:
create-issuestart-issuecreate-prcleanup
This workflow works for me because I dedicate a lot of effort to the architecture, best practices and testing of the project. If not, I wouldn't trust as much as I do the generated code. This is called Fitness Function Driven Development, I talked about it in the last issue.
I've also instructed the agent via the start-issue skill to always create a git branch using the conventions of the project and to work in a git worktree to parallelize the work.
To avoid the costly tax of context switching I make sure before planning the next bit of work to rename the tmux herdr session with a relevant name. Before opening the PR I check the code and make necessary adjustments.
If it's a big task I iterate first with the agent to create a small reproducible example that can then be used as a reference. Along the way I create a temporary skill that can be reused for the task. I've used this approach with great success when performing big migrations that a few years back would have been impossible.
#Conclusion
So, as you've seen, my process is quite lean. I would like to evolve some parts with custom agentic loops to check CI, for example in case it fails, or to report back.
I'm also interested in exploring orchestrators and more complex techniques, however to me what stays true is that for agentic development to happen, projects need to invest in best practices, testing and architecture.
What's your workflow? Feel free to reply, I read every email.
P.S: Writing from Madrid where I think I'll spend most of the summer. I will also be around React AlicanteOpen in a new tab, where I'll be giving a talk about how I built this newsletter. I'm also participating as a "mecenas" of TRGxOpen in a new tab. Perhaps see you around?