I’ve been using this general pattern - a custom cli app for deterministic tasks, skills for the agent harness, run the skills in the agent and it produces artifacts for you by using the cli and its own agentic reasoning - a lot lately for work. Things like “give me an executive brief of the activity in these teams backlogs over the last month” and in 5-10 minutes I have a few page doc I can read that is cited with the tickets it analyzed and I don’t have to go bug people or ask them to do yet another task for me, just make sure your backlog is updated and detailed like normal practice. It’s awesome and really fits a useful spot between pure agent usage (which is hard to get consistent results from on repeat tasks) and not having to build/buy a full blown app for every random thing.
We're not selling vibe slop, the "vibe slop" tools which work for one person enable of automation of tasks for the services we sell. Whether or not we use AI behind the scenes is entirely irrelevant to the service we're providing other than that it allows our margins to be higher and our speed of implementation to be faster.
I absolutely agree that it's not logical to think "oh we'll sell our AI stuff", that's the old model (which is just a variation on SaaS). I suspect a lot of HNers can't imagine a "product" that isn't code, but that's not at all what I'm describing.
The products that most people on HN have traditionally built are used by other companies to make money by allowing those processes to be scaled. AI, in many new cases, eliminates the need for a 'software' middle man. The case I'm describing is "I know how to make money doing X if only I could scale it up with out hiring people" and my offering is "I can scale it up without hiring people".
This is increasingly where I think the future of work is headed, and it's more than fine if you aren't convinced.
> You could take an editor session, a diff, or a pull request and automatically split it into a series of more focused commits that are easier for people to review. This is one of the cases where the AI can reduce human review labor
I feel this should be a bigger focus than it is. All the AI code review start up are mostly doing “hands off” code review. It’s just an agent reviewing everything.
Why not have an agent create a perfect “review plan” for human consumption? Split the review up in parts that can be individually (or independently) reviewed and then fixed by the coding agent. Have a proper ordering in files (GitHub shows files in a commit alphabetically, which is suboptimal), and hide boring details like function implementations that can be easily unit tested.
I think it's a mistake to believe that this money would exist if it was to be spent on these things. The existence of money is largely derived from society scale intention, excitement or urgency. These hospitals, machine shops, etc, could not manifest the same amount of money unless packaged as an exciting society scale project by a charismatic and credible character. But AI, as an aggregate, has this pull and there are a few clear investment channels in which to pour this money. The money didn't need to exist yesterday, it can be created by pulling a loan from (ultimately) the Fed.
And using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them at a time. Eventualy I hope that https://github.com/w3c/csswg-drafts/issues/9098 will land and we'll be able to use this saner way to do it.
C has no problems splitting programs in N files, to be honest.
The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.
At some point you mainly split for compilation time and to better orient yourself into the file, instead of having to seek a very large mega-file. Pointing the finger to some program that is well written because it's a single file, strlongly correlates to being not a very expert programmer.
I generally download from https://rutracker.org/ (need an account to search not for downloading). They have pretty much everything that you can imagine (not just films) and in proper quality too (BD Remuxes etc). There will be no scene releases here because they add russian/ukrainian dubs and subs to almost all films but that's a small problem.
The other one is Heartive which lists torrents from the DHT network with Magnet links https://heartiveloves.pages.dev/ You just click on the torrent icon in the middle top of the selected film and all the available releases will be listed in plain text. The only downside that you need to be familiar with the release tags
Last but not least https://nyaa.si/ if you have a slight interest in anything japanese from manga to anime to much more
Yes, I save an incredible amount of time. I suspect I’m likely 5-10x more productive, though it depends exactly what I’m working on. Most of the issues that you cite can be solved, though it requires you to rewire the programming part of your brain to work with this new paradigm.
To be honest, I don’t really have a problem with chunking my tasks. The reason I don’t is because I don’t really think about it that way. I care a lot more about chunks and AI could reasonably validate. Instead of thinking “what’s the biggest chunk I could reasonably ask AI to solve” I think “what’s the biggest piece I could ask an AI to do that I can write a script to easily validate once it’s done?” Allowing the AI to validate its own work means you never have to worry about chunking again. (OK, that's a slight hyperbole, but the validation is most of my concern, and a secondary concern is that I try not to let it go for more than 1000 lines.)
For instance, take the example of an AI rewriting an API call to support a new db library you are migrating to. In this case, it’s easy to write a test case for the AI. Just run a bunch of cURLs on the existing endpoint that exercise the existing behavior (surely you already have these because you’re working in a code base that’s well tested, right? right?!?), and then make a script that verifies that the result of those cURLs has not changed. Now, instruct the AI to ensure it runs that script and doesn’t stop until the results are character for character identical. That will almost always get you something working.
Obviously the tactics change based on what you are working on. In frontend code, for example, I use a lot of Playwright. You get the idea.
As for code legibility, I tend to solve that by telling the AI to focus particularly on clean interfaces, and being OK with the internals of those interfaces be vibecoded and a little messy, so long as the external interface is crisp and well-tested. This is another very long discussion, and for the non-vibe-code-pilled (sorry), it probably sounds insane, and I feel it's easy to lose one's audience on such a polarizing topic, so I'll keep it brief. In short, one real key thing to understand about AI is that it makes the cost of writing unit tests and e2e tests drop significantly, and I find this (along with remaining disciplined and having crisp interfaces) to be an excellent tool in the fight against the increased code complexity that AI tools bring. So, in short, I deal with legibility by having a few really really clean interfaces/APIs that are extremely readable, and then testing them like crazy.
EDIT
There is a dead comment that I can't respond to that claims that I am not a reliable narrator because I have no A/B test. Behold, though: I am the AI-hater's nightmare, because I do have a good A/B test! I have a website that sees a decent amount of traffic (https://chipscompo.com/). Over the last few years, I have tried a few times to modernize and redesign the website, but these attempts have always failed because the website is pretty big (~50k loc) and I haven't been able to fit it in a single week of PTO.
This Thanksgiving, I took another crack at it with Claude Code, and not only did I finish an entire redesign (basically touched every line of frontend code), but I also got in a bunch of other new features, too, like a forgot password feature, and a suite of moderation tools. I then IaC'd the whole thing with Terraform, something I only dreamed about doing before AI! Then I bumped React a few majors versions, bumped TS about 10 years, etc, all with the help of AI. The new site is live and everyone seems to like it (well, they haven't left yet...).
If anything, this is actually an unfair comparison, because it was more work for the AI than it was for me when I tried a few years ago, because because my dependencies became more and more out of date as the years went on! This was actually a pain for AI, but I eventually managed to solve it.
Because of the Ukraine conflict, the phrase "mission command" came to my attention. It's about C2 rather than leadership but another one of those gems we might filter out in our "Bay Area" (you're all terminally online Europeans / teenagers jk) bubble.
The idea of mission command is pretty simple. If you see an incidental opportunity that will contribute to the big picture and pursuing it won't compromise the objective of your orders, take it. IIRC they call it something like "scoped initiative."
If you see an incidental opportunity that you can't take because it would compromise your local objective, you escalate. Up the chain, in the larger scope, that incidental opportunity that would compromise the objective of the smaller unit may be addressable using some available resources of the bigger unit.
It works by deduction and beautifully because you get the best of both individual initiative and large-scale coordination. It's an example where from-first-principle CS and pragmatic emergent systems resonate because it's near a morally true optimum.
In the context of OP, knowing the objective of your larger 1-2 organization levels is all the transparency that is every necessary. Neurons aren't smart. Information flows in a network are smart. Don't trust people who start performing and asking for transparency because ninety-nine times out of ten, they can't do better with what they ask for but will make everyone else do worse by breaking the cohesion.
And finally I read OP. It's a vapid feel-good long-form tweet that is nothing compared to the comment section.
This response turned into more of an essay in general, and not specifically a response to your post, marginalia_nu. :)
Sharing information, to me, was what made things so great in the hacker culture of the 80s and 90s. Just people helping people explore and no expectation of anything in return. What could you possibly want for? There was tons of great information[1] all around everywhere you turned.
I'm disappointed by how so much of the web has become commercialized. Not that I'm against capitalism or advertising (on principle) or making money; I've done all those, myself. But while great information used to be a high percentage of the information available, now it's a tiny slice of signal in the chaff--when people care more about making money on content than sharing content, the results are subpar.
So I love the small internet movement. I love hanging out on a few Usenet groups (now that Google has fucked off). I love neocities. And I LOVE just having my own webpage where I can do my part and share some information that people find entertaining or helpful.
There's that gap from being clueless to having the light bulb turn on. (I've been learning Rust on and off and, believe me, I've opened plenty of doors to dark rooms, and in most of those I have not yet found the light switch.) And I love the challenge of finding helpful ways to bridge that gap. "If only they'd said X to begin with!" marks what I'm looking for.
I'm not always correct (I challenge anyone to write 5000 words on computing with no errors, let alone 750,000) or as clear as I could be, but I think that's OK. Anyone aspiring to write helpful information and put it online should just go for it! People will correct you if you're wrong[2] :) and you'll learn a *ton*. And your readers will learn something. And you'll have made the small web a slightly larger place, giving us more freedom to ignore the large web.
[1] When I say "great information", I don't necessarily mean "high quality". But the intention was there, and I feel that makes the difference.
[2] It can be really embarrassing to put bad information out there (for me, anyway). I don't want people to find out I don't know something and think less of me. But that's really illogical--I don't even personally know my critics! And here's the thing: when the critics are right (and they're often right!), you can go fix your material. And then it becomes more correct. After a short time of fixing mistakes critics point out, you get on the long tail of errors, and these are things that people are a lot less judgmental about. The short of it is, do the best you can, put your writing out there, correct errors as they are reported or as you find them, and repeat. I cannot stress how grateful I am to everyone who has helped me improve my guides, whether mean-spirited or not, because it's helped me and so many others learn the right thing.
Don't use all-MiniLM-L6-v2 for new vector embeddings datasets.
Yes, it's the open-weights embedding model used in all the tutorials and it was the most pragmatic model to use in sentence-transformers when vector stores were in their infancy, but it's old and does not implement the newest advances in architectures and data training pipelines, and it has a low context length of 512 when embedding models can do 2k+ with even more efficient tokenizers.
Shrinking is by far the most important and impressive part of Hypothesis. Compared to how good it is in Hypothesis, it might as well not exist in QuickCheck.
You could start with the guy who was there, and coined the term, Arnold Toynbee (not to be confused with his similarly-named nephew, who writes the preface to this edition), The Industrial Revolution, developed from a series of lecture notes 1880-81:
There's a series edited by Joel Mokyr of Northwestern University and published by the Princeton University Press, "The Princeton Economic History of the Western World" with a number of highly recommended titles:
R.U. Ayres (Robert) has written a number of articles and essays looking at technological development which are IMO highly underrated.
The question of why the IR arose in the UK has been called "the Needham Question" (especially in contrast with why it did not arise in China, which has a long and deep history of technological innovation). I'm not aware of any single treatment of this, and Needham's own Science and Civilisation in China despite its excellence in cataloguing China's accomplishments really doesn't serve as a concise answer either.
`bcrypt` is probably the "standard" in the sense that it has the widest adoption, but since 2015 [1] the "standard" in terms of what you should recommend for new work has been `argon2id` (and you can find parameter recommendations here [2]).
This is a great example of why `pull_request_target` is fundamentally insecure, and why GitHub should (IMO) probably just remove it outright: conventional wisdom dictates that `pull_request_target` is "safe" as long as branch-controlled code is never executed in the context of the job, but these kinds of argument injections/local file inclusion vectors demonstrate that the vulnerability surface is significantly larger.
At the moment, the only legitimate uses of `pull_request_target` are for things like labeling and auto-commenting on third-party PRs. But there's no reason for these actions to have default write access to the repository; GitHub can and should be able to grant fine-grained or (even better) single-use tokens that enable those exact operations.
(This is why zizmor blanket-flags all use of `pull_request_target` and other dangerous triggers[1]).
We are also working on a database linter.
Currently focusing on Oracle but we will support Postgres soon too.
Rules can either run queries against the DB (e. g. foreign key without index) or use our parser to check code SQL, PL/SQL, and pgSQL soon (naming standards, security and performance issues, etc.). We currently have over 280 rules [1]. The tool runs as a lange server during development or as a CLI so you can use it in your automations. Its more enterprise focused, an admin can create configurations that get applied to all developmers.
They're blue because computer scientist Ben Schneiderman made them blue using research from 1985:
" In 1985, a group of students at the University of Maryland, mentored by computer science professor Ben Shneiderman , conducted a series of experiments to study the impact of different hyperlink colors on user experience. They were eager to determine which color would be the most effective in terms of visibility and readability.
The experiments revealed interesting findings. While red highlighting made the links more noticeable, it negatively affected users' ability to read and comprehend the surrounding text. On the other hand, blue emerged as the clear winner. It was dark enough to be visible against a white background and light enough to stand out on a black background. Most importantly, it did not interfere with users' retention of the text's context."
Mozille should really do better research before posting histories like this. It's easy to overlook the impact of academic research in tech.
There's an interesting rabbit hole to go down for English words from Latin "spirare" - to breathe, and how it connects air and breath of life, spirituality. We get respiration (re-spire, re-breathing), inspire (blowing on something, figuratively breathing life/fire into it), expire (breathing out the last breath of life), spirit (a vital substance of life), conspire (to breathe together, speak similar thoughts).
etc. Words that were almost literal Latin that are now more figurative English based on a sort of French / medieval version of the Latin version. [edit: just remembering that the rather Germanic and plain "Breathe on me breath of God" used to give me the image of someone going "huuuhhh" on their spectacles before polishing them. The next bit is "till all this earthly part of me Glows with thy fire divine" so it is supposed to be exciting and soul-sparking. I only feel the poetic imagery of "fill me with life, blow on the embers of my soul, oh life giving wind-deity", through Romance *spire* words not Anglish *breath* words. "inspire my spirit(2) through respiration, you spiritual spirit(1)"]
The idea of an IX, or IX peering LAN is simple in concept. It is a LAN (a flat, layer2 network), to which multiple ISP's can plug in routers.
Like your home LAN might have 192.168.0.1 = router, 192.168.0.2 = laptop, 192.168.0.3 = phone etc, a peering LAN will have things like 195.66.224.21 = HurricaneElectric, 195.66.224.22 = NTLI, 195.66.224.31 = Akamai, 195.66.224.48 = Arelion etc ...
So instead of all these ISP's that want to exchange traffic with each other having to assign ports and run cables in a full mesh (which quickly would get out of control), everyone connects to the "big switch in the middle" with that peering LAN on it, and they use that.
Back in the day, that might have been an actual single big switch, or a stack of switches. Now IXP infrastructures are much more complex, but the presentation to the end user is usually still a cable (or bundle of cables) that goes into something that looks to them like a "big switch".
There is a LOT more to know about this space (Peering vs Transit, PNI's, L3 internet exchanges, what Google are doing by withdrawing from IXP's), but I wanted to write a comment that didn't turn into an essay.
DK (Dorling Kindersley) and especially Stephen Biesty's books use it, a lot of software in the 90s used it. I wouldn't say today it's particularly interesting or special objectively, but I personally like it mostly because of nostalgia.
This is a pretty good description of RGA (Replicated Growable Array). Which is a list & text CRDT that works pretty well in practice. Automerge used to use this algorithm for text editing, before moving across to FugueMax.
This algorithm has another obscure downside: It has interleaving problems if you insert items backwards. If two users do a series of inserts in reverse order, their inserts will get interleaved in a weird, unpredictable way. Eg, if I type "aaaaa" (as a series of prepended inserts) and you type "bbbb" in the same way, we can end up with "ababababa" or "aabbabbaa" some combination like that. We generally want CRDTs to be non-interleaving - so, "aaaaabbbb" or "bbbbaaaaa" should be the only possible results.
This problem is fixed by FugueMax, described in "The Art of the Fugue" paper[1]. If you're thinking of implementing a text CRDT, I recommend starting there. Fuguemax is a tiny change from RGA. We swap out the sequence numbers for a "right parent" pointer and the problem goes away. Coincidentally, the algorithm is also a 1 line change away from Yjs's CRDT algorithm.
And its really not that complicated. Most of the complexity in the fuguemax paper comes about because - like with RGA - they describe the algorithm in terms of inserts into a tree. If you ask me, this is a mistake. The algorithm is simpler if you primarily think of it as inserts into a list. (Thanks Kevin Jahns for this insight!) I programmed Fuguemax up live on camera a few months ago like this. You can fit a simple reference implementation of fuguemax in ~200 lines of code[2]. (The video is linked from the readme in that repository. In the video I explain the algorithm and all the code along the way).
