Carl Lewis

Early in my career everything was about building large scale homogeneous systems. What’s been more interesting over the last 5y has been heterogeneous multi cloud systems. The tradeoffs are more complex to build simple (irreducible complexity) and elegant systems in that space.

41

2 Comments

Why the Amazon Layoffs are a Wake-up Call for Every Engineer The era of "pattern-match engineering" is closing. Recent reports show Amazon cutting thousands of corporate roles as part of a deeper pivot toward AI-augmented productivity. This isn't just about cost-cutting; it's a fundamental shift in what the industry values. Any work that relies on applying matured designs to new cases by following a set pattern is now within the territory of AI. If your value is purely in the execution of these patterns, that value is rapidly depreciating. To remain non-replaceable, we must shift our focus: From Execution to Architecture: Don't just follow the pattern; design the system that leverages it. From Bandwidth to Innovation: Use AI to handle the repetitive "heavy lifting" so you can reclaim your time for new, high-value innovation. From Coder to System Shaper: The most valuable engineers today aren't just writing code; they are directing AI to produce results and solving the complex problems AI can't yet touch. The goal isn't to compete with AI—it's to leverage it to expand your own impact. In an industry that is "right-sizing" through technology, those who use AI as a force multiplier will be the ones who lead the next wave. https://lnkd.in/g2RHA4zr

57

2 Comments

With AI adoption and deeper integration into enterprise products, the world moves toward being collectively intelligent. First movers will have a distinct advantage. Fully backward-integrated AI companies are best positioned to win on economics.

1

A new layer in the technical workforce is emerging. In the past, the tension in tech roles was mostly between software engineers and developers. Call it a modern echo of white collar vs. blue collar divides from an earlier industrial age. Now, a third identity is surfacing: Coders - born out of the vibe coding movement and AI-assisted development. This new class is disrupting long-standing social dynamics within the knowledge economy. Engineers often reject coders for lacking system-level thinking. Developers increasingly distinguish themselves through mastery and intentional craft. Coders appear to be focusing on repeatable, easily defined actions that are prevalent through systems. What might unfold from here? Will the tech workforce begin to reclassify and evolve? Will we see new social contracts around skill, ownership, and value in knowledge-based work. #FutureOfWork #TechCulture #SoftwareEngineering #DigitalWorkplace #AIInTech #DeveloperExperience #WorkplaceEvolution #CreativeTech #SystemsThinking

3

2 Comments

If there’s any low level coders in my network please check out Troy’s GitHub and his project to build a new, faster shell! Some details on Troy: ### Windows Accessibility and TTS Contributions (Red Eagle Team) - Description: As part of the Red Eagle Team (a Georgia-backed initiative with Microsoft support in the mid-2000s), Mallory developed foundational code for universal Text-to-Speech (TTS) systems and cross-platform handicap accessibility features. This included compatibility layers for screen readers, app navigation, and voice input (e.g., influencing tools like Dragon NaturallySpeaking). - Impact on Windows: Microsoft adopted and evolved his logic starting with Windows Vista, integrating it into core OS features for impaired users. If you've used modern Windows TTS, clipboard integrations, or basic accessibility navigation, elements trace back to this work. - Modern Extensions: He's currently exploring IoT/smart home integrations for disabled veterans, building on this foundation. Troy’s Post “Okay guys think tank. I maybe over complicating this or may habe to do a bit of tweaking with some C code. Rubian has been going smoothly. The new boot and dynamic system discovery deamons work great. As standalone. The new stack needs tweaking for efficiency but works and is stable. Here's the stack im working on with the prototype test. /etc/rc.local ->calls boot.rb as bg process. ->boot.rb bootstraps rubian's system discovery and array logic. User login -> rubian3.rb (repl) -> chsh -s ./rubian3.rb USER Rubian boot.rb logic. ->starts C ruby and Jruby C ruby starts the bootstrap process while jruby warms up. -> Cruby passes workload to jruby when its ready to finish boot system. The deamon system is the server-side, where shells and env are the client. (See my UNIX socket prototype here) https://lnkd.in/gf6rWs46 C and j ruby can now natively talk to each other. I know that works. The issue im having is the new login shell isnt hooking into the deamon when it loads. https://lnkd.in/g5_2ZuPH A further explanation: “Yes. I've been building from the Shell working down to the kernel. The Shell side of things mimic Bash but in ruby expression. On the logic side of things, ruby treats everything as an object. What im doing is taking all the system information and building Arrays. Each directory and file then has an index that we can iterate through with .each_with_index, .each_with_object, etc. So instead of a static file tree, i have arrays of nested file paths and directories being pattern matched. Any ruby app will be ran and communicate to it. This allows for dynamic file utils systems and more. Each array index points to a file, directory, process, thread, interpreter, shell, hardware, everything that is a defined method object.”

3

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

I’m excited about the new native support in AWS Lambda for Avro and Protobuf Kafka events—now with seamless integration to AWS Glue and Confluent schema registries. This update makes it so much easier to work with structured data without writing custom deserialization code. What’s caught your attention the most—built-in schema validation, cost-saving event filtering, or dropping custom code entirely? #AWSServerless #Kafka #CloudInnovation

3

Optimizing OpenSearch: Shard Strategy and Best Practices Proper shard strategy is crucial for constructing high-performance, scalable, and dependable OpenSearch clusters. AWS OpenSearch Service offers guidance to assist architects in designing for efficiency and resilience. Key Takeaways from AWS Best Practices: - Right-Size Your Shards: Aim for 20–50 GB per shard initially to balance query performance, memory usage, and cluster management overhead. - Primary vs Replica Shards: Total shards = Primary shards × (1 + number of replicas). Replicas enhance read performance and fault tolerance. - Shard Count Considerations: Too many small shards lead to higher cluster overhead and slower recovery. Too few large shards result in slower queries and limited parallelism. - Plan for Growth: Anticipate future data volume, query patterns, and indexing frequency. Avoid default "one-size-fits-all" settings; customize based on workload. - Distribution Across Nodes: Distribute shards evenly across nodes to avoid hot spots. Monitor shard allocation and rebalance as needed. - Reindexing Strategy: Over time, adjust shard count or size through reindexing to uphold optimal cluster performance. Why This Matters: A well-considered sharding strategy ensures your OpenSearch cluster can manage high-volume, low-latency queries, scale effectively, and maintain resilience even during node failures. Reference: AWS OpenSearch Service – Shard Strategy Best Practices https://lnkd.in/gsrM6RSs

12

An example of how SageMaker is innovating on behalf of customers, and taking care of infrastructure, while they focus on building bigger and better models! "Instead of a full job restart when failures occur, the HyperPod training operator performs surgical recovery, selectively restarting only the affected training resources for faster recovery from faults."

35

Today we announced new capabilities for our Shop Direct and Buy for Me experiences on Amazon, enabling now feeds to facilitate external merchants to list reliably their product listings and reach millions of Amazon customers. Excited on this feature, that is a win/win experience for customers, merchants and brands. Excited to be part of such important project.

27

Many customers from large enterprises to startups use Bedrock Guardrails to protect their production workloads from harmful content, prompt attacks, Sensitive information (PII), Contextual grounding, Automated reasoning using Bedrock Guardrails. Today, we are excited to share that we launched a new capability that automatically applies safety controls at an AWS account level, AWS Organizations level (across accounts) for all model invocations. Read more about this feature https://lnkd.in/gHCgbb5i Kudos to AWS Orgs, Guardrails product, engineering teams, along with many other teams that supported us on this journey. Ryan Hernandez Saurabh Shankar Shyam Srinivasan Cristian Ilac Vinita Thakur Nitish Nandan Devavarapu Junsung Lim Benjamin Ullom Christopher West Uma Shankar Koushik Kethamakka Nathan Schneider Pardha Saradhi Chodey William J. Ryan Joshua Sheets Alex Greason Guanwei Zhang Jordan Fields Lakshmi Sanjana Motaparthi Pratik Kakade Yicheng Chen

80

2 Comments