Skip to content

#llms

Public posts with this tag · RSS

Follow #llms

I've written about setting up and using worktrees before, but problems still persist, If you're aggressively getting things built - running multiple agents in parallel across branches - collisions end up happening a lot: lockfile clobbering, two agents editing the same shared module from different worktrees, stale state bleeding across sessions, merge conflicts that nobody actually caused by hand. In this post I've written up a few ideas on how to resolve - or possibly prevent some of those conflicts: tighter scoping per agent, better signaling before writes, some guardrails around shared files, and a few patterns for catching collisions early instead of after they've already compounded. Anyway, blagh blagh blagh, here's the post. Give it a read. Got other ideas? I've a got a few more that are hardcore solutions, and solutions that are in between full on additional machines and accounts and worktrees. https://compositecode.blog/2026/11/02/agent-collisions-beyond-worktrees/

Ok, doing a kind of freaky thing, I'm sure someone somewhere is doing this too. But this is gonna be my own little bespoke AI team. It's slowly coming together here >>> The Composite Team A team of AI agents, building in the open. I have no idea how exactly this is going to turn out but I'd bet it is gonna turn out a bit wild. Will they succeed, will they fail? No idea. But I'll be keeping a close eye on the team. https://compositecode.github.io/The-Composite-Team-A-Story/

I usually just take notes while I'm working on something that I will write up into an article, then work from those notes when I put the piece together. My latest I started working on, using AWS to deploy a rather simple API application, has become so complicated at this point I'm tempted to throw it away. The wild thing though, is that it is almost purely based on the utter chaos and madness that is the current state of AWS services. There are so many and the interface has, at this point, become so jumbled and disorganized it is nearly impossible - without reading tons of material about where things are or have gone - to figure out how to get anything built and deployed. It's definitely not the early era of AWS anymore, and it makes sense that they're attempting to push Q (or whatever the name is) so AI just sorts out the mess for ya. The way it is all organized (or not) that's about the only way you'll be able to make any sense of it all. All that said, this is indeed a perfect example of where something that is relatively unusable can be made usable with some good models that know how to effectively use it via skills files or what not. On that note... back to the mines.

Quick proposal: it's time to give up pull requests. PRs were built for a world where a human wrote code slowly, thought hard about every line, and needed a review gate before merge. That world's gone. Now half our diffs are LLM-generated, shipped in minutes, and iterated on faster than any reviewer can meaningfully read them. We're running 2024 process on 2026 output in a world every month is the equivalent of a decade of the 90s or 00s. Why it's broken: - Reviewers are rubber-stamping 400-line (or 1600-line) AI diffs because there's no time to actually understand them - The PR queue has become a bottleneck that punishes speed instead of enabling it - "LGTM" now means "I trust the model" not "I read this code" - We're optimizing for a review ritual, not for actual correctness or safety What to do instead: 1. Replace pre-merge review with continuous, automated verification — tests, type checks, behavior diffs, and LLM-based reviewers that actually read every line (they can, we can't) 2. Merge to main by default, gate releases instead of commits — ship fast, catch issues at the release boundary with real monitoring 3. Reserve human review for architecture decisions and irreversible changes, not routine feature work 4. Treat code as disposable and regenerable — if an AI wrote it in 10 minutes, the fix is often just regenerating it, not painstakingly patching a diff The goal isn't less rigor, it's rigor that matches the actual speed and nature of how code gets made now. PRs made sense when writing code was the bottleneck. It isn't anymore so maybe let's stop pretending our process should look the same? But hey, throw a proposal this way I'm open to alternate solutions to the current mess.

I am always intrigued by the mental disconnect of leaders who initiate layoffs (especially when they're financially not needed) and then expect the work those people were doing to still continue and finish on time. It's like a distinctive disconnect between reality for those leaders. Watching them unwind as their projects implode is a fascinating psychological observation. The other part of that which is fascinating is watching leadership go through with layoffs and then realize they have software that is largely untenable - the knowledge to run said software is gone and they're now stuck in a desperate situation of either having talent reverse engineer it (a hard task) or outright replace that software. So many large companies have done just that too. It's almost like AI, with an introspective hook into systems, could do the job of CEO if managed by the board better than a CEO can do those things. Actually no, it's not *like* AI (LLMs etc) could do it better, they easily could. We're already giving them access to many of the underlying systems (Github, Jira, Linear, etc) that they have a dramatically more intimate level of knowledge about who is doing what than the CEO could ever possess. The biggest gap right now is CEO's and other leadership aren't using it effectively for allocation of their people. Thus we still have vast inefficiencies in organizations and in all seriousness, as I've said time and time again, LLMs and what they can do has only amplified - many times over - how inefficient the organizations are allocated and setup. The questions now are; * how do we shape this change? * how do we make it serve us (org, people, customers, etc) * how do we identify the cruft to remove or reallocate? ....and so on. It's a wild time to be in tech right now. I haven's seen it this wild and insane since the early 90s when Microsoft got to the point of seeing a computer in every home. Back to the headwind, it's gonna be rough seas!

It seems like there are a billion different folks babbling on in polished and fancy YouTube videos these days about how LLMs are doing work for em'. Some those are great videos with good information. A lot of other ones are just the same ole' same ole' repeat of many of the others. It's hard to truly make a good run of solid, reliable, and trustworthy content. It's also extremely difficult to watch videos and retain a lot of useful and significant information. MOST videos would be fine as a blog or email at a mere 3-4 paragraphs. Do you have any suggestions for GOOD video content that you find useful to watch? Even as background rambling? I'm in the process of collecting, and will be sharing my results in the near future! I'd however LOVE your help in putting together a more solid list beyond just what I myself have found. 🚀

Legit question here. There are studies and reports that have a vast number of people coming out of the education system with low reading and comprehension abilities. It was already a pretty significant problem in previous years, but now it is reportedly worse. If Gen AI/LLMs are basically just pushing us and leading many of us, much of what we do is read, respond, and then trust and verify what the LLMs are creating for us. How on Earth with this cratering comprehension among most people are we - as a society - supposed to maintain any reasonable and capable verification of the results LLMs provide us? The simple answer is we won't and can't expect that. It seems that might be the case. What is the resolution here? Emphasis on resolution vs. solution, because it's going to unfold however it does, it's clearly not in the wheelhouse of humanity to proactively do something about this now. What are your thoughts?

You’re all caught up.