Ticket management in production

This week was my regular reminder of the strengths and weaknesses of agentic coding: a couple of valuable features implemented quickly, and a lot of cleanup work was done on last week’s work. No novel ideas from me on this contrast! I think it’s just continuing proof that throwaway or personal tools can be built extremely quickly, while for “real products” the payoff using AI to compliment human coders not replace them (at least at startup scale).

The first valuable feature was importing Linear tickets. Straightforward to implement: a script to download the issues from Linear, and an addition to the acme CLI to import them into Ticket nodes in ACME. Simple, fast, but hugely valuable! I’ve been using ACME consistently instead of Linear for a few days without issue.

The second was “query provenance”, adding a link to each component that enables the user (me) to see the actual SQL query or queries run by that component. A developer feature more than a user feature, born of the many times that looking at the SQL query was the first step to diagnosing an issue. It’s already made obvious where ACME is being very inefficient in terms of quering the backend.

On the cleanup work, the most time consuming effort was overhauling the “NodePage” component, which is intended to be the default way of viewing a node in the knowledge graph. The root cause of the cleanup work is developer error: I didn’t specify clearly how the page should be constructed, how I wanted it broken down into sub-components, the importance of encapsulating the functionality so that a NodePage can be used without the developer having to be deeply familiar with its code.

It’s an interesting example for me, though, since I did not have a clear design in mind when doing the first NodePage. It is through building and using the page that I started to develop opinions about it. Even setting aside the AI factor, this is similar to a lot of product development: you need to somehow test or prototype ideas as part of planning, not after.

The “accounting question” then becomes: was building the NodePage with minimal guidance a good prototyping exercise (since it didn’t take any effort at all really), or a costly re-work exercise? It could easily be taken as either, but in this case I’ll be honest with myself and say it was costly re-work from a gap I should have anticipated.

With a working ticket system, though, I’m now enjoying the payoff: I can reduce the number of issues in my Linear account and get myself back on the free tier :)

More seriously, I’ve got a much clearer idea of ACME’s design, and how to make it more modular. That will make it easier to reason about and maintain. This feels broadly similar to my experience with Mock Machines: on a truly greenfield project, at the cost of more re-work than I’d need for code I wrote myself, I can get a lot of clarity on the overall product. The test of this will be, can I therefore give that clarity to the coding agents?