Every week, I curate a list of some of the Software Engineering articles that I read in the past week, add a quick summary and then links to them. I also create a reel about the same for my social media channels (go follow me there).
Agentic Engineering: Practical application of AI to create quality software
explores how software development is moving toward a model where engineers and AI collaborate closely, combining human judgment and craftsmanship with AI’s ability to handle repetitive and large-scale tasks. Rather than replacing developers, AI becomes a powerful partner embedded in the workflow, helping generate and modify code while engineers maintain control over design, quality, and decisions. The article also outlines some guiding principles for making this collaboration effective, aiming to build software that is faster to create without sacrificing clarity, maintainability, or accountability.
Code Smells Every Software Engineer Should Know
explores common patterns in code that signal deeper issues—not necessarily bugs, but structural weaknesses that make software harder to maintain and evolve. These “code smells” include things like duplicated logic, long parameter lists, overly large classes, and unused (dead) code. While each smell might seem harmless on its own, they often point to design problems that grow over time if not addressed. Karsh emphasises the importance of noticing these early and refactoring regularly, so teams can build software that stays clean, readable, and adaptable as it scales. The article also encourages using tools and team habits—like linters and code reviews—to catch and clean up code smells before they become technical debt.
Concurrency is not parallelism
This article breaks down the critical difference between concurrency and parallelism—two concepts often used interchangeably but with distinct meanings. Concurrency is about dealing with multiple tasks at once by structuring programs to switch between them efficiently, improving responsiveness and flow. Parallelism, in contrast, is about doing multiple things literally at the same time, requiring multiple processors or cores. The author argues that while concurrency is a design decision, parallelism is an execution property. Understanding the distinction helps developers write clearer, more scalable code without chasing performance gains in the wrong place.
The 13 software engineering laws
This article compiles thirteen enduring “laws” (mental models) from software engineering, ranging from Parkinson’s and Hofstadter’s to Conway’s and Murphy’s. Each offering sharp insight into recurring behavioural and structural challenges in tech teams. It explains how work tends to expand to available time, estimates always run long, adding people to a late project often slows it down, and organisations design software mirroring their communication makeup. Other laws touch on topics like feature creep (Zawinski’s law), accidental customer dependencies on every behaviour (Hyrum’s), the disproportionate output of a few contributors (Price’s), and the dangers of metrics becoming targets (Goodhart’s). The piece emphasises why each law matters to engineers and managers, advising that knowing these patterns helps design better communication structures, set realistic scopes, review metrics wisely, and engineer resilient systems. Understanding these laws equips teams to anticipate common traps and build software development cultures that stay efficient, focused, and adaptable.
Software engineering with LLMs in 2025: reality check
Shares how seasoned developers are thinking about the role of LLMs in the future of software development. Instead of being just another coding assistant, these tools are becoming powerful collaborators—writing, testing, and even refactoring code with minimal prompts. Engineers like Kent Beck, Armin Ronacher, and Simon Willison reflect on how LLMs are shifting the way they approach their work, allowing them to focus more on design and problem-solving while the AI handles boilerplate and grunt work. There’s a clear theme: LLMs won’t replace engineers, but they’re changing how we build—introducing new workflows, speeding up iteration, and making the process feel more fluid and creative.