But they forgot that users who are NOT signed into Twitter don't see threads at all, so it looks to anyone who's follows the link that they just took an official AWS position at odds with the entire industry that they're trying to make billions of dollars from.
Here's the full text of that thread:
> More AI-generated code doesn't make your team faster. It might actually slow you down.
> The real bottleneck was never writing code. It's releasing it, debugging it, & keeping it running well. So when @Honeycombio CTO Charity Majors set a productivity target, she didn't chase 10x. She chose 2x, & built from there.
> Her team also skipped the mandates & built a set of AI values instead:
> "Every AI output has to have a human owner. If you don't want your name on it, it's probably not good work."
> Quality first, quantity second.
> Hear how @mipsytipsy built it on the AWS for Software Companies podcast.
No. It makes you faster. You can prove it by looking at the lines of code.
Source: Gary Tan, who can write more code than Jeff Dean and John Carmack.
If you want to go really fast, you put a Ralph Wiggum dungeon. It's where you orchestrate a team of Ralph Wiggum loops together using subagents to win the economic Darwin Award which companies are handing out for who can burn the most tokens.
Yes, we know. Good teams increase the likelihood of success with AI code generation the same way they increased the likelihood of success during hypergrowth: better infra, better devops, better internal abstractions/frameworks/building-blocks/golden-path-tooling that make the "easiest" way the "best" way to do antyhing. Otherwise, you get bogged down in garbage and everything breaks and catches on fire forever.
I'm a huge fan of Charity Majors and the quoted line in the next tweet in the thread is one of our team's rules, too:
> Every AI output has to have a human owner. If you don't want your name on it, it's probably not good work.
> The basic algorithm divides points by a power of the time since a story was submitted. Comments in threads are ranked the same way. Other factors affecting rank include user flags, anti-abuse software, software which demotes overheated discussions, account or site weighting, and moderator action.
Hah, this is pretty funny.
The official AWS account posted a thread to promote their podcast interview with Charity Majors: https://art19.com/shows/aws-for-software-companies-podcast/e...
But they forgot that users who are NOT signed into Twitter don't see threads at all, so it looks to anyone who's follows the link that they just took an official AWS position at odds with the entire industry that they're trying to make billions of dollars from.
Here's the full text of that thread:
> More AI-generated code doesn't make your team faster. It might actually slow you down.
> The real bottleneck was never writing code. It's releasing it, debugging it, & keeping it running well. So when @Honeycombio CTO Charity Majors set a productivity target, she didn't chase 10x. She chose 2x, & built from there.
> Her team also skipped the mandates & built a set of AI values instead:
> "Every AI output has to have a human owner. If you don't want your name on it, it's probably not good work."
> Quality first, quantity second.
> Hear how @mipsytipsy built it on the AWS for Software Companies podcast.
No. It makes you faster. You can prove it by looking at the lines of code.
Source: Gary Tan, who can write more code than Jeff Dean and John Carmack.
If you want to go really fast, you put a Ralph Wiggum dungeon. It's where you orchestrate a team of Ralph Wiggum loops together using subagents to win the economic Darwin Award which companies are handing out for who can burn the most tokens.
You still need domain knowledge and a solid understanding of what you're doing/what you want to achieve.
If you don't have that, now that writing code is basically zero-cost now (in terms of time), you'll still be slow.
I think they were being sarcastic.
Yes, we know. Good teams increase the likelihood of success with AI code generation the same way they increased the likelihood of success during hypergrowth: better infra, better devops, better internal abstractions/frameworks/building-blocks/golden-path-tooling that make the "easiest" way the "best" way to do antyhing. Otherwise, you get bogged down in garbage and everything breaks and catches on fire forever.
I'm a huge fan of Charity Majors and the quoted line in the next tweet in the thread is one of our team's rules, too:
> Every AI output has to have a human owner. If you don't want your name on it, it's probably not good work.
I did not realize it's possible that AI could engage with a project in such a way that Brooks' Law becomes applicable. Fascinating.
Ha-ha, I got more:
'Skipping tests doesn't make your team faster. It might actually slow you down.'
'Developing without requirements doesn't make your team faster. It might actually slow you down.'
`Using AWS services doesn't save you money. It might actually lead to you burning more money.`
'Making your team faster doesn't make your team faster. It might actually slow you down.'
How did this get to the front page?
From the FAQ:
> How are stories ranked?
> The basic algorithm divides points by a power of the time since a story was submitted. Comments in threads are ranked the same way. Other factors affecting rank include user flags, anti-abuse software, software which demotes overheated discussions, account or site weighting, and moderator action.
This is one sentence.
Is this notable because AWS is commenting this?
It’s a thread promoting an AWS podcast episode. The link is in a reply because X limits the reach of top-level posts that contain links.
The X thread shouldn’t’ve been posted here. If the podcast episode is worthwhile, a link to that should’ve been posted.