zerotolerance

There is a lot of "my" floating around in this article. I always love getting peeks into experiences with this sort of thing, but I think the "mys" highlight something I've seen every day. These agents are really great at bespoke personal flows that build up a TON of almost personal tribal knowledge about how things get done if there is any consistency to those flows at all. Doing this in larger theaters is much more difficult because tribal knowledge is death for larger teams. It drives up the cost of everything which is why individuals or extremely new small teams feel so much more productive. Everything is new here and consistency doesn't matter yet.

Apple has some of my favorite vulnerabilities, most notably GOTO Fail: https://www.imperialviolet.org/2014/02/22/applebug.html

But today people can just vibe code their own sudo "with blackjack and hookers!"

/s

Really though, it is remarkable just how high we've built this towering house of cards on the selfless works of individuals. The geek in me immediately begins meditating on OSS funding mechanisms I've seen in the past, and what might work today. Then I remember that I don't believe it can work, but hope desperately that people like Todd can keep paying rent and continue getting some satisfaction from the efforts.

Pure anecdote. Over the last year I've taken the opportunity to compare app development in Swift (+ SwiftUI and SwiftData) for iOS with React Native via Expo. I used Cursor with both OpenAI and Anthropic models. The difference was stark. With Swift the pace of development was painfully slow with confused outputs and frequent hallucinations. With React and Expo the AI was able to generate from the first few short prompts what it took me a month to produce with Swift. AI in development is all about force multipliers, speed of delivery, and driving down cost per product iteration. IMO There is absolutely no reason to choose languages, frameworks, or ecosystems with weaker open corpuses.

I always like finding people advocating for older sage knowledge and bringing it forward for new audiences. That said, as someone who wrote a book about Docker and has lived the full container journey I tend to skip the containerized build all together. Docker makes for great packaging. But containerizing ever step of the build process or even just doing it in one big container is a bit extra. Positioning it as a build scripting solution was silly.

Google created two kinds of value: content discovery via connection (value to the consumer), and market reachability for advertisers. Oh, and also the world's most inconvenient spell check.

AI proposes to solve: a content supply side problem which does not exist, and an analysis problem which also only maybe exists. Really what it does in the best of cases (assuming everything actually works) is drive the cost to produce content to zero, make discovery less trustworthy, make the discovery problem worse, and launder IP. In the best case it is a net negative economic force.

All that said, I believe the original comment is about the fact that the economy exists to serve market participants and AI is not a market participant. It can act as a proxy, but it doesn't buy or sell things in the economic sense. Through that lens, also in the best case the technology erodes demand by reducing economic power of the consumer.

That said, I'm stoked to hear about the next AI web site generator or spam email campaign manager. Lets setup an SPV to get it backed off-balance sheet.

It is such a pure thing when an engineer looks at the world and is surprised, frustrated, or disappointed at behavior at scale. This is a finance game which in itself is a storytelling / belief based system. It might seem like math, but when you're playing on the growth edges valuation is really is about the story you tell and the character of the players. Thats only worse when people stop caring about cashflows or only expect them to happen "in the future" because that makes it someone else's problem.

Because it isn't a car company, it feels more like a fraud funnel for retail investor funds into multi-billion special dividends and bonuses for Musk.

Nobody is buying them today. But these shaky clumsy versions didn't exist even a few years ago. The hype promises these things tomorrow, which is obvious BS. But the better they look today the more investment will be poured into their R&D which accelerates real improvement, which accelerates investment, etc.

Generalist robotics are all about minimizing or at least front loading some portion of retooling cost, minimizing overhead associated with safety and compliance, and being able to capitalize what would have otherwise been human opex. Those pressures aren't going anywhere.

The most difficult part is managing the delivered / processed state and ordered delivery. Consistent ordering of receipt into a distributed buffer is a great challenge. Most stacks do that pretty well. But deciding when a message has been processed and when you can safely decide not to deliver it again it is especially challenging in a distributed environment.

That is sort of danced around a bit in this article where the author is talking about dropped messages, etc. It is tempting to say "use a stream server" but ultimately stream servers make head-of-line accounting the consumer's responsibility. That's usually solved with some kind of (not distributed) lock.

Kafka is a wonderful technology that punts on the most difficult part of distributed stream processing and makes it the consumer's problem.

There are good things about this article. It seems like a nice intro for people who have never worked on this type of system. And I'm always happy to celebrate someone's win. But I feel like it was missing an overview of what actually makes distributed queues difficult (the distributed part) and why you probably don't need them if you can survive without them.

Seems like a feature. This was always going to be the case. Just like how it was cheaper to train those models on billions of prior works than to have generated or paid to generate all those works in-house.

Did he need it to prove a business viable if there were already players in the market? No. Do you ever need to validate that people would switch providers of a commodity product or service if presented with a cheaper option? Also no. What did he learn then, that he can create a partial solution that people might pay for initially (no data on renewals) but will ultimately have to actually hire people to build a real product which will eat at his differentiator (price). Wait until he decides he actually has to spend money on marketing.

The good news is that with each of these we get to "validate" that having an idea still isn't worth much without the ability to actually execute.

It is trivial to create a digital picture of a false ID.

"Judge says training Claude on books was fair use, but piracy wasn't."

The coding time is irrelevant and always has been. Time writing code has never been the high cost or challenge especially so in blue sky / green field development cases like those described in all these articles. And as far as ops processes go, we're already lightyears faster than we were even a decade ago. I could rant about ITIL and these integrated flow fantasies, but even that is a distraction.

The bulk of engineering time is spent engineering (not writing code), researching the right thing to build, reviewing plans with product ownership, considering operating context and constraints, adjusting designs and redeveloping based on learnings. Writing code is the easy part when everyone leaves you alone and you just cook. Those meetings aren't going anywhere because at the end of the day it takes a lot of back and forth to even come up with a relatively stable spec.

I agree that ops automation is important, but its hard to take this article seriously.

Much of the work "security, keeping things up and running" that AWS does behinds the scenes is bolstered due to the nature of running a massively complicated multi-tenant cloud. Doing exactly what you need in-house is orders of magnitude simpler, but has a deeper knowledge requirement. The cloud is a powerful way for companies to commoditize skill.

AI is a race to the bottom, and a race to over-spend. Seeing this as competition will bankrupt the players, make enablers rich, and end up killing a lot of people when the need to bolster confidence in its capabilities overrules basic common sense.

Ah, the old "if you have nothing to hide you should let us surveil and search you as much as we want" argument.

There is a lot of idealism wrapped up in this statement and just because we think something should be does not make it truth.

They don't actually need to achieve AGI or ASI. All they need to do is pump expectations around growth to the point where the public will believe all the BS about their terminal growth rate to dump their equity on the open market.

I'll go further and say that audiobook production is not cost constrained unless the marketable value of the work is extremely low. What we get is cheap audiobooks for which there is no / low demand, and what it costs us is the decimation of the limited audiobook economy. That's happening at the same time as a billion new / fully generated works hit the market and overwhelm our ability to curate the supply and provide meaningful discovery. Again, more spam. Then AI spam to promote these valueless works. Awesome.

The premise of this argument is false. Pre-agriculture people were food supply constrained. Nobody is audiobook or other entertainment supply constrained today. And worse, modern farm produce is effectively worth zero. In many cases farmers are paid NOT to produce specific goods. And those who do MUST produce at purely artificial levels as to require the use of unsustainable, patented, and specialized chemicals or GMOs to break even. This entire line of research leads to spam and waste.

This is a soft layoff not some BS productivity hack. They've also kneecapped comp.

There are a few tragedies in the Docker story, but at least two are specifically tied to naming things. First, Swarm (mode) because by the time they released Swarm (mode) the world had already taken a collective dump on Swarm (the proof-of-concept). Even in 2024 most of the time people talk about Swarm and start dumping on it they're actually talking about the proof-of-concept architecture. Second, they should never have called the subcommand "build." It isn't building anything. In this case "build" is performing a packaging step with very raw tools. But the minute they called it build people started literally building software INSIDE intermediate container layers on the way to assembling a packaged container. Dockerfile is about as weak of a build tool as you could possibly ask for. Zero useful features with respect to building software. But Docker named it "build" and now we've got Dockerfile calling compilation steps, test commands, and dependency retrieval steps.

People doing all the work of dependency fetches, code builds, and test execution inside ephemeral environments never designed for building software within.

It is difficult to overstate how important advertising is in every economy.

> Consent to arbitrary termination of the account at any time for any reason.

Imagine having your digital identity for interacting with the government terminated arbitrarily.

Unfortunately, this mission reminds me of "This video is for educational purposes only." There is no real way to enforce use restrictions.