i wonder if we should expect this to fail by default.
The meta culture has historically been known as "move fast and break things". This seems counter to a typical cloud business.
Seeing how meta works in ads and business interfaces for whatsapp/instagram, it seems that
1. meta lacks support and customer success functions for enterprise
2. meta lacks b2b sales functions/culture
3. meta lacks a scrutable high quality operations culture for their APIs (SLAs, scaling, etc).
These aren't easy things to gain, and we see the problems that the AI providers/azure/gcp etc have had historically as consequence of these various issues.
The post suggests fear about a surge of increasing amounts of code by loops and loops of agents.
I don’t know if I like the current world without it though.
80% of different teams code the code is poorly tested. The code doesn’t handle data consistency or asynchronous code properly because the engineers don’t know better (and frankly don’t care enough).
Dependency handling is poorly managed leading to low quality operations with improper dashboards, alarms, and ops.
Badly managed processes leads to people doing monkey work signing off checklists rather than automation.
Frankly… why is keeping any of that good? It really pisses me off seeing people accept any of that low quality but that standard is the default and not the outlier.
The blog posts the experiences of trying to write out a new service in AWS with mostly agentic coding.
The project was generally a success and achieved replacement of internal bedrock services.
BUT, it came with various caveats:
1. the communication bottleneck is significant and alignment becomes even more expensive between engineers
2. engineering decisions cascade and become even more important, so you need high quality decision makers. The entire team was highly skilled, principal and distinguished engineer level.
3. every single blocker that you had administerially previously would need to be broken down, and your organization has to functionally already be in full continuous deployment mode already. if you aren't, the increased velocity is useless.
4. even with increased velocity, further bottlenecks were induced such as the rate of safe deployments through the pipeline, the ability to A/B/feature flag test, soak tests, and others.
in aws, some of the core bedrock services have been replaced with the new serving architecture. that thing was written basically with LLMs.
mind you, guy's a distinguished engineer, his team was basically all principals, but you can do it and some of the new teams are copying the style (though with less success, due to lack of technical skill).
composer is competitive with around opus 4.5 in feeling?
largely lags behind opus4.7/gpt5.4, but is respectable, and generally outperforms the glm/qwen equivalents anecdotally despite benchmarks.
fails to follow instructions more often, and is less code critical, but performs okay if you can decompose the task to smaller problem spaces. i.e. only do manual review, only do typechecking, only do specific component. etc
myself? senior engineer role is basically figuring out the business problem and getting funding.
IDK i've always been able to get senior managers/managers to give me lots of leeway to do wtv i want and figure out problems.
At least in most places i've worked at.
i work on platform stuff mostly, so there's always a large need for stuff.
the backlog alone b4 all the agentic stuff was roughly 20-30x the capacity of any team (per year). 80% of requests were usually SVP goals and we'd just outright drop them due to lack of capacity or request HC transfer/away teams.
i.e. internal improvements alone were always massive (not gonna talk about prod code/cross team organization).
1. we need better test coverage for x,y,z
2. we need to be able to eval the long term costs (XX growth YOY, how to reduce)
3. the internal system streaming is inefficient, need to eval the alternative systems
4. we need better ops handling/management automation for issues and sev3s/sev2s. i.e. scaling, anomaly analysis, bugs introduced, improved metrics, dashboards.
5. DX stuff needs better handling, people keep confusing themselves on how to onboard. better docs on how to onboard, automation,
6. teams x,y,z are fighting with each other bcz they don't have a good grasp on systems, improve internal docs on arch and interop
7. we need automation to be able to more easily test our systems in an adhoc fashion
8. there's no linters for API platform, leading to bad results and inconsistency.
9. we're seeing bugs in the code, but aren't appropriately manualy testing after deployments. spawn 100 agents to do it, compile the results. do it every X days, feed the bugs back into the system.
i could go on and on. and this is one service, usually you own quite a few, and each one has their unique set of challenges.
well work wise its usually for adjacent tooling. It unblocks other things, but like actual prod code, i'm always a little skeptical.
For example we had this problem where we had to take in customer inputs for requests and calculate out the projected downstream TPS. This is fairly complex since we run a query parser/orchestrator.
This is expensive to write myself or to have engi's do it, but the scaling algorithms are all there and we have excel sheets for spreading out overall costs.
so then all was needed was basically write out a big spec of the reqs - give it the docs/parser code/excel sheets, then just have it span out the pieces as a sequential checklist.
1. CI/OPS
2. docs
3. test infra
4. incremental build out in phases to chain it all together.
I find ai generated deep code wikis very valuable. They provide clear walk path to read the code. Reading code raw is always painful, trying to trace the right start points, especially with lots of legacy code.
One really valuable thing i'm seeing in open source though is everything is being localized. Most before it was just not available. In a way, that's really good because it helps to bring the chinese and english speaking communities.
+1, all the things that were said about India are true about Malaysia, Singapore, and to various degrees within Vietnam and Thailand. Yet these countries are all richer than India.
It is still true today as Lky said 50ish years ago. The bureaucracy of India is federalized yet overly centralized.
When the city governor must ask for permission to their own money from the federal when yet they are so far away, there is nothing efficient. The powers are yet so powerful yet blind at the same time.