André Jasiskis

An Algebra of Thoughts: When Kyo effects meet LLMs by Flavio Brasil Kyo, a cutting-edge effect system in Scala 3, introduces a novel approach to composability through algebraic effects. This talk will present a type-safe method for structuring LLM interactions based on Kyo effects, introducing an algebra of thoughts that simplifies complex AI workflows. We’ll demonstrate how this approach enables explicit modeling of AI capabilities, simpler management of LLM context, proper resource management, and seamless integration with Kyo's comprehensive suite of effects. Additionally, we will explore how Kyo’s effect tracking can serve as a sandboxing mechanism, facilitating safe and controlled execution of code generated by LLMs. Join us to see how Kyo’s algebraic design can transform how we think about and build reliable, scalable systems for next-generation AI. https://lnkd.in/dAtj3Mh4 #funcprogsweden #functionalprogramming #kyo #scala

20

Next week at SREcon in Dublin, several of my colleagues will present talks and lead discussions on critical aspects of reliability engineering. Pierre Theo Klein, Garrett Holthaus, and Rubén Barroso will present “STPA for Software Systems–Illuminate the Unknown Unknowns”: SREs know about some of the flaws and vulnerabilities in their systems. They might also have intuition on where to look for additional issues–"known unknowns." But what about the "unknown unknowns"–outages waiting to happen that nobody is even looking for? What if we could understand our systems enough to be able to methodically explore these complex interactions and build a comprehensive list of possible outage scenarios? In STPA, we model systems based on control-feedback loops, creating a hierarchical control structure, or HCS. In this session, we'll use a real Google system to show how an HCS can help you gain a new perspective and understanding of your system. We'll note similarities to common patterns in software design so you can start thinking about similar vulnerabilities in your own systems. Tomasz Koczorowski will present “the Bitter and the Sweet of Running a Planet-Scale Build & CI Stack at Google”, about managing Google's planet-scale Build & CI stack from an SRE perspective. He’ll explore the complexities of supporting over 100,000 monthly users and massive workloads, maintaining a 98% cache hit rate across diverse computing environments. Discover resource management strategies for doubling year-over-year growth, the application of the Pareto principle, and critical caching layers. You will gain insights into optimizing the build stack and maintaining a 24/7 service with a small SRE team through strategic planning, monitoring, and collaboration. He will present availability risks, standardization, and the pros and cons of a monolithic Build & CI stack Jennifer Petoff will lead a discussion on “Oops to Ops: Establishing SRE Practices”: Establishing SRE practices, gaining buy-in, and building momentum around reliability can be a significant hurdle for many organizations. This interactive discussion session, designed for both SRE newcomers and seasoned practitioners, will explore common challenges and effective strategies for implementing SRE principles based on our collective experience. We'll delve into practical approaches for demonstrating the value of SRE, fostering a culture of shared ownership, and overcoming resistance to change. Participants are encouraged to share their experiences, ask questions, and contribute to a collaborative exchange of ideas on how to successfully integrate SRE into their organizations and build a strong foundation for operational excellence. (continued in comments)

48

3 comentários

To Effect or Not to Effect - a Scala Perspective by Daniel Ciocîrlan at Func Prog Conf 2025 Just as Scala has transformed the way we build applications with functional programming, effect systems are changing how we build strong, testable, composable and provably correct code. In this talk, we will explore the benefits of effect systems in Scala, the different approaches to effects, how effects make our code more modular and powerful, and the tradeoffs we need to make in the code—all with realistic examples from personal experience and the experience of companies using them. By the end of this talk, you'll know what effects are, how they work, and whether you can (or should) use them in your own code, with the excitement that may come with it. Full presentation: https://lnkd.in/dRU-Qi5x #functionalprogramming #fpc2025 #scala

42

⚠️ 𝐀 𝐥𝐢𝐯𝐢𝐧𝐠 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭 𝐭𝐡𝐚𝐭 𝐥𝐢𝐞𝐬 𝐢𝐬 𝐟𝐚𝐫 𝐦𝐨𝐫𝐞 𝐝𝐚𝐧𝐠𝐞𝐫𝐨𝐮𝐬 𝐭𝐡𝐚𝐧 𝐧𝐨 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐚𝐭 𝐚𝐥𝐥 ‼️ Google just released 𝐂𝐨𝐝𝐞𝐖𝐢𝐤𝐢, an open-source framework designed to accelerate code understanding. It promises a dynamic feedback loop, scanning codebase to regenerate documentation on every commit, creating hyper-linked, context-aware knowledge base that evolves in lockstep with your repo. https://lnkd.in/g5D2f53x I’ve been a fan of Cognition’s 𝐃𝐞𝐞𝐩𝐖𝐢𝐤𝐢 for some time. Google's entry signals a shift from proprietary moats to open benchmarks, and one data point reveals a hard truth which needs to be discussed. We are looking at a market that has technically matured, but practically stalled at "𝐂+" 𝐬𝐭𝐚𝐧𝐝𝐚𝐫𝐝. According to 𝐂𝐨𝐝𝐞𝐖𝐢𝐤𝐢𝐁𝐞𝐧𝐜𝐡, current state automated documentation hovers between 64% 𝐚𝐧𝐝 69% 𝐚𝐜𝐜𝐮𝐫𝐚𝐜𝐲. That is the quantitative truth that technology is immature which requires constant human oversight. 𝐀 𝐥𝐢𝐯𝐢𝐧𝐠 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭 𝐰𝐡𝐢𝐜𝐡 𝐥𝐢𝐞𝐬 (𝐜𝐨𝐧𝐟𝐢𝐠 𝐟𝐢𝐥𝐞𝐬 𝐰𝐡𝐢𝐜𝐡 𝐚𝐫𝐞 𝐧𝐨𝐭 𝐮𝐬𝐞𝐝) 𝐢𝐬 𝐟𝐚𝐫 𝐦𝐨𝐫𝐞 𝐝𝐚𝐧𝐠𝐞𝐫𝐨𝐮𝐬 𝐭𝐡𝐚𝐧 𝐧𝐨 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧. 𝐈𝐭 𝐩𝐨𝐢𝐬𝐨𝐧𝐬 𝐭𝐡𝐞 𝐜��𝐧𝐨𝐧𝐢𝐜𝐚𝐥 𝐬𝐨𝐮𝐫𝐜𝐞 𝐨𝐟 𝐭𝐫𝐮𝐭𝐡 ! 𝐓𝐡𝐫𝐞𝐞 𝐭𝐚𝐤𝐞𝐚𝐰𝐚𝐲𝐬 💡 : 1. "𝐖𝐡𝐚𝐭" 𝐯𝐬. "𝐖𝐡𝐲": Reading code is no longer enough. The code only tells you what is happening. To enable true agentic behavior (SE 3.0), we must capture the why—the Intent. We need architectures (Architecture as a Code) —that connect the code to the business context: the Jira tickets for PRD, architectural decisions, tribal knowledge, etc. 2. 𝐍𝐞𝐰 𝐁𝐨𝐭𝐭𝐥𝐞𝐧𝐞𝐜𝐤: Human Readiness . Barrier to adoption is no longer AI capability; it is human readiness gap. We are facing a crisis of trust. While 93% of organizations are exploring GenAI, only 46% of employees actually trust these systems. The "ancillary costs" of verifying AI output and building "𝐀𝐜𝐜𝐮𝐫𝐚𝐜𝐲 𝐒𝐮𝐫𝐯𝐢𝐯𝐚𝐥 𝐊𝐢𝐭𝐬" are currently higher than the productivity gains for many enterprises. 3. 𝐈𝐭’𝐬 𝐍𝐨𝐭 𝐀𝐛𝐨𝐮𝐭 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧: This race isn't about generating cleaner wikis. It is a race to build Enterprise Knowledge Graph. This graph — mapping of your proprietary code to your business logic—is the training data that will power your future domain-specific models. 𝐁𝐨𝐭𝐭𝐨𝐦 𝐥𝐢𝐧𝐞: We are moving from "𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐯𝐢𝐭𝐲" (speed) to "𝐜𝐫𝐞𝐚𝐭𝐢𝐯𝐢𝐭𝐲" (systemic understanding, high cognition tasks). But until we solve the trust gap, we are simply building faster ways to misunderstand our own systems. CodeWiki: Evaluating AI’s Ability to Generate Holistic Documentation for Large-Scale Codebases - https://lnkd.in/g6qUh4Jm #AIArchitecture #CodeWiki #DeepWiki #SoftwareEngineering #LivingDocumentation

21

2 comentários

I talk with ☁️🔧Rui Duarte a Lead Cloud Platform Engineer and we take a look at DX, Platform Engineering, PX?! and Platform as a Product (PaaP). 📺 Full link in the comments. We cover: ✅ What is Platform Engineering? and Platform as a Product? ✅ What size and kind of companies will you see it? ✅ What is DX and how has it changed? ✅ Are Consumer Product and Platform Product similar? ✅ Cognitive load and its impact on engineers? ✅ Engineering away Enablement and why? ✅ Enablement as an important feedback loop? ✅ Ivory tower Platform Engineering? ✅ How Platform adoption grows and how it stalls. ✅ Choosing meaningful metrics and true outcomes. ✅ AI / LLM coding impact on DX and Platform Engineering. #cloud #platformengineering #infrastructure #googlecloud #gcp #dx #platformasaproduct #developerexperience #interview #aws #azure #aiinfrastructure

33

3 comentários

The Architecture That’s Replacing Microservices A friend recently asked: “How much of your work now touches agentic AI?” My answer: All of it. Agentic architecture is the next evolution in how systems are built—and it’s not just for engineers. This isn’t about coding. It’s about how goals get executed in your business. 🧱 First there were monoliths (everything in one place) 🧩 Then microservices (pieces talking to each other) 🤖 Now agents—autonomous AI-powered modules that act on goals, not just instructions. Each agent has: Its own input/output Its own memory (vector DB) Its own link to an AI model And autonomy to plan and act I break this all down in a new blog post with a simple diagram and some founder-first framing. 👉 Check it out here: https://lnkd.in/gCgN8rkd Curious how this applies to your product? Happy to jam in the comments. #AgenticAI #AIArchitecture #ArtificialIntelligence #Microservices #SystemDesign #VectorDatabases #StartupTech #Founders #FutureOfWork #TechInnovation

17

2 comentários

“This is changing how developers work, allowing them to spend less time generating code with the agent inside the IDE and more time delegating entire workflows.” So much about software engineering has changed in the last 2~3 years, with much of that change happening in just the last 12 or so months. Many of the most influential voices in tech agree that the discipline (and industry around it) is undergoing a significant shift, the likes of which haven’t been felt since the move away from assembler to higher-level languages. What we’re experiencing is quite a digital revolution, one might say. With all the new tools and improved capabilities, it’s time to really rethink the SDLC. Much is possible that didn’t use to be and we’re starting to see some back pressure in certain areas (code review, I’m looking at you). How, you might ask? Create a process map of your software delivery workflow and identify all the steps that would benefit the most from the simplest agents you can think of. Start small and iterate. Learn from your experiments. Creativity and curiosity will go a long way. An enduring focus on security will take you further, safer. OpenAI have written a guide with some great suggestions on how to get started. This will differ for every team - your context is different. Use this as a starter kit.

17

1 comentário

AI Coding Agents: Revolutionizing Software Engineering But at what Cost? 🤔 The last days, I was reading a lot of discussion and posts on this. Thanks to Raphael Neves for triggering first thoughts. A lot of companies report unprecedented gains in productivity, code quality, and delivery speed, fundamentally changing how teams operate. But as we embrace this technological leap. Are we fully prepared for the dual impact on our KPIs and performance indices? The upside is clear and some studies giving good insights: 🚀 Tools like GitHub Copilot are accelerating task completion by up to 55%, freeing developers from repetitive work to focus on innovation. ✨ AI helps detect anomalies, suggest optimizations, and improve test coverage, leading to fewer bugs and higher reliability. ⚡ Automated code reviews and streamlined testing are cutting lead times and increasing deployment frequency. 😊 Reduced cognitive load, easier learning of new languages, and more "flow state" for developers. However, we must address the negative impact as well: Quality & reliability concerns AI-generated code can vary in quality, harbor hidden bugs, or be based on outdated practices, often requiring more human review time. Security vulnerabilities A significant portion of AI-generated code contains security flaws, and agents are susceptible to prompt injection and data leakage. This is a critical risk to our security posture. Skill erosion Over-reliance on AI could lead to a decline in hands-on coding skills, particularly for junior developers, impacting long-term problem-solving capabilities. Technical debt Quick fixes from AI might accumulate technical debt, leading to long-term maintenance challenges and inconsistent coding styles. The speed and efficiency AI provides, if unchecked, can inadvertently degrade code quality, increase security risks, and accumulate technical debt. This means apparent short-term productivity gains could be offset by significant long-term remediation efforts. Success will increasingly hinge on our ability to effectively prompt, evaluate, and integrate AI, focusing on strategic thinking, architectural design, and nuanced decision-making. What's your take? How are you balancing the incredible potential of AI coding agents with the critical need for quality, security, and sustained human skill development in your teams? Let's discuss! 👇 Matthias Patzak John Crickett Stephan Wimoesterer Chris Duffy CAIO what are your thoughts on this?

16

5 comentários