ionetan

With agents code has gotten really easy to shape, like a fabric. If you'd want to build something rigid, like a tipi, it would require you to introduce sturdy architectural structures to stretch out the fabric of agentic code.

Data and its shape is one such rigid structure. It will stay with you long after the code around it has been replaced. You do want to be intentional about it and build intuition for it.

Once you have that in place, you can spin out a web of agentic fabric across it, and pin it down with pegs/tests.

I built an issue tracker that persists issues as code, which you can run in a separate, linked repo, so you don't need to litter your code repo. If you do run it the same repo it puts it in a state branch, so it isn't really in the way.

https://ljtn.github.io/epiq/

One benefit of persisting issues as code is traceability of intent and keeping track of vision drift. Epiq enables this via time travel, so you can trace the board evolution by going back in time, filtering for specific sessions, etc.

Funny how comments like this go dim...

Good point. I also think that the training data is different in this regard. It has trained on (mostly) verified, correct code, but when in comes to free text it has trained on a lot of unfounded opinions.

I think it is more about comprehension. It reveals that AI does not actually understand what it does. It gets code right mostly because it is probabilistic and has seen enough sound precedents to land in something that works, but it does not come from an internal comprehension.

AI has a way of using abstract language, sounding impressive and eloquent, but in reality it is mostly incoherent fluff. You can see this in humans too. Some politicians and academics are good at expressing themselves in clever ways but when you actually try to parse what they say it makes no sense what-so-ever.

I think there’s something to be said for distributed systems that work equally well online and offline. I’ve built an issue tracker that uses Git as its transport, with no central broker or service and eventual consistency.

That means agents can collaborate on issues locally without needing network access to an external tracker, which could help with the sandboxing problem. You can then sync when it is deemed safe.

It’s called Epiq on Github.

I read DHH, and started wondering if he is ok :D

Built an issue tracker like that, that persists state as an event graph in your repo in a dedicated branch. It is vendor agnostic and works offline:

https://ljtn.github.io/epiq

Yes. Started off cleaning school toilets. Went to a bootcamp 10 years ago, taught myself the rest, got to sit in fancy offices and drink coffee, but always felt outta place. "You can take the kid out of the ..." and so on. Guess I gotta pick up the broom again.

Yeah, I guess it is quite hard to tell where the line should be drawn, and we probably need to rely on human intuition and experience. One thing that the article left out that I have thought more of afterwards is that the classification would need to be relative to the enterprise as a whole. So if you are building a gimmick app for a birthday party you might just vibe code the whole thing, including its "core", but if you are a building business-critical sales system for a major company, the impact of something going wrong would rate the core at the upper end of the scale.

Yeah, I think most success stories in AI seem to come from ports, or from projects where a deliberate architecture has been laid by humans who understand it, and AI is sprinkling features on top. Adding features and drivers to a Linux distro seems like one of those places where AI is uniquely well positioned to bring value, because the foundation has already been laid. I wrote a post the other day on how agentic code still needs this kind of architectural foundation to not end up in a tangled mess. It might interest someone: https://ljtn.github.io/epiq/blog/the-soft-fabric-of-agentic-...

I think understanding the details is still important. However, it moves toward the more central parts of the application, where the risk is higher and agentic workflows can’t be pushed as far. I think the author may benefit from specializing in those parts of the system where unattended agentic work is still too risky.

Wrote a post some time ago on how we'd be helped by segmenting and ranking the domains of our systems so we can be deliberate about where we stop short of full automation: https://ljtn.github.io/epiq/blog/cost-of-cognitive-debt.html

Hey, thanks for the kind words. I need to get to the bottom of Epiq not showing up in search engines! It doesn't help that Skoda released a car model with the same name a month or so after :D. Totally understand the large corp dynamics!

Good stuff. I share this view fully. I've been working on a project, which I am happy I had no agentic help on for the first year. When you lay the architectural foundation you need to start with a vision, derive constraints and then map a solution to all of them. This takes a level of intentionality that agents don't have. Probabilistic models will work against anything that is unconventional, so they tend to favor low-value solutions that have already been seen.

Wrote up the longer version of my journey on that project here:

https://ljtn.github.io/epiq/blog/on-the-soft-wet-fabric-of-a...

Would you be more inclined to use Epiq? It is instant, as every write is local, synced over Git. It is built with engineers in mind. I'm its author for disclosure.

It might be you'd like Epiq. It is an issue tracker I built that actively does what it can to not be another Jira. It has way less fields and configurations per ticket (description, tags, assignees, attachments, comments), and it integrates with your code/repo, it is local-first and distributed so super fast. https://ljtn.github.io/epiq/

I've built a tool in this domain that might interest you. Its an issue tracker called Epiq that stores its state as an event graph in your repo, so it doesn't require a separate service or migration away from Github. Works well for solo devs:

https://ljtn.github.io/epiq

It lets you trace how individual workflows evolve over time through board replay, and it has inline-diffs in the tickets, which together with filtering helps give an overview. Would this be the kind of thing you had in mind?

Leads me to think of a related topic, the Cost of Cognitive Debt. I think it is about time that we start to quantify what it means that we no longer grasp major parts of our systems and infrastructure. Once we quantify it, we can start to reason about how to address it.

I explored this concept in this post:

https://ljtn.github.io/epiq/blog/cost-of-cognitive-debt.html

You may be interested in Epiq. Its is an issue tracker sourcing state from a log in state branch.