[VoxxedDaysAmsterdam2026] Coding Fast and Slow: Managing Mental Energy for Sustainable Software Development
Lecturer
Baruch Sadogursky is a Developer Advocate at Tessl, focusing on package management for AI agent skills. A Java Champion with extensive experience in DevOps and software engineering, Baruch explores the intersection of behavioral psychology and programming practices to improve developer effectiveness and well-being.
Abstract
Software development demands significant cognitive resources, yet the mental costs of context switching, interruptions, and decision fatigue are frequently overlooked. Baruch Sadogursky applies insights from behavioral psychology, particularly Daniel Kahneman’s framework of fast and slow thinking, to examine how developers can manage mental energy more effectively. The presentation analyzes the biological and psychological mechanisms underlying attention, fatigue, and intuition, while offering practical strategies for preserving cognitive capacity throughout the workday. Topics include reducing unnecessary context switches, implementing deliberate work patterns, and leveraging AI tools with appropriate context engineering. These approaches enable developers to maintain high-quality output while avoiding burnout and sustaining long-term productivity.
The Dual Systems of Human Cognition in Programming
Human decision-making operates through two distinct cognitive modes. System one functions automatically, emotionally, and with minimal effort. It excels at pattern recognition and rapid responses but can lead to errors when complex analysis is required. System two engages deliberate, logical, and effortful thinking. It handles complex problem-solving and critical evaluation but consumes significant mental energy and operates more slowly.
In software development, system one drives much of routine coding activity. Experienced developers intuitively navigate familiar codebases, recognize common patterns, and make quick implementation decisions. This efficiency feels productive and satisfying. However, system one also introduces risks. Code that “looks okay” may contain subtle flaws that system two would identify through careful review. When mental resources are depleted, developers default to system one even for tasks requiring deeper analysis, resulting in overlooked issues and technical debt.
System two becomes essential for architectural decisions, debugging complex interactions, code reviews, and learning new technologies. The challenge lies in preserving sufficient system two capacity for these critical activities rather than exhausting it on routine interruptions and low-value tasks.
The Hidden Costs of Context Switching and Interruptions
Modern work environments are engineered to fragment attention. Email notifications, messaging platforms, meetings, and status updates create frequent context switches throughout the day. Each interruption forces the brain to reload relevant information, reestablish mental models, and regain focus. This process is metabolically expensive and significantly reduces overall effectiveness.
Research demonstrates that developers check email approximately 77 times daily on average. Attention spans on digital interfaces average just 47 seconds before shifting to another task. Returning to deep work after an interruption requires substantially more time than most people realize. The cumulative effect is reduced code quality, increased errors, and diminished creative problem-solving capacity.
Critically, developers often fail to recognize when their cognitive performance has declined. Similar to how tired individuals overestimate their driving ability, programmers working on system one may believe their code quality remains high. This self-assessment bias makes proactive management of mental energy essential rather than reactive.
Strategies for Preserving and Replenishing Cognitive Resources
Effective mental energy management requires both prevention of depletion and strategic restoration. Time blocking dedicates specific periods to focused work without interruptions. The Pomodoro technique, originally using 25-minute intervals, establishes minimum focused periods while allowing flexibility for natural flow states. When developers enter deep concentration, they should continue beyond the timer rather than forcing artificial breaks.
Task batching groups similar activities to minimize context switches. Responding to all messages during designated periods rather than reacting immediately preserves cognitive continuity for primary development work. Physical exercise, adequate sleep, and mindfulness practices support overall cognitive resilience. Sleep in particular serves as the primary mechanism for restoring system two capacity, making consistent rest non-negotiable for sustained performance.
Workspace organization and notification management reduce environmental triggers for attention shifts. Tools that intelligently manage calendars and protect focus time help implement these practices at scale. Delegation of routine tasks to appropriate automation or AI assistance frees cognitive resources for higher-value activities.
Engineering Context for Human and Machine Systems
Context engineering addresses both human and artificial intelligence systems. For developers, clear documentation, consistent coding standards, and well-structured codebases reduce the mental effort required to understand and modify systems. When context is preserved, system two can focus on creative problem-solving rather than basic comprehension.
Artificial intelligence systems similarly require rich context to perform effectively. Large language models benefit from detailed prompts, relevant examples, and domain-specific knowledge. The same principles that help human developers maintain context—clear boundaries, explicit documentation, and systematic organization—enhance AI performance when integrated thoughtfully.
Modern AI coding assistants represent both opportunity and responsibility. When used with appropriate context, they augment human capabilities without replacing critical thinking. However, over-reliance on AI without sufficient system two engagement can lead to acceptance of suboptimal code that appears functional but lacks deeper quality. Balancing AI assistance with human judgment remains essential for maintaining code integrity.
Building Sustainable Development Practices
Organizations can support cognitive sustainability through intentional practices. Protected focus time, reduced meeting loads during deep work periods, and recognition of the costs of context switching contribute to better outcomes. Engineering workflows that minimize unnecessary interruptions while maintaining necessary collaboration create environments where developers can consistently access their full cognitive capabilities.
Individual developers benefit from self-awareness of their energy patterns and implementation of personal systems for protection and restoration. Regular reflection on work patterns, experimentation with different techniques, and honest assessment of code quality under varying conditions build more effective personal practices.
The goal extends beyond short-term productivity to sustainable careers in software development. By treating mental energy as a finite and valuable resource, developers and organizations can achieve higher quality outcomes while reducing burnout and turnover.
Technology continues to evolve, with AI assuming more routine tasks and shifting human roles toward system-level thinking and creative problem framing. The ability to manage cognitive resources effectively becomes increasingly valuable in this landscape. Developers who master these skills will maintain their effectiveness and competitive advantage regardless of technological changes.
Conclusion: Toward More Conscious Software Creation
Software development is fundamentally a cognitive activity requiring sustained mental effort and clear thinking. Understanding the mechanisms of attention, fatigue, and decision-making empowers developers to work more effectively. By applying principles from behavioral psychology to daily practices, teams can reduce unnecessary cognitive costs and preserve capacity for the most valuable aspects of their work.
The combination of thoughtful process design, appropriate tool usage, and individual self-management creates conditions where developers can consistently produce high-quality work while maintaining their well-being. In an industry characterized by rapid change and high demands, these skills become essential for long-term success and satisfaction.
Conscious management of mental energy transforms software development from a reactive, exhausting process into a sustainable, engaging craft. The investment in understanding and optimizing cognitive performance yields returns in code quality, innovation, and professional fulfillment.
Links:
[AWSReInvent2025] Accelerating E-Commerce Insights with Snowflake Intelligence: A Case Study on Decile’s Luma AI Analyst
Lecturer
Santiago Giraldo serves as Senior Director of Product Marketing for Artificial Intelligence at Snowflake. With over 15 years of experience in data and AI technology, Santiago specializes in bridging business needs with advanced technical solutions, focusing on generative AI and enterprise data platforms. He holds a background from Parsons School of Design – The New School and is based in the Denver Metropolitan Area.
Brian Neumann is Senior Vice President of Engineering at Decile, an e-commerce analytics platform. Brian leads engineering efforts to develop innovative data solutions for brands, emphasizing multi-tenant architectures and AI integration to enhance customer insights.
Abstract
This presentation explores the transformative potential of Snowflake Intelligence, a generative AI-powered feature set designed to enable natural language interactions with enterprise data. Santiago introduces the core principles of Snowflake Intelligence, addressing longstanding challenges in data accessibility and decision-making velocity. Brian then details Decile’s implementation, showcasing how the platform powers Luma, a custom AI analyst that democratizes e-commerce insights across organizational roles. The discussion highlights architectural strategies, trust mechanisms, and practical outcomes, illustrating how agentic AI can shift enterprises from reactive reporting to proactive, reasoned action.
Bridging the Gap Between Business and Data Teams
Enterprises often grapple with disparities in how business users and data teams interact with information. Business stakeholders require timely, actionable insights to drive decisions, yet data teams frequently dedicate substantial effort to producing static reports or dashboards. By the time these deliverables reach decision-makers, opportunities may have diminished, as insights arrive too late for effective intervention.
Snowflake Intelligence addresses this divide by empowering users—from executives to frontline employees—to pose complex questions in natural language and receive reasoned responses. Unlike traditional tools limited to surface-level queries (e.g., “What were sales last week?”), this innovation facilitates deeper inquiry, such as identifying underlying causes or forecasting future trends. It integrates data from disparate sources, including databases, customer platforms like Salesforce, and third-party enrichments, all within a secure, governed environment.
A key advantage lies in its enterprise readiness: features are native to the Snowflake platform, ensuring robust governance, security, and data quality. This approach fosters a “reasoning partner” dynamic, where AI not only retrieves data but also provides explanatory context, enabling high-confidence decisions in real time.
Core Principles and Capabilities of Snowflake Intelligence
Snowflake Intelligence rests on three foundational pillars: deep analysis, trust, and enterprise-grade security.
Deep analysis extends beyond descriptive reporting to prescriptive and predictive reasoning. Users can explore questions like “What headwinds threaten upcoming sales?” or “How can retention be improved?” by leveraging multimodal data—structured and unstructured—across the organization. Features such as research mode enable forward-looking investigations, drawing from comprehensive knowledge sources.
Trust is paramount in generative AI adoption, where hallucinations or opaque reasoning erode confidence. Snowflake mitigates this through verified answers, full traceability to original sources, and transparent explanations. Responses include reformulated queries, step-by-step reasoning, and direct links to underlying SQL, allowing verification down to individual data points.
Enterprise readiness ensures all operations occur within Snowflake’s governed ecosystem. Dynamic discovery provides clear explanations of results, while integrations with marketplace data and enterprise tools unify insights. This holistic design transforms data utilization, placing organizational knowledge at users’ fingertips for instantaneous, reliable exploration.
Decile’s Journey: From Traditional Analytics to AI-Driven Insights
Decile operates as an e-commerce analytics platform, serving over 100 leading brands by aggregating data from sources like Shopify, Magento, marketing channels, and enrichment providers such as Acxiom. The platform creates dedicated Snowflake data warehouses per client, overlaid with application experiences for lifecycle reporting and customer segmentation.
Initially, Decile’s dashboards aimed to surpass native platform reporting by stitching disparate data for richer views. However, brand variability—ranging from retail integrations to diverse product analytics—complicated dashboard flexibility. This led to increased complexity for non-technical users, who grew reliant on customer success teams, effectively positioning Decile as an outsourced data function.
Recognizing this barrier, Decile sought to empower clients directly through an AI analyst. Early prototyping with various frameworks revealed significant hurdles: building vector stores for semantic understanding, ensuring SQL accuracy, providing visualizations, and establishing evaluation mechanisms. These challenges posed substantial investment risks for a startup.
Snowflake Intelligence emerged as an ideal solution, leveraging existing governed warehouses and dbt semantic models. Implementation involved extending dbt documentation with metadata (aliases, synonyms, sample values) to inform semantic views—YAML-defined structures describing dimensions, measures, relationships, and natural language descriptions.
Cortex Search services enhanced fuzzy matching for free-form queries, while verified queries predefined complex calculations (e.g., retention cohorts). A custom library automated provisioning of semantic views, search services, and agents via deployment pipelines.
Implementation Outcomes and Future Directions at Decile
Rapid deployment enabled pilot testing through Snowflake’s UI, gathering feedback to refine models. API access facilitated seamless integration into Decile’s application, branding the experience as Luma—a conversational AI analyst.
Users reported substantial time savings, with marketers and executives conducting analyses previously requiring extensive report stitching. Visible thinking steps—detailing semantic mappings and reasoning—built confidence, reducing perceived black-box risks. Support queries dropped 75% among adopters, as users self-served segments for activation.
Luma’s impact extends to operational efficiency: quicker market entry, reduced custom report demands, and empowered segmentation (e.g., identifying repeat purchasers for subscriptions).
Looking ahead, Decile plans per-brand instruction customization to capture nuances (e.g., subscription vendors, wholesale handling). Aspirations include user-contributed context for vertical-specific analyses and scheduled alerting for anomalies, emulating a proactive human analyst.
Implications for Enterprise AI Adoption
This collaboration exemplifies how Snowflake Intelligence lowers barriers to agentic AI in specialized domains. By providing turnkey frameworks—semantic views, APIs, and observability—platforms like Decile accelerate innovation without prohibitive development overhead.
Broader implications include democratized data access, reducing silos and delays while upholding trust through traceability. For e-commerce, this translates to agile responses to market dynamics, personalized strategies, and sustained growth.
Ultimately, such integrations signal a shift toward AI-augmented workflows, where tools complement human expertise, fostering cultures of data-driven agility and innovation.
Links:
[MiamiJUG] Retrieval-Augmented Generation: Building Deterministic AI for Production
Lecturer
Frank Greco is a Java Champion, enterprise architect, and senior consultant specializing in Artificial Intelligence and Cloud computing. He is the founder and Chairman of NYJavaSIG and a co-author of JSR #381 “VisRec,” the Java API for visual recognition. Frank is a recognized educator and technical leader who has presented at major global conferences including JavaOne, DevNexus, and Devoxx.
Abstract
This article provides an analytical framework for integrating Large Language Models (LLMs) into production Java environments using Retrieval-Augmented Generation (RAG). By moving beyond simple chat interfaces to programmatic API access, developers can build AI systems that are grounded in verified enterprise data. The analysis explores prompt engineering methodologies—such as Few-Shot and Chain of Thought (CoT)—and the architectural role of vector databases in mitigating model hallucinations while ensuring data security and version control.
Methodologies in Prompt Engineering
Prompting is the primary mechanism for steering the behavior of a neural network. Unlike traditional programming, prompting is probabilistic rather than deterministic. Frank identifies several advanced techniques to improve model reliability:
- Zero-Shot and Few-Shot Learning: Few-shot prompting provides the model with specific examples of the desired input-output pattern, significantly improving the accuracy of complex tasks.
- Chain of Thought (CoT): This instructs the model to “think step-by-step,” detailing its reasoning process before providing a final answer. This methodology is critical for reducing logical errors.
- Persona Identification: Assigning a specific role to the model (e.g., “Act as a Java security expert”) helps contextualize the response and refine the output tone.
Architectural Implementation: Retrieval-Augmented Generation (RAG)
To overcome the limitations of an LLM’s static training data, enterprises utilize RAG to ground the model in real-time, private data. In a RAG architecture, a user query is first used to search a knowledge base—typically a Vector Database—for relevant documents. This retrieved context is then injected into the prompt, allowing the LLM to generate an answer based on specific facts rather than general probabilities.
This approach offers several production-grade benefits:
- Reduced Hallucinations: By providing the model with the necessary facts, the likelihood of it “making up” information is significantly decreased.
- Data Security: RAG allows models to use private company information without that data being used to train the underlying public model.
- Traceability: Responses can be cited back to specific source documents found in the vector database.
Production Challenges and Ethical Considerations
Implementing AI at scale introduces significant engineering overhead. Developers must manage Prompt Versioning to ensure consistent behavior across deployments and navigate the legal implications of AI-generated content. Furthermore, because these are probabilistic systems, Frank warns that if a wrong answer poses a high risk to the business, generative AI may not be the appropriate solution. Engineers must balance the productivity gains of AI with the need for rigorous safety guardrails and human-in-the-loop verification.
Links:
[AWSReInvent2025] The Next Frontier in Financial Systems: Architecting Transformer-based Foundation Models for Real-Time Payments
Lecturer
Sudeep Kalindi is a Principal Solution Architect at Amazon Web Services (AWS), where he focuses on building scalable AI and machine learning solutions for the global financial services industry. With a deep expertise in high-frequency transaction systems and cloud infrastructure, Sudeep advises major financial institutions on modernizing their fraud detection and personalization engines using advanced neural network architectures.
Pahal Patangia is the Global Head of Business for the Payments Industry at NVIDIA. He has spent nearly five years at NVIDIA accelerating the adoption of AI and accelerated computing within the payments ecosystem. Pahal works closely with banks, fintechs, and payment processors to deploy large-scale foundation models that transform transactional data into real-time business value.
Abstract
As digital transactions explode in volume and complexity, traditional rule-based and machine learning models are reaching their limits in combating sophisticated fraud and providing personalized customer experiences. This article examines the emergence of transformer-based foundation models as the “next frontier” for financial systems. Unlike prior models that treated transactions as isolated events, transformers excel at capturing long-term dependencies and sequential patterns in tabular transactional data. The discussion details the technical advantages of “attention” mechanisms in finance, the role of NVIDIA’s accelerated computing in training these massive models, and the deployment strategies on AWS that enable real-time inference. By integrating tabular foundation models with Graph Neural Networks (GNNs), financial institutions can achieve unprecedented accuracy in fraud detection and customer behavioral analysis.
The Evolution of Payment Systems: Beyond Rule-Based Models
The world of digital transactions has undergone a massive expansion, with billions of events flowing through systems daily via credit cards, QR codes, contactless payments, and cross-border transfers. This explosion in volume has been matched by an increase in the complexity of financial crime. Fraudsters now leverage generative AI and chatbots to simulate synthetic identities and execute complex, multi-stage attacks.
Historically, payment systems relied on rules-based engines or traditional machine learning models (such as Gradient Boosted Trees) that analyzed data in a “flat” or non-sequential manner. While effective for basic anomalies, these systems often fail to resolve the deep contextual history of a customer. They may miss the subtle shift in behavior that signals a compromised account because they lack the “memory” to connect transactions across long periods. The industry’s challenge is to find a middle way: leveraging the cutting-edge innovation of deep learning while maintaining the explainability and governance required by global financial regulators.
Transformers for Tabular and Sequential Financial Data
The primary innovation discussed is the application of the transformer architecture—originally designed for Natural Language Processing (NLP)—to tabular financial data. Transformers introduce the “attention” mechanism, which allows a model to weigh the importance of different parts of a transaction sequence differently.
In a financial context, this means the model can distinguish between a user’s stable, long-term habits and their recent, potentially anomalous interests. For instance, if a customer who has lived in the same city for ten years suddenly makes a high-value purchase in a foreign country, a transformer can analyze the sequence leading up to that event—looking for “warm-up” transactions or patterns indicative of travel—rather than just flagging the high dollar amount.
Key technical advantages include:
- Contextual Understanding: Transformers treat the entire transaction history of an entity (customer, merchant, or card) as a sequence, similar to a sentence in a language model.
- Solving Vanishing Gradients: Unlike Recurrent Neural Networks (RNNs), transformers can capture long-range dependencies without the performance degradation typically associated with long sequences.
- Multi-Modal Integration: They can blend different data “worlds”—such as event logs, clickstream data, and structured transaction records—into a single global embedding that provides a 360-degree view of an entity.
NVIDIA Accelerated Computing in Financial AI Factories
The training and deployment of these large-scale foundation models require immense computational power, a concept referred to as the “AI Factory.” NVIDIA’s accelerated computing platform is the engine behind these factories, providing the necessary throughput for processing millions of transactions in real time.
NVIDIA’s contribution extends beyond hardware (GPUs like the H100 and Blackwell) to specialized software frameworks. For example, the use of the NVIDIA AI Enterprise suite on AWS allows for efficient tuning and scaling of these models. Furthermore, the integration of Graph Neural Networks (GNNs) with transformers allows systems to not only understand the sequence of transactions but also the relationships between different entities (e.g., shared IP addresses or common merchants among fraudulent accounts). This combined approach enables “pattern mining” at a scale previously thought impossible.
Code Sample: Conceptual Transformer Layer for Transaction Sequences
import torch
import torch.nn as nn
class TransactionTransformer(nn.Module):
def __init__(self, input_dim, embed_dim, num_heads, num_layers):
super(TransactionTransformer, self).__init__()
'''Project tabular transaction features into an embedding space'''
self.embedding = nn.Linear(input_dim, embed_dim)
'''Transformer Encoder Layer to capture sequential dependencies'''
encoder_layer = nn.TransformerEncoderLayer(d_model=embed_dim, nhead=num_heads)
self.transformer = nn.TransformerEncoder(encoder_layer, num_layers=num_layers)
'''Output layer for fraud classification (binary: 0 or 1)'''
self.classifier = nn.Linear(embed_dim, 1)
def forward(self, x):
'''# x shape: [batch_size, sequence_length, input_dim]'''
x = self.embedding(x)
x = x.permute(1, 0, 2) # Transformer expects [seq_len, batch, embed]
output = self.transformer(x)
logits = self.classifier(output[-1]) # Use the last transaction's context
return torch.sigmoid(logits)
print("Financial Transformer initialized for sequential analysis.")
Real-Time Fraud Detection and Personalized Banking
The ultimate goal of deploying these models on AWS is to move from reactive fraud detection to proactive prevention and hyper-personalization. By leveraging Amazon SageMaker, financial institutions can run “target experiments” and deploy models into a secure, scalable production environment.
The business impact is multifaceted:
- Reduced False Positives: By understanding context, models can reduce the number of legitimate transactions being declined, improving customer satisfaction.
- Authorization and Routing Optimization: Real-time insights allow for smarter routing of transactions through payment networks, reducing costs and increasing success rates.
- Hyper-Personalization: Beyond fraud, these models understand customer intent, allowing banks to offer relevant products and services at the precise moment of need.
While it is still early in the adoption cycle, initial experiments show performance improvements in the range of 1% to 2% in fraud detection accuracy—a seemingly small number that translates into billions of dollars in saved revenue across the global economy.
Conclusion
The intersection of transformer architectures, NVIDIA’s accelerated computing, and AWS’s scalable infrastructure is redefining what is possible in financial services. By treating transaction data as a language to be understood rather than a set of rows to be filtered, the industry is building a more secure and personalized future for global payments. As these “global embeddings” continue to evolve, they will ultimately provide a comprehensive context for every customer, product, and entity in the financial ecosystem.
Links:
[DevoxxBE2025] How Browsers Really Load Web Pages
Lecturer
Robin Marx holds the position of Web Performance Specialist at Akamai Technologies, with expertise in protocols including HTTP/2, HTTP/3, and QUIC. Possessing a doctorate in Computer Science from KU Leuven, Belgium, he has contributed extensively to scholarly articles on web efficiency and formerly conducted research at the institution prior to his industry move.
Abstract
This article investigates the sophisticated procedures browsers utilize in retrieving and displaying web content, emphasizing resource hierarchies, HTTP evolutions, and variances in browser executions. It dissects the management of parsing impediments, anticipatory scanning, and hints like preloads to refine acquisition sequences. Via thorough review of timing diagrams and precedence frameworks, the inquiry unveils procedural disparities, their historical backdrops, and consequences for digital construction efficacy. Anticipated progress in measurements and platform rivalry is contemplated, stressing the trajectory toward uniform and proficient online encounters.
Core Operations in Content Retrieval
Browsers engage in elaborate routines when acquiring and manifesting online materials, surpassing mere successive acquisitions. Envision a fundamental site composition: it could encompass blocking scripts that halt depiction until wholly obtained, postponed scripts activating after document assembly, and visual or auxiliary assets. These components require meticulous coordination to guarantee streamlined retrieval, particularly under protocol restrictions.
In earlier times, HTTP/1 confined simultaneous acquisitions to one per link, inciting browsers to initiate several links—commonly up to six per host—to concurrentize retrievals. This demanded astute choice of preliminary assets to prevent postponing vital ones. As an example, a straightforward sequential examination of markup might overlook crucial routines at the file’s conclusion, resulting in suboptimal efficacy.
The emergence of HTTP/2 and HTTP/3 brought interleaving, permitting numerous acquisitions via a solitary link. Nevertheless, this fails to eradicate constrictions; hosts continue to encounter capacity limits regulated by overcrowding mitigation and gradual initiation methods. Hence, browsers designate hierarchies to assets, conveying significance to the host. Essential elements such as style sheets and routines obtain elevated hierarchies (e.g., “utmost” or “elevated”), whereas postponed items receive diminished ones.
Practically, this hierarchy arrangement appears in HTTP/3 as a specific “hierarchy” header, observable in inspection utilities. Hosts arrange incoming acquisitions by these hierarchies, releasing replies as capacity permits. This system seeks to favor perceived efficacy, assuring apparent material arrives promptly.
Moreover, browsers augment this with supplementary algorithms. An anticipatory examiner, for instance, swiftly reviews arriving markup bytes to detect auxiliary assets prematurely, prior to complete examination. This facilitates proactive acquisitions for elements like typefaces cited in styles, alleviating revelation postponements. Asset cues such as anticipatory linkage and preparatory connection additionally steer this routine, allowing browsers to foresee requirements.
Asset Hierarchy Approaches and Platform Conducts
The designation of hierarchies diverges considerably, affecting how sites materialize across platforms. Blocking assets generally secure premier hierarchy, yet subtleties proliferate. For head-located blocking routines, primary browsers concur on supreme urgency. However, postponed routines, performed following structure formation, are demoted to minor or intermediate, mirroring their secondary essence.
Visuals exhibit a more pronounced variance. In one browser, visuals commence at intermediate hierarchy but may ascend if judged “visible” through arrangement evaluation. Another sustains uniform minor hierarchy for visuals, whereas a third frequently handles them comparably but with distinct scheduling. This influences timing representations—diagrams illustrating acquisition chronologies—where one platform might integrate visual retrievals sooner than rivals.
Anticipatory cues add complexity. Designed for delayed-revealed assets like style-embedded typefaces, anticipatory signals indicate forthcoming utility. One platform reduces preloaded typefaces from utmost to elevated, presuming deferred relevance, while another promotes them from minor to intermediate. A third stays apathetic, designating steady hierarchies irrespective.
The acquisition hierarchy attribute permits creators to sway this, elevating or lowering hierarchies. Yet, adherence varies: one platform disregards elevated acquisition hierarchy on typeface anticipatories, retaining them at elevated, while another boosts them markedly. Minor acquisition hierarchy, inversely, incites reductions across platforms, but to diverse extents—two descend two tiers, one one.
These conducts derive from protocol architectures striving for optimal capacity utilization. In HTTP/2, hierarchies constitute a reliance structure, although numerous hosts streamline to fundamental ordering. HTTP/3 refines this with overt headers, yet platform construals yield diverse results. For illustration, in a site with blended routines and visuals, one platform might postpone non-essential acquisitions until essential ones conclude, another could disperse them, and a third might retrieve advantageously.
Relative Assessment of Platform Executions
Variances originate from diverse doctrines and realizations, frequently anchored in chronological settings. One platform’s proactive hierarchy favors apparent velocity, promoting visible visuals to accelerate optical fulfillment. Another favors restraint, maintaining non-vital assets minor to evade obstructing vital routes. A third’s method, shaped by its core framework, commonly yields singular timing diagrams, occasionally postponing acquisitions deliberately until reliances settle.
Timing diagrams exemplify these distinctly. On a basic site with blocking routines, postponed ones, and visuals, one platform might finalize vital downloads before commencing others, yielding a tiered configuration. Another could intermingle low-hierarchy items, exploiting interleaving more dynamically. A third’s configurations might display advantageous retrieval, with relaxed conformity to hierarchies.
Such divergences pose hurdles for creators, as sites efficient in one platform may falter in another. For example, bespoke typefaces: one platform’s elevated hierarchy guarantees swift text depiction, but another’s minor designation might defer, inducing unformatted text flashes. Anticipatory exacerbates this; while aimed at hastening, it can unintentionally modify hierarchies adversely.
Hosts exacerbate matters by mishandling hierarchies. Many, such as certain servers, disregard them or execute partial backing, resulting in arrival-order dispatching. This weakens platform cues, particularly in HTTP/2 where reliance structures are intricate. Even adherent hosts might not synchronize with platform anticipations, as protocols permit adaptability in construal.
These inconsistencies illuminate a segmented environment, where protocol aspirations conflict with pragmatic realizations. Creators must maneuver this by evaluating across platforms, utilizing utilities like consoles to examine hierarchies and timing diagrams.
Outlook for Enhanced Uniformity and Ramifications
Developments vow alleviation of these hurdles. Inter-platform vital web indicators, encompassing major content depiction and response to subsequent depiction, are broadening through collaborative initiatives. One platform’s embrace will elucidate efficacy oversights, facilitating focused refinements.
Platform rivalry on mobile systems, propelled by legal actions against monopolistic practices, could instill authentic variety. Presently, all mobile browsers employ a uniform core, standardizing conducts and indicator gathering. Permitting alternative cores nurtures novelty, possibly aligning retrieval tactics via rivalrous forces.
Ramifications for digital creation are significant. Comprehending these routines empowers superior asset cueing and hierarchy, augmenting inter-platform uniformity. Although inconsistencies endure, they are less devastating than former periods, where arrangements fundamentally fractured.
Ultimately, browser retrieval encapsulates the online realm’s variety—irritating yet essential for durability. Accepting this, with utilities and advancing norms, secures persistent advancement toward proficient, inclusive encounters.
Links:
- Lecture video: https://www.youtube.com/watch?v=n34UjuPKIYI
- Robin Marx on LinkedIn: https://be.linkedin.com/in/rmarx
- Robin Marx on Twitter/X: https://twitter.com/programmingart
- Akamai Technologies website: https://www.akamai.com/
[AWSReInforce2025] From compute to code: Expanding vulnerability scanning across the SDLC (APS203)
Lecturer
AWS security specialists drive the evolution of Amazon Inspector from infrastructure scanning to comprehensive SDLC integration. Their work focuses on shifting vulnerability management left while maintaining developer velocity and operational scalability.
Abstract
The presentation traces vulnerability management from runtime compute assessment to proactive code-level analysis throughout the software development lifecycle. Through Amazon Inspector’s expanded capabilities, it demonstrates how organizations reduce risk earlier, accelerate remediation, and align security with modern delivery practices.
Traditional Vulnerability Management Limitations
Legacy approaches focus on production systems:
Deploy → Scan → Patch → Repeat
This reactive model creates:
- Large attack surface exposure windows
- Developer-security team friction
- Patch management overhead
The iceberg metaphor illustrates that production workloads represent only the visible tip; source code, dependencies, and build artifacts constitute the submerged risk mass.
Shift-Left Security Integration Patterns
Amazon Inspector now spans the entire SDLC:
stages:
- code_commit:
scan: SCA, secrets
- build_pipeline:
scan: container_images
- deploy:
scan: EC2, Lambda, ECR
- runtime:
monitor: active_exploitation
Integration with CodePipeline enables automatic scanning at commit, build, and deploy phases.
Software Composition Analysis (SCA)
Inspector examines dependencies:
{
"package": "log4j-core",
"version": "2.14.1",
"vulnerability": "CVE-2021-44228",
"exploitability": "ACTIVE"
}
Findings include EPSS scores, exploit maturity, and reachability analysis—identifying if vulnerable code paths are actually executable.
Secrets Detection and Prevention
The service identifies hardcoded credentials:
detectors:
- aws_access_key
- github_token
- private_key_material
Integration with GitHub Actions fails builds containing secrets, preventing credential leakage at source.
Container and Infrastructure Scanning
Inspector assesses:
- ECR repositories during push
- ECS/Fargate tasks at launch
- Lambda functions on deployment
Continuous monitoring detects new vulnerabilities in running workloads without rescan triggers.
Developer Experience and Remediation Acceleration
Findings appear in IDEs via CodeWhisperer:
\# Vulnerability: SQL injection in query parameter
\# Fix: Use parameterized statements
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
Pull request comments provide contextual remediation guidance, reducing mean time to fix from weeks to hours.
Risk-Based Prioritization Framework
Inspector implements multi-dimensional scoring:
CVSS × EPSS × Reachability × Business Criticality = Risk Score
This focuses remediation on vulnerabilities that matter—exploitable, in-use, and impactful.
Operational Outcomes and Metrics
Organizations achieve:
- 85% reduction in production vulnerabilities
- 60% faster remediation cycles
- 40% decrease in security-development friction
The 15-day free trial enables immediate risk assessment across repositories and workloads.
Conclusion: Proactive Security as Development Practice
Amazon Inspector transforms vulnerability management from periodic operations task into continuous development practice. By illuminating risks from code commit through runtime execution, organizations build security into the delivery pipeline rather than bolting it on afterward. This shift-left approach enables confident innovation at cloud speed.
Links:
[MunchenJUG] Strategic Approaches to Mitigating Software Defects in Java Development (08/Jul/2025)
Lecturer
Tagir Valeev is a distinguished software engineer and a prominent figure in the Java ecosystem, currently serving as a Technical Lead at JetBrains. His professional focus lies in the advancement of Java static analysis within IntelliJ IDEA, a critical tool for automated bug detection. Tagir is an OpenJDK committer and a Java Champion, honors that reflect his deep technical contributions to the language’s core. He is also the author of the authoritative text “100 Java Mistakes and How to Avoid Them”, which systematically classifies common programming errors.
Abstract
The pervasive nature of software defects necessitates a multi-layered defense strategy rather than a single technical solution. This article examines the methodology for reducing bug density in Java applications by exploring the classification of “tiny but disastrous” repeatable errors. Central to this analysis is the “Swiss Cheese Model” of software quality, which posits that a combination of independent defensive layers—such as static analysis, unit testing, and code review—is significantly more effective than over-investing in any single approach. By investigating real-world code snippets and the limitations of 100% test coverage, this study provides a framework for developers to understand the trade-offs and synergies between modern quality assurance tools.
The Taxonomy of Modern Software Defects
Software bugs vary significantly in complexity and scope. While large-scale architectural failures often make for compelling post-mortem analyses, the majority of developer time is occupied by tiny, local errors. These defects, though appearing minor—such as a single incorrect character or an erroneous one-line construct—can lead to catastrophic system failures in production.
The critical characteristic of these small-scale bugs is their repeatability. Because they recur across different projects and developers, they can be systematically classified and studied. Understanding these patterns allows developers to proactively identify potential pitfalls during the implementation phase. Furthermore, repetition is often the catalyst for such errors; copying and pasting code blocks without rigorous verification is a frequent source of “repeatable” defects that elude casual observation.
The Limitations of Individual Quality Assurance Layers
A common misconception in software engineering is the belief in a “Silver Bullet”—a single technique, such as Test-Driven Development (TDD) or advanced static analysis, that can eliminate all defects. Empirical evidence suggests that each individual layer of defense eventually reaches a plateau of efficiency.
The Paradox of Total Test Coverage
Striving for 100% test coverage often results in diminishing returns. In complex libraries, achieving the final percentages of coverage can require significantly more effort than the actual implementation of the feature. Moreover, high coverage metrics do not guarantee the absence of bugs; code that is executed during a test run can still contain logical flaws that the test assertions fail to capture.
Static Analysis and Code Review
Static analysis tools like FindBugs (now SpotBugs) and the integrated analyzers in modern IDEs offer the “revelation” of finding bugs without code execution. However, these tools are not infallible, as they are subject to both false positives—reporting errors where none exist—and false negatives—failing to detect actual issues. Similarly, code reviews and pair programming provide essential human oversight, but they are limited by the reviewers’ cognitive load and familiarity with the specific bug patterns being introduced.
The Swiss Cheese Model of Defensive Programming
The most effective strategy for defect mitigation is derived from the “Swiss Cheese Model,” originally applied in aviation and medical engineering. This model represents each defensive technique as a slice of Swiss cheese; while each slice has “holes” (limitations or specific types of bugs it cannot catch), stacking multiple slices significantly reduces the likelihood that a defect will pass through all layers into production.
In a robust development pipeline, these layers typically include:
- Static Analysis: Catching syntactical and common logical patterns early.
- Code Review/Pair Programming: Leveraging peer insight to spot errors that automated tools might miss.
- Unit and Integration Testing: Verifying functional requirements and edge cases.
- Emerging AI Tools: Utilizing modern large language models to provide an additional, albeit experimental, layer of scrutiny.
By distributing resources across these diverse layers, teams can ensure that if one layer fails, another is likely to intervene.
Conclusion
Mitigating software bugs is an “endless struggle” that cannot be completely won, but it can be managed through strategic, diversified defenses. Rather than seeking a single bulletproof solution, developers should focus on understanding repeatable bug patterns and implementing a multi-layered quality assurance process. The integration of specialized static analysis, thorough peer review, and balanced testing creates a resilient ecosystem capable of catching disastrous errors before they impact the end user.
Links:
[NDCOslo2024] Ways to Optimize Cloud Disaster Recovery Cost – Natalie Serebryakova
In the volatile realm of cloud continuity, where resilience wrestles with rising expenditures, Natalie Serebryakova, a seasoned staff cloud engineer, unveils strategic stratagems to streamline AWS disaster recovery (DR) costs. With a keen eye on efficiency, Natalie navigates the nuances of DR architectures—pilot light to warm standby—offering a roadmap to reconcile robustness with fiscal restraint. Her discourse, distilled from enterprise engagements, demystifies billing complexities and champions resource rationalization, ensuring recovery readiness without profligate spending.
Natalie commences with a clarion call: DR, a non-negotiable necessity, need not necessitate exorbitant outlays. Her mission: equip engineers with acumen to architect economical, effective recovery frameworks, balancing business imperatives with budgetary boundaries.
DR Archetypes: From Pilot Light to Warm Standby
Natalie delineates DR’s spectrum: pilot light, a minimal ember—core components dormant, ignited on demand; warm standby, a robust readiness—replicas running, poised for promotion. She contrasts: pilot light’s parsimony suits sporadic surges, while warm standby’s preparedness prioritizes promptness.
Selection hinges on strategy: recovery time objectives (RTO) and recovery point objectives (RPO) dictate design. Natalie advises: map mission-critical mandates—databases demand duplication, static stores suffice with snapshots—ensuring alignment with enterprise exigencies.
Banishing Zombie Resources: Eradicating Excess
Zombie resources—idle instances, orphaned objects—bleed budgets. Natalie advocates audits: AWS Cost Explorer exposes extravagance, tagging tracks tenancy. Her tactic: terminate transients—unused EBS volumes, unattached IPs—reclaiming resources rigorously.
Automation augments austerity: CloudWatch alarms trigger terminations, Lambda lances lingering loads. Natalie’s narrative: proactive pruning preserves pennies, fortifying fiscal fortitude.
Billing Brilliance: Mastering AWS Economics
AWS’s billing labyrinth bewilders: compute costs, storage surcharges, data transfer tolls. Natalie illuminates: reserved instances reap rebates—commitments carving costs; spot instances, though volatile, vie for value in non-critical niches. Her caveat: DR demands dependability, sidelining spot’s savings for stability.
Cost allocation tags, she asserts, clarify consumption—departmental delineations demystify disbursements. Natalie’s nudge: engage finance, forecast flavors—memory-optimized, compute-centric—optimizing outlays.
Automation’s Ascendancy: Streamlining Scalability
Automation anchors efficiency: auto-scaling adjusts arsenals, serverless setups shrink spend. Natalie showcases: AWS Auto Scaling synchronizes surges, ECS economizes elasticity. Her maxim: script shutdowns, schedule sweeps—DR’s dynamism thrives on disciplined design.
Her vision: cost-conscious engineering, where analysis and automation converge, crafts resilient, resource-savvy recoveries.
Links:
[VoxxedDaysTicino2026] Technical Enshittification: Why Everything in IT is Horrible Right Now and How to Fix It
Lecturer
Baruch Sadogursky is the Head of Developer Relations at TuxCare, with a distinguished career in Java and DevOps ecosystems. A Java Champion and Microsoft MVP for AI, he has authored books on these topics and is known for his candid analyses of industry trends.
Abstract
This article examines Baruch Sadogursky’s critique of technical enshittification, where software platforms degrade user experiences after gaining dominance. It explores the underlying causes, such as excessive complexity and bloat, and proposes remedies through AI, smart tooling, and refined workflows. By analyzing real-world examples and systemic issues, the discussion highlights methodologies for restoring efficiency and innovation in IT.
The Phenomenon of Enshittification in Technology
Baruch Sadogursky introduces the concept of technical enshittification as an extension of Cory Doctorow’s idea, where platforms initially attract users but subsequently exploit them at the expense of quality. In software, this manifests as bloated applications, sluggish performance, and accumulating bugs that erode reliability. He illustrates this with examples like operating systems losing files or password managers suffering repeated breaches, underscoring how such degradation is not isolated but systemic. The contexts reveal that this trend stems from economic pressures favoring monetization over maintenance, leading to innovation that often amounts to superficial changes rather than substantive improvements. The implications are profound, as they diminish developer productivity and user satisfaction, fostering a cycle of frustration in the industry.
Systemic Causes and Their Interconnections
The talk delves into how complexity has become an obstacle course in software development, with layers of tools, approvals, and abstractions slowing progress. Baruch points to attention fragmentation, where developers spend minimal time coding—around 52 minutes daily—due to distractions like meetings and context switching. He references studies showing it takes 25 minutes to refocus after interruptions, amplifying the toll of lengthy builds or code reviews. Organizational habits, such as frequent reorgs, further destroy shared knowledge, while technical debt accumulates from unrefactored legacies. Bloat exacerbates vulnerabilities, as more code lines create more attack surfaces, evidenced by rising malicious packages in repositories. The contexts connect these to broader industry dynamics, where rapid feature additions outpace quality controls. The implications include stalled innovation and heightened risks, as teams grapple with outdated contexts rather than advancing core functionalities.
AI as a Double-Edged Sword in Development
Baruch views AI as a catalyst that accelerates code generation but risks compounding technical debt through unvetted outputs. While it promises faster features, it often introduces bugs and vulnerabilities, as seen in Java’s poor performance on AI security benchmarks. He critiques the “credit card” mindset, where AI enables unchecked experimentation, leading to more complexity. However, he advocates for its responsible use in context engineering—compressing knowledge for relevance and expanding it thoughtfully. Spec-driven development emerges as a safeguard, where high-level specs guide agents, ensuring traceability. The contexts highlight the need for integrity chains to verify AI-generated code against intentions. The implications suggest AI can revitalize workflows if paired with human oversight, but without it, it perpetuates enshittification.
Organizational Reforms and Workflow Optimizations
To combat these issues, Baruch recommends streamlining processes to minimize distractions and preserve context. Agile principles, when applied purely, encourage reactive planning over rigid foresight, allowing small bets to test assumptions iteratively. DevOps practices, like automation and “you build it, you run it,” offload context to systems, reducing manual toil. Management should focus on documentation of decisions and protecting focus time. The contexts draw from attention research, showing how interruptions fragment productivity. The implications include enhanced efficiency, where teams reclaim coding time and foster cultures of continuous improvement.
Reclaiming Joy and Progress in Software Engineering
In conclusion, Baruch urges embracing these reforms to restore the joy of building software. By prioritizing context preservation and leveraging AI judiciously, organizations can escape enshittification’s grip. The talk serves as a call to action, reminding developers they are not alone in facing these challenges and that proactive changes can lead to meaningful progress.
Links:
[AWSReInvent2025] Maximizing Block Storage Performance for High-Intensity Workloads: A Technical Analysis of io2 Block Express and the Nitro System
Lecturer
Mark Olsen and Jody Berenblatt are distinguished engineering and product leaders at Amazon Web Services, specializing in high-performance block storage. Mark Olsen serves as a Principal Product Manager for Amazon EBS, where he focuses on the architectural evolution of Provisioned IOPS volumes to meet the demands of mission-critical enterprise applications. Jody Berenblatt, a Senior Technical Product Manager, brings extensive expertise in the integration of storage subsystems with the AWS Nitro System and the optimization of storage networking protocols. Their work has been pivotal in the development of io2 Block Express, a storage tier designed to provide SAN-like performance in the cloud.
Abstract
This article provides a comprehensive examination of the technical foundations and performance characteristics of high-intensity block storage within the Amazon Elastic Block Store (EBS) ecosystem. Centered on the io2 Block Express architecture, the analysis explores how the integration of the AWS Nitro System, the Scalable Reliable Datagram (SRD) protocol, and Multi-Attach NVMe reservations enables ultra-low latency and high-throughput capabilities for data-intensive workloads such as SAP HANA, Oracle, and Microsoft SQL Server. The discussion details the methodology for managing tail latency, the benefits of decoupled storage architectures, and the operational strategies required to maximize I/O performance in a distributed cloud environment.
Infrastructure Foundations: The Evolution of Provisioned IOPS
The landscape of enterprise computing has shifted toward workloads that demand not only high throughput but also extreme consistency in I/O operations per second (IOPS). For decades, on-premises Storage Area Networks (SANs) were the only viable option for these applications. However, the maturation of Amazon EBS, particularly the transition from io1 to the io2 Block Express architecture, has redefined the capabilities of cloud-native block storage. The fundamental challenge in high-intensity storage is the management of latency, which is often the primary bottleneck for database performance.
In traditional storage models, performance was often tethered to the physical limitations of the disk or the controller. In the modern AWS architecture, the storage is decoupled from the compute instance, connected via a dedicated high-speed network. This separation allows for independent scaling of compute and storage resources but introduces the necessity for highly optimized networking to maintain sub-millisecond latency. The io2 Block Express volumes are engineered to provide up to 256,000 IOPS and 4,000 MB/s of throughput per volume, offering a level of performance that satisfies even the most demanding transactional databases.
Architecture of io2 Block Express: Performance and Durability
The architecture of io2 Block Express represents a paradigm shift in how block storage is provisioned and managed. Unlike standard volumes, io2 Block Express is designed to handle “high-intensity” workloads, defined by their sensitivity to latency and their requirement for high durability. These volumes provide a durability rating of 99.999%, which is a ten-fold improvement over standard io1 volumes. This reliability is achieved through sophisticated replication techniques across multiple physical hardwares within an Availability Zone.
A critical innovation in this architecture is the way it handles I/O operations. By utilizing the Nitro System, the overhead of the hypervisor is removed, allowing the EBS service to communicate directly with the instance’s memory. This “Block Express” layer acts as a high-performance interface that minimizes the processing time required for each I/O request. For applications like SAP HANA, where the speed of logging and data loading is critical, the reduced overhead translates directly into faster business processing cycles.
Networking Innovations: Scalable Reliable Datagram (SRD)
Perhaps the most significant technical advancement in maximizing block storage performance is the implementation of the Scalable Reliable Datagram (SRD) protocol. Traditional TCP protocols, while reliable, are prone to “head-of-line blocking,” where a single lost packet can delay the entire stream of data. In a high-performance storage environment, this creates “tail latency”—spikes in response time that can disrupt database synchronization and performance.
SRD solves this by utilizing multipath routing. Instead of sending data down a single network path, SRD spreads the traffic across as many as 64 different paths simultaneously. If a specific network switch becomes congested or a link fails, the protocol automatically reroutes the data without the latency spikes associated with TCP retransmissions. This protocol is implemented directly in the Nitro Cards, ensuring that the heavy lifting of network management does not consume CPU cycles on the user’s EC2 instance. The result is a more consistent “p99” latency profile, which is essential for maintaining stable performance in clustered environments.
Multi-Attach NVMe Reservations and High Availability
For enterprise applications requiring high availability, the ability for multiple EC2 instances to attach to a single EBS volume is a critical requirement. io2 Block Express supports Multi-Attach, allowing up to 16 Nitro-based instances to access the same volume simultaneously. This feature is particularly valuable for clustered file systems and applications that require shared storage for failover or parallel processing.
To manage concurrent access without data corruption, AWS implemented Multi-Attach NVMe Reservations. Based on the NVMe standard for persistent reservations (similar to SCSI-3 PR), this technology allows one instance to “reserve” the volume, ensuring that only authorized nodes can perform write operations. In the event of an instance failure, the reservation can be quickly cleared and reassigned to a healthy node, minimizing downtime. This mechanism provides the coordination layer necessary for complex deployments like Oracle RAC or SAP environments, where data integrity across multiple nodes is non-negotiable.
Observability and Performance Tuning for Enterprise Workloads
Achieving maximum performance requires a sophisticated approach to observability. Many administrators focus on average latency, but in high-intensity workloads, the “outliers” or tail latency are what truly matter. AWS provides tools such as Amazon CloudWatch and EBS Volume Insights to monitor these metrics in real-time. A key metric is the “Queue Depth,” which represents the number of pending I/O requests for a volume. To reach the full potential of an io2 Block Express volume (e.g., 256,000 IOPS), the application must maintain a sufficient queue depth—often 128 or higher—to keep the storage pipeline full.
// Example AWS CLI command to modify an EBS volume to io2 with high provisioned IOPS
aws ebs modify-volume \
--volume-id vol-0123456789abcdef \
--volume-type io2 \
--iops 100000
Furthermore, the choice of the EC2 instance type is paramount. Performance is not solely a function of the storage volume; the instance must be “EBS-optimized” with sufficient dedicated bandwidth to handle the provisioned throughput. For instance, using an R5b or X2idn instance allows the application to utilize the full 4,000 MB/s throughput offered by Block Express. Failure to match the instance capability with the volume performance will lead to throttling at the instance level, regardless of how many IOPS are provisioned.