My first name is a random set of numbers and letters and other alphanumerics that changes hourly forever
Montreal
Joined December 2007
- Tweets1.2K
- Following136
- Followers550
- Likes296
Pinned Tweet
Principles of successful "factory" building
1. Don't build a factory, don't think of it as a factory, don't say the word "factory". It's a bad analogy and it puts the emphasis and goals at the wrong parts. Just erase that from your head. You are building focused automations, and getting compounding value from them.
2. Go slow, don't skip steps. If you start feeling a lack of control, that means its time to slow down, and reorient. You should have high confidence, trust, and be deriving value each step of the way. The only way to maintain your ability to judge is to go extremely incrementally.
3. Focus on verification before any other automation. This doesn't mean create-verification-skill from @poteto (although that is excellent and you should check it out), it means taking a step back and thinking about all the ways you could be confident your app works, and getting those into a good spot.
For example, the first goal should be a skill that is able to generate unit tests to the point that you are happy with them. If you aren't happy, change the skill, regenerate. Move on, generate another set of unit tests. Rinse and repeat till you build confidence, take bigger swings. Your first milestone is getting to the first atom of verification, which is a test suite you could confidently regenerate if you needed to.
4. Verification (in the broadest sense of the word) is your lever to building trust. This includes your type system, your linter, your architectural choices, infrastructure, test environments and isolation, benchmarking, and automated agent runs. Probably more stuff then that.
Focus on automating building that to world class levels. Verification is an easier problem to solve reliably then "all programming work", so start by solving for that. As that gets better, trust will go up. If you can get to the point where "verification passes means my app is functional" you are in the promised land. You wont get there, but that is what you are aiming for.
5. Only trust what is trustworthy. Don't start by saying "i want to fart out an idea and have the agent build it for me" that is the end of the road. Start with something like "when an exception is caught in prod, and the fix is easy, fix it automatically". Start at the edges, as you build trust you can build on top of that.
The devil is in the details, but this is my mental model of basically what has been figured out so far. Caveat emptor, I am not sitting at the pinnacle of the mountain and sharing my wisdom, it is largely based on conversations with people I trust further along then me, reading the tea leaves, and matching that to my own experience of successes and failures. Also, we're in a world right now that is changing month over month, I feel like I am trying to articulate current thinking, but the rules could all change tomorrow.
You can have whatever theme you like now extremely easily. I liked dark-copper from tern, asked the agent to look at folke/tokyo-night and build me a dark copper theme for neovim with the same care folke took with tokyo-night
Rex by @superlogical doesn’t have a Tokyo Night theme (the best theme ever created) but no problem. Asked an agent to extract the colors from Lumis - github.com/leandrocp/lumis/t… and it did, restarted the whole thing and done.
I mostly agree with this, I think its a preference thing though, and I think its less a love of the process / lack of process, but more downstream of the types of problems people work on.
That being said, I think the insight is right, and explanatory of the discourse.
Organizations tend to have two types of developers.
The first loves improving how work gets done: processes, tooling, automation. The second loves going deep on a narrow, difficult problems, and don't care about the process that much.
Both do valuable work. Teams need both.
The first type tends to be more enthusiastic about AI. Much of the work they do is making things repeatable, and repeatable work is easier to automate. Agents are great at that. Such devs have sophisticated software factories and other powerful workflows.
The second type can also be enthusiastic about AI, but not the same degree. They use it differently. Agents suck at deep, specialized, domain-heavy work when unguided. They work closely with an agent, steering and correcting it, rather than leaving it to run.
This explains some of the disagreement about what AI can do. People are doing different kinds of work and generalizing from their own experience.
In general, the first type tends to overestimate the value of process. The second tends to underestimate it.
Which one are you?
I think the anthropic s1 leak tells us 2 things
1. We’re still decently far from sustainable AI labs
2. The most impressive new number is the drop in their compute costs this year, that probably makes the future of token prices going up less likely.
I still think it’s distinctly possible that the labs limit people to 1 subsidized account per person, or restrict non team accounts for personal use only.
mbriggs retweeted
Initial iPhone Duo score: 9/10
Why? Same reason Gruber and Nilay are slagging on it:
1. It's an iPad mini you can carry everywhere
2. It eliminates any need to carry an iPhone
I have wanted to go iPhone-free for a decade. Calling it the worst iPhone but best iPad is awesome!
X is really pretty great as long as you stay the fuck away from political content. As soon you you break containment out of tech bubble stuff gets dark really quick
For awhile now I have been single threading focus, and I firmly believe that its better to play factorio for a few minutes vs start another task if you need to wait on an agent.
But I think there are several different modalities, at least right now
lvl 1: Code open, agent open, deep work. I think it depends on the work, sometimes you need to be in the weeds
lvl 2: Interacting with an agent at a higher level, but still very much in the weeds
lvl 3: Giving an agent a high level task, and having it orchestrate other agents to get there
I have been doing all 3 for about a year and a half. Over that time, its been a steady slant towards level 3, I keep doing that more. At this point, I think I may have bought my last laptop because the bulk of the work is at lvl 2 or 3, and you dont need a laptop for that.
Hot take: as good as @bot and Hermes are getting, tools like T3 Code and Rex may not be necessary for much longer.
The future isn't juggling a dozen threads and sessions. It's semi-autonomous agents working on your behalf.
Working this way taught me I don't have to shred my attention anymore. Spend the time upfront on rules, lints, checks, and verification, and you can actually trust the delegation.
The scary part is giving up some of being in the weeds. Once you do, the UI barely matters.
I don't think that the idea that the world will be turned into a utopia or destroyed, and that since utopia is more likely we should all embrace that is sound reasoning.
Wouldn't the most likely future be somewhere in between those two poles?
So here for what lauren is cooking up
i've been a bit quiet - working on a new companion skill that will help your agents draw these beautiful statecharts/diagrams + check them against the specs you made with /create-formal-verification-skill in pstack!
it now uses Pele from @kepano too which is why they look so good.
will release soon!
Its important to think of skills structurally. To do that, you need a pretty good grasp of logic and language. If you can express ideas and argumentation as a tree as well as linear prose you get what I am talking about.
The way to think of skills is as units of structure, similar to a package. Cross linking skills is a super power, don't ask the agent to invoke other skills, instead just link in markdown, and have those invocations be part of the parent skill call.
Understanding how LLMs respond to prompts is critical, things like how they will glom onto lists, be autistically literal, turn vibes into a matrix of invariants, etc. LLMs are not good at writing non trivial skills without a lot of guidance and iteration. This also makes it critical to eliminate unnecessary instruction. Will the LLM do what you want without adding it explicitly? Does it know something already you are explaining to it? Those types of things will degrade overall performance in the real world, and are way most skills out there are a net negative.
Because of the previous paragraph, it is critical to test skills. This is frustrating, time intensive, and expensive, but there is no other way. Try various prompts, see what happens. Make adjustments, based on what you find. Run evals when you can on major changes.
All of this together makes skills insanely hard and time intensive to build. And a new model or harness can mean going back to the test bench. But when you get it right.....
this is the raw basics, there is so much more. Descriptions are critical. Sequencing matters a lot. Leading questions can beat imperative instruction and vice versa depending on context. When do you extract references? When do you extract playbooks? When do you write code? When do you use subagents? What agentic patterns do you use, there are like 12 cannonical ones, do you know them?
mbriggs retweeted
Vibecoders, 𝗜'𝗺 𝗯𝗲𝗴𝗴𝗶𝗻𝗴 𝘆𝗼𝘂, add these two lines to your AGENTS.md:
"Cut taglines, helper text and secondary labels. If a screen needs them to make sense, fix the layout."
"Make the best decision that will elevate all three: the user experience (UX), developer experience (DX), and agent experience (AX) always, without breaking anything."
Maybe a hot take but I don't like grill.
When you are figuring out what to do, you should be able to flesh this out yourself. The act of fleshing it out should clarify / crystallize what is important, if this is even necessary, etc. That act should not have the clanker as a driver.
There is space for something like an exhaustive interview, but I think that should be framed more like thesis defence, it should question / strengthen something you are already strong on.
I think you should be able to go into that with something like a toyota A3 already defined (allaboutlean.com/practical-p…).
