Bas Brekelmans

I think every tech company should have at least 3 well funded projects like the one Galen is working on. He is focused on "converting" a massive codebase but the heart of it is focusing on bulk manipulations of existing massive codebases. The dirty little secret is that most of our codebases are dumpster fires. (Though you could probably have guess this from your user experience) Code that was written in a rush to meet and deadline and then abandoned after it was shipped and the promotions handed out. It even has a name: LPA - LAUNCH, PROMOTIONS, ABANDON. Many organizations promote the people that make the mess but not the people that try to make the mess actually work. Code that is so fragile or incomprehensible that no one wants to touch it or that it breaks every time you touch it. etc. etc. There is a steady stream of changes that need to be made because of security, policies, compliance, reliability, etc etc. Many of these go unimplemented because of local reward/risk calculations or lack of resources. Lots of AI for code efforts are focused on new code. Where the real win is going to be is in taming the monster codebases we already have. We have to be in a position were we are not afraid of our code - we need to implement these steady stream of changes with confidence. That requires shifting our focus from the "keynote demos" and focusing on the existing codebase. Bulk transformations. Consistency passes. etc. When we achieve this, we can put our houses in order and free up our best talent to work on the new stuff.

47

6 Comments

I've been discussing this recently with Frances Buontempo in the context of coding assistants. We hear a lot from developers saying that LLM assistants in their fave IDEs are great for generating a lot of the (boring) boilerplate code needed to stand up a non-trivial system. However, most popular IDEs have been able to do exactly this for decades--whether with "wizards", code-block and project templates, or other various forms of meta-programming. The difference is that the "old" way is much less hungry of resources, while simultaneously being much more predictable and reliable at automatically generating the "boring" stuff. Coding assistants are also good at other things, of course, but many of the popular (in my conversations with developers) tasks are those I would much prefer to do myself, such as writing tests.

15

6 Comments

Yesterday, I shared that Amazon Simple Queue Service (#SQS) launched Fair Queues and today I want to dive deep into why it matters. Fair queues can automatically mitigate noisy neighbors by detecting when a single tenant starts consuming too many queue resources and then prioritize delivering messages from other tenants, keeping their processing times consistently low. Simply add a `MessageGroupId` (acting as a tenant identifier) when sending messages. The fair queue logic kicks in automatically—no changes needed for your consumers and no throughput limitations... now THAT is EASY! Fair queues help you build resilient multi-tenant architectures and are ideal for modern SaaS, microservices, and event-driven platforms where consistency and tenant fairness are critical. You get enhanced observability with metrics in Amazon CloudWatch that now differentiate between “noisy” and “quiet” groups, helping you monitor and optimize tenant isolation. Want to learn more? https://lnkd.in/gs7V85WD #Queues #Messaging #AWS

13

Monolith Vs. Micro-frontend Architecture The frontend components can be built, tested, deployed, and released independently as part of the micro-frontend architecture. When interacting, all the independent components are bundled and displayed as one single UI, but in reality, they are interacting with independent child components. Each component is called a micro-frontend, which drives a specific business functionality. 𝗦𝗼𝗺𝗲 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀 𝗼𝗳 𝗠𝗶𝗰𝗿𝗼𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗮𝗿𝗲 : Independent Development & Release Drive Polyglot & Team autonomy Performance & Scalable Improved time to market Modularity Compared to the micro-frontend, the monolith frontend has all the components tightly coupled, deployed, and released as one piece. Any new development, deployment and release must be done as a release of the entire codebase. 𝗦𝗼𝗺𝗲 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀 𝗼𝗳 𝘁𝗵𝗲 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵 𝗳𝗿𝗼𝗻𝘁 𝗮𝗿𝗲 : Ease of development & maintenance Much simpler Cost-effective & Faster to adopt

158

21 Comments

Not complaining about the choice of Rust as a memory safe intermediate language. The problem is the idea that Rust will be the only language everyone will write code in 2030. Rust is unsuitable for most people as a primary language to express their ideas. I'd guess less than 5% of humans are capable of being proficient at it. If Microsoft has built such magical infra, a better application is to apply it to Python/Typescript translation to Rust vs fighting the C++ war.

8

7 Comments

An agent has no consistent definition. You can think of an agent as an autonomous or semi-autonomous system that can take actions on behalf of the user in a given environment, state, and make decisions or take actions that can accomplish certain tasks along a given time-frame, either by calling tools, dynamically selecting the next action to take or use a deterministic "workflow" (systems where LLMs and tools are orchestrated through predefined code paths). Using an Agent framework that gives you the ability to built systems in both, a reliable and a dynamic way can accelerate your agent development journey using agent abstractions. This means building Agentic systems that can reliably call tools, store memory (episodic/semantic/procedural), have comprehensive logging and observability, human in the loop workflows and the ability to build various multi-agent patterns flexibly based on your use case. A successful Agentic system in production is usually a combination of both, dynamic and predictable/reliable multi-agent systems. Strands Agents SDK gives you exactly these capabilities by treating each “agent” as a combination of a foundation model plus a suite of tools. You define a prompt and register your tools (decorated functions) in code, then Strands handles reasoning→planning→tool-execution cycles, local testing, and cloud deployment (ECS, Fargate, Lambda, EC2), along with support for all other agent abstractions provided above. Excited to share a hedge-fund analyst multi agent system: This uses the newest Anthropic's Claude 4 Sonnet/Opus that powers the Lead Analyst Agent, routing incoming queries to specialized sub-agents for fundamental, technical, and market analyses. Each specialist is wrapped as a callable tool (using the “agents-as-tools” multi-agent pattern), so the orchestrator never has to implement domain logic itself and can handoff the task to an agent as a tool. For sensitive operations (insider lookups), we utilize a HITL approval step that halts execution until a human grants consent. We also use meta-tooling that enables the Lead Analyst to generate, load, and invoke new custom tools at runtime—whether it’s a portfolio beta calculator or a pricer—without redeployment. Strands also embeds observability (Langfuse) and OpenTelemetry tracing so you can trace reasoning events, tool invocations, errors, and end-to-end workflows in real time. View more information on the code implementation here: https://lnkd.in/gJmwVyGi Code implementation: https://lnkd.in/gzTtJvJq Thanks to 🏄‍♂️ Cagatay Cali for being a reviewer/collaborator on this! Feel free to try it out and reach out with any questions/ideas. #aws #agenticAI #strands #agents #generativeAI

60

6 Comments