How I Set Up My Interaction with AI Agents for Coding and Research

Why post this now?

Recently, after watching an interesting episode of Markus Academy, I was late to the party and started watching the great series on Claude Code for applied economists that Markus Brunnermeier recorded with Paul Goldsmith-Pinkham.

In their discussion I saw a lot of things I was already doing, some that were new to me, and also noticed that parts of my own workflow were not mentioned. Granted, everybody works differently. But in the interest of advancing our general knowledge base, I want to put my ideas out there and discuss them with anyone who might read this, even if it is only an AI.

The central problem for me is simple: coding agents make it much easier to produce code, but they can also make it harder to keep track of and grasp how a research project arrived at its current state.

Why I believe we need better workflows for working with agentic AI

When I started using the Codex VS Code extension in December 2025, I had already been an avid user of ChatGPT for coding and my (admittedly only PhD-candidate-level) “research” since the launch of GPT-4. Until December, I had been in charge of structuring my code in the editor. But after that, I suddenly had someone else working in there and after a few days lost track of what was going on. The number of scripts, and the complexity of their structure, grew faster than I could keep up with.

I had to go through tons of scripts, some already basically irrelevant, just to determine the current state of a project. In research, this is particularly bothersome. We all need to verify quickly how a measure was computed, which filters were applied, and how the individual steps of an analysis fit together.

Note: I found this problem both in greenfield projects, where I started from an empty folder, and in projects I had already pre-structured, although it was slightly less extreme in the latter. So I tried to solve my problems for the last few months.

My first attempt at a solution was smarter prompting. This had helped me before with chat versions of AI and helped to some extent in this context as well, since if properly prompted:

• The agent put files into suitable subfolders when instructed to do so.
• It created README files describing the code and project structure.

However, it was not an all-out success:

• The agent forgot the instructions unless I repeated them all the time - This was annoying.
• README files either became huge and increasingly unusable, or there were so many that I no longer knew which one was really correct.
• During the exploratory stage, new files accumulated faster than I could distinguish current results from abandoned paths.

For me, still far away from finishing most projects, let alone publishing one, these were the immediate concerns. But I can only imagine the pain of creating a replication package from code structured like this, or of being the co-author who has to understand what changed since they last looked at the project.

What others propose to solve the problem

Karpathy’s LLM Wiki

One viral, but perhaps not super obvious, response to my struggles was Andrej Karpathy’s LLM Wiki. I think of it as a framework for aggregating knowledge in a growing set of Markdown files, either for one project or more globally for a user or research group. The idea is to keep knowledge generated in our interaction with the machine from disappearing into old conversations by persisting the relevant context in files that both humans and agents can read.

When I brought this up with my advisor in May or June, near the end of my own experimentation, he told me that he liked Karpathy’s approach but had found a tool he considered more useful for organizing project work: Markplane.

Markplane

Markplane was the next big step in my interaction with coding agents. It stores high-level projects, plans, tasks, and notes as linked Markdown files with unique identifiers. It also provides a Kanban board, dependency graphs, compact project summaries, and an MCP server through which coding agents can manage the project directly. I have tested this with Codex and Claude Code.

Since then, I have integrated Markplane tightly into my projects. I use it to document tasks, explain plans, and structure the overarching project; somewhat like a development team would. This is super helpful because I can search the repository to find out how we - meaning the agent and I - set something up, while the next agent session can read the same record.

More importantly, each item has a stable identifier and a status. A decision can be linked to the task that produced it, and that task can be linked to a larger plan. This is much more useful to me than another general README because I can see what is current, what is blocked, and what has already been abandoned without first reading the entire project history.

Caveat: The documentation has to stay up to date. Otherwise, a polished project summary simply makes stale information easier to consume. Markplane therefore helps with project state, but it does not by itself guarantee a good process.

Superpowers

The second tool I combine with this setup is Superpowers, created by Jesse Vincent (obra). It is a toolkit of reusable skills and workflow rules for coding agents (plugin). Skills provide instructions for recurring tasks such as brainstorming, planning, testing, debugging, and review. A router decides which skills are relevant rather than loading the full process for every request.

What I like is the discipline this introduces. The agent is pushed to clarify a task before implementation, write a plan when needed, test whether code behaves as intended, and review the result before claiming completion. Superpowers also supports subagent-driven development, where a planning agent delegates a narrower task and then reviews the output.

I think this matters in research because many useful checks are mundane but easy to miss: Are merge keys unique? Does sample attrition reconcile? Are dates inside the intended window? Do variables have plausible units and ranges? Writing these checks down does not replace economic judgment, but it makes the mechanical parts of verification visible and repeatable instead of leaving them inside one conversation.

Its planning features are narrower than Markplane’s. They document how to execute one piece of work, while Markplane connects that work to a larger project. This distinction is exactly why the tools complement each other for me.

Note: In general, it is not a good idea to download just any plugin or skill, since the instructions contained in it might be almost anything. I have checked the skills and tools used here to the best of my abilities, but you should of course do the same yourself. Also, be aware that Superpowers makes you burn through more tokens, mostly because it introduces a more complex development process.

For applied economics, I still believe this toolkit is exceptionally valuable. The test files allow you, your co-authors, reviewers, and readers or replicators to look at edge cases and verify whether the implementation really does what it is supposed to do, possibly by adapting the tests to their own questions.

Using Git and version control in the development process

A super interesting suggestion I picked up from the Markus Academy series with PGP is to use version control regularly to split development into bite-sized pieces that belong together in the research process. Git records the history of a folder and shows the difference between saved states. A commit message can then explain what changed and why - ideally, the agent writes that summary itself.

For anyone new to Git: turning a folder into a repository does not send the code to GitHub. It remains 100% local unless you deliberately connect it to an online service. In VS Code and most other editors I have used, the version-control button looks like a small branching graph.

I find Git useful even when I am working alone. It gives me clear checkpoints and, importantly when working with agents, a way back if a change turns out to have been a bad idea. But it really kicks into overdrive with co-authors: a private repository lets everyone see what has changed since they last looked at the project and gives them a concrete set of changes to review. If the repository is kept reasonably clean along the way, a large part of the work needed for a replication package has already been done by the time the paper is ready.

A short excursion on my mental model of model context

Before I continue with my own additions, I want to explain briefly how I think about model context and why it matters here.

Model context is basically the information your agent can use to answer the next prompt: the conversation, instructions, selected files, and tool outputs. As a conversation grows, useful information has to compete with a lot of accumulated material. One tool that model providers now use to address this problem is called compaction, where at a certain level of context, the model starts to summarize its current context, into shorter condensed form, thereby freeing up tokens that no longer need to by copied to your every prompt.

Since I am a mere PhD student, I have fairly limited access to tokens, and this annoys the hell out of me. PGP is very adamant about using compaction and starting new chats regularly. My problem is that a restart is costly when the model first has to reconstruct the project from a mixture of files and previous chat history.

This is why I want the relevant state to live in the repository rather than in one conversation. A new context window is much less painful when the agent can read a compact project summary and then open only the tasks, plans, and code relevant to the next step.

The combination might be better than the sum of its parts

Now that I have bored you with all these details about coding agents and the tools that might improve our collaboration with them, let me get to what I think is still missing: the link between them.

For this, I have combined modified versions of Markplane and Superpowers with a couple of self-designed skills into a continuously extendable package optimized for research and token-poor PhD students.¹

The setup itself is relatively simple. I use the adapted version of Markplane to create a persistent structure for the project and keep track of its current state. I then use the adapted Superpowers package to plan and execute individual tasks within that structure. Where possible, plans are created once and then linked or summarized in Markplane, so that the researcher and their collaborators can find them without maintaining the same documentation in several places.

To support this, I added rules and hooks that check whether the relevant Markplane state has been updated and synced before a task is completed. A slimmer version of the toolkit is also inherited by the subagents used in the process, so that their actions are not swept under the rug.

Further, I added two skills aimed specifically at repository structure and agent behavior in research. Both follow the same basic principle: everything should be as transparent and obvious as possible, so that co-authors, reviewers, readers, and replicators can understand the process and the resulting output. The agent is therefore instructed never to mutate raw data, never to perform a data manipulation without a dedicated script, and to keep the repository in order by creating appropriate subproject folders and documenting which code is used, what it produces, and how it can be run. At the same time, it keeps track of the project checkpoints so that changes can be committed at suitable points.

Note: I brought up context windows earlier, so what you must be thinking now is: if he uses all of this stuff, is that not going to eat into his tokens big time?

For an individual task, the honest answer is yes. Superpowers uses more tokens because it introduces a more involved development process. But I believe that much of this cost can be recovered through the way the tools are combined. The Superpowers router only loads the skills needed for the current task. More importantly, the documentation in Markplane allows me to move to a completely fresh context window, or even to a different coding agent when I run out of tokens in the other one, without having to reconstruct the whole project. This is also why I adapted the package for Claude Code, Codex, and Gemini/Antigravity.

Finally, if I do need to compact a context window because I cannot or do not want to start a new conversation, the toolkit instructs the agent to use the existing project documentation during compaction. The idea is that the summary is grounded in the state of the project instead of relying only on whatever happens to remain in the conversation.

In total, I believe that this small compilation of other people’s work, together with a couple of additional instructions, allows me to interact with agents more smoothly and apply them more usefully to research in applied economics.

Application

If anyone wants to try the toolkit, Research With Coding Agents is now available on GitHub. The repository contains both the individual components and a predefined installer. Windows is the first supported release target. I have tested the Windows build and automated installer paths, but I still treat the project as early/pre-release. macOS and Linux source use, including basic Markplane operation, is experimental for now while agent and installer support catches up.

Now let’s discuss

If you want to share your thoughts about this article, or how you integrate coding agents into your workflow in academia or any other field, let’s discuss it on Bluesky or by email.

KS off - Bye