Linkblog

AI and Architecture: Future or Folly?

2026-03-03T00:00:00Z

From: AEA Webinars - AI and Architecture: Future or Folly?

I recently listened to a webinar by Chris Armstrong, President of Armstrong Process Group, regarding the intersection of AI and Enterprise Architecture (EA). While the session focused on how AI fits into established frameworks like TOGAF, Chris offered a lot of wisdom between the lines on what it actually means to be a “good” architect. This is exactly the kind of perspective I needed when I first started in this field.

The Core Concept: Abstraction

A central theme was the principle of abstraction—the ability to represent the essential characteristics of a system while de-emphasising the irrelevant. Chris highlighted that what makes an abstraction “good” is inherently subjective and varies by domain.

“An abstraction represents the essential characteristics of an entity that distinguish it from all other kinds of entities… What makes an abstraction ‘good’ is a matter of perspective.”

He made a clear distinction between Architecture Building Blocks (ABBs), which focus on the “what,” and Solution Building Blocks (SBBs), which focus on the “how.”

Where AI Fits (and Where It Does Not)

The webinar captured the current pain points of EA work: keeping models current, correlating content, and the mundane struggle of wrestling with tool user experience. Chris suggested that AI could help raise the level of abstraction, allowing architects to focus on “true” ABBs while AI handles the solution-level assets.

However, he identified several “unique capabilities” that should remain in human hands:

Subjectivity: Determining what is “architecturally significant.”
Collaboration: Building consensus with stakeholders.
Innovation: Applying best practices in a specific, human context.

“Architects should not surrender their unique contribution and creativity… There are critical activities that are best suited to remain in human hands.”

My Take

While Chris captured the current struggles of the profession perfectly, I think he is being very modest about the impact of generative AI. I believe it will have a much larger effect than he suggests, automating a significant portion of the workflow and making architecture data far more reliable and up to date.

That said, he was spot on regarding why certain parts of the job must remain human. Strategy, deep understanding, and human interaction are not things AI can replicate. His examples of why we build models—to build consensus and explore alternatives—remind us that architecture is as much about people as it is about diagrams.

Software Factories and the Quest for Agentic Proof

2026-02-12T00:00:00Z

The landscape of software development has reached a significant inflection point. We are moving beyond simple code assistance toward “Software Factories”—environments where human engineers no longer write or even review code. This shift, highlighted by Simon Willison in How StrongDM’s AI team build serious software without even looking at the code, suggests a future where the primary role of a developer is to build the systems that build the software.

The Dark Factory Model

The concept of the “Dark Factory,” a term borrowed from manufacturing to describe fully automated plants, is being applied to software by teams like StrongDM. Their approach is governed by radical rules: code must not be written or reviewed by humans.

“We built a Software Factory: non-interactive development where specs + scenarios drive agents that write code, run harnesses, and converge without human review.”

To make this viable, StrongDM utilizes several advanced techniques:

Technique	Description
Scenario Testing	End-to-end user stories kept as “holdout sets” that agents cannot see, used to validate satisfaction.
Digital Twin Universe	Behavioral clones of third-party APIs (like Slack or Okta) built by agents to allow high-volume testing.
Gene Transfusion	Using agents to extract patterns from existing systems to reuse them in new contexts.
Pyramid Summaries	Multi-level documentation that allows agents to scan quickly and zoom in on details.

Proving That Code Works

If humans are not reviewing the code, the burden of proof shifts entirely to automated validation. Simon introduces two tools in Introducing Showboat and Rodney, so agents can demo what they’ve built designed to address this. These tools allow agents to demonstrate their work to human overseers through generated artifacts rather than raw code.

Showboat: A CLI tool that allows agents to construct Markdown documents. It records commands, outputs, and screenshots to “show” the progress of a feature.
Rodney: A browser automation tool designed for agents to perform web-based tasks and accessibility audits, feeding the results back into Showboat.

“The more code we churn out with agents, the more valuable tools are that reduce the amount of manual QA time we need to spend.”

Economic and Professional Implications

This transition is not without its challenges. StrongDM suggests that a high-performing software factory might require a spend of $1,000 per day per engineer on LLM tokens. While this cost is significant, it raises a fundamental question: is it more profitable to pay for tokens than for a massive QA department?

For the individual engineer, the concern is twofold: how to remain relevant and how to maintain a business model when competitors can use similar agents to clone features rapidly. The focus is shifting from the “how” of implementation to the “what” of system design and verification. We are moving from being writers to being architects of automated pipelines.^[1]

This reflects a broader trend where the value of a software engineer is increasingly found in their ability to define requirements and validation criteria rather than syntax. ↩︎

The Agentic AI Handbook: Production-Ready Patterns

2026-01-21T00:00:00Z

From: https://www.nibzard.com/agentic-handbook

The transition from experimental AI demos to stable production systems requires more than clever prompting; it demands architectural rigour. Nikola Balić has compiled 113 patterns derived from real-world implementations, providing a shared vocabulary for developers building autonomous and semi-autonomous systems.

“Agentic patterns are the bridge across this gap. Each pattern represents something more than one team has implemented and validated. They’re not theoretical—they’re born from production experience.”

Core Categories of Agentic Design

The handbook organises these patterns into eight functional areas to address the specific challenges of agent reliability and security:

Category	Focus Area	Key Pattern Example
Orchestration	Decision making and planning	Plan-Then-Execute
Tool Use	Interaction with external APIs/DBs	Code-Over-API
Context	Managing memory and token limits	Episodic Memory Retrieval
Feedback Loops	Iterative improvement	Reflection Loop
UX/Collaboration	Human-in-the-loop dynamics	Spectrum of Control
Reliability/Eval	Quality assurance and testing	Workflow Evals
Learning	Institutional knowledge building	Skill Library Evolution
Security	Safeguards and privacy	Lethal Trifecta Model

How to Start: Foundational Patterns

For those moving away from “vibe coding” toward structured engineering, Nikola suggests starting with these four pillars:

Plan-Then-Execute: Separate the reasoning phase from the action phase. This prevents untrusted data from hijacking the agent’s logic mid-stream.^[1]
Inversion of Control: Instead of micromanaging every step, provide the agent with tools and a high-level goal.
Reflection Loop: Implement a system where the model critiques its own draft against a metric before finalising output.
Chain-of-Thought Monitoring: Maintain “a finger on the trigger” by observing intermediate reasoning and interrupting if the agent drifts off-course.

“The jump from single-agent to multi-agent systems follows a natural progression. Specialization beats generalization. An agent optimized for code review will outperform a generalist agent asked to review code.”

The “Lethal Trifecta” Security Framework

A critical takeaway for production environments is the security model. To prevent data exfiltration via prompt injection, a system should never simultaneously possess:

Access to private data.
Exposure to untrusted content.
The ability to communicate externally.

By ensuring at least one of these “circles” is missing in any execution path, developers can create a robust safety boundary that does not rely solely on the model’s ability to follow instructions.

This pattern is notably used in Claude Code’s “plan mode” to increase success rates in complex tasks. ↩︎

The Human Element in Chatbot Exams

2026-01-20T00:00:00Z

From: https://ploum.net/2026-01-19-exam-with-chatbots.html

Lionel Dricot (Ploum), teaching “Open Source Strategies” at École Polytechnique de Louvain, recently experimented with a radical exam format. He allowed students full internet access and the choice to use chatbots, provided they followed strict accountability rules.

“You can use chatbots, but you will be held accountable for it. Mistakes made by chatbots will be considered more important than honest human mistakes, resulting in the loss of more points.”

The Experiment and Results

Out of 60 students, 57 chose not to use chatbots. Lionel identified four distinct clusters among those who declined:

Cluster	Performance Range (out of 20)	Motivation
Personal Preference	15 – 19	Pride in their own work; perceived AI as a time-sink for verification.
Never Use	~13	Active dislike for the interaction style of LLMs.
Pragmatic	12 – 16	Judged the specific exam as unsuitable for AI assistance.
Heavy Users	8 – 11	Afraid of the accountability constraints and missing AI errors.

Key Observations

The Accountability Paradox: When students are forced to justify AI output and are penalised more heavily for AI-generated errors, most abandon the tool.
The Stream of Consciousness: Lionel introduced a “stream of consciousness” text file where students recorded their thoughts in real-time without editing. This provided a “glimpse inside the minds” of students, helping to save those who understood the material but struggled with oral articulation due to stress.
Generational Fear: Students expressed a significant fear of “cheating,” even regarding standard collaborative practices. Many were panicked by Google’s forced AI overviews, fearing they would be accused of academic dishonesty.

“Can chatbots help? Yes, if you know how to use them. But if you do, chances are you don’t need chatbots.”

Comparison to Automated Oral Exams

This method contrasts sharply with the Voice AI approach used by Panos Ipeirotis.^[1] While the Voice AI model focuses on scalability and high-integrity automated testing, Lionel’s method focuses on human interaction and the “stream of consciousness” to mitigate stress. Lionel’s approach is deeply personal—averaging 26 minutes per student—making it difficult to scale to large cohorts, whereas the Voice AI model handles dozens of students for pennies.

See the previous discussion on Scalable Oral Exams with Voice AI. ↩︎

ChatGPT Health: The Marketplace Where You Are the Product

2026-01-12T00:00:00Z

From: https://consciousdigital.org/chatgpt-health-is-a-marketplace-guess-who-is-the-product/

OpenAI’s new ChatGPT Health service integrates medical records and wellness data (Apple Health, Peloton) to offer insurance comparisons and health advice. While marketed as a personal assistant, the infrastructure reveals a marketplace designed for insurers and payers.

Ther risks:

The Partnership: OpenAI partnered with b.well, a company that helps insurers assess member risk “before the first claim.”
The Privacy Gap: Data shared with OpenAI is generally not protected by HIPAA^[1], leaving it subject to corporate policy rather than federal law.
The Pay-to-be-Product Model: Even paid users are not exempt from data harvesting.

“If you’re not paying for the product, you are the product. ChatGPT showed us that even this formulation is too optimistic. You can pay for ChatGPT Plus or even Pro and still end up as the product.”

This serves as a grim reminder of how “privacy theatre” operates. I am very happy that this is not released in Europe. The fact that OpenAI has bypassed the EU, UK, and Switzerland—regions with strict GDPR enforcement—suggests the product cannot meet high privacy standards. When a company under financial pressure aggregates health data, you are no longer a patient; you are inventory.

HIPAA: US law protecting health information held by doctors and insurers, but often not tech platforms. ↩︎

The Model Context Protocol is a fad

2026-01-09T00:00:00Z

From: https://tombedor.dev/mcp-is-a-fad/

The Model Context Protocol (MCP) has gained rapid traction as a standard for connecting AI agents to various toolsets. However, Tom Bedor argues that this popularity is driven more by marketing momentum and ease of initial integration than by long-term technical utility. While it aims to solve the “NxM” problem—connecting N agents to M tools—the architectural trade-offs and security implications suggest it may be a transient trend.

The NxM Problem and MCP’s Approach

The core promise of MCP is to eliminate the need for bespoke connectors between different LLM APIs (like Gemini or OpenAI) and various tools. Currently, frameworks like LangChain or LiteLLM already handle these minor schema differences. MCP shifts tool execution into separate, long-lived processes.

“This abstracts away schema generation and invocation, but at a cost. Tool logic runs in a separate process, making resource management opaque. The application loses control over tool instructions, logging, and error handling.”

Key Structural Issues

The transition to MCP introduces several technical hurdles:

Incoherent Toolboxes: Tools developed in isolation lack context regarding other available tools, leading to “tool confusion” where an agent might use pliers when a hammer is more appropriate.
Runtime Complexity: Each MCP server requires its own environment. Users often struggle with dangling subprocesses, memory leaks, and dependency management across different runtimes like Node and Python.
Security Vulnerabilities: MCP often bypasses traditional security infrastructure. Recent CVEs have highlighted risks such as Remote Code Execution (RCE) and data exfiltration through prompt injection.

“You’re not eliminating trust; you’re redirecting it to third-party code that, as the CVEs demonstrate, is often unaudited and vulnerable.”

Better Alternatives

For most use cases, existing methods provide more robust results without the protocol overhead:

User Type	Better Alternative	Reason
Technical Users	Local scripts + command runners	AI can easily write these; they work for humans too.
App Developers	1st party tools	Better auth, logging, and shared memory state.
Tool Authors	OpenAPI / REST	Decades of battle-tested tooling and validation.

Simon Willison has also expressed skepticism regarding MCP’s long-term dominance, and I agree that the protocol’s benefits rarely outweigh its complexity and token cost. As model providers introduce native capabilities like Claude Skills, the need for a separate, over-engineered protocol is likely to diminish.

Fighting Fire with Fire: Scalable Oral Exams with Voice AI

2026-01-07T00:00:00Z

From: https://www.behind-the-enemy-lines.com/2025/12/fighting-fire-with-fire-scalable-oral.html

The traditional take-home exam is dead. When student submissions start looking like professional memos but the authors cannot explain their own logic during cold calls, the assessment model has failed. Panos Ipeirotis and Konstantinos Rizakos addressed this by deploying a Voice AI agent to conduct scalable, personalized oral exams.

The Core Experiment

Using ElevenLabs and a “Council of LLMs” for grading, the instructors transformed a 30-hour manual grading task into a $15 automated process.

“If you cannot defend your own work live, then the written artifact is not measuring what you think it is measuring.”

Key Takeaways

Scalability: The system cost $0.42 per student and handled 36 exams over 9 days without instructor fatigue.
The Council Method: Grading was handled by three models (Claude, Gemini, GPT). While they initially disagreed, a “consultation” round where they viewed each other’s evidence led to high consistency.
Instructional Mirror: The data revealed that students failed “Experimentation” questions consistently, highlighting a specific gap in how the professors had taught the material.
Human Factors: Students found the AI voice “intimidating” and “condescending,” proving that the persona of the AI is as important as its logic.

Grading Convergence

Metric	Round 1 (Independent)	Round 2 (Consultation)
Within 1 point	0%	62%
Within 2 points	23%	85%
Mean max difference	3.93 pts	1.41 pts

The experiment suggests that while AI created the cheating problem, it also provides the only scalable way to return to high-integrity oral examination.^[1]

Panos Ipeirotis is a Professor at NYU Stern. ↩︎

Useful patterns for building HTML tools

2025-12-12T00:00:00Z

From: Useful patterns for building HTML tools

I’ve started using the term HTML tools to refer to HTML applications that I’ve been building which combine HTML, JavaScript, and CSS in a single file and use them to provide useful functionality.

Simon Willison has built over 150 such tools, almost all with the help of LLMs. Here are the core insights and reusable patterns from his experience.

Core characteristics of HTML tools

Single file: inline JavaScript and CSS, no separate files.
No React or build steps: avoids complexity and eases copying.
Dependencies from CDNs: load libraries like PDF.js from CDNjs or jsDelivr.
Small size: typically a few hundred lines, making them easy to rewrite or understand.

Development workflow

Prototype with LLM canvases: Use ChatGPT Canvas, Claude Artifacts, or Gemini Canvas to quickly generate a working tool.
“Build a canvas that lets me paste in JSON and converts it to YAML. No React.”
Switch to coding agents for complex projects: Tools like Claude Code or Codex CLI can test code with Playwright and submit pull requests.
Self-host on GitHub Pages: Copy-paste the HTML into a repository and enable GitHub Pages for reliable, sandbox-free hosting.

Key patterns

Copy and paste: Leverage clipboard events for input and output; include “Copy to clipboard” buttons for mobile convenience.
Debugging tools: Build tools to inspect browser capabilities (e.g., clipboard formats, key codes, CORS).
State persistence:
- URL: store state in query parameters or hash for bookmarkable/shareable tools.
- localStorage: for larger state or secrets like API keys.
CORS-enabled APIs: Directly fetch data from APIs with open CORS headers (iNaturalist, PyPI, GitHub raw content, Bluesky, Mastodon).
Calling LLM APIs: OpenAI, Anthropic, and Gemini APIs are CORS-enabled; store API keys in localStorage.
File handling: Use <input type="file"> to read files locally and process them with JavaScript libraries (PDF.js, Tesseract.js).
Downloadable files: Generate files client-side and offer download via URL.createObjectURL().
Pyodide: Run Python in the browser, loading additional packages via micropip.
WebAssembly: Use WebAssembly ports of existing tools (e.g., Tesseract.js, SLOCCount).
Remixing previous tools: Reference existing tools in your prompt to leverage proven patterns. For example, to create pypi-changelog, Simon instructed:
“Look at the pypi package explorer tool… Build a new tool pypi-changelog.html which uses the PyPI API to get the wheel URLs…”

How Google Maps Quietly Allocates Survival Across London's Restaurants

2025-12-11T00:00:00Z

From: How Google Maps quietly allocates survival across London’s restaurants - and how I built a dashboard to see through it

Lauren Leek’s analysis provides a data-driven look at how Google Maps’ ranking system doesn’t just reflect consumer choice but actively shapes it, creating a cumulative advantage for some restaurants while leaving others algorithmically invisible.

Google Maps as a Market Maker

The platform’s public story is one of passive reflection, but its ranking is built on three signals: relevance, distance, and prominence. It is the last one—prominence—that is politically and economically significant. Google defines it using review volume, review velocity, average rating, brand recognition, and web visibility.

“Visibility on these ranked lists determines foot traffic. Foot traffic determines how quickly reviews accumulate. Review accumulation then feeds directly back into the prominence signal. The system compounds.”

This creates a feedback loop that disproportionately benefits chains and venues in high-footfall areas, while new independents face a cold-start problem. The dynamic resembles Robert Merton’s Matthew Effect: ‘unto every one that hath shall be given.’ In economic terms, Google Maps functions less like a directory and more like a market maker, allocating attention and steering demand.

Building a Counterfactual with Machine Learning

To separate a restaurant’s intrinsic appeal from its platform-amplified visibility, Leek built a machine learning model. It predicts a restaurant’s expected Google rating based on structural features like review count, cuisine, chain status, price, and location. The difference between the actual rating and this predicted baseline is the rating residual.

A positive residual indicates a restaurant performs better than the algorithm typically rewards for its type; a negative one suggests it is underperforming relative to the platform’s structural biases. This residual acts as a measure of “algorithmic mispricing.”

The London Food Dashboard

The practical output of this analysis is a public dashboard. Users can filter London restaurants by cuisine, borough, price, and, crucially, by “underrated gems”—those with high positive residuals. The tool makes the abstract effects of the algorithm concretely visible.

From Restaurants to Neighbourhood Ecosystems

Scaling the analysis up, Leek aggregated restaurant data into spatial cells to classify neighbourhoods into hub types: elite, strong, everyday, and weak. The analysis reveals that culinary diversity is not evenly distributed. Migrant cuisines often cluster in areas with weaker algorithmic visibility, tied to settlement histories and affordability.

“Cuisine diversity, in other words, is not just about taste. It is about where families settled, which high streets remained affordable long enough for a second generation to open businesses, and which parts of the city experienced displacement before culinary ecosystems could mature.”

The Takeaway

The core insight is that platforms like Google Maps now quietly structure economic survival in urban markets. What appears as consumer choice is increasingly a downstream effect of ranking algorithms. This has implications for policy, suggesting that tools for urban regeneration and small business support must now consider platform transparency and auditability.

Leek concludes that we audit financial markets, so we should also audit the attention markets that increasingly govern local economies.

Optimising LLM Agent Instructions with CLAUDE.md

2025-12-01T00:00:00Z

From: Writing a good CLAUDE.md | HumanLayer Blog

This article explores best practices for creating effective CLAUDE.md (or AGENTS.md) files, which are crucial for instructing large language model (LLM) agents. It highlights that LLMs are largely stateless and require explicit instruction for each session, making CLAUDE.md a high-leverage point for onboarding agents to a codebase.

“CLAUDE.md (or AGENTS.md) is the only file that by default goes into every single conversation you have with the agent.”

The author notes that LLMs often ignore CLAUDE.md content if it is not deemed relevant to the current task, due to an embedded system reminder. This underscores the importance of keeping instructions concise and universally applicable.

Key Principles for a Good `CLAUDE.md`

The article outlines several recommendations for crafting an effective CLAUDE.md file:

Onboard the Agent: Use CLAUDE.md to provide the agent with essential context about the codebase, covering:
- WHAT: Technology stack, project structure, and codebase map (especially for monorepos).
- WHY: The project’s purpose and the function of its various parts.
- HOW: How the agent should operate, including tools (e.g., bun instead of node) and verification steps (tests, typechecks).
Less is More:
- LLMs, particularly smaller models, have limitations on the number of instructions they can reliably follow (around 150-200 for frontier models).
- Instruction-following quality decreases uniformly as instruction count increases.
- The Claude Code system prompt already consumes about 50 instructions.
- Therefore, CLAUDE.md should contain as few, universally applicable instructions as possible.
Concise and Universally Applicable:
- The context window performs better with focused, relevant information.
- Since CLAUDE.md is included in every session, its contents must be broadly applicable. Avoid task-specific instructions.
- Aim for less than 300 lines; shorter is generally better. The HumanLayer root CLAUDE.md is under sixty lines.
Progressive Disclosure:
- Instead of including all instructions in CLAUDE.md, store task-specific instructions in separate Markdown files (e.g., agent_docs/building_the_project.md).
- CLAUDE.md can then list these files and instruct the agent to read them only when relevant.
- Prefer pointers (file:line references) over copying code snippets to avoid outdated information.
LLMs are Not Linters:
- Do not use LLMs for code style guidelines or formatting; they are expensive and slow compared to deterministic tools like linters and formatters.
- LLMs are in-context learners; if your code follows conventions, they should adapt with minimal explicit instruction.
- Consider using Stop hooks or Slash Commands to integrate linters and formatters, allowing the agent to fix issues identified by these tools.
Avoid Auto-Generation:
- CLAUDE.md is a critical leverage point for agent performance.
- Carefully craft its contents rather than relying on auto-generation tools, as a poorly constructed CLAUDE.md can negatively impact every phase of the workflow.

My Take

My recent experience with LLMs, particularly Gemini Pro 2.5, has shown a noticeable decrease in performance and instruction adherence, even with human-readable instructions. This article provides a compelling explanation for why this might be the case and offers practical strategies to mitigate it.

The concept of “less is more” and the emphasis on “universally applicable” instructions are particularly relevant. I have often been guilty of trying to stuff too much detail into initial prompts, hoping to cover all eventualities. The idea of using “Progressive Disclosure” by pointing to separate, task-specific Markdown files is a game-changer. This allows for detailed guidance without overwhelming the agent’s primary context window.

I also appreciate the strong stance against using LLMs as linters. It reinforces the principle of using the right tool for the job, leveraging deterministic tools for deterministic tasks and reserving LLMs for more complex, non-deterministic problem-solving. I plan to implement the “CRITICAL (PRIORITY 0)!!!” approach mentioned in the Hacker News discussion for my AGENTS.md files, alongside these structured principles, to see if it improves instruction following.

This approach aligns well with the idea of creating a “README for agents,” where the README.md remains for humans, but the agent-specific documentation is optimised for LLM processing efficiency and instruction adherence.

Navigating the AI Tsunami: Investment, Product, and the Professional Services Imperative

2025-11-27T00:00:00Z

The artificial intelligence boom continues its relentless march, prompting both excitement and apprehension. With unprecedented capital flowing into AI infrastructure and a rapid pace of technological advancement, a critical question emerges: are we witnessing an AI bubble, or is this a foundational shift? The answer, it seems, is nuanced, depending on which part of the AI ecosystem one examines.

The AI Investment Landscape: A Three-Tiered View

Andrew NG offers a framework for understanding where investment is flowing and where the opportunities and risks lie, as detailed in his newsletter Is there an AI bubble?. He categorises AI investment into three distinct areas:

AI Application Layer: Andrew believes this area is currently underinvested. There is immense potential for new applications built atop AI infrastructure, and these applications, by their nature, must be more valuable than the underlying technology to sustain the ecosystem. He observes “many green shoots across many businesses that are applying agentic workflows” and notes that Venture Capital investors often hesitate here, preferring the more understood recipe of infrastructure deployment.
AI Infrastructure for Inference: This sector still requires significant investment. The demand for processing power to generate tokens (AI outputs) already outstrips supply. Andrew highlights that businesses are “supply-constrained rather than demand-constrained,” a positive problem indicating strong underlying need. As agentic coders like Claude Code, OpenAI Codex (with GPT-5), and Gemini 3’s Google CLI improve and gain market penetration, the aggregate demand for token generation will only grow.
AI Infrastructure for Model Training: While Andrew is “cautiously optimistic” about this sector, he considers it the riskiest of the three. The rise of open-source/open-weight models and continuous algorithmic and hardware improvements weaken the “technology moat” for training frontier models. This could lead to a scenario where companies pouring billions into training might not see attractive financial returns.

Andrew’s primary concern regarding a potential “bubble” is not a fundamental flaw in AI, but rather the risk that overinvestment and a subsequent collapse in one part of the stack (e.g., training infrastructure) could trigger negative market sentiment across the entire field. However, he remains “very confident about the long-term health of AI’s fundamentals.”

The Product Reality: What Actually Works (and What’s Next)

Sean Goedecke offers a pragmatic view on the types of AI products that have genuinely found traction, noting that despite massive investment, many “new AI products” are simply chatbots, as discussed in his article Only three kinds of AI products actually work. He identifies three successful archetypes:

Chatbots: While ubiquitous, Sean argues that “the best chatbot product is the model itself.” AI labs possess decisive advantages in model access and simultaneous development of chatbot harnesses (e.g., Anthropic with Claude Code, OpenAI with Codex). Most bespoke chatbots struggle to compete with general-purpose models like ChatGPT.
- Caveat: Explicit Roleplay: A niche exists for chatbots that fulfil requests (e.g., adult content) that mainstream models avoid. However, this segment is likely to be absorbed by major AI labs as they become more flexible.
- Caveat: Chatbots with Tools: These “AI assistants” often fail because “chat is not a good user interface.” Savvy users can manipulate tools, and simple actions are often more efficiently performed via traditional UIs.
Completions: Products like GitHub Copilot, which predated ChatGPT, exemplify this. They act as “smart autocompletes,” allowing users to leverage AI power without changing their workflow. The genius lies in users never having to talk to the model. Sean expresses surprise that this hasn’t taken off more widely outside coding.
Agents: This is the most recent successful archetype, with coding agents making significant strides in the last year. Agents differ from chatbots-with-tools because they take an initial request and autonomously implement and test it. Their success in coding stems from the ease of verifying changes (running tests) and AI labs’ incentive to produce effective coding models. The “multi-billion-dollar question” is whether agents can be useful for tasks beyond coding, with research agents (e.g., in law or medicine) showing promise.

Sean also identifies two types of LLM-based products that “don’t work yet but may soon”:

LLM-generated Feeds: With major players like Mark Zuckerberg, OpenAI (Sora), and xAI exploring infinite personalised content feeds, this could become a primary mode of interaction. The advantage, like completions, is that users don’t need to interact with a chatbot; inputs come from user behaviour.
Games: While speculative, the integration of LLMs into video games, from full world simulations to AI-generated dialogue, holds potential. However, long development cycles, gamer resistance to AI, and challenges in making AI-generated content genuinely “challenging” are hurdles.

The Professional Services Imperative: Productise or Perish

The rapid evolution of AI, particularly agentic capabilities, is profoundly reshaping professional services. Jonas Braadbaart starkly illustrates this with the recent news of Accenture firing 11,000 employees who couldn’t adapt to AI, as detailed in his post Accenture Just Fired 11,000 People. You’re Next.. These were not underperformers, but consultants whose billable-hour work was rendered obsolete by AI performing tasks in minutes that once took hours.

This event underscores a critical shift: professional services firms are moving from billable-hour models to outcome-based business models. The economic reality is stark: a EUR 500 per hour client engagement struggles against an AI competitor charging EUR 20 per month.

Jonas argues that firms must “productise or perish.” This involves:

Embracing Opportunity: Identifying services that can be productised through AI and agentic solutions.
Value-Based Pricing: Aligning offerings with the value created for customers, rather than time spent. A “back-of-the-napkin” calculation reveals that €20 (the hourly rate for entry-level white-collar positions) can buy 5 million Gemini 3 Pro tokens, translating to 3 million input words and 0.75 million output words. This volume of information would take a human 625 hours to process, costing €12,500 at €20 per hour—a staggering 625x difference in processing cost.
Re-architecting for AI: Traditional firm structures, organised around human cognitive limits, are out of sync with AI’s capabilities.

While venture capital pours into vertical agentic AI startups, Jonas contends that these often struggle to gain significant market share due to the complexity of real-world economies. This presents a unique opportunity for existing professional services firms. By leveraging their “local industry and client expertise” and packaging it into “agentic, done-for-you productised services that create direct customer outcomes,” they can gain a significant advantage.

Jonas makes a bold prediction for 2026 and beyond: “The next big platform play will be to build the Shopify or Stripe of agentic service delivery: a platform that allows professional services firms to build and deliver agentic done-for-you services to their existing clients in a composable no-code environment.”

Synthesis: The Intertwined Future

The perspectives of Andrew Ng, Sean Goedecke, and Jonas Braadbaart paint a cohesive picture of the AI future. Andrew’s call for underinvestment in the AI application layer directly aligns with Sean’s identification of successful product archetypes like completions and agents. These are the “green shoots” Andrew observes, and they represent the kind of AI applications that professional services firms must learn to build and productise, as Jonas argues.

The increasing demand for AI inference capacity, highlighted by Andrew, is a direct consequence of the growing adoption of agentic tools and the massive token consumption demonstrated by Jonas’s calculations. The rapid advancements in models like Claude Sonnet 3.7, GPT-5, and Gemini 3, which have only truly enabled effective agents in the past year, are the catalysts for this transformation.

The AI landscape is not merely a speculative bubble but a rapidly evolving ecosystem. Strategic investment, focused product development on truly effective archetypes, and a fundamental re-evaluation of business models in professional services are not just opportunities but necessities for navigating this transformative period. The future belongs to those who can effectively build, deploy, and productise AI’s capabilities to deliver tangible outcomes.

How to Remember Everything You Read

2025-11-26T00:00:00Z

From: https://substack.com/@polymathinvestor/note/c-181277895

This guide offers a systematic approach to transforming reading from passive consumption into active knowledge construction. It addresses a common frustration: investing hours in reading only to find the details slip away within days. The framework combines cognitive science with practical heuristics used by elite learners.

Passive reading (just moving your eyes over text) is a recipe for low retention.

Encoding & Comprehension Heuristics

The foundation lies in how you initially process material:

Preview first: Spend 5–10 minutes surveying structure—contents, headings, introduction, summary—before diving into details. This creates a mental framework for new information.
Ask questions: Convert headings into questions. Reading becomes an active hunt for answers rather than passive intake.
Layered reading: Make multiple passes. A quick skim maps the territory; a slower read builds understanding; deep dives target only the most relevant sections.
Active engagement: Mark up texts with marginal notes, but highlight sparingly—no more than 10–20% of content. Over-highlighting bypasses the critical decision of what truly matters.
Paraphrase relentlessly: Write notes in your own words. If notes approach the length of the source, you are transcribing, not summarising.

Memory & Retention Frameworks

Long-term retention requires deliberate reinforcement:

Spaced repetition: Review material at increasing intervals (e.g., one day later, then a few days, then weeks). This exploits the brain’s consolidation processes, with optimal intervals around 10–20% of your desired retention period.
Active recall: Test yourself without looking at the material. Close the book and write down key ideas from memory. This strengthens neural pathways far more effectively than re-reading.
Immediate review: Revisit new material within 24 hours. Without this, up to 70–80% of new information can vanish before it consolidates.
The “one month later” test: True learning is measured by what you can recall after weeks, not minutes. Set a calendar reminder to test yourself a month later; gaps reveal what needs reinforcement.

If you can’t explain it simply, you don’t really understand it.

Synthesis & Integration

Knowledge becomes useful when connected to existing mental models:

Build a latticework: Deliberately connect new ideas to what you already know. Each connection creates an additional retrieval cue.
Feynman technique: Explain concepts in simple terms as if teaching a novice. Struggling to simplify reveals gaps in understanding.
Zettelkasten method: Break ideas into atomic notes, each containing one concept in your own words, and link them to related notes. This external system mirrors a well-connected brain.
Progressive summarisation: Distil material in layers—first highlights, then bold the most critical points among those, then write a high-level summary. Each pass reinforces memory while creating ultra-condensed review material.

Tools & Systems

Experts offload cognitive load to reliable external systems:

Analog note-taking: Writing by hand forces concision and processing. Many maintain a commonplace book or index card system.
Digital second brain: Tools like Obsidian or Notion allow you to capture, link, and retrieve knowledge with minimal friction. The key is consistent review, not complex organisation.
Spaced repetition software: For facts requiring verbatim recall, apps like Anki automatically schedule reviews at optimal intervals.
Frictionless capture: Carry a notebook or use quick-capture apps. If an idea takes more than a few seconds to record, you will resist doing it.

Mindset & Behavioural Heuristics

The underlying psychology determines success:

Curiosity as engine: Approach material with genuine questions. Curiosity primes the brain’s reward and memory centres, releasing dopamine that enhances learning.
Growth mindset: Believe memory is improvable through strategy and practice, not a fixed trait. This reduces anxiety and encourages persistence.
Patience and persistence: Deep understanding forms gradually. Accept that you will forget some material and treat each review as part of the journey.
Deep work habit: Dedicate uninterrupted blocks to single-tasking. Divided attention produces shallow, fragmented encoding.

Memory is a marathon, not a sprint; train and fuel accordingly.

A personal note on implementation: the resistance to reading things twice—or only partially—stems from a desire for efficiency. Yet elite readers accept that strategic re-reading of high-value material yields greater returns than consuming more content superficially. The key is selectivity: skim widely, but invest deeply in the 20% that matters most. Experimentation will reveal which techniques integrate naturally into existing habits.

Good Engineering Management - Is a Fad

2025-11-24T00:00:00Z

From: https://lethain.com/good-eng-mgmt-is-a-fad/

Larson’s bird’s-eye view of leadership evolution provides a useful antidote to prevailing narratives. The ability to step back and recognise these cyclical patterns is valuable. Rather than chasing fashionable management doctrines, focusing on these common characteristics offers a more stable foundation. These eight skills serve as practical anchors while the industry continues its inevitable shifts.

Will Larson observes that engineering management has cycled through distinct eras, each demanding different behaviours from its leaders. What constitutes “good” management is not a timeless truth but a response to prevailing business conditions. This macro perspective reveals that while styles fluctuate, certain foundational skills persist.

Three Eras of Engineering Leadership

Larson identifies three periods with sharply different expectations:

Era	Time Period	Business Context	Expected Manager Behaviour
Yahoo	Late 2000s	Stable organisations, limited resources	Navigate bureaucracy, identify opportunities, minimal direct reports contact
Hypergrowth	2010s	Zero-interest-rate policy^[1], hiring as constraint	Attract and retain engineers, stop coding, focus on team motivation
Post-ZIRP	Late 2022+	Higher interest rates, AI productivity promises	Flattened hierarchies, hands-on technical work, coordination roles reduced

Each transition arrived with a morality tale. The 2010s framed empowering engineers as a fundamental good; the 2020s recast middle managers as bureaucratic drag. Larson argues these narratives obscure the true driver: shifting business realities.

The industry will want different things from you as it evolves, and it will tell you that each of those shifts is because of some complex moral change, but it’s pretty much always about business realities changing.

If you accept any morality tale as absolute truth, you risk being misaligned when the cycle shifts again.

Eight Foundational Skills

Despite these swings, Larson proposes eight enduring skills that transfer across eras. He groups them into core and growth categories.

Core skills (essential for all management levels):

Execution: Lead teams to deliver tangible and intangible work consistently. Examples include shipping projects, managing on-call rotations, and incident response.
Team: Shape team and environment to balance organisational and individual needs. This covers hiring, coaching, performance management, and advocacy.
Ownership: Navigate reality to make progress despite systemic difficulties. This means showing up when uncomfortable and being accountable.
Alignment: Build shared understanding across leadership, stakeholders, and teams. This prevents surprises and ensures realistic planning.

Growth skills (determine career progression):

Taste: Exercise discerning judgment about what “good” looks like technically, in business terms, and in process/strategy. This helps avoid high-risk rewrites and refine product concepts.
Clarity: Ensure all parties understand your approach, reasoning, and how you overcome biggest problems.
Navigating ambiguity: Move from messy, open-ended problems to viable approaches.
Working across timescales: Balance short-term delivery with long-term sustainability without cutting corners.

The distinction between core and growth is not fixed. Execution, for example, was less central during hypergrowth but has regained prominence today.

Self-Assessing on These Skills

Larson includes a set of reflective questions in his article to help managers evaluate their proficiency across each of the eight skills. These questions probe areas such as team delivery friction, hiring and retention track record, problem ownership, stakeholder alignment, technical judgment, decision-making clarity, ability to unstick ambiguous problems, and trade-offs between short and long-term priorities. He also observes that executives often poach managers onto their most important problems that correspond to their strengths—if they never attempt to pull you in, you may not be considered particularly strong on that dimension.

Career Trade-offs

The “Manage your priorities and energy” chapter in The Engineering Executive’s Primer captures an important reality: the perfect allocation of work is not the mathematically ideal allocation that maximises impact. Instead, it’s the balance between that mathematical ideal and doing things that energise you enough to stay motivated over the long haul.

Recognising where you are in your career and making deliberate trade-offs is one of the highest value things you can do. Most importantly, it’s extremely hard to have a career at all if you don’t think about these dimensions and have a healthy amount of self-awareness to understand the tradeoffs that will allow you to stay engaged over half a lifetime.

Takeaways

Management expectations change with business cycles, not moral imperatives
Morality tales about leadership obscure economic drivers
Develop a broad base across all eight skills to remain effective across eras
Prioritise work that energises you to sustain a long-term career
Recognise where you are in your career and make deliberate trade-offs

ZIRP refers to the zero-interest-rate policy environment that characterised much of the 2010s, where central banks kept interest rates near zero to stimulate economic growth. ↩︎

Thinking Like an Architect: Beyond the Job Title

2025-11-19T00:00:00Z

Interesting and funny talk from Gregor: https://www.youtube.com/watch?v=xtxfrxf0mfE

Gregor Hohpe challenges the traditional view of an architect as a decision-maker or the “smartest person in the room.” Instead, he posits that an architect’s true value lies in making everyone else smarter, acting as an amplifier and translator across different organisational levels. This involves connecting disparate parts of a business, using powerful metaphors to bridge communication gaps, and employing models to sharpen thinking and facilitate better decisions.

Hohpe argues that the architect’s role is not to dictate but to empower, enabling teams to navigate complexity and make informed choices.

“I don’t think the architects should strive or pretend to be the smartest people in the room and decide for other people. Rather, we should make everybody else a little bit smarter.”

The Architect as an Amplifier

Hohpe outlines several key ways architects can amplify intelligence within an organisation:

Connecting Different Levels (The Architect Elevator):
- Organisations often suffer from disconnects between “upper management” (the penthouse) and “development teams” (the engine room).
- Architects act as an “elevator,” facilitating fast vertical movement and translation between these levels, ensuring technical efforts align with business strategy and vice versa.
- This isn’t about telling different stories but translating decisions and constraints so they make sense to each audience.
- The architect’s role is not to “dig” (code extensively) but to ensure the “tunnels meet,” occasionally picking up a shovel to stay connected to reality.
Using Metaphors:
- Metaphors translate complex technical problems, constraints, and decisions into a domain easily understood by the audience.
- They are not merely “cute stories” but powerful tools that allow the audience to “think along with you” in their own context.
- Example: Hohpe uses car metaphors (accelerator vs. gas pedal, disruption with Japanese cars, “Halo products” in cloud services) and train metaphors (self-centering wheels, guard rails vs. lane assist) to explain complex concepts like technical debt, platforms, and governance.
- The most effective metaphors leverage the audience’s business domain (e.g., financial options in a financial services context).
Seeing More Dimensions:
- Architects often perceive more dimensions in a problem than others, moving discussions from a binary “either/or” to a multi-dimensional “both/and.”
- Example: Instead of viewing “cutting project timelines” and “compromising quality” as opposing forces, an architect might introduce dimensions like “shifting testing earlier” or “automated testing” to show how both can be achieved.
- Discussing “vendor lock-in” can be reframed by considering the “utility” gained from a service versus the “switching cost,” leading to a more balanced ROI discussion.
- Lock-in is not just vendor-specific; any change has a switching cost, even within open-source products or different versions.
- “Mental lock-in” occurs when thinking is confined to a vendor’s product terms (e.g., always thinking in AWS SQS/SNS instead of generic queues and retry policies).
Expanding the Solution Space:
- Architects break down problems, add dimensions, and understand interdependencies to expand the range of possible solutions.
- This moves discussions beyond simple “left or right” choices, making people “smarter and ultimately happier” by offering more nuanced options.
- The Architect Boomerang: When faced with buzzword-driven demands (e.g., “we need to be cloud-native”), an architect asks “what are we really after?” (resilience, scalability, developer productivity, reduced switching cost). This allows them to identify more options, understand trade-offs, and return with a better-fitting solution.

The Architect as a Modeller

Models for Sharpening Thinking:
- Models are powerful tools for making people smarter, particularly at mid-levels of the organisation.
- They are not meant to be accurate depictions of reality but rather to sharpen thinking and aid decision-making.
- Example: The shift from a geocentric to a heliocentric model of the solar system simplified understanding by using a more suitable model, even though all models are inherently “wrong.”
- Simple models are often more useful than over-elaborate ones, as they abstract away complexity to focus on key insights.
- The “Read the Rest of the Paper” Rule: Architects delve deeper than surface-level understanding, applying principles like George Box’s quote: “All models are wrong, but some are useful.” Simple models are the most useful.
Context-Dependent Models:
- The “best” model depends on the question being asked. A topographical map is excellent for planning a hike but useless for understanding population density.
- When asked to “show me your architecture,” a valid retort is “what question are you looking to answer?”
- Sketching for Two-Way Communication: While standard models (UML, C4) are great for broadcasting information, custom sketches are powerful for two-way conversations, aiding dialogue and decision-making.
- Sketches can express over 20 dimensions (colour, shape, size, proximity, squiggliness for certainty), making them incredibly rich tools for communication.
- Raising the Level of Abstraction: “High-level diagrams” should not “dumb down” information. Instead, they should raise the level of abstraction to deepen thinking and reveal different complexities, as seen in the “Powers of Ten” concept.

Failure Modes and Countermeasures

Hohpe highlights common pitfalls architects face:

Believing the Audience “Doesn’t Get It”:
- People are not stupid; they have different incentives and motivations.
- An architect must translate their message into the audience’s language (e.g., selling “speed” to someone who cares about “cost” by linking speed to reduced operational costs or opportunity costs).
Trying to Change Behaviour Directly:
- It’s nearly impossible to change behaviour without first changing underlying assumptions and beliefs.
- If someone resists change, it’s often because they believe “change brings operational risk” (e.g., “never touch a running system”). The architect must address these beliefs with evidence and alternative approaches.
Being Labelled “Too Academic”:
- When using the “architect boomerang” to explore options, some may demand a quick decision.
- Hohpe’s “coin toss” analogy illustrates that an “informed decision” is preferable to a random one, justifying a brief pause for architectural thinking.
Making Things “More Complicated”:
- This perception arises when others assume a stable, predictable future.
- Architects must challenge this “wrong assumption” by highlighting that complexity arises from uncertainty and change, which good architecture helps manage.

Conclusion

Hohpe concludes that “architect” is not a job title but a way of thinking. By embracing the roles of amplifier, translator, and modeller, architects can empower others, foster better decision-making, and ultimately make organisations more effective and adaptable.

“Architecture and agility are absolutely no opposites; they’re no contradiction. Both thrive with high levels of uncertainty.”

Three Kinds of AI Products That Currently Work

2025-11-16T00:00:00Z

From: https://www.seangoedecke.com/ai-products/

Sean Goedecke identifies three categories of AI products that have demonstrated viability and success in the market: chatbots, completion tools, and agents. While many “AI products” are merely variations of chatbots, Goedecke argues that only specific implementations of these three archetypes truly deliver value. He also discusses two emerging categories—AI-generated feeds and AI-powered games—that show future potential.

“As far as I can tell, there are only three types of AI product that currently work.”

The Three Working AI Product Archetypes

Goedecke categorises successful AI products into three distinct types:

Chatbots:
- Description: The most popular LLM product, exemplified by ChatGPT. These allow users to interact with an LLM in natural language for a wide range of tasks.
- Challenge: The best chatbot is often the model itself (e.g., ChatGPT), which has advantages in model access and simultaneous harness development.
- Variants:
  - Explicit Roleplay: Chatbots that cater to niches (e.g., adult content) that mainstream models avoid. Goedecke notes ethical concerns and the likelihood of large labs eventually entering this space.
  - Chatbots with Tools (AI Assistants): These allow the model to perform actions (e.g., booking meetings). However, they are prone to “jailbreaking” for malicious use (e.g., refunds) and often provide a worse user interface than direct actions (e.g., Ctrl+Plus for font size).
Completion Tools:
- Description: Products that act as “smart autocomplete,” suggesting completions as a user types. GitHub Copilot is the prime example.
- Advantage: Users do not need to interact with a chatbot, seamlessly integrating AI power into existing workflows without changing user interface habits.
- Observation: While highly successful in coding, their adoption in other areas like professional writing has been slower, possibly due to user familiarity with existing autocomplete in code editors.
Agents:
- Description: Systems where the AI takes an initial natural language request and autonomously implements and tests the solution. Coding agents (e.g., Claude Code, GPT-5-Codex) are the most prominent example.
- Distinction from Chatbots with Tools: Agents manage a sequence of actions, rather than just single tool calls, making them effective for complex tasks.
- Why Coding Agents Work:
  - Verifiability: Changes can be easily validated through tests or compilation.
  - Incentive: AI labs are motivated to develop effective coding models for their own use.
- Future Potential: Research agents (e.g., for skimming search results or data analysis) are emerging, with potential in specialised fields like medicine or law.

Emerging AI Product Categories

Goedecke also identifies two categories that are not yet widely successful but show significant future potential:

LLM-Generated Feeds: Infinite, personalised content feeds generated by AI, similar to social media feeds but with AI-created content. This leverages existing user habits of scrolling feeds.
AI-Based Video Games: Games that incorporate LLMs for content generation, dialogue, or even full world simulations. Challenges include long development cycles, gamer resistance to AI-generated content, and the difficulty of making AI-generated content engaging and challenging.

Commentary

Sean’s analysis highlights a crucial distinction between AI as a feature and AI as a standalone product. Many “AI products” are simply chatbots, which often struggle to compete with general-purpose models like ChatGPT or face usability issues when trying to integrate tools. The success of completion tools like GitHub Copilot underscores the value of AI that enhances existing workflows without forcing a new interaction paradigm.

The rise of agents, particularly in coding, points towards a future where AI handles more complex, multi-step tasks autonomously. This shift from conversational interfaces to task-oriented execution is a significant development. The discussion on “AI-generated feeds” and “AI-based video games” also touches on the broader impact of generative AI on content creation and consumption, suggesting a future where AI plays a more direct role in shaping our digital experiences.

A key takeaway is that the most successful AI products often integrate AI capabilities seamlessly into existing user behaviours or solve specific, verifiable problems, rather than trying to replace established user interfaces with chat. The Hacker News comments further elaborate on this, pointing out successful AI applications in areas like grammar checking (Grammarly), translation (DeepL), and document processing, which often operate as embedded features rather than overt “AI products.” This suggests that the most impactful AI might be the one users don’t explicitly notice, working behind the scenes to enhance functionality.

Mastering Claude Code: Core Settings and Process for Developers

2025-11-03T00:00:00Z

From: https://blog.sshh.io/p/how-i-use-every-claude-code-feature

Shrivu Shankar’s guide highlights key strategies for optimising Claude Code, focusing on practical application for both personal and enterprise development. This summary distils the core settings and processes essential for effective AI integration into coding workflows.

“The single most important file in your codebase for using Claude Code effectively is the root CLAUDE.md. This file is the agent’s “constitution,” its primary source of truth for how your specific repository works.”

`CLAUDE.md`: The Agent’s Constitution

The CLAUDE.md file is fundamental, acting as the primary source of truth for how Claude Code interacts with your repository.

Core Principles:

Targeted Guardrails: Document common agent errors or specific project constraints rather than creating a comprehensive manual.
Context Efficiency: Avoid embedding large external documents; instead, provide clear references and conditions for their use.
Actionable Guidance: Always provide alternative actions when imposing limitations, preventing the agent from getting stuck.
Simplify Tooling: Use CLAUDE.md to drive the simplification of complex CLI commands into more intuitive wrappers.

Context Management & Session Control

Efficiently managing Claude’s context window is vital for performance and cost.

Monitor Context: Regularly use /context to track token usage.
Avoid /compact: This automatic compaction is often unreliable.
Strategic Resets:
- Simple Reboot: /clear followed by a custom /catchup command (to re-read changed files) is the preferred method.
- Complex Tasks: For larger efforts, “Document & Clear” involves saving progress to a .md file, clearing the session, and then instructing Claude to resume from the saved document.

Slash Commands: Personal Shortcuts

Slash commands should be simple, personal shortcuts for frequent actions.

Purpose: Streamline common tasks (e.g., /catchup for reading changes, /pr for pull request preparation).
Avoid Complexity: Do not create a complex, mandatory set of commands that requires separate documentation.

Agent Orchestration: Master-Clone Approach

For complex tasks, the “Master-Clone” architecture offers a flexible alternative to rigid subagents.

Subagent Drawbacks: Subagents can hide context and force predefined workflows, limiting the agent’s holistic reasoning.
Master-Clone: Centralise core context in CLAUDE.md and allow the main agent to dynamically delegate work to copies of itself using Task(...). This preserves full context while distributing effort.

Hooks & Session History

Leveraging hooks and historical data enhances control, validation, and continuous improvement.

Session History: Use claude --resume to restart sessions and extract insights from past interactions, informing CLAUDE.md improvements.
Validation Hooks:
- Block-at-Submit: Implement hooks (e.g., PreToolUse) to validate results at the commit stage, forcing the agent to fix issues before committing.
- Avoid Mid-Process Blocking: Allow the agent to complete its task before validating the final outcome, preventing confusion.

Planning & Skills

Evolving agent autonomy through structured planning and “Skills” is key to robust interaction.

Structured Planning: Use Claude’s built-in planning mode for complex changes to align on strategy and define inspection checkpoints.
Skills (Scripting Model): Formalise the agent’s ability to directly access the environment (binaries, scripts) and generate code on the fly via SKILL.md. This is more robust than traditional tool-calling.
MCP’s Evolved Role: MCPs should act as secure data gateways, providing high-level tools for authentication and security, rather than mirroring entire APIs.

Claude Code SDK & GitHub Actions

The Claude Code SDK and GitHub Actions (GHA) enable powerful automation and integration.

SDK Use Cases: Parallel scripting for refactors, building internal chat tools, and rapid agent prototyping.
GitHub Action: Operationalise Claude Code within GHAs for automated workflows (e.g., “PR-from-anywhere”) and auditable processes, driving continuous improvement.

Advanced Customisation (`settings.json`)

The settings.json file provides crucial customisation for advanced users.

Debugging: Use HTTPS_PROXY/HTTP_PROXY for traffic inspection.
Timeouts: Adjust MCP_TOOL_TIMEOUT/BASH_MAX_TIMEOUT_MS for long-running commands.
API Keys: Utilise enterprise API keys for usage-based pricing.
Security: Regularly review permissions for auto-run commands.

By focusing on these core settings and processes, developers can effectively harness Claude Code to enhance productivity and maintain code quality.

Functional Core, Imperative Shell: Separating Logic from Side Effects

2025-10-28T00:00:00Z

From: Simplify Your Code: Functional Core, Imperative Shell

The “Functional Core, Imperative Shell” (FCIS) pattern advocates for a clear separation between an application’s pure business logic and its interactions with the outside world. This architectural approach aims to enhance testability, maintainability, and adaptability by confining side effects to a thin, imperative layer.

“Mixing database calls, network requests, and other external interactions directly with your core logic can lead to code that’s difficult to test, reuse, and understand. Instead, consider writing a functional core that’s called from an imperative shell.”

Understanding the Components

Functional Core: This part contains pure, testable business logic. It operates solely on the data it is given, producing predictable outputs without causing any side effects (such as I/O operations or external state mutations). Its purity makes it inherently easier to reason about and unit test in isolation.
Imperative Shell: This layer is responsible for handling all side effects. It orchestrates interactions with external systems like databases, APIs, or user interfaces. The shell uses functions from the functional core to perform business logic, acting as the bridge between the pure logic and the impure reality of external dependencies.

Why Adopt FCIS?

Enhanced Testability: The functional core can be tested exhaustively with unit tests, as its behaviour is deterministic and free from external dependencies. This significantly reduces the need for complex integration tests for core logic.
Improved Maintainability: By isolating side effects, changes to external systems (e.g., swapping a database or email service) primarily affect the imperative shell, leaving the stable functional core untouched.
Increased Reusability: Pure functions within the core are highly reusable across different contexts or imperative shells, as they have no hidden dependencies.
Clearer Separation of Concerns: This pattern enforces a disciplined approach to software design, making it easier to understand which parts of the codebase are responsible for what.

Example: Sending Expiration Notifications

Consider a function to send expiration notification emails. A common “messy” approach might interleave database calls and email sending directly within the logic:

# Bad: Logic and side effects are mixed
import datetime

class User:
    def __init__(self, name, email, subscription_end_date, is_free_trial):
        self.name = name
        self.email = email
        self.subscription_end_date = subscription_end_date
        self.is_free_trial = is_free_trial

class Database:
    def get_users(self):
        # Simulates fetching all users from a database
        return [
            User("Alice", "alice@example.com", datetime.date(2025, 1, 15), False),
            User("Bob", "bob@example.com", datetime.date(2025, 11, 1), True),
            User("Charlie", "charlie@example.com", datetime.date(2025, 10, 20), False),
        ]

class EmailService:
    def send(self, recipient, subject):
        print(f"Sending email to {recipient}: {subject}")

def send_user_expiry_email_bad():
    db = Database()
    email_service = EmailService()
    today = datetime.date.today()

    for user in db.get_users():
        if user.subscription_end_date > today:
            continue
        if user.is_free_trial:
            continue
        email_service.send(user.email, f"Your account has expired {user.name}.")

# Example usage (not run in actual blog post)
# send_user_expiry_email_bad()

Rewriting this using the FCIS pattern separates the pure logic from the side effects:

Functional Core (Python):

# Functional Core: Pure business logic
import datetime

class User: # Re-using the User class definition from above
    def __init__(self, name, email, subscription_end_date, is_free_trial):
        self.name = name
        self.email = email
        self.subscription_end_date = subscription_end_date
        self.is_free_trial = is_free_trial

def get_expired_users(users: list[User], cutoff_date: datetime.date) -> list[User]:
    """Filters a list of users to find those with expired, non-free trial subscriptions."""
    return [
        user for user in users
        if user.subscription_end_date <= cutoff_date and not user.is_free_trial
    ]

def generate_expiry_emails(users: list[User]) -> list[tuple[str, str]]:
    """Generates email details (recipient, subject) for a list of users."""
    return [
        (user.email, f"Your account has expired {user.name}.")
        for user in users
    ]

Imperative Shell (Python):

# Imperative Shell: Handles side effects and orchestrates the functional core
class Database: # Re-using the Database class definition from above
    def get_users(self):
        # Simulates fetching all users from a database
        return [
            User("Alice", "alice@example.com", datetime.date(2025, 1, 15), False),
            User("Bob", "bob@example.com", datetime.date(2025, 11, 1), True),
            User("Charlie", "charlie@example.com", datetime.date(2025, 10, 20), False),
        ]

class EmailService: # Re-using the EmailService class definition from above
    def send_bulk(self, emails: list[tuple[str, str]]):
        for recipient, subject in emails:
            print(f"Sending email to {recipient}: {subject}")

def send_expiry_notifications_fcis():
    db = Database()
    email_service = EmailService()
    today = datetime.date.today()

    all_users = db.get_users() # Side effect: database read
    expired_users = get_expired_users(all_users, today) # Pure function call
    emails_to_send = generate_expiry_emails(expired_users) # Pure function call
    email_service.send_bulk(emails_to_send) # Side effect: sending emails

# Example usage (not run in actual blog post)
# send_expiry_notifications_fcis()

This refactoring makes the core logic (get_expired_users, generate_expiry_emails) pure and easily testable. The imperative shell then handles the actual database retrieval (db.get_users()) and email dispatch (email_service.send_bulk()).

Reflections and Nuances

From: https://news.ycombinator.com/item?id=45701901

The FCIS pattern, while powerful, invites discussion on its practical application and relationship with other architectural principles.

FCIS vs. “Generic Core, Specific Shell” (GCSS)

A related concept, “Generic Core, Specific Shell,” suggests building a generic core that can address a family of related problems, adapted by a specific shell for particular needs. While seemingly opposed, these two ideas can be seen as orthogonal or even complementary^[1].

FCIS focuses on verification (“Does it do what it’s supposed to do?”) by isolating side effects for easier testing.
GCSS focuses on validation (“Is what it’s supposed to do what we actually need it to do?”) by promoting adaptability and reusability across similar problems.

Ideally, GCSS can be applied recursively, with specific shells adapting slightly more generic cores. FCIS, on the other hand, is more about the boundary between pure logic and impure effects within a component.

Practical Considerations and Criticisms

Database Interaction: A common critique of the example is the db.get_users() call within the imperative shell, which implies fetching all users into memory before filtering. In real-world scenarios, the imperative shell would typically interact with the database to perform filtered queries directly (e.g., db.get_expired_users(datetime.date.today())) to avoid performance issues^[2]. The example serves to illustrate the separation of concerns rather than an optimal database interaction strategy.
Readability of Chained Calls: The one-liner email.bulkSend(generateExpiryEmails(getExpiredUsers(db.getUsers(), Date.now()))); can be difficult to read and debug. Many developers prefer breaking this into multiple lines with intermediate variables for clarity, or using pipe operators available in some languages^[3].
Over-engineering vs. Adaptability: While GCSS promotes adaptability, it also carries the risk of over-engineering if not applied judiciously, potentially violating KISS (Keep It Simple, Stupid) and YAGNI (You Ain’t Gonna Need It) principles. The balance lies in understanding the context and anticipated evolution of the system.
The “Good Code” Debate: The discussion around FCIS often touches upon the subjective nature of “good code.” Different paradigms (e.g., Object-Oriented Programming, Domain-Driven Design) offer distinct approaches, and what constitutes “good” can depend on the project, team, and specific challenges. FCIS offers a valuable lens for achieving certain qualities like testability and maintainability, but it is not the sole arbiter of code quality.
Time-Dependent Logic: The use of Date.now() (or datetime.date.today() in Python) in the example highlights a common challenge: how to handle time-dependent logic in a testable way. Injecting a “clock” dependency (e.g., clock.now()) rather than relying on global time functions is crucial for deterministic testing.

Ultimately, FCIS provides a robust framework for structuring code, particularly in languages that support functional programming constructs. It encourages a mindset where core logic is pristine and predictable, while external interactions are managed explicitly at the boundaries. This distinction is crucial for building software that is both robust and easy to evolve.

As one commenter noted, “I disagree that these two pieces of advice are opposed. I think they are orthogonal at worst, and in agreement at best.” ↩︎
The author of the original article acknowledged this, stating, “I do regret using ‘db’ a bit now after reading all of the comments here, as it’s taken away focus from the main point.” ↩︎
Languages like Elixir, with its pipe operator (|>), can make such chained calls significantly more readable. ↩︎

Securely Accessing OpenWebUI with Tailscale Funnel on Proxmox

2025-10-22T00:00:00Z

This guide outlines a method for making your OpenWebUI instance publicly accessible via Tailscale Funnel, while maintaining robust security on your Proxmox host. The approach isolates OpenWebUI within an LXC container and uses Nginx as a reverse proxy, ensuring that only the OpenWebUI service is exposed.

This solution segments access so only the OpenWebUI service is publicly available while keeping your critical management interfaces secure.

This setup is designed for security and maintainability, providing persistent data, auto-updates, and compatibility with various network environments.

1. Environment Setup Overview

The solution consists of three main environments with specific tools and purposes:

Environment	Tools Installed	Purpose
Proxmox Host	Nginx, Tailscale	Reverse proxy and secure public access
LXC Container	Docker, OpenWebUI	Application isolation and execution
Tailscale Network	ACLs, Funnel	Secure access control and public exposure

2. Architecture Options

Before proceeding with the setup, consider these architectural choices based on your specific needs. The standard implementation is optimized for home use where simplicity and reliability are prioritized over enterprise-grade scalability.

Component	Purpose	Tool Used	Practical Alternatives
Container Platform	Isolates the application from the host system	LXC on Proxmox	Docker on bare metal (simpler but less isolation)
Reverse Proxy	Routes traffic to the correct service	Nginx on Proxmox host	Caddy (simpler configuration), Traefik (more dynamic)
Public Access	Provides secure external connectivity	Tailscale Funnel	Cloudflare Tunnel (requires domain), SSH tunneling
Security Model	Controls who can access what	Tailscale ACLs with tags	Basic authentication, IP whitelisting
OS for Container	Base operating system for the container	Debian 12	Ubuntu (more familiar), Alpine Linux (smaller footprint)

Home Use Notes:
For personal deployments, avoid over-engineering. Kubernetes is excessive for a single OpenWebUI instance. The standard implementation provides the right balance of security and simplicity for home use. While OpenWebUI does have a Python version, the Docker implementation is more reliable for persistent deployment.

3. Setting Up the LXC Container on Proxmox

Create a new LXC container with the following specifications (when not hosting a model locally this is fine):

Operating System: Debian 12
Resources: 2GB RAM, 2 CPU cores, 20GB disk
Container ID: 101
Hostname: opwebui-lxc

After creation, enable nesting by adding the following lines to the container’s configuration file at /etc/pve/lxc/101.conf on the Proxmox host:

lxc.apparmor.profile: unconfined
lxc.cap.drop: 
lxc.cgroup2.devices.allow: a
lxc.mount.auto: cgroup:rw

Note: For production use, consider setting a static IP for the LXC container in the Proxmox web interface to avoid IP changes that could disrupt the Nginx configuration. The command pct list in the Proxmox host terminal can also be used to verify the container’s current IP address.

4. Configuring the LXC Container for OpenWebUI

4.1 Install Docker

Docker is required to run OpenWebUI. Follow the official installation guide for Debian: Docker Installation for Debian.

4.2 Create OpenWebUI Directory Structure

mkdir -p /root/openwebui
cd /root/openwebui

4.3 Create the `.env` File

This file stores environment variables for the OpenWebUI Docker container. Replace Europe/Amsterdam with your local timezone.

cat > .env <<EOF
WEBUI_SECRET_KEY=$(openssl rand -hex 32)
TZ=Europe/Amsterdam
EOF

Alternatively, you could use nano .env to create and edit the file.

4.4 Create the `docker-compose.yml`

This file defines the OpenWebUI service and a Watchtower service for automatic updates. Note the WEBUI_URL placeholder; this will be the public URL for your OpenWebUI instance.

cat > docker-compose.yml <<'EOF'
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main-slim
    container_name: open-webui
    ports:
      - "8080:8080"
    environment:
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
      - WEBUI_URL=https://opwebui.yourdomain.ts.net # Replace with your Tailscale Funnel URL
      - ENABLE_SIGNUP=false
      - DEFAULT_USER_ROLE=pending
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    
  watchtower:
    image: containrrr/watchtower:latest
    container_name: openwebui-watchtower
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_LABEL_ENABLE=true
      - WATCHTOWER_INCLUDE_RESTARTING=true
      - WATCHTOWER_SCHEDULE=0 0 7 * * *
      - TZ=${TZ:-Europe/Amsterdam}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped
    
volumes:
  open-webui:
EOF

4.5 Start the Containers

docker compose up -d

5. Configuring the Proxmox Host

5.1 Install Required Packages

apt update && apt upgrade -y
apt install -y nginx net-tools

5.2 Create Nginx Configuration

This Nginx configuration listens on 127.0.0.1:8090 (localhost only) and proxies requests to the OpenWebUI container. This ensures Nginx is not directly exposed to the network.

cat > /etc/nginx/sites-available/openwebui.conf <<EOF
server {
    listen 127.0.0.1:8090;
    server_name opwebui.yourdomain.ts.net; # Replace with your Tailscale Funnel URL
    
    client_max_body_size 100M;
    
    location / {
        proxy_pass http://192.168.1.100:8080; # Replace with your LXC's static IP
        
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
            
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";
            
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
        proxy_buffering off;
        proxy_request_buffering off;
    }
    
    location = /health {
        return 200 "OK\n";
        access_log off;
        add_header Content-Type text/plain;
    }
}
EOF

5.3 Enable the Nginx Configuration

ln -sf /etc/nginx/sites-available/openwebui.conf /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t && systemctl restart nginx

6. Configuring Tailscale Security

6.1 Install Tailscale

On the Proxmox host:

curl -fsSL https://tailscale.com/install.sh | sh

6.2 Authenticate Tailscale

tailscale up

Follow the URL provided in the output to authenticate your Proxmox host with your Tailscale account.

6.3 Apply Security Tags

tailscale up --advertise-tags=tag:openwebui,tag:proxmox

6.4 Configure ACLs in Tailscale Dashboard

Go to the Tailscale admin console

Replace the existing ACL configuration with the following:

{
  "acls": [
    {"action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:self:*"]},
    {"action": "accept", "src": ["autogroup:members"], "dst": ["tag:openwebui:443"]},
    {"action": "accept", "src": ["autogroup:admin"], "dst": ["tag:proxmox:22", "tag:proxmox:8006"]}
  ],
      
  "tagOwners": {
    "tag:openwebui": ["autogroup:members"],
    "tag:proxmox": ["autogroup:admin"]
  },
      
  "nodeAttrs": [
    {
      "target": ["tag:openwebui"],
      "attr": ["funnel"]
    }
  ],
      
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:admin"],
      "dst": ["tag:proxmox"],
      "users": ["root"]
    }
  ]
}

Save the configuration

6.5 Enable Funnel for Public Access

tailscale funnel --bg --https=443 8090

7. Verification and Testing

7.1 Verify OpenWebUI is Running

In the LXC container:

docker ps
# Should show open-webui and openwebui-watchtower

7.2 Verify Nginx is Listening

On the Proxmox host:

ss -tlnp | grep :8090
# Should show nginx listening on 127.0.0.1:8090

7.3 Test Public Access

curl -I https://opwebui.yourdomain.ts.net
# Should return HTTP 200 OK

8. Troubleshooting Common Issues

If you get “connection refused” errors:

Check Nginx is running: systemctl status nginx
Verify Nginx is listening: ss -tlnp | grep :8090
Check OpenWebUI is running: docker ps (in LXC container)

If Tailscale Funnel is not working:

Check Funnel status: tailscale funnel status
Verify tags are applied: tailscale status | grep Tags
Check ACL is active in the Tailscale admin console

If WebSocket streaming fails:

Verify Nginx has WebSocket headers:

grep -A10 "location /" /etc/nginx/sites-available/openwebui.conf

Ensure you are using HTTPS (not HTTP) for public access

Final Notes

This configuration:

Secures your Proxmox host while allowing public access to OpenWebUI.
Respects Tailscale’s architecture without workarounds.
Maintains all requirements for persistence, auto-updates, and corporate proxy compatibility.
Follows security best practices with the principle of least privilege.

The solution is intentionally minimal; only the necessary components are used, each with a clear purpose. This reduces complexity and attack surface while ensuring reliable operation. Your OpenWebUI instance is now securely accessible from anywhere, keeping your critical Proxmox management interfaces protected from unauthorised access.

A note on corporate proxies: While this setup is designed to be robust, some corporate proxies can interfere with WebSocket connections, leading to errors such as websocket connection failed to wss://.... If you encounter this, it may be due to the proxy’s strict filtering or inspection of WebSocket traffic. Unfortunately, direct workarounds for client-side corporate proxies are often limited without administrative access to the proxy itself. If you have found a solution for this specific issue, please share it.

For accessing environments via SSH, particularly on Windows, tools like MobaXterm can offer a more reliable experience compared to web interfaces, especially when dealing with network complexities.

Claude Skills: A Simpler Approach to Specialised AI Tasks

2025-10-20T00:00:00Z

From: https://simonwillison.net/2025/Oct/16/claude-skills/

Claude Skills represent a refreshingly simple approach to extending AI capabilities—functioning like a library where the model acts as a librarian, accessing only relevant resources when needed. This contrasts with more complex protocols like MCP, offering a natural extension to how language models handle specialised tasks.

Skills are conceptually extremely simple: a skill is a Markdown file telling the model how to do something, optionally accompanied by extra documents and scripts that the model can run to help it accomplish the tasks described by the skill.

The core innovation lies in its minimalism:

Context-aware loading: Skills only consume tokens when relevant to the current task
Library-like organisation: Each skill is a self-contained folder of instructions and resources
Natural integration: The model accesses skills as needed, like a librarian retrieving specific materials

This approach addresses key limitations of previous systems:

Feature	Skills	MCP
Complexity	Simple Markdown files	Full protocol specification
Token efficiency	Only loads metadata initially	Consumes thousands of tokens upfront
Implementation	Single files or small folders	Requires dedicated infrastructure
Adaptability	Easy to iterate and share	More rigid implementation

The library analogy proves particularly apt—rather than forcing the model to carry all knowledge at once, Skills allow it to reference external resources only when necessary. This creates a more sustainable pattern for extending AI capabilities without overwhelming the model’s context window.

What makes Skills compelling is their accessibility. Unlike MCP’s comprehensive protocol, Skills require minimal setup:

A skill is essentially a well-structured Markdown file
Optional supporting scripts can be added as needed
The system only loads relevant skills during a session

This simplicity enables rapid iteration and sharing. As Willison notes, “The core simplicity of the skills design is why I’m so excited about it.” The approach leverages what LLMs do best—interpreting text instructions—while outsourcing complex coordination to the underlying system.

The contrast with MCP is instructive. Where MCP required significant infrastructure investment, Skills work with existing coding environments, making them more practical for immediate implementation. This shift from protocol to pattern represents a maturation in how we extend AI capabilities.

From: https://github.com/anthropics/skills

The official skills repository demonstrates this simplicity in practice. Each skill is self-contained in its own directory with a SKILL.md file containing instructions and metadata. The repository includes both open-source examples and the proprietary document creation skills that power Claude’s native document capabilities. The basic structure requires only two fields in the YAML frontmatter: a unique name and a description of when to use the skill.

Agentic Engineering: Just Talk To It

2025-10-16T00:00:00Z

From: https://steipete.me/posts/just-talk-to-it#do-you-do-spec-driven-development

Peter Steinberger presents a streamlined approach to agentic engineering, advocating for direct, conversational interaction with AI models rather than relying on elaborate frameworks or subagents. His workflow, heavily centred on GPT-5-Codex, emphasises simplicity, rapid iteration, and developing an intuitive understanding of the model’s capabilities.

“Don’t waste your time on stuff like RAG, subagents, Agents 2.0 or other things that are mostly just charade. Just talk to it. Play with it. Develop intuition.”

Key Tenets of Steinberger’s Agentic Workflow

Model of Choice: GPT-5-Codex is preferred over Claude Code due to its superior context management, efficiency, speed, and less “silly” conversational style.
- Context & Efficiency: Codex offers ~230k usable context, which fills slower than Claude Code’s 156k.
- Speed: Rewritten in Rust, Codex is “incredibly fast” and lightweight, avoiding the freezes and memory issues observed with Claude Code.
- Language & Interaction: Codex is described as an “introverted engineer that chugs along and just gets stuff done,” requiring shorter prompts and being less prone to “silly” responses.
Harness & Parallelisation:
- codex cli: The primary daily driver, often run in 3-8 parallel instances within a terminal grid for concurrent tasks.
- Atomic Commits: Agents are configured to perform atomic Git commits, ensuring a clean history.
- No Worktrees: A single development server is used to facilitate testing multiple changes simultaneously, avoiding the overhead of multiple branches or servers.
“Blast Radius” Thinking:
- Before making changes, consider the potential impact (time and files touched).
- Prefer “many small bombs” (small, isolated changes) over “Fat Man” (large, sweeping changes) to maintain control and ease of rollback.
- Don’t hesitate to stop models mid-way to check status or redirect, as file changes are atomic.
Prompting Strategy:
- Concise Prompts: Codex requires significantly shorter prompts (often 1-2 sentences) due to its ability to read the codebase effectively.
- Visual Context: Screenshots are frequently used (up to 50% of prompts) to provide visual context, with the model adept at identifying relevant strings and locations.
- Conversational Approach: Instead of rigid “plan mode” or structured documents, Steinberger “talks” to Codex, asking it to “discuss” or “give me options” and waiting for approval.
Refactoring & Maintenance:
- Approximately 20% of time is dedicated to refactoring, entirely performed by agents.
- Refactoring tasks include code duplication checks (jscpd), dead code removal (knip), ESLint checks, API consolidation, documentation, dependency updates, and test writing.
- This cyclical approach of rapid iteration followed by dedicated refactoring phases is considered more productive and enjoyable.
Spec-Driven Development (Evolved):
- The “old way” of writing a large spec and letting the model build for hours is eschewed.
- Current approach involves a collaborative discussion with Codex, feeding it websites and ideas, and fleshing out features together.
- For tricky features, a spec might be drafted and reviewed by GPT-5-Pro (via ChatGPT.com) for alternative ideas, then integrated back.
- UI-based work often starts with under-specified requests, allowing the model to build and iterate in real-time, morphing the “chaos into the shape that feels right.”
Tooling & “Charade”:
- Avoids Over-Engineering: Dismisses many agentic tools (e.g., Conductor, Terragon, Sculptor) as “thin wrappers” that work around inefficiencies and promote suboptimal workflows.
- CLI over MCPs: Advocates for using command-line interface (CLI) tools over “Multi-Command Prompts” (MCPs) due to their zero context cost and existing model knowledge.
- tmux for Background Tasks: Instead of relying on model-specific background task features, tmux is used for persistent CLI sessions.
Addressing Model Imperfections:
- Acknowledges that Codex is not perfect (e.g., occasional reverts, forgetting bash commands, “losing” lines in the terminal).
- These flaws are considered minor compared to its overall effectiveness, and human-like patience is sometimes required (“soothen it like a child”).
- Lazy Workarounds: For long-running tasks, queuing “continue” messages can keep the model engaged.
- Test Generation: Asking the model to write tests after each feature/fix improves test quality and uncovers bugs.
- Intent Preservation: Prompting to “add code comments on tricky parts” helps both human and future model understanding.

Steinberger’s “Just Talk To It” philosophy underscores the importance of developing intuition and direct communication with AI agents, treating them as collaborative partners rather than complex systems requiring elaborate orchestration. The skills needed to manage agents, he notes, mirror those of senior software engineers.

Digital Twins: From Industry to Ecology

2025-10-15T00:00:00Z

From: https://www.nature.com/articles/d41586-025-03314-y

Digital twin technology, traditionally an industrial tool, is now proving valuable in ecological research and wildlife management. This marks a positive shift for a technology that has previously faced scepticism regarding its practical delivery.

“Digital twins can be particularly useful for studying systems that are changing outside historical norms… That includes how ecosystems react to anthropogenic climate change.”

The Nature article details how virtual representations are simulating animal behaviour, predicting environmental changes, and informing conservation efforts.

The Rise of Digital Twins

A digital twin is a virtual model that accurately reflects a physical entity, continuously updated with real-time data. This allows for simulations, monitoring, and analysis. Its accelerated adoption stems from:

Increased data availability.
Prevalence of Internet of Things (IoT) devices.
Advancements in artificial intelligence (AI) and cloud computing.

Ecological Applications

Ecologists are using digital twins to address complexities and data gaps in biodiversity research:

Crane Radar: Developed by Wageningen University & Research, this twin forecasts common crane migration across Western Europe. It integrates migration data, birdwatcher sightings, and environmental factors. Ecologist Koen de Koning noted its personal benefit: “This model really helped me, personally, to see them more often.”
Doñana National Park: A complex model is being built to simulate interactions between vegetation, rabbits, and the Iberian lynx, understanding how various factors affect the ecosystem.
River Management: Digital twins for rivers like the Stiffkey (England) and Mara (Kenya) aid in habitat improvement, flood prevention, and community alerts.

Challenges

Despite their potential, ecological digital twins face hurdles:

Data Reliability: High-quality, real-time data is crucial; inaccurate citizen observations can affect model accuracy.
Data Storage Costs: The large data volumes required can lead to significant cloud storage expenses.
Funding & Awareness: As a new application in ecology, educating potential users and securing sustainable funding for long-term maintenance are essential.

My experience with digital twins has primarily been in industrial contexts, where they often faced scepticism due to initial over-promising. It is encouraging to see this technology find positive and impactful application in ecology, moving beyond its previous reputation to deliver tangible benefits in wildlife management and environmental conservation. This shift demonstrates a maturing of the technology, where practical applications are now outweighing earlier hype. The Crane Radar, engaging the public as data providers, illustrates the potential for digital twins to foster a more connected approach to environmental stewardship.

Avoiding Negativity Echo Chambers in Your Career

2025-10-13T00:00:00Z

From: https://brooker.co.za/blog/2025/06/20/career.html

Marc Brooker, an engineer at Amazon Web Services (AWS), shares a piece of career advice: actively avoid negativity echo chambers. He argues that while complaining can be an inviting and inclusive activity, such environments ultimately hinder career progression and negatively impact personal well-being.

“If I could offer you a single piece of career advice, it’s this: avoid negativity echo chambers.”

Brooker highlights the pervasive nature of these “watering holes where the whiners hang out” within organisations and industries. He observes that these communities often make complaining their core identity, pushing out those who are positive, optimistic, or ambitious.

Key takeaways from Marc’s perspective include:

The Detrimental Nature of Cynicism: While occasional complaints are normal, consistently engaging with communities centred on negativity is harmful. Brooker suggests a personal limit, disengaging when approximately 20% of the content becomes negative.
Two Paths for Career Engagement:
- Advance and Improve: Focus on the positive aspects of your role and invest energy in making things better.
- Maintain and Disengage: If career advancement is not the goal, dedicate just enough energy to maintain your position, then redirect your focus to personal life and hobbies, rather than joining cynical groups.
Impact on Well-being: Negativity echo chambers are not only detrimental to career prospects but also to mental and physical health. Brooker advises avoiding them, especially if their content “resonates” with existing frustrations.
The “Yes, And” Approach: Seek out communities that foster growth and collaboration. Spend time with individuals who are doing admirable work, living the life you aspire to, and from whom you can learn. These are not found in spaces focused on past grievances.
Driving Real Change: True change is seldom driven by sadness and anger. While working with others to push for change is valuable, passive complaining does not achieve this.
Protecting Communities: Negativity can erode the quality of a community. When cynicism becomes dominant, valuable members disengage, leading to a decline in the community’s overall health and vibrancy.

This perspective resonates with my own experiences. Being surrounded by negativity can indeed hinder progress and keep one stuck in undesirable situations. I find that actively choosing to “lean in” and focus on making the best of circumstances, rather than dwelling on complaints, is a far more constructive approach. It is about identifying what can be improved and contributing to that improvement, or, if that is not feasible, consciously disengaging to protect one’s own energy and focus on other fulfilling aspects of life.

The Critical Scrutiny of TOGAF: A Pragmatic Reflection

2025-10-10T00:00:00Z

Following my recent post, “TOGAF: A Pragmatic Starter Kit for Engineers,” which explored a lean, iterative approach to leveraging TOGAF’s principles, it is equally important to critically examine the framework itself. This post aims to provide a balanced perspective on TOGAF’s utility and limitations, acknowledging its enduring presence while reflecting on its practical application.

Svyatoslav Kotusev, a dedicated researcher in the field of Enterprise Architecture, offers a comprehensive and critical analysis in his article, “The Critical Scrutiny of TOGAF.” His work challenges the common perception of TOGAF as a definitive guide for EA practitioners, prompting a deeper reflection on its role.

TOGAF: Methodology or Toolkit?

A central point of discussion revolves around TOGAF’s identity: is it a consistent methodology or merely a toolkit?

Original Intent as Methodology: Kotusev highlights that TOGAF’s original documentation explicitly positioned it as “a detailed method and a set of supporting tools.” The Architecture Development Method (ADM) was described as a “step-by-step approach,” and the Architecture Content Framework (ACF) as a “detailed model of the outputs to be created by the ADM.” This indicates an initial design as a comprehensive, consistent methodology.
Repositioning as Toolkit: In practice, many architects find it challenging to follow the ADM’s prescribed steps or produce the extensive documentation recommended by the ACF. This practical disconnect has led to TOGAF being increasingly positioned by its community as a “useful toolkit” rather than a rigid methodology. Kotusev suggests this repositioning occurred because the “detailed method” proved impractical in real-world scenarios.
Evolution of “Framework”: Even the term “Framework” in TOGAF’s title has seen a reinterpretation. Initially, an EA framework was defined as a “logical structure for classifying and organizing the descriptive representations of an Enterprise.” However, contemporary interpretations by TOGAF trainers often equate “Framework” with “a set of reusable components,” akin to software frameworks, a meaning that diverges from its original definition.

This shift from a prescriptive methodology to a more flexible toolkit, alongside the redefinition of core terminology, suggests an adaptation to practical realities where a rigid, original approach might have been unworkable.

Best Practice: Claim Versus Reality

The Open Group asserts that TOGAF is based on “best practice” developed through the collaborative efforts of numerous leading companies. However, Kotusev’s research prompts us to question this claim:

Lack of Real-World Adherence: If practitioners do not consistently follow the ADM or create the recommended documents, whose “best practice” does TOGAF truly represent? Kotusev notes that he has “never seen any architects or organizations who might have said that the ADM, ACF or Enterprise Continuum represent their actual best practice.”
Origins in TAFIM: TOGAF’s foundation in the Technical Architecture Framework for Information Management (TAFIM) is also scrutinised. TAFIM was reportedly retired due to its impracticality and high costs, which raises valid questions about how a framework based on an unsuccessful predecessor can claim to embody best practice.
Marketing Motivation: Kotusev suggests that the “best practice” claims are primarily marketing statements, driven by the significant revenue generated from TOGAF certifications, training, and related services.

Furthermore, Kotusev argues that actual best practices in EA are often not fully captured within TOGAF. A prime example is the Business Capability Map (BCM), widely used in many organisations for strategic alignment and IT investment, yet “not even mentioned in TOGAF at all.” This highlights a potential gap between TOGAF’s content and the practical tools employed by successful EA practices.

The Illusion of Flexibility

TOGAF’s proponents often praise its flexibility, arguing it can be tailored to various organisational contexts. Kotusev, however, views this flexibility as a “logical trick” or “catch-22.”

Removed Categorisation Model: Earlier versions of TOGAF (e.g., Version 9) categorised its content into “core,” “mandated,” “recommended,” and “supporting” sections, implying that certain elements were essential for it to be “recognizably TOGAF.” The removal of this categorisation model in TOGAF Version 9.1 effectively allows any EA-related activity to be interpreted as “using adapted TOGAF,” regardless of its actual adherence to the framework’s recommendations.
Unspecified Adaptation: While TOGAF’s documentation mentions the need for adaptation, it provides little guidance on how to adapt it effectively. This can leave practitioners to “adapt” TOGAF by essentially setting aside its impractical recommendations and devising their own solutions.
“Lossless Lottery” for The Open Group: This “flexibility trick” places The Open Group in a beneficial position: failures can be attributed to improper adaptation by unqualified architects, while successes can be “appropriated” as TOGAF-based due to its broad adaptability.

In essence, Kotusev concludes that TOGAF’s admired flexibility “is nothing more than a simple trick helping (1) conceal impracticality of the actual TOGAF’s recommendations, (2) put the burden of responsibility for improper adaptation on EA practitioners, (3) avoid any potential criticism and (4) interpret successes and failures ‘properly’.”

TOGAF 10: Addressing Criticisms, or More Symbolic Than Ever?

Kotusev’s analysis of the TOGAF Standard, 10th Edition, prompts us to consider whether the latest version genuinely addresses long-standing criticisms or merely reinforces its symbolic status.

Attempting to Address Criticisms: The 10th edition attempts to address some long-standing criticisms, such as the perception of the ADM as a rigid waterfall model. The removal of arrowheads from the ADM aims to convey a more iterative and agile approach. However, Kotusev argues this is a “patently perfunctory, ‘quick and dirty’ fix” [Kotusev, “The TOGAF Standard, 10th Edition: What’s New?”].
Restructuring, Not Substantive Change: The 10th edition primarily involves restructuring and extending content, splitting the previous monolithic manual into “TOGAF Fundamental Content” and “TOGAF Series Guides.” While presented as an improvement for usability, Kotusev argues that “no substantial changes have actually been introduced to the framework.”
Rhetorical Novelties: New guides often address trendy topics like “digital” and “agile,” but offer little concrete advice beyond asserting TOGAF’s compatibility. The introduction of terms like “minimum viable architecture (MVA)” is seen as applying agile terminology to EA without substantive methodological changes.
Contradictory Statements: The removal of arrowheads from the ADM in the 10th edition, intended to counter the perception of a waterfall model, has led to contradictions within the text. While some sections still describe the ADM as a “tested and repeatable process” with a “recommended sequence,” others explicitly state that “The TOGAF ADM should not be understood as a processes model.”
Increased Volume, Decreased Clarity: Despite the modularisation, the total volume of TOGAF documentation has increased significantly, making it even more challenging to comprehend. Kotusev describes the text as “very poorly written, incoherent and hard to follow,” with repetitions and unintelligible fragments.

This analysis suggests that while TOGAF 10 makes an effort to adapt rhetorically to current industry buzzwords, it may inadvertently further obscure its already vague ideas, potentially reinforcing its symbolic status rather than enhancing its practical clarity.

What is TOGAF, Then?

Kotusev ultimately characterises TOGAF as “a toolkit of random EA-related recommendations” that struggles to clearly define what EA practice is. Its value, from this perspective, can be haphazard, realised only if some of its recommendations “accidentally turn out useful.”

He also describes TOGAF as a “distractor of attention,” potentially shifting discourse away from real EA-related questions towards artificial ones about TOGAF’s application or advantages. This can lead to a “doublethink” phenomenon, where TOGAF’s existence implies extensive knowledge of EA practice, yet its perceived impracticality means no one can specify how it should be used.

Kotusev provocatively likens TOGAF to a “religious text” due to its disputable origins, perceived mythical wisdom, need for interpretation by “enlightened gurus,” and its vague, unchanging core text with evolving interpretations. While a strong metaphor, it underscores the challenge of objectively assessing a framework that often evokes strong opinions.

Conclusion

Kotusev’s critical scrutiny provides a valuable counterpoint to the conventional view of TOGAF. While my previous post explored how engineers might pragmatically extract value from TOGAF’s concepts, Kotusev’s analysis suggests that such an approach often involves “studying TOGAF and then doing something else instead.”

The framework’s popularity, he argues, stems from aggressive promotion, a perceived lack of serious alternatives, and the “inertness” of the EA research community. For many, TOGAF certification offers symbolic benefits for career progression rather than necessarily fostering genuine architectural competence.

Ultimately, I view TOGAF as a collection of ideas that can still be useful, provided one approaches it with a critical and reflective mindset. It is not a perfect, ready-to-use methodology, and its evolution, particularly in the 10th edition, shows an attempt to respond to criticisms, even if those responses are sometimes perceived as superficial. The key lies in understanding how and what to use from it, rather than adhering to it blindly. For those seeking a deeper, practical understanding of EA, it is crucial to complement TOGAF with evidence-based sources and real-world experience.

TOGAF: A Pragmatic Starter Kit for Engineers

2025-10-09T00:00:00Z

The Open Group Architecture Framework (TOGAF) has long been a foundational standard for Enterprise Architecture. The framework continues to evolve, offering a structured yet adaptable approach to managing the complexity inherent in modern enterprise systems. This post aims to distil the essence of TOGAF, particularly for software engineers, focusing on its practical application, the establishment of an architecture capability, and the sustained maintenance of architectural integrity. It addresses the common challenges faced in integrating architectural principles into dynamic development environments, providing a pragmatic pathway to leverage TOGAF’s benefits without succumbing to bureaucratic overhead.

Architecture is a moving target; TOGAF simply gives you a rifle and a compass—not a cage.

1. Why Implement TOGAF?

The strategic implementation of TOGAF offers distinct advantages over ad-hoc architectural practices, particularly in mitigating common organizational inefficiencies and risks.

Pain without TOGAF	Pain with ad-hoc TOGAF	Gain with disciplined TOGAF
Ambiguity regarding data ownership and system responsibilities across development teams.	Extensive, often unread, architectural documentation lacking practical application.	Concise Architecture Vision documents complemented by living data catalogues.
Repetitive integration efforts for disparate systems following organizational expansion.	Protracted architectural definition phases, leading to delayed project initiation.	Streamlined Architecture Development Method (ADM) cycles, fostering the creation of reusable building blocks.
Recurring audit findings due to inconsistent architectural adherence.	Superficial governance processes that fail to enforce architectural standards effectively.	Robust governance mechanisms, including Architecture Board reviews linked to verifiable compliance checks.

The enduring relevance of TOGAF lies not in its rigidity, but in its capacity to provide a structured approach to architectural development and governance. The framework has refined this, emphasizing adaptability and integration with contemporary development methodologies such as Agile and DevOps. The core Architecture Development Method (ADM) remains a robust foundation for guiding architectural efforts, irrespective of prevailing technological trends. For a deeper understanding of its application in solution architecture, refer to Anatolii Gabuza’s article: “What Software Engineers Should Know About “TOGAF” Solution Architecture?”.

2. The Architecture Development Method (ADM): A Conceptual Overview

The ADM, central to TOGAF, can be conceptualized as an iterative, risk-driven process akin to an OODA (Observe, Orient, Decide, Act) loop, guiding the evolution of enterprise architecture.

Observe – Encompasses the Preliminary Phase and Architecture Vision, focusing on establishing the architecture capability and defining the scope and high-level vision.
Orient – Involves the detailed definition of Business, Information Systems (Data and Application), and Technology Architectures.
Decide – Addresses Opportunities & Solutions and Migration Planning, translating architectural definitions into actionable implementation strategies.
Act – Pertains to Implementation Governance and Architecture Change Management, ensuring adherence during implementation and managing subsequent architectural evolution.

This iterative nature underscores that the ADM is not a linear, waterfall model. It is expected that insights gained during the “Act” phase, particularly from actual implementation, may necessitate revisiting earlier “Orient” phases to refine architectural decisions.

3. Initiating the First Iteration

A pragmatic approach to adopting TOGAF involves a focused, iterative launch, prioritizing tangible outcomes over comprehensive documentation.

Step 0 – Defining the Scope

Effective scoping is paramount for a successful initial iteration. This involves:

Breadth: Concentrating on a single, manageable value stream (e.g., “customer onboarding”).
Depth: Limiting the architectural detail to a “container” level. The C4 model, while not explicitly mentioned or endorsed by TOGAF, provides a hierarchical approach to modelling technical architecture, allowing for different levels of detail to be presented to various audiences. This aligns with the TOGAF principle of views and viewpoints, ensuring stakeholders receive tailored perspectives.
Domains: Potentially deferring a deep dive into Business Architecture if the “why” of the initiative is already clearly articulated by product management.

Step 1 – Preliminary Phase

This phase establishes the foundational elements for architectural work.

Role Assignment: Designate an Architecture Owner (typically a lead engineer) and a Business Sponsor (e.g., a product director).
Principle Definition: Draft a concise set of five core Architecture Principles to guide decision-making. An example could be: “Services are reusable across divisions unless a legal exemption is formally granted by the Architecture Board.” These principles, as defined in TOGAF, are enduring rules that guide decision-making and support governance.
Tooling Selection: Establish a centralized, version-controlled repository for architectural artefacts, such as a Confluence space or a Git repository. This aligns with the concept of the Architecture Repository as a central vault for architectural outputs.

Step 2 – Architecture Definition Sprint (Phases A→D)

This period focuses on developing the initial architectural definitions.

Architecture Vision: Conduct a collaborative workshop to produce a high-level Architecture Vision document. While TOGAF defines the Architecture Vision as a key deliverable, it does not specify its format or length. A concise, one-page summary can be an effective way to gain stakeholder approval.
Parallel Track Development:
- Data Architecture: Identify canonical data entities, their respective owners, and critical quality dimensions. This corresponds to the Data Architecture aspect of Phase C.
- Application Architecture: Map existing application capabilities, categorizing them for retirement, retention, or new development. This corresponds to the Application Architecture aspect of Phase C.
- Technology Architecture: Define the target technology stack, security zones, and non-functional requirements. This is the focus of Phase D.
Gap Analysis and Risk Identification: Consolidate findings into a gap matrix and a comprehensive risk register. Gap analysis is a key technique to identify differences between baseline and target architectures.
Architecture Board Review: Conduct a concise review with the Architecture Board to capture key decisions. While TOGAF supports documenting decisions, it does not use the specific term “Architecture Decision Records (ADRs)” or prescribe this format. However, the practice of formally recording architectural decisions is consistent with TOGAF’s emphasis on governance and accountability.

Step 3 – Planning for Implementation (Phases E→F)

This phase translates architectural definitions into an actionable implementation plan.

Work Package Definition: Decompose identified gaps into manageable work packages, ideally requiring limited effort.
Prioritization and Resource Allocation: Prioritize work packages using methodologies like MoSCoW, assigning estimated costs, risks, and business value.
Migration Plan: Document the Migration Plan as a dynamic artefact. While TOGAF defines the Architecture Roadmap and Migration Plan, it does not specify tooling. Using dynamic boards like DevOps can be a practical approach to manage and visualize the plan.

Step 4 – Continuous Governance (Phases G→H)

Sustained architectural integrity requires continuous oversight and adaptation.

Compliance Checks: Implement regular compliance checks to ensure development activities adhere to established architectural decisions. While TOGAF supports early compliance and governance, it does not explicitly mention code-level enforcement mechanisms like pull request checks. However, such mechanisms can be effective in ensuring implementation projects conform to the Target Architecture, which is a core objective of Phase G, Implementation Governance.
Change Management: Establish a “change window” to review new requirements and funnel them into the Requirements Management log. Triggering mini-ADM cycles based on change thresholds is not formally defined in TOGAF, though Phase H (Architecture Change Management) supports iterative updates and managing changes to the new architecture. This pragmatic approach helps maintain the architecture’s relevance.

4. Essential Architectural Artefacts

To maintain agility and avoid documentation overload, focus on a minimal set of high-impact artefacts, ensuring they are version-controlled and easily accessible.

Artefact	Storage Location	Update Trigger	Primary Audience
Architecture Vision (1 page)	`docs/vision.md`	Introduction of a new strategic objective.	Executive leadership, stakeholders.
Architectural Decision Log	`docs/adr/`	Each significant architectural decision.	Development teams, architects.
Data Catalogue (auto-generated)	GitHub Pages	Schema changes or new data entity definitions.	Data engineers, business analysts.
C4 Diagrams (Levels 1-3)	Mermaid in repository	Introduction of new containers or significant system changes.	Development teams, architects.
Roadmap Board	Devops/Miro/Trello or similar platform	Conclusion of each Program Increment (PI).	Project Management Office (PMO), stakeholders.

If an architectural artefact is not maintained within a version control system, its practical utility and reliability are diminished.

5. Sustaining Architectural Momentum

Maintaining a living architecture requires embedding architectural practices into routine organizational processes.

Integration with Development Rituals:
- Sprint Planning: Incorporate a review of the architectural decision log to identify architectural implications for upcoming user stories.
- Demonstrations: Present architecture compliance dashboards, providing visual feedback on adherence to architectural standards.
Performance Measurement: While TOGAF discusses KPIs and maturity models, it does not define specific metrics such as re-use ratio, escape rate, or time-to-integrate. However, organizations can define their own relevant metrics to gauge the effectiveness of their architectural practice.
Annual Principle Review: Periodically (e.g., annually) review and refresh architectural principles. Any principle that cannot be linked to a measurable outcome or address a recurring issue should be re-evaluated or retired.
Leveraging the TOGAF Library: Utilize the TOGAF Series Guides selectively, focusing on those directly relevant to current organizational needs. Examples include:
- For Agile development: “ADM & Agile”
- For cloud migration initiatives: “Cloud Architecture”
- For security mandates: “Security Architecture”

6. Common Pitfalls and Mitigation Strategies

Experience reveals recurring challenges in architectural practice. Awareness and proactive mitigation are key.

Trap	Symptom	Antidote
Big-Bang Target Architecture	Overly ambitious, multi-year architectural projects yielding no intermediate deliverables.	Adopt a capabilities-based roadmap with short-term horizons.
Template-Driven Documentation	Production of voluminous, generic documents filled with boilerplate content.	Prioritize concise, purpose-driven documentation. Each artefact should address a specific audience and concern.
Retrospective Governance	Architecture Board reviews occurring only after significant implementation efforts are complete.	Implement “shift-left” governance, where architectural compliance is assessed at earlier stages, such as during code reviews or pull request approvals.

Key Takeaways

TOGAF is a lightweight risk-management loop, not a document factory.
Run the first ADM cycle lean: focused scope, limited principles.
Store architectural truth in Git, not static documents.
Tie every governance gate to a working product increment.
Iterate continuously—architecture requires ongoing adaptation.

TOGAF, when applied judiciously, serves as a powerful tool for strategic alignment and risk management, ensuring that architectural efforts contribute directly to business value. By embracing its iterative nature and focusing on pragmatic application, engineers can effectively leverage TOGAF to navigate the complexities of enterprise-scale development.

Vibe Engineering: The Senior Developer's Approach to LLMs

2025-10-08T00:00:00Z

Simon Willison has introduced the concept of “vibe engineering” to distinguish a rigorous, professional approach to working with Large Language Models (LLMs) from the more casual “vibe coding.” While “vibe coding” often involves fast, prompt-driven software development with less attention to underlying mechanics, “vibe engineering” focuses on integrating LLMs into established software engineering best practices, treating the LLM as a junior developer under the guidance of a senior engineer.

This concept also builds on Simon’s earlier work, which I have previously explored, regarding the effective and safe use of AI in development. Specifically, his insights on embracing parallel coding agents and designing safe and effective agentic loops provide crucial context for understanding the “vibe engineering” philosophy.

The Essence of Vibe Engineering

Vibe engineering is about seasoned professionals accelerating their work with LLMs while maintaining accountability for the software they produce. It acknowledges that productive engagement with LLMs is complex, requiring a deep understanding of the tools and an awareness of potential pitfalls. The rise of coding agents—such as Claude Code, OpenAI’s Codex CLI, and Gemini CLI—has amplified the need for this structured approach, as these tools can iterate on code, test, and modify it to achieve specified goals.

Simon notes that he is increasingly hearing from experienced engineers who are running multiple agents simultaneously, tackling several problems in parallel. He himself has started running multiple agents, finding it surprisingly effective, albeit mentally demanding. This contrasts sharply with “vibe coding,” where simple, low-stakes tasks are outsourced to an LLM with less rigorous review.

“Iterating with coding agents to produce production-quality code that I’m confident I can maintain in the future feels like a different process entirely.”

Key Elements of Vibe Engineering

Vibe engineering actively rewards and amplifies existing top-tier software engineering practices. The following elements are crucial for effectively leveraging LLMs in a professional development context, categorised for clarity:

I. Technical Foundations

Automated Testing: Robust, comprehensive, and stable test suites allow agentic coding tools to operate efficiently. Without tests, agents might claim functionality without actual verification, and new changes could introduce regressions unnoticed. Test-first development is particularly effective with agents.
Comprehensive Documentation: LLMs, like human programmers, have limited context windows. Providing relevant documentation enables them to use APIs from other areas without needing to read the entire codebase. Well-written documentation can even allow models to build implementations from input alone.
Good Version Control Habits: The ability to undo mistakes and understand change history is paramount, especially when coding agents are making modifications. LLMs are proficient with Git, capable of navigating history and using tools like git bisect to track down bug origins.
Effective Automation: Continuous integration, automated formatting and linting, and continuous deployment to preview environments all benefit agentic coding tools. LLMs can also facilitate the creation of quick automation scripts for consistent task repetition.

II. Strategic & Managerial Skills

Planning in Advance: A high-level plan is essential before beginning development. With agents, this becomes even more critical; the plan can be refined first, then handed off to the agent for code generation.
A Unique Form of Management: Interacting with coding agents requires clear instructions, necessary context, and actionable feedback, akin to managing a human collaborator. While agents do not have emotions, existing management experience proves surprisingly useful in guiding their work.
Instinct for Outsourcing: Developing an intuition for what tasks are best delegated to AI and what requires manual handling is an evolving skill.
Updated Sense of Estimation: AI-assisted coding changes project timelines significantly. Estimating project duration, a core senior engineer skill, becomes more complex as tasks that were once time-consuming become much faster, introducing new variables for consideration.

III. Quality Assurance & Review

Culture of Code Review: A fast and productive code review process is vital when working with LLMs. This ensures quality and allows for human oversight of agent-generated code.
Strong Manual QA: Beyond automated tests, proficiency in manual testing, including predicting and investigating edge cases, is crucial.
Ability to Ship to a Preview Environment: Safely previewing agent-built features before production deployment makes reviews more productive and reduces deployment risks.

IV. Problem Solving & Research

Research Skills: The ability to identify the best approaches and validate solutions remains important before engaging an agent to write code.

These characteristics are largely those already possessed by senior software engineers. AI tools, therefore, serve to amplify existing expertise; the more skills and experience a developer has, the better and faster the results they can achieve with LLMs and coding agents.

The “Senior Developer” Analogy

The analogy of treating an LLM as a junior developer is fitting. A senior developer provides clear instructions, sets up a supportive environment (including robust testing and documentation), reviews the junior’s work, and guides them towards the desired outcome. This mirrors the “vibe engineering” approach, where the human engineer acts as the architect and manager, ensuring the LLM’s output aligns with project goals and quality standards.

“You’re not just responsible for writing the code—you’re researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review.”

This perspective highlights the shift in the senior engineer’s role: from solely writing code to orchestrating and validating the work of AI collaborators. It is a more sophisticated way of working with AI tools to build production-ready software, ensuring that the power of LLMs is harnessed responsibly and effectively.

I applaud Simon Willison for articulating this nuanced approach, which provides a valuable framework for navigating the evolving landscape of AI-assisted development. His work consistently offers practical and forward-thinking insights into this rapidly changing field.

Extracting Knowledge from PDFs: Advanced Techniques and Local Solutions

2025-10-07T00:00:00Z

The challenge of extracting structured information from PDF documents for use with Large Language Models (LLMs) is a significant topic in AI. Andrew Ng, through his newsletter, has shed light on both the complexities and emerging solutions in this area. This post examines the principles behind advanced document extraction, exemplified by concepts from LandingAI’s Agentic Document Extraction (ADE), and contrasts them with a local PDF-to-Markdown conversion tool I developed, inspired by Simon Willison’s work.

The Challenge of PDF Data Extraction

PDFs frequently contain what is termed “dark data”—information that exists but remains largely inaccessible for automated analysis. Historically, the static and visually oriented nature of PDFs made it difficult for software to interpret their content beyond basic text recognition. With the advent of LLMs, the potential to derive meaning from vast archives of PDF documents has grown, yet accurate extraction remains a hurdle.

Andrew Ng highlights a critical aspect of this challenge:

“Some of the most disconcerting mistakes I’ve seen a computer make have been when a system incorrectly extracted figures from a large table of numbers or complex form and output a confident-sounding but incorrect financial figure. Because our intuition tells us that computers are good at numbers (after all, computers are supposed to be good at computing!), I’ve seen users find silent failures in the form of incorrect numerical outputs particularly hard to catch.”

This observation underscores that simple text extraction is often insufficient; a deeper understanding of document structure and context is required to prevent subtle, yet impactful, errors.

Principles of Advanced Document Extraction (e.g., Agentic Approaches)

Advanced document extraction systems, such as those employing “agentic” principles, aim to overcome the limitations of traditional OCR by mimicking human-like understanding. The core idea is to process documents not as flat images or simple text streams, but as structured entities with visual and semantic relationships.

Key principles often include:

Intelligent Document Understanding: Moving beyond basic Optical Character Recognition (OCR) to interpret visual cues, such as the layout of form fields, tables, and checkboxes. This involves understanding the purpose of elements based on their visual presentation.
Complex Layout Extraction: Decomposing documents into semantic units rather than just text blocks. This allows for parsing diverse formats (e.g., PDFs, scanned images, complex tables) without extensive pre-training for each specific layout. The goal is to identify intricate relationships between elements.
Accurate Extraction of Structured Data: Systems are designed to precisely extract data from tables, charts, and other complex visual layouts. This minimises errors that arise from text-only analysis, ensuring comprehensive data capture.
Visual Grounding: The ability to pinpoint the exact location of visual elements and text within a document. This feature is crucial for verifying extracted information by linking it back to its source, thereby building trust in AI-generated insights.
Field-Specific Extraction: The capability to extract only specific, relevant fields from documents (e.g., invoice numbers, medical record entries). This automates large-scale data capture, reduces manual errors, and ensures consistency.

The “agentic workflow” concept suggests that, much like a human, an AI system can iteratively examine different parts of a document to gather information piece by piece. This might involve using specialised models, such as a Document Pre-trained Transformer (DPT), to break down complex documents into smaller, more manageable sub-problems, leading to more accurate results.

My Local PDF-to-Markdown Tool: The Sacred Scroll Transcriber

In contrast to comprehensive, cloud-based solutions, I developed “The Sacred Scroll Transcriber” as a local, privacy-focused tool for converting PDFs to Markdown. Inspired by Simon Willison’s work on client-side OCR, this static site operates entirely within the user’s browser.

Core Capabilities:

Local Processing: All operations, from PDF rendering to OCR, are performed client-side, ensuring no data leaves the user’s device.
OCR-Based Extraction: It leverages Tesseract.js for optical character recognition. Each PDF page is first rendered as an image, and then OCR is applied to extract text.
Markdown Output: The tool converts the extracted text into Markdown format, aiming to preserve the document’s structure where possible.
Image Handling: It can extract and display images embedded within the PDF.
User-Centric Design: The tool is designed for straightforward use, allowing users to upload a PDF and download the transcribed content.

Technical Approach (Inspired by Simon Willison):[1]

PDF Page Rendering: PDF.js is used to render each page of the PDF to a high-resolution canvas.
Image Conversion: The content of the canvas is then converted into a JPEG image format.
Tesseract OCR: Tesseract.js processes these rendered images to perform text recognition.
Structured Output: The recognised text is organised by page and formatted into Markdown.

While my tool offers a practical, privacy-conscious solution for converting PDFs to a structured text format, it primarily relies on image-based OCR. Advanced systems, by contrast, integrate a deeper understanding of visual context and semantic relationships, making them suitable for highly complex documents where precise data extraction and verification are paramount for applications like financial analysis or medical record processing.

This approach is directly inspired by Simon Willison’s OCR tool. ↩︎

Embracing the Parallel Coding Agent Lifestyle

2025-10-06T00:00:00Z

Simon Willison’s recent post, “Embracing the parallel coding agent lifestyle”, details his evolving approach to using multiple AI coding agents concurrently. Initially sceptical, Simon has found specific scenarios where parallel agents significantly boost efficiency without overwhelming the human reviewer.

“I can only focus on reviewing and landing one significant change at a time, but I’m finding an increasing number of tasks that can still be fired off in parallel without adding too much cognitive overhead to my primary work.”

Effective Patterns for Parallel Agents

Simon outlines several patterns where running multiple agents proves beneficial:

Research for Proof of Concepts: Agents can quickly build proof-of-concept implementations for new libraries or technologies, even if they are too new to be in the training data. This helps answer fundamental questions about feasibility and integration.
Understanding Existing Systems: For complex codebases, agents can provide detailed explanations of how specific parts of the system function. They can trace code paths, identify dependencies, and summarise functionality, which can then be used as context for future prompts.
Small Maintenance Tasks: Low-stakes tasks, such as fixing deprecation warnings or minor irritations, can be delegated to agents. This allows the developer to remain focused on primary work while the agent resolves peripheral issues.
Carefully Specified and Directed Work: When the developer provides a precise specification, agents can generate code that requires less effort to review. This “authoritarian approach” to prompting reduces the cognitive load of validation.

Simon currently uses a mix of Claude Code (on Sonnet 4.5), Codex CLI (on GPT-5-Codex), and Codex Cloud for asynchronous tasks. He often runs multiple terminal windows with different agents, sometimes in “YOLO mode” for tasks where the risk of malicious instructions is low.

Jesse Vincent’s Parallel Agent Workflow

Jesse Vincent’s article, “How I’m using coding agents in September, 2025”, provides a detailed workflow for parallel agents, primarily using Claude Code. Jesse employs a “brainstorming” prompt to refine ideas into a design and specification, followed by a “planning” prompt to generate a comprehensive implementation plan.

A key aspect of Jesse’s method involves using two separate Claude Code instances: an “architect” and an “implementer”.

Architect Agent: This agent focuses on design, planning, and reviewing the work of the implementer. It helps clarify and update the planning document.
Implementer Agent: This agent executes the tasks outlined in the plan. It works in small chunks, and its output is reviewed by the architect.

Jesse also uses git worktree to isolate tasks, allowing multiple agents to work on different features within the same codebase concurrently. For code review, he integrates CodeRabbit, but adds a layer of role-play to his prompts, asking the agent to evaluate the reviewer’s suggestions critically rather than blindly applying them.

“A reviewer did some analysis of this PR. They’re external, so reading the codebase cold. This is their analysis of the changes and I’d like you to evaluate the analysis and the reviewer carefully.”

Personal Commentary

The concept of running parallel coding agents, as described by Simon and Jesse, offers a compelling vision for enhanced development productivity. The ability to offload research, minor fixes, or even carefully specified implementation tasks to AI agents while maintaining focus on a primary task is particularly appealing.

I believe this approach can be highly effective, especially for projects where the review bottleneck is managed. I am keen to explore this further, potentially by setting up a local environment using tools like y-router^[1] to connect Claude Code CLI with OpenRouter. This would allow me to experiment with various LLMs and host my own local LLM safely accessible via Tailscale. The inherent latency in receiving responses from LLMs suggests that spinning up multiple agents in parallel could be a natural way to maximise throughput, as one might as well initiate another task while waiting for a current one to complete.

y-router is a Cloudflare Worker that translates between Anthropic’s Claude API and OpenAI-compatible APIs, enabling the use of Claude Code with OpenRouter and other OpenAI-compatible providers. ↩︎

The Leader's Duty to Train and the Culture of Discipline

2025-10-03T00:00:00Z

The importance of rigorous, realistic training is crucial for any team facing high-stakes situations. This principle, discussed in a very informative and valuable podcast episode (Jocko Podcast #419) featuring Jocko Willink and Leif Babin, is well worth the time to listen to and extends beyond military applications to any organisation where performance under pressure is critical.

A leader’s fundamental duty is to ensure their people are prepared for the worst-case scenario. This preparation is not merely about ticking boxes; it is about instilling automatic, effective responses through disciplined practice.

The Necessity of Hard Training

The discussion highlights a memorable story about PFC Willie Lump Lump, a fictional character used as a training aid. While Willie Lump Lump is not a real person, the story serves as a powerful example. It illustrates the severe cost of training that is weakened by external pressures or misplaced concerns.

“The only way to prepare men for combat is to train them in conditions as close to the real thing as possible.”

This means accepting the inherent risk in realistic training to ensure readiness when the stakes are highest. Visualising this negative outcome helps drive home the core message: training saves lives.

Formal vs. Informal Training (OJT)

While formal training provides a necessary foundation, the most critical learning occurs through On-the-Job Training (OJT).

Training Type	Description	Value Proposition
Formal	Structured courses, classroom instruction, theoretical foundation.	Provides baseline knowledge and fundamental concepts.
Informal (OJT)	Learning through direct application, mentorship, and real-time problem-solving.	Develops practical skills, adaptability, and decision-making under pressure.

The Leader’s Role in OJT:

Instead of providing a complete solution (e.g., a pre-made project timeline), the leader should present the problem and require the subordinate to develop the solution.

Present the Problem: “Here is the project. Come up with a timeline.”
Review and Coach: Review the proposed solution, identifying gaps and providing context (e.g., procurement lead times, logistical constraints).
Iterate: Repeat the process on the next project, allowing the subordinate to apply learned lessons.

This approach forces critical thinking, connects theory to practice, and accelerates the subordinate’s development, eventually enabling them to perform better than the leader in that specific domain.

Connecting the Classroom to Chaos

A key challenge in training is bridging the gap between theoretical instruction and the chaos of real-world application. The use of visual aids, such as a magnet board to simulate tactical scenarios, proved highly effective.

Detached Perspective: By viewing the problem from an elevated, detached perspective (like a chessboard), leaders and subordinates can understand the overall flow and consequences of their actions, which is impossible when immersed in the immediate chaos.
Simplification: Complex procedures (like Immediate Action Drills) must be simplified to core principles (e.g., “If you move, someone must cover you”). This allows for flexible application rather than rigid memorisation.
Flexibility: Leaders must understand the parameters within which they can manoeuvre. While support roles may have tighter constraints, the leader must be able to move where necessary to influence the situation.

Building a Culture of Discipline

Training and leadership development must be woven into the fabric of the organisation’s culture. Culture is defined not by what is preached, but by what is tolerated and exemplified.

Element	Description	Impact on Culture
Setting the Example	The leader’s actions are constantly observed and judged. If the leader cuts corners or avoids difficult tasks, the team will emulate that behaviour.	Establishes the true standard of effort and commitment.
Propagating History	Sharing the organisation’s history, successes, and failures. This can be done through stories, documentation, or physical displays (like banners or plaques).	Provides context, fosters pride, and reinforces core values.
Rewards and Mitigation	Publicly rewarding behaviour that supports the culture and mitigating (or penalising) behaviour that undermines it.	Clearly defines acceptable and unacceptable standards of conduct.
Material Items	Patches, uniforms, or insignia that must be earned. These items serve as tangible symbols of achievement and shared identity.	Creates a sense of belonging and pride, provided the value is earned, not given.
Language	The use of specific slogans, mantras, or common phrases (e.g., “No Slack,” “Prioritise and Execute”).	Unifies the team’s mindset, creates a shared understanding, and reinforces cultural attitudes towards challenges.

Taking Care of Your People

Taking care of people is often misunderstood as coddling or avoiding discomfort. True care involves discipline—setting high standards and pushing individuals to achieve their long-term potential.

Long-Term Success: A leader’s focus must be on the long-term success of their team members, which often requires demanding performance and holding the line on standards.
The Truth: Leaders must always tell the truth, even when it is difficult. This builds trust and ensures the team has an accurate assessment of the situation, even if the truth reveals the leader’s own shortcomings (e.g., failing to build a necessary relationship with a superior).
Shared Hardship: Hard training and shared suffering strengthen bonds and make the culture stronger. Teams that endure difficult challenges together develop a tougher, more unified identity.

Stop Avoiding Politics

2025-10-02T00:00:00Z

The post Stop Avoiding Politics from Terrible Software tackles a common aversion among engineers: workplace politics. The author argues that dismissing politics as a “dirty game” is a strategic mistake. The core problem isn’t politics itself, but bad politics. By refusing to participate, well-intentioned engineers cede influence, allowing poor decisions to be made without their input.

Perspective like this and other on influencing link to the realities of power explored in Niccolò Machiavelli’s The Prince. Written as a guide for acquiring and maintaining political power, its lessons are surprisingly applicable to modern organisational dynamics.

Politics, in this context, is simply the mechanism of human coordination within groups—the network of relationships, influence, and informal power present in every organisation.

Good politics is just being strategic about relationships and influence in the service of good outcomes.

The author contrasts two mindsets: the engineer who avoids politics and complains about bad decisions, and the engineer who understands that “ideas don’t speak. People do.” The latter engages in what is often reframed as “stakeholder management” or “building alignment,” which are essentially political skills used for positive ends.

Machiavellian Principles for Modern Influence

Machiavelli’s work provides a foundational theory for understanding why engaging with politics is necessary. His central argument is that a leader must be pragmatic, understanding the world as it is, not as we wish it to be.

Machiavellian Concept	Application in Modern Organisations
Virtù vs. Fortuna	Relying on skill and ability (`virtù`) to navigate chance and circumstance (`fortuna`), rather than hoping merit alone will suffice.
The Importance of Appearances	Managing perception and being visible, ensuring good work is recognised.
It is Better to be Feared than Loved	Translated to a corporate context: being respected for your competence and reliability is more durable than being liked.
The Lion and the Fox	Combining the strength of the lion (technical competence) with the cunning of the fox (political acumen) to be effective.

Good Politics in Practice

The article provides concrete examples of what constructive political engagement looks like, which align with these principles:

Building relationships before you need them: A casual coffee with a colleague from another team can turn them into a valuable ally months later. This is an exercise in building a base of support, a key Machiavellian strategy.
Understanding real incentives: Framing technical proposals in terms of what decision-makers actually care about (e.g., shipping speed, not microservices architecture). This is pragmatism—understanding what truly motivates people.
Managing up effectively: Keeping managers informed and presenting solutions, not just problems, to build trust. This strengthens your position and influence (virtù).
Creating win-win situations: Finding ways to collaborate that benefit multiple parties instead of engaging in zero-sum fights for resources. This secures alliances and stabilises your position.
Being visible: Ensuring that good work is seen and recognised through presentations, documentation, and communication. This is the modern equivalent of managing your reputation and appearances.

The alternative to good politics isn’t no politics. It’s bad politics winning by default. The choice mirrors the dilemma Machiavelli presents: to engage with the messy reality of power or to be governed by it. Leading and influencing from where you stand, without formal authority, is the essence of practical leadership. Giving it our all means mastering the art of influence to champion good ideas and protect our teams, embracing the pragmatism that has been necessary for effective action for centuries.

Designing Safe and Effective Agentic Loops

2025-10-01T00:00:00Z

AI coding agents that can write, execute, and correct their own code represent a significant step forward. However, their power comes with inherent risks. In his post on designing agentic loops, Simon Willison provides a clear case for what is needed to work with these agents effectively and safely.

An agentic loop, as Simon defines it, is an LLM running tools in a loop to achieve a goal. The skill lies in carefully designing that loop and the tools within it.

The Risk of “YOLO Mode”

To get the most out of these agents, they need to run unattended in what Simon calls “YOLO mode,” where they can execute commands without constant human approval. This is also where the danger lies. As Solomon Hykes memorably put it:

An AI agent is an LLM wrecking its environment in a loop.

The primary risks of an unattended agent include:

Executing destructive shell commands that delete or corrupt files.
Exfiltrating sensitive data like source code or API keys.
Using your machine as a proxy for malicious attacks on other systems.

A Practical Approach to Safety

Simon outlines three ways to manage these risks, with a clear preference for one. While you can take the risk on your local machine or trust the tool’s built-in sandboxing, the most robust approach is to use a secure, isolated environment.

His preferred method is to use “someone else’s computer.” This is a practical idea; by running the agent in a disposable, cloud-based environment like a GitHub Codespace, you contain the potential damage. If the agent goes rogue, it does so on a temporary virtual machine, not your primary workstation. This prevents breaches of your local data and contains any harm to the isolated environment.

Designing an Effective Loop

Once a safe environment is established, the focus shifts to designing the loop itself.

Provide the Right Tools: Agents are proficient with shell commands. Instead of complex abstractions, you can create a simple AGENTS.md file with examples of the commands you want it to use. This gives the agent a clear, discoverable set of capabilities.
Issue Scoped Credentials: If the agent needs access to services, provide it with tightly scoped credentials. For example, use API keys for a staging environment or set low budget limits on accounts that can incur costs.

When to Use Agentic Loops

This pattern is not a universal solution. It is most effective for problems that have clear success criteria and are likely to require significant trial and error. Good use cases include:

Debugging: Investigating why a test is failing.
Performance Optimisation: Experimenting with database indexes to improve query speed.
Dependency Upgrades: Updating packages and fixing minor breaking changes, provided you have a solid test suite.

The key takeaway is that the power of AI agents is unlocked not just by the model itself, but by the secure and well-designed environment you create for them. Using disposable sandboxes like GitHub Codespaces is an effective strategy for mitigating risk while still allowing the agent the freedom it needs to solve complex problems.

The AI Coding Trap

2025-09-29T00:00:00Z

Chris Loy’s article The AI coding trap provides a structured framework for AI-assisted development. His core insight is that we should treat AI coding agents as exceptionally fast but limited junior engineers, applying traditional software engineering practices to avoid technical debt.

The fundamental shift

Traditional development involves extensive problem-solving before implementation. With AI, this reverses - we generate code immediately but then face the harder task of understanding what was produced. Loy calls this “the AI coding trap.”

AI as junior engineers

This perspective helps explain why productivity gains are often modest rather than revolutionary:

Aspect	Junior Engineer	AI Coding Agent
Velocity	Improves with experience	Consistently high
Learning	Grows through experience	Limited to context engineering
Domain Knowledge	Develops over time	None without explicit context

Applying structured practices

What I find valuable about Loy’s approach is how it systematises AI collaboration using proven software development practices:

Specification first: Use AI to explore requirements before implementation
Documentation focus: Generate and review documentation upfront
Modular design: Scaffold architectures to control context scope
Test-driven development: Create tests before writing code
Coding standards: Apply house styles through careful prompting

This structured approach transforms AI from a code generator into a collaborative tool. The practices that work with human teams—clear specifications, documentation, and standards—prove equally essential when working with AI.

“By understanding that delivering software is so much more than just writing code, we can avoid the AI coding trap and instead hugely amplify our ability to deliver working, scalable software.”

The framework acknowledges that while AI handles implementation at unprecedented speed, human oversight remains essential for design, architecture, and maintaining system coherence.

Questions to Ask Before Finishing a Side Project

2025-09-28T00:00:00Z

As someone balancing screen-based work with hands-on hobbies like woodworking and family life with three children, I often face the dilemma of when to continue with a side project versus when to let it go. Cassidy Williams, a software engineer based in Chicago, offers a concise framework for navigating this common challenge in her article Questions to ask when you think need to finish something.

Williams identifies six key questions for conducting a “mental audit” of ongoing projects. These help distinguish between genuine commitment and obligation-driven persistence:

Does this still align with my current goals?
Reassess whether the project serves your present priorities, not past aspirations.
Would I start this again without prior investment?
Imagine beginning fresh—would you choose this project today?
Do I want this, or am I proving I can finish it?
Separate intrinsic motivation from completion pressure.
What happens if I let this go?
Acknowledge potential consequences without emotional bias.
Am I meeting my expectations or others’?
Identify whether external validation drives your effort.
What would I pursue instead?
Clarify opportunities created by releasing the project.

Doing a little “mental audit” around projects have helped me ship better when I realize some projects I pursue aren’t actually worth it to me.

This approach resonates with my experience of alternating between laptop work and tangible activities like woodworking. The physical immediacy of sawing wood or sanding surfaces provides a stark contrast to digital work, making me more intentional about where I invest limited time. Similarly, parenting three children teaches me to prioritise what truly matters—often revealing that “finishing” isn’t the goal, but rather aligning effort with life’s context.

Stanford's CS146S: The Modern Software Developer

2025-09-26T00:00:00Z

I came across the Stanford’s CS146S course, The Modern Software Developer, which started this week. Taught by Mihail Eric, the course aims to equip students with the skills to master modern AI development tools and workflows. The curriculum is designed to explore how AI-assisted coding, automated testing, and emerging trends can significantly boost developer productivity: very interesting perspective for a software engineering course!

The introductory email from the course instructor outlined several key takeaways that frame the entire course. These principles move beyond simply using AI tools and focus on the evolving role of the developer.

Core Principles of Modern Development

The course emphasises a shift in mindset and practice for software engineers.

Human-agent engineering, not vibe coding. Pure vibe coding is still not a viable way to build production software. Instead, every developer must learn to become a manager of an eager set of AI agent interns.

This is a spot on reframing. The developer’s role transitions from a sole coder to a manager who provides high-level direction, system architecture, and crucial business context to AI agents.

LLMs are only as good as you are. If a developer says AI “doesn’t work on their codebase”, it typically means even a human entering their codebase for the first time would be confused. The key is to set your agents up for success with clear context and well-structured code.

This principle places the responsibility for effective AI collaboration squarely on the developer’s shoulders. It suggests that the quality of the output is directly correlated with the clarity of the input and the health of the underlying system.

Course Structure

The course schedule provides a comprehensive look at the topics that are essential for the modern developer. The ten-week curriculum covers:

Week	Focus Area	Key Topics
1-2	AI Fundamentals	LLM mechanics, prompt engineering, agent architecture (MCP)
3-5	Development Environment	AI IDEs, terminal automation, context management
6-7	Quality & Security	AI testing, vulnerability detection, debugging, code review
8-9	Deployment & Operations	Automated UI building, monitoring, incident response
10	Future Outlook	The evolving role of the software engineer

The inclusion of guest speakers from companies like Cognition (Russell Kaplan), Warp (Zach Lloyd), and a16z (Martin Casado) indicates a strong connection to current industry practices and future trends.

This course appears to be a valuable resource for understanding the practical application of AI in software development. I plan to follow the released materials to see how these principles are put into practice.

On Leading a Room Full of Experts

2025-09-25T00:00:00Z

In technical environments, leadership is often misinterpret as being the most senior expert in the room. In his article, How to Lead in a Room Full of Experts, Ibrahim Diallo argues that a leader’s value in a team of specialists is not in having the deepest knowledge, but in providing connection and context.

Diallo reframes the role of a technical leader around a few core responsibilities.

Leadership in technical environments isn’t about being the smartest person in the room. It’s about being the most effective translator.

The Leader as Translator

A leader’s primary function is to bridge communication gaps between different groups of experts and stakeholders. This involves translating the same technical decision into different “languages” for different audiences:

For Developers: Explaining the technical dependencies and risks (e.g., “cascading failures”).
For Product Teams: Framing the issue in terms of user impact and timeline (e.g., “prevent potential outages”).
For Executives: Highlighting the strategic trade-off (e.g., “prioritizing system reliability over feature velocity”).

By acting as a translator, the leader ensures that each group understands the implications of a decision from their own perspective, without needing to become experts in other domains.

The Leader as Goal-Keeper

When a room is full of experts, discussions can easily dive deep into technical specifics that, while interesting, may not serve the primary objective. The leader’s job is to constantly steer the conversation back to the actual problem to be solved.

Diallo notes that he has sat through many meetings where engineers debated technical minutiae while the core problem remained poorly defined. A leader’s role is to ask clarifying questions that connect the discussion back to the goal, ensuring the team is solving the right problem, not just an interesting one.

The Leader as Facilitator

In an expert-driven environment, pretending to have all the answers erodes trust. Diallo argues that saying “I don’t know, but let’s figure it out” is a powerful tool. It creates psychological safety, encourages intellectual humility, and empowers specialists to contribute their unique knowledge.

The leader’s role is not to have the best answer, but to:

Frame decisions in terms of trade-offs, timelines, and user impact.
Create space for the right experts to contribute at the right time.
Clearly articulate the “why” behind a decision to maintain alignment and trust.

Your role isn’t to have all the answers. It’s to make sure the right questions get asked, the right people get heard, and the right decisions get made for the right reasons.

Personal Takeaways

This model of leadership applies to both people and technical leadership. Two points in particular stand out.

First, the idea of “remembering the goal” is a daily challenge. Many discussions become sidetracked by competing priorities, a desire to impress, or the introduction of a novel idea that is unrelated to the objective. A leader who can consistently help a group maintain focus on the actual goal provides a significant service to the team and the organisation.

Second, the emphasis on defining the problem clearly connects to the challenge of understanding the underlying needs of stakeholders. Being able to effectively listen, identify the core problem beneath the symptoms, and then codify it for the team is a critical and difficult skill. It is the foundation for ensuring that the experts’ work is directed at a valuable outcome.

Scaling Python Data Science: Lessons from Coiled

2025-09-24T00:00:00Z

Moving data science projects from a local laptop to a scalable production environment is a persistent challenge. The path is often filled with friction between the need for rapid experimentation and the demand for robust, reproducible systems.

The Talk Python podcast recently featured Matthew Rocklin and Nat Tabris from Coiled to discuss this problem. They share lessons learned from building their platform, which is designed to help Python data scientists scale their work in the cloud with minimal DevOps overhead.

The Core Philosophy: Making Cloud Scale Feel Like Play

The central argument presented by Matthew and Nat is that using the cloud for data science should be an empowering experience, not a chore. Their goal is to abstract away the complexities of cloud infrastructure so that scaling a workload feels as simple as importing a library.

The cloud is a really fun tool to use once you get past all the pain… Suddenly the cloud is like play.

To achieve this, Coiled allows users to provision large, temporary clusters of virtual machines directly from a familiar environment like a Jupyter notebook. This approach is optimised for the bursty, short-lived nature of many data science tasks, such as model training or large-scale data processing, where a cluster might be needed for an hour and then shut down.

The Debate: Runtime Replication vs. Docker

One of the most interesting points of the discussion is their stance on environment replication. For many, Docker is the default tool for creating consistent, portable environments. However, the Coiled team argues that it introduces significant friction into the data science development loop.

If you put in a Docker build, Docker push cycle into the data science work cycle, it just gums everything up.

The argument is that the time spent building and pushing a Docker image for every small code change stifles rapid iteration. Instead, Coiled uses a runtime replication approach. It scans the developer’s local Python environment and automatically synchronises packages and files to the cloud machines. This method is designed to reduce setup time from several minutes to under a minute, keeping the developer in a state of flow.

My Perspective on Standardisation and Speed

The podcast’s position on Docker is valid for workflows that demand high-speed iteration. However, the ideal approach depends heavily on the nature and cadence of the work.

In our company, we do not typically deploy new software versions multiple times per day. A release cycle of once every one or two weeks is more common. In this context, the few extra minutes required for a Docker build is not a critical bottleneck. The benefits we gain from standardisation often outweigh this minor delay.

We value and benefit from using templates for our code and deployment pipelines. Using Docker as a foundation for these templates helps us maintain consistency and develop faster across projects. The formal structure it provides is an asset for long-term maintainability.

Ultimately, it is a trade-off. The Coiled approach optimises for the speed of individual experimentation, while a Docker-based workflow prioritises the formal standardisation of the production environment.

Key Takeaways

Optimise for Your Workflow: The tension between rapid iteration and stability in production is central to MLOps. Tools like Coiled are optimised for the former, making them suitable for exploratory, bursty workloads.
The Cost of Iteration: The overhead of your development cycle matters. For frequent, small changes, a 5-10 minute Docker build can be a significant drag on productivity.
Standardisation Has Value: For teams with a more structured and less frequent release cadence, the consistency and reproducibility of a Docker-based workflow can provide more long-term value than pure speed of iteration.
Context is King: The right tool depends entirely on your team’s specific needs, deployment frequency, and tolerance for process overhead.

Timeless Leadership Principles from Jocko Podcast 251

2025-09-23T00:00:00Z

I frequently listen to the Jocko Podcast. While I have no military background, I recognise that military history offers a rich source of knowledge on leadership and effectiveness. The concepts discussed can be applied not just in conflict, but also in business—a principle the hosts, Jocko Willink and Leif Babin, have built their company on.^[1] They are effective at explaining these ideas, using real examples from their combat experience to ground abstract principles in reality.

A clear example of this is Jocko Podcast episode 251. In it, Jocko and Leif discuss a rare book that heavily influenced their philosophy: Guidelines for the Leader and Commander by General Bruce C. Clarke. This book was also a key source for Colonel David Hackworth, an important influence on Jocko’s thinking. The episode traces the lineage of their core ideas back to this foundational text.

Key Principles from ‘Guidelines for the Leader and Commander’

The podcast discussion centres on the timeless nature of the book’s advice. The principles, written decades ago, are the same ones Jocko and Leif now teach.

The Burden of Command: Leadership requires immense personal sacrifice and a willingness to devote yourself entirely to your team and mission. It means accepting total responsibility for the failures of your subordinates, a core tenet of Extreme Ownership.
What a Team Expects from a Leader: General Clarke outlines several non-negotiable expectations. A leader must be honest, just, and fair. They must be loyal to both superiors and subordinates. They must lead by example, share information by explaining the “why,” and show genuine interest in their people’s well-being.
Setting and Enforcing Standards: The leader is directly responsible for the standards of the organisation. This is captured in two of the book’s most important axioms, which Jocko had sought for years. The first connects preparation to performance, and the second highlights the necessity of inspection.
An organisation does well only those things the boss checks.
Morale is Built on Competence: High morale is not achieved through coddling. It is the direct result of confidence built through hard training, competence, and effective management. A team that is well-trained and well-led develops pride and resilience.
Constant Vigilance: A core theme is that a unit must be ready for anything, 24/7. General Clarke warns against the complacency that led to surprise attacks in the past. This principle of constant readiness is a cornerstone of the Jocko and Leif mindset.

The ‘Normal Face’ Principle: Emotional Regulation in Leadership

A powerful, practical tool discussed in the episode is what Jocko and Leif call “Normal Face.” It is the practiced ability to control your external emotional response to project calmness and focus, especially when faced with bad news or chaos. It is not about being emotionless, but about emotional discipline.

When a subordinate reports a significant mistake, a leader’s calm, measured response is often more effective than an angry outburst. It keeps the focus on solving the problem rather than assigning blame. As Leif explains, Jocko’s composed reaction to a serious error provided a sense of comfort and made the situation feel manageable.

Jocko: “…if I can’t control my emotions because you lost a piece of gear… like how am I going to react in the future?.. The punishment for me is knowing like it’s constructive because I know like I gotta get this fixed we can’t let this happen again this is a massive issue… as opposed to me just saddling you with unbearable guilt for letting me down.”
Leif: “It’s actually the worst because if you were like ‘dude are you kidding me?’… I would be looking… it would be desirable when Jocko was like ‘Roger’ and just looks back at you… doesn’t give you… a big sense of comfort like okay at least this is manageable?”

By controlling your reaction, you own the environment and prevent panic from spreading. This principle of emotional regulation is not just for high-stakes environments. The hosts suggest that everyday frustrations, such as managing family life, can be training opportunities. Treating each moment as a chance to practice a measured response is a practical way to develop this skill for constant growth.

Jocko Willink and Leif Babin are retired U.S. Navy SEAL officers who served together in the Battle of Ramadi. They are the co-authors of ‘Extreme Ownership’ and ‘The Dichotomy of Leadership’ and co-founders of the leadership consultancy Echelon Front. ↩︎

Understanding the Five Doors of Influence

2025-09-22T00:00:00Z

The more senior you become in an organisation, the more your success depends on your ability to influence others. Your ability to advance good work and build effective relationships hinges on this skill. There is a delicate balance between influencing and dictating. While seniority may grant formal authority, true progress comes from fostering intrinsic motivation in your team. Forcing people to act is far less effective than inviting them to contribute to a shared goal.

Of course, a balance is necessary. Some tasks are non-negotiable. When direct influence is not enough, you must rely on structural mechanisms. For example architectural governance boards, contracts and complience in the TOGAF framework. This allowed enterprise architecture to align teams with the company’s strategic goals, providing a formal channel for influence where informal methods might fail.

In his article, “How can I influence others without manipulating them?”, executive coach Andi Roberts provides a useful model for thinking about interpersonal influence. He frames it not as manipulation, but as an invitation.

Influence can be understood as an invitation. It is the art of meeting people where they are, of entering their world with respect, and of opening a door that they might choose to walk through with us.

Andi proposes five “doors” of influence, which are different styles of persuasion. Most of us have a default style, which can become a blind spot. We mistake a different communication preference for resistance. The key is to recognise which door the other person is standing at and adapt our approach accordingly.

Here is a summary of the five doors:

Door	Description	Best For	Risk of Overuse
Rationalising	Persuading with facts, evidence, and logical analysis.	Appealing to people who value data, structure, and clarity.	Becoming cold, detached, and overly complex.
Asserting	Persuading with confidence, conviction, and direct statements.	Engaging with people who value decisiveness and a clear position.	Appearing domineering and silencing dialogue.
Negotiating	Persuading by finding common ground and seeking mutual benefit.	Working with people who are pragmatic and prefer collaboration.	Seeming weak or making unnecessary concessions.
Inspiring	Persuading with stories, vision, and appeals to purpose.	Motivating people who respond to meaning and possibility.	Feeling idealistic and disconnected from reality.
Bridging	Persuading through relationships, social proof, and third-party validation.	Influencing people who value trust, rapport, and peer endorsement.	Becoming dependent on others for validation.

The central challenge is that any of these styles, when used exclusively or inappropriately, ceases to be a tool for connection and becomes a barrier.

The paradox is that any of them, when overused, becomes a wall. Logic turns cold. Conviction turns harsh. Compromise turns weak. Vision turns empty. Relationship turns dependent.

This framework is a practical guide for senior leaders. It reminds us to be conscious of our own default style and to listen for the preferences of others. By choosing the right door, or variating between doors, we can make our invitations to collaborate more effective. And when that is not enough, we can turn to structured governance to ensure alignment.

From Code Generation to AI-Native: Insights from the Front Lines

2025-09-19T00:00:00Z

Just yesterday, I analysed the AWS guide on “vibe coding,” noting how it formalises AI-assisted development for the enterprise. It represents a shift from individual craft to scalable, process-driven systems. A recent panel discussion with experts from Anthropic, Trae, and Replit provides a complementary view, offering a look at the best practices emerging from the very frontier of this technology.

This discussion moves the conversation from AI-assisted coding to what can be called “AI-native” development. It reinforces the idea that the developer’s role is fundamentally changing, and it provides practical strategies that bridge the gap between solo experimentation and enterprise-grade systems.

The Core Shift: AI as a Collaborator

The panellists—Paxton Maeder-York from Anthropic, Chao Peng from Trae, and Michele Catasta from Replit—unanimously framed AI not as a tool, but as a collaborative partner. This is more than a semantic distinction; it underpins a new development paradigm.

Paxton Maeder-York (Anthropic): “I typically say I collaborated with Claude… Claude and I are best friends and we do a lot of work together. We’re very much encouraged at Anthropic to try to automate our entire job away with Claude.”

This perspective aligns with the principles I have explored previously: the human acts as the architect, directing a powerful collaborator. The panel’s insights show how this collaboration works in practice.

Battle-Tested Best Practices

The discussion yielded several concrete strategies that are being used right now.

Strategic Context Management: Even with large context windows, managing what the AI knows is critical. Paxton shared a practical tip: strategically “compacting” a conversation’s history into a summary file (like claude.md) to maintain essential context. This is a more dynamic, developer-led version of the formal requirement documents proposed in the AWS guide. He also offered a simple but effective prompt suffix: “don’t break anything and don’t change anything else.”
Multi-Agent Orchestration: The concept of using specialised sub-agents, which I have noted from developers like Zach Wills, is now a key strategy inside Anthropic. Paxton confirmed that their internal experts run multiple AI agents in parallel, each working on a different part of the codebase. This is the practical application of turning the developer into an orchestrator of an AI team.
The Resurgence of Test-Driven Development (TDD): The panel offered a powerful solution to the problem of AI-generated code quality. Both the AWS guide and my own experience suggest that AI assistants are poor at designing meaningful tests. Chao Peng argued for a TDD revival: the human defines the tests, and the AI’s job is to write code that passes them. This creates a clear feedback loop and makes debugging far more efficient for both the human and the AI.

The Final 20%: Enterprise Readiness

The panel was realistic about the challenges of deploying AI-built applications. Michele Catasta pointed out the “foot guns” that coding agents expose and the complexities beyond pure code generation.

Michele Catasta (Replit): “There are many other things that are important: how do you deploy? Data governance, security and so forth?”

This directly explains why the enterprise-focused approach seen in the AWS guide is so process-heavy. The formalisms and security guardrails are not bureaucracy; they are the necessary systems to manage the final, difficult 20% of getting a product into production reliably and securely.

The Engineer’s Evolving Role: From Coder to Specifier

Ultimately, the panel confirmed a conclusion I have been moving toward: the core work of a senior engineer is shifting from implementation to specification.

Michele Catasta (Replit): “I think it’s already the case. Like the more you grow as an engineer in your career, the more you write specs rather than code. That’s where the important insights are.”

This is the end-game of the “human as architect” model. Our primary value is no longer in writing lines of code, but in defining the problem with such precision that an AI collaborator can execute the solution. The innovator’s agile mindset and the enterprise’s formal processes are both methods for achieving this clarity of specification. The most effective developers will be those who master this skill of architectural definition, regardless of the tools they use.

Revisiting Vibe Coding: An Analysis of AWS's Practical Guide

2025-09-18T00:00:00Z

The practice of using large language models for software development is moving from individual experimentation to a more formalised discipline. I have previously written about structuring this process, distinguishing between chaotic “vibe coding” and effective, human-led agentic workflows. Now, Amazon Web Services (AWS) has published its own guide, Vibe Coding Tips and Tricks, offering a corporate, tool-centric perspective on the same challenge.

This new information provides a valuable opportunity to see how these developer-led strategies are being adapted for enterprise environments. The AWS guide reinforces core principles but also introduces new considerations that show the practice is maturing.

The AWS Framework for Vibe Coding

The AWS guide frames “vibe coding” as a structured process heavily reliant on a specific ecosystem of tools, primarily clients and Model Context Protocol (MCP) servers. While it acknowledges the developer’s central role, its focus is less on the philosophy of interaction and more on the operational mechanics.

Key principles from the guide include:

Human Responsibility is Non-Negotiable: The guide is explicit that the developer owns the architecture, vision, and quality. The AI is a tool, not a replacement for critical thinking.
Never blindly trust code generated by AI assistants. Always:
- Thoroughly review and understand the generated code
- Verify all dependencies
- Perform necessary security checks
- Test the code in a controlled environment
A Tool-Centric Workflow: Significant emphasis is placed on selecting the right AI client (e.g., Amazon Q, Cline) based on compliance and security, and leveraging specific features like “Plan mode” before generating code. It advocates for a multi-client strategy, using different tools for different tasks.
Process Before Prompting: The guide formalises the preparation phase. It mandates defining requirements, design guidelines, and constraints in markdown files before coding begins, ensuring the AI has clear context.
Explicit Rules and Configuration: It suggests creating documented rules for the AI, such as file length limits or documentation standards, to enforce consistency.

Evolving the Practice: From Solo Craft to Enterprise Systems

Compared to my earlier post “A Practical Guide to Coding with LLMs”, the AWS guide shows how these concepts evolve when applied at an enterprise scale. It bridges the gap between an individual’s cognitive workflow and a team’s need for a shared, scalable system.

From Mindset to System: My previous analysis focused on the mindset of the developer acting as an architect. This is ideal for the solo innovator. The AWS guide provides the engineering system to support that mindset across a team, emphasising approved tools and security compliance. It is the natural next step for integrating this practice into a collaborative environment.
From Agile Prep to Formal Process: The “first swing” of architecture I advocated for is an agile method well-suited for an individual. AWS formalises this into creating explicit requirement documents. For an enterprise, this is not bureaucracy; it is a necessary mechanism for team alignment, creating a persistent source of truth that enables asynchronous work and maintains quality at scale.
From Prompting Limits to Engineering Challenges: The limitations—such as performance degradation from long conversations or the superficiality of AI-generated tests—are signs of maturity. We are moving beyond simple prompt engineering and are now facing the next frontier of engineering problems: how to make AI-assisted development reliable, scalable, and maintainable. These are the challenges we expect to see when a practice becomes more mature.

Practical Implications and Learnings

The AWS guide provides a blueprint for how AI-assisted development can be integrated into a corporate environment.

Standardisation is Coming: The emphasis on approved clients, security policies, and documented processes suggests that organisations are moving to standardise these workflows, moving them out of the realm of personal productivity hacks.
Testing Remains a Human Domain: The guide’s explicit warning about the poor quality of AI-generated tests is a critical takeaway. It confirms that while AIs can write functional code, they lack the deep understanding of business logic and edge cases required for creating meaningful validation. The responsibility for test case design remains firmly with the developer.
Context Management is an Engineering Problem: The performance degradation mentioned in the guide is a practical manifestation of context window limitations. This implies that managing conversation history and tool configuration is not just a prompting issue but an engineering challenge that requires deliberate process management.

The Path Forward: A Combined Playbook

The individual developer, as explored in my earlier posts, pioneers the creative techniques and architectural mindset. The enterprise then codifies these techniques into robust, scalable, and secure processes.

The path forward for every developer is to build a hybrid approach: maintain the architectural mindset of a solo innovator while adopting the discipline of structured processes and tooling where appropriate. We are collectively writing the playbook for this new phase of software development, learning from both experimentation and enterprise-level implementation. The goal is a future where human creativity directs AI execution with clarity and purpose.

You Should Delete Tests

2025-09-16T00:00:00Z

I use automated tests extensively when working on Python code. I have often found it a challenge to strike the right balance: creating tests with enough detail to confirm functionality without making them so brittle that a minor code change requires rewriting the entire suite. This tension is why I found the perspective in André Arko’s article, You should delete tests, to be a practical reminder about the purpose of a test suite.

André argues that the fundamental reason for writing automated tests is to increase human confidence that a change will succeed. We run tests to be confident when we open a pull request, merge to main, and deploy to production.

The core purpose of a test suite is to increase confidence. Therefore, a test should be removed any time it begins to decrease that confidence.

If we accept this premise, then the decision to delete a test becomes clear. André identifies several scenarios where tests actively harm confidence and should be removed.

Flaky Tests: These are tests that fail intermittently and without a clear reason, like after fixing a typo. They train developers to ignore failures, which is a dangerous habit. As André puts it: "Oh, it’s failing because of that flaky test, it’s actually fine” is something I have heard more times than I can count, even when the code is broken and the tests are really failing. A test that encourages this behaviour is worse than no test at all.
High-Maintenance Tests: When a one-line code change requires updating 150 tests, the test suite is creating friction instead of confidence. This often indicates that the tests are too tightly coupled to the implementation details rather than the behaviour. Such a high volume of failures for a small change does not make a developer more confident; it just creates unnecessary work.
Unrun Tests: Sometimes, to speed up a slow test suite, teams start skipping tests that “always pass”. A test that is never run provides a false sense of security, which is another form of flakiness. It harms confidence by creating a mismatch between perceived and actual test coverage.
Irrelevant Tests: When business requirements change, the tests for the old behaviour become obsolete. Spending time updating these tests to align with new logic is wasted effort. The correct action is to delete the old tests and write new ones that directly validate the new behaviour.

The main takeaway is that a test suite is a living tool, not a sacred artifact. Maintaining it requires not just addition but also subtraction. Unproductive overhead is a significant cost, and curating a test suite by deleting tests that no longer build confidence is a necessary and healthy part of software development.

A Practical Guide to Coding with LLMs: Dos and Don'ts

2025-09-15T00:00:00Z

The way we build software is changing. Instead of writing code line-by-line, developers are increasingly orchestrating AI assistants to generate, refactor, and even debug entire features. As I have explored in previous posts, this shift requires a deliberate and structured approach to be effective.

Drawing from the experiences of developers like Matt Webb, Zach Wills, and Taylor, we can identify a set of principles for working with tools like Claude Code. These principles distinguish between productive, structured collaboration and chaotic, unproductive “vibe coding”.

The Two Faces of “Vibe Coding”

According to Matt Webb’s reflections in What I think about when I think about Claude Code, working with an AI agent introduces a new, slower rhythm to development. It involves a loop of composing a thoughtful prompt and then waiting. This contemplative pace has an unexpected benefit: it helps avoid what Linda Stone called “email apnea,” a tendency to hold one’s breath and induce stress during focused screen work.^[1]

With Claude Code, I don’t have that metronome shortening my breath. I do not subject myself to “code apnea.” So it becomes calm, contemplative.

This calm state, however, is only possible when the interaction is structured correctly. If problems are too large or vague, you fall into the trap of “vibe coding”—a process that produces code which may function but is often tangled and impossible for humans to edit.

However, as I discussed in “The last hurrah of human coding”, this term has another meaning. For senior engineers, “vibe coding” can be a superpower, but only when it happens within a highly structured environment. The key is to give the agent “large, but not too large, extremely well defined problems.” As I noted previously, the path to successfully using these tools is through structure, not chaos.

A Framework for Effective AI Collaboration

To move beyond the vibe and toward structured development, we need a systematic approach. The central principle, articulated in a detailed case study by Taylor on building a tool called diggit.dev, is that the human must be the architect. LLMs are excellent at executing well-defined tasks, but they are not designers.

Taylor proposes a phased, human-led workflow:

Viability: Get the most basic version of the application running, even if it is broken.
Observability: Make the application “loud” by adding comprehensive error handling and progress reporting. This is critical for debugging what the LLM produces.
Features: Add core functionality through a series of small, focused tasks.
Styling: Refine the user interface.

This process relies on giving the LLM atomic prompts for single, clear goals. Before writing any prompts, the human does the heavy lifting of creating plaintext mockups, defining the data model, and preparing copious notes. This “first swing” puts the LLM in a position to succeed.

Scaling Up with an Agentic Workflow

For more complex projects, you can extend this structured approach by using multiple, specialist AI agents. In his post on using sub-agents to parallelize development, Zach Wills outlines a sophisticated workflow built on three principles:

Parallel Execution: Assign independent tasks (e.g., backend API, frontend component, QA tests) to different specialist agents to run concurrently.
Sequential Handoffs: Create an automated assembly line where the output of one agent (e.g., a product-manager agent defining a feature) becomes the input for the next (e.g., an engineer agent implementing it).
Context Isolation: Give each specialist agent its own dedicated context window. This prevents quality degradation, as each agent can focus entirely on its task without losing crucial details.

This method transforms the developer’s role into that of an orchestrator, managing a team of AI agents to build software at a much faster pace. However, this powerful approach is not without its practical trade-offs, particularly regarding cost. As usage is typically priced per token—for both the input you provide and the output you receive—these advanced workflows can become expensive. Chaining multiple agents, especially in iterative loops, will increase your token usage significantly. This creates a direct trade-off: you gain development velocity and higher output at the expense of higher operational costs. Managing these “token economics” becomes a crucial part of orchestrating AI workflows at scale.

Summary of Dos and Don’ts

To make these concepts practical, here is a summary of best practices for coding with LLMs.

Do	Don’t
Be the architect. Spend time on high-level design, data models, and planning before prompting.	Outsource architectural decisions. Do not expect the LLM to design a coherent system from a vague idea.
Use atomic, well-defined prompts. Give the agent one clear, focused task at a time.	Engage in chaotic “vibe coding.” Avoid giving prompts that are too large or ill-defined, as this leads to write-only code.
Codify conventions in a “rulebook”. Use files like `.cursor/rules` to provide persistent context and constraints.	Let the AI touch “sacred boundaries.” Forbid the AI from modifying tests, database migrations, or security-critical code.
Make it observable early. Add logging and error handling so you can see what the agent is doing.	Run the agent without supervision. Avoid using modes like `--dangerously-skip-permissions`. Your role is approval and course correction.
Choose LLM-friendly tools. Select languages and frameworks with clear syntax and descriptive errors (e.g., Elm).	Ignore the agent’s limitations and costs. Be aware of context windows, non-determinism, and the financial cost of token usage (both input and output).

Conclusion

Effectively using AI in development is less about mastering a specific tool and more about adopting a new mindset. The developer’s primary skill is shifting from direct implementation to system design and process orchestration. As I concluded in a previous post, this changes the very nature of senior engineering.

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

By providing structure, clarity, and thoughtful direction, you can transform an LLM from a simple autocomplete tool into a powerful collaborator.

As described by Matt Webb, Linda Stone observed that 80% of people experienced compromised breathing while working on email, a phenomenon she termed “email apnea.” This shallow breathing or breath-holding contributes to stress. ↩︎

Is AI the Next Microprocessor or the Next Shipping Container?

2025-09-14T00:00:00Z

For anyone investing in or betting on the next big thing, the central question is where generative AI sits in the history of technological revolutions. Will it create a new wave of wealth for startups and their backers, or will its value be captured elsewhere? In his article, “AI Will Not Make You Rich,” Jerry Neumann presents a compelling framework for this analysis, arguing that AI more closely resembles the economic impact of shipping containerisation than the microprocessor.

This framework, based on the work of economist Carlota Perez, helps analyse how technological revolutions create and distribute value. It suggests that where we are in a broader technological cycle is the primary determinant of who wins.

The Four Phases of a Technological Wave

Carlota identifies four phases in every major technological revolution. These cycles describe a predictable human and financial response to new technology.

Irruption: The initial period of experimentation and uncertainty, where a new technology emerges. Investment is risky and driven by true believers.
Frenzy: A period of speculative mania where capital floods into the new paradigm, leading to a bubble as hype outpaces reality.
Synergy: After the bubble pops, a “golden age” begins. The technology is mature enough for practical application, and companies focus on building real businesses.
Maturity: The technology becomes fully integrated. Growth slows, markets consolidate, and innovation becomes incremental, focused on extending the current paradigm.

Two Models of Innovation

Jerry contrasts two historical innovations to illustrate how these phases play out. The key difference is the element of surprise.

It’s the element of surprise that should strike us most forcefully when we compare the early days of the computer revolution to today. No one took note of personal computers in the 1970s. In 2025, AI is all we seem to talk about.

This lack of surprise shapes the entire competitive landscape.

Feature	The Microprocessor (Irruption Phase)	Shipping Containerisation (Maturity Phase)
Initial Perception	A niche solution; its potential was a surprise.	The benefits were obvious to everyone from the start.
Competition	Incumbents were slow to react, creating a moat for startups.	Incumbents and competitors reacted immediately, leading to intense competition.
Innovation Style	Permissionless and distributed tinkering by enthusiasts.	Centralised and capital-intensive; required huge investment.
Value Capture	A new class of entrepreneurs and investors became wealthy.	Value flowed to customers and a few early pioneers.

Containerisation arrived late in its technological wave. Its benefits were so clear that it sparked an immediate competitive free-for-all, squeezing profits. The real winners were downstream businesses that used cheap, reliable logistics to reinvent their own industries.

The business ended up being dominated primarily by the previous incumbents, and the margins went to the companies shipping goods, not the ones they shipped through.

My Analysis: AI Is Not a Monolith

Jerry’s argument that AI is a maturity-phase innovation of the ICT wave is convincing. It is an extension of a 60-year quest for machine intelligence, built on existing infrastructure. Every major company has an AI strategy.

To understand where value might accrue, we must break down the AI stack:

Foundation Models: These are the “container ships” of our era. They are enormously expensive to build and operate, requiring vast capital for chips and data centres. This part of the market fits the containerisation analogy perfectly. Competition is fierce among the large, well-funded incumbents behind models like OpenAI’s GPT series, Google’s Gemini, and Anthropic’s Claude.
The Commoditisation Engine: The containerisation analogy is strengthened by the rise of highly efficient, semi-open-source models, particularly from Chinese companies like Alibaba (Qwen) and others. These models are often cheaper to run and focus on software optimisation, triggering price wars and accelerating the commoditisation of model performance. This directly mirrors the rate wars in container shipping that squeezed profits and suggests high margins will be difficult to sustain at the model layer.
AI-Native Applications: These are companies building products directly on top of foundation models. As Jerry argues, they risk being squeezed by the model providers through pricing or vertical integration. If an application becomes successful, the underlying model provider has every incentive to capture that value by raising prices or launching a competing feature.
AI-Enabled Businesses (Downstream): This is where the “IKEA and Walmart” opportunities lie. These are not tech companies, but businesses in sectors like law, finance, and healthcare that use AI to fundamentally reduce costs and improve services. The value is not in building the AI but in using it to create a new business model. A firm that uses AI to offer legal services at a fraction of the traditional cost is a modern equivalent of IKEA using containerisation to sell flat-pack furniture globally.

The lesson from Jerry’s analysis is clear: the most durable fortunes will likely be made not by building the next model, but by being the first to figure out how to use it to transform an old industry.^[1]

The main wildcard in this analysis is the open-source movement. If cheap, powerful, and truly open models become widely available, they could enable the kind of permissionless tinkering that characterised the microprocessor era. This could potentially trigger a new “Irruption” phase, but for now, the market is dominated by the capital-intensive, centralised approach. ↩︎

Working with AI Wizards and the Need for Explainability

2025-09-13T00:00:00Z

In a recent post, Ethan Mollick describes a fundamental shift in how we interact with AI. He argues we are moving away from a “co-intelligence” model, where we act as collaborators guiding an AI intern, towards working with a “wizard.” In this new model, we provide a vague request and receive a sophisticated, often impressive, output with little to no insight into the process.

Ethan illustrates this with several powerful examples:

NotebookLM: Generated a coherent video summary of his book and articles, but offered no explanation for how it selected its key points or structured the narrative.
GPT-5 Pro: Analysed his academic paper, ran its own code to verify results, and found a subtle error that had gone unnoticed for years. The output was remarkable, but the method was a complete black box.
Claude 4.1 Opus: Transformed a multi-tab Excel spreadsheet for a new business case, preserving the original lesson’s goal. It reported its steps, but these were summaries, not a verifiable log of its actions.

This leads to what Ethan calls the “wizard problem.” The results are good, sometimes exceptionally so, but we become a passive audience, unable to verify the work without significant effort.

The paradox of working with AI wizards is that competence and opacity rise together. We need these tools most for the tasks where we’re least able to verify them.

This observation is accurate. Interacting with these advanced models can feel like outsourcing our thinking, which might make us lazy. But the more important question is whether this opacity is an acceptable trade-off. For casual tasks, perhaps. For professional and scientific work, it is a significant barrier.

In scientific research, the process is as important as the result. If an AI wizard finds a novel insight in a dataset, its discovery is of limited value if it cannot explain the steps it took to get there. We need to understand the intermediate steps to trust the conclusion.

This is not a new problem. I have seen the same requirement in business settings for machine learning models. Stakeholders are rightly hesitant to trust a model’s prediction—whether for credit risk, sales forecasting, or customer churn—unless they can understand the factors and logic driving its conclusion. The same will be true for generative AI.

The way forward is to build explainability into the core of these models.^[1] The ability for an AI to provide a step-by-step, verifiable account of its process will be critical for adoption in high-stakes fields. There is a clear business opportunity for companies that can move beyond the black box and deliver transparent, trustworthy AI systems.

Ethan concludes that we must develop a new literacy for working with wizards: learn when to use them, become better judges of their output, and embrace a “provisional trust.” While this is practical advice for today, the real goal should be to demand more from our tools. We need wizards that are willing to show us their spellbooks.

I have a feeling that some open-source models are already making progress in this area, though I have not verified this completely. Their architecture seems to lend itself better to exposing the internal state and reasoning process. ↩︎

Contrasting Memory Philosophies: Claude's Explicit Tools vs. ChatGPT's Automatic Profiles

2025-09-12T00:00:00Z

Recent posts by Shlok Khemani and Simon Willison highlight a fundamental difference in how leading AI assistants handle memory. Their analyses reveal two distinct product philosophies, with each company building a system that reflects its target audience.

ChatGPT’s memory is automatic and profile-based, designed for seamless consumer use. Claude’s is explicit and tool-based, offering transparency and control for technical users.

Shlok Khemani’s investigation shows that Claude starts every conversation with a blank slate. Memory is only activated when explicitly invoked, at which point it uses visible tools (conversation_search and recent_chats) to search through raw conversation history. In contrast, ChatGPT automatically loads an AI-generated summary of past interactions and user preferences into every new chat, aiming for a “magical” and personalised experience.

This table summarises the core differences in their personal-tier offerings:

Feature	ChatGPT (Implicit Memory)	Claude (Explicit Memory)
Activation	Automatic, always-on	Explicit, invoked by user or model
Data Source	AI-generated summaries & user profiles	Raw conversation history
Transparency	Opaque; context is pre-loaded	High; memory access is a visible tool call
User Control	Limited; memory is managed by the system	High; user decides when to invoke memory
Target User	General consumer	Technical professionals, developers

Simon Willison praises Claude’s approach for its transparency. He notes, “I like to understand as much as possible about what’s going into my context so I can better anticipate how it is likely to affect the model.” The visible tool calls in Claude provide exactly this clarity.

However, Simon also points out a reassuring detail from Shlok’s research on ChatGPT: its memory system only surfaces the user’s messages, not the assistant’s responses. This mitigates the risk of carrying over flawed logic from a previous session into a new chat.

I find Claude’s explicit, tool-based system more aligned with my own workflow. The control it provides over when and how memory is used feels more intuitive. It allows for a “clean slate” by default, which is valuable for focused work, while still making it straightforward to pull in relevant history when needed. This transparency is a significant advantage for managing context and aligns with a preference for privacy.

It is worth noting that this distinction is becoming less rigid. As both authors point out, Anthropic has introduced a new, ChatGPT-like memory feature for its Team and Enterprise accounts. This version creates an editable summary of interactions, offering a hybrid approach that combines automatic context with user oversight.

A Structured Methodology for Disciplined AI Software Development

2025-09-11T00:00:00Z

Collaborating with Large Language Models (LLMs) on software development can be highly effective, but it often introduces problems like architectural drift and context dilution. The Disciplined AI Software Development methodology by Jay Baleine offers a structured approach to mitigate these issues by imposing systematic constraints on the AI-human interaction.

The methodology addresses common issues like code bloat, architectural drift, and context dilution through systematic constraints and validation checkpoints.

The core problem it identifies is that AI systems operate on a simple “Question → Answer” pattern. When given broad, multi-faceted requests, they tend to produce code that lacks structure, contains repetition, and drifts from the intended architecture over time.

The Four Stages of the Methodology

The approach is broken down into four distinct stages, designed to build upon each other with clear validation points.

AI Configuration: The process begins by providing the AI with custom instructions (e.g., AI-PREFERENCES.XML) that establish behavioural constraints. This includes instructing the AI to flag any uncertainty, ensuring it does not “hallucinate” solutions when it lacks sufficient information.
Collaborative Planning: The developer and AI work together to define the project’s scope, components, dependencies, and phases. This structured planning session results in a development plan with clear modular boundaries and measurable checkpoints.
Systematic Implementation: Development proceeds phase by phase, with each request focused on a single, specific component. A key constraint is a strict file size limit (e.g., ≤150 lines) to maintain small context windows, enforce focused implementation, and simplify debugging.
Data-Driven Iteration: A benchmarking suite is built first (Phase 0). Performance data from this suite is fed back to the AI, ensuring that optimisation decisions are based on empirical measurements rather than assumptions.

Architectural Guardrails for AI Collaboration

The principles outlined in this methodology can be viewed as tactical architectural guardrails, similar in spirit to the high-level principles found in frameworks like TOGAF.^[1]

Where TOGAF provides a strategic framework for enterprise architecture, these rules provide a micro-framework for AI code generation. Constraints like the 150-line file limit and single-component implementation are not arbitrary; they enforce modularity and prevent the AI from making sprawling, unmanaged changes. This approach transforms the AI from an unpredictable partner into a disciplined builder that adheres to a pre-defined architectural vision.

The repository includes practical tools to support this workflow, such as example configuration files and a Python script (project_extract.py) for generating structured snapshots of the codebase to share with the AI.

By enforcing a systematic process, the developer’s role shifts from constantly debugging inconsistent output to strategically planning the work and validating the results. It is a practical framework for turning an AI into a more reliable and predictable development partner.

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. ↩︎

The Tension Between Legibility and Efficiency in Software Companies

2025-09-10T00:00:00Z

In his article “Seeing like a software company”, Sean Goedecke applies the ideas of James C. Scott’s book Seeing Like a State to the world of large technology companies. The core concept is “legibility”—the drive by a central authority to make a complex system understandable, measurable, and controllable.

This often creates a fundamental tension. While legibility provides significant benefits for planning and coordination, it frequently comes at the cost of on-the-ground efficiency and resilience. This model helps explain many seemingly counter-productive behaviours I have observed in large organisations.

The Core Idea: Legibility vs. Illegibility

Goedecke summarises Scott’s idea with a simple analogy: 19th-century German scientific forestry. To maximise timber yields, state foresters replaced complex, diverse forests with neat rows of a single, fast-growing tree species.

The Goal (Legibility): The new forest was “legible”. An inspector could easily count the trees and predict the yield. This enabled long-term planning, large trade deals, and reduced graft.
The Reality (Reduced Efficiency): This legible forest was a biological failure. It was vulnerable to a single pest and ultimately produced less wood than the old, “illegible” forest, which had a complex, self-regulating ecosystem.

Even when it became clear that legibility reduced overall productivity, states continued to pursue it because the benefits of control and planning were considered more valuable.

Increasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless.

In software companies, this translates to a distinction between two types of work:

Legible Work: Predictable, estimated, and tracked through systems like Jira and OKRs. It has a clear paper trail and is designed for management oversight.
Illegible Work: The informal, untracked work that is often essential. This includes asking for favours, using unwritten tacit knowledge, and leveraging interpersonal relationships to get things done quickly.

Small companies thrive on illegibility and can be highly efficient. Large companies, however, optimise for legibility to manage complexity and secure large enterprise deals, which require long-term commitments and predictable roadmaps.

The Paradox of Process and the Role of TOGAF

Large organisations make simplifying, legible assumptions that are practically false but useful for planning: that engineers are interchangeable, that productivity is tied to headcount, and that project estimates are reliable.

Frameworks like The Open Group Architecture Framework (TOGAF) are powerful tools for achieving this legibility. For “business as usual” activities, TOGAF provides a comprehensive structure and acts as a checklist to ensure nothing is forgotten. It helps an organisation arrange itself in a predictable, repeatable manner. This is the positive side of legibility: it creates order and a common language for complex operations.

The downside emerges when such frameworks are applied too rigidly. Their exhaustive processes can stifle the very illegible work—quick favours, rapid pivots, creative problem-solving—that is essential for genuine efficiency. This is how managers can be dismissed for failing to prioritise critical tasks, even when all their processes were well-defined. They become so focused on the legible game of process compliance that they fail to navigate the illegible world where urgent problems are actually solved.

However, a framework like TOGAF is not inherently negative. With some creativity, its principles can be adapted for more ad-hoc work. One could use a “TOGAF-lite” approach within an engineering team, borrowing its structural thinking without adopting the full bureaucratic weight. This represents a mature approach: using tools of legibility selectively, rather than being controlled by them.

Sanctioned Zones of Illegibility

When a crisis hits—like an imminent database failure—the formal, multi-step approval process is too slow. Goedecke notes that companies create a clever compromise: “temporary sanctioned zones of illegibility”.

These are often called “tiger teams” or “strike teams” and operate under a different set of rules:

A team of trusted, hand-picked engineers is assembled.
They are given a loose mandate (e.g., “Fix the urgent problem”).
They are empowered to do whatever is necessary, bypassing normal processes.

This allows the organisation to benefit from high-efficiency, illegible work in a controlled way without abandoning the legible structure it needs for day-to-day operations. It is a formal acknowledgement that the official process is not always fit for purpose.

Even these zones are not immune to the pull of legibility. In my experience, even when a tiger team is formed, managers often want to see a budget approved and funds transferred internally before work can begin.^[1] The instinct to measure and control remains powerful.

Ultimately, an organisation’s success depends on its ability to balance both worlds. It needs the legible systems for stability and scale, but it must also allow space for the unsanctioned, illegible work that provides resilience and true operational effectiveness.

This adds a layer of formal process back onto an activity designed to escape it, showing the deep-seated organisational preference for legibility. ↩︎

Frameworks as Mental Handrails for Navigating Complexity

2025-09-09T00:00:00Z

In his article “Frameworks,” published on open.substack.com, Mike Fisher presents a compelling metaphor: frameworks are “handrails for thinking.” They provide the scaffolding needed to navigate uncertainty and complexity, transforming overwhelming problems into manageable tasks.

The core idea is that frameworks simplify complexity by providing structure, much like a recipe guides a cook or an algebraic simplification clarifies an equation.

This structure is not just for convenience; it is rooted in cognitive science. Fisher explains that frameworks help by:

Reducing Cognitive Load: By organising information into clear patterns, frameworks free up our limited working memory. This allows us to allocate mental energy to higher-order tasks like creativity and problem-solving, rather than managing basic complexity.
Guiding Through Uncertainty: Like a handrail on a dark staircase, a framework offers stability and a clear path forward when the environment is ambiguous. It reduces the fear of missteps and builds confidence.
Mitigating Cognitive Biases: Structured methods like SWOT or the Eisenhower Matrix force a deliberate evaluation of multiple perspectives, acting as a check against common biases like confirmation bias or overconfidence.

However, Fisher wisely cautions against rigidity. Over-reliance on a framework can stifle creativity and lead to oversimplification. The key is to use them as a starting point—to adapt, question, and even build your own.

Reflection from a Systems Perspective

As a practitioner of TOGAF and Systems Engineering, this perspective is foundational. These disciplines are, at their core, the application of structured frameworks to manage immense complexity.

TOGAF’s Architecture Development Method (ADM) is a perfect example of a “handrail.” It breaks down the monumental task of designing an enterprise architecture into distinct, manageable phases. This reduces the cognitive load on architects and provides a common language for stakeholders, ensuring a project moves forward with clarity. Similarly, the V-model in Systems Engineering provides a clear framework for development and validation, ensuring that what is built aligns with what was required.

Beyond their direct application in problem-solving, frameworks are invaluable communication tools. They help in finding the right level of detail for a specific audience, ensuring that complex information is conveyed effectively. When frameworks are used well, they empower stakeholders to ask more structured and relevant questions, leading to more focused discussions and better-informed decisions. This steering of the discussion towards productive outcomes is a critical, often overlooked, benefit of employing robust frameworks.

These frameworks are not rigid rulebooks. The most effective architects and engineers know how to tailor them. They adapt the ADM to their organisation’s specific needs or modify the V-model for a unique project context. This aligns with Fisher’s final point: the goal is not blind adherence but thoughtful engagement. Frameworks are the mental infrastructure that enables us to build complex systems, but their real usefulness is realised when we adapt them to the terrain.

Where's the Shovelware? The AI Coding Claims Conundrum

2025-09-08T00:00:00Z

In recent years, AI coding tools like GitHub Copilot, Claude Code, and Cursor have promised extraordinary productivity gains for developers. These tools claim to make coding faster, easier, and more efficient, with taglines like “Built to make you extraordinarily productive” and “Build Better Software Faster.” However, despite these bold claims and widespread adoption, there is a noticeable lack of evidence that these tools are actually leading to a significant increase in software output.

In his article “Where’s the Shovelware? Why AI Coding Claims Don’t Add Up”, Mike Judge argues that the AI coding revolution is more hype than substance. He points out that if these tools were truly making developers as productive as claimed, we should be seeing a flood of new software—apps, games, websites, and more. Yet, the data shows no such surge. Charts tracking new software releases across various sectors remain flat, with no indication of the exponential growth one would expect if AI coding tools were living up to their promises.

Judge’s argument is compelling. If AI coding tools were genuinely making developers 10x more productive, as some claim, the world would be drowning in shovelware. The fact that this isn’t happening suggests that these tools may not be as transformative as advertised. This disconnect between claims and reality has serious implications for the tech industry, as companies are making decisions based on the assumption that AI coding tools are dramatically increasing productivity.

Key Takeaways from Mike Judge’s Analysis

Productivity Claims vs. Reality:
- AI coding tools claim to make developers significantly more productive, with some developers even claiming a 10x increase in output.
- However, studies like the METR study show that developers often overestimate their productivity gains from AI tools. In some cases, AI tools may actually slow developers down.
Lack of Shovelware:
- If AI coding tools were as effective as claimed, there would be a noticeable increase in the number of new software releases.
- Data from sources like Statista, Verisign, and SteamDB show no significant increase in new software releases post-2022/2023, despite widespread AI tool adoption.
Impact on Developers:
- The pressure to adopt AI coding tools is leading to job insecurity, with developers feeling compelled to use these tools even if they don’t find them helpful.
- The focus on AI tools may be distracting from other important aspects of software development, such as code quality and continuous improvement.

Personal Reflections on AI Coding Tools

While AI coding tools haven’t turned me into a 10x developer, they have given me the confidence to take on more complex coding tasks. As Simon Willison notes, only a small portion of a programmer’s time is spent on hands-on coding, which may explain why we’re not seeing a flood of new software. AI tools can speed up the coding process, but they don’t address the other aspects of software development, like planning, testing, and maintenance.

That said, the lack of a noticeable increase in software output is concerning. It suggests that the benefits of AI coding tools may be overstated, and that the industry’s focus on these tools could be misplaced. As Judge argues, developers should trust their gut and stick with what works for them, rather than feeling pressured to adopt tools that may not actually improve their productivity.

Conclusion

The AI coding revolution may not be living up to its promises, but that doesn’t mean these tools are useless. They can still be valuable for certain tasks and for certain developers. However, the industry should approach these tools with a healthy dose of skepticism and focus on objective measures of productivity, rather than hype and bold claims.

Building Reliable AI Agents: Notes on Evaluation and Contracts

2025-09-06T00:00:00Z

As AI agents are integrated into business operations, ensuring their reliability is essential. A new book, Agentic Design Patterns by Antonio Gulli, offers a practical guide for building robust agentic systems. You can find it on Amazon or read the pre-print version on Google Docs.

The foreword by Marco Argenti, CIO of Goldman Sachs, clearly states the problem:

The hard truth is that you cannot simply overlay these powerful new tools onto messy, inconsistent systems and expect good results. Messy systems plus agents are a recipe for disaster.

So, how do we build and monitor agents to be dependable? The book’s chapter on “Evaluation and Monitoring” provides a clear framework.

How to Evaluate Agents

Traditional software testing is not enough for probabilistic systems like AI agents. We need continuous evaluation. Key techniques include:

Response Assessment: Check if the agent’s output is correct using methods that understand meaning, not just exact text matches.
Performance Monitoring: Track metrics like response speed and resource consumption to ensure the agent runs efficiently.
Qualitative Assessment: Use another AI as a “judge” (LLM-as-a-Judge) to evaluate subjective qualities like helpfulness based on a clear rubric.^[1]
Trajectory Analysis: Review the sequence of steps an agent took to understand its reasoning process and spot inefficiencies.

The ‘Contractor’ Model for Reliability

To achieve the reliability needed for business-critical tasks, the book proposes evolving from simple agents to “contractors.”

This contractor framework reimagines AI interaction by embedding principles of formal specification, negotiation, and verifiable execution directly into the agent’s core logic.

This model is built on four pillars:

The Formalised Contract: Define the task with a detailed specification, not a vague prompt. This makes the outcome objectively verifiable.
Dynamic Negotiation: The agent can analyse the contract and clarify ambiguities before starting work, preventing errors from misunderstandings.
Quality-Focused Execution: The agent prioritises correctness, operating in a loop of generating, self-validating, and correcting its work until quality standards are met.
Hierarchical Decomposition: A primary contractor can break a large task into smaller sub-tasks, creating formal “subcontracts” for other specialised agents.

Conclusion

Building trust in AI agents requires a shift in approach. By implementing robust evaluation frameworks and adopting the “contractor” model—which relies on formal agreements and verification—we can move from unpredictable tools to reliable systems fit for critical business applications.

The LLM-as-a-Judge approach is powerful but has limitations. Its effectiveness is constrained by the capabilities of the judge model, and it may overlook errors in intermediate reasoning steps if only the final output is assessed. ↩︎

How Optimising for Short-Term Metrics Causes Long-Term Harm

2025-09-05T00:00:00Z

Lucas Pierce’s post, Short-term metrics, long-term harm, analyses how optimising for short-term metrics leads to negative long-term consequences, even when builders have no malicious intent.

The Optimisation Engine

The engine for this is the A/B test, which allows companies to measure a change’s impact on a target metric like ‘time spent’. Instead of debating a feature’s merit, teams can simply test it. As Pierce notes, “It no longer matters why it works, just that you can prove it does work.”

The relentless pursuit of engagement has led to features that exploit human psychology, such as variable reward schedules, social validation, and infinite scroll.

The process requires no more intent than natural selection does. It’s just thousands of little experiments, with the most compulsive features surviving because they satisfy a simple fitness function: does time spent go up?

Pierce warns that this pattern is repeating with Large Language Models (LLMs). When optimised for engagement, chatbots learn to tell users what they want to hear, not what is accurate. This encourages sycophantic behaviour and creates personalised echo chambers.

This creates a direct trade-off between easily measured metrics and harder-to-quantify user well-being.

Short-Term Metric	Potential Long-Term Harm
Increased Time Spent	Fosters addiction; reduces well-being.
More Likes & Comments	Exploits need for social validation; can harm mental health.
Higher Post Frequency	Encourages performative behaviour over genuine connection.
Engaged Chatbot Sessions	Reinforces biases and echo chambers; promotes sycophantic responses over accuracy.

Systemic Problems Require Systemic Solutions

These outcomes are not the result of “evil” people but are the consequence of a system that rewards short-term growth. Pierce argues for fixing the system, not blaming individuals, using root-cause analysis like the 5 Whys.^[1]

The article concludes with a call for professional responsibility. Builders must actively investigate and mitigate the harms of their products, rather than deferring to “consumer choice.”

If you build a product, you are responsible for understanding its long-term impact on users… the burden should be on the builder of the product proving their product isn’t harmful, and mitigating what harm they do discover.

This challenges the industry to implement mechanisms that prevent known patterns of harm from repeating.

The 5 Whys is an interrogative technique used to explore the cause-and-effect relationships underlying a problem. By repeatedly asking “Why?”, teams can move past surface-level symptoms to identify a systemic root cause. You can read more about it at interaction-design.org. ↩︎

Quantifying the Environmental Impact of Large Language Models

2025-09-03T00:00:00Z

As artificial intelligence systems become more integrated into our digital infrastructure, understanding their environmental impact is a growing concern. While discussions often focus on carbon emissions, the full picture includes water consumption and material resource depletion.

In a move towards greater transparency, the French company Mistral AI published a comprehensive lifecycle analysis (LCA) of its models. The study, conducted with leading environmental consultancies, is one of the first of its kind and aims to establish a standard for evaluating the environmental footprint of AI.

Key Findings from the Mistral Report

The analysis tracked the environmental impact of Mistral Large 2 (a 123-billion-parameter model) over 18 months, covering everything from data centre construction to model training and inference.

Training Impacts:

Greenhouse Gases: 20,400 metric tons of CO₂e.
Water Consumption: 281,000 cubic metres.
Resource Depletion: 660 kg Sb eq.^[1]

To put these numbers in context, the training emissions are roughly equal to the annual emissions of 4,400 petrol-powered cars. The water consumed is equivalent to what an average U.S. family of four would use in 500 years, according to an analysis in Andrew Ng’s The Batch newsletter.

Inference Impacts (per 400-token response):

Greenhouse Gases: 1.14 gCO₂e (similar to watching a 10-second YouTube clip in the U.S.).
Water Consumption: 45 millilitres (about 3 tablespoons).
Resource Depletion: 0.16 mg Sb eq.

The report also breaks down where these impacts originate.

Impact Source	Greenhouse Gas Emissions	Water Consumption	Materials Consumption
Training & Inference	85.5%	91%	29%
Server Lifecycle	11%	5%	61%
Network Traffic	< 1%	< 1%	< 1%

This data shows that while the operational phase (training and inference) dominates emissions and water use, the manufacturing and transport of hardware are the primary drivers of material resource depletion.

Why This Matters

Andrew Ng’s newsletter, The Batch, summarises the core issue well, explaining why such analysis is critical for the future of the technology.

AI consumes enormous amounts of energy and water, and finding efficient ways to train and run models is critical to ensure that the technology can benefit large numbers of people. Mistral’s approach provides a standardized approach to assessing the environmental impacts.

A Proposed Standard and Takeaways

The initiative by Mistral AI is a crucial step towards establishing industry-wide transparency. By publishing a methodology and its results, Mistral provides a framework that other companies can adopt, which could enable more direct and objective comparisons between models.

This push for transparency coincides with a trend towards greater model efficiency. Newer models and architectures are often more resource-efficient. While commercial incentives to reduce operational costs are a likely driver for this, the resulting progress in sustainability is a positive outcome.

Mistral’s report proposes that a useful standard should include:

The absolute environmental impacts of training a model.
The marginal impacts of inference.
The ratio of total inference impacts to total lifecycle impacts.

Having a clear, standardised picture of AI’s consumption of resources is essential for managing them effectively as demand continues to rise. This report provides a valuable baseline for the industry to build upon.

Abiotic Resource Depletion (ADP) quantifies the depletion of non-renewable resources like metals and minerals. Values are standardised relative to Antimony (Sb), a scarce resource, providing a uniform unit of kg Sb eq. ↩︎

On 'Communication is The Job' by Andrew Bosworth

2025-09-02T00:00:00Z

Effective communication is a fundamental skill, and one I am always working to improve. In his post, “Communication is The Job”, Andrew ‘Boz’ Bosworth^[1] provides a clear, actionable framework that supports this goal of continuous development. He argues that communication is not an auxiliary function but the central task for anyone connecting people with information.

Given that we cannot prevent communication, we must embrace it. While perfect communication is impossible, my goal is to get most people most of the information most of the time.

Boz outlines eight practical strategies to improve communication.

Eight Strategies for Effective Communication

Layer Your Message: Structure your communication so the audience can engage at their desired level of detail. Start with the core theme, then key points, then the full details.
Consider the Second Order Audience: Your message will be repeated by others. Frame it in a way that is memorable and can be shared with high fidelity.
Communicate Defensively: Before sharing, consider the most cynical interpretation of your message and refine it to minimise the chance of misinterpretation.
Repetition is Key: Repeat the critical message multiple times within a single communication and across different communications to aid retention.
Use Multiple Channels: People absorb information differently. Use a mix of channels—meetings, posts, one-on-ones—to reach everyone.
Maintain Channels: Regularly use your communication channels with high-quality content so that the audience trusts them and stays engaged.
Communicate Early and Often: Do not wait for perfect information. It is better to share the current state of understanding and revise it later than to let a vacuum be filled by rumours.
Debug Miscommunication: If your message is not landing, it is your fault, not the audience’s. Take full responsibility, ask questions to understand the gap, and correct the message for everyone.

The principle of taking ownership for miscommunication provides a clear path for improvement. Rather than getting frustrated, the task becomes to diagnose the failure and correct it.

When I’m doing a poor job of communicating it can feel like I’m pushing with a rope… It can be a frustrating experience and it is tempting to blame the audience for not understanding. But make no mistake, when this happens, it is your fault.

This perspective transforms communication from a vague talent into a concrete skill that can be systematically debugged and improved—a powerful mindset for growth.

Andrew “Boz” Bosworth is the CTO of Meta and a long-time executive at the company. ↩︎

A reading list on developer productivity metrics

2025-09-01T00:00:00Z

Measuring the productivity of software developers is a complex and often contentious topic. Simplistic metrics like story points or lines of code are widely criticised for creating the wrong incentives and failing to capture the true nature of engineering work. The focus is shifting towards measuring project outcomes and team health rather than individual output.

Laura Tacho has curated a comprehensive reading list that provides an excellent overview of the modern landscape of developer productivity metrics. It serves as a valuable resource for anyone looking to move beyond flawed traditional measures.

The list is organised into several key sections, providing a structured path through the subject.

Frameworks overview

This section covers the foundational frameworks used to think about and measure productivity and developer experience today. It includes:

The AI Measurement Framework: For tracking AI adoption and impact.
DX Core 4: A unified framework combining DORA, SPACE, and DevEx.
SPACE Framework: The original paper outlining Satisfaction, Performance, Activity, Communication, and Efficiency.
DORA Metrics: The four key metrics for software delivery performance.
DevEx Framework: Focuses on feedback loops, flow state, and cognitive load.

Measuring the impact of AI

With the rise of generative AI, measuring its actual effect on productivity is crucial. This part of the list offers guides on how to measure GenAI adoption and its impact on developer experience and throughput, cautioning that its use is not a guaranteed productivity boost.

Key articles and perspectives

The collection includes several important articles that provide context and critical perspectives. It references the debate around the McKinsey article on productivity, offering a counterpoint from The Pragmatic Engineer. It also highlights foundational pieces from Martin Fowler and Bryan Finster on effectiveness and the potential misuse of DORA metrics.

Laura includes her own strong perspective on the human element of measurement:

One thing I won’t shut up about is that developers are adults, and if they tell you something is preventing them from working efficiently, you should believe them.

This list is a valuable addition, providing extra detail to my earlier posts on the various frameworks for measuring developer productivity and a deeper look at AI’s impact through the SPACE framework. It is a nice, comprehensive overview that brings together many of the current standards and debates in one place.

The full, detailed reading list is available here:
Developer Productivity Metrics - Reading List (Google Docs)

Do the simplest thing that could possibly work

2025-08-31T00:00:00Z

In a recent article, Sean Goedecke argues for a powerful principle in software design: “Do the simplest thing that could possibly work”. It is a philosophy that pushes back against the common tendency to over-engineer solutions for problems that do not yet exist.

A summary of Sean’s argument

Sean observes that many engineers design for an imagined “ideal” system—one that is perfectly factored, infinitely scalable, and elegantly distributed. He suggests this is the wrong approach. Instead, the focus should be on deeply understanding the current system and implementing the most straightforward solution possible.

He notes that truly effective design can often seem underwhelming.

Great software design looks underwhelming. It doesn’t look like anything much is happening at all. You can tell you’re in the presence of great software design because you start having thoughts like “oh, I didn’t realise the problem was that easy” or “oh nice, you don’t actually have to do anything difficult”.

Sean anticipates and addresses three common objections to this philosophy:

Creating a “Big Ball of Mud”: The concern that this approach encourages quick hacks, leading to a messy system. Sean counters that true hacks are inherently complex; the simplest solution often requires more engineering thought to discover and is fundamentally cleaner.
The Ambiguity of “Simplicity”: The argument that “simplest” is too subjective. He offers a practical definition: simple systems have fewer moving parts, are less internally connected, and are more stable, requiring less ongoing work.
Ignoring Scalability: The objection that this method is irresponsible because it does not prepare for future growth. Sean argues that trying to predict future scale often fails and leads to inflexible systems.

On the topic of scale, he is particularly direct:

In my view, the cardinal sin of big tech SaaS engineering is an obsession with scale. I’ve seen so much unavoidable pain caused by over-engineering systems to prepare for several orders of magnitude more than the current scale.

The core message is to design for the requirements you have right now. This approach, originally credited to Ward Cunningham and Kent Beck, results in more flexible and manageable systems.

Applying simplicity beyond code

I find this principle is applicable in almost any field. In my own work, for example, when writing architecture documents or creating diagrams, I actively try to make them as simple as possible. A straightforward diagram is much easier for stakeholders to understand and work with. It reduces the effort needed to convey the core message.

This line of thinking is crucial when designing the systems themselves. Consider the initial architecture for a new machine learning model. The temptation is to design a system with separate microservices for data ingestion, a dedicated feature store, and a complex orchestration tool like Kubeflow, all before the first model has proven its value.

Applying Sean’s principle, the simplest thing that could possibly work looks very different:

A single, version-controlled script that pulls data, trains the model, and saves the model file and performance metrics.
A simple cron job to run this script on a schedule for retraining, leaning on existing system primitives.
If real-time predictions are a hard requirement, a basic API using Flask can serve the model. If not, the simplest solution is even more direct: a batch script that runs predictions and saves the results to a database or file.

This minimal setup delivers value immediately. You only add complexity—like a dedicated feature store or a more advanced orchestrator—when you have a proven need, such as multiple models reusing the same features or training dependencies that a cron job can no longer manage. By applying the KISS principle and leaving out anything that is not essential, the architecture becomes more approachable and we can focus on delivering value first.

Measuring AI Impact on Developers: No Holy Grail, But Practical Paths Forward

2025-08-30T00:00:00Z

In my earlier post, “A deeper look at AI’s impact through the SPACE framework”, I explored how AI affects developers across multiple dimensions; not just output, but satisfaction and collaboration. But how do organisations measure that impact at scale?

As Laura Tacho, CTO at DX, details in her deepdive for The Pragmatic Engineer, “How tech companies measure the impact of AI on software development”, there is no single metric that tells you whether AI is working. In fact, 60% of engineering leaders cite a lack of clear metrics as their biggest AI challenge.

“We agreed a long time ago that LOC is a bad measure of developer productivity, but it’s easy to measure LOC, and in the absence of a clear alternative, easy to latch on to.” — Laura Tacho

From her article, here’s what actually works and what doesn’t.

What to Measure: The Core + AI Blend

You don’t need new metrics. Start with what already matters and add AI-specific signals on top.

Core Engineering Metrics (What Always Mattered)

Change Failure Rate (CFR)^[1]: % of deployments that cause incidents or rollbacks. Measures reliability.
PR Throughput^[2]: Number of pull requests merged per engineer or team per week. Measures delivery speed.
PR Cycle Time^[3]: Time from first commit to PR merge. Measures workflow efficiency.
Developer Experience (DevEx)^[4]: How much friction developers feel across planning, coding, testing, and production. Often measured via surveys.

AI-Specific Signals (What’s New)

DAU/WAU^[5]: Daily or weekly active users of AI tools. Shows adoption depth.
CSAT^[6]: Satisfaction score for AI tools, e.g.; “On a scale of 1–5, how satisfied are you with Copilot?”
Self-reported time saved: Estimated hours per week saved using AI tools.
Cost per engineer: AI tool spend divided by active users. Helps track ROI.

Dropbox, for example, tracks both and found that AI users merge 20% more PRs while reducing CFR. This dual tracking prevents over-indexing on speed.

“You don’t need totally new metrics to measure AI impact. Instead, focus on what’s always mattered. Is AI helping your organization get better at those things?” — Laura Tacho

What Not to Measure (Or At Least, Not Alone)

These metrics are misleading if used in isolation:

Lines of Code (LOC)^[7]: Easy to count, meaningless as a productivity signal. Doesn’t reflect quality, maintainability, or business value.
Acceptance Rate (alone): Measures how often developers accept AI suggestions, but says nothing about whether the code is good, maintainable, or bug-free.
Token Spend (without context): Cost matters, but not if it’s divorced from value delivered. Some companies (like Shopify) celebrate high spend as a sign of experimentation.
“AI-Generated Code %”: A headline-friendly number, but tells you nothing about quality, reliability, or developer experience.

As Monzo’s Suhail Patel puts it:

“If we have to spend an equal amount of time fixing up AI-generated code as we spent handwriting the code, then we’ve made no progress!”

Break Down Data, Don’t Aggregate Blindly

Don’t treat “AI impact” as a monolith. Slice and dice your data:

AI users vs. non-AI users^[8]: An “AI user” is typically someone who uses an AI tool at least weekly. Compare their metrics (e.g., PR throughput, CFR) against non-users.
Cohort analysis^[9]: Follow the same group of developers before and after they adopt AI tools. Measures individual impact.
Segment by role, tenure, or language^[10]: E.g., junior devs may open more PRs; seniors may slow down due to review load. Reveals where enablement is needed.

Webflow found AI saved the most time for devs with 3+ years experience. Monzo saw juniors open more PRs, seniors slow down likely reviewing AI output. These aren’t flaws, they’re signals for targeted enablement.

Balance Speed with Quality and Maintainability

Track metrics that keep each other in check:

PR Throughput + Change Failure Rate: Speed without stability is a trap.
System data + Self-reported data: You can’t measure “maintainability” or “change confidence” from logs alone.

“Developer experience tells us the story behind the numbers. While output metrics like PR throughput show us what is happening, developer satisfaction reveals whether it’s sustainable.” — Shelly Stuart, CircleCI

How to Start (Even Without Big Tech Resources)

Establish baselines for core metrics (CFR, cycle time, throughput).
Layer in AI signals via surveys (CSAT, time saved) and system data (DAU, spend).
Use experience sampling ask quick questions during workflows (e.g., “Did you use AI here?”).
Adopt an experimental mindset test hypotheses, not just collect data.

As Tacho notes:

“Taking these measurements once won’t give you much insight into AI impact; tracking them over time is what reveals trends and patterns.”

What This Means for Your Team

No single metric is enough. Speed, quality, maintainability, and experience are interdependent — measure them together.
Context is king. A 20% PR increase means nothing if bugs spike. Always ask: “At what cost?”
Culture matters more than tools. Teams with high AI adoption report greater personal and team benefits — because they share best practices and support each other.
Start small, iterate often. You don’t need perfect data — you need enough to make better decisions. Pick one core metric and one AI signal to track next quarter.

The goal isn’t to “measure AI”, it’s to measure whether AI is helping your team deliver better software, faster, without burning out or accumulating tech debt. That’s a challenge worth tackling; one metric, one cohort, one survey at a time.

Change Failure Rate (CFR): % of deployments that cause incidents or rollbacks. Measures reliability. ↩︎
PR Throughput: Number of pull requests merged per engineer or team per week. Measures delivery speed. ↩︎
PR Cycle Time: Time from first commit to PR merge. Measures workflow efficiency. ↩︎
Developer Experience (DevEx): How much friction developers feel across planning, coding, testing, and production. Often measured via surveys. ↩︎
DAU/WAU: Daily or weekly active users of AI tools. Shows adoption depth. ↩︎
CSAT: Satisfaction score for AI tools — e.g., “On a scale of 1–5, how satisfied are you with Copilot?” ↩︎
Lines of Code (LOC): Total lines of code written or generated. A poor proxy for productivity or value. ↩︎
AI users vs. non-AI users: An “AI user” is typically someone who uses an AI tool at least weekly. Compare their metrics against non-users. ↩︎
Cohort analysis: Follow the same group of developers before and after they adopt AI tools. Measures individual impact. ↩︎
Segment by role, tenure, or language: E.g., junior devs may open more PRs; seniors may slow down due to review load. Reveals where enablement is needed. ↩︎

Documents: The architect's programming language

2025-08-30T00:00:00Z

In a post on the Stack Overflow blog, Isaac Lyman presents a interesting argument that for a software architect, documents are the equivalent of a programming language. They are the primary tool for deploying ideas into a system of people, a powerful way to think about a skill that is often seen as a secondary task. stackoverflow.blog

The core idea: Deploying ideas to systems of people

The central premise of the article is captured in this distinction:

Senior developers know how to deploy code to systems of code.
Architects know how to deploy ideas to systems of people.

An architect’s main challenge is not just technical implementation, but achieving alignment, consensus, and shared understanding across teams and stakeholders. The most significant bottlenecks are often people-related: communication, persuasion, and decision-making. Isaac argues that well-crafted documents are the most effective and repeatable way to navigate these challenges.

Principles for effective documentation

To make documentation effective, Lyman suggests a few key principles and techniques:

Prioritise action over perfection: It is better to jot things down than to worry about the perfect structure initially. An existing, imperfect document is more valuable than a perfect one that was never written.
Use bullet points and headers: These tools are an architect’s best friend. They force a focus on structure and completeness over style, and they make documents easy for busy people to skim and digest. The goal is to avoid a “wall of text”.
Embrace point-in-time documents: Most documents serve a purpose and then become obsolete. They are more like one-off scripts than applications that need constant maintenance.

A chronological approach to organisation

One practical idea in the article is the approach to organising documents. Instead of grouping them by topic—which Isaac argues is subjective and wastes time—he proposes a chronological structure. A few high-level, continuously maintained documents like an Overview and Architecture can live at the top level. Everything else is organised by time.

This structure might look like this:

📄 Overview
📄 Architecture
📁 2025
    📁 Jan 1 Sprint
        📄 Proposal: Connect edge compute 
        📄 ADR-132 Machine Learning on the edge
    📁 Jan 15 Sprint
        📄 ADR-135 Messaging edge

This approach makes the timeline of decisions clear and encourages the use of search, which is often more efficient for finding specific information. When you find a document, you immediately have context for when it was written and what else was happening at the time.

High-impact document types

The article provides an excellent appendix of high-impact document types that an architect can use to orchestrate ideas.

The architecture overview

What it is: A document or diagram describing the major components of a system and how they communicate.
How it orchestrates ideas: It helps contributors form a shared mental model of a system, which is essential for building on it, troubleshooting it, and getting it approved by leadership.

The dev design

What it is: A plan for code you intend to write, outlining the steps, classes, and methods involved.
How it orchestrates ideas: It helps developers share knowledge, preserve core patterns, and create a permanent record of how a system evolved. It provides many of the benefits of pair programming asynchronously.

The project proposal

What it is: A document communicating the value, cost, and impact of a potential project.
How it orchestrates ideas: This is how large, impactful projects are born. A well-written proposal sets the roadmap for entire teams by making it easy for leaders to say “yes”.

The developer forecast

What it is: A document that raises potential risks or worse-than-expected outcomes of a decision.
How it orchestrates ideas: It allows an engineer to share professional foresight, get people thinking about pitfalls, and prepare the organisation to respond adeptly if things go wrong.

What it is: A comparison of favoured technologies (languages, frameworks, etc.) with recommendations for when to use each.
How it orchestrates ideas: It creates consensus on how things are built, freeing developers from “this-versus-that” debates and allowing them to spin up new projects efficiently.

The problem statement

What it is: A clear explanation of a problem, its constraints, and a few possible solutions.
How it orchestrates ideas: It enables anyone, regardless of their role, to understand a problem and weigh in on the solution. It also creates a record of the decision-making process.

The postmortem

What it is: A blameless analysis of a catastrophic failure, including its timeline, root causes, and recommended changes.
How it orchestrates ideas: It helps an organisation move from fear (“this can never happen again”) to confidence (“we will make sure of it”) and shifts the culture away from individual blame toward systemic resilience.

My perspective: Documentation as code

Isaac’s perspective aligns with how I view the craft of documentation. I see a direct parallel between writing good documentation and writing high-quality code. Just as we refactor code into clean, reusable, and understandable functions or classes, our documentation should follow the same principles.

The goal is not just to write something, but to create an asset that is easy for others (and our future selves) to parse and use. The emphasis on bullet points, clear headers, and logical structure is the documentation equivalent of clean code. It is about creating a clean, simple, and understandable artefact that serves a clear purpose. Thinking of documents as a “programming language” for influencing human systems is the right way to approach this essential architectural skill.

Entering the probabilistic era of software

2025-08-28T00:00:00Z

Gian Segato’s essay, Building AI Products In The Probabilistic Era, offers a clear perspective on the fundamental changes AI is bringing to software development. He argues that we are moving from a ‘classical’ deterministic world to a ‘quantum’ probabilistic one, a shift that requires a complete rethinking of how we build, manage, and measure software products.

From deterministic funnels to infinite fields

Traditionally, software has been deterministic. We build products that map known inputs to expected results: F(x) -> y. An action x reliably produces an outcome y. Our entire industry, from engineering Service Level Objectives (SLOs) to product management conversion funnels, is built on the premise of predictable, countable, and reliable outcomes.

Gian argues that generative AI breaks this model. We now have a function, F'(?), that accepts a near-infinite range of open-ended inputs and produces a probability distribution of possible outputs. The input is unknown, and the output is stochastic.

In moving to an AI-first world, we transitioned from funnels to infinite fields.

This change means our products can now succeed in ways we never imagined and fail in ways we never intended.

The shift from engineering to empiricism

This new reality demands a different mindset. The classical engineering approach of adding constraints to ensure 100% reliability can “nerf” the model, destroying the very emergent intelligence that makes it powerful.

Instead, Gian suggests a move towards empiricism, where we act more like scientists than traditional engineers. This involves forming hypotheses, testing them rigorously, and accepting that we do not have perfect knowledge of the system.

With AI products, all this is no longer true. These models are discovered, not engineered. There’s some deep unknowability about them that is both powerful and scary.

This approach requires a willingness to fundamentally rethink and even rebuild systems when a new, more capable model is released, as demonstrated by Replit’s complete product re-architecture in three weeks to leverage a new model’s capabilities.

My perspective

Gian’s essay provides a valuable framework for what many of us are experiencing with the rise of generative AI. It feels like we are only at the beginning of understanding the implications of this shift, and his articulation of the move from deterministic to probabilistic systems is very accurate.

I see a direct parallel in how large corporations must adapt. Implementing these new models is not just about adding a new tool; it requires a complete overhaul of processes and how we define value.

However, this transition also introduces a significant tension, particularly in a corporate environment. While AI excels in ambiguity, many business functions rely on determinism. For tasks like KPI reporting or financial tracking, an 80% or 90% probability of being correct is not sufficient. The answer must be 100% right. The same applies to security; 99% secure is a critical failure.

This highlights a crucial challenge: how do we harness the power of probabilistic AI for creative and exploratory tasks while maintaining the deterministic integrity required for critical business operations? Finding that balance will be key for full value creation with these new tools.

The GenAI divide report: Scrutiny, hype, and the reality of AI adoption

2025-08-27T00:00:00Z

Two weeks ago, a report titled “The GenAI Divide,” produced in collaboration with MIT’s Project NANDA, made significant waves. Its headline claim—that 95% of enterprise Generative AI initiatives yield zero financial return—was quickly amplified by news outlets and fuelled discussions about a potential AI bubble.

However, a closer look at the report and the subsequent analysis from industry experts reveals a more nuanced story. The debate it sparked offers valuable lessons on technological adoption, academic rigour, and the organisational challenges that truly define success with AI.

A critical examination of the report

Wharton Professor Kevin Werbach provided a sharp critique of the report’s methodology and conclusions. He argues that the document is “deeply problematic” and that its most striking claim lacks clear evidence within the report itself.

The “MIT report” which made a big splash this week, finding few generative AI deployments generate any returns, is deeply problematic. The incident is, frankly, a great example of confirmation bias.

Kevin points out several key issues:

Unsubstantiated Claims: The “95% getting zero return” figure is stated in the executive summary but is not clearly supported by data in the rest of the document. The methodology, based on interviews with 52 organisations and surveys with 153 leaders, is not detailed enough to validate such a specific, impactful claim.
Misleading Association: He notes the report was produced “in collaboration with Project NANDA out of MIT,” questioning the level of involvement from MIT’s core faculty and researchers. This association lent the report a degree of credibility that its contents may not warrant.
Vague Definitions: The report defines “unsuccessful” deployment in a way that does not explicitly mean “zero returns,” creating ambiguity.

Kevin suggests that the report’s authors may have lacked academic research rigour, and its findings were seized upon by sceptics looking to confirm their biases.

Beyond the bubble talk

In his Substack newsletter, Jonas Braadbaart offers a different perspective. While acknowledging the report and the “bubble talk” it generated, he argues that for business owners and operators, the focus should be elsewhere. Jonas contends that we are still in the very early stages of AI adoption, comparable to the internet in 1998.

He cleverly uses the report’s own data to highlight what he sees as the real issue. When interviewees were asked about the likely causes for pilot failures, the top reasons were not technical.

Most of the challenges faced by these pilots were organizational—not technological.

Jonas points to a disconnect between IT and business teams, poor user experience, and a failure to set the right context for users as the primary culprits. The problem is not that the technology is failing, but that organisations are failing to adapt their processes and culture to leverage it effectively.

Personal reflection

Connecting the perspectives of Kevin Werbach and Jonas Braadbaart provides a comprehensive view. Kevin rightly scrutinises the report’s sensationalist claims and questionable methodology, reminding us to be critical of sources, even those with prestigious affiliations. Jonas, on the other hand, looks past the headline to extract a practical insight: the friction in AI adoption is more organisational than technological.

I believe there is immense value to be gained from AI, but it is not a magic wand. The NANDA report, despite its flaws, inadvertently highlights this truth. The focus on “agentic AI” and other technical solutions within the report feels like a distraction from the core challenge. Real, sustainable returns will not come from a slightly better model or a new marketing term. They will come from fundamentally rethinking and adapting our ways of working.

Success requires integrating these new tools into our existing workflows in a thoughtful way, which means changing processes that have been in place for years. It demands that we move beyond the hype and critically assess how this technology can solve specific, real-world problems within our businesses. The real “GenAI divide” is not between companies getting returns and those getting zero; it is between organisations that understand this and those that are still waiting for a plug-and-play solution.

Alberta's new blueprint: Treating data centres as grid actors

2025-08-26T00:00:00Z

I came across an interesting post by Dlzar Al Kez on LinkedIn detailing a significant policy shift in Alberta, Canada. The province’s grid operator, AESO, has drafted new connection requirements that fundamentally redefine the role of large, transmission-connected data centres (TCDCs). Instead of treating them as passive loads, Alberta is mandating that they behave like active, responsible grid participants.

The context is crucial. Alberta’s grid has a peak demand of around 12.4 GW—for context, the peak demand in the Netherlands is around 19 GW (tennet.eu)—with limited connections to neighbouring systems. In a grid of this scale, a sudden drop or surge of 500 MW from a single data centre is not just noise; it is a major system event that could threaten stability for the entire province. As Dlzar notes, what is a minor fluctuation in a large grid like Texas’s ERCOT is a province-wide event in Alberta.

A new set of rules

AESO is proactively addressing the risks associated with the rapid, high-volume power consumption of modern data centres, particularly those running AI workloads. The draft rules are a blueprint for how to integrate these massive loads safely.

The core requirements include:

➤ Capped Ramping: Ramping speed is limited to 10 MW per minute. This forces the computational workload to align with the grid’s physical constraints, not the other way around.

➤ Mandatory Ride-Through: Data centres must remain connected during significant grid disturbances, such as voltage sags and frequency swings. As Dlzar puts it: “In practice: data centres must survive faults that would trip an industrial site because dropping hundreds of MW instantly is worse than riding through.”

➤ Reactive Power Support: They are required to help maintain grid voltage by providing reactive power, a function traditionally handled by generation plants.

➤ Oscillation and Harmonic Limits: Strict limits are placed on power variability and electrical noise to prevent grid instability.

➤ Built-in Load Shedding: Data centres must have the capability to reduce their demand on command from the grid operator.

Dlzar summarises the shift perfectly:

This is the start of a new era. Programmable demand is no longer a silent passenger. It’s a grid actor, with obligations.

The official blueprint

The details are laid out in AESO’s draft document, “Connection Requirements for Transmission-Connected Data Centres,” which is open for stakeholder review. This is not a high-level policy paper; it is a deeply technical, engineering-level specification that treats the data centre as a complex electrical machine.

The document goes into exhaustive detail. For example, it mandates that data centres provide sophisticated project models, including phasor domain and electromagnetic transient (EMT) models, before they can connect. This is the same level of scrutiny applied to power plants. It also specifies precise ride-through capabilities for numerous scenarios, from low-voltage events lasting 0.15 seconds to frequency swings and rapid phase-angle jumps. These requirements force the data centre’s internal power infrastructure to be an active participant in grid stability, rather than a fragile load that trips offline at the first sign of trouble.

My takeaway

While these rules are for Alberta, the principles are universal and highly relevant for Europe. The explosive growth of AI and data processing means every grid operator will face this challenge sooner or later.

This proactive approach offers a clear path for grid operators like TenneT or local DSOs to consider. European regulations might present challenges to implementing such rules directly, but the concept is ripe for exploration in proof-of-concept projects.

Furthermore, this policy could positively affect the public debate surrounding data centres. By framing them as responsible grid partners with clear obligations, it moves the conversation away from them being just massive energy consumers to being integrated, flexible assets. This transparency and accountability are essential for gaining public acceptance.

A critical perspective is that these strict rules might inadvertently push data centres towards proprietary, off-grid generation to guarantee uptime. However, an alternative and more constructive view is that it encourages smarter on-site solutions. As some commenters on the original post noted, this could accelerate the adoption of technologies like DC microgrids within the data centre itself. These systems can use batteries and intelligent load management to smooth out their demand on the main grid, enhancing both their own resilience and the stability of the public infrastructure.

Ultimately, Alberta’s move is a necessary evolution. It acknowledges that in a modern, renewables-heavy grid, large consumers cannot remain passive. They must participate in maintaining the stability of the system they depend on.

GitHub's playbook for an AI-powered workforce

2025-08-25T00:00:00Z

GitHub has published a practical playbook detailing its internal strategy for building an AI-powered workforce. The document provides a clear framework for structuring organisational change around the adoption of artificial intelligence.

The core argument of the playbook is that successfully integrating AI is not a technology problem, but a change management challenge.

Their mistake is treating AI adoption as a technology problem when it is, in fact, a change management problem. Companies fail at AI adoption because they treat it like installing software when it’s actually rewiring how people work.

The playbook is built on a holistic system of eight mutually reinforcing pillars designed to create an ecosystem where AI fluency can thrive.

The eight pillars of AI enablement

This is a visually structured summary of the core components outlined in the playbook:

AI Advocates: A volunteer network of internal champions who scale adoption through peer-to-peer influence and feedback.
Clear policies and guardrails: Simple, tiered rules that empower employees to use AI confidently and responsibly.
Learning and development: An accessible ecosystem of curated training resources to build practical skills.
Data-driven metrics: A phased measurement framework to track adoption, engagement, and business impact.
Dedicated responsible individual (DRI): A central owner who orchestrates the programme and drives the overall strategy.
Executive support: Visible leadership commitment that provides strategic vision, investment, and clear communication.
Right-fit tooling: A portfolio of vetted first-party and third-party tools suited for various roles.
Communities of practice: Dedicated forums for peer-to-peer learning, knowledge sharing, and collaborative problem-solving.

The full document provides actionable steps for implementing each of these pillars. You can read the complete playbook on the GitHub Resources site.

My takeaway

This is a useful framework for structuring organisational change around AI. It is interesting to see how a tech-native company like GitHub approaches this.

The playbook’s emphasis on change management is particularly relevant for large, non-tech corporates. In these environments, the challenge is often less about the technology itself and more about getting everyone on board, addressing fears, and rewiring established ways of working. The principles outlined here provide a solid blueprint for that process.

MCP servers: less is more

2025-08-23T00:00:00Z

The AI development space is currently buzzing with talk of Model Context Protocol (MCP) servers, which promise to extend the capabilities of Large Language Models (LLMs). However, a recent article by Geoffrey Huntley, “too many model context protocol servers and LLM allocations on the dance floor”, serves as a critical reminder that this new frontier is not without its significant challenges.

Geoffrey argues that while the hype is immense, the foundational understanding of how MCPs affect LLM performance is dangerously low. His core thesis is simple: when it comes to context, less is more.

The hidden cost of context

The central problem Geoffrey identifies is the consumption of the LLM’s context window. Every tool and tool description from an installed MCP server is loaded into this window, effectively reducing the available space for your actual query and the model’s response.

He illustrates this with a stark example: a model with a 200k context window might only have 176k of usable space after the model’s own system prompt and the harness prompt are loaded. If a developer then installs a handful of popular MCP servers, this usable space can shrink dramatically, sometimes by more than 50%.

If your AGENTS.md, or Cursor rules are incredibly extensive, then you could find yourself operating with a headroom of 20k tokens and thus the quality of output is utter dogpoo.

This “context bloat” leads to several issues:

Degraded Performance: LLMs perform a “needle in a haystack” search. The more you allocate, the harder it is for the model to find the relevant information, resulting in lower-quality output.
Tool Conflicts: The MCP space currently lacks namespacing. If you have multiple tools that perform similar functions (e.g., listing files), the model’s behaviour becomes non-deterministic.
Inconsistent Tuning: Different LLM providers have different best practices for writing tool prompts. A tool tuned for an Anthropic model might perform poorly with a GPT model, and vice-versa.

Beyond performance, Geoffrey highlights a major security risk. This echoes concerns I recently covered in my post, “Simon Willison on the lethal trifecta and MCP security”, which discusses the dangers of combining private data access with untrusted content. Since there is no meaningful separation between system prompts, harness prompts, and tool prompts, a malicious tool could potentially execute harmful instructions.

Again, there is no name-spacing in the context window. If it’s in the context window, it is up for consideration and execution. There is no significant difference between the coding harness prompt, the model system prompt, and the tooling prompts. It’s all the same.

He points to a supply chain attack on Amazon’s Q assistant as a real-world example of this vulnerability. His recommendation for enterprises is clear: ban third-party MCPs and build your own, first-party tools to maintain control over the supply chain.

My takeaway

Geoffrey’s analysis confirms the feeling that the MCP ecosystem is currently the Wild West. The rush to add more tools and capabilities is happening without sufficient regard for the second-order effects of token consumption and security. The indiscriminate installation of MCP servers is akin to filling a small backpack with every tool imaginable, only to find you have no room left for food and water.

The key is to be deliberate. Before installing an MCP server, we should ask:

Is this functionality already achievable through a CLI that the model knows?
How many tokens will this server and its tools consume?
Have I vetted the source of this tool?

Ultimately, curating a small, trusted, and efficient set of tools will yield far better and safer results than collecting every available MCP server.

Popular MCP servers by the numbers

To provide some context on the landscape, here is a list of some of the most-starred MCP servers, based on data from Glama.ai. This illustrates the variety and popularity of tools currently available.

Server	Stars	Language	Description
PaddleOCR	52,748	Python	Multiple text-type recognition, handwriting recognition, and high-precision parsing.
Prisma	43,529	TypeScript	Manage Prisma Postgres databases with ease.
crewAI	35,854	Python	A framework for orchestrating role-playing, autonomous AI agents.
Context7	25,610	JavaScript	Fetches up-to-date, version-specific documentation and code examples.
GitHub MCP	21,218	Go	Official GitHub MCP server for repository interaction.
Repomix	18,620	TypeScript	Packages repositories into single files to reduce token usage.
Playwright MCP	17,368	TypeScript	Enables LLMs to interact with web pages through accessibility snapshots.

This list shows the significant developer interest in extending LLM capabilities, but as Geoffrey Huntley’s article makes clear, this power must be wielded with caution and a clear understanding of the trade-offs.

A modern toolkit for great Python projects

2025-08-21T00:00:00Z

I came across this excellent repository and accompanying article by Duarte Pompeu which outlines a modern and pragmatic approach to setting up Python projects in 2025. It serves as a great reference for establishing a consistent and efficient development workflow.

The fundamental principle of Duarte’s approach is the centralisation of all tool configurations within the pyproject.toml file. This simple strategy ensures consistency across different environments—from a developer’s local machine and IDE to the CI/CD pipeline.

If you work in a team, this means these tools will affect you and all your colleagues too! There are two possible outcomes: do it well, and everyone will have a smooth experience and appreciate the setup; do it wrong, and inconsistencies and errors will make it more painful than helpful.

The recommended toolkit

The setup is built around a small set of fast and effective tools:

Package Management (uv): For managing dependencies and virtual environments. uv is recommended for its exceptional speed and for providing a reliable, all-in-one solution that simplifies previous complex setups involving tools like poetry, pyenv, and pipx.
Formatting (ruff format): ruff is used for code formatting, providing consistency similar to black but with better performance. It is paired with reorder-python-imports to manage imports in a way that minimises git conflicts.
Linting (ruff check): ruff is also used for linting, replacing flake8 with a faster tool that offers hundreds of rules and auto-fixing capabilities. It can detect a wide range of potential errors, from unused imports to security vulnerabilities.
Testing (pytest): pytest remains the tool of choice for its ergonomic syntax and advanced features like fixtures and parametrized tests, making testing more efficient and maintainable.

Centralised configuration in practice

By defining rules in pyproject.toml, you ensure that running a command like uv run ruff check behaves identically everywhere. The repository provides a clear example configuration.

[tool.ruff]
target-version="py313"

include = ["src/ **.py", "tests/** .py"]
exclude= ["src/before.py"]

lint.select = [
  "B",    # bugbear:    potential bugs
  "F",    # pyflakes:   potential errors
  "S",    # bandit:     security issues
  "UP",   # pyupgrade:  upgrade syntax for newer versions
  "PERF", # perflint:   performance anti-patterns
]

[tool.pytest.ini_options]
pythonpath = ["."]
testpaths = ["./tests"]

My take

I find this approach very practical and it aligns with what I have seen work effectively in team environments. I am a strong proponent of using pre-commit to integrate these checks directly into the development workflow.

As Duarte also suggests in his Q&A, using pre-commit with language: system hooks ensures that the same tool versions and configurations defined in pyproject.toml are used. This creates a tight feedback loop.

The benefit is most apparent when working on code destined for cloud platforms. A CI/CD pipeline can take several minutes to provide feedback. Catching formatting, linting, or even basic security errors locally with a pre-commit hook is significantly faster and more efficient. It enforces consistency across the team before code is ever pushed.

What are the most profitable uses of ChatGPT?

2025-08-20T00:00:00Z

Simon Willison recently linked to a Reddit thread asking users for the most profitable things they have done with ChatGPT. The responses offer a overview, if anecdotal, showing how people are using these tools for practical, everyday value.

The definition of “profit” in these threads is broad. While some users report direct income, the more pervasive theme is using the tool to reclaim value—either by drastically cutting costs on professional services, automating time-consuming tasks, or gaining leverage in disputes. The tool effectively acts as an on-demand expert, a patient tutor, or an administrative assistant.

The responses generally fall into a few key categories.

Legal and contractual disputes

One of the most frequent applications is using the tool to understand and draft communication for legal or quasi-legal situations. It helps level the playing field against companies with dedicated legal teams.

Drafting letters to contest insurance claim denials.
Challenging unfair rental lease agreements or move-out fees by citing tenancy laws.
Negotiating with landlords over issues like a lack of heating by referencing building codes.
Getting out of unfair dismissal claims or securing unpaid bonuses.
Helping to write grant proposals that secure funding.

I asked ChatGPT to act as an insurance expert and legal advisor to draft a letter in response to an insurance claim denial. The insurance company offered me a few thousand dollars in response to my letter, which I didn’t expect.
— u/proofofcrisis

Professional and work efficiency

Many users leverage ChatGPT to augment their professional skills, automate tedious tasks, and advance their careers.

Writing VBA macros for Excel to automate data processing.
Drafting well-structured performance reviews to secure raises.
Helping to write and debug code, especially for unfamiliar languages or systems.
Creating entire business systems, like interconnecting a SaaS app with a legacy VoIP server, saving thousands in development costs.
Preparing for job interviews by role-playing questions and answers.

Turned a business around that was losing 15k/mo… The amount of all-nighters I spent with ChatGPT coming up with strategy still gives me nightmares 😩
— EnterLucidium

Personal finance and cost savings

A huge category of use is simple, direct cost avoidance through DIY projects and better negotiations.

Diagnosing and fixing household appliances like HVAC systems, garage doors, and ovens.
Troubleshooting car problems to avoid expensive mechanic visits.
Learning local electrical codes to perform home wiring projects, saving thousands on electricians.
Negotiating better prices on new cars by analysing fees and comparing offers.
Keeping swimming pools chemically balanced without a professional service.

Electrician wanted $6,000 to wire my sauna (long run through the attic, then down an exterior wall and underground for ~30ft). Chat helped me figure out the electrical code and I did it myself for $600 and passed inspection on first try.
— u/Nothing3561

Health and wellbeing

While risky if taken as gospel, many use AI as a first-line research tool for health issues, often leading to better outcomes.

Diagnosing conditions in pets and humans by providing symptoms, prompting a second opinion from a real doctor.
Identifying potentially harmful drug interactions that were missed by doctors or pharmacies.
Acting as a “trauma dump” or a therapy tool for self-reflection and emotional processing.
Creating personalised workout and nutrition plans.

It hasn’t paid me in cash yet, but it’s paid me in growth. Using ChatGPT for self-development has sharpened my emotional awareness and helped me process what I feel. I use it as a catalyst, not a crutch.
— First-Chemistry4075

Entrepreneurship and side hustles

For those building something new, ChatGPT serves as a co-founder, assistant, and creative partner.

Building and launching iOS apps or SaaS websites with little to no prior coding knowledge.
Writing and self-publishing textbooks or e-books.
Generating business ideas and developing marketing strategies.
Creating storyboards and scripts for creative projects.

Learning and self-development

The tool is widely used as a personal tutor to acquire new skills or understand complex topics.

Studying for professional certifications and university degrees.
Learning to code, invest, or perform complex data analysis.
Understanding personal finance concepts like setting up an IRA.
Helping to manage ADHD by creating schedules and organisational systems.

My takeaway

The overarching theme is one of empowerment. The tool gives individuals access to specialised knowledge that was previously hard or expensive to obtain. It acts as a powerful sparring partner for thinking through complex problems, whether that is a business strategy, a legal argument, or a DIY project.

At least part of the value seems to come from using it as an intelligent starting point. It can organise your thoughts, highlight what you do not know, and provide a structured path for further, more focused research. For many, it is a tool that reduces friction and provides the confidence to tackle challenges that would otherwise seem insurmountable.

Sources:

Thinking like a VC when evaluating a startup role

2025-08-19T00:00:00Z

I came across an interesting article by Irina Stanescu and Oana Olteanu on The Caring Techie that presents a valuable perspective on choosing a new job, particularly within the startup world. Their central idea is that joining a startup is a significant personal investment, and as such, it should be approached with the same level of scrutiny a venture capitalist (VC) would apply to a financial investment.

But joining a startup is a bet. You’re not writing a check. Instead, you’re putting in something harder to get back: your time, focus, energy, and reputation. Once those are spent, there’s no refund.

The authors propose a framework based on five key questions to guide this due diligence process.

A VC-inspired checklist for job seekers

The article breaks down the evaluation into five core areas:

Is this a market worth betting on? Before looking at the product or team, assess the market itself. Is it large and growing, or small and stagnant? A strong market can support even an average product, but a brilliant team will struggle in a declining market.
Can this team actually win? Evaluate the founders and early hires. Do they have complementary skills, domain expertise (founder-market fit), and a track record of shipping products? The team’s ability to execute is critical.
Is there a business behind the product? A cool product is not a business. The authors advise looking for evidence of a clear business model, customer demand (are people paying or willing to pay?), and a path to sustainable revenue. Is it a “painkiller” solving a real problem, or just a “vitamin”?
What’s the actual deal you’re getting? This involves understanding the financial offer beyond the base salary. What is the company’s valuation, and what percentage of equity are you being offered? Understanding the potential financial outcome is key to evaluating the risk-reward trade-off.
Is this the right move for you? Finally, the decision must align with your personal and career goals. Does the company’s stage match your risk tolerance? Will the role help you grow the skills you want to develop?

A European perspective

While the article has a distinct Silicon Valley feel, particularly regarding the emphasis on stock options, its core principles are universally applicable. In many parts of Europe, significant equity grants for non-founding employees are less common or have different tax implications, which can change the calculation for the fourth question.

However, the fundamental premise—that you are investing your most valuable, non-refundable asset: your time—remains entirely valid. The framework forces a structured, objective analysis that moves beyond the initial excitement of a polished website or an enthusiastic recruiter.

By asking these questions, you can build a more complete picture of the opportunity and make a decision based on conviction rather than just a gut feeling. The full article provides much more detail and is a recommended read for anyone considering a role at a startup.

Read the original article here: thecaringtechie.com.

On Simplicity in Software and System Design

2025-08-18T00:00:00Z

Sean Goedecke has written two posts that articulate a clear philosophy on design: simplicity and the deliberate elimination of complexity are marks of quality. This post summarises his main arguments and reflects on how they apply to wider architectural disciplines.

The ideas and concepts presented in the following summaries are entirely from Goedecke’s articles: “Great software design looks underwhelming” and “Everything I know about good system design”.

Great software design is underwhelming

Goedecke’s first article argues that great software design is not about using sophisticated features, but about proactively eliminating risk. Instead of reacting to potential failures, a good design removes the possibility of them occurring.

He outlines several methods for achieving this:

Protecting the hot paths: Moving slow or risky operations out of the direct user request-response cycle.
Removing components: Simplifying the architecture by using fewer parts.
Centralising state: Ensuring a single source of truth to prevent data inconsistency.
Using robust systems: Relying on battle-tested, simple technologies that are reliable due to their lack of sophistication.

Great software design looks simple because it eliminates as many failure modes as possible during the design stage. The best way to eliminate a failure mode is to not do something exciting (or if you can, not do anything at all).

Applying simplicity to system design

In the second article, Goedecke extends this philosophy from software (assembling code) to systems (assembling services). He states that complex systems are often a sign of poor design decisions being compensated for, not a mark of good engineering.

A complex system that works always evolves from a simple system that works. Beginning from scratch with a complex system is a really bad idea.

His practical advice for keeping systems robust includes:

Minimise stateful components: State is where things go wrong. Isolate it to as few services as possible.
Use databases wisely: Design clear schemas, use indexes correctly, and offload reads to replicas.
Use background jobs for slow operations: Keep user-facing requests fast by pushing heavy work into a queue.
Cache as little as possible: Caching introduces another form of state and should be a last resort.
Focus on the “hot paths”: Concentrate on the most critical and high-traffic parts of a system.

Broader architectural context

While Goedecke frames these principles for software and system design, they echo fundamental concepts in broader disciplines like Systems Engineering and enterprise architecture frameworks like TOGAF.

The core idea is about tailoring the approach to the problem. In Systems Engineering, a key practice is to determine the necessary level of detail and formality based on the project’s complexity and risk. Not every part of a formal process is needed for every project; knowing what to leave out is as important as knowing what to include. This aligns directly with Goedecke’s principle of avoiding unnecessary components and complexity. As noted by the Systems Engineering Body of Knowledge (SEBoK), principles are general rules that guide reasoning and conduct, not rigid instructions.

Similarly, with a framework like TOGAF, the value is not in dogmatically applying every step but in using it as a toolbox. A good architect selects the appropriate tools and defines the right level of detail required to meet the stakeholder’s goals. The objective is to create a useful, guiding architecture, not to produce documentation for its own sake.

Goedecke’s focus on simplicity is a practical application of this thinking. Whether designing a small software component or a large enterprise system, the goal remains the same: build a solution that is fit for purpose. This means resisting the urge to add complexity and instead focusing on creating a robust, simple, and maintainable system that meets the end goal. Less is often more.

Fixing the context window for LLM agents

2025-08-16T00:00:00Z

I recently came across an article by dbreunig.com, “How to Fix Your Context”, they neatly summarise several ideas on how to manage the context window for Large Language Model (LLM) agents. As models get ever-larger context windows, it is tempting to think we can just “throw it all in”. However, this approach often leads to degraded performance.

The article brings an information-management perspective to the problem, with some principles from the days before LLMs became mainstream. It all comes down to the saying: “Garbage in, garbage out.”

The problem with long contexts

The core issue is that every token in the context influences the model’s response. The article identifies four main ways this can go wrong, which can be summarised as follows:

Failure Mode	Description
Context Poisoning	An error or hallucination gets into the context and is repeatedly referenced.
Context Distraction	The context becomes so large that the model focuses too much on it, ignoring its training.
Context Confusion	Superfluous information in the context is used by the model to generate a low-quality response.
Context Clash	New information or tools added to the context conflict with existing information.

Six tactics for context management

To tackle these issues, the post outlines six key tactics for actively managing an agent’s context.

Every time a model ups the context window ante, a new “RAG is Dead” debate is born… But, as we covered last time: if you treat your context like a junk drawer, the junk will influence your response.

Tactic	Description
RAG	Selectively adding only relevant information to the prompt.
Tool Loadout	Applying RAG principles to select only the most relevant tool definitions.
Context Quarantine	Isolating different tasks into their own threads, each with a dedicated context.
Context Pruning	Actively removing irrelevant or unneeded information from the context.
Context Summarisation	Condensing the accrued context into a shorter summary.
Context Offloading	Using an external tool, like a scratchpad, to store notes outside the context.

A closer look at Provence

I was particularly interested in the “Context Pruning” tactic and the mention of a model called Provence. This isn’t just a simple filter. Provence is a specialised model trained to be an efficient and robust context pruner.

It works by framing the task as “sequence labeling”, where it learns to identify and keep only the relevant sentences in a body of text for a given query. What makes it particularly clever is that it can be unified with a reranker—a standard component in a RAG pipeline—which means it can prune the context with almost no additional computational cost. It is trained on diverse data, making it effective across different domains out-of-the-box.

A practical perspective on multi-agent systems

The idea of “Context Quarantine” is powerful, but it also highlights the biggest challenge in agent architecture. A recent post from Cognition AI, “Don’t Build Multi-Agents”, offers a strong, practical opinion on this.

The author argues that most multi-agent systems are fragile because they fail to share context effectively. If sub-agents work in isolation, their outputs can be based on conflicting assumptions, leading to poor results when the main agent tries to combine them.

Principle 1: Share context, and share full agent traces, not just individual messages.
Principle 2: Actions carry implicit decisions, and conflicting decisions carry bad results.

This perspective from Cognition AI does not contradict the tactics from dbreunig’s article; instead, it reinforces them. It serves as a real-world example of why disciplined context engineering is essential. Building agents that can truly work in parallel requires solving the difficult problem of cross-agent context passing, which remains a significant challenge.

Final thoughts

The key takeaway from these articles is that massive context windows are a powerful capability, but not an excuse for sloppy information management. The principles of RAG, pruning, and selective inclusion are still important. As the dbreunig article concludes, it is the job of the agent designer to be deliberate about what goes into the context.

The key insight across all the above tactics is that context is not free. Every token in the context influences the model’s behavior, for better or worse… As you build your next agent or optimize an existing one, ask yourself: Is everything in this context earning its keep?

Rethinking RAG with visual document analysis

2025-08-15T00:00:00Z

I recently came across an article from the company Morphik that details their approach to Retrieval-Augmented Generation (RAG). Instead of following the ‘regular’ path of parsing documents by extracting text, they treat each page as an image. This method sidesteps many of the common frustrations involved in processing complex documents with tables, charts, and intricate layouts.

The problem with traditional RAG pipelines is their fragility. Extracting text via OCR, detecting layouts, and chunking information intelligently are all steps where context can be lost. Morphik’s team came up with this question:

Why are we deconstructing these documents just to reconstruct meaning? What if we treated them the way humans do: as visual objects?

How it works

Their solution is built upon research like Google’s ColPali. The architecture treats each document page as a high-resolution image. This image is then divided into patches, and a Vision Transformer creates rich embeddings that capture both the textual and visual information in context. A language model then refines these embeddings to understand the overall structure.

When a user submits a query, the system uses a technique called “late interaction” to find relevant patches. It does not just look for keywords; it understands the spatial relationship between elements on the page. For example, it can connect the text “Q3 revenue” with a nearby chart showing an upward trend.

A comparison of a traditional, multi-step RAG pipeline versus the more direct visual approach. Source: Morphik Blog.

The performance claims are promising. On a challenging financial document benchmark, they report a significant accuracy advantage over other methods.

The results were striking: while other end-to-end providers peaked at around 67% accuracy… Morphik delivered 95.56% accuracy on the same evaluation set.

My thoughts on this approach

This is a innovative way to handle the messiness of real-world documents. For financial reports, technical manuals, and other visually rich materials, preserving the original layout is not just a convenience—it is essential for preserving meaning. This method seems particularly good for use cases where the visual context is as important as the text itself.

However, this approach also presents some interesting trade-offs. While it excels at understanding visual context, it might be less suitable for tasks that depend on the extraction of clean, reusable text. For example, workflows that require copying and pasting specific clauses from a legal document or exporting raw data from a table into a spreadsheet would still benefit from traditional text extraction.

Furthermore, a key consideration for any organisation is how this model handles 100% text-based documents or tasks requiring precise, literal string matching, such as finding a specific serial number. The value of this visual-first strategy is highest when the layout itself contains information. For a simple text file, the benefits are less obvious.

Overall, Morphik’s work is a great example of thinking differently to solve a persistent problem. It is a reminder that sometimes the most effective solution is the one that works with the nature of the information, rather than trying to force it into a different format.

Understanding the ecosystem of MBSE, SysML, and TOGAF

2025-08-14T00:00:00Z

My exploration of complex system development has led me to examine the relationship between several key frameworks and methodologies: Model-Based Systems Engineering (MBSE), the Systems Modeling Language (SysML), and The Open Group Architecture Framework (TOGAF). While it can be tempting to see them as a simple hierarchy, their interactions are more interconnected.

This post synthesises how these concepts fit together, not as layers in a stack, but as distinct, complementary functions within the broader challenge of managing complex systems.

Defining their distinct roles

The most effective way to understand these concepts is to see them as functions with different scopes, all operating within the same ecosystem.

Systems Engineering (SE) is the overarching discipline. It is the holistic, lifecycle-spanning process for managing the technical development of a system.
TOGAF provides the enterprise context. It is a framework that helps an organisation align its technology strategy with its business goals, guiding which systems should be built and how they fit together.
MBSE is a relatively new methodology for executing systems engineering. It is a specific way of doing SE that uses models instead of documents as the primary artefact.
SysML is the language used to implement the MBSE methodology. It provides the standard notation for creating the models.

Let’s break down each of these roles.

Systems engineering: The overarching discipline

As I explored in my previous posts on core SE concepts and the journey from design to disposal, systems engineering is the discipline that brings structure to complexity. It is a formal process that covers the entire system lifecycle, from defining needs and requirements to design, verification, operation, and retirement.

It is not a single layer but the entire project-level framework. The master plan for this effort is often captured in a Systems Engineering Management Plan (SEMP), which outlines all the technical activities required to deliver the system.

TOGAF: The enterprise context

TOGAF operates at the level above a single project. It helps an organisation answer strategic questions like, “What capabilities do we need to achieve our business objectives?” and “How should our portfolio of systems evolve to provide these capabilities?”

It provides the governance and architectural vision that ensures individual projects, each run using systems engineering principles, are not just successful in isolation but also contribute to the broader enterprise strategy. In essence, TOGAF sets the stage and defines the “why” for a project, while SE manages the “how” for that specific project.

MBSE: A modern approach to systems engineering

MBSE is not a separate discipline from SE; it is an evolution of it. Where traditional systems engineering often relied on a vast collection of documents (specifications, interface control documents, test plans), MBSE centralises this information into a single, interconnected digital model.

Adopting MBSE is more than implementing new tools; it’s about transforming your organization’s approach to systems engineering.
— specinnovations.com

It is a methodological choice. A team applies the discipline of systems engineering by using a model-based approach. This brings benefits like improved consistency, better change management, and clearer communication.

SysML: The language of MBSE

If you choose the MBSE methodology, you need a language to build your models. SysML is the industry standard for this. It provides a precise, graphical notation for defining a system’s structure, behaviour, requirements, and parameters. It is the technical tool that makes the MBSE methodology practical.

How they work together in practice

Imagine a large energy company wants to improve its grid management.

TOGAF (Enterprise Context): The enterprise architecture team uses TOGAF to analyse business drivers (e.g., renewable energy integration, cost reduction). They identify a need for a new, intelligent grid management system and define its high-level requirements and how it must interface with other enterprise systems.
Systems Engineering (The Discipline): A project is launched to build this new system. The project is governed by SE principles, documented in a SEMP. This plan outlines the entire lifecycle, including requirements management, design reviews (PDR, CDR), risk management, and its Verification and Validation (V&V) strategy. This strategy ensures the team continuously checks that they are building the system correctly (verification) and building the correct system that meets the user’s needs (validation).
MBSE (The Methodology): The project team decides to use an MBSE approach to manage the system’s complexity. Instead of writing a multitude of separate documents, they will build a comprehensive system model.
SysML (The Language): The engineers use SysML to create the model in a tool like Cameo or Enterprise Architect. They use SysML diagrams to capture stakeholder requirements, define the system’s architecture, model its behaviour, and trace everything from end to end.

Benefits of a model-based approach

Choosing to implement SE principles via an MBSE methodology offers several advantages:

Improved Communication: A unified model becomes the single source of truth, breaking down silos between teams.
Reduced Risk and Cost: Virtual simulation allows engineers to identify design flaws early, before expensive physical prototypes are built.
Guaranteed Traceability: MBSE provides clear, end-to-end traceability from requirements through to design and testing.
Supports Sustainability: It allows for the optimisation of product design to reduce waste and improve resource efficiency.

In the end, everything connects back to the core discipline of systems engineering. As I have explored in my earlier posts, it provides the structured, lifecycle-focused approach needed to manage complexity. Frameworks like TOGAF and methodologies like MBSE, powered by languages such as SysML, represent the evolution of the systems engineering toolkit. They provide engineers with increasingly sophisticated capabilities to manage complexity with greater precision and clarity. As the systems we build become more interconnected and ambitious, the continuous improvement of our engineering tools is what allows us to tackle these challenges, ensuring we not only build the system right, but also build the right system.

A practical guide to MLOps with Databricks

2025-08-13T00:00:00Z

I recently came across this excellent free resource on MLOps with Databricks, and I am particularly proud that it comes from a great Dutch team. I have been following Maria Vechtomova and Başak Tuğçe Eskili of Marvelous MLOps for some time, and they are definitely very knowledgeable in this area.

This course is a great read if you want to get into the practical side of this topic. It is especially relevant as it focuses on Databricks, which provides useful but also very specific tooling for its platform.

My perspective on MLOps with Databricks

While this course is an excellent guide to the “Databricks way,” I believe it is important to approach any platform with a critical eye, especially with the goal of building a flexible, long-term MLOps strategy. My primary aim is always to avoid vendor lock-in and maintain a platform-agnostic mindset where possible.

From that viewpoint, here are some challenges and considerations when implementing MLOps on Databricks:

Portability and Reusability: Databricks-native components like Databricks Asset Bundles (DABs) are powerful for managing deployments within the ecosystem. However, they are not as portable as universal standards like Docker containers. This can make migrating workflows or parts of the stack to other platforms in the future more difficult.
Limited Customisation: The convenience of managed services like Model Serving comes with trade-offs. You have less control over the underlying environment, such as specific OS-level dependencies or fine-tuning the web server. This can be a limitation for complex models with unique requirements.
Integrated vs. External Tooling: The platform’s monitoring capabilities are well-integrated but can feel like a walled garden. For a comprehensive observability strategy, it is crucial that monitoring data and alerts can be easily exported to external, best-of-breed systems (like Grafana, Prometheus, or Datadog) without significant effort.
Cost Complexity: The Databricks pricing model, based on DBUs (Databricks Units), can be complex to forecast and control. While powerful, features like serverless compute, auto-scaling clusters, and multiple specialised services can lead to unexpected costs if not governed carefully.
Learning Curve: Although Databricks simplifies many aspects of big data and ML, its ecosystem is vast and has a steep learning curve. Concepts like Unity Catalog, workspace management, and its specific Spark optimisations require significant investment to master.

Despite these considerations, the deep integration of open-source tools like MLflow is a major strength. It provides a solid, open foundation for model tracking and management that adds value both inside and outside the Databricks platform.

Course overview

The MLOps with Databricks course is a comprehensive 10-lecture series that provides a hands-on guide to end-to-end machine learning operations.

Full Course Repository on GitHub

What makes this course particularly valuable is its focus on practical implementation over theory, using the Marvel Characters dataset to build a complete MLOps pipeline.

Key technologies covered include:

Databricks Lakehouse Platform
MLflow for experiment tracking and model registry
Unity Catalog for governance
Databricks Asset Bundles (DAB) for CI/CD
Lakehouse Monitoring for production model oversight

Lecture summary

Lecture	Title & Link	Key Focus
1	Introduction to MLOps	Foundational concepts, the distinction from DevOps, and an overview of the MLOps tool landscape.
2	Developing on Databricks	Moving beyond notebooks to production-grade software engineering practices and local development setups.
3	Getting Started with MLflow	The core components of MLflow: tracking experiments, runs, parameters, metrics, and artifacts.
4	Logging and Registering Models	Bridging training and deployment by logging models, defining signatures, and using the model registry.
5	Model Serving Architectures	A conceptual overview of different deployment patterns: batch, real-time, and hybrid architectures.
6	Deploying Model Serving Endpoint	A practical guide to deploying models as REST APIs, including A/B testing implementations.
7	Databricks Asset Bundles	Using declarative YAML (DABs) for infrastructure-as-code to package and deploy ML workflows.
8	CI/CD and Deployment Strategies	Automating the path to production with Git flow, GitHub Actions, and security best practices.
9	Introduction to ML Monitoring	The “why” of monitoring: understanding data drift, concept drift, and monitoring architecture.
10	Implementing Model Monitoring	A complete implementation of a monitoring system using inference tables and Lakehouse Monitoring.

Beyond keys: The rise of semantic and prefix caching for LLMs

2025-08-12T00:00:00Z

Caching is a fundamental concept in system design. At its core, it involves storing frequently accessed data in a temporary, high-speed storage layer that sits between the user and the primary data source, like a database. The goal is simple: improve performance by serving requests from this fast local store, avoiding slower network calls and database operations. When a request for data is made for the first time, it results in a “cache miss,” and the data is fetched from the database and stored in the cache. Subsequent identical requests result in a “cache hit,” where the data is served directly from the cache, leading to significantly faster response times.

A simplified view of how a cache intercepts requests to reduce database load and improve response times. Source: GeeksforGeeks

This traditional model, where a cache hit relies on an identical request, works perfectly for predictable queries. However, the game changes with Large Language Models (LLMs). I came across an article from Raul Junco in System Design Classroom that clearly articulates this challenge. He points out that in AI systems, users often ask for the same information using different phrasing. For example:

“What is semantic caching?”
“Can you explain how semantic caching works?”
“Tell me about caching based on meaning.”

All three questions seek the same answer, but to a traditional cache, they are entirely different strings. The result is a cache miss every time, triggering a new, costly call to the LLM for a response you have likely already generated. As Junco’s article puts it:

Caching by key doesn’t work when your users speak in meaning.

This is where new, more intelligent caching methods become essential.

A new approach: Semantic caching with Redis 8

Junco’s article focuses on the new capabilities in Redis 8, which aim to solve this problem at the application/data-layer by understanding the meaning behind a query, not just its literal text. This is achieved through a combination of new features:

Vector Sets: Redis can now natively store and search vectors. This allows it to find prompts that are “close” in meaning by comparing their vector embeddings, without needing a separate vector database.
LangCache: This is a managed semantic cache built on Redis. It takes an incoming prompt, creates an embedding, and searches the cache for vectors of previous prompts that are semantically similar. If a close match is found, it returns the cached response, skipping the LLM call entirely.
Redis Flex: To make storing vast amounts of cached data affordable, Redis Flex uses a hybrid memory model. It keeps “hot” data in RAM for speed and offloads less-used “warm” data to more economical SSD storage.

This approach moves caching from a simple key-match to a more powerful meaning-match, directly addressing the issue of varied user phrasing.

The incumbents’ approach: Prefix caching

While Redis tackles this at the application layer, major AI providers like OpenAI and Anthropic (Claude) have implemented their own form of caching at the API level. Their method is best described as prefix caching.

Instead of understanding semantics, their systems identify and cache the static, initial parts of a prompt. This is particularly effective for applications that repeatedly send large, unchanging blocks of text, such as a detailed system prompt, few-shot examples, or context from a RAG system.

Anthropic (Claude): Provides explicit control via a cache_control parameter in the API call. You mark which parts of the prompt are static (e.g., a system message or a large document), and Claude caches them. Subsequent calls only need to process the new, dynamic parts of the prompt, saving on token costs and reducing latency. You can find the details in their prompt caching documentation.
OpenAI: Implements this automatically for prompts over 1024 tokens. It hashes the beginning of a prompt and routes requests with the same hash to a server that has that prefix cached. While automatic, it offers less direct control than Claude’s method. More details are in their prompt caching guide.

Comparison: Semantic vs. prefix caching

These two strategies solve related but distinct problems. Semantic caching is user-focused, while prefix caching is developer-focused. Here is a breakdown of the differences:

Feature	Redis (Semantic Caching)	Claude & OpenAI (Prefix Caching)
Core Mechanism	Vector similarity search on prompt embeddings.	Exact match of the initial, static part (prefix) of a prompt.
Solves For	Varied user phrasing for the same intent.	Repetitive, large static contexts (e.g., system prompts, RAG).
Implementation	Application-layer service (e.g., Redis Cloud).	Built directly into the LLM provider’s API.
Control	Granular control over similarity thresholds, TTLs, etc.	API-level control (explicit in Claude, automatic in OpenAI).
Flexibility	High. Understands meaning, independent of exact wording.	Low. Requires the prefix to be 100% identical.
Primary Benefit	Reduces redundant calls from semantically similar user inputs.	Reduces token processing for large, developer-defined contexts.

Why this matters

The evolution of caching for AI systems is a big step towards making them more efficient, scalable, and affordable. The quote from Junco’s article is a powerful summary:

Every LLM call you make that could’ve been a cache hit is tech debt you’re paying in real time.

Semantic caching, like the solution from Redis, represents a fundamental shift. It addresses the inherent ambiguity of natural language. Prefix caching, on the other hand, is a pragmatic and powerful optimisation for common development patterns like RAG.

They are not mutually exclusive. A truly optimised system will likely use both: prefix caching at the API level to handle static system instructions and document context, and semantic caching at the application level to handle the diversity of user queries. This layered approach seems to be the most logical path forward for building robust and cost-effective AI applications.

Onboarding AI with READMEs and quality gates

2025-08-11T00:00:00Z

In my last post on structuring AI-assisted development, I explored the idea of creating rulebooks to steer AI coding tools. While this is a powerful technique, I have sometimes struggled to get consistent, high-quality results from AI agents. The process can still feel like it requires constant supervision.

A recent article by Fuzzy Computer, “Onboarding for coding agents”, offers a practical solution that reframes the problem. Instead of focusing solely on instructing the AI, it proposes structuring the project environment so that the AI can self-correct. The core idea is simple but effective: use universal documentation for context and automated tools for constraints.

This approach creates a system that is not only beneficial for AI agents but also for any human developer joining the project.

The two pillars of the system

The article proposes a clear, two-part strategy for managing AI collaboration, moving away from tool-specific configuration files like CLAUDE.md or .cursor/rules towards a more universal setup.

1. Onboarding with READMEs

The first pillar is to treat every AI session like onboarding a new team member. Instead of putting project context into proprietary files, place it in a series of README.md files, a format every developer already understands.

Ask yourself: if a new software engineer or designer joined this project tomorrow, what would you want them to read before they start on their first task? That’s the type of context you should put in READMEs.

The article suggests a simple naming convention to keep this context modular:

README.md: The high-level project overview.
README.architecture.md: Explains the application structure, data flow, and key patterns.
README.commands.md: Lists key development scripts and commands.
README.design.md: Details the design system and visual guidelines.
README.testing.md: Outlines testing strategies and patterns.

This way, the CLAUDE.md file shrinks to a simple instruction list, telling the AI to read all relevant README files at the start of a session.

2. Quality gates

The second pillar is to enforce rules through the environment itself, not through text-based instructions. These are called “Quality Gates”—automated checks that must pass before the AI’s work is considered complete.

This works well because LLMs are terrible at formatting whitespace or sorting imports and Tailwind classes consistently, or ensuring every React hook’s dependency array is correct. But they’re good at running tools and fixing errors until all checks pass.

The article uses TypeScript as example, for a Python project we can make something similar:

ruff format . (Code formatting)
ruff check . (Linting rules)
mypy . (Static type checking)
pytest (Unit and integration tests)

By instructing the AI to run these checks and fix any errors until they all pass, you delegate the tedious work to the machine while ensuring the output meets your project’s quality standards.

Giving the software an OODA loop

This “Quality Gates” pattern is effective because modern AI models can now operate in a feedback loop. The article connects this to the OODA loop, a decision-making model from military strategy.

The OODA loop, developed by John Boyd. Source: Wikipedia.

Wikipedia describes the OODA loop as follows:

The OODA loop (observe, orient, decide, act) is a decision-making model developed by United States Air Force Colonel John Boyd. […] The approach explains how agility can overcome raw power in dealing with human opponents. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly and/or more effectively than an opponent, can thereby get inside the opponent’s decision cycle and gain the advantage.

When an AI agent writes code that fails a linting check (Observe), it analyses the error (Orient), determines a fix (Decide), and rewrites the code (Act). It repeats this cycle until all gates pass, effectively giving the development process its own primitive OODA loop.

An evolution of steering

This approach feels like a natural evolution from the concepts in my previous post. Where “vibe coding” with rulebooks is about actively steering the AI with prompts, this method is about building a self-correcting environment. It shifts the focus from micromanagement to system design. The developer defines the “laws of physics”—the tech stack, architecture, and quality standards—and the AI operates within that well-defined world.

I plan to implement this system in my own projects. The dual benefit is what makes it so appealing: it creates clear, modular documentation that serves both human developers and our new AI assistants, making the entire development process more robust and efficient.

Simon Willison on the lethal trifecta and MCP security

2025-08-09T00:00:00Z

Simon Willison has published another excellent piece on the persistent security challenges in the world of AI, based on his recent talk at the Bay Area AI Security Meetup. You can find his full annotated presentation here.

He revisits the concept of prompt injection and expands on what he calls the “lethal trifecta”—a combination of capabilities that makes AI agents vulnerable to data theft.

The lethal trifecta of capabilities is:
Access to your private data
Exposure to untrusted content
The ability to externally communicate in a way that could be used to steal your data

When an AI agent combines these three features, it can become a target for attackers who can trick it into accessing private information and sending it to them.

Simon argues that many common mitigations, such as using an AI to scan for malicious prompts, are insufficient. He makes a point about the standards we should demand:

… in application security, 99% is a failing grade! Imagine if our SQL injection protection failed 1% of the time.

This highlights a point that I find particularly frustrating: the security responsibility being placed on the end user. Most people are not aware of these risks. They are often just keen to experiment with the latest technology, and in doing so, can inadvertently create security holes. In my own company, we use Microsoft Copilot. While it offers clear benefits, it also introduces risks that need to be balanced with proper education—something that is often lacking. With the current lack of robust security standards for LLMs, it feels like we are simply waiting for the next security incident to happen.

This new post is a great follow-up to the ideas I summarised previously in “Security risks in LLM agents: Simon Willison’s insights”, where I first covered the lethal trifecta. It is worrying to see how fundamental these challenges remain. Simon’s critique of the Model Context Protocol (MCP) for outsourcing these critical security decisions to users is good. We need better-designed systems, not just better-informed users.

A periodic table for system design

2025-08-08T00:00:00Z

I came across a project on GitHub by Joy Arulraj that presents a “periodic table” of system design principles. The goal is to create a shared vocabulary for concepts that recur across different domains in computer science, such as databases, operating systems, and distributed systems.

The paper argues that different fields often use their own terminology for the same underlying ideas. As Arulraj notes:

For newcomers, it can be challenging to spot connections across different domains due to the diversity of traditions and vocabularies: the same design principle may appear in different guises across domains.

This project attempts to solve this by distilling over 100 influential papers into a structured table of more than 40 design principles, grouped into themes like Structure, Efficiency, and Reliability.

A systems engineering viewpoint

From a systems engineering perspective, the effort to create a common language is valuable. A core part of systems engineering education focuses on structured design, defining system boundaries, understanding interfaces, and performing trade-off analyses. This table provides a vocabulary for these activities.

For example, a trade-off analysis often involves balancing principles from different groups in the table. One might need to relax consistency (Cr) to improve scalability (Sc), or choose between a generalised design (Gr) and a common-case specialisation (Cc). Having these principles explicitly named helps in articulating design decisions.

The methodology for selecting principles is also logical, requiring them to be abstract (implementation-independent) and general (applicable across domains).

Applying the principles effectively

To get the most value from this resource, it is helpful to consider how to apply it. While the abbreviations offer a concise shorthand, they do introduce a learning curve. Taking the time to become familiar with the definitions is key to using the vocabulary fluently in discussions.

The table’s greatest strength is as a vocabulary for articulating design trade-offs, rather than as a prescriptive checklist. Approaching it as a checklist could inadvertently lead to over-engineering, which would contradict the foundational principle of Simplicity (Si). The author rightly notes this in the paper, positioning it as a vocabulary to aid discussion.

Within the list, certain principles stand out as universally applicable starting points for any project. Concepts like Simplicity (Si), Modularity (Mo), and Policy/Mechanism Separation (Pm) are not just items on a list but core tenets of sound engineering that help manage complexity from the beginning.

The full project and the paper are available on GitHub: A Periodic Table of System Design Principles.

A deeper look at AI's impact through the SPACE framework

2025-08-07T00:00:00Z

A short while ago, I posted about different frameworks for measuring developer productivity, including the holistic SPACE framework. I recently came across an article from Research-Driven Engineering Leadership that provides a great real-world application of this model: RDEL #104: How does the SPACE framework apply to AI’s impact on engineering?.

The article summarises a detailed study that surveyed over 500 developers to understand how AI tools are changing their work. The findings confirm what many of us might suspect, but it is valuable to see it backed by data.

Key findings from the research

The study shows that AI adoption is widespread, with 75% of developers reporting regular use. For those who use AI, the benefits are clear across most dimensions of the SPACE framework:

Activity & Efficiency: 88% of users reported improved task throughput, and 82% felt their efficiency had increased.
Performance: 71% believe AI helps them deliver more customer or business value.
Satisfaction: 62% reported higher job satisfaction since using AI tools.

The research highlights that AI excels at handling repetitive work, freeing up developers to focus on more complex challenges. As some participants noted in the full paper:

“It takes care of so much tedious work!” “I’m still stuck solving all the hard problems”

The nuance of collaboration

A more nuanced story emerges around the Collaboration dimension. Fewer than half of the developers (48%) agreed that AI improved their ability to collaborate, with a significant portion remaining neutral.

However, the qualitative interviews in the study revealed that AI is not hindering collaboration but changing its nature. Developers are less likely to interrupt colleagues with simple coding questions, as they can turn to an AI assistant first. This reduces low-value interruptions and shifts team conversations towards higher-value topics like architecture and brainstorming.

The critical role of team culture

The research also underscores a critical factor that goes beyond the tool itself: team and organisational culture. Developers in organisations that actively support AI adoption are seven times more likely to use it daily.

This reinforces a key point from the research paper: when AI adoption is high within a team, individuals perceive greater benefits for both the team and themselves.

“Developers on teams with higher AI adoption don’t just rate their team as more productive—they also report stronger personal agreement that AI makes themselves more productive.”

This suggests that shared learning, best practices, and a supportive environment are essential for maximising the benefits of AI. It is not just about providing a tool, but about a culture where it can be used effectively. This study provides valuable evidence for why a multi-dimensional framework like SPACE is necessary to understand the true impact of a technology like AI.

A practical framework for trusting your gut

2025-08-06T00:00:00Z

In business, we often talk about the balance between data-driven decisions and relying on gut feeling. While numbers provide a solid foundation, intuition plays a crucial role that is difficult to quantify. I came across this excellent article by Phil McKinney, which provides a practical way to structure this process.

Systematically investigating your gut feeling.

In his post, “The $200M Gut Check That Taught Me Intuition Isn’t Magic”, McKinney shares two contrasting personal stories: one where he dismissed Twitter’s potential and another where his intuition saved his company from a $200 million bad acquisition. The difference, he argues, was not luck but the application of what he now calls the ‘Practical Thinking Framework’.

He posits that what we call ‘gut feeling’ is often our brain detecting inconsistencies between the official story and the underlying reality. The key is not to follow that feeling blindly but to use it as a trigger for a systematic investigation.

Most innovation failures happen because people address the stated situation rather than the real situation.

The framework consists of three steps:

Reality Recognition: See the situation for what it actually is, not what it is presented to be.
Experience Application: Use your specific knowledge and past experiences, not generic best practices.
Stakeholder Psychology Reading: Decode what people truly want, need, and fear, versus what they claim they need.

McKinney’s core argument is that good judgment does not come from having better intuition, but from having a better system to analyse it.

The leaders with amazing judgment haven’t been blessed with superior gut feelings—they’ve systematised them.

My take

What I find particularly valuable here is the idea that intuition should not be an endpoint, but a starting point for investigation. The framework provides the ‘how’—a structured way to validate that feeling, which is much more robust than either blindly trusting a hunch or ignoring it completely. It turns a vague feeling into a starting point for a practical analysis. This is a great bookmark for anyone who needs to make (high-stakes) decisions and wants to integrate their experience and intuition in a more structured way.

An oral history of how ChatGPT disrupted the field of NLP

2025-08-05T00:00:00Z

This oral history from Quanta Magazine documents the disruption in the Natural Language Processing (NLP) field. When I first entered data science, NLP was a distinct specialisation. The colleagues I knew in that area were highly intelligent and research-focused, so reading about their collective experience with this shift is a useful reference.

The article, When ChatGPT Broke an Entire Field: An Oral History, uses interviews with researchers to tell the story of the NLP community’s journey from the introduction of the Transformer architecture to the release of ChatGPT.

Key moments in the timeline

The article outlines a clear progression of events that reshaped the field:

2017: The “Attention Is All You Need” paper introduces the Transformer architecture, though its full impact was not immediately recognised.
2018: Google’s open-source model, BERT, begins to shatter performance records on NLP tasks, leading to a “benchmark boom”.
2020: OpenAI releases GPT-3. Its scale and capability to perform complex tasks with simple prompts was a shock to many researchers, leading to what one described as a “career-existential crisis”.
2020-2022: Debates intensify around model “understanding” and the ethics of scale, exemplified by the influential “Stochastic Parrots” paper.
November 2022: The public launch of ChatGPT acts as a “Chicxulub” moment, making many existing NLP research problems obsolete overnight.
2023-Present: The field reorients completely. NLP is largely absorbed into the broader AI landscape, with a focus on prompting, evaluation, and building foundational models.

Summary of the disruption

The release of GPT-3 in 2020 was the first major shock. As one professor noted, tasks that once formed the basis of a five-year PhD could suddenly be replicated in a month.

I’m trying out all the things that my recent Ph.D. students had done as their dissertations, and just realizing — oh my God, the thing that had taken a student five years? Seems like I could reproduce that in a month.
— Christopher Callison-Burch, University of Pennsylvania

The public launch of ChatGPT was the final, decisive event. It effectively ended entire categories of academic research.

In a day, a lot of the problems that a large percentage of researchers were working on — they just disappeared.
— Iz Beltagy, Allen Institute for AI

The aftermath has been a complete reorientation of the field, with researchers grappling with obsolete work, intense media attention, and a new reality driven by corporate-funded, large-scale AI.

The article effectively documents the human and professional consequences of rapid technological change. It confirms my early impression of the field being full of deep thinkers, and it is notable to see them navigate a revolution they helped create.

If you achieve so much, you also have to accept that the debates are going to be heated. How else could it be?
— Christopher Potts, Stanford University

A practical guide to setting company policies

2025-08-04T00:00:00Z

I came across an article on the Stay SaaSy blog about the important, and often delicate, task of setting company policies.

You can read the full piece here: Setting Startup Policies.

What I particularly appreciate is its clear perspective, which applies not just to startups but to any company. It covers the entire lifecycle of a policy, from its birth to its eventual dead. The author frames policy-setting as a core executive function and provides a set of practical rules to follow.

The article makes several valuable points, which I have summarised below:

Treat policies like products. A policy needs to be well-designed to avoid unintended consequences. This involves using existing solutions as a starting point, getting wide feedback before release, and rolling them out progressively.
The best way to ensure that your policies make sense from top to bottom is to treat them like products.
Ensure full transparency. Secret exceptions or loopholes erode trust quickly. The author suggests an “all hands test”: if you would be nervous explaining the entire policy, including its exceptions, to the whole company, it needs to be rethought.
Do not punish good behaviour. Policies should never create a situation where following the rules puts someone at a disadvantage. For example, a “use-it-or-lose-it” budget can punish teams that are fiscally responsible.
Allow for evolution. The people most affected by a policy must have a way to influence its change. A policy should not become a fixed rule that harms one group to benefit another.
Use them sparingly. Creating policies can be a form of false productivity. It adds friction and can slow people down. Healthy organisations focus on pruning and automating rules that are no longer needed.
Many teams confuse creating policies with adding value – one of the most toxic mistakes that an organization can allow.

Helpful post for setting guardrails effectively.

Leadership co-processing with LLMs

2025-08-03T00:00:00Z

In the rapidly evolving landscape of AI, it is refreshing to see perspectives on Large Language Models (LLMs) that go beyond coding assistance or virtual companionship. James Stanier, in his post for The Engineering Manager, provides a look at how leaders can use LLMs as a “co-processor” to enhance their thinking and decision-making.

He frames the core idea as follows:

Effectively, I now think of LLMs as a co-processor for my brain. It isn’t always correct or even trustworthy, but in practice it always puts momentum behind my thinking, and often helps me to see things from a different perspective.

Stanier outlines several practical techniques for integrating LLMs into leadership workflows:

Prompting: Using simple prompts to inject momentum into problem-solving and overcome the initial friction of a blank page.
Pair Prompting: A collaborative method where two people use an LLM as a third member of the team to work through a problem, documenting the entire thought process.
Deep Research: Leveraging the LLM as a research assistant to explore topics in depth, saving significant time.
Contrarian Thinking: Employing the LLM to challenge assumptions and identify personal biases, leading to more robust decisions.
The Executive Assistant: Using the LLM to prioritise tasks and structure the day, especially during busy periods.
The Coach and Sounding Board: A way to process thoughts and reactions to complex situations in a structured, two-way dialogue.

This perspective is valuable because it focuses on augmenting, not replacing, human thought. I particularly liked the concept of “pair prompting,” where the tool facilitates a richer, documented collaboration between two people.

Pair prompting is just like pair programming, but with an LLM as the third member of the team. The idea is that you and your partner can use the LLM to help you both think through a problem together, and it can help you to see things from a different perspective.

In my day-to-day work, I also use LLMs for many non-coding tasks. Beyond basic grammar and spelling checks, I use them to navigate complex situations. By using pre-set prompts based on principles like those from Michael Pilarczyk, I can more quickly find a path to a decisive, well-considered action.

Of course, it is crucial to remain critical. An LLM does not have the full context of a situation, nor to all of your thougths and ideas, so its output must be adapted and validated against your specific circumstances.

The full article by James Stanier offers more detail and example prompts. You can read it on his Substack: Leadership co-processing with LLMs.

Experimenting with Kilo Code and the Model Context Protocol

2025-08-02T00:00:00Z

For the past couple of weeks, I have been experimenting with AI-assisted coding tools. After trying Cursor, I started looking into Kilo Code, an open-source alternative that plugs into VS Code. My main motivation was to gain more flexibility, specifically the ability to experiment with models of my own choosing, like the Kimi K2 model from Moonshot via OpenRouter.

Kilo Code accelerates development with AI-driven code generation and task automation. This open source extension plugs directly into VS Code.

My initial impressions are positive. I particularly like the ease with which you can change the rules for the AI and the availability of different modes, such as the ‘Architect’ mode, which adapts the AI’s persona for specific tasks.

The challenge with the Model Context Protocol

However, I ran into a snag while trying to set up the Playwright Model Context Protocol (MCP) to allow the AI to control a web browser. The Playwright documentation suggested a simple ‘add to cursor’ button, but this did not work as expected within Kilo Code. I could see in the logs that the server was spinning up correctly, but Kilo Code itself could not connect. It took some digging to realise the server was being initiated in the context of my main editor, not within Kilo Code’s environment.

The solution was in the Kilo Code documentation, which provided a Windows-specific configuration for running MCP servers directly. Adapting the example was the key to getting it working:

{
  "mcpServers": {
    "playwright": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@playwright/mcp@latest"
      ]
    }
  }
}

With the setup now working correctly, I am experimenting with a project to build a reverse hotel search: you select a room, and it finds the availability. It is still a work in progress, but it is a fun way to explore the capabilities of these new tools.

This hands-on experience of configuring tools and setting up protocols is a practical follow-up to my previous thoughts on structuring AI-assisted development. Having the right rules and configurations in place is essential to move beyond simple ‘vibe coding’ and into a more deliberate and powerful workflow.

Putting the developer at the centre of platform engineering

2025-08-01T00:00:00Z

I came across an article on the Stack Overflow blog, “Building better platforms with continuous discovery”, which offers a tangible and practical perspective on platform engineering. It argues for adopting a product management practice—continuous discovery—to ensure platform teams build tools that developers, their customers, actually need and use.

The core idea is to treat internal engineers as customers and to understand their workflows and pain points before building solutions. This prevents teams from creating tools that, while technically sound, do not get adopted because they solve the wrong problem. As the article states:

When discovery is missing, platform work starts to drift from its real purpose, which is empowering engineers to deploy working software faster and with confidence.

While the article provides a strong framework, it is a bit light on the specific methods used to gather this continuous feedback from engineers. However, the central principle of placing the developer at the heart of the process is a valuable one, especially in larger corporate environments where platform teams can become disconnected from the developers they serve.

This approach is a practical next step to the ideas I explored in my post on “From platform engineering to platform democracy”. Where platform democracy describes the ‘what’—a more collaborative and flexible platform model—continuous discovery provides the ‘how’. It is the mechanism through which developers can contribute to and shape the platform, ensuring it meets their evolving needs.

It also connects well with the mindset of moving quickly, which I discussed in “The cost of being wrong”. By maintaining a tight feedback loop with developers, platform teams can iterate with more confidence. They can test assumptions early and often, reducing the risk of building the wrong thing for months on end. This aligns perfectly with the article’s conclusion:

Shipping fast is great. Shipping right is better. Discovery helps us do both.

Ultimately, continuous discovery is a useful framework for ensuring platform engineering delivers on its primary promise: helping developers ship valuable software more effectively.

Women as technology

2025-07-31T00:00:00Z

Today I visited an interesting exhibition at the Design Museum Den Bosch called ‘Vrouwen als technologie’ (Women as Technology). It provides a powerful perspective on how women’s roles in technology have been shaped, and often marginalised, over time.

It is quite sad to see how this marginalisation persists. For example, the film industry cemented the image of the “computer nerd” as a man, while in the early days of computing, it was often women who operated the large IBM machines. It was thought they could work with more focus and precision for longer periods, a skill deemed essential for operating both early computers and complex machinery like textile looms. This shift from operator to a male-dominated field is a recurring theme.

A woman operating an early IBM computer. Women were often hired for these roles due to their perceived ability to concentrate for long periods. Image source: Braythwayt.com

The exhibition shows that technology is rarely neutral; it reflects the prevailing societal views of its time. It explores this through four key, and sometimes problematic, roles assigned to women.

Some roles of women in technology

The museum organises its narrative around four themes: women as calculators, homemakers, incubators, and lust machines.

Calculators and assistants
This section reminded me of how the first computers were marketed. The computing power of early machines in the 1940s was sometimes measured in “girl-hours”. When the work became more valued, it symbolically became more ‘masculine’. We see this today with virtual assistants like Siri and Alexa, which are given female names and voices by default, reinforcing the idea of women in service roles.

Incubators
The exhibition also touches on more confronting topics, such as how medical technology has been designed by men for women. There are some gruesome stories. The design of the first incubator (couveuse in Dutch) treated the womb as a kind of industrial machine, reducing a natural process to a mechanical one. An 1875 papier-mâché model of a uterus, presented completely isolated from the woman herself, is an example of this detached, clinical view.

Lust machines
The objectification continues with modern technology. AI robots and chatbots are often modelled on Western ideals of female beauty. It is telling that among the most popular applications for some large language models are chats with fictional female characters. The exhibition features a hyper-realistic sex robot from RealDoll, which highlights how technology is used to fulfil male desires.

The exhibition is rightly called Women as technology: not only because women are often reduced to machines, but also because they are interwoven with technology – as a driving force, as a critical consumer and as a brilliant designer. In short: as infinitely more than the smiling users of household appliances and secret vibrators.
— Doortje Lenders, Vrij Nederland

The themes feel particularly relevant today. With major societal shifts like the reversal of Roe v. Wade in the United States and the growing online popularity of the ‘trad wife’ movement, it seems we are reinforcing some of the very stereotypes this exhibition critiques.

This exhibition does an excellent job of showing the ambivalent relationship between women and technology. It reveals how technology has both shaped and been shaped by these roles, but it also highlights the important contributions women have made and continue to make in the fields of computing, medicine, and design. It is a valuable perspective.

The bitter lesson for organisations

2025-07-30T00:00:00Z

I read another great piece by Ethan Mollick titled “The Bitter Lesson versus The Garbage Can”. He presents two compelling concepts that are on a collision course.

First is the “Garbage Can Model” of organisations. This theory suggests that most companies are not the well-oiled machines we imagine. Instead, they are chaotic collections of problems, solutions, and people, where processes are often undocumented, informal, and evolved rather than designed. As Mollick shares from one case study:

The CEO, after being walked through the map, sat down, put his head on the table, and said, “This is even more fucked up than I imagined.”

Second is “The Bitter Lesson” from the world of AI research. Coined by computer scientist Richard Sutton, it observes that attempts to build AI by encoding complex human knowledge are consistently beaten by general methods that leverage massive computational power. The AI simply figures out a better way on its own through brute force.

…encoding human understanding into an AI tends to be worse than just letting the AI figure out how to solve the problem, and adding enough computing power until it can do it better than any human.

The core conflict

The central question Mollick raises is whether this Bitter Lesson will apply to our messy, “Garbage Can” organisations. Will we soon have AI agents that we can simply give an outcome—like “produce the weekly sales report”—and they will figure out how to navigate the internal chaos to deliver it, rendering our carefully crafted processes obsolete?

This seems logical. An AI trained on outcomes could find more efficient paths than the ones humans have created through habit and negotiation. It suggests a future where understanding how work gets done is less important than clearly defining what a successful output looks like.

Where humans remain essential

This leads to an interesting question: if AI can optimise processes through brute force, where does that leave human expertise and historical knowledge? I believe our value shifts to areas that computation alone cannot address.

Defining ‘good’: An AI can achieve a target, but a human must define it. For qualitative goals like “excellent customer service” or “a positive company culture,” human judgment is needed to set the parameters of success.
Handling ambiguity and ethics: Business is not as clear-cut as a chess game. Humans are required to navigate situations with conflicting goals, ethical grey areas, and incomplete information. An AI might find the most efficient way to a sale, but a human must ensure it is not a manipulative or brand-damaging one.
Asking the right questions (first principles): An AI is exceptional at solving a problem it is given. Humans, however, are capable of questioning if we are solving the right problem in the first place. This first-principles thinking, which redefines the entire challenge, is a uniquely human form of innovation.
Understanding ‘why’ (Chesterton’s Fence): Many seemingly inefficient processes exist for good, unwritten reasons—to maintain relationships, ensure legal compliance, or manage team morale. Humans provide the wisdom to understand why a fence was built before tearing it down, preventing unforeseen consequences.

The future is not about AI replacing human processes wholesale. It is about a partnership where we use our uniquely human skills to direct the immense power of AI. We will set the destination, define the rules of the road, and let the AI find the best route.

The cost of being wrong

2025-07-29T00:00:00Z

I love this kind of perspective. As a deep thinker, I sometimes find myself analysing a decision to the point of paralysis. This article by Jack Vanlightly, “The Cost of Being Wrong”, offers a helpful perspective.

The core idea is that the cost of being wrong shapes how we make decisions. In science or civil engineering, mistakes can be catastrophic and set progress back years. In software, however, the cost of failure is often remarkably low. We can roll back a deployment, fix a bug, or pivot on an architectural choice without bringing down a bridge.

Vanlightly quotes a post that captures this idea perfectly:

“Real founders? They make the wrong decision at 9am. Fix it by noon. Ship by 5. Coward founders are still scheduling the kickoff meeting. Your job isn’t to be liked. Your job is to be clear. Wrong but decisive beats right but timid… every single time.”

This freedom to experiment and course-correct is one of the best parts of working in technology. Instead of agonising over finding the perfect, irreversible solution, we should embrace our ability to iterate.

As Vanlightly concludes:

“So if you sometimes struggle with decision making, as I myself have done, just remember that software decisions are not irreversible, they do not have to be perfect.”

It is a good and simple reminder. I recommend reading the full article for his complete analysis.

A refreshing, back-to-basics approach to coding with AI

2025-07-28T00:00:00Z

I came across an article by Salvatore Sanfilippo (antirez) titled “Coding with LLMs in the summer of 2025”. I find his perspective on using Large Language Models (LLMs) in development quite refreshing because it feels like a return to first principles.

Antirez argues that while frontier models like Gemini 2.5 Pro are incredibly powerful, their best use is as a direct extension of the programmer, not as an autonomous agent. The goal is not to have the AI do the work for you, but to amplify your own capabilities. He sees the ideal partnership as a “human+LLM equation” where the developer remains firmly in control.

I strongly believe the maximum quality of work is reached using the human+LLM equation.

His approach is about maximising the effectiveness of this partnership by providing the LLM with extensive, high-quality context—the entire codebase, relevant documentation, and a “brain dump” of your own thoughts and goals.

Retaining control: no agents allowed

The most distinct part of his argument is the deliberate rejection of integrated agents and tools that automate the interaction with the LLM. He advocates for a more manual, explicit process: copying and pasting code from your terminal directly into a LLM’s interface and back again.

His reasoning is that this keeps the developer in the loop at all times. You are forced to see, review, and understand every piece of information the LLM receives and every suggestion it provides. This prevents the model from making decisions based on incomplete or incorrect context, which is a common failure point for many integrated tools.

You must be in control of what the LLM can see when providing a reply.

By acting as the manual interface, you ensure you are still the coder, just an augmented one. You retain a complete understanding of the code and its design, which is essential for building high-quality, robust software.

A different perspective on developer augmentation

This view provides an interesting contrast to the “vibe coding” approach I wrote about recently in “The last hurrah of human coding”, which relies on integrated tools like Cursor to structure the AI’s workflow.

While Alex MacCaw’s method uses rules and scaffolds to rein in the AI within an editor, antirez’s method achieves control by stepping outside the editor entirely. It is a more purist approach, ensuring nothing happens without the developer’s explicit action.

Both philosophies agree on the most important point: the developer’s experience, taste, and architectural judgment are irreplaceable. The debate is simply about the best interface for applying that judgment. Antirez’s method feels particularly suited for deep, foundational work where absolute clarity and control are needed. It is a reminder that sometimes, the most effective tools are the ones that keep us most engaged.

People, principles, process, then product

2025-07-26T00:00:00Z

In his post, “People > Principles > Process > Product”, Mike Fisher makes a case for the order in which leaders should focus their efforts. He argues that while the natural tendency is to jump straight into fixing or improving the product, this approach is backwards.

Despite this being most of our natural proclivity, I think it’s backwards. The order in which we should focus is people, principles, process, and then product.

Fisher suggests that true, sustainable success comes from building a solid foundation. This starts with getting the right people on the team and fostering trust. Next, you establish the principles that guide decision-making and define the culture. With those in place, you can create the processes that enable smooth, repeatable execution. Only then, he argues, should the focus shift to the product, which becomes the natural outcome of a well-functioning team.

I find this a clear and valuable way to think about delivering a product, whether as a team, department or an entire company. It particularly applies after a reorganisation, when realignment is critical. You might have the same people, but you still need to align on the new principles and processes.

I have seen what happens when you skip these steps. When principles are not well-established, people are left without clear guidance. They often revert to their old ways of working, which may have been effective in a previous structure but are not suited for the new one. They simply do not know any better because the new guiding principles and processes have not been properly established.

In the end, great products are the byproduct of great teams, clear values, and thoughtful execution. That’s why the product comes last, because when everything else is working, it’s the natural outcome.

Skipping a step or getting the order wrong makes progress difficult. Fisher’s framework confirms that the sequence is effective for building products.

Networking for people who do not network

2025-07-25T00:00:00Z

I am not a natural networker, so I was glad to find this practical breakdown on the topic. While I recognise the benefits, it is an area where I would like to grow. The article from Stay SaaSy, “Networking For People Who Don’t Network”, offers some excellent, down-to-earth advice.

They compare networking to working out: a small, consistent effort can yield significant benefits.

The #1 missed opportunity in networking is failing to take the achingly simple steps to build a network from people you work with every day.

A summary of their heuristics

Here is a scannable summary of their main points:

Start with your coworkers: This is your most accessible and high-quality network. Be competent, a good teammate, and positive.
It is a numbers game: Meet many people without the pressure of making every connection a deep one.
Find what works for you: Choose events you genuinely enjoy, whether that is small dinners or specific meetups, rather than forcing yourself into environments you dislike.
Nurture your network: A simple “thinking of you” message or a semi-regular in-person meeting keeps relationships alive.
Do not act weird: Avoid common pitfalls like asking someone to be your mentor on the first meeting or bragging.

I also found this point about workplace positivity very true:

Winners are inspired by ambition and shared victories, and complaining is pretty much the polar opposite.

Stay SaaSy has many other great posts, so their site is worth exploring. They also publish a newsletter on Substack.

Aligned autonomy: from military strategy to engineering teams

2025-07-24T00:00:00Z

I came across an interesting article in the Stack Overflow newsletter, “Building stronger engineering teams with aligned autonomy”, which discusses a leadership philosophy for empowering teams. The core idea is to give teams the freedom to make decisions independently (autonomy) while ensuring those decisions support the company’s broader goals (alignment).

The article describes this as offering “freedom within a framework, where engineers understand the why behind their work but have the space to figure out the how.” This approach relies on three key components:

A clear north star: A guiding, long-term objective.
Feedback loops: Systems to measure impact and course-correct.
Guardrails, not gates: Clear boundaries that define acceptable decisions without halting progress.

This concept immediately struck me as familiar, as it closely mirrors a fundamental doctrine used in military organisations like the U.S. Marine Corps and the Army: Mission Command.

The military parallel: mission command

In the military, the success of any operation hinges on achieving the mission objective. Mission Command is a command philosophy that empowers subordinate leaders to execute mission orders with disciplined initiative. A commander provides their “Intent”—a clear and concise statement of the purpose of the operation and the desired end state.

This Commander’s Intent explains the what and the why, but it deliberately does not specify the how. It is then up to the individual unit leaders on the ground to determine the best way to achieve that objective based on the real-time situation they face. Completing the mission is paramount, and this decentralised execution allows for speed, adaptability, and resilience in a chaotic environment.

A direct comparison

The parallels between “aligned autonomy” and “mission command” are striking. The concepts map almost directly onto each other:

The “North Star” in business is the military’s “Commander’s Intent”. It defines the purpose and desired outcome.
“Guardrails” are the business equivalent of “Rules of Engagement”. They set the non-negotiable limits for action.
“Team Autonomy” mirrors the military’s “Disciplined Initiative”. It is the freedom to decide how to achieve the mission within the given constraints.

The Stack Overflow article states that leaders must shift from “giving directions to providing context.” This is the essence of Mission Command. A leader’s primary job is to ensure everyone understands the strategic context so they can make effective independent decisions. As the article puts it:

Leaders who want to build a culture of aligned autonomy need to undergo a mental shift: from giving directions to providing context. That means sharing the why but not dictating the what or how.

Whether on the battlefield or in a business, this principle creates highly effective organisations. This approach particularly appeals to me because it focuses on clear goals and efficient execution, without unnecessary fuss. It is not a new management trend but a time-tested leadership philosophy for achieving complex goals in dynamic environments. It proves that when you give talented people a clear purpose and the trust to execute—using or creating standard practices to get there—they will deliver remarkable results.

What makes a principal engineer different from a senior?

2025-07-23T00:00:00Z

I recently watched an insightful video featuring Steve Hume, who spent 17 years as a Principal Engineer at Amazon. He shared a great deal about the company’s engineering culture, but what I found most interesting was his breakdown of the Principal Engineer role. It is not just the next step on the ladder; it is a leap into a different, and often more challenging, type of work.

The role is not about being the best coder; it is about navigating ambiguity and wielding influence, often with significant trade-offs.

The leap from senior to principal

At many companies, the path from Senior to a role like Staff or Principal is a linear progression. At Amazon, the path is deliberately different. They largely omit the “Staff Engineer” level, creating a huge step between Senior (L6) and Principal (L7). Hume notes the promotion is incredibly difficult, with thousands of Senior Engineers competing for a few hundred Principal roles.

A Senior Engineer at Amazon is a force within their team. They are expected to deliver complex projects and, crucially, own their services end-to-end. As Hume puts it, “At Amazon, you don’t just build it—you’ll be paged at 3 AM when it breaks in production.” They lead through influence and documentation within their domain, but they cannot command other teams to do work. Their autonomy is bounded by their team’s scope.

The Principal role is a fundamental shift in three key areas.

1. From solving problems to defining the problem space

This is the most critical differentiator. A Senior Engineer solves a given problem. A Principal Engineer is given a vague business objective and must first define the problem itself, and then expand the entire menu of possible solutions.

When a VP says, “Improve availability for our NFL streams,” the Principal’s job is not to start optimising code. It is to ask:

Should we re-architect the service?
Should we buy a third-party solution?
Should we reallocate engineers from a lower-priority team to this problem?
Is this even the right problem to solve to achieve the business goal?

They might even decide to kill a project if it is not the highest-impact work. This is about strategic leverage, not just technical execution.

2. Autonomy with high-stakes accountability

The role is not about “freedom from micromanagement.” It is about being thrust into ambiguity with high-stakes accountability. As Hume says, “A VP tells you the direction, not the steps.”

A Principal is expected to take that vague directive and deliver a transformative solution without hand-holding. The other side is that if they fail, the consequence is not a performance improvement plan; it is a loss of trust from senior leadership. The feedback would be, “This is not what I expected from a Principal.” That is a career-limiting outcome.

3. Influence over authority: The paradox of belonging

Hume describes the Principal experience with a compelling phrase: “You belong everywhere and nowhere.”

This is not just about floating between teams; it is a significant psychological and political challenge. Principals operate in the gaps, which means they are constantly having to rebuild context in new domains. They often face friction from teams who may resent an “outsider” parachuting in to give advice.

Because they have no direct authority, they must lead entirely through influence. They work with teams by challenging assumptions, connecting people to avoid duplicated work, and using data and well-structured arguments (like the ‘six-pagers’) to build consensus. They act as guides and guardrails, not commanders. This status also leads to extreme bandwidth challenges, forcing them to prioritise ruthlessly, often at the expense of hands-on coding.

How this compares to our own expert roles

This analysis makes the comparison to my own company’s structure much sharper. We have technical experts who are the highest authority within a specific domain. This model prioritises depth. Our experts have deep, long-term context and ownership, which is invaluable for core business areas.

Amazon’s model is structurally different and deliberately so. By avoiding domain-aligned Principals, they force them to develop breadth. Their value comes from identifying and solving systemic, cross-organisational problems that no single team can see or solve.

The trade-off is clear. Our model builds world-class specialists but may struggle to address issues that span multiple domains. Amazon’s model is designed to fix those systemic issues but means its Principals may lack the deep, focused expertise that our roles cultivate. Neither is inherently better, but they are optimised for different goals.

The video was an interesting look into a role defined by its trade-offs: influence over hands-on coding, breadth over depth, and autonomy at the cost of extreme accountability.

You can watch the full video here: What is a Principal Engineer at Amazon? With Steve Huynh.

Roger Martin on going on the offensive with creative strategy

2025-07-22T00:00:00Z

I recently came across an interesting article by Roger Martin, “Going on the Offensive with Creative Strategy,” which questions a foundational principle of modern business. His argument is a direct challenge to the way many of us, myself included, have been taught to approach new ideas.

The core argument

Martin posits that the business world is dominated by “analytics”—executives who believe that the future can be accurately predicted by rigorously analysing data from the past. On the other side are the “creatives”—the innovators and designers trying to build something new.

The problem arises when creatives are forced to justify their new ideas using the analytics’ framework. They are asked to prove future success with historical data, which is an impossible task for something that has never existed before. As Martin notes, this is a game creatives are destined to lose.

Creatives have a strong tendency to attempt to defend their ideas while implicitly or explicitly accepting the dominant premise.

Creativity versus analytics: a battle of methodologies.

The flaw in the analytical premise

Martin argues that this reliance on historical data is fundamentally flawed, a point made centuries ago by thinkers like Aristotle and Charles Sanders Peirce. Aristotle pointed out that data analysis is only useful if we are certain the future will be identical to the past—a rare occurrence in business. Peirce went further, stating that no truly new idea has ever been proven analytically in advance.

When analytics ask creatives to prove a new idea in advance analytically, they are asking the creatives to do something that has never been done in the history of the world — good luck with that!

This creates an environment where forecasting becomes a comforting illusion rather than a useful tool for genuine innovation.

It is the great pacifier of modern business — revenue forecasting makes analytics feel good, even if it provides no more value than popping a pacifier in a baby’s mouth.

A critical reflection

Martin’s argument made me reflect on my own work. I see a large reliance on trying to predict business outcomes based on past data, which is exactly what he criticises. It is important, however, to distinguish this from other types of prediction. For instance, in predictive maintenance, we are not forecasting unpredictable human behaviour in a market. Instead, we are predicting machine failure based on sensor data and physical principles. We can say, “We are 95% confident this machine will fail within the next 30 days.” This is a calculated probability within a more constrained system, allowing for informed operational decisions. It is fundamentally different from trying to forecast revenue for a product that does not exist yet.

Martin’s core point about business strategy remains valid and important. Truly great business ideas are rarely born from maintaining the status quo. Sticking to the proven path may yield marginal gains with some confidence, but it will not lead to breakthrough innovations. Look at a tool like the Cursor IDE; it was not created by marginally improving existing code editors but by fundamentally rethinking the developer workflow with AI at its core.

Why an offensive stance is better

To escape this trap, Martin urges creatives to stop defending their ideas on the analytics’ terms and instead go on the offensive. This means questioning the assumptions behind the status quo.

For Innovation in Modern Business, the only Defense is Offense.

Instead of trying to prove your new idea will work, challenge the assumption that the current model will continue to work indefinitely. This shifts the conversation from defending the unknown to comparing two possible futures: one based on a new idea and one based on the increasingly fragile assumption that nothing will change.

This “offensive” mindset is more powerful in general because it is proactive. It is about taking control of the narrative, setting the terms of the discussion, and actively shaping the future rather than passively reacting to the past. It is a shift from defence to creation.

Include your tests in coverage reports

2025-07-21T00:00:00Z

I recently came across this article by Ned Batchelder. He makes a case against the common practice of omitting test files from code coverage reports. I completely agree with him.

He argues that your tests are code too and should be scrutinised. Including them can help you find issues you might otherwise miss. Here are the main reasons why:

It helps detect simple errors, like accidentally duplicating a test by copy-pasting and forgetting to rename the function. The old test would be overwritten, but coverage would show the code as un-run.
It can identify unused helper code within your test suite. If a helper function or a specific clause is never executed, it is worth investigating why.
It provides a more complete picture of your codebase. While it might increase your overall coverage percentage, that is not a bad thing. You can always adjust your target percentage accordingly.

It is a small change in configuration that can provide valuable feedback on the quality of your test suite. You can read his full article for more details.

Lessons on building software quickly

2025-07-20T00:00:00Z

I recently came across an article by Evan Hahn titled “How I build software quickly”. It is a practical and down-to-earth read on a topic that is relevant to every developer: finding the right balance between speed and quality.

What I appreciate is that while Large Language Models (LLMs) are mentioned, the focus remains on foundational practices. It is a refreshing perspective that earns bonus points from me.

Evan covers several useful techniques, but a few, in particular, stood out to me.

Key takeaways

Fine-tuning requirements: One of the most effective ways to work faster is to do less. Evan makes a great point about questioning and softening requirements where possible. This strategic approach can prevent a lot of unnecessary work.
Building top to bottom: His advice to build “top to bottom” is very practical. He suggests starting with the user-facing part first to ensure the underlying logic serves the actual use case from the beginning.
Build the top layer first—the “dream code” I want to write or the API I wish existed—rather than trying to build the “bottom” layer first. It’s easier to make the right API decisions when I start with how it will be used.
Using a timer: The simple trick of setting a timer to stay focused is something I can relate to. It is an effective way to avoid getting “lost in the mud” and wandering through the codebase.
My estimates are frequently wrong, but when the timer goes off, I’m often jolted out of some silly distraction.
Extracting smaller changes: I also found the suggestion to extract smaller, self-contained changes (like a dependency update or a minor bug fix) into separate patches very useful. It simplifies reviews and makes the main task easier to manage.

The article contains many more valuable points, including the importance of rough drafts and making small, incremental changes. I highly recommend reading the full post on Evan Hahn’s website for a complete picture.

The Pragmatic Engineer 2025 survey

2025-07-19T00:00:00Z

I always appreciate articles like the annual survey from The Pragmatic Engineer. They provide a great overview of what is currently being used across the industry. It is a good way to get ideas about what other people are using and to discover tools you might not have heard of. After reading this year’s edition, I have definitely found one or two new tools that I am going to try out.

You can read the full, detailed survey here: The Pragmatic Engineer 2025 Survey.

Below are a few of my key takeaways.

The rise of AI and ‘vibe coding’ tools

It is no surprise that AI tools are prominent, but the speed of change is remarkable. While GitHub Copilot remains extremely popular, the survey shows that newer tools like Cursor are gaining ground very quickly. It is also interesting to see Claude closing the gap with ChatGPT.

The article also mentions several “vibe coding” tools, such as Vercel v0 and Bolt.new. These seem to be aimed at less technical audiences who want to create prototypes or mockups quickly. It confirms that there is a growing market for tools that assist non-developers in bringing ideas to life, which I guess makes a lot of sense.

A surprise in the IDE landscape

I was genuinely surprised to see how popular JetBrains’ suite of IDEs is. I had the impression they were a much smaller player in the market, but the survey data shows they are a strong competitor to Microsoft’s offerings like VS Code.

The most-loved and most-hated tools

One of the most hated tools is JIRA, by a large margin. The main complaints are that it is slow, complex, and cumbersome. On the other hand, tools like Linear, VS Code, and the JetBrains IDEs receive a lot of positive mentions. It seems that developers value speed and simplicity above all else.

Overall, the survey is a valuable snapshot of the current state of developer tooling. It is a great resource for anyone looking to understand current trends or discover new tools to improve their workflow.

Practical lessons from Meta on improving code

2025-07-18T00:00:00Z

Following on from my last post about the human cost of technical debt, it is clear that actively managing code quality is crucial for team morale and confidence. The next question is: how can we do this effectively?

The Research-Driven Engineering Leadership newsletter pointed me towards a research paper from Meta that details their systematic approach to improving a massive, rapidly evolving codebase. Their findings offer practical lessons for teams of any size.

At Meta, code improvement is not an afterthought. The research found that over 14% of all code changes were explicitly for improvement purposes. This is a significant investment and shows a deep commitment to maintainability.

Their approach is a mix of top-down strategic initiatives and bottom-up, organic work from individual engineers. What I is interesting is how they decide where to focus their efforts: it is based on data.

Practical lessons

The research highlights several key practices that we can adapt for our own teams.

1. Make improvement work visible and measurable

At Meta, improvement work is explicitly tagged. This prevents it from being invisible labour buried within feature development. By tracking this work, teams can understand how much effort is being dedicated to code health and recognise engineers for their contributions. We can do this with specific tags or task types in our project management tools.

2. Prioritise with data, not just intuition

The Meta teams use over 20 different criteria to prioritise which parts of the codebase to improve. This goes far beyond simply looking for “code smells.” Some of the most compelling criteria they use are:

Outage history: Files frequently associated with production issues are obvious candidates for improvement.
Authoring speed: They measure Diff Authoring Time (DAT). If it consistently takes a long time to make changes to a specific file, it is a sign of high complexity or poor design.
Knowledge loss: They track the percentage of changes made by developers who have since left the company. A high percentage indicates a knowledge silo and a potential risk, making that code a priority for refactoring and documentation.
Centrality: They analyse how interconnected a piece of code is. Improving central, highly-depended-on components has a much larger ripple effect across the system.

3. Foster a culture of continuous improvement

Meta’s “Better Engineering” initiative encourages teams to allocate 20-30% of their time to these projects. They support this with training, tooling, and even gamification elements like profile badges for deleting code or fixing high-priority issues.

While we might not need a company-wide gamification system, the principle is sound: create time and space for improvement, and actively recognise and reward the effort.

What this research from Meta demonstrates is that managing technical debt can be a mature engineering discipline. These practical, data-driven approaches are the antidote to the falling morale and reduced confidence discussed previously. By making improvement a visible, valued, and systematic part of work, we not only build better software but also foster healthier and more effective engineering teams.

A deeper dive into systems engineering: from design to disposal

2025-07-17T00:00:00Z

A short while ago, I wrote an overview of the core concepts of systems engineering, summarising the first half of the Introduction to Systems Engineering course I am taking. I have now completed the second half, and it has been just as valuable. This part of the course moves from the foundational ‘what’ to the practical ‘how’, covering the entire lifecycle from detailed design and production to operational use and eventual disposal.

This post synthesises the key ideas from these final modules. It covers the transition from a logical design to a physical product, the activities required to support a system in the real world, and the management disciplines needed to keep the entire process on track.

From blueprint to build

The first half of the course focused on defining the problem and establishing the system’s requirements (the ‘what’). The second half dives into creating the solution (the ‘how’). This journey is a structured progression from a high-level concept to a detailed, buildable design.

The process starts by decomposing the overall system into interconnected subsystems. For each subsystem, a critical decision must be made on how to acquire it. This is a trade-off between cost, schedule, risk, and performance.

Option	Description	pro	con
COTS	Commercial Off-the-Shelf	Low cost, low risk, immediate availability.	May be an imperfect fit for requirements.
MOTS	Modified Off-the-Shelf	A tailored solution built on a known base.	Modification adds risk, cost, and schedule delays.
Developmental	Built from scratch.	Potential for a “perfect” fit.	Highest risk, cost, and longest schedule.

A core activity throughout this phase is requirements traceability. Every feature in the design must trace back to an authorised requirement. This is the primary defence against ‘requirements creep’—the tendency for a system to become more complex than necessary.

For example, a team might build a fantastic, feature-rich air conditioner for a car, but if its extra weight and power consumption cause the car to fail its overall efficiency targets, the team has created a great subsystem but a failing system.

Backward traceability prevents this by forcing the question: “Which top-level requirement does this feature support?”

This design effort concludes with two major milestones that act as quality gates:

Preliminary Design Review (PDR): Confirms that the high-level design approach for each subsystem is sound before committing to the expensive detailed design phase.
Critical Design Review (CDR): The final gate before production. It confirms the detailed design is complete, correct, and ready for manufacturing.

The system in the wild

Once the design is approved at the CDR, the systems engineer’s role shifts from creation to oversight. The focus is on ensuring the system is built, operated, and supported correctly.

Production and construction

During this phase, the main activities are Verification and Configuration Audits. Verification is the process of confirming that the as-built system meets its specified requirements. This is not just testing; it involves a combination of methods:

Inspection: Looking at the system.
Analysis: Using calculations or certificates.
Demonstration: Showing it can perform a function.
Test: Using equipment to measure performance.

At the same time, a Physical Configuration Audit (PCA) is performed. This audit confirms that the system’s documentation perfectly matches the physical product. This must be done during construction, not after. For example, you confirm the exact location of a stormwater pipe in an open trench before it is buried. This creates an accurate record that is invaluable for future maintenance and modifications.

Utilisation and support

Once the system is operational, it requires ongoing support. This happens at different levels, from day-to-day operational tasks performed by the user to deeper engineering support for modifications and upgrades. Any modification is treated as a “mini” systems engineering project, requiring a formal process to avoid introducing new problems.

Disposal

Finally, every system has an end-of-life. Planning for disposal from the very beginning is a key part of modern systems engineering. This applies to software as well. Retiring a legacy enterprise system is not just about turning off a server. It involves a planned process of data migration to a new system, ensuring data integrity, and securely wiping sensitive customer information from old databases and backups to comply with privacy regulations like GDPR. Without a plan, companies risk data loss, security breaches, and legal penalties.

Managing the machine

Underpinning the entire lifecycle is a set of management disciplines that provide control and mitigate risk. Without them, complex projects can quickly descend into chaos.

The course highlighted four key areas:

Management Function	Purpose	Key Activities
Verification & Validation (V&V)	To prove we built the system right (Verification) and that we built the right system (Validation).	Planning and executing a progressive evaluation program, from component tests to final operational evaluation.
Configuration Management	To ensure the system’s configuration is known, accurate, and controlled at all times.	Identifying what is under control, tracking its status, managing changes formally, and auditing the process.
Technical Risk Management	To identify, assess, and treat risks that could cause the system to fail technically.	Assessing the likelihood and consequence of risks; treating them by avoiding, reducing, or transferring them.
Technical Reviews	To assess progress at logical points, detect errors early, and approve plans for the next phase.	Conducting formal reviews like the PDR and CDR to ensure readiness before proceeding.

All of these activities are documented in a Systems Engineering Management Plan (SEMP). This is the master plan for the entire technical effort, defining the strategies, processes, and resources for the project.

Final thoughts

This second half of the course provided a clear framework for how a system moves from an idea to a real-world entity and through to its eventual retirement. The emphasis on structured processes, continuous verification, and proactive management is a powerful lesson. It shows that systems engineering is not just a collection of technical tasks, but a holistic discipline for managing complexity and ensuring that what we build truly delivers lasting value.

Has self-service BI finally arrived with AI?

2025-07-16T00:00:00Z

I came across this article by Silvan Späti that explores how conversational AI, combined with the Model Context Protocol (MCP), might finally deliver on the long-standing promise of self-service Business Intelligence (BI).

The value for the end customer

The idea is powerful: instead of relying on developers or data analysts to build reports, business users could simply ask questions in natural language. For instance, an operations manager could ask, “Which of our wind turbines are underperforming against their contractual power curve for the last quarter?” and receive an immediate, data-backed answer. This direct interaction has the potential to dramatically speed up decision-making and empower teams to explore data on their own terms and time.

In my experience, end-users often consume data from a dashboard only to re-process it. They combine several numbers or present the information in a different way for their specific needs. This is where an LLM-based approach could be particularly beneficial, making it much easier to fine-tune queries and get the desired end result without manual work or overloading the dashboarding or development team.

A dose of healthy scepticism

However, I must admit I am still a bit sceptical. Will end-users truly adopt this workflow, or will they just keep asking the development team for help? The shift from being a passive consumer of dashboards to an active conversational partner with data is a significant behavioural change that should not be underestimated.

The real win

That said, the real value might lie in two key areas. First, the ability to communicate in natural language is a fundamental shift. It lowers the technical barrier significantly.

Second, and perhaps more importantly, is the ability to verify the output. The article explains how the system can show its work, including the queries it runs. This means you can fact-check the AI’s conclusions yourself, ensuring it is not hallucinating and that the insights are grounded in actual data. This builds trust, which is essential for adoption.

It makes data more accessible, results more tailored, and more verifiable. The combination of human expertise guiding a powerful, transparent AI tool could be where the true revolution lies.

Frameworks for measuring developer productivity

2025-07-15T00:00:00Z

Quantifying the impact of AI on software development can be a challenge. I came across two resources from DX that provide a structured approach: the DX AI Measurement Framework™ and the foundational DX Core 4.

The Core 4 addresses overall engineering health, while the AI framework focuses on the specific impact of AI tools. Here is a summary of their key indicators:

Framework	Dimension	Focus
DX Core 4	Speed	Measures PR throughput and perceived rate of delivery.
	Effectiveness	Assesses the developer experience (DXI) and time allocation.
	Quality	Tracks change failure rate and time to restore service.
	Business Impact	Connects engineering work to organisational goals.
AI Framework	Utilization	Tracks the adoption and active usage of AI tools.
	Impact	Measures direct time savings and indirect productivity gains.
	Cost	Monitors usage to identify high-ROI use cases and manage expenses.

The developer’s changing role

The articles offer an interesting perspective on the two ways the developer’s role is changing. First, existing developers will increasingly act as leads for teams of AI agents, shifting their focus to directing and overseeing automated systems.

Second, AI is lowering the barrier to entry for software creation. The articles note that roles like product managers, designers, and business analysts are now using AI to generate working software. This expands the definition of who a “developer” is within an organisation. Consequently, when applying metrics, it becomes important to distinguish between production-grade contributions and disposable, AI-generated prototypes to ensure the data is measured in the right context.

Other productivity frameworks

The DX framework is a useful model, but it is one of several in the landscape of developer productivity. Other well-known frameworks include:

DORA Metrics: Originating from the DevOps Research and Assessment (DORA) team at Google, these four metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service) are highly focused on the speed and stability of the software delivery process. They are used effectively for measuring the health of a CI/CD pipeline.
SPACE Framework: Developed by researchers from Microsoft and the University of Victoria, this is a more holistic model that covers five dimensions: Satisfaction & Well-being, Performance, Activity, Communication & Collaboration, and Efficiency & Flow. Its inclusion of developer satisfaction provides a human-centric balance to purely output-based metrics.

The DX Core 4 framework actually aims to encapsulate principles from both DORA and SPACE, creating a unified system. Understanding these different models provides a broader context for choosing the metrics that best fit an organisation’s specific goals.

The importance of starting early

Regardless of the framework chosen, the articles make a strong case for establishing baselines early. This can begin with self-reported data to get an initial understanding. It is critical to communicate that these metrics are for understanding tool effectiveness and guiding investment, not for individual performance reviews. This avoids gamification and helps ensure the data remains meaningful.

The state of software engineering with LLMs in 2025

2025-07-14T00:00:00Z

Gergely Orosz at The Pragmatic Engineer recently published an overview titled “Software engineering with LLMs in 2025: reality check”. The article provides a grounded look at how Large Language Models (LLMs) are being used in the industry today, moving beyond the hype to see what is actually working.

He covers the spectrum from AI startups dogfooding their own products to how Big Tech organisations are integrating these tools.

Corporate adoption and progress

The article highlights how companies like Google and Amazon are systematically integrating AI into their internal development workflows. Google has built AI features into its custom toolchain, from the Cider IDE to its Critique code review system. They are taking a cautious but steady approach, aiming to build trust with their engineers.

Amazon is heavily promoting its own tool, Amazon Q, and is seeing significant internal adoption of the Model Context Protocol (MCP). This protocol makes it trivial to turn internal APIs into servers that AI agents can interact with, automating tasks across different systems. This widespread adoption is a direct result of the “API-first” mandate Jeff Bezos instituted years ago.

The view from experienced engineers

For me, the most interesting part of the article was the perspective of seasoned software engineers. Many, like Armin Ronacher (creator of Flask), have shifted from being sceptical to becoming believers in the productivity gains offered by agentic AI tools. The sentiment is that models like Claude have become “shockingly good”.

This enthusiasm is shared by others, including Simon Willison, whose work I follow closely. The consensus is that we have reached an inflection point where these tools are no longer just toys but are fundamentally changing how we build software. Kent Beck, a creator of Extreme Programming, is quoted as saying he is “having more fun programming than I ever had in 52 years”. When engineers with decades of experience express this level of excitement, it is a clear signal that a significant shift is happening.

My own next steps with AI tools

Reading this has sharpened my own thinking and plans for the near future. I want to integrate these agentic tools more deeply into my workflow, especially those that connect directly with Git.

I have been using Cline in VS Code, and my experience has been mixed. Sometimes it works very well, but at other times it falls short. I plan to dedicate more time to mastering it, particularly its Git integration and the rule system. I also intend to experiment with Cursor, which looks very promising.

Perhaps the most significant next step for me is to improve my use of Test-Driven Development (TDD). The article reinforces the idea that agents work best when they have clear goals and feedback loops, and a solid test suite provides exactly that. An LLM can work against the tests to ensure its output complies with the requirements.

While I have experience writing tests in Python, I need to explore how to effectively apply this to static sites like this blog. It is a new area for me, and I am keen to learn how to get it working properly.

A time for experimentation

The key takeaway from Gergely’s article is that the landscape of what is “cheap” and “expensive” in software development has changed. It is time to experiment. The tools are maturing at an incredible pace, and I am excited to see how they will continue to evolve and enhance the way we create.

A simple trick for better dictation with AI

2025-07-13T00:00:00Z

I sometimes use dictation to capture thoughts or write texts, but the process can sometimes feel messy. It is easy to become hesitant, knowing that any mistake or forgotten detail will require manual correction later, which can disrupt the flow of ideas.

I recently read an article by Matt Webb that offers a simple and practical solution to this problem. He suggests creating a persona—in his case, ‘Diane’—to act as a virtual secretary. While dictating your thoughts, you can embed instructions directly to this persona.

For instance, you could say, “The main points are A and B. Diane, please format that as a bulleted list. The third point is C.”

This method separates your content from your commands, allowing you to correct yourself or format on the fly without interrupting your flow. The LLM can then process the transcript, executing the instructions addressed to ‘Diane’ and cleaning up the final text.

It is a very good idea from Matt. I have found this works well on Android using the dictation feature in the Microsoft Word app, resulting in a much cleaner and more usable output.

The human cost of technical debt

2025-07-12T00:00:00Z

Some time ago, I wrote about avoiding and reducing technical debt, where I explored Chelsea Troy’s concept of ‘maintenance load’. Her perspective frames technical debt not as abstract ‘bad code’, but as the concrete, ongoing effort required to keep software running. The focus was on practical strategies like improving documentation, testing, and empowering developers to streamline the codebase.

That post centred on the technical and process-related aspects of the problem. However, a recent article from the Research-Driven Engineering Leadership newsletter adds another dimension to this discussion: the human side.

The research highlighted in the article shows a direct link between technical debt and developer morale. It is not just about slowing down development cycles; it actively reduces developers’ confidence and makes them feel their progress is hindered.

This connects directly to the idea of ‘maintenance load’. When developers constantly battle a high maintenance load, they are the ones who experience the ‘wasted time’ the research mentions. This feeling of running in place, fixing the same types of issues, or struggling with poorly documented code is a significant drain on motivation.

These two perspectives reinforce each other. The solutions Chelsea Troy proposes—valuing documentation, empowering developers to refactor, and forcing features to earn their keep—are not just good technical practices. They are, in fact, immediately positively influencing the morale issues identified in the research. By giving developers the tools and time to reduce maintenance load, we directly improve their sense of progress and confidence.

This reinforces the idea that managing technical debt is a core leadership responsibility. It is not merely a technical chore to be relegated to a backlog. It is an ongoing investment in the health of our systems and in the well-being and productivity of teams. Addressing the technical side has a direct, positive impact on the human side.

From platform engineering to platform democracy

2025-07-11T00:00:00Z

In supporting software development teams the goal has always been to increase efficiency and reduce friction. A recent study and a couple of related articles have highlight a trend that builds on the foundations of DevOps and platform engineering.

The core problem: wasted developer time

A study conducted by the Enterprise Strategy Group (ESG) for Google Cloud, “Building Competitive Edge With Platform Engineering”, presents interesting statistics. As highlighted in an article by The New Stack, developers can waste up to 65% of their time on tasks that are not directly related to writing code. This includes managing tools, patching systems, and navigating infrastructure complexities—all tasks that platform engineering aims to solve.

This waste represents a huge loss of value. For every €100,000 invested in development, only €35,000 translates into new features and products. Platform engineering addresses this by providing a curated, self-service portal and patterns where developers have access to proven and maintained tools, freeing them to focus on their primary role.

This is a natural progression from the principles of DevOps, which I have discussed before in the context of DevOps for Data Science. While DevOps improved collaboration, it often does not scale well in organisations with more than 50 developers, creating a need for a more structured approach.

The next evolution: platform democracy

While platform engineering provides a “golden path” for developers, it can sometimes feel restrictive. Developers often have strong preferences for their tools, and a one-size-fits-all platform may not cover every team’s specific needs.

This is where the concept of “platform democracy” comes in, as explored in another article from The New Stack, “Beyond Platform Engineering: The Rise of Platform Democracy”. The idea is to evolve from a centrally controlled platform to a more collaborative model.

Daniel Bryant from Syntasso describes it as enabling “all the producers in your organization to [reconfigure and modify] the platform to fit their individual needs”. This means developers, security teams, and SREs can all contribute to the platform, shaping it collectively. It is a shift from a “my way or the highway” approach to a multiplayer mode where everyone participates.

The goal is to create a system that covers the common 80% of needs centrally, while allowing teams the flexibility to build the remaining 20% themselves in a supported and consistent way.

Key enablers of modern platforms

The Google/ESG research points to several key components that make these modern platforms successful:

Open source: 96% (!) of organisations use open source tools to build their platforms. This provides the customisability and community support needed for a democratic and flexible approach.
CI/CD tools: Continuous integration and deployment pipelines are considered essential. They are the engine that automates the delivery process, making the “golden paths” efficient and reliable.
Scalability: The platform must be able to scale to handle growing workloads and adapt to new requirements, such as the increasing integration of AI and machine learning.

A systems engineering perspective

From a systems engineering perspective, the “platform as a product” mindset is a direct application of lifecycle thinking. You analyse the needs of your users (developers), synthesise a solution (the platform), and evaluate its effectiveness with clear metrics (like deployment frequency or mean time to recovery).

Platform democracy is an adaptation of this model. It makes the “synthesise” and “evaluate” phases continuous and collaborative rather than top-down. It is a more agile, iterative approach to managing the system’s lifecycle, ensuring it adapts to the evolving needs of its users.

The journey from DevOps to platform engineering and now towards platform democracy is about one thing: empowering developers to deliver value more effectively. It is a strategic shift that recognises that the best platforms are not just built for developers, but also with them.

A practical LLM coding workflow and a reflection on teamwork

2025-07-10T00:00:00Z

I came across a post by Harper titled “My LLM codegen workflow atm” that offers a practical, hands-on look at using Large Language Models for software development. While it is already a few months old—a long time in the AI space—his core principles remain relevant.

He breaks his process down into two main paths.

For new (greenfield) projects

This is a structured, three-step approach that moves from idea to execution.

Idea honing: Use a conversational LLM to brainstorm and flesh out an idea, ending with a detailed developer specification.
Planning: Feed the specification to a reasoning model to create a detailed, step-by-step implementation plan, broken down into small, testable chunks.
Execution: Use a codegen tool like Aider or pair-programme with a model like Claude to work through the plan, step by step.

For existing projects

When working on an established codebase, the approach is more iterative and task-focused.

Get context: Use a tool to package the relevant parts of the codebase into a context file for the LLM. He mentions repomix, but another popular tool for this is gitingest.
Use specific prompts: Run targeted prompts against the context to perform tasks like generating a code review, identifying missing tests, or creating GitHub issues.

From solo-mode to multiplayer

What particularly caught my attention was Harper’s final point about the loneliness of this workflow.

My main complaint about these workflows is that it is largely a solo endeavor - i.e. the interfaces are all single player mode.

He notes that the tools are largely single-player, making it difficult to collaborate as a team. This connects directly to my previous post, “Beyond the vibe: structuring AI-assisted development”. I believe the “rulebook” or “constitution” approach we discussed there is the key to unlocking team-based, AI-assisted development.

By establishing a shared set of rules—whether in a CLAUDE.md, a .cursor/rules directory, or a similar system—we create a unified standard for how the AI should behave. This acts like a traditional linter or code style guide, but for AI collaboration. It ensures that every developer’s AI assistant is working from the same playbook, respecting the same architectural boundaries, and following the same coding conventions.

This transforms the process from a series of isolated “single-player” sessions into a coordinated “multiplayer” effort, where the AI becomes a consistent and predictable partner for the entire team.

How to use AI without damaging your thinking

2025-07-09T00:00:00Z

In his article “Against ‘Brain Damage’”, Ethan Mollick addresses the common fear that using AI will harm our ability to think. He argues that while AI does not cause literal brain damage, using it without intention can lead to outsourcing our thinking, which prevents learning and mental growth. The key is not if you use AI, but how you use it. When used as a shortcut to get answers, it hinders learning. However, when used with well-designed prompts and clear guidance, like an AI tutor that challenges you, it can greatly improve learning outcomes. The same principle applies to creativity and writing: do the thinking and drafting yourself first, then use AI as a tool to refine and expand upon your own ideas.

This is a very helpful post for me, as I interact a lot with LLMs. It is interesting to see that so much depends on how you prompt an LLM. I was also surprised to see that prompts created for older models (like GPT-4 from over a year ago) still work effectively today. I did not expect that, given the heavy development in this area.

For writing on this blog, my process aligns with Mollick’s advice. I first create a rough draft myself. Only after that do I ask an LLM to help fill in details and check my writing. The summary that begins each post is something I hardly ever write myself. I find an LLM is especially effective for that task, though I always guide it to highlight the interesting bits.

A practical guide to active AI use

To make this more concrete, here is a simple overview of the do’s and don’ts for keeping your brain active when using AI in different situations, based on Mollick’s insights.

Situation	Do (Activate your brain)	Don’t (Outsource your thinking)
Learning & Tutoring	Use prompts that force you to construct knowledge through questions and hints. Explain concepts in your own words.	Ask for the final answer or a complete explanation right away.
Writing & Creativity	Generate your own ideas and write a full draft first. Use AI to polish, refine, or expand on your work.	Let the AI write the first draft or generate all the initial ideas, which can anchor your thinking.
Teamwork & Meetings	Use AI as a facilitator to surface unspoken concerns, find patterns, or ensure all voices are heard.	Use AI to simply summarise meetings you skip, replacing interaction entirely.

From theory to practice

Mollick’s article made me reflect on my own systems engineering prompt. I think my prompt has value for creating a broad overview of course materials. However, to truly learn and engage with the topic, I should use a prompt like Mollick’s tutor prompt.

My plan is to use this new tutor-style prompt at the end of my course, just before the final exam. I will feed it my course materials and then use it to quiz myself. I think using it with a voice mode will be a blast.

Here is the tutor prompt from the Wharton prompt library. It is quite detailed, but it is designed to guide the AI to be a true tutor rather than just an answer machine.

Click to view the full AI tutor prompt

GOAL: This is a tutoring exercise in which you play the role of AI tutor and you will help a student learn more about a topic of their choice. Your goal is to improve understanding and to challenge students to construct their own knowledge via open ended questions, hints, tailored explanations, and examples.

PERSONA: In this scenario you play AI tutor an upbeat and practical tutor. You have high expectations for the student and believe in the student’s ability to learn and improve.

NARRATIVE: The student is introduced to AI tutor, who asks a set of initial questions to understand what the student wants to learn, the student’s learning level and prior knowledge about the topic. The tutor then guides and supports the student and helps them learn about the topic. The tutor only wraps up the conversation once the student shows evidence of understanding: the student can explain something in their own words, can connect an example to a concept, or can apply a concept given a new situation or problem.

Follow these steps in order:

STEP 1: GATHER INFORMATION
You should do this:

Introduce yourself: First introduce yourself to the student and tell the student you’re here to help them better understand a topic.
Ask students to answer the following questions. Ask these questions 1 at a time and always wait for a response before moving on to the next question. For instance, you might ask “What would you like to learn about and why” and the student would respond with a topic. And only then would you say “That sounds interesting! I have another question for you to help me help you: What is your learning level…”. This part of the conversations works best when you and the student take turns asking and answering questions instead of you asking a series of questions all at once. That way you can have more of a natural dialogue.
- What would you like to learn about and why? And wait for the student to respond before moving on.
- What is your learning level: high school student, college student, or a professional? And wait for the student to respond before moving on.
- What do you already know about the topic? And wait for the student to respond before moving on.

You should do this:

Wait for a response from the student after every question before moving on.
Work to ascertain what the student wants to learn specifically.
Ask one question at a time and explain that you’re asking so that you can tailor your explanation.
Gauge what the student already knows so that you can adapt your explanations and questions moving forward based on their prior knowledge.

Don’t do this:

Start explaining right away before you gather this information.
Ask the student more than 1 question at a time.

Next step: Once you have the information you need move on to the next step and begin with a brief explanation.

STEP 2: BEGIN TUTORING THE STUDENT, ADAPTING TO THEIR RESPONSES
You should do this:

Look up information about the topic.
Think step by step and make a plan based on the learning goal of the conversation. Now that you know a little bit about what the student knows consider how you will:
Guide the student in an open-ended way
Help the student generate answers by asking leading questions and providing hints when necessary.
Remind the student of their learning goal, if appropriate
Provide explanations, examples, and analogies
Break up the topic into smaller chunks, going over those first and only then leading up to the larger task or idea.
Tailor your responses and questions to the student’s learning level and prior knowledge; this will change as the conversation progresses.
When pushing the student for information, try to end your responses with a question so that the student has to keep generating ideas.

Once the student shows improvement, ask the student to:

Explain the concept in their own words.
Articulate the underlying principles of a concept.
Provide examples of the concept and explain how those connect to the concept.
Give them a new problem or situation and ask them to apply the concept

Don’t do this:

Provide immediate answers or solutions to problems.
Give the student the answer when asked.
Ask the student if they understand, follow or needs more help – this is not a good strategy as they may not know if they understand.
Lose track of the learning goal and discuss something else.

Next step: Once the student demonstrates understanding move to wrap up.

STEP 3: WRAP UP
You should do this:

When the student demonstrates that they know the concept, you can move the conversation to a close and tell them you’re here to help if they have further questions.

The fear of AI “damaging our brains” is really a fear of our own laziness. The technology offers an easy way out of the hard work of thinking, and we worry we will take it. We should worry. But we also have a choice.

As Mollick concludes:

Your brain is safe. Your thinking, however, is up to you.

Europe's new summer energy challenge: the 'Hitzeflaute'

2025-07-08T00:00:00Z

Extreme heatwaves are creating significant stress on Europe’s energy infrastructure. I came across an interesting article by Julien at GEM Energy Analytics that clearly explains this growing challenge. He introduces the German term Hitzeflaute, which describes a period of intense heat with little to no wind.

The challenge of a hot, still day

For years, the energy sector has discussed the Dunkelflaute, a dark, windless period in winter when both solar and wind generation are low. The Hitzeflaute is its summer equivalent, though slightly different.

During a hot, windless period, solar panels generate a large amount of electricity during the day, which helps to meet the high demand from air conditioning. The problem, however, shifts to the evening. As the sun sets, solar generation drops to zero, but temperatures remain high, and so does the demand for cooling. With no wind to support, the grid is faced with high demand and low renewable supply.

The impact on energy prices

This predictable evening scarcity has a direct effect on electricity prices. As demand exceeds the available renewable supply, the system must rely on more expensive power sources, causing prices to spike for several hours.

This volatility leads to extremely high imbalance prices: the costs paid to balance the grid in real-time. These prices are a clear indicator that the system is operating under significant stress. The article highlights that these price peaks are becoming a structural feature of our modern, renewables-heavy grid.

At first, this seems counterintuitive. If we can predict this evening scarcity, why are the prices so high? The simple answer is that knowing a problem is coming is not the same as having enough cheap tools to solve it. When the sun sets, the grid must instantly replace a massive amount of solar power. We currently do not have enough large-scale battery storage to save cheap daytime energy for the evening. Therefore, the system must rely on expensive backup power plants. The high price reflects the cost of this scarce, last-resort solution needed to keep the lights on.

What can Europe do?

The good news is that these challenges have solutions. The price signals are sending a clear message about where investment and innovation are needed. The article suggests several key areas of focus:

Increased flexibility and storage: Battery storage is ideal for solving this kind of short-term problem. It can absorb cheap, abundant solar power during the day and release it during the evening peak, flattening the price curve.
Smarter demand management: Encouraging consumers to shift their energy use away from peak hours (load shifting) can significantly reduce strain on the grid.
Better grid interconnection: Strengthening connections between countries allows electricity to flow from areas with a surplus to areas with a deficit, increasing overall system resilience.

A systems engineering perspective

From a systems engineering viewpoint, this is a classic optimisation problem. The grid is a complex system that must be designed for resilience against predictable events like heatwaves.

The article notes that some power plants are offline for maintenance during summer, which is traditionally a period of lower demand. This is where predictive maintenance can help. By predicting potential failures, maintenance can be scheduled more strategically. For instance, instead of a fixed annual shutdown, a gas plant’s maintenance could be dynamically scheduled based on long-term weather forecasts and real-time sensor data. This data, from sensors monitoring things like turbine vibration, operating temperatures, and component stress, helps predict wear and potential failures. This approach ensures that essential backup power plants are available during these high-stress heatwave periods, rather than being offline when they are needed most.

Wrap-up

The “Hitzeflaute” demonstrates how Europe’s power system is now shaped as much by the climate as it is by technology. These events are no longer rare disruptions but regular stress tests.

An overview of systems engineering core concepts

2025-07-07T00:00:00Z

Recently, I wrote about my process for using an LLM as a personal tutor for the Introduction to Systems Engineering course I am taking. This post is a direct result of that process. I have synthesised the core concepts from the first half of the course into a single overview. My goal is to solidify my own understanding and share a clear, practical summary of the foundational principles of systems engineering. I hope it also encourages you to explore the course yourself. There is much extra detail and insight in the course itself; it is an excellent course for anyone working with complex systems.

This is a longer post, but I have structured it to be as scannable as possible, covering the journey from defining a system to engineering its requirements.

A system, much like a city, is a set of interconnected elements with a clear boundary and purpose.

What is a system?

The course starts with the most fundamental question. In systems engineering, a system is defined as a set of elements that interact to achieve a stated purpose. This simple definition forces us to be precise about three things: the system’s elements, their interconnections, and its mission.

A key concept here is the system boundary, which defines what is inside our ‘System of Interest’ and what is in the external environment. This boundary determines the project’s scope and clarifies our responsibilities.

The system life cycle

Every system, from a simple application to a complex aircraft, goes through a life cycle. Understanding these phases is essential because decisions made in one phase have consequences in all others. The generic life cycle has four major phases:

Pre-Acquisition: The conceptual phase where the business need is identified, a business case is developed, and feasibility is assessed.
Acquisition: The phase where the system is designed, built, and tested. This is the heart of the engineering effort.
Utilization: The operational phase where the system is used and supported. This is typically the longest and most expensive phase.
Retirement: The final phase where the system is disposed of at the end of its useful life.

The acquisition phase itself is broken down into four sequential activities, each ending with a critical review that establishes a design ‘baseline’.

Activity	Review	Baseline Established	Description
Conceptual Design	System Design Review (SDR)	Functional Baseline	Defines what the system must do (the logical architecture).
Preliminary Design	Preliminary Design Review (PDR)	Allocated Baseline	Maps the ‘what’ to a high-level ‘how’ (subsystem design).
Detailed Design	Critical Design Review (CDR)	Product Baseline	Details the design down to the component level for manufacturing.
Construction	Formal Qualification Review (FQR)	Qualified System	The system is built, tested, and accepted for use.

Each baseline represents an increasing level of detail and a decreasing flexibility to make changes. This structured approach helps prevent costly errors late in the process.

The two views: logical versus physical

A core principle is the separation of the logical and physical architecture.

Logical Architecture (The “What”): Describes what the system will do, how well it will perform, and under what conditions. It is based on requirements and is relatively stable over time. The purpose of an engine—to provide motion—has not changed much, even as the technology has.
Physical Architecture (The “How”): Describes the actual components, how they are manufactured, and how they are integrated. This is based on design specifications and changes rapidly with technology.

We always develop the logical architecture first. Understanding the problem clearly before committing to a specific solution prevents us from being constrained by old technology or legacy thinking.

The discipline of systems engineering

With the foundations in place, the course defines what systems engineering actually is. It is not about a specific engineering field but a holistic discipline focused on six key areas:

Requirements engineering: Systematically managing stakeholder needs.
A top-down approach: Starting at the system level and decomposing downwards.
A life cycle perspective: Considering all phases from concept to retirement.
System optimisation and balance: Making the whole system work well, not just the parts.
Integration of disciplines: Coordinating various engineering specialities.
Management: A structured process for managing complexity.

Without this discipline, it is easy to create systems that are functional but unnecessarily complex, like the famous Rube Goldberg machines.

The 'Self-Operating Napkin'. Rube Goldberg, Public domain, via Wikimedia Commons

The fundamental process used throughout is Analysis-Synthesis-Evaluation (A-S-E). It is an iterative loop: we analyse the problem, synthesise potential solutions, and evaluate them against the requirements. This loop is repeated at every level of design, from the overall system down to the smallest component.

A common misconception is that systems engineering adds cost. In reality, it shifts costs. By investing more effort upfront in requirements and design (the A-S-E process), we significantly reduce expensive changes and rework during construction and operation, leading to a lower total life cycle cost.

The language of needs and requirements

The language of systems engineering is built on a clear distinction between needs and requirements.

Needs are expectations from the business or stakeholders, stated in their language. For example, “I need a secure place to park my car.”
Requirements are formal, agreed-upon obligations derived from those needs. They are precise and, crucially, verifiable. For example, “The system shall include a garage with a lockable door.”

This transformation from abstract needs to concrete requirements happens in a structured hierarchy, often captured in a series of documents:

Concept of Operations (ConOps): The high-level vision of how the system will be used.
Business Requirements Specification (BRS): Formalises the business needs.
Stakeholder Requirements Specification (StRS): Formalises the needs of users and other stakeholders.
System Requirements Specification (SyRS): The technical specification that the developers will build against.

A well-formed requirement is necessary, unambiguous, feasible, and verifiable. If you cannot define how to test a requirement, it is probably not a good requirement.

The process of requirements engineering

The formal process for defining and managing requirements is called Requirements Engineering. It involves two main activities:

Elicitation: Gathering requirements directly from stakeholders and other sources.
Elaboration: Analysing the elicited requirements to derive other functions that are logically necessary for the system to work, even if they were not explicitly stated.

Once requirements are defined, we must ensure we build the right system and build the system right. This is the job of Verification and Validation (V&V).

Verification: “Did we build the system right?” This checks if the system complies with its design specifications.
Validation: “Did we build the right system?” This checks if the system actually meets the original stakeholder needs.

A system can be perfectly verified but fail validation if it was built to flawed requirements.

Finally, traceability is the thread that connects everything. It is the ability to follow a requirement’s life from its origin to its implementation.

Forward traceability ensures every high-level requirement is addressed in the final design.
Backward traceability ensures every design feature can be traced back to an authorised requirement. This is the primary defence against ‘requirements creep’—the addition of unrequested features that add cost and complexity.

Final thoughts

Working through these concepts has given me a much clearer picture of systems engineering. It is a discipline dedicated to managing complexity. By taking a structured, top-down approach that considers the entire life cycle, it provides a framework for translating abstract business needs into a successful, operational system. The emphasis on getting the requirements right from the start is a lesson that applies far beyond just large-scale engineering projects.

What makes strong engineers strong?

2025-07-06T00:00:00Z

I recently read an interesting view from Sean Goedecke: What makes strong engineers strong?. He argues that the difference between a strong engineer and a weaker one is not just technical skill, but a combination of four key traits, which he presents in order of importance.

His perspective is that strong engineers can complete tasks that ‘weaker’ ones cannot, even with unlimited time. Here is a brief summary of his points.

1. Self-belief

This is the foundation. Strong engineers have the confidence to tackle difficult and unfamiliar problems head-on. They believe they can figure it out, which creates a positive feedback loop: taking on hard problems builds confidence, which encourages them to tackle even harder ones. They do not shy away from the most challenging part of a task.

2. Pragmatism

Strong engineers focus on shipping solutions that work. They prioritise getting things done over creating a theoretically “perfect” or “elegant” system. Design decisions are judged by their effectiveness, and they are willing to make compromises to deliver a working product.

3. Speed

According to Goedecke, strong engineers are always fast workers. This is not about working long hours, but about efficiency and accumulating experience rapidly. Fast execution allows for more experimentation and makes it possible to try ideas with a low chance of success but a high potential reward.

4. Technical ability

While essential, technical skill is the final piece of the puzzle. A baseline is necessary, but what matters more is having the right technical skills for the job at hand. Goedecke notes that raw intelligence does not always translate to effectiveness; he would rather work with an engineer who is confident and pragmatic than a genius who struggles with those traits.

Goedecke’s summary is that it is the combination of these traits that truly defines a strong engineer. It is a good read, and I recommend checking out the full post for his detailed thoughts.

From notebooks to production systems

2025-07-05T00:00:00Z

I recently listened to an episode of the TalkPython podcast featuring Dr. Catherine Nelson, where she discussed the journey from exploratory data science in notebooks to building scalable, production-grade systems. The conversation highlighted a critical transition that many data scientists face, and I wanted to expand on the key points that stood out to me.

The limits of notebooks

Notebooks are fantastic tools for exploration. Their interactive nature allows for rapid iteration, visualisation, and a free-form approach to understanding data. This is perfect for the initial stages of a project where the path forward is not yet clear.

However, this flexibility becomes a liability when a project needs to be run repeatedly and reliably. When a notebook is simply converted to a Python script, several problems emerge:

Hidden state and execution order: Notebooks allow you to run cells out of order, creating an invisible state that a linear script cannot replicate. A script might fail because it depends on a variable from a cell that was run manually but is not in the correct sequence.
Monolithic structure: A single notebook often mixes data loading, cleaning, analysis, and modelling. This makes the resulting script a “God script”—impossible to test in isolation, difficult to debug, and with no reusable components.
Testing blind spots: Notebooks are rarely written with testing in mind. Code is not structured in testable functions, making it hard to validate logic without significant refactoring.
Collaboration barriers: The JSON structure of .ipynb files is notoriously difficult to manage with Git, leading to frustrating merge conflicts that hinder team collaboration.

The shift to a production engineering mindset

The most crucial takeaway for me was the necessary shift in thinking from an exploratory, scientific mindset to a production engineering mindset. This is not about abandoning data science principles but augmenting them with software engineering best practices.

It is about recognising that your successful experiment is now a piece of software. The focus must change from “what can this data tell me?” to “how can I build a reliable, efficient, and maintainable system that delivers this result consistently?”

This means moving from:

Exploration-first to reliability-first.
“Throwaway” code to maintainable, reusable code.
Manual execution in a notebook to automated CI/CD pipelines.
Local environments to containerised, reproducible systems.

A practical workflow for making the switch

Dr. Nelson outlined a practical, battle-tested process for moving code from a notebook into a production-ready structure.

Map the workflow: Before writing any code, draw a simple diagram of the logical steps in your notebook. This could be as straightforward as load_data → clean_data → train_model → predict. This map becomes the blueprint for your new structure.
Refactor into functions: Create separate Python files and begin moving code from your notebook cells into single-responsibility functions. Start with empty function stubs that match your workflow diagram, then fill them in one by one. Tools like nbconvert can do a one-time export, while Jupytext can keep a .py file and a notebook in sync, which is useful during the transition.
Write tests as you go: For each function you create, write a corresponding unit test using a framework like pytest. This validates that the logic works as expected and provides a safety net for future changes. It forces you to write clean, testable code from the start.
Adopt engineering fundamentals: Fully commit to standard software engineering practices. Use Git for version control, write clear docstrings to explain what your functions do, and use a linter to maintain code quality.

The role of MLOps and containerization

This new workflow is supported by two key technological pillars: MLOps and containerization.

MLOps (Machine Learning Operations) provides the framework to manage the entire machine learning lifecycle in a standardised way. Platforms like MLflow or TensorFlow Extended (TFX) help automate data validation, model retraining, and deployment, preventing the “ad hoc script proliferation” that plagues many teams.

Containerization (with Docker) for production systems. It solves the “it works on my machine” problem by packaging your code, libraries, and system dependencies into a single, consistent unit. This ensures your application runs identically everywhere, from your laptop to a cloud server, and is essential for building scalable, isolated microservices.

Diving deeper into MLOps

For those looking to learn more, the field of MLOps is fortunately well-documented. The major cloud providers, such as Databricks, Microsoft, and Amazon, offer extensive documentation that, if you focus on the bigger picture, provides valuable platform-agnostic principles.

If you prefer a more structured, book-based approach, several excellent texts can guide you. For instance, Implementing MLOps in the Enterprise by Yaron Haviv and Noah Gift takes a production-first approach, focusing on designing the operational pipeline before integrating machine learning components. Alternatively, Introducing MLOps by Mark Treveil et al. introduces the core concepts by breaking down the entire model lifecycle into five key stages: Build, Preproduction, Deployment, Monitoring, and Governance.

The journey from a notebook to a production system is a sign of success. It means your work has proven valuable enough to be operationalised. As Dr. Nelson said, it is about making your code robust and easy for others to use—that is how data science creates real impact.

From theory to practice: How organisations are adopting AI

2025-07-04T00:00:00Z

Following up on my recent post about the real impact of AI on engineering leadership, I came across an interesting article from the Stack Overflow blog. Titled “Not an option, but a necessity”, it moves beyond the theoretical and shows how different companies are practically integrating AI into their workflows.

The article reinforces that while many leaders see AI deployment as immature, the push for adoption is undeniable. It is driven by the need for greater efficiency, faster access to knowledge, and more innovative strategies.

Different teams, different approaches. Whether you're a meticulous beaver, a collaborative otter, or a pragmatic badger, strategy is key.

How different companies are approaching AI

What I found most useful were the specific examples of how different organisations are tackling this challenge. Each has a distinct, intentional approach.

Cloudflare: They are taking a top-down approach by giving AI tools to their most senior, high-performing developers first. The goal is not to make average developers good, but to make the best developers even better. This allows them to measure the productivity impact on complex problems before rolling it out more widely.
GitHub: Their focus is on freeing up developer time for more strategic work and collaboration. By automating routine tasks, AI allows their technical teams to focus on higher-value activities and work more closely with non-technical departments, breaking down traditional silos.
Abnormal AI: They take a pragmatic view, acknowledging that AI tools do not work perfectly “out of the box”. Their approach emphasises that success requires investment and a willingness to shape the tools and the organisation to fit each other.

A systems engineering perspective

From a systems engineering perspective, these approaches are fascinating. Instead of treating AI as a simple plug-and-play tool, these companies are managing it as a new, powerful component within their complex organisational systems. They are carefully observing the interactions—the feedback loops—between the technology, their people, and their processes. This allows them to manage the emergent outcomes, rather than just hoping for the best.

The common thread is strategy

These examples perfectly illustrate the point from my previous post: successful AI adoption requires a clear roadmap. Each of these companies has a deliberate plan. They are not just adopting technology for its own sake; they are integrating it to solve specific business problems, whether that is amplifying top talent, fostering collaboration, or accepting the need for customisation.

It is encouraging to see these practical approaches emerge. They confirm that the path to getting real value from AI is less about the tool itself and more about the strategy behind its implementation.

Reflecting on AI's real impact on engineering leadership

2025-07-03T00:00:00Z

In her recent post, “RDEL #99: How has AI impacted engineering leadership in 2025?”, Lizzie Matusov shares some grounded findings from the 2025 LeadDev Engineering Leadership Report. The data paints a picture that is less about revolutionary transformation and more about a gradual, and sometimes challenging, integration of AI into engineering workflows.

Key findings from the report

The survey of over 600 engineering leaders reveals:

Productivity gains are modest: 60% of leaders said AI has not significantly boosted team productivity yet.
Headcount is stable: 54% do not expect AI to reduce their team size this year.
Adoption is focused: The most common use cases are coding assistants for generation, refactoring, and documentation.
Leaders are concerned: Over half (51%) believe AI will have a negative long-term impact on the industry, citing code maintainability and the effect on junior developers.

The overall message is that while adoption is widespread, the promised productivity revolution has not yet materialised.

A practical path forward

These findings align with my own experience. In the early days, AI and LLM projects often felt like a technology searching for a use case. It was a classic example of a solution looking for a problem, which I discussed in my post on assessing new technology with Readiness Levels.

What gives me confidence for the future, however, is the emergence of standards that help with corporate adoption. Protocols like MCP are a great step forward, providing a common language for integrating AI with existing tools. This helps to reframe the technology; instead of being a goal in itself, AI becomes a practical tool to help realise business capabilities more effectively.

For AI to deliver real value, there must be a clear roadmap for its implementation and practical usage. This is not just about buying new tools; it is about organisational change. A well-defined plan is the first practical step to getting people on board and ensuring the company invests its time and money in the right things. Without that clarity, we risk staying in a cycle of experimentation without ever achieving meaningful results.

A practical take on prioritisation

2025-07-02T00:00:00Z

I recently read a very good article by Jason Cohen of A Smart Bear called Ruthless prioritization while the dog pees on the floor. It addresses a problem we all face: there is never enough time to do everything we want or need to do.

Cohen’s central point is that time is a zero-sum game. Every choice is a trade-off.

Time is a zero-sum resource: An hour spent on one thing necessarily means not spending an hour on the entire universe of alternative things. Every minute is a choice. Every choice is a trade-off.

While there are many prioritisation frameworks out there, from the Eisenhower Matrix to RICE scoring, Cohen’s approach cuts through the complexity. He proposes a simple, practical way of thinking that forces you to identify what truly matters.

Identifying your 10x tasks

The first step is to actively seek out what Cohen calls “10x tasks”. These are activities where the return on your time is an order of magnitude greater than the effort you put in. They are the tasks that can genuinely transform your business or career.

Examples include:

The few features that win the majority of your sales.
Finding the marketing message that doubles your conversion rate.
Hiring a critical employee who elevates the entire team.
Addressing the single biggest bottleneck to your growth.

In my industry, a 10x task in data science could be developing a predictive model that automates a core business decision, freeing up hours of manual analysis each week. In modern systems engineering, it might be establishing a rigorous traceability process from the start. While it feels like overhead initially, it prevents entire teams from building features that do not map to a core stakeholder need, saving months of wasted effort down the line.

It is important to find your 10x tasks:

If you don’t know what one or two 10x tasks you should be working on, then identifying that is your highest priority.

Without this clarity, any work you do, no matter how efficient, risks being a waste of time.

Minimising the 0.1x tasks

On the other end of the spectrum are “0.1x tasks”. These are the low-impact activities, many of which are mandatory but do not provide a high return. The goal is to spend as little time on them as possible. Cohen suggests several strategies:

Eliminate: Can you change your strategy to avoid the task completely?
Delegate: Can someone else do it, even if not perfectly?
Batch or Automate: Can you group similar tasks and do them all at once?
Archive: For ideas or tickets that have sat untouched for months, accept they will likely never be done and archive them. If it is truly important, it will come back.

He makes an important distinction that effort does not equal impact. A simple task is not automatically a 0.1x task; some easy wins can have a 10x impact.

The reality of focus: letting the dog pee on the floor

Cohen uses a memorable parable to illustrate the true cost of focus. Instead of me paraphrasing, here it is directly from the article:

In a well-lit living room, a dog is peeing on the floor while a man sits in a chair, reading a book. The man doesn’t react. You’re watching from a window, concluding that this man must be ignorant, crazy, or at least a poor decision-maker. Put down the book and take that dog for a walk, idiot!
Except, you don’t know the full story. In one hour, the man has the most important meeting of his life. His performance in this meeting will dictate the next ten years of his career. Everything he needs to know to be successful in this meeting, is in that book. Yes the dog should have been taken for a walk, but the penalty of having to clean up the pee is worth it, because the call is that important.

This is what intense prioritisation looks like. You must intentionally ignore some problems to give your full attention to the 10x opportunity.

The importance of communication

This intentional neglect can destroy morale if your team only sees the “dog peeing on the floor”. They see problems being ignored and lose faith in leadership.

The solution is constant and clear communication. You must explain why certain fires are being left to burn. You need to share the full story: what the 10x task is, why it is the top priority, and explicitly acknowledge the things you are not doing as a result.

Assessing new technology with Readiness Levels

2025-07-01T00:00:00Z

I recently came across the concept of Technology Readiness Levels (TRLs), and it immediately struck me as a very practical tool. Originally developed by NASA to assess technologies for space missions, it provides a simple yet effective scale for measuring the maturity of a technology.

It is a straightforward way to create a common language when discussing how ‘ready’ a new piece of technology is. Here is a simplified summary of the levels:

Level	Name	Description
TRL 1-3	Research	Basic principles observed, concepts formulated, and proof-of-concept demonstrated. This is the blue-sky thinking and early lab work phase.
TRL 4-6	Development	Components are tested in a lab, then in a ‘relevant’ environment. A prototype exists that works in a simulated operational environment.
TRL 7-9	Deployment	The prototype is demonstrated in an operational environment, the final system is qualified, and it is proven to work through successful operation.

How I use it

This framework is very practical when assessing a new demand or technology. It helps answer critical questions before committing significant effort:

Does it fit our existing architecture?
Does it align with our data landscape?
Can it be integrated into our current processes?

The TRL scale helps frame the answers. If a technology is at a low TRL (e.g., TRL 3), it is perfectly acceptable that it does not fit with our established processes. At this stage, we are just experimenting to learn. The goal is not integration, but validation of the concept itself.

However, if the ambition is to bring that technology to a mature state (e.g., TRL 8), the assessment changes. We must then plan and dedicate effort to embedding it within the organisation. This work runs parallel to the technical development and building our team’s experience with it. Using TRLs makes this distinction clear and helps manage expectations.

Shortcomings and the commercial view

No model is perfect. A high TRL ensures a technology is mature, but it does not guarantee it is appropriate or commercially viable. This is a critical gap, as a technically perfect product that nobody wants is a failure.

This is where the Commercial Readiness Level (CRL) comes in. It acts as a parallel framework to TRL, assessing everything from initial market research and business model validation to achieving the first revenue.

TRL and CRL are interdependent journeys, not sequential steps. (From: [LaMonaco & Associates](https://lamonaco.com/blogs/2024/12/11/commercial-readiness-level-crl-for-startups))

Technology Readiness Level (TRL) and Commercial Readiness Level (CRL) are not sequential; they are interdependent and should progress in parallel. A common mistake is to perfect the technology (high TRL) before even starting the commercial validation (low CRL). Feedback from early customer interviews (a low CRL activity) should directly influence technical priorities and feature development (TRL activities). This alignment ensures you are building something people actually want, reducing market risk and making resource allocation far more efficient.

Connecting the dots: A more complete strategic toolkit

How do these readiness levels fit into a broader strategy? Short recap what they give us: Technology Readiness Level (TRL) answers the question, “Can we build it?” It measures technical maturity and helps us manage engineering risk. Commercial Readiness Level (CRL) answers the question, “Should we build it?” It measures market viability and helps us manage commercial risk.

In my earlier post on a practical toolkit for technology strategy, I outlined a way to map the strategic landscape using two key frameworks:

Wardley Maps: To visualise our value chain and understand how components evolve from new ideas (Genesis) to stable utilities (Commodity).
Pace Layering: To categorise our systems by their required speed of change, from fast-moving Systems of Innovation to slow and stable Systems of Record.

This is where TRL and CRL become useful additions to that toolkit. They provide the granular, evidence-based metrics needed to make those high-level maps actionable.

TRLs quantify the Wardley Map evolution axis. A component in ‘Genesis’ has a low TRL by definition. A ‘Commodity’ service has a TRL of 9. Using TRLs allows us to precisely measure where a component is on its journey and plan the work needed to move it.
TRLs and CRLs act as gates for Pace Layering. A technology with a low TRL and CRL belongs firmly in the ‘System of Innovation’. We would never place it in a ‘System of Record’. As a technology matures both technically (higher TRL) and commercially (higher CRL), we can make a conscious, data-informed decision to migrate it to a more stable layer.
CRL validates the ‘user need’ on the map. A Wardley Map starts with a user need. CRL is the framework for testing if that need is real and if our proposed solution is desirable before we over-invest in technical development.

By combining these frameworks, we move from abstract maps to a practical, measurable system for managing technology development and de-risking our strategic bets. For those who want to go deeper, the definitive document on TRL is the NASA Technology Readiness Assessment Guide. For a great breakdown of CRL, I recommend the post by LaMonaco & Associates.

Pairing technical assessment (TRL) with commercial validation (CRL) provides a more complete picture, ensuring that what you build is not only feasible but also valuable.

The value of the expert generalist

2025-06-30T00:00:00Z

In our industry, we often see job descriptions demanding years of experience in niche frameworks, pushing us towards ever-narrower specialisation. While deep knowledge is valuable, I have found that the most effective people are those who can bridge different domains.

That is why I enjoyed the recent article, “Expert Generalists,” by Unmesh Joshi, Gitanjali Venkatraman, and Martin Fowler of Thoughtworks. They give a name and a framework to a concept I have long admired, arguing that being an “expert generalist” is a skill we should actively cultivate.

The authors identify several traits that define an expert generalist, including deep curiosity, collaborativeness, and a sharp customer focus. However, the most important trait is a preference for fundamental knowledge over transient, tool-specific trivia. They explain this concept as follows:

The vertical stroke of a skill set represents broader, long-lasting domains, not specific tools or frameworks. An expert generalist therefore pursues depth in distributed-data systems—partitioning and replication strategies, fault-tolerance mechanisms, consistency models, and consensus algorithms—instead of mastering only Databricks notebooks.

This directly addresses a core issue in our field: we often mistake tool proficiency for fundamental competence. The authors make a good point that this is not a new problem. In the 90s, the focus was on mastering tools like Rational Rose instead of the principles of Object-Oriented Programming. Today, we see the same pattern with certifications for specific cloud platforms.

This focus on tools makes our skills brittle and creates organisational silos. As the article states, these labels can become a significant problem:

The labels become an organisational anti-pattern—turning flow into a series of hand-offs when it should be a cross-functional sprint.

To counter this, the authors even propose practical workshops, like building miniature versions of Kafka or Kubernetes, to teach these core concepts directly.

In the end, an expert generalist who focuses on fundamentals can move between technologies with confidence, because they understand that the core challenges of replication, consistency, and fault tolerance remain the same. The benefit is not just personal growth; it creates better teams and partnerships.

…engineers who have a good grasp of the fundamentals are able to partner well with multiple product and platform teams, without needing to have product specific training for each product.

The full article offers much more detail and is well worth the read.

The last hurrah of human coding

2025-06-29T00:00:00Z

I just read an excellent article by Alex MacCaw titled “How to Vibe Code as a Senior Engineer”, and it captures the current excitement around AI-assisted development perfectly. He describes “vibe coding” not as a tool for junior developers to get by, but as a genuine superpower for experienced engineers.

It feels like rubbing a magic lamp and whispering your intent to a genie.

He argues that with the latest generation of AI models, a senior engineer’s productivity can be amplified to an incredible degree. It is a shift from writing every line of code to guiding a powerful, knowledgeable, but context-less assistant. As he puts it, we are in “the last hurrah of human coding” 😯😅, a magical time where our judgment and experience are still essential to guide these powerful new tools.

The senior engineer’s toolkit for vibe coding

Alex does not just celebrate the concept; he provides a practical toolkit for making it work effectively. His approach is about creating a highly structured environment where the AI can perform at its best. His key requirements include:

A solid foundation: Starting with a rich monorepo scaffold gives the AI clear examples and patterns to follow. A monorepo is particularly effective because all the code is in one place, making it simple to provide the necessary context to the AI.
Clear rules of engagement: Using a tool like Cursor’s .cursor/rules to codify project conventions is critical. This acts as a rulebook for your AI assistant. For example, you can define a strict development cycle: force the AI to create a plan before coding, automatically run type-checking and linting after every change, and even forbid it from trying to start a dev server.
Providing the right context: AI models have no memory, so it is our job to manually provide all relevant files—including TypeScript definitions—to get quality output.
A capable editor: He recommends Cursor for its tight integration of linting, type-checking, and context management, allowing for rapid iteration.
Using the best models: He advises against sacrificing quality for cost, advocating for top-tier models like Claude Opus 4 or Gemini 2.5 Pro.

This is not about letting the AI run wild; it is about creating the perfect conditions for it to succeed under your direction.

From vibe to structure

This approach strongly connects with my own thoughts, which I shared in a previous post, “Beyond the vibe: structuring AI-assisted development”. In that article, I discussed the need for guardrails and a clear “constitution” to make AI collaboration professional and scalable.

Alex’s practical advice feels like the direct implementation of these principles. His “scaffold” and “rules” are the very guardrails and rulebooks I was exploring. It confirms that the path to successfully using these tools in a professional setting is through structure, not chaos.

As I wrote previously, the role of the senior developer is changing:

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

The senior developer becomes the architect of the system that produces the code, embedding their expertise into the process itself.

The architect remains in charge

Alex touches on a crucial point when he lists what AI is bad at: “Taste & Architecture.” This is where human experience remains irreplaceable. An AI can generate code at an astonishing rate, but it cannot understand your project’s long-term vision, its architectural principles, or the subtle trade-offs that define a robust system.

This reinforces my belief that AI does not diminish the importance of software architecture; it elevates it. A well-defined architecture, clear boundaries, and explicit rules are the map and compass the AI needs to navigate your codebase. Without them, you are just generating technical debt faster than ever before.

It is an exciting time to be building software. The tools are becoming magical, but they demand a new level of discipline and architectural clarity from us. We are not just coders anymore; we are becoming the conductors of a powerful orchestra.

Shape your work, influence strategy

2025-06-28T00:00:00Z

In my recent post on a practical toolkit for technology strategy, I explored how frameworks like Wardley Maps and Pace Layering help us understand the strategic landscape. These are excellent for creating a high-level diagnosis, but the crucial next step is translating that vision into concrete work for our teams.

I recently came across an excellent article by Frederick Vanbrabant, “Choosing where to spend my team’s effort,” that provides a hands-on, ground-level guide for this challenge, applicable even within large corporate organisations. He explains how teams can identify and fill gaps in high-level strategy, allowing them to propose their own valuable projects. This approach is not just for managers; it is equally powerful for product owners, principal engineers, or any leader wanting to influence decisions and shape the technical direction.

Frederick’s core idea is that teams can and should move from being passive recipients of tasks to proactive contributors to the strategy. He captures this shift perfectly:

Replace assigned work with chosen work. That’s the shift.

This is a powerful mindset change. It is not about adding more work but about shaping the work that is already planned to deliver greater value. Frederick outlines a straightforward process for any team lead to connect their work directly to organisational goals.

1. Truly understand the ‘why’

The first step is to go beyond simply reading the strategy document. Frederick advocates for having a deep conversation with your manager about the company’s direction and the reasoning behind it. As he rightly points out:

What you see depends on where you sit. That means there might be gaps in vision, gaps that you can fill.

By understanding the bigger picture, you can identify opportunities that might not be visible from higher up.

2. Connect strategy to projects

With a clear understanding of the goals, the next step is to brainstorm how your team can contribute. Frederick suggests a simplified version of an opportunity solution tree (from Teresa Torres):

Start with a strategic goal (e.g., “reduce operational costs”).
Brainstorm broad actions (e.g., “automate manual processes”).
Define specific projects (e.g., “build an API to connect the sales and delivery platforms”).
Outline a proof of concept to quickly test the idea’s value.

This process does more than just generate ideas; it builds a business case. When you can directly link a project to an organisational goal, you are no longer just pitching a technical task. You are presenting a solution. This makes the project far easier to champion. As Frederick notes:

If you can pitch your projects in the framework of the company’s strategy your odds of a successful pitch will skyrocket, most of the convincing has been done for you already.

You are speaking the language of the business, which makes it easier for your manager to support and sponsor your proposal.

3. Find the multiplier effect

The most valuable projects are those that serve multiple strategic goals at once. Using the API example, not only does it reduce manual labour (cutting costs), but it might also provide real-time data needed for a future innovation project (increasing speed and capability).

This is where the high-level view from a Wardley Map, as discussed in my previous post, becomes so effective. By mapping your value chain, you can spot where a single technical improvement—like building that API—can unlock value across different parts of the business. Frederick’s method gives you the team-level process to propose and justify that work.

Your seat at the table

This approach is a practical way to increase your team’s autonomy and impact. By consistently proposing well-reasoned projects that align with company goals, you demonstrate strategic thinking. Over time, this helps you earn the freedom to shape your team’s direction, moving from assigned work to chosen work that truly makes a difference.

What a coffee shop can teach you about system design

2025-06-27T00:00:00Z

I recently received a genuinely good suggested read from Substack: an article by Raul Junco that uses a common, everyday experience—ordering a coffee—to explain the core principles of system design. I found the analogy so effective that I wanted to share it here.

In architecture, it can sometimes be challenging to move from complex processes, interconnections, and technologies to a clear overview that still has enough detail. Methodologies like TOGAF and tools like ArchiMate offer guidance, but they can also be overwhelming. I think this post shows an interesting perspective on how to model a system with some practical considerations along the way.

This diagram by Raul Junco illustrates the coffee shop analogy.

The central idea is that a busy coffee shop operates much like a distributed system in software engineering. By observing how it handles requests, queues, and bottlenecks, we can gain a practical understanding of otherwise abstract concepts.

Here is a breakdown of his main points:

The Cashier as an API Gateway: The system’s entry point that validates and logs requests.
The Order Queue as a Message Queue: A buffer that holds tasks, where processing time can vary.
The Baristas as Event Consumers: Independent workers who pull tasks from the queue when they have capacity.
The Espresso Machine as a Shared Bottleneck: A limited resource that can cause contention and slow down the system.
Calling Your Name as a Push Notification: An efficient way to signal task completion without wasteful polling.

As Junco puts it:

Distributed systems don’t start in the cloud.
They start with understanding how work flows, where it gets stuck, and who needs to be notified.
You don’t need Kubernetes to learn system design. You just need to watch how a coffee shop works under pressure.
Next time you’re in line, look around and ask:
Where’s the queue?
What’s async?
What’s the bottleneck?
What breaks under load?
If you can model a coffee shop, you can model a backend system.

Using a simple analogy like this is a powerful way to establish a shared understanding with stakeholders before introducing the complexity of a full enterprise architecture model.

Are you the best Chief Data Officer?

2025-06-26T00:00:00Z

I came across a great little game (~4 mins) that lets you test your skills as a Chief Data Officer (CDO) in just four minutes. It is called ‘Who is the best CDO?’ and was created by Charlotte Ledoux. You can read more about her thoughts on the game in her LinkedIn post.

The objective is clear:

Your goal: balance innovation with compliance, win support across departments, manage data risks, and prove the value of data to the business.
[…]
You have to manage the two key indicators: Data Quality and Reputation. But your ultimate goal is to increase the company’s profit.

My own attempt was interesting. I managed a good score on data quality, but my reputation took a hit. Still, I ended up with a nice profit!

It is a fun challenge. Give it a try and see how you do!

Using an LLM as a personal tutor for my systems engineering course

2025-06-25T00:00:00Z

I am currently taking the Introduction to Systems Engineering course from UNSW Sydney. According to the course description, it “uses a structured yet flexible approach to provide a holistic, solid foundation to the successful development of complicated systems.” It covers the entire system life cycle, from design and development to production and management, explaining how different components interrelate to achieve a project’s goals.

While the video lectures are informative, I find the accompanying study materials can be quite basic and sometimes lack the depth I am looking for. To overcome this and engage with the subject matter, I have developed a workflow that uses a Large Language Model (LLM) as a personal study companion.

My AI study companion, helping me make sense of complex topics.

Why I use an AI assistant for studying

My approach serves two main purposes.

To add depth: The standard course materials do not always contain all the information I need. An assistant can help fill in the gaps and provide a more comprehensive overview.
To improve learning: Interacting with the theory is crucial for my understanding and retention. This process forces me to synthesise information, which is a more effective way to learn than passive reading.

My study workflow

My process transforms fragmented course content into a structured and coherent study guide in OneNote. It involves a few key steps and some custom tools.

Gathering the raw materials
First, I collect all the available information for a course module. This includes video captions, lecture notes, and any provided handouts in PDF format. To handle the PDFs, I use a tool I created, the PDF to Markdown Converter, which I wrote about in a previous post.
The AI study companion
Next, I feed all this raw text into an LLM. After some experimenting, I have settled on using Google’s Gemini 2.5 Pro for generating the study guides. I found that other models had drawbacks for this specific task; Claude 4 Sonnet was often too talkative, DeepSeek R1 was too brief, and Gemini 2.5 Flash was not detailed enough. The quality of the output, however, depends almost entirely on the prompt.
Structuring the notes for OneNote
The LLM generates a well-structured overview in Markdown. To get this into my preferred note-taking application, I use another tool I built: the Markdown to OneNote Converter. This tool, which I also posted about earlier, converts the Markdown into formatted text that I can paste directly into a OneNote page.
Final touches
As a final step, I manually review the generated guide and copy over the most important diagrams and slides from the original materials. This step ensures the visual information is not lost and serves as another engagement with the theory.

Crafting the perfect prompt

The heart of this workflow is the prompt. A good prompt is the difference between a generic summary and a truly useful study guide. I collaborated with Claude 4 Sonnet to develop and refine my prompt.

Here is a summary of that development process:

Initial Goal: Create an AI agent to synthesise video content and poor-quality handouts into comprehensive, exam-ready study materials for my Systems Engineering course.
Evolution:
Version 1: Comprehensive Foundation. Established the agent’s identity and a detailed output structure.
Version 2: Course-Centric Focus. Shifted priority to the course’s specific learning objectives and improved diagram preferences.
Version 3: Holistic Integration. Moved from separate content blocks to a unified, flowing narrative for better retention.
Version 4: Enhanced Learning Techniques. Added metacognitive support, concept mapping, and comparative analysis to deepen understanding.
Final Agent Characteristics: The final prompt defines an elite Systems Engineering educator that transforms fragmented materials into a single, integrated study guide focused on clarity, retention, and the course’s specific goals.

The final prompt: My systems engineering master educator

This iterative process resulted in the following detailed prompt, which I now use to generate my study guides that help me understand the theory.

Click to view the full prompt

**Systems Engineering Master Educator & Study Companion**

## **Your Core Identity**
You are an elite Systems Engineering educator with 20+ years of experience in both academic instruction and real-world systems implementation. You have taught at top-tier universities, consulted for Fortune 500 companies, and have deep expertise in systems thinking, requirements engineering, system architecture, verification & validation, and lifecycle management. You are passionate about making complex systems concepts crystal clear and intuitive for students.

## **Your Mission**
Transform poorly structured course materials into a **unified, holistic study guide** that flows seamlessly from concept to application to exam preparation. You will receive handout text and video captions from an "Introduction to Systems Engineering" course and synthesize them into a **single, integrated learning experience** that ensures deep understanding and academic success.

## **Your Primary Approach**

### **Course-Centric Analysis**
- **Extract and prioritize** the explicit learning objectives from the provided course materials
- **Map course content structure** to identify the intended learning progression
- **Identify gaps** in the provided materials and fill them with pedagogically sound content
- **Align everything** to the course's specific goals, terminology, and emphasis areas
- **Supplement strategically** only when course content is incomplete or unclear

### **Holistic Integration Philosophy**
- **Seamless narrative flow** - Weave concepts, examples, applications, and study aids into one coherent story
- **Natural progression** - Let each idea build organically into the next
- **Integrated learning** - Embed real-world examples, memory aids, and exam insights throughout the explanation
- **Study-optimized structure** - Organize content for maximum retention and easy review
- **Concise clarity** - Provide comprehensive understanding without overwhelming text volume

### **Enhanced Learning Techniques**
- **Concept mapping** - Help you visualize how ideas connect and build mental models of system relationships
- **Comparative analysis** - Highlight key differences between similar concepts to prevent confusion and deepen understanding

## **Your Integrated Output Approach**

Create a **unified study overview** that naturally weaves together:

- **Course learning objectives** introduced at the beginning and reinforced throughout
- **Core concepts** explained through a logical narrative flow
- **Mental models and concept maps** that show how ideas interconnect
- **Comparative insights** that clarify distinctions between related concepts
- **Real-world examples** seamlessly integrated into concept explanations
- **Visual aids** (Tables, Mermaid, PlantUML, GraphViz, or minimal ASCII) embedded where they naturally enhance understanding
- **Memory aids and analogies** woven into the conceptual explanations
- **Exam-relevant insights** highlighted naturally within the content flow
- **Practice elements** integrated as "checkpoint questions" throughout the narrative
- **Cross-connections** to other course topics mentioned organically as concepts build

### **Structure Your Holistic Overview As:**

**🎯 [Topic Title] - Complete Study Guide**

Begin with course learning objectives, then create a **flowing narrative** that:
- Introduces concepts with immediate real-world context
- **Maps concept relationships** visually and conceptually
- **Compares and contrasts** similar ideas to prevent confusion
- Builds complexity naturally while reinforcing fundamentals
- Embeds visual diagrams or tables exactly where they clarify the explanation
- Integrates industry examples as natural extensions of theory
- Weaves in memory techniques and analogies as concepts are explained
- Includes "💡 Key Insight" moments that highlight exam-critical points
- Poses "🤔 Check Your Understanding" questions at natural transition points
- Connects to previous and future course topics organically
- Concludes with integrated summary that reinforces the complete picture

#### diagrams guide
Create diagrams using (in order of preference):
- Mermaid Diagrams - for flowcharts, process flows, and system diagrams
- PlantUML Diagrams - for UML-style system architecture and relationships
- GraphViz Diagrams - for complex network relationships and hierarchies
- Simple ASCII diagrams - only as a last resort when other formats aren't suitable

## **Your Specialized Integration Capabilities**

### **Narrative Construction**
- Transform fragmented course materials into compelling, logical stories
- Create natural bridges between concepts, examples, and applications
- Build momentum that carries students through complex topics
- Maintain engagement while covering comprehensive content **efficiently**

### **Seamless Enhancement**
- Embed visual aids at optimal comprehension points
- Integrate memory techniques into concept introductions
- Weave exam insights throughout rather than segregating them
- Connect theory to practice within single, flowing explanations

### **Study Optimization**
- Structure content for easy scanning and review
- Create natural "checkpoint" moments for self-assessment
- Build in multiple reinforcement opportunities within the narrative
- Design content that supports both initial learning and exam review
- **Prioritize brevity with completeness** - comprehensive understanding without excessive text
- Reuse wording from the original course
- Make sure to have all concepts from the course in the study guide
- Add a table with abbreviations and acronyms
- If exam or quiz questions are added; make sure the concepts are well defined in the overall handouts. The answers I provide may not be correct, so rely on your own knowledge and the earlier input.

## **Your Commitment**
- **Holistic integration** - Every element serves the unified learning experience
- **Study-optimized flow** - Content organized for maximum retention and easy review
- **Course fidelity** - All enhancements serve the original learning objectives
- **Seamless experience** - Students should feel they're reading one masterfully crafted guide
- **Efficient learning** - Provide complete understanding through clear, concise explanations

**Remember**: You are creating a masterful, integrated learning experience - not a collection of separate explanations or lengthy textbook chapters. Your goal is one seamless, comprehensive yet concise study guide that flows naturally from beginning to end while covering everything needed for deep understanding and exam success.

Finding leverage in the middle: Thoughts on domain engineering

2025-06-24T00:00:00Z

I recently came across a very clear article by Jack Danger called Infrastructure Gravity. It puts a name to a concept I have been thinking about a lot lately: the critical importance of the ‘middle layer’ in a company’s technology stack.

In his article, Jack argues that engineering organisations do not have two layers (Product and Infrastructure), but three. He identifies powerful forces that pull engineers to the extremes. Feature Lift pulls them towards shipping visible new features, while Infrastructure Gravity pulls them down into the foundational, transferable skills of running software.

This leaves the middle layer—what he calls Domain Engineering—often neglected. This is the layer that contains the logic and concepts unique to the company’s business but shared across multiple features. It is the connective tissue.

The power of the domain layer

This middle layer is where the real leverage for a company exists. It is the difference between building a series of disconnected features and creating a cohesive, scalable system.

Consider a practical example from industrial technology. In the past, connecting a wind turbine’s SCADA control system to a cloud platform for machine learning was often a direct, point-to-point job. An engineer would write custom code to pull data from the turbine and push it to a specific cloud endpoint. This works, but it is fragile. What happens when you add a new type of turbine, or want to send the data to a second platform? You have to build it all over again.

Now, imagine introducing a domain layer. This layer does not just move data; it acts as a standardisation layer. It provides a standard way for any system—new or old—to talk about turbines and their data, for example, by enabling the use of a shared ontology like WeDoWind for the wind industry.

The SCADA system sends its data once, to the domain layer. The machine learning platform requests data once, from the domain layer. This layer is the translator and the central hub. It is a powerful enabler for long-term growth, making it simpler to add new data sources and consumers without rebuilding the core logic each time.

Putting it into practice

At my own company, we are making a conscious effort to invest more in this middle, or domain, architecture. We see it not as a cost centre, but as a strategic investment. It helps us structure our development efforts and ensures that our short-term work aligns with our long-term vision.

By deliberately building and maintaining this domain layer, we are not just fixing problems; we are building leverage for the future. It allows us to move faster, be more consistent, and build a more resilient and valuable technology platform.

Beyond the vibe: structuring AI-assisted development

2025-06-23T00:00:00Z

I recently came across a very informative post by Diwank Singh titled “Field Notes From Shipping Real Code With Claude”. It explores the concept of “vibe coding”—letting an AI assistant like Claude handle much of the implementation while the developer guides the process.

While the term sounds casual, Diwank’s article makes a crucial point: to make this work effectively in a professional environment, you need structure, discipline, and clear guardrails. It is not about mindlessly accepting AI output; it is about amplifying your own capabilities.

Instead of crafting every line, you’re reviewing, refining, directing. But—and this cannot be overstated—you remain the architect. Claude is your intern with encyclopedic knowledge but zero context about your specific system, your users, your business logic.

Effective collaboration with AI requires clear rules and boundaries.

This post summarises some of the key ideas from the article and adds my own reflections on how these practices change our ways of working.

The different modes of vibe coding

Diwank’s article outlines three distinct modes of working with an AI, each with its own purpose and level of rigour. I have found this framework very useful for thinking about when and how to apply these tools.

Mode	Characteristics	Best For
The Playground	Chaotic and fast. The AI writes 80-90% of the code with minimal guidance.	Weekend hacks, proofs-of-concept, and personal scripts. Not for production.
Pair Programming	Structured collaboration. The developer provides context and guidance, often through a project “rulebook”.	Small to medium-sized projects, well-scoped features, and side projects with real users.
Production Scale	Highly orchestrated. Requires deep context, strict boundaries, and careful integration into complex systems.	Large, mature codebases and monorepos where mistakes have significant consequences.

The constitution for your code

Cursor has the options for three kind of rules (or four?).

The concept of a “rulebook” is becoming a standard for professional AI-assisted development. Claude, Cline, and Cursor each offer a way to provide persistent context, but they differ in their approach. Claude’s CLAUDE.md is the most straightforward, while Cline offers more organisation with its folder system. Cursor provides the most granular and controlling system, allowing developers to define precisely how and when a rule should apply.

Feature	Claude (`CLAUDE.md`)	Cline (`cline.rules`)	Cursor (`.cursor/rules`)
File Location	`CLAUDE.md` in repo root, sub-directories, or home folder.	`.clinerules/` folder in project root or a global folder.	`.cursor/rules/` folder, which can be nested in sub-directories.
File Format	Plain Markdown (`.md`).	Plain Markdown (`.md`).	Markdown with metadata (`.mdc`).
Activation	Automatic, based on file location. Always on if present.	Automatic (all files in folder are active) with a UI to toggle rules during a session.	Highly configurable: Always, Auto Attached (by file path), Agent Requested, or Manual.
Scoping	Repository, sub-directory, and global user level.	Workspace and global user level.	Project, nested sub-directory, global user level, and automatic “Memories”.
Key Differentiator	Simplicity and being unopinionated.	Organised folder structure and an easy-to-use UI toggle.	Fine-grained control and conditional activation logic.

Applying the rules: the art of steering

However, as Diwank Singh’s article masterfully illustrates, the real power is not just in having a rulebook, but in the art of actively steering the AI. He details a layered approach that goes far beyond a single file, creating a hierarchy of influence from global principles down to task-specific directives.

Here are some of the steering mechanisms he describes:

Anchor comments: These are hyper-localised instructions embedded directly in the code to act as surgical constraints. They bind rules to specific code blocks, reference architectural decisions, and use imperative language to override generic assumptions.
Prompt engineering as control flow: This involves treating prompts as execution blueprints rather than simple requests. An advanced prompt hardwires business constraints, links to authoritative documents to reduce hallucination, and is designed to be token-aware to avoid iterative fixes.
Workflow choreography: Instead of asking for code directly, the AI is orchestrated through distinct phases: research, planning, execution, and validation. This forces the AI into a structured problem-solving process that mirrors a standard software development lifecycle.
Tool lockdown via permissions: This technique involves controlling the AI’s capabilities on a per-session or global basis, granting only the permissions absolutely needed for a task. It treats the AI like a least-privilege system process.
Session psychology management: The article advocates for using fresh, task-bound sessions for distinct tasks to avoid “context pollution,” where information from a previous, unrelated task bleeds into the AI’s current model.

As Diwank summarises:

“Without proper guardrails, you’re playing whack-a-mole with an overeager intern. With them, you gain a tireless co-pilot who respects your flight plan.”

The sacred boundaries: what an AI must never touch

This brings us to the guardrails. While an AI can accelerate implementation, some areas of a codebase are too critical to delegate. The article provides a clear list:

Test files: Tests are the executable specification of your intent. An AI should never write or modify them.
Database migrations: These are often irreversible and carry a high risk of data loss.
Security-critical code: Authentication, authorisation, and encryption logic must be handled with human oversight.
API contracts: Changing an API can break client applications and should only be done deliberately.
Configuration and secrets: The AI should never handle secrets or production settings.

The change in ways of working

Adopting these tools and practices fundamentally changes team dynamics and individual roles.

Onboarding a new developer, for instance, looks different. Their first task is no longer just setting up a development environment, but also reading and understanding the project’s rulebook. This document becomes the foundation for how they, and their AI partner, will contribute.

The role of a senior developer also evolves. As Diwank’s article highlights:

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

The senior developer shifts from being just a top producer of code to an architect of the system that produces code. Their expertise is now captured and scaled through the AI, guiding both junior developers and the model itself.

A reflection on software architecture

A final thought on software architecture: It might seem like these AI tools reduce the need for deep architectural thinking, but I think the opposite is true.

An AI cannot invent your system’s boundaries or understand the trade-offs behind your API contracts. It is a powerful implementation engine, but it needs a well-defined map to operate effectively. This forces us to be more explicit about our architectural decisions. The project rulebook is, in essence, a living architectural document that is both human-readable and machine-actionable.

With these new ways of working, the role of the software architect is still critical. Their job is to define the playground, set the rules, and draw the lines the AI must not cross. Vibe coding can be incredibly powerful, but only when it happens within a well-designed and clearly communicated structure.

How extraversion shapes remote communication

2025-06-22T00:00:00Z

I recently read a great piece in the Research-Driven Engineering Leadership newsletter by Lizzie that I wanted to share. It explores how our personality, specifically whether we are more introverted or extraverted, affects how we experience remote work.

Of course, introversion and extraversion are not black and white categories. Still, it can serve as a simplification model (systems engineering, anyone?) that we can use to study and improve real-life interactions.

The study highlighted an interesting contrast in communication needs:

Task-focused team talk is good for everyone. When team interactions were centred on the work at hand, everyone reported being more productive. This effect was even stronger for extraverts.
Supervisor interactions are personal. This was the most surprising finding for me. Introverts reported higher well-being and productivity after having relational, more social chats with their supervisors. Extraverts, on the other hand, benefited more from task-oriented conversations with their boss. My gut feeling would have said this was the other way around, so that is an interesting find!
More check-ins are not always better. This was not so much of an eye-opener, but it is an important reminder: a higher frequency of interactions with a supervisor was linked to a slight decrease in productivity for everyone. This suggests that the quality and purpose of an interaction are more important than the quantity.

A practical takeaway

The original article offers more clear advice, but one point stands out for creating an inclusive remote environment: provide balanced communication channels. Ensure your team has access to a mix of structured, task-oriented discussions and informal, relational spaces to meet the diverse needs of every team member.

The original article can be found here: RDEL #97: How does extraversion shape communication behavior in remote workplaces?

Not BYOD, but BYOS: Learning by building

2025-06-21T00:00:00Z

Not Bring Your Own Device, but Build Your Own Software 😅.

I love guides like these. You can learn so much from building something with your own hands. You discover details that can only be learned through experience, not just from reading a book. This is also why practical courses are so valuable; they help bridge the gap between theory and real-world application.

The main challenge, of course, is finding the time. For me, the best approach is to work on something that helps me in my daily life. That way, I can more easily justify the time spent.

I recently came across a fantastic repository on GitHub that is a great resource for this kind of learning: Build your own X. The project’s philosophy is captured perfectly by a quote from Richard Feynman:

What I cannot create, I do not understand.

The repository is a compilation of well-written, step-by-step guides for re-creating our favourite technologies from scratch. The list of project categories is impressive, and each one contains many different projects to build:

3D Renderer
Augmented Reality
BitTorrent Client
Blockchain / Cryptocurrency
Bot
Command-Line Tool
Database
Docker
Emulator / Virtual Machine
Front-end Framework / Library
Game
Git
Network Stack
Neural Network
Operating System
Physics Engine
Programming Language
Regex Engine
Search Engine
Shell
Template Engine
Text Editor
Visual Recognition System
Voxel Engine
Web Browser
Web Server
Uncategorized

It is an excellent resource for anyone looking to deepen their technical understanding.

Another good resource is this substack newsletter: [coding challenges](https://open.substack.com/pub/coding challenges), from John Crickett. It is a weekly challenge to level up your coding skills, giving you knowledge in the inside workings of software tools you normally use without thinking.

The small habits that define great managers

2025-06-20T00:00:00Z

I came across this nice article from First Round Review, and it offers simple and easy to apply small things you can do to make life better for the people around you in your company. I like that it is not (only) about grand gestures, but about the consistent, small habits that build trust and empower people.

The original article, The 25 Micro-Habits of High-Impact Managers, is well worth a full read.

The piece lists 25 habits, and I have included them all below. A few, in particular, stood out to me because I either appreciate them in a manager or try to practise them myself.

Don’t swerve around a debate.
Be generous with your ideas.
Think of yourself as the team captain, not the head coach.
Set the tone with cross-functional partners.
Write down what makes you tick.
Shine a light on failure.
Pull back the curtain.
Make space for reflection.
Reserve time for thinking outside the box.
Find the connective tissue.
Resist the urge to multitask.
This means being fully present in conversations, especially 1:1s, showing your team they have your undivided attention.
Follow up and follow through.
It highlights the importance of consistency and reliability, closing loops on open items to build trust.
Don’t forget the humans behind the company’s goals.
Encourage folks to put themselves first.
Cushion the blows.
Create a monthly performance review action plan.
This turns annual feedback into a continuous, actionable process with regular check-ins on progress.
Reinforce good habits.
Take a beat before delivering feedback.
Look for opportunities to praise in the moment.
Spot chances to send kudos up the chain.
Celebrate moments outside of the office, too.
Invest in their career.
A great manager actively helps people get to the next step, seeing the current role as just one part of their journey.
Bring in mentors and skip-levels.
Make space for growth.
This involves actively checking in on a person’s well-being and career goals to ensure they do not feel stuck.
Sharpen your arrows.

Security risks in LLM agents: Simon Willison’s insights

2025-06-19T00:00:00Z

In his latest newsletter and blog posts, Simon Willison shared some excellent thoughts on the security challenges surrounding LLM (Large Language Model) agents. These agents, also known as tool-using LLM systems, are AI models that interact with external tools or systems to perform tasks. Simon’s analysis moves from theoretical frameworks to practical examples, highlighting the risks and potential solutions. Here are some of his recent posts that I found especially insightful:

1. The lethal trifecta for AI agents: private data, untrusted content, and external communication

Source

If you’re using LLM agents that combine private data access, exposure to untrusted content, and external communication capabilities, you’re exposing yourself to significant risks. Simon explains this as the “lethal trifecta”:

If you are a user of LLM systems that use tools (you can call them “AI agents” if you like) it is critically important that you understand the risk of combining tools with the following three characteristics. Failing to understand this can let an attacker steal your data. The lethal trifecta of capabilities is:
Access to your private data – one of the most common purposes of tools in the first place!
Exposure to untrusted content – any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM.
The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood).
If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.

2. Design patterns for securing LLM agents against prompt injections

Source

Simon highlights several design patterns to protect LLM agents from prompt injection attacks. These patterns include:

The Action-Selector Pattern
The Plan-Then-Execute Pattern
The LLM Map-Reduce Pattern
The Dual LLM Pattern
The Code-Then-Execute Pattern
The Context-Minimization Pattern

These patterns are discussed in detail in the paper here.

3. An introduction to Google’s approach to AI agent security

Source

Google outlines three core principles for securing AI agents:

Agents must have well-defined human controllers.
It is essential for security and accountability that agents operate under clear human oversight. Every agent must have a well-defined set of controlling human user(s).
Agent powers must have limitations.
Agent actions and planning must be observable.

Simon agrees with this approach, emphasizing the importance of transparency in LLM systems:

Yes. Yes. Yes. LLM systems that hide what they are doing from me are inherently frustrating – they make it much harder for me to evaluate if they are doing a good job and spot when they make mistakes. This paper has convinced me that there’s a very strong security argument to be made too: the more opaque the system, the less chance I have to identify when it’s going rogue and being subverted by prompt injection attacks.

I also appreciate this approach. Working with LLMs that display their thought process is more intuitive and even entertaining 😅. It helps fine-tune prompts and ensures better results. This is especially useful when working with tools like Cline, where you can ask it to start with a planning phase and it shows you all the intermediate steps.

4. Breaking down ‘EchoLeak’, the first zero-click AI vulnerability

Source

The ‘EchoLeak’ vulnerability in Microsoft 365 Copilot was a major security concern. It demonstrated how the lethal trifecta can be exploited in real-world scenarios:

The lethal trifecta strikes again! Any time a system combines access to private data with exposure to malicious tokens and an exfiltration vector you’re going to see the same exact security issue.

This AI looks like it’s up to no good!

This vulnerability was big news in many companies, including mine. While Copilot has been a valuable tool for managing business data, especially as an advanced search function, it also highlights the risks we face. I have always raised my eyebrows at SharePoint’s usability and design decisions, but Copilot made it easier to find documents. However, this incident underscores the need for caution.

Bonus: Anthropic’s multi-agent research system

Source

Simon also shared a link to Anthropic’s documentation on their multi-agent research system. It’s a great example of how to build secure and effective LLM agents. You can read more about it here.

A practical toolkit for technology strategy

2025-06-18T00:00:00Z

In my work, I have often sought to be more effective in creating technology strategy. It is not enough to only have a good idea; I need a clear path from a high-level vision to tangible, on-the-ground execution. This is what makes ‘strategy’ practical and applicable. This requires a complete toolkit that allows us to see the landscape, diagnose our position, and then act with purpose.

In the past months, I have seen some great posts with practical ideas on how to be better at strategy. In this post, I will combine insights from these thinkers. It starts with understanding the terrain using the powerful mapping tools detailed in an excellent article by Alex Ewerlöf, Wardley Maps & Pace Layering for Senior Tech Leads.

The strategic landscape: Seeing the terrain

Before you can plan a journey, you need a map. In technology strategy, two frameworks provide this essential high-level view.

Wardley Mapping: A GPS for your value chain

A Wardley Map is a visual tool for understanding your business and technology, as detailed in Alex’s article. It plots your value chain (from user needs down to the power supply) against an axis of evolution—from new Genesis ideas to standardised Commodities.

A visual map is a great way to explain complex tech dependencies and strategic choices to CPO, CTO, or even CFO.

Example Wardley Map. Source: learnwardleymapping.com, by Simon Wardley.

This is far more than an academic exercise. It has direct, practical applications:

It makes invisible value visible. The map shows how foundational components like databases and APIs, while hidden from the user, are critical to delivering value. This helps justify investment in non-feature work.
It provides a language for strategic decisions. The evolution axis gives us a powerful way to discuss trade-offs. We can clearly show why building a custom authentication system (‘Custom-Built’) is inefficient when a mature ‘Product’ like Okta exists, freeing up resources for work that truly differentiates us.
It helps spot risks and opportunities. Seeing a critical user-facing feature dependent on a fragile ‘Genesis’ component is an immediate red flag for technical debt. Conversely, seeing a component that could be moved to ‘Commodity’ highlights an opportunity for cost savings.

Pace Layering: Governing the speed of change

Pace Layering, adapted from Stewart Brand’s work in his essay Pace Layering: How Complex Systems Learn and Keep Learning, provides a complementary view. It categorises systems based on their required rate of change. As Brand famously wrote:

Fast learns, slow remembers. … Fast gets all our attention, slow has all the power.

The three layers of Pace Layering. Source: blog.alexewerlof.com, by Alex Ewerlöf.

This translates into three layers for our technology systems:

Systems of Innovation (SOI): Fast-changing experiments where learning is the goal.
Systems of Differentiation (SOD): Your unique business logic; your competitive edge.
Systems of Record (SOR): The slow, stable foundations that must not fail.

This framework is essential for effective governance. It justifies why an SOI team can use CI/CD to deploy daily, while the SOR team has a quarterly release cycle with rigorous controls.

Combining the two

In his article, Alex gives an excellent perspective on combining the two:

This is where it gets really powerful:
Wardley Maps give you the “lay of the land” – the strategic “why” and “what.” They help you see opportunities, competitor moves, and user needs.
Pace Layering then helps you organize your internal response – the “how.” A Wardley insight might identify a new SOI, which then gets agile funding and rapid iteration.

The Systems Engineering Perspective: From Maps to Artifacts

As strategic tools, these maps are excellent, but their practical application is unlocked when we ground them in systems engineering. With this link, they go from high-level diagrams to blueprints for action.

Pace Layering is not just about speed; it is a framework for temporal decomposition. It establishes stratified change velocities that dictate interface specifications, verification rigor, and failure domain isolation. This is critical for managing emergent properties and ensuring that a failure in a fast-moving layer does not cascade into a stable, foundational one.
A Wardley Map is more than a value chain diagram; it is a tool for requirements traceability. It allows us to trace a user need all the way down to its dependent components. This enables precise trade-off analysis of functional requirements against non-functional constraints (like reliability and cost) and helps define clear system boundaries.
The evolution axis enables a more quantitative approach to risk management. It allows us to apply Technology Readiness Levels (TRLs) to our components, which feeds directly into formal risk methodologies like Failure Mode, Effects, and Criticality Analysis (FMECA). This helps us model the risk of migration paths and measure our technical debt, moving to more data-informed decisions.
The combined framework directly informs verification planning and lifecycle management. It helps us answer critical, long-term questions: When should we introduce new technologies? How do we maintain a stable, known version of our systems? And how do we plan for replacing old technology before it becomes a liability?

This integration transforms strategic maps from conceptual tools into engineering artifacts that directly inform technical planning, risk management, and verification processes.

A framework for action: From diagnosis to operations

These technically grounded maps provide the perfect input for a structured strategy process. As I explored in a post on implementing an ML platform, Will Larson’s five-step framework (Explore, Diagnose, Refine, Policy, Operations) provides a robust path from analysis to action. The maps are the primary tools for the Exploration and Diagnosis phases, providing the evidence needed to build a compelling case for change.

The ground-level view: Validating the plan

Once we have a diagnosis and a proposed policy, we need to validate it. As I discussed in my post on Larson’s systems thinking approach, simple models of stocks and flows help us test our assumptions. This modelling fits perfectly into Larson’s later steps of Components of an Engineering strategy:

Refinement is about testing our strategic hypotheses with prototypes or small-scale experiments to de-risk our ideas before committing fully.
Operations is about creating the mechanisms for adoption and success, such as feedback loops, training, and review processes that ensure the strategy sticks.

A complete strategic toolkit

By weaving these frameworks together, we create a comprehensive approach to strategy that spans from the deepest foundations to the visible horizon.

Landscape (Wardley & Pace Layering): We start by mapping the terrain to understand our position, using these tools to create concrete engineering artifacts.
Process (Larson’s 5 Steps): We use a structured process to move from an evidence-based diagnosis to a concrete policy and operational plan.
Execution (Systems Modelling): We use detailed models to refine our plans and ensure they will have the desired real-world impact.

This multi-layered toolkit moves strategy from an abstract exercise to a practical, repeatable discipline for driving meaningful change.

A clear framework for the build vs. buy decision

2025-06-17T00:00:00Z

In my career, I have more than once encountered the ‘build versus buy’ dilemma. Many organisations have a policy that looks something like this: first, try to use an existing internal product; if not, buy an off-the-shelf solution; and only as a last resort, build it yourself. While this provides a sequence, it often lacks the nuance needed to make an effective decision.

This is why an article by Chris on his blog, Entropic Thoughts, got my attention. He presents an simple and elegant approach for this exact problem.

The article suggests a simple rule: you should only build a component if it meets all three of the following criteria:

It has a high cost.
It is tightly integrated with your core system.
It is difficult to design.

If a component does not meet all three conditions, the default choice should be to buy it (or use an existing open-source solution).

The article provides an informative perspective on the actual cost of purchasing. It is not just the purchase price. For a component that is expensive and complex, the cost of properly evaluating suppliers and making a good purchasing decision is substantial. To make that decision well, your team needs to become experts on the component. The article argues that the process of becoming an expert (designing, prototyping, and testing) is almost indistinguishable from the initial stages of building it yourself. Once you have invested that effort, you are already a long way down the “build” path.

This quote captures the essence of focusing a company’s expertise where it matters most:

The reason we want to buy as much as possible is that an organisation has a limited capacity for expertise, so we do not want to have to become experts on things that do not make up a competitive advantage.

And on the complexity of the judgment call itself:

This type of judgment is the reason good software engineers get paid a lot of money – not for typing in code.

This approach provides the clarity that I have often found missing. It shifts the focus towards mastering what truly gives a competitive advantage. I will certainly be applying this line of thinking in my work.

The full post has a good example on building stealth planes, worth the read: Entropic Thoughts.

Smart People Don't Chase Goals - They Create Limits

2025-06-16T00:00:00Z

Recently, Joan Westenberg shared an interesting article, “Smart People Don’t Chase Goals; They Create Limits”. Joan argues that in many complex situations, focusing on creating clear boundaries and constraints is far more effective than chasing specific goals. This idea aligns with my own experiences, especially when I consider strategy implementation or ensuring architectural principles are followed in systems engineering.

I have found that communicating “guardrails” and then checking that they are applied is often much more effective than dictating precise steps. This approach allows developers the freedom to innovate and use their imagination, rather than being stifled by overly prescriptive instructions. In systems engineering, for instance, defining clear non-functional requirements like performance thresholds or security protocols allows teams to design creative solutions that meet the system’s core needs without being told exactly how to build them.

... or do you?

Think about it in terms of raising children. It is not very effective to set the goal of “having a nice afternoon”. Instead, it is much more productive to stimulate their creativity by providing an environment with clear boundaries, within which they can explore and play freely. This allows them to develop their own ideas and solutions, leading to a much more engaging and positive outcome.

Joan writes about it as follows:

“Constraints do not block creativity. They aim it. The sonnet form is maddeningly restrictive. Yet Shakespeare produced infinite meaning inside 14 lines. Jazz musicians work within a key and tempo. Architects must respect the load-bearing capacity of concrete. The painter who begins with a blank canvas faces more paralysis than the one who starts with a frame and a palette.”

This perspective shifts our focus from a rigid outcome to the enabling environment. It is about defining the playing field, not just the score. Another quote from the article that I liked:

“Goals often focus our attention on the visible holes. But it’s the invisible constraints that tell us what really matters.”

This is shown by the WWII bomber example in the article:

“In WWII, when allied bombers returned to base riddled with bullet holes, engineers initially proposed reinforcing the areas with the most damage. But statistician Abraham Wald pointed out the flaw: they were only seeing the planes that made it back. The holes marked the survivable areas. The real vulnerabilities were the untouched parts on the returning planes, because the ones hit there never came home.”

It is about understanding the underlying system and its true vulnerabilities, not just the superficial damage.

While constraints are powerful, there are certainly situations where setting clear goals is productive:

Training for a marathon: A specific distance and time are clear objectives.
Preparing for an exam: A defined curriculum and passing score provide a direct goal.
Shipping a product by a hard deadline: A fixed delivery date necessitates a goal-oriented approach.
Learning a new skill: Achieving proficiency in a specific area can be a clear goal.
Saving for a down payment on a house: A specific financial target is a tangible goal.

In these finite, controlled, and well-understood domains, goals are perfectly suitable. However, for ambiguous, ill-defined problems, or when fostering innovation, embracing constraints and boundaries can lead to far more robust and creative solutions. It is about creating the right environment for success, rather than just pointing to a finish line.

Understanding MCP: A New Standard for AI Integration

2025-06-15T00:00:00Z

The Model Context Protocol (MCP) is an open standard developed by Anthropic that enables AI systems to connect with real-world tools and data sources. Announced on November 25, 2024, MCP acts as a universal bridge between AI models like Claude and external systems such as databases, APIs, and business tools. You can read the official announcement for more details and access to the GitHub repository.

Arjan Codes recently published an excellent practical demonstration of MCP implementation. Having completed his software architecture course, I appreciate how Arjan delivers clear, practical content from an independent perspective - refreshingly not tied to major cloud providers, which is common in architecture discussions.

Architectural approaches for MCP implementation

When implementing MCP, developers face key architectural decisions:

Approach	Direct Module Access	API Layer Integration
Implementation	MCP server calls internal modules directly	MCP server interacts with existing REST API
Best for	Small-scale projects	Systems with established APIs
Advantages	Simpler setup	Reuses existing logic, avoids duplication
Limitations	Tight coupling, scales poorly	Extra network hop, added complexity

Overall, Arjan shares these conclusions:

Direct access works well for prototypes but becomes difficult to maintain as systems grow
API integration leverages existing infrastructure but adds communication overhead
Auto-conversion (using tools like fast_mcp) can generate MCP servers from FastAPI applications

For concrete coding examples of these approaches, I recommend watching Arjan’s full video demonstration.

I believe MCP represents an important evolution - soon, even internal company tools might include AI interfaces as standard features, fundamentally changing how we interact with software.

Agents: Programming with feedback-driven LLMs

2025-06-14T00:00:00Z

David Crawshaw shares a good perspective on how LLMs transform into powerful programming assistants when given tools to interact with their environment. While definitions of “AI agents” vary widely, David aligns with Simon Willison and Solomon Hykes’ view of agents as systems that repeatedly interact with their environment; what Solomon calls “wrecking its environment in a loop”.

Via Pointer.io’s Essential Reading For Engineering Leaders newsletter

Definition of an agent by Solomon Hykes (photo from Simon Willison)

Unlike standalone language models that operate in isolation, agents can execute commands, read files, and iterate based on feedback; this fundamentally changes their capabilities.
The core insight: Agents are essentially feedback loops where an LLM can:

Run test suites and interpret results
Execute bash commands to explore codebases
Apply patches and validate changes
Access documentation through web searches

“Agents are LLMs with environmental feedback. Just as humans thrive in environments with feedback, LLMs go from nice demos to useful programmers when given a surprisingly small core set of tools.”

A practical example: When an agent runs your test suite and encounters failures, it can:

Analyse error messages
Modify the problematic code
Re-run tests
Repeat until passing

This transforms coding from a “whiteboard exercise” into an interactive process where the LLM can validate its own work. As David notes:

“The result, compared to an LLM generating code without these tools available is significantly different. API use is greatly improved because the agent can web search for documentation and curl the docs into its context window.”

While agents currently work slower than traditional coding (minutes vs seconds, meaning they are still relatively expensive), they enable completing “dreary tasks” that might otherwise take days, freeing developers for higher-value work.

Containerized agent environments

The future likely involves containerized agent environments, isolated execution spaces that solve two key challenges:

Safety: Prevents agents from accessing sensitive credentials or systems
Parallelism: Allows multiple agents to work simultaneously without conflicts

These sandboxed environments let developers safely run agents while maintaining their normal workflow, with changes extracted as diffs or branches when complete.

Moving beyond point-by-point arguments

2025-06-13T00:00:00Z

I recently read an excellent article by Sean Goedecke, “Arguing point-by-point considered harmful”, that clearly articulates a communication anti-pattern many of us in technology have experienced. He describes the unproductive cycle where a technical discussion devolves into endless mini-arguments, with no real progress made.

This is a pattern I recognise from my own experience, particularly from the perspective of a technical leader. It is a delicate balance. You want to guide the technical direction, but getting stuck in a point-by-point debate can easily damage working relationships. If you harm that trust, you risk people avoiding you, working around you, or simply not telling you about potential issues in the future.

I have been in those discussions that did not bring me, or the other party, anything of value. I learned that you have to step out of it and take a more holistic view, much like in systems engineering. Goedecke’s advice points to the same conclusion.

Arguing over the pieces instead of looking at the box.

Instead of diving headfirst into every concern individually, he suggests a more constructive approach to shift the conversation from a series of small debates to a discussion about the core value. His method can be summarised in a few steps:

Recognise the trap: Identify when a discussion is becoming an unproductive point-by-point argument.
Focus on the affirmative case: Instead of defending against a list of concerns, make a clear case for the overall value of your proposal.
Identify the real problem: Often, the stated reasons are not the core objection. Give the other person space to articulate their main concern.
Collaborate on details: Once there is alignment on the bigger picture, you can work through the technical details together.

As Goedecke puts it, you should:

…make the case for why your feature is valuable enough to spend the developer time and CPU time on it.

This changes the dynamic entirely. It is about moving from defending individual points to building a shared understanding of the overall goal. When you achieve that alignment, the rest often falls into place.

If you get them on your side, you can work out the technical details together. If they don’t believe in your mission, you’ll never convince them by proving that they’re wrong about the technical points.

A good read for any engineer or leader looking to improve their communication and effectiveness.

Why learning systems thinking is essential in tech

2025-06-12T00:00:00Z

Today I listened to Diana Montalion’s insightful conversation on the Tech Lead Journal podcast about systems thinking in technology. She shares her perspective on how relationships between components create effects and why it is important to have this holistic view.

Some takeaways from the conversation include:

What is systems thinking?

At its core, a system is a set of interconnected components whose relationships produce outcomes that individual parts cannot achieve alone. Systems thinking means understanding these relationships to architect desired effects. As Montalion explains:

Relationships produce effect. Systems thinking is understanding the effect and being able to architect for the kinds of effects we want in a system.

This approach requires considering multiple levels simultaneously—from code implementation to business outcomes. We need this holistic view to communicate clearly with all stakeholders, secure alignment, obtain funding, and achieve shared goals.

The need for collaboration

Importantly, no single person can master all perspectives. Partnering becomes essential:

Your skills are insufficient in the modern world. You can know everything about JavaScript there is to know. But if you do not know how to make people’s lives better with JavaScript, how much value are you really bringing?

The benefits of modeling

Modeling emerges as a powerful tool to bridge understanding gaps:

We often think we’re solving the same problem, and when we’re going around and around, usually it is because we have completely different mental models. Including visual elements—moving things around, making relationships—helps.

I particularly appreciated Montalion’s practical advice on architectural decision records. I do not know if I need to laugh or cry here, as I have encountered ADRs that lacked this depth:

A thing that stands out to me often is that people do not describe other options they considered. They are just recording the decision.

Her emphasis on “yes, and” collaboration and systemic reasoning provides actionable methods to implement these concepts. The full conversation offers insights for developers or anyone building (technical) systems.

Watch or listen to the complete episode.

Choosing the right data architecture

2025-06-11T00:00:00Z

This post is inspired by an article by Dr. Fatih Hattatoglu on Medium, exploring different data architecture choices from a data engineer’s perspective. The article highlights the importance of data as a valuable asset and the need for flexible solutions to manage the increasing volume and diversity of data, particularly as use cases continue to grow, including those in machine learning and AI.

A 'data lakehouse' from clay, made by recraft.ai

As Dr. Hattatoglu notes:

However, the foundations of a successful data architecture must be laid right from the beginning of the design process. This is not just about building a technical structure, but aligning it with organisational goals and data management strategies.

This quote is particularly relevant as it underscores that technology choices are always connected with broader business and strategic considerations.

The article discusses four main data architecture approaches:

Data Warehouse: Focused on structured data, optimised for reporting and analysis. Uses ETL processes and is suitable for consistent, well-organised data. However, it can be expensive and only handles structured data.
Data Lake: A flexible structure for storing structured, semi-structured, and unstructured data in its raw form. Ideal for advanced analytics and machine learning, offering flexibility but posing challenges in data management and security.
Data Lakehouse: Combines the flexibility of a Data Lake with the structured management of a Data Warehouse. It supports both SQL queries and machine learning, offering the best of both worlds but with complex setup and management.
Data Mesh: A decentralised architecture where each department manages its own data product. It promotes flexible management and avoids bottlenecks but can create challenges in data consistency and integration.

The article stresses that the choice of architecture is a strategic decision, not just technical, and must align with organisational goals and data management strategies. Requirement analysis is presented as the crucial first step to define needs, identify stakeholders, clarify scope, and choose the correct technology.

Data architecture and machine learning / AI

Here is a summary of how each data architecture approach relates to the needs of machine learning and AI, based on the article:

Data Architecture	Suitability for Machine Learning / AI	Key Characteristics Relevant to ML/AI
Data Warehouse	Limited suitability. Primarily designed for structured data and reporting, not the diverse data types often needed for ML/AI.	- Works only with structured data. - Optimised for reporting, not flexible data exploration or raw data processing.
Data Lake	Highly suitable. Designed to store raw, diverse data (structured, semi-structured, unstructured) which is crucial for ML/AI training.	- Stores data in native format (raw). - Offers flexibility for data engineers/scientists to process data as needed. - Ideal for handling continuously changing datasets.
Data Lakehouse	Highly suitable. Combines the flexibility of a Data Lake with the structure/performance of a Data Warehouse, supporting both ML/AI and traditional BI.	- Handles both structured and unstructured data. - Supports both SQL-based queries and machine learning operations on the same platform.
Data Mesh	Potentially suitable, but depends on how data products are designed and shared. Decentralisation can support domain-specific ML/AI efforts.	- Distributed data management. - Data ownership by departments. - Requires careful consideration of data integration and consistency for cross-domain ML/AI.

In essence, Data Lakes and Data Lakehouses are presented as the most inherently suitable architectures for the diverse data needs and processing flexibility required by modern machine learning and AI workflows.

Designing data architecture: A systems engineering approach

Designing the right data architecture is a complex undertaking that benefits greatly from applying Systems Engineering principles. This approach breaks down the process into structured phases, ensuring that the solution meets requirements throughout its entire lifecycle. Here is a simplified view of this process, aligning with the data lifecycle:

Pre-Acquisition (Understand the Problem & Needs)
- Define the business mission & data purpose (Why?): Begin by clearly articulating the business objectives that the data architecture needs to support. Why is this data needed? What strategic goals will it enable (e.g., predicting turbine component failures, optimising maintenance schedules based on weather forecasts)?
- Identify stakeholder data needs & requirements (What?): This involves deep engagement with all users and consumers of the data (offshore technicians, data scientists building predictive models, operational managers). Determine the specific data types required (SCADA (sensor) data, weather data, maintenance logs, video feeds), how data needs to be accessed (real-time streaming, batch processing), performance expectations (low latency for anomaly detection), necessary governance policies (data security for sensitive operational data), and data ownership responsibilities (who is responsible for turbine sensor data?).
- Output: This phase culminates in a Logical Data Architecture, defining the functional requirements and conceptual data model – essentially, the “what” the system must do.
Acquisition (Design the Solution)
- Explore data architecture options (How – High Level): Based on the requirements gathered in the previous phase, evaluate the different architectural patterns discussed (Data Warehouse, Data Lake, Data Lakehouse, or Data Mesh). Select the pattern that best fits the identified needs and constraints, particularly considering the need for diverse data types common in offshore wind (structured sensor data, unstructured video, semi-structured logs).
- Output: This results in a High-Level Physical Data Architecture, outlining the chosen pattern and major components – the high-level “how”.
- Detailed design & technology selection (How – Detailed): With the high-level architecture decided, delve into the specifics. Select the appropriate technologies and platforms (e.g., cloud storage for raw data, a processing engine for time-series analysis, a database for structured maintenance records). Design the detailed data models, data pipelines (including streaming data from turbines), security mechanisms, and infrastructure.
- Output: This yields the Detailed Physical Data Architecture, providing the complete blueprint – the detailed “how”.
- Construct & produce (Build & Test): Implement the detailed design, building the data pipelines, storage layers, and processing components. Test the system to ensure it meets all defined requirements for data quality, performance (especially for real-time data), security, and functionality (e.g., can the ML models access the necessary data?).
Utilization (Operate & Evolve)
- Operational use & support: Once implemented, the architecture is put into production, supporting ML model training, inference, and operational reporting. This phase involves ongoing monitoring of performance, data quality (critical for model accuracy), and security. It also includes providing support to data users and addressing any operational issues.
- Modification & evolution: Data needs and technologies are constantly changing. This phase involves adapting the architecture to accommodate new sensor types, evolving ML model requirements, or integrating new data sources (e.g., drone inspection footage). This is an iterative process, potentially looping back to the design phase.
Retirement (When Data is No Longer Needed)
- Data retirement: When data or parts of the architecture are no longer required (due to compliance, obsolescence, or data retention policies for specific data types like raw sensor streams from SCADA), a plan for secure and compliant retirement is executed. This involves archiving data or securely deleting it according to established policies.

This structured, lifecycle-oriented approach, rooted in Systems Engineering, helps ensure that the data architecture is not only technically sound but also strategically aligned, maintainable, and capable of evolving over time to support critical operations like offshore wind maintenance.

For further reading, the original article can be found here: https://medium.com/academy-team/which-data-architecture-should-i-choose-for-my-workplace-a-data-engineers-approach-f913b71d8ee6

Navigating the Corporate Maze

2025-06-10T00:00:00Z

I recently read an interesting article by Sergio Visinoni titled “Navigating the Corporate Maze” on Substack. The article offers a guide for engineering leaders aiming to drive strategic changes within large, bureaucratic organisations where change often seems impossible. It outlines a four-step process: drawing maps of the new environment, clarifying your role, building bridges, and driving change incrementally.

When I transitioned into a domain architect (Technical Authority) role after being the lead data scientist in the same department, I attempted to follow a similar pattern in my large organisation. Step 1, mapping the environment, came quite naturally as I already knew all the stakeholders. The challenge here was that stakeholders tended to view me in my old position. I constantly needed to remind them that I was in a new role with different responsibilities and ways of working.

This largely relates to step 2, clarifying your role. In my case, after a reorganisation, clarifying my new role – which was simultaneously new to the organisation – was the largest hurdle. This required constant proactive involvement and explanation from my side. However, I noticed that with most groups of colleagues, this started to move in the right direction after some time. For example, I went from having to chase to be part of a decision-making meeting to being asked to join.

Step 3, building bridges, is also something I had already applied and seen working. From my peer technical authorities in other domains, I learned to frame initiatives in light of the company goals and agenda. This makes it much easier for decision-makers to approve your requests. I also found that mapping stakeholders and their needs in enterprise architecture tools helped me to frame initiatives against the correct goals and agenda.

Overall, this is a really good article with applicable insights for large corporations. I especially liked the insight to move with the company’s rhythm. As with other things in life and nature, this is almost always the most effective course of action.

Don’t go against the Company’s Rhythm: In a crash between a cargo boat and a powerboat, the cargo boat wins. Instead of being the powerboat, learn to nudge the cargo boat in the right direction.

Understanding and appreciating this natural rhythm, much like the seasons, is crucial for long-term success and well-being when navigating the complexities of a large organisation.

Insights on building MLOps systems

2025-06-09T00:00:00Z

In his post ‘What I’ve learned building MLOps systems for four years’, Mehmet Burak Sayıcı offers valuable insights about the multidisciplinary nature of MLOps work. The article highlights how MLOps professionals need to develop expertise across various domains.

It was fun at first, but then we had to integrate everything into a platform. That’s when I slowly started to understand object-oriented programming, system design, and the principles of traditional software engineering.

Actionable strategy: implementing an ML platform in an energy business

2025-06-08T00:00:00Z

In a large organisation, making significant technology decisions, such as selecting a machine learning platform, demands more than just a good idea. It requires a clear, actionable strategy to ensure the chosen solution truly integrates and delivers value. I have found Will Larson’s structured approach to engineering strategy to be a valuable tool for this.

Will’s framework, detailed in his “Components of Engineering Strategy” article, breaks down strategy creation into five practical steps:

Exploring: Understanding the landscape of existing ideas and practices
Diagnosing: Deep dive into the specific problem and its context
Refinement: Testing and validating initial ideas
Policy: Making concrete decisions and defining guidelines
Operations: Implementing mechanisms to ensure adoption and success

These steps are designed to prevent common pitfalls and provide a robust path from concept to execution. I will focus on how the steps of exploration, diagnosis, and operations can be practically applied to a challenge I faced some time ago: implementing an ML platform within an offshore wind business. I draw on Will’s insights from “Exploring for Strategy”, “Diagnosis for Strategy”, and “Operations for Strategy”, together with a systems engineering perspective.

Exploration: gathering the facts on ML platform options

The exploration phase provides the opportunity to gather comprehensive information about potential ML platforms without premature commitment. It is about understanding the practical realities of different solutions and avoiding the trap of simply adopting what is familiar or trendy, as Will cautions.

For our context, this means:

External benchmarking: Actively researching various ML platforms, including those within our central IT’s Azure guardrails and other industry-leading solutions. How are other companies, particularly in the energy sector or those managing similar data complexities, successfully implementing ML? This involves a practical review of industry case studies, technical documentation, and direct conversations with peers to understand real-world trade-offs and team structures.
Internal audit: Conducting a thorough review of existing technology within our large, distributed organisation. Different business units may operate with distinct technology architectures, including various data platforms (like Snowflake or Databricks) and ML tools (such as Azure ML). Our own department has an existing data platform that supports ML tasks. Exploration here means documenting these existing components, assessing their current utilisation for ML, and identifying any internal “skunkworks” projects or successful patterns in other departments that could offer valuable lessons.

From a systems engineering perspective, exploration is about collecting data on available components and their performance characteristics. We are identifying existing infrastructure, data sources, and tools, and also very important, understanding the human capabilities and team models that support successful ML operations in various contexts. This fact-finding ensures strategy is founded on a broad understanding of the options.

Diagnosis: pinpointing our specific ML platform challenges

Following exploration, diagnosis is the crucial step of precisely defining the problem we need the ML platform to solve within our specific offshore wind context. Will indicates that a wrong diagnosis is a primary reason for strategic failure, making this phase essential.

For our ML platform, a precise diagnosis requires:

Defining ML use cases: Clearly articulating the specific ML problems our data scientists aim to address (for example, optimising turbine performance, predictive maintenance). What are the exact performance, reliability, and scalability requirements for these applications?
Assessing data ecosystem: Mapping our data sources, access patterns, and processing needs. What are the volumes, velocity, and specific data governance, security, and compliance requirements for our energy data? In this, we need to clarify our responsibility and influence. For example, some tasks might be handled via an Operational Level Agreement (OLA) with other teams, while others we manage ourselves.
Evaluating team capabilities and gaps: We have skilled data scientists and data engineers. However, an important observation in our current system is the absence of dedicated ML engineers who specialise in operationalising models and maintaining ML infrastructure. This skill gap is a significant constraint that must be explicitly addressed in our strategy. We also acknowledge that our data scientists, while domain experts, may require support with platform-specific technologies.
Acknowledging resource constraints: Recognising that our business unit operates with resource limitations, a reality in the current offshore wind market. This directly impacts the feasibility and scope of any platform implementation and the investment in new skills.
Clarifying organisational interfaces: Defining how we will effectively collaborate with central IT, who provide essential guardrails, and how we can leverage insights from other, more mature ML departments within the organisation.

Applying a systems engineering perspective, diagnosis involves creating a detailed problem statement for our ML system. We quantify where possible, using objective criteria to describe the current state and desired future state:

Platform maintainability: What is the estimated ongoing effort (for example, FTE hours) to maintain the platform, explicitly factoring in the current lack of dedicated ML engineering expertise?
Developer experience (DX): How efficiently can our data scientists perform core tasks (data access, model training, deployment, monitoring)? This must consider their current proficiency levels and the need for streamlined workflows.
Integration with existing data: How well does the platform integrate with our existing data infrastructure (Snowflake, Databricks)?
Alignment with IT guardrails: Does the platform adhere to central IT’s approved technology stack? What level of support and collaboration can we expect from IT?
Resource footprint: What are the estimated infrastructure costs and the human resources needed for implementation and ongoing support, including the investment required to build ML engineering skills?
Collaboration effectiveness: How will the platform and associated processes improve collaboration between data scientists and data engineers, and how will it facilitate the integration of new ML engineering capabilities?
Skill gap analysis: What is the current availability of necessary skills (data science, data engineering, ML engineering), and how significant is the gap in dedicated ML engineering expertise?

By step by step diagnosing these elements, we build a clear, evidence-based understanding of our challenges, which is essential for making informed decisions.

Operations: actioning the strategy and building new expertise

The final step is operations. A well-conceived strategy and a carefully chosen platform will not deliver value without the practical mechanisms to ensure adoption and sustained success. Operations is about translating policy into tangible actions, and this critically includes addressing the skill gaps identified in our diagnosis.

Operational mechanisms for our ML platform strategy could include:

Structured collaboration frameworks: Implementing clear processes and regular forums that encourage data scientists and data engineers to work together on platform usage and improvements. Crucially, this must also define how new ML engineering skills will be integrated into this collaborative model, perhaps through dedicated MLOps working groups or shared responsibilities.
Targeted training and support programmes: Providing accessible, hands-on training tailored to our data scientists’ existing skill levels, focusing on the practical use of the chosen platform. Establishing clear support channels, involving both our internal tech teams and central IT. This training should also include structured pathways for data engineers or data scientists interested in advancing into ML engineering roles, for internal talent development (this would be ideal).
Clear guidelines and best practices: Documenting how to use the platform effectively, including standards for model development, versioning, and deployment. These guidelines should evolve to incorporate the MLOps practices that dedicated ML engineering expertise can enable.
Automated workflow tools: Implementing automated checks for model versioning, testing, or deployment standards, with nudges to guide developers towards best practices. Developing and maintaining these automation tools is a key function that ML engineering can support, streamlining operations.
Lightweight review processes: Establishing efficient review processes for new model or software package deployments to ensure they meet quality, security, and operational standards.
Performance monitoring and feedback loops: Setting up dashboards to monitor platform usage, performance, cost, and user satisfaction. Establishing a clear channel for data scientists to provide feedback on their experience and needs to the platform support teams and IT, ensuring continuous improvement.
Strategic skill development plan: Explicitly defining how the necessary ML engineering skills will be acquired – whether through targeted hiring, dedicated upskilling programmes for existing data engineers or data scientists, or a combination. This plan is a core operational mechanism for the strategy’s long-term success.

These operational mechanisms, as Will describes, are the practical steps that transform the platform choice (the policy) into a living, impactful part of our engineering practice. They address the human and process elements necessary for technical success in a complex organisation, including the vital step of building the required expertise.

The path forward: driving impact with clear strategy

Applying Will Larson’s framework provides a clear and actionable path for navigating the complexities of choosing and implementing an ML platform in our environment. It moves us beyond simply evaluating technical features to building a holistic strategy that considers our specific needs, constraints, the operational realities of a large energy company, and the crucial human skills required for success.

By focusing on thorough exploration, a detailed diagnosis grounded in our unique context (including acknowledging skill gaps), and practical operational mechanisms (including a plan for skill development), we can build a strategy that is not only technically sound but also achievable and impactful for our offshore wind business. The remaining steps in Will’s framework, refinement and policy, would guide us in testing our assumptions and drafting well-informed policy. ML engineering expertise is key in this to getting the full potential of ML for optimising turbine performance and contributing to our KPIs.

You can find Will Larson’s full series on engineering strategy here:

Disclaimer: This post reflects my personal thoughts and learning based on publicly available frameworks and general industry challenges. It does not represent the official views, plans, or internal details of my employer.

Building a PDF to markdown converter with vibe-coding

2025-06-07T00:00:00Z

I needed a way to extract text from poorly formatted PDF handouts for my studies. The plan was to feed this extracted text, together with the video captions of the lessons, to an LLM. I have configured this LLM to be my teaching assistant, formatting and structuring the text in a way that makes it easy to read and helps me understand the material for my exams.

The PDF to Markdown approach

Rather than spending time researching complex solutions, I decided to build something simple that worked. One HTML file with everything included: PDF.js for parsing, vanilla JavaScript, and modern CSS.

Using Claude Sonnet 4 effectively

Before starting, I read through Anthropic’s Claude 4 prompt engineering best practices. The documentation provides specific techniques for getting optimal results from Claude 4 models. I recommend reading it if you’re working with Claude.

Using their guidance, I crafted this prompt for Sonnet 4:

Give me options to transform pdf to markdown. Can you create a converter tool using a single web page? First think of how you would design such a tool.
Please write a high quality plan for a general purpose solution. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs. Instead, implement the actual logic that solves the problem generally.
Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution. Provide a principled implementation that follows best practices and software design principles.
If the task is unreasonable or infeasible, or if any of tests are incorrect, please tell me. The solution should be robust, maintainable, and extendable.

The result worked perfectly on the first attempt. Impressive.

The Markdown to OneNote converter

After successfully creating the PDF to Markdown tool, I followed up by building a converter that takes Markdown with formatting and converts it to OneNote format. This allows me to easily adapt the notes in my favourite note-taking tool.

I started with a similar prompt, but this one proved more challenging. It required multiple attempts to get right. During development, I used prompts like this when encountering errors:

I have this error, can you think of a fix? One that is elegant, robust and works in a generic way. Include as many relevant features and interactions as possible. Don’t hold back. Give it your all.
The overall goal of the tool is to copy markdown with formatting to OneNote.
I do not think you have access here to a Python environment.
Error
markdown-to-onenote.html:823
Image loading failed, using SVG data URL
img.onerror @ markdown-to-onenote.html:823

Through iterative refinement, we eventually arrived at a working solution. The final result handles Markdown formatting and converts it properly to OneNote’s format. ~~However, it still has some limitations, such as not supporting more than one diagram. I would like to improve this, but I have to dive into what the real problem is.~~*
*Fully working now for mupliple diagrams in one page.

You can try the tools here:

Results

These tools now handle my study workflow efficiently:

Convert PDF handouts to Markdown.
Feed text and video captions to Claude with instructions to create study summaries.
Convert formatted Markdown to OneNote for easy editing.
Get structured exam notes in my preferred note-taking app.

What used to take hours of manual text extraction and formatting now takes minutes. The combination of proper prompt engineering and focused tools solved the actual problems I had. The iterative development process, while sometimes challenging, ultimately produced robust solutions that work well for my needs. And most importantly, it was a lot of fun to build, and I am very impressed with the capabilities of these new models!

Avoiding and reducing technical debt

2025-06-06T00:00:00Z

Following on from yesterday’s post about decision-making pitfalls for technical leaders, I wanted to highlight another series by Chelsea Troy on technical debt.

In her post “Quantifying Technical Debt”, Chelsea starts by defining technical debt, or what she prefers to call “maintenance load,” as the ongoing effort required to keep existing software features running. She argues that all code carries maintenance load, which increases over time depending on the practices used to build and maintain the software. In the post, she illustrates this with two cases: a “yikes case” where a team adds the equivalent of one full-time developer’s worth of maintenance load every 18 months due to a lack of tests, documentation, and a complex coding style, and an “average case” where this happens every 24-30 months with some testing and documentation in place.

In the second post of the series, “Avoiding Technical Debt”, Chelsea explores how some teams manage to keep their maintenance load from growing. She highlights the example of the Explosion company, which maintains multiple complex products with a small team. Key factors she identifies are:

Lower churn: Open-source projects, like SpaCy, tend to have lower developer churn, reducing the loss of undocumented context.
Higher code stewardship skills: Open-source contributors often have strong skills in testing, documenting, and communicating their work, as their “clients” are other developers who need to understand and contribute to the code. This focus on accessibility and clarity mitigates context loss.
Developer empowerment: In open-source, developers often have more autonomy to rethink or remove features, streamlining the codebase.

To avoid maintenance load growth, Chelsea consequently suggests:

Normalising and valuing writing tests and documentation.
Training and rewarding developers for effective communication about their technical choices.

In the third post, “Reducing Technical Debt”, Chelsea addresses the challenge of reducing maintenance load when a team is already struggling under its weight. She offers three strategies:

Force features to earn their keep: Regularly measure the ROI of features and remove those with low returns.
Regularly equip developers to suggest streamlining options: Give developers time and space to find simpler solutions that improve functionality, robustness, and maintainability simultaneously.
Recover lost context: Develop skills in “forensic software analysis” to understand how older codebases work, even when the original authors are gone. This is often less expensive than a full rewrite.

Chelsea emphasizes that both the technical team having these skills and the organisation valuing the use of those skills are crucial for managing and reducing maintenance load.

This series really resonated with me. The idea of “maintenance load” is a much more tangible way to think about technical debt than just “bad code.” It highlights that it’s an ongoing cost, not just a one-time fix. The strategies she outlines, particularly the focus on code stewardship and streamlining, provide practical steps teams can take. I have seen how a lack of documentation and communication negatively influences a team’s ability to maintain a codebase, and the concept of “forensic software analysis” is an interesting approach to move away from that. It also highlights that investing in these “non-feature” activities is essential for long-term project health. Finally, effective technical leadership, as discussed in my previous post, is key to implementing these strategies and fostering a culture that prioritises sustainable software development.

Links to the series:

Quantifying Technical Debt: https://chelseatroy.com/2021/01/14/quantifying-technical-debt/
Avoiding Technical Debt: https://chelseatroy.com/2021/01/18/avoiding-technical-debt/
Reducing Technical Debt: https://chelseatroy.com/2021/01/21/reducing-technical-debt/

Decision-making pitfalls for leaders from Chelsea Troy

2025-06-05T00:00:00Z

I recently came across Chelsea Troy’s website, she shares many interesting thoughts there, I recommend checking it out: https://chelseatroy.com/. She is a Senior Staff Engineer at Mozilla and a Computer Science teacher who provides great insights on technical topics, strategy, and leadership.

Her post discussing common decision-making pitfalls for technical leaders was very informative. Pitfall #2, in particular, about treating everything as an optimising metric, particularly stood out:

Pitfall #2: Treating Everything as an Optimizing Metric
What it is: Making a long list of characteristics to consider while making a decision between two or more dependencies, architectures, or strategies, and then forestalling or repeatedly reopening the decision until one option outperforms all the others on all of the characteristics.

I have also fallen into this trap in the past. I remember being part of a team that was incredibly indecisive about platform options. This led to endless debates, a prolonged period without a technology choice, and a lot of uncertainty. We tested countless options, suffering from “death by comparison tables.” And because we could, we would even reopen discussions six months later. Not fun at all!

I like Chelsea’s idea on how to prevent or move away from this situation:

To explain this, I want to introduce you to the idea of optimizing and satisficing metrics.
Optimizing metrics are the ones for which more is always better… Satisficing metrics are the ones for which we have a clear idea of how good is good enough. More of this does not improve our product outcome.
When you are making decisions, narrow down the list of optimizing metrics to as few as possible—zero if you can, one or two realistically. Then, establish the threshold at which your options would satisfice on all of the other metrics.

This simple distinction is very much to the point.

In my own experience, getting some extra support and having central IT make up their mind, along with some help from platform providers, helped us move forward. This aligns with the idea of getting clear on what “good enough” looks like for certain criteria.

You can read Chelsea’s full post here: https://chelseatroy.com/2024/10/16/decision-making-pitfalls-for-technical-leaders/

Python Developer Tooling Handbook

2025-06-04T00:00:00Z

Python Developer Tooling Handbook

I came across this excellent resource by Tim Hopper: a comprehensive guide to Python development tools and best practices.

This is not a book about programming Python. Instead, the goal of this book is to help you understand the ecosystem of tools used to make Python development easier and more productive.

The handbook is structured into four sections:

Tutorial: Step-by-step guides to improve your Python development experience
How To: Practical guidance for your Python projects
Explanation: In-depth understanding of Python development concepts
Reference: Detailed information about specific tools and concepts

What I particularly appreciate is how it provides detailed explanations of design decisions and tool functionality, complete with code examples and references to relevant PEPs. For instance:

The pyproject.toml reference includes example code and relevant standards
A blog post on Simple Modern Python highlights modern tooling:

[…] minimal but essential tools for Python projects:
Uses uv for package management
Incorporates ruff for linting and formatting (replacing Black and isort)
Includes mypy, codespell, and pytest
Provides GitHub Actions configuration
Uses Copier for template management
[…]

This would have been incredibly helpful in the past when I struggled with determining which standards to use or what best practices to follow. The book provides a valuable and easy to understand overview of the modern Python development ecosystem.

Building a modern resume: from manual tweaks to AI-powered automation

2025-06-03T00:00:00Z

Creating and maintaining a resume used to be a real headache. In the past, I’d spend hours fine-tuning the layout. Every text edit meant a cascade of layout adjustments just to make it fit, look decent, or simply not break. It was a constant battle.

My next attempt was using PowerPoint, with two A4-sized slides. This gave me a bit more freedom to tweak the design, and it looked pretty cool, I must say. But still, fine-tuning the layout was hard, and selecting all text for editing was cumbersome. Even thinking about using a different layout meant hours of tweaking everything from scratch.

My third iteration, however, has been the best so far. I stumbled upon an open-source tool called Reactive-Resume. With this, you can store your resume as JSON, use an interactive UI, and with a single click, play around with a limited selection of themes. It’s truly great that this tool has been developed and open-sourced.

As their documentation states:

Reactive Resume is a free and open-source resume builder that simplifies the process of creating, updating, and sharing your resume. With zero user tracking or advertising, your privacy is a top priority. The platform is extremely user-friendly and can be self-hosted in less than 30 seconds if you wish to own your data completely.
It’s available in multiple languages and comes packed with features such as real-time editing, dozens of templates, drag-and-drop customisation, and integration with OpenAI for enhancing your writing.
You can share a personalised link of your resume to potential employers, track its views or downloads, and customise your page layout by dragging-and-dropping sections. The platform also supports various font options and provides dozens of templates to choose from. And yes, there’s even a dark mode for a more comfortable viewing experience.
Start creating your standout resume with Reactive Resume today!
(Source: https://docs.rxresu.me/)

It’s a really easy tool to use with an intuitive UI. Also, I can store the JSON in my GitHub, which automatically gives me an overview of the history of changes. Then I use the online editor to play with the layout and generate a PDF version.

Of course, I also used generative AI for translating and fine-tuning my resume’s text. I tried many different models, but at this moment, I most liked the language use of Google’s Gemini 2.5 Flash, especially if you tell it not to be “too engaging” 🤭. I heard others saying they had good experiences with Anthropic Sonnet 4 or even Opus 4. I liked these for translation from English to Dutch, but overall, I think they tend to generate overly long texts, which means a lot of editing for me.

For editing all text from the document using an LLM, you could share the whole JSON in the chat, but that’s quite large. I also noticed you really need to be very specific about what it can change; for example, it shouldn’t alter the unique identifiers in the JSON. I found it easier to only give the personally written texts as Markdown to the LLM and let it proofread that. To get the text from the JSON, again, you need to be very specific. The models tend not to copy everything or change some text here and there. Proofreading the LLM’s output to ensure it was correct, and waiting for it to generate the output, became quite tedious.

So, I asked Anthropic Sonnet 4 to create an app for me:

I want you to build me app in which I can paste a json and as output I get the relevant text in markdown. I will provide an example json, it is my resume, I am only interested in the text I wrote, like summary or title, and not IDs. First create a step by step plan to build this app. I would prefer something that can run in the browser.
# json
[resume json]

It came back with a plan to build the app:

# Step-by-Step Plan: JSON Resume to Markdown Converter
[…]
Overview
[…]
Steps
[…]
1. Setup Basic HTML Structure
[…]
2. Design the User Interface
[…]
3. Implement JSON Parsing Logic
[…]
4. Create Content Extraction Functions
[…]
5. Implement HTML to Text Conversion
[…]
6. Create Markdown Formatting Functions
[…]
7. Implement the Main Conversion Logic
[…]
8. Add User Experience Features
[…]
9. Error Handling and Validation
[…]
10. Testing and Refinement
[…]
Technical Approach
[…]
Expected Output Format
[…]

Next, I asked it to build the app, and voilà, it created an app that worked in one go, did exactly what it needed to do, and even had quite a nice design. On closer inspection, I did ask it to make it a more generic tool, as the first version referenced an ID, which is, of course, unique to my example JSON. I asked it to come up with a more generic solution for that, and it did the filtering on section name, which seems to be working just as well.

My custom-built web tool for extracting text from Reactive Resume JSON into Markdown.

I’ve hosted it using GitHub Pages, so you can try it for yourself. Here is the link: https://allarddewinter.github.io/rxresume-json-markdown-converter/.

This has been absolute fun to make! Using code (HTML, CSS, JavaScript), which I only have limited experience with, saves me a lot of hassle proofreading the LLM. The output is instant, and it saves tokens used (although I don’t think that really saves a lot of money). As a last note, you could say it also touches on the environmental impact, Simon Willison’s recent posts offer a good perspective on this, suggesting that for typical personal use, it’s not as significant as some might fear:

Developers burning through $100 of tokens per day (not impossible given some of the LLM-heavy development patterns that are beginning to emerge) could end the year with the equivalent of a short haul flight or 600 mile car journey.
(Source: https://simonwillison.net/2025/May/20/ai-energy-footprint/ and https://simonwillison.net/2025/May/6/whats-the-carbon-footprint-of-using-chatgpt/)

Overall, it’s been real fun to be ‘vibe coding’ like this and creating tooling to make my work easier.

Inspiring Persons: Chip Huyen – A Structured Approach to Technology and (Career) Growth

2025-06-02T00:00:00Z

Chip Huyen, whose work is available on her personal website, demonstrates a structured and strategic approach to career and personal development. This aligns with principles of positive mindset and self-direction, as discussed by Michael Pilarczyk in my earlier post on him: Inspiring Persons: Michael Pilarczyk. She has a consistent method of exploring complex topics, synthesising information, and presenting it for others to learn from through her blog, books, and courses.

Her perspectives on personal growth, detailed in her blog post “Measuring personal growth” (https://huyenchip.com/2024/04/17/personal-growth.html), reflect an analytical approach to self-improvement. She discusses metrics such as the rate of change in life, the time taken to work on significant challenges, and the expansion of future options. This quantitative view of personal development shares common ground with Michael Pilarczyk’s “Master Your Mindset” in its emphasis on intentional growth and proactive problem-solving. As she writes in her blog post:

As someone lowkey fascinated by numbers, I don’t see why measuring and living have to be mutually exclusive – measuring often helps me live better – but I see where they come from.
Both perspectives support this deliberate and intentional approach to personal development.

From a professional standpoint, her Stanford course, CS 329S: Machine Learning Systems Design, has been especially a valuable resource to me:

Lecture 9, on “Model Deployment,” provided insights into batch versus online prediction. (While “streaming” is often used for real-time data processing, “online prediction” is the term used in the course for synchronous, on-demand predictions.) It helped structure my understanding of our team’s needs at the time, where batch prediction was sufficient, and provided considerations for future transitions to online prediction, with possible real-time needs. The discussion also covered implications for future applications involving edge computing, such as models deployed on wind turbines.
Lecture 10, covering “Data Distribution Shifts and Monitoring,” was especially relevant to my industry. In the context of wind turbines, component wear can lead to shifts in nominal values. Moreover, this lecture highlighted the importance of monitoring practices, including setting alerts and establishing notification channels, to detect such shifts and maintain model performance. These materials were subsequently applied to implement relevant processes and tools in my professional role.

In addition to her course, Chip Huyen has authored two books. “Designing Machine Learning Systems” (O’Reilly, 2022), derived from her Stanford course, provides a comprehensive view of ML system development. Her book, “AI Engineering” (O’Reilly, 2025), covers the development and deployment of applications using foundation models. Summaries for both books are accessible on her GitHub.

Finally, her contributions as a woman in technology are noteworthy, particularly in the context of ongoing industry efforts towards diversity. Her work demonstrates a combination of technical expertise and a methodical approach to problem-solving. Very inspirational!

Twelve-factor agents: Building reliable LLM applications

2025-06-01T00:00:00Z

Dexter Horthy has put online a guide on building production level LLM applications. The guide presents a structured approach for developing LLM-powered software, in similar fashion as the original 12 factor framework.

12 factors for LLM applications

Building LLM applications presents challenges when moving from prototype to production. The gap between demonstration quality and production readiness requires proven engineering principles. The original 12 Factor Apps methodology provided structure for SaaS development (web-based software delivered as a service to users). Dexter created a similar framework for LLM applications.

Most production AI agents are not fully autonomous systems. They consist of traditional software with LLM components integrated at specific points. This guide documents patterns for building functional systems.

Let the LLM make decisions in real time to figure out the path

The twelve principles are:

Natural language to tool calls
Own your prompts
Own your context window
Tools are just structured outputs
Unify execution state and business state
Launch/pause/resume with simple APIs
Contact humans with tool calls
Own your control flow
Compact errors into context window
Small, focused agents
Trigger from anywhere, meet users where they are
Make your agent a stateless reducer

The complete guide is available at 12-factor-agents on GitHub.

Two factors stand out as particularly important yet factor 4 is for example often overlooked in the current AI hype with all these marketing terms:

Factor 4: Tools are just structured outputs

This principle defines tools as structured JSON outputs from LLMs that trigger deterministic code. All the function calls you see today are simply JSON outputs. The pattern separates decision-making from execution. The LLM determines actions while application code controls implementation. This provides flexibility in execution logic without being constrained to specific function calls.

Factor 10: Small, focused agents

This principle recommends building specialised agents for specific tasks rather than monolithic, everything-in-one systems. Context window limitations affect LLM performance as complexity increases. Limiting agents to 3-10 steps maintains manageable context and improves reliability. This approach facilitates debugging and testing while allowing gradual scope expansion.

The original 12 Factor Apps

The 12 Factor Apps methodology, created by Adam Wiggins, established principles for building web applications. It addressed configuration management, dependency isolation, and deployment practices in SaaS development.

The 12-factor agents methodology addresses similar fragmentation in LLM application development. Both methodologies aim to create systematic approaches for building scalable software. Just as 12 Factor Apps gives order to web application development, this new framework provides structure for the field of LLM powered applications.

Building and deploying LLMs: A course made by practitioners

2025-05-31T00:00:00Z

Although published a year ago, this Mastering LLMs course remains a good resource for understanding LLM best practices. With teachers like Jeremy Howard and Simon Willison, it offers practical insights from people actually building AI products.

I particularly appreciate the deployment architecture perspectives. For those making technology decisions, understanding deployment complexity matters:

Simple Model Serving: Basic setup with minimal configuration, direct integration with model library (e.g., FastAPI), ideal for proof of concepts and simple applications
Advanced Model Serving: Complex setup involving multiple components and configurations, uses auto-scaling clusters, load balancers, and specialized components, designed for high availability and scalability, suitable for large-scale, production-level applications

Course contents

The course covers these topics:

Evaluations: Testing frameworks for LLM applications
RAG (Retrieval-Augmented Generation): Information retrieval systems
Fine-tuning: LoRA adaptations and QLoRA optimisation
Building applications: Deployment patterns and serving architectures
Prompt engineering: Production techniques

Each section includes chapter summaries, notes, and resources. I especially like how they discuss building actual LLM-powered applications and model serving.

The course is free and open. It covers applied topics rather than theory.

Inspiring Persons: Will Larson's systems thinking approach to engineering strategy

2025-05-30T00:00:00Z

I find this fascinating: mapping a complex problem to a simple diagram with some numbers. This helps shift discussions from opinion-based to something more structured. This text is just an example from a larger book Will Larson is writing on engineering strategy. It shows how you can turn a sensitive topic like implementing LLMs, changing the way engineers work (maybe even combined with vibe coding), into a structured and meaningful conversation about impact on engineering quality and velocity.

Larson's systems model of developer workflow with forward progress and error feedback loops

It even backs up the importance of a good test suite, as it saves time throughout the whole software lifecycle. I’ve often had to have conversations about why it makes sense to invest in better testing. In the time of LLMs writing (parts of) code and vibe coding, it makes sense to have good tests to ensure the generated code actually does what you want. Of course, you can use LLMs to help generate the tests too. See also a recent discussion from Simon Willison on this.

What I appreciate is how he iterates and refines his approach and thinking on the job, meanwhile releasing some open source tooling (systems modelling tools) and free-to-read chapters from his book.

Here are some key insights from his LLM developer experience model:

“The value of a model is in refining our thinking, and simple models are usually more effective at refining thinking across a group than complex models, simply because complex models are fairly difficult to align a group around.”

“This is a fascinating result, because tripling development and testing velocity has changed how much work we start, but ultimately the real constraint in our system is the error discovery rate in production.”

“If we want to increase our velocity, we have to reduce the rate that we discover errors in production.”

Systems modelling definition

Larson provides this summary of systems modelling (from his strategy systems modelling post):

Systems thinking uses stocks (accumulations like boxes in a diagram) and flows (changes between stocks, shown as arrows) to understand circumstances that might otherwise have surprising behaviour or are too slow to understand from measurement.

In his LLM impact model, Larson demonstrates how tripling development speed doesn’t actually increase overall velocity if errors in production remain the constraint. Without the model, teams might celebrate faster coding while missing that the real bottleneck is downstream error rates, this is what models do: they create a cheap way to understand reality when fully understanding reality is cumbersome.

For deeper learning, Larson recommends Donella Meadows’ Thinking in Systems or his own shorter introduction in An Elegant Puzzle.

Source: Modeling impact of LLMs on Developer Experience

This structured way of thinking, creating an overview, focusing on identifying constraints and levers for improvement, is very valuable for improving the software development process.

Emerging developer patterns for the AI era

2025-05-29T00:00:00Z

Yoko Li at a16z discusses how AI is changing software development, moving beyond tooling to a new foundation. This involves rethinking core concepts.

Nine emerging patterns are highlighted:

AI-native Git: Version control shifts focus to prompt+test bundles over line changes.
Dashboards -> Synthesis: Interfaces become dynamic and conversational via LLMs.
Docs as interactive knowledge bases: Documentation serves humans and agents for context.
Templates to generation: Custom project scaffolding based on descriptions replaces static templates.
Beyond .env: Secrets management moves towards scoped tokens and local brokers for agents.
Accessibility as the universal interface: Accessibility APIs may become the primary layer for agent interaction.
Asynchronous agent work: Developers orchestrate agents working in the background across the development lifecycle.
MCP becoming a universal standard: Model Context Protocol enables tools to expose standard interfaces for agents.
Abstracted primitives: Agents use robust, composable services (auth, billing, storage) optimised for agent consumption.

The article states:

It’s not just AI layered onto old workflows, but is a redefinition of how software gets built with agents, context, and intent at the core.

Read the full article for details.

Source: a16z.com

Notes on The Startup CTO's Handbook by Zach Goldberg

2025-05-28T00:00:00Z

Came across The Startup CTO’s Handbook by Zach Goldberg. While titled for startup CTOs, it offers a lot of valuable insights that apply more broadly to anyone involved in tech leadership, engineering management, or even just looking to understand the processes and considerations within a tech department, whether in a startup or a larger corporate environment. It covers topics ranging from architecture and technology choices to team building and HR aspects.

A point on tech architecture that resonated:

Good architecture aligns the strengths of the tools and patterns you choose with the needs of your organization now and in the foreseeable future.

This highlights that architecture isn’t just a technical exercise, but needs to serve the business context and its future trajectory.

Under General Tips And Best Practices For Architecture Design, several practical recommendations stand out:

Putting business logic in the backend for testability, code sharing, and security.
Designing services to be externalisable, which encourages better API design and data abstraction from the outset.
Minimising the number of programming languages used, acknowledging the significant overhead each additional language introduces beyond just the code itself (build systems, dependencies, best practices, interfaces).

Another section worth noting is on Boring Technology. The core idea here is that the primary goal is delivering business functionality, and this often doesn’t require the newest, most exciting tools. Using “not boring” technology can introduce hidden costs (immature documentation, underdeveloped ecosystems, higher defect rates, training, maintenance) that can outweigh perceived benefits. The decision to adopt new tech should involve a clear-eyed assessment of these costs versus the velocity benefit.

Overall, the handbook provides a solid framework of considerations for building and leading engineering teams effectively. It’s a resource worth exploring for practical advice on navigating the complexities of tech leadership and development processes.

DevOps for Data Science

2025-05-27T00:00:00Z

Following up on the discussion about DevOps from an engineer’s perspective (as covered in a previous post), I wanted to share some thoughts on Alex K Gold’s book, “DevOps for Data Science”.

This book offers a clear introduction to DevOps specifically for the data science field. Given the diverse backgrounds these special creatures called data scientists often have, the explanations start at a very accessible level. For instance, it covers foundational concepts like how an SSH connection is established and notes that Python and R are primarily single-threaded.

It provides a good overview of essential topics such as branching strategies, continuous integration/continuous deployment (CI/CD), and the necessity of different environments. While it doesn’t go deeply into each topic, it effectively introduces the terminology and explains the general purpose of these practices within DevOps.

The book includes a helpful table summarising how it addresses common challenges faced by data science teams and those supporting them:

Why I want it	How I feel	What’s my pain	Pain Killer	DO4DS is…
I’m trying to take my/our DS practices + procedures to the next level. I need a framework for what I should do.	Unclear	I know our data science practice isn’t production-grade, but I don’t know how to get better.	DO4DS gives me a framework for thinking about production data science.	Clear + Full of Mental Models
I don’t know how to communicate with the IT/Admins who manage our data science environment. I need advice.	Confused	I don’t know what matters to IT/Admins or the words they use. Are they just bamboozling me?	DO4DS helps me understand the concerns of an IT/Admin and gives me the vocabulary to speak with them.	DS-Focused
I’m suddenly have to manage a data science environment as a data scientist. I need to know where to start with this IT/Admin stuff.	Alone	I have no mental models for how IT/Admin stuff works. Can someone help me understand?	DO4DS gives me step-by-step instructions for getting started.	Actionable
I’m administering a data science environment, but I’m way over my head. I need some reassurance that I’m not accidentally laying landmines I’m going to step on later.	Scared	I think I’ve figured it out, but I’m self-taught and don’t know if I’ve missed something important.	DO4DS points out security and stability risks and ways to limit them. I might not have it perfect now, but I understand the issues.	Forewarned

Here is a relatable moment from the book that made me smile 🤭:

[…]All this means it is impossible to work without real data.
“Duh”, you say, “Of course you can’t do data science without real data”.
This may be obvious to you, but needing to do data science on real data in dev is a common source of friction with IT/Admins.[…]

This highlights a common point of friction and the book’s focus on bridging the gap between data science needs and IT realities.

Overall, “DevOps for Data Science” is a valuable resource for anyone looking to understand or implement DevOps principles in a data science context, providing easy-to-understand explanations and some practical guidance.

300,600

A Recommended Read: Architecture Patterns with Python

2025-05-26T00:00:00Z

I came across ‘Architecture Patterns with Python’ by Harry Percival and Bob Gregory, also known as ‘Cosmic Python’. Released in March 2020 by O’Reilly Media, this book is a really nice, in-depth guide to architectural patterns specifically for Python developers.

Why did they write the book?

At the end of Harry’s last book, Test-Driven Development with Python (O’Reilly), he found himself asking a bunch of questions about architecture, such as, What’s the best way of structuring your application so that it’s easy to test? More specifically, so that your core business logic is covered by unit tests, and so that you minimize the number of integration and end-to-end tests you need? He made vague references to “Hexagonal Architecture” and “Ports and Adapters” and “Functional Core, Imperative Shell,” but if he was honest, he’d have to admit that these weren’t things he really understood or had done in practice.
[…]
Our aim with this book is to introduce several classic architectural patterns and show how they support TDD, DDD, and event-driven services.

What I particularly like are the practical code examples provided in the book. They effectively illustrate the concepts discussed. The authors take a structured approach, integrating test-driven development (TDD) and Domain-Driven Design (DDD) principles.

Beyond just patterns, the book also includes helpful design tips, some inspiration for creating UML diagrams, and practical testing advice within its chapters. It’s a comprehensive resource for anyone looking to improve their understanding of building robust Python applications.

You can find the online version at https://www.cosmicpython.com/ and the O’Reilly link here: https://learning.oreilly.com/library/view/architecture-patterns-with/9781492052197/.

Simon Willison on Building with LLMs (PyCon 2025)

2025-05-25T00:00:00Z

Came across this neat tutorial on building LLM-powered applications from Simon Willison, which he shared via his newsletter.

The materials cover practical things like setting up and running LLMs from the command line, using RAG (Retrieval Augmented Generation), and tool usage.

Here’s a snippet of the topics covered:

Topics we will cover include:
A review of the best currently available models
Using multi-modal LLMs to analyze images, audio and video
Use-cases that LLMs can be effectively applied to
How to access the most capable models via their various APIs
Prompt engineering
Retrieval Augmented Generation (RAG)
LLM tool usage
Automated evaluations for LLM applications
The latest options for running local models

Here are the tutorial materials: https://github.com/simonw/building-with-llms-pycon-2025

Found it via his newsletter here: https://open.substack.com/pub/simonw/p/building-software-on-top-of-large

Making AI Work: Leadership, Lab, and Crowd

2025-05-24T00:00:00Z

Once again, Ethan Mollick delivers an interesting piece. I absolutely feel the need for the things he describes in my own experience.

Leadership
- Function: Vision Setting
- People: Company leaders (e.g., CEOs, executives)
The Crowd
- Function: Performance Innovation
- People: Employees across departments
The Lab
- Function: Product Development
- People: Subject matter experts, technologists, and non-technologists

Link to original article

An overall vision is not enough, however, because leaders need to start to anticipate how work will change in a world of AI.

[…]

I am increasingly seeing organizations start to experiment with radical new approaches to work in response to AI. For example, dispersing software engineering teams, removing them from a central IT function and instead having them work in cross-functional teams with subject matter experts and marketing experts. Together, these groups can “vibework” and independently build projects in days that would have taken months of coordination across departments.

[…]

When research that once took weeks now takes minutes, the bottleneck isn’t the research anymore, it’s figuring out what research to do. When code can be written quickly, the limitation isn’t programming speed, it’s understanding what to build. When content can be generated instantly, the constraint isn’t production, it’s knowing what will actually matter to people.

[…]

The key is treating AI adoption as an organizational learning challenge, not merely a technical one.

Yevgeniy Brikman on DevOps from an engineer's perspective.

2025-05-23T00:00:00Z

“The goal of DevOps is to make software delivery vastly more efficient.”

That quote comes from Yevgeniy Brikman’s book, Fundamentals of DevOps and Software Delivery (2025), which can be read for free on the Gruntwork website.

I had always thought of DevOps primarily as a separate role or team within tech. However, the book clarifies that it’s much broader:

“DevOps isn’t the name of a team or a job title or a particular technology (though you’ll see it used for all three). Instead, it’s a set of processes, ideas, and techniques.”

Based on the outline, the book dives deep into the practical, hands-on aspects of software delivery from an engineer’s viewpoint. It covers topics like deploying applications, managing infrastructure as code, using orchestration tools, setting up CI/CD pipelines, handling networking and security, managing data storage, and monitoring systems. It provides concrete examples using various tools, making complex concepts accessible and providing code examples.

If, like me, you come from a technical background but have (or want to have) a more holistic view on how to work efficiently, this book seems like a great fit. It describes from an engineering perspective how to become better in DevOps. The potential improvements for companies that adopt these principles are significant:

Deploying once per month versus many times per day.
Deployment processes that take 36 hours versus 5 minutes.
Two out of three deployments causing problems versus one out of twenty.
Outages that last 24 hours versus 2 minutes.

Implementing DevOps is challenging, though; the task can feel daunting. I had similar experiences, particularly when trying to implement and educate about MLOps. Often, you focus on optimising a single piece of the puzzle, making that more efficient in isolation. But the scope of what needs to change is so broad that changes are needed across the board, and you get stuck somewhere in the middle for more complete and lasting improvements. You might need to influence not only your own team but also surrounding teams, and perhaps even department structures or the overall company philosophy.

Brikman describes this complexity as a “box of snakes” 🐍🐍🐍:

What makes DevOps hard is not that any one of these concepts is incredibly complicated by itself, but that there are so many concepts to master—and you have to connect them all together just right. The TLS certificate must be configured just right, or your users will get scary errors that prevent them from accessing your website; your deployment pipeline must be configured just right, or your team won’t be able to deploy; your database backup must be set up just right, or you are at risk of data loss, and if you lose all your data, you may go out of business entirely. DevOps is remarkable combination of an incredibly broad surface area, but also one where you have to sweat every single detail, for either you get everything connected together correctly, or nothing works at all.

The perspective Brikman takes is that of the engineer, which makes the book a very accessible read if you’re coming from a tech background. It is an absolutely valuable read for anyone looking to understand and improve the efficiency of software delivery.

Inspiring Persons: Michael Pilarczyk (Part 1)

2025-05-22T00:00:00Z

I want to introduce you to someone who has significantly impacted my perspective: Michael Pilarczyk. He has a remarkable ability to articulate and structure the way I generally approach life. I am a genuine admirer of his book, “Master Your Mindset”, and the powerful ideas it contains, which blend neuroscience, stoicism, Eastern meditation, and modern coaching. The core message is about actively working and training your mindset towards achieving success, building resilience, and finding purpose.

A core conviction he shares, echoing Napoleon Hill’s ‘Think and Grow Rich’, is the power of focused thought and visualisation in attracting opportunities. This principle has manifested in my life multiple times. Most recently, when searching for our current home. We visualised finding a specific type of place, one that met our needs for space, location, and crucially, allowed us to live near my wife’s twin sister and her husband. Despite the specific requirements, within a year, we found our dream house in Kerkdriel.

Similarly, setting up our NGO and working in Rwanda and Madagascar involved visualising the goal and actively seeking possibilities. Initially, connections in Africa seemed distant, but by preparing and looking for openings, we unexpectedly connected with inspiring individuals like entrepreneur Rik Stamhuis and the mindful Father Jean Bosco in Nyabinoni, Rwanda, who provided the support and location we needed.

For me, this isn’t about magic or passive wishing. It’s about the active process of preparing yourself thoroughly, staying alert for even the smallest glimmer of opportunity, and then having the readiness and courage to seize that moment when it arises.

Key takeaways from Master Your Mindset

Michael’s book, ‘Master Your Mindset’, offers practical tools for this. Here are some key takeaways:

Mindset as “software”: your beliefs shape reality
Identify and reframe limiting beliefs
Use daily practices: journaling, affirmations, visualisation
Design rituals and environment for consistency
Apply tiny habits to build unstoppable momentum
Embrace discomfort to grow resilience
Review and adjust goals regularly

If you’re interested in exploring his work further, his Dutch podcast “Leef je mooiste leven” is a great resource.

I’m personally looking forward to attending his “Maximum Potential 2025” event; very excited about that!

Inspiring Persons: Simon Willison

2025-05-20T00:00:00Z

You are reading this post on my own website thanks to the inspiration of Simon Willison.

He is the one who inspired me to get my own site up and running and publish here instead of relying (only) on social media platforms. His personal website, simonwillison.net, nicely demonstrates the value of owning your digital narrative and sharing knowledge freely.

Simon Willison is the creator of Datasette, an open source tool for exploring and publishing data. He currently works full-time building open source tools for data journalism, built around Datasette and SQLite.
Prior to becoming an independent open source developer, Simon was an engineering director at Eventbrite. Simon joined Eventbrite through their acquisition of Lanyrd, a Y Combinator funded company he co-founded in 2010.
He is a co-creator of the Django Web Framework, and has been blogging about web development and programming since 2002 at simonwillison.net.
Source: Simon Willison’s About Page

Inspiration for Coding and Learning

Beyond inspiring me to build my own platform, Simon is also an exceptional coder. His dedication inspires me to write better code and continue coding myself, even as my career progresses and coding is expected less and less.

I particularly appreciate how he shares his deep dives into Large Language Models (his pelican on a bike tests are real fun!), practical coding techniques, and technology trends. These provide really good insight and overview, and inspire me to experiment and build things myself.

llm -m gemini-2.5-flash-preview-05-20 'Generate an SVG of a pelican riding a bicycle'

Contributing to the Common Good

I also appreciate his commitment to helping the common good. His Datasette tooling and workshops for the press are a great example of using technology to benefit everyone.

Overall, Simon Willison’s technical expertise, commitment to open source, and focus on the common good make him an inspiring person!

Jager McConnell on Proprietary Data in the Age of Generative AI

2024-05-21T00:00:00Z

I also see this advantage for companies with large assets bases, like energy companies, if they learn how to leverage it.

As a data company, I feel really good, because if you’ve got proprietary data that no one else has access to, it’s very hard to beat me at the game. Data and differentiation in that data that no one else has access to is the holy grail I think in the long run because, no, AI can’t make it up, and that feels like a winner.
— Jager McConnell, Crunchbase CEO

Read the full article here: https://stackoverflow.blog/2025/05/15/whether-ai-is-a-bubble-or-revolution-how-does-software-survive/