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
- Likes277
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
mbriggs retweeted
i love writing. i never let agents write for me. whether it's docs, or tweets, or shitposts, or even prompts (okay maybe that one's harder as agents manage other agents)
there's a simple reason for that: i still strongly believe that writing is thinking. it's a skill i hope to never give up. it's also important to me that whatever i say is always authentic, mistakes and all. my favorite posts are the ones that i just full send without any editing
i suspect it also helps with prompting. being able to clearly express what i want, and knowing the vocabulary i need to be able to direct my agents does seem to make for more effective usage of agents. in the same way that engineers have an advantage when we prompt agents to write code, because we are intimately familiar with the words that make up the discipline
knowing the right word incantations to get an agent to produce a desired goal almost feels like spellcasting. as models get more capable, and that input box looks more and more like a magic box that can output anything, words become the interface between you and the genie
there may come a time when we give up the keyboard in exchange for brain-computer interfaces. but until then, i'm writing every word.
This has been living in my head all week.
- Good code a) works b) doesn't do things it is not supposed to c) is performant d) is maintainable
- a and b are more or less deterministic properties. But c and d are not, they are, and always have been, sliding scales based on context
- We now have tools that dramatically improve our ability to a-c at the cost of d
- Those tools also make it dramatically easier to maintain existing code
So if maintainability is a sliding scale, and our ability to maintain code has gotten dramatically easier, wouldn't our target points for maintainability change along with it?
This has happened with performance. When everyone has 512k of ram, caring about memory matters a lot more vs 8gb being normalized. Performance matters, but it is a sliding scale that moves with availability of resources.
It bothers me a lot that slack bloats to over 1gb of ram sometimes, but that has not stood in its way to being a highly successful and valuable product. If it bothers me because a clanker code design is nonsensical, but it falls within the thresholds of maintainability, does it matter? Isn't that more or less the same thing?
My personal bar for software is different from my professional bar. I will not use vscode because of how slow it is, that doesn't stop it from being insanely popular, and I understand thats a me thing.
I think the flipside is that greatness sometimes requires the non economical choice. Ghostty is a great terminal with far less features then most of its competitors, and @mitchellh spent years on it. It is not great because of how incredibly fast it is, it is great because the kind of person who cares about doing things the right way also will care more then they need to about how effectively it runs.
But it is also clear to me that most software does not need to be great. Most software needs to fall within the calculation of marginal utility. And I think thats a re-calibration we all need to make.
Sitting on this for longer, I think its worth teasing out an underlying message here that is highly valuable.
What we saw as "good code" was good for a reason, it accomplished a goal. Now we are living in a different paradigm, maybe there are other, cheaper ways to accomplish the same things that "good code" accomplished, but the way to get to those effects are highly different.
My mind is open to that possibility. I still think that she is going too far with "all code is slop", and the interesting part of this conversation is lost in that stance.