Caylent has been testing this for quite some time and I have to say it's an interesting take. With claude code you can shift between planning and coding modes and this offers a similar approach. The speed is quite good and the results are solid. The spec approach is solid but it takes a learning curve. Some of the tooling and autojumps take a bit to get used to because they differ from the other IDE approaches.
Overall I do believe this has accelerated our development and I'm interested to see where it goes. I don't think it's a direct comparison to claude code or cursor - its a different approach with some overlap.
I've certainly heard things wrong before, and had high fever, and loads of alcohol, and migraines, and high sleep deprivation, and andrenaline. All things that greatly affect whether I can do something seemingly simple or not
You get a scale at AWS that is hard to find elsewhere. There are still a huge number of very smart people there. You can learn a lot. I loved my time at AWS.
That said there are a ton of cons. There's an entrenched management class that is disconnected from reality. There are a number of ~L8-L10 folks who don't believe or understand how they're falling behind the cloudflares and other providers. There is a bizarre arrogance in Seattle that masquerades as "willing to be misunderstood for long periods of time". People aren't afraid enough.
What AWS will struggle with over the next few years is verifying the results of the narratives they tell themselves. At some point along their evolution a disconnect between narrative and reality happened and someone needs to bring everything back to a baseline of reality. Leaders tell a story of their success (that I'm sure they themselves believe) and no one follows through to actually verify the results.
This issue of lack of narrative/reality baseline, to me, is a cancer at the heart of AWS and if it can be addressed then I think they can recover and shine. Otherwise they'll fall into the same trap as MSFT back in the 90s/2000s where they think everything is going just fine while the floor falls out from under them.
Happened to MSFT, happened to Google, happened to Sears, happened to GE, happneed to Boeing, happened to IBM.
There's definitely been some rot in AWS, which has been holding off the collapse in most other areas. Honestly it seems the more top down leadership, no matter who, gets their hands involved in thr sausage making process, thats when things start to go awry.
Engineering companies success because of their engineering culture. Amazon has some of the besr in class. Keep the accountability that many other top tier companies lack, but otherwise imo get out of the way and let the ICs do their job.
What happened to Microsoft and Alphabet does not seem comparable to Sears, GE, Boeing, and IBM. The latter group have objectively declined in terms of profit and potential.
MS/GOOG are still earning near record amounts of net income with fat profit margins, and have a higher than ever market cap.
AMZN also, so far, has pretty rosy numbers to back it up. They’re profit margins are relatively tiny though, so the executives are focusing on increasing those to match its trillion dollar market cap.
It is the reason Amazon shareholders enjoy a $2T market cap rather than Walmart shareholders that only have a $650B market cap.
It depends on what you mean by "what happened". If what you're talking about happening to those companies is how much money they make, you're totally right.
That said, your reply is a bit of a non sequitur. The thread is largely about answering the question of "why do you work at Amazon?", and I haven't seen anyone saying the answer is because of how much money Amazon makes. I also haven't seen anyone say they quit because Amazon appears to be on the same financial trajectory as GE or Boeing.
I bet you a tonne of people would agree that there's a culture shift away from valuing the experience of the boots-on-the-ground operational folk at all of those companies, which is why they don't want to work there.
Really, none? IDK, I've always thought DynamoDB and S3 were amazing, and Lambda, albeit not perfect on launch, was highly innovative and useful for many, many, many circumstances you'd either needs a k8s cluster or fleet of little used servers at the time.
SQS and Cloud watch were legit to, although cloud watch metrics are a bit aged and logs were really difficult to use until insihhts came into place
Also Glue, while it has some tenancy issues and rough edges, takes a bunch of work out of managing a datalake
Oh and Aurora + Aurora serverless weren't as flashy but from an ops perspective game changing at the time
Cloudformation is definitely showing it's age and I hate writing it compared to CDK, but it was also pretty game changing at the time. I don't know if it was the first infrastructure as code language, but it definitely kick-started the revolution.
The shopping site is the worst mainstream shopping site. Find stuff is hell. It’s missing criteria, finding the shipping time / cost when comparing products is painful.
Shipping is fast and prices are good, but you’re never quite sure you ordered the right size / color / edition.
>Engineering companies success because of their engineering culture.
What current companies do you consider to be both successful and have this culture now?
It's brought up a lot on HN. Heck, the evolution from 'fun, small, engineer company makes through product then everything changes when it becomes larger, more corporate' is almost a Hollywood cliche now (films like Blackberry, tv like Halt and Catch Fire).
Like the amazing story where a L7 insisted rewriting a python-based CLI tool in Rust, all in the name of performance even though the majority of the time was spent on HTTP calls?
What's more amazing is that the manager of the team thought that was an L7 scope and a great achievement.
> even though the majority of the time was spent on HTTP calls?
I'm not sure why this detail is relevant. The CPU it consumes is still CPU. Hypothetically, if a rewrite saves $100 million annually in compute, why does it matter that the majority of its time isn't spent in compute? It's still $100 million.
I took that to mean the tool was IO-bound, so it wasn't using much CPU to start. So if there was even that tiny sliver of slack CPU (and that's almost definitely the case on a desktop or other dev machine), then saving that tiny bit of CPU actually saved no money, since it was already riding on the spare capacity of other investments. That just leaves the cost in engineer-hours to rewrite the program.
IO-bound doesn't mean it doesn't use much CPU. A tool can use a lot of IO and also a lot of CPU.
> then saving that tiny bit of CPU actually saved no money
this doesn't follow
> since it was already riding on the spare capacity of other investments
nor does this
Take for example a CLI that downloads and verifies the Bitcoin blockchain. It may spend most of its time downloading blocks, but it spends a ton of time calling SHA256 to verify those blocks. Similarly with a tool that downloads and checksums large files like Docker images.
If you have a fleet of 650K developer machines all running this util, then at some point it becomes cost effective to optimize the CPU usage.
Whether that point was reached in this example is not something I know. It seems like the L7 and their manager believed it was. But OP believes it wasn't. Either way, we don't know from OP's description of the situation.
Sure, something like that is technically consistent with the description, but unlikely to be relevant. If you're thinking of a program that downloads a bunch of data and then does a bunch of cryptographic operations on it, what are the odds that the first description in your mind is "spends most of its time on HTTP requests"? Slim, I'd say, even if it's technically the majority of the time.
The question isn't the "hey what's the first description that comes to mind?" The question is why people on HN are mocking the idea that saving HUGE_NUMBER*B is a bad investment just because there is some other A satisfying A > B.
I was on that team. The rewrite was NOT valuable. Heck there is even a pinned Github issue at the top of the repo that tries to explain why this rewrite even happened and it doesn't have a good answer.
And high ranking managers never make silly judgments based on hype or cool-factor, is that right? Come on, the overlying context was specifically the claim that upper level management had lost touch with reality, and that this was just one example.
I get that people want to make fun of management. But the complaints were that Amazon was stagnating and frugal. The idea that they're spending extravagantly on programming language fads is amusing, but isn't really consistent with what others were saying or with what we know about Amazon generally.
Rewrites to save compute resources are done pretty frequently at huge companies. It's a relatively easy source of projects for high level engineers because they can see the fleet-wide metrics and have figured out how to choose projects that have clear dollar value in their performance write-ups.
Could an L7 have wasted a bunch of time on a fruitless project? Of course. Could an L7 have wasted a bunch of time on a fruitless project at a notoriously cutthroat and frugal company AND be super proud of it? That seems much less likely since they have to show some numeric impact at that level, but I obvious still possible. Would their manager then also be proud of it? That seems even less likely.
So when the only description of the project also accurately describes a large class of valuable projects (i.e. decrease fleet-wide cost of a ubiquitous tool) I was genuinely curious if there was more to the story.
Have you used many cli tools that consume a meaningful amount of cpu (in terms of cost)? They are generally used by a human, so the scale can’t be all that big.
Yeah, go to a place with poor bandwidth and run any tool that downloads and hashes large files. It will spend a large time waiting on the download and also a large time hashing the files.
reply