Related: this article was very unilkely make it to the Hacker News homepage thanks to the clickbait headline, but I recommend reading it anyway: <a href="https://twitter.com/jsnnsa/status/2115623382721126826" rel="nofollow">https://twitter.com/jsnnsa/status/2115623382721126826</a><p>It describes a team spending 30x payroll on tokens - $3,000,000 in token spend per month - building a multiplayer game where incidents and bug reports from users are passed directly to Fable 5/5.1 agents who then act on them and deploy the changes to production.<p>"We consider it an outage if we don't ship every hour"<p>It's worth reading because it's either a complete disaster or a glimpse of the future, or quite possibly both.
Was thinking of that exact article while I was reading this, we must be following the same folks. Highly recommend folks reading it, even if it feels insane in some regards it's a fascinating look at what the limits of this stuff could be and I found myself with a lot of new ideas to consider after reading it. Interesting times.
It this point, a whole lot of teams have been leaning into AI-first, not-entirely-reviewed code since around March this year.<p>That means we are already 6-8 months in, and not far from having a full year of experience of what that actually looks like, albeit weirdly influenced by the increase in model capabilities during that period.<p>I'm looking forward to those retrospectives. Did this turn out to work OK for the teams doing it? What were the biggest failings and/or surprises? With hindsight, did this produce good quality software?
I think the biggest shift is in predictability. Will something be done today, next week, or next month - nobody knows. Will we converge on a bug free state? not sure.<p>So far AI works great at fast moving work which you will probably recode or throw away in a month or two anyway (e.g. a startup) but is weak at maintaining a large code base that you rely on. At least part of this is cultural, as the cost of misalignments between team members can be quickly translated into broken software.
Maybe it's just me, but "How much we ship per engineer" doesn't seem like the correct metric to track.<p>If that's the benchmark, developers are incentivized to produce over-engineered and bloated code.
Categorically, if you ship more bugs per engineer, you fix more bugs per engineer.
I have come to realize that code (and I think possibly productivity in general) being expensive was always a feature. I am sure that a few great ideas did get lost to obscurity due to lack of access to resources to build them out. However, we now have an absolute deluge of complete and utter shite.
Yep and there is no real demand for slop engineers are producing anyways.
This post is funny to me, because I feel it falls well short of what a proper, forward-thinking "AI-native" engineering org would actually look like. That is, the author is presenting this as kind of a radical departure from normal engineering, but I just see it as normal engineering with more AI. I don't see <i>that</i> as AI-native.<p>To me, true "AI-native" engineering will be one where questions regarding how humans will do things like review code are irrelevant. You explicitly throw away any concept of typical software engineering and, instead, differ to the AI. Your job, as a human, is solely to do what the AI can't physically do. That's <i>not</i> the same as closing gaps between what AI is currently capable of doing and what you'd need it to be capable of doing. It's literally enforcing that anything an AI is able to do is treated as correct in itself, and you, as a human, only support it by being a human.<p>If that sounds outlandish, that's because it is. We don't have such capable AI systems yet. It's possible we never will. But that's beyond the point. The reality is trying to make an "AI-native" engineering org by just layering AI on top of existing processes and systems is futile. If your expectation is that AI will continue to improve in capabilities at an accelerating rate, then these stop-gaps are pointless. You might as well just ignore AI altogether until it is able to completely take over, because that's the inevitable goal, right?<p>If you're willing to buy that will be possible, then my guess is that it will occur in the form of small scale startups and actual mavericks rather than someone trying to run an existing business who will simply be too risk adverse to go all in when the time comes. Some guy in his basement is more likely to leverage AI "properly" to build an actual "AI-native" engineering org because that person won't have much to lose.
Reminds me of a few things, like being a meat proxy, as well as books like Company of One or Million Dollar One Person Business, and these were published before AI so right now we will see companies with only one founder and hundreds to thousands of AI agents. There already was that drug delivery company with the one founder but apparently a lot of their revenue was fraudulent. Still, it proves the point that it is possible.
I think this is all fair, but somewhat just semantics.<p>Most engineers are working in "normal" engineering orgs, but can feel the ground underneath them shifting, and companies believe that if they are caught flat footed, they will be out competed in the marketplace, so they are all trying to make sure they are adopting it at least in a way that lets them keep pace if not accelerate revenue.<p>If you are not impacted by economic incentives, you can continue to not care about this transitional state, but most people do.
Spent few minutes reading the infomercial -- regretted it. Engineering principles form the bedrock first, and AI-tools are made to fit in them, not the other way around as this infomercial propounds. Its linkedin vibe is a big turnoff too.
Nice work. How do you handle swapping in a new model version, hot reload or restart? And what happens to a batch that's mid-run when it changes?
In my best impression of the slapchop guy:<p>First you take your Blendtech and "will it blend" your engineers, then upload the result to the cloud inside what is called an S3 bucket (don't forget to set access permissions on your buckets kids!) to be digested by the clankers, sit back and profit!<p>Dark humor aside I think disconnecting a bunch of problem solvers from their computing equipment could really enhance the world, putting that analytical power into the world in person could move a lot of cogs, rather then marshalling JSON.