My first name is a random set of numbers and letters and other alphanumerics that changes hourly forever
Montreal
Joined December 2007
- Tweets1.2K
- Following133
- Followers548
- Likes279
Pinned Tweet
New workflow:
1. talk through the problem with the agent
2. read the code
3. implement at least the first draft of the hard part
4. ask the agent what I got wrong
5. tell the agent to do the rest
6. review the full changeset
I find I am able to retain _far_ more judgement.
The thing that makes me really envious of people at gigs with unlimited tokens is how expensive skill evals are. You gotta do them, but MAN are they expensive
mbriggs retweeted
ok I think the main thing we've learned this month is that computer programs get faster whenever they're ported to another programming language, and all we need to do is keep porting back and forth until every program only needs one CPU cycle to finish
I copied the principle-* pattern from pstack awhile ago, this is invocation counts from the last week (i just added question-invariants today)
I am very bullish on elixir right now. I feel like the biggest knock against it is how its kind of esoteric, but I feel like with agents that doesn't really matter that much anymore.
I was a framework believer in the before-times. It's not because I don't know how to build without a framework, its because machinery thats needed in every app is a lot of noise, and it makes it easier to see the app when you can separate out the machinery from the logic. Every program has an internal language, a framework lets you see that clearly.
There are good and bad frameworks. Bad frameworks don't let you see the language, you only see the framework. They box you in, so its all wonderful when you are on the happy path, and you fall off a cliff when you deviate.
A good framework is built on a tower of abstractions, and exposes all the intermediary pieces to you in a way that you are able to reasonably be able to consume them yourself. A good framework extends itself to build itself.
In the agentic era, I think the architecture that wins is one that provides clear rules and constraints for the agents to work within. The definition, extension, and enforcement of those rules and constraints is extremely hard work, but it provides sophistication, standardization, and enforcement to the rest of the app. Agents _love_ to reinvent the wheel over and over and over again, that gets hard if the rules are pre-defined and they are coloring within the lines.
I don't think that the future is zero abstraction, low level for everything. That can work, but it is a much much much harder job to figure out how to wrangle agents in an environment of unlimited possibility. The good frameworks from the before-times I think are the best set up for extension into the world of agents.
Wouldnt it be funny if AshTypescript + inertia is a less painful and more productive full stack react vs next / remix?
This is one of my principle skills (using the idea from pstack). I think this is a general agent problem, but I may make it worse with my prompting / verification cycles. I have this cross linked a lot through my skills
gist.github.com/mbriggs/3611…
I have been using this judge skill for awhile and really like it. I cross link my skills heavily, but even without the others you should be able to get the jist :)
gist.github.com/mbriggs/12c0…
I am probably really late to the party here, but things like @AshFramework are REALLY good for agents.
Really been digging elixir so far
Instead of using worktrees, i have 3 big orchestration runs happening in the same repo. I asked them all to communicate and coordinate through a markdown file in the root of the project, nothing more then that. It seems to be working REALLY well, they are coming up with processes and practices, giving each other heads up for things they think the others would find helpful, etc.
mbriggs retweeted
Want my advice on becoming a better builder, a better orchestrator of agents, a better engineer?
Build intentional boundaries into your life. Take breaks. Keep a sabbath. Make room for rest and time away from screens.
Protect your time to disconnect as ruthlessly as you protect your time to focus.
You need both to do good work.
mbriggs retweeted
how do you trust your agents' work more? copy this post/link and give it to your @bot or agent!
1. codebase improvements: this is just good software engineering - better architecture, stronger types and invariants, clear boundaries. agents love to copy what exists and take the shortest path, so make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again.
2. static analysis: lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time.
3. prose: comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill.
4. human review: the hardest to scale. at the rate agents land code, it's pretty much impossible to thoroughly review every PR, so spend that effort on the highest leverage point, designing an environment where agents do the right thing by default.
this forms an inverse pyramid: you want most of your effort at the top, least at the bottom. codebase improvements are deterministic, making it more token efficient, and lets you sleep more soundly at night.
install github.com/cursor/plugins/tr… and create a new Project:
1. look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture
2. use /recall on my past transcripts to learn how i steer agents
3. /poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data.
4. before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me
