标签 · Software Engineering

Recent picks

28picks · chronological

09-20

AI Coding Is a Framework, Not a Library

Piglei argues that AI coding tools are better understood as a framework than a library. Frameworks own the program's overall structure and buy convenience at low upfront cognitive cost; AI tools do the same, with natural language replacing code as the input. Using Django REST Framework as the case study, he shows a four-line ModelViewSet generating a full CRUD API, then details what customizing a create response or adding list filters actually costs: rewriting get_queryset and stacking if/else patches. Dropping to a plain ViewSet makes the code longer but surfaces the hidden cognitive debt. Two framework problems persist with AI: abstraction leaks, when prompts fail and you must debug down to variable names, and loss of control, as in vibe coding where the agent owns the structure. His advice: treat AI as a library, find the prompt sweet spot, design the structure yourself, encode constraints in AGENTS.md, and review generated code.

www.piglei.com · 4 min · AI Engineering · Code Review · Essay

09-18

No More Issues: Laravel Asks for PRs Instead

Laravel disabled issue creation on several package repositories — including Socialite and Scout — and now asks contributors to open pull requests instead; the main framework repo is unaffected. Brent Roose, an open source maintainer, walks through the trade-offs. Forcing a PR can cut maintainer triage time, and duplicate fix attempts are easier to close. But in the AI era, opening a PR is nearly as cheap as filing an issue, and LLM-written patches demand more review effort than ones a contributor reasoned through. Duplicate PRs also trigger far more CI runs than duplicate issues. Requiring PRs raises the contribution bar rather than lowering it, and shuts out contributors without AI access or enough experience — even though many people, the author included, started out writing Laravel issues. He draws no firm conclusion, but finds the change hard to square with the idea that every contribution is a learning opportunity. Aimed at OSS maintainers and contributors.

stitcher.io · 5 min · AI Engineering · Code Review · Open Source

09-17

High Internal Quality Makes Software Cheaper, Not More Expensive

Martin Fowler argues that the familiar quality-versus-cost trade-off does not apply to the internal quality of software. He splits quality into external attributes users can perceive — UI, defects — and internal ones they cannot, such as architecture, naming, and modularity. Customers will pay more for a better interface but cannot judge internal structure, so it is usually treated as a cost to be cut. Fowler's claim runs the other way: internal quality lowers the cost of future change, making software cheaper to produce, not more expensive. A pseudo-graph of cumulative functionality against time shows low-quality projects starting fast and then stalling as cruft accumulates; the developers he canvassed report being slowed within weeks. Even the best teams create cruft — they hold it down with automated tests, frequent refactoring, and continuous integration. He concedes that output cannot be measured, so the crossing point rests on experience rather than data. Written for engineers who need an economic, not moralistic, case for quality.

martinfowler.com · 15 min · Code Quality · Refactoring · Software Engineering

09-17

Your Database Skills Are Not 'Good to Have'

A MySQL war story from 2006: a three-person team builds faceted search for New York Magazine's Fashion Week portal, with exact per-tag counts, before Solr facets or Endeca existed. The author tunes MySQL 4 by timing queries and reading EXPLAIN output. Twenty years later he sees the opposite trend: engineers reach for "planet-scale" databases while barely knowing the relational engine they already run. He recounts an e-commerce incident where a product listing page took over 10 seconds even with no traffic, caused by three mistakes at once: no index, ORM loops firing 200-500 queries per page, and SELECT-ing every column. The argument: a modern RDBMS is innocent until proven guilty, and the burden of proof is on you. Includes a troubleshooting runbook and anti-patterns (exotic databases, unnecessary caching, data landfill). For backend and data engineers.

renegadeotter.com · 14 min · Database · MySQL · Performance

09-17

A Lannister Always Pays His Technical Debts

The author sorts technical debt into three buckets: aesthetic (import order, naming — annoys you but doesn't touch users or velocity, and tooling can fix it), deferrable (contained, to be crossed off methodically inside normal sprint work), and toxic (a half-finished thing that turns into a workaround magnet, with every new feature built on top of it). Missing tests and missing docs are called out as toxic debt: without an integration suite you won't dare swing a sledgehammer at the codebase, and without READMEs and runbooks every bug repro starts with reverse-engineering the system at real dollar cost. The related advice: TODO comments mean you will never do it, so turn them into actual cards on the board, and tag debt stories so the ratio of features to debt stays visible. The debt column will never be empty — just don't let it run away.

renegadeotter.com · 8 min · Refactoring · Software Engineering · Technical Debt

09-16

The Product-Minded Software Engineer: 9 Traits and How to Grow Them

The author breaks "product-minded" down into observable behaviors: these engineers do not take a spec and start coding, they ask why first, challenge requirements, and evaluate product and engineering tradeoffs together. Nine traits are listed, including digging into business and user data, building relationships with non-engineers, applying a minimum-lovable-product lens to edge cases, and following user behavior metrics for weeks after launch before drawing conclusions. Product instinct, the author argues, compounds across repeated project cycles of questioning, proposing, validating fast, and debriefing gaps. Written for engineers on user-facing teams who work with PMs; it closes with six concrete habits to build the muscle.

blog.pragmaticengineer.com · 12 min · Career Advice · Product Management · Software Engineering

09-16

You Want Modules, Not Microservices

Ted Neward argues the microservices pitch is recycled: of six quoted benefits, two come from microservices literature, two from twenty-year-old EJB material, and two from Oracle Tuxedo, forty-year-old technology. Strip the branding and what remains is the module — an independently built, versioned, deployed and reusable unit of code, the concept Parnas defined in 1971 and Unix pipes-and-filters delivered in the 1970s. What organizations actually bought was organizational clarity: small teams owning their own analysis, testing, data and deployment dependencies instead of waiting on DBA, QA or infrastructure groups, at the cost of full-stack staffing and on-call duty. Technically, in-process module calls become network calls, adding five to seven orders of magnitude of latency and running into the Fallacies of Distributed Computing, which more nodes only worsen. Neward's advice: any decomposition behind a common API convention works; fix organizational dependencies directly. Suited to architects and tech leads.

blogs.newardassociates.com · 15 min · Distributed Systems · Microservices · Modularity

09-16

20 Things I've Learned in my 20 Years as a Software Engineer

A Simple Thread co-founder distills 20 years of engineering into 20 opinions, prefaced by an honest account of his context: small teams and startups first, then consulting inside large companies, then growing his own firm from 2 to 25 people. The list runs against received wisdom: building the right thing is harder than building it well; the best code is code you never write; every system eventually rots, so aim for continuous improvement rather than elegance; the 10x programmer is a myth and the real win is keeping 0.1x programmers off the team; data outlives your codebase; interviews predict almost nothing about teammates; prefer durable "shark" technologies to fashionable ones. Aimed at working engineers who want to sanity-check their own judgment, with the caveat that all advice is contextual.

www.simplethread.com · 14 min · Career Advice · Engineering Culture · Essay

09-15

antirez on code comments: a nine-part taxonomy from Redis

antirez works through the Redis source (unstable branch, 32e0d237) to argue that comments are not a crutch for weak code. He sorts comments into nine kinds, namely function, design, why, teacher, checklist, guide, trivial, debt and backup, judging the first six useful and the last three suspect. His two reasons: many comments carry information the code cannot express, such as why a statement is there instead of a more natural alternative, and comments lower the reader's cognitive load, as when scripting.c annotates the Lua stack layout after every call. Each category comes with real examples: the replication code that swaps replication IDs before freeing the backlog, the expire.c loop that increments current_db early, the trigonometry behind LOLWUT, the checklist duty created by Redis's 4-bit type field, and the TODO left in t_stream.c. Reading and writing comments, he argues, is bug hunting and design review in disguise.

antirez.com · 31 min · Code Comments · Code Readability · Redis

09-15

Write code that is easy to delete, not easy to extend.

The thesis: treat lines of code as lines spent, not lines produced. Every line carries a maintenance cost, and abstractions built for reuse bind callers to both the intended and unintended behaviour of an implementation, making later change more expensive. The goal should be disposable code, not reusable or extensible code. The author walks through tactics: don't write code at all; copy-paste a few times before extracting a function; keep stateless, application-agnostic helpers in a util directory with one utility per file; accept boilerplate so static library code stays away from fast-changing business logic; layer policy over protocol the way requests wraps urllib3; let one big ball of mud hold things together; split modules by what they don't share rather than by shared functionality; use uniform interfaces, HTTP caches/CDNs and feature flags as replaceable seams; handle errors at the outer edges (end-to-end principle), as Erlang's supervision trees do by restarting instead of recovering in place. Aimed at engineers maintaining long-lived codebases.

programmingisterrible.com · 20 min · API Design · Code · Essay

09-15

How to ask good questions about software

Julia Evans argues that asking good questions is a trainable software engineering skill, not a personality trait. Her core technique: state what you already understand, then ask 'is that right?'. She rewrites vague questions ('how do SQL joins work?') into questions with factual answers — is joining N and M rows O(NM) or O(NlogN)+O(MlogM), does MySQL always sort join columns first. She shows the rkt-dev mailing list question where she first wrote down how rkt and Docker store container images differently, then asked why; and the term dictionary she built for Hadoop, Scalding, Hive, Impala and HDFS when joining a data team. She also covers choosing whom to ask (a 5-minute answer that saves you 2 hours is a good trade; the most senior person is not always the right target), stopping an explanation to ask what a term like optimistic locking means, and reading the Etsy Debriefing Facilitation Guide for questions that surface hidden assumptions. She is explicit that asking dumb questions is fine, and criticizes ESR's 'How To Ask Questions The Smart Way' for putting an unreasonable burden on askers. Aimed at engineers ramping up on unfamiliar systems.

jvns.ca · 13 min · Career Advice · Software Engineering · Technical Communication

09-14

The Law of Leaky Abstractions

Joel Spolsky's classic essay starts with TCP, which promises reliable, ordered, uncorrupted delivery on top of IP, a protocol that guarantees none of those things. TCP is an abstraction, and like every non-trivial abstraction, it leaks. The examples span the stack: iterating a 2D array column-wise can trigger far more page faults than row-wise; logically equivalent SQL queries can differ by orders of magnitude in runtime; no C++ string class can make "foo" + "bar" compile, because string literals are char*; an NFS server outage silently drops mail that depended on a .forward file; ASP.NET fakes form submission from a hyperlink with generated onclick JavaScript, breaking when JavaScript is disabled. The practical consequence: abstractions save time writing code, not time learning. As tools get higher-level, debugging them still requires knowing what was abstracted away, so proficiency gets harder, not easier.

www.joelonsoftware.com · 12 min · Abstractions · Essay · Software Engineering

09-14

My Principles for Building Software

A practitioner's list of principles for building software, most aimed at making systems simpler: make invalid states unrepresentable, enforce data consistency, design data before code, measure before trading away simplicity. The appendix shows what inconsistency costs — split two Boolean variables x and y that must stay equal into separate databases and the data gains two more states, leaving the toggle function with no correct answer. The author argues consistency is the most undervalued property in software engineering and that most bugs are data failing an expectation. Other principles: avoid trading local simplicity for global complexity (smaller services often do this), don't optimize without measurement, keep code consistent even when the consistent thing isn't the "correct" thing, and learn concepts — the relational model, algebraic data types, borrow checking — rather than surface details of React or Kubernetes. Aimed at backend and data engineers weighing service splits and schema design.

kevinmahoney.co.uk · 9 min · Database · Programming Languages · Software Engineering

09-14

Healthy Documentation: A CTO's Case for Docs-First Engineering

A CTO's field notes on running a docs-first engineering culture: replace half-hour check-ins with a one-page memo, budget documentation time explicitly in estimates, and require a short "why X over Y" paragraph on every merged feature. He is candid about the failure modes — stale pages are worse than none, and some workarounds should be fixed in code rather than explained in three paragraphs of handbook. Concrete mechanisms include a lightweight CI check that fails the build when a new analytics event ships without a matching wiki entry, ADR and post-mortem templates, the Diátaxis split between tutorials and reference, and a part-time "docs gardener" who prunes dead links.

vadimkravcenko.com · 11 min · Developer Tools · Documentation · Engineering Culture

09-14

How to Do Code Reviews Like a Human (Part One)

Michael Lynch argues that most code review writing obsesses over finding bugs and ignores the social half of the process, turning reviews into judgments of the author rather than the code. Drawing on his own review experience, he offers concrete practices: push whitespace, build, test, and lint checks into CI and formatters so humans review logic; settle style disputes with a style guide instead of arguing mid-review; start reviews immediately and keep each round under one business day; stay under roughly 20-50 notes per round and lead with high-level design feedback; include runnable code examples but cap them at two or three per round; never write "you" in a comment, preferring "we", subject-less shorthand, or questions; phrase feedback as requests rather than commands; and tie every note to a stated principle with links to the team style guide or library docs. Aimed at engineers who want reviews that improve code without damaging the team.

mtlynch.io · 23 min · Code Review · Collaboration · Software Engineering

09-08

Software Craft vs Industry: Bun's Rust Rewrite, Agents, Seat Belts

Taking the 2026 Bun rewrite from Zig to Rust and the ugly public spat between Andrew Kelley and Jarred Sumner as its cue, this essay asks a question the author has carried through his career: is software production a craft or an industrial process? It combs through tabs-vs-spaces wars, the rise of formatters, Go's deliberate deskilling and work intensification, the Clojure community's hand-tool romance, woodworking hobby culture, and the US government's seat-belt mandates—all to build a metaphor for type systems and Rust's borrow checker. The author argues quality is subjective, 'slop' is in the eye of the beholder, and predicts coding agents will drive software further into industrialisation: language lock-in for small/medium projects disappears, hand craftsmanship becomes a hobby, and quality is increasingly quantified and automated. A thought-provoking culture essay with a clear pro-AI, industrialist viewpoint; not a technical tutorial.

newsletter.powderworks.dev · 76 min · AI Engineering · Claude Code · Essay

09-03

Writing Code Is Easy. Reading It Isn't.

Drawing on years of contract work, the author argues that the real cost of software lives in reading, not writing: every codebase demands a mental model, built by tracing function definitions, return types, database paths, caches, error handling, and call sites. Understanding one getUserPreferences-like function often means opening five other files. Because LLMs can now emit code faster than anyone can consume it, they enlarge the reading burden; the lawyer who filed fictitious ChatGPT-sourced cases failed not at generating but at verifying through reading. The practical conclusion is to point AI at comprehension—explaining existing code, uncovering side effects, compressing context—rather than at producing bigger diffs. Team throughput should be measured by how quickly members construct accurate mental models, not by lines generated. A grounded opinion piece for engineers who want AI assistance without mistaking output volume for velocity.

idiallo.com · 6 min · AI Engineering · Developer Tools · LLM

09-02

Code Factories Without Quality: The AI Development Blind Spot

As Zapier, Nubank, and Goldman Sachs hand coding tasks to AI agents, 'code factories' scale generation 10x while verification lags. The article argues generated code is implicitly treated as production-ready, with QA deprioritized or reduced to shallow coverage. It cites unverified claims of a 30% rise in change-failure rate and 23.5% more incidents per PR, then argues line coverage is worthless because 100% coverage can still miss broken user flows. The fix: autonomous verification that scales like generation, tests real user journeys, runs independently of the coding agent, and self-maintains to survive flake. The second half is a QA Wolf product pitch. Useful for engineering teams adopting AI coding, though explicitly vendor-biased.

www.qawolf.com · 10 min · Agent Engineering · Agents · AI Engineering

09-01

A Git-compatible VCS with a commit-centric workflow

Jujutsu (jj) is an open-source version control system written in Rust. It aims to make the everyday VCS workflow simpler while staying compatible with the Git ecosystem. The key design is a working copy that is automatically committed: every file change becomes a snapshot you can revisit or revert. An operation log records every state mutation, providing robust undo/redo. Conflicts are first-class data objects instead of inline text markers, making merges and rebases more predictable. jj can be used in existing Git repositories or as a standalone VCS, so it supports incremental adoption. This project is relevant for engineers exploring modern VCS design, Git workflows, and high-quality Rust-based tooling.

github.com · 2 min · CLI · Developer Tools · Rust

08-31

Why senior developers fail to communicate their expertise

This post frames senior developers' communication failure as a clash between two business loops. The first loop tries to reduce market uncertainty by shipping fast; the second loop keeps paying customers served by controlling system complexity. Once a company has customers, both loops run at once, so developers talk in terms of complexity while everyone else worries about uncertainty. The author argues that senior developers' real skill is refusing unnecessary work and reusing existing software, and that they should express it as 'Can we try something quicker?' — a phrase that acknowledges the business's need for speed while leaving room for simplification. He also proposes separating the fast 'Speed' system from a stable 'Scale' system, and warns that AI accelerates the first loop while degrading understandability and stability in the second, without taking responsibility. A thoughtful read for engineers interested in organizational communication and system evolution.

www.nair.sh · 13 min · Engineering Culture · Software Engineering · System Design

08-31

Good Engineering Doesn’t Trust Engineers

Factory workers tell the author they don't trust software engineers, because clean models miss dusty sensors, part batch changes, and cold-morning valve stickiness. Good engineering agrees: NASA, aviation, and nuclear plants build processes around the assumption that engineers can be wrong. AI makes code cheap, exposing that mainstream software development treats code as source of truth, requirements as Jira tickets, and safety arguments as PR comments. The post argues that engineering means making intent explicit and attaching evidence to obligations, separating verification from validation, and applying rigor proportional to risk. It cites NASA's SWEHB, MC/DC coverage, and FRET project, then introduces ReqProof as an agent-driven lifecycle where obligations stay visible and evidence stays attached. The core ideas stand even if you never use the product.

blog.reqproof.com · 17 min · Agent Engineering · AI Engineering · Requirements Engineering

08-21

Software Engineering Fundamentals Matter More Than Ever

In this reflective essay, a software engineer discusses impostor syndrome and why software engineering fundamentals still matter amid agentic AI hype. Agent harnesses have crossed the "can it be done" threshold, but producing software that is debuggable, maintainable, layered, and composable still requires careful human judgment. LLMs don't truly reason; they predict based on compressed human knowledge, so effective use depends on providing concise data at the right time and deterministic validation tools giving natural-language feedback. The author cites the Illusion of Thinking paper, JEPA/LeCun research, and Simon Willison's "lethal trifecta" about prompt injection and advice filtering. Aimed at engineers who want a grounded perspective on AI-assisted development.

rhonabwy.com · 6 min · Agents · AI Engineering · LLM

08-15

The AI Engineering Skills Map

In this post, Andrew Ng unveils the AI Engineering Skills Map, synthesized from 10,000+ job postings, dozens of expert interviews, and surveys. It identifies four core skills: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build. Because AI systems produce unpredictable outputs, developers must rely on statistical evals and error analysis. Strong software fundamentals help you steer agents effectively, while the rise of agentic coding shifts engineering value from implementation to product sense and tradeoff decisions. A useful guide for developers setting priorities and employers hiring AI-capable engineers.

x.com · 6 min · Agent Engineering · AI Engineering · Context Engineering

08-11

What Is an AI Engineer?

A concise role introduction to AI engineering, drawing on Latent Space's 'The Rise of the AI Engineer.' It draws the line at the API boundary: AI Engineers orchestrate models to build applications, while ML Engineers build the model APIs themselves. The post argues newcomers don't need linear algebra or pretraining experience; instead they need strong software fundamentals, evaluation frameworks, and feedback loops. It also distinguishes AI Engineers from AI-assisted developers who merely use tools like Copilot. Web developers are presented as well suited for the transition, and TypeScript is called a fast-growing fit. The article is accessible but conceptual, with a promotional block for the author's AI Hero skills system.

www.aihero.dev · 4 min · AI Engineering · Career Advice · LLM

08-08

Cloudflare ADLC: Workflow-based CI/CD for agent software factories

Cloudflare argues the bottleneck in software development has moved from implementation to every other SDLC stage, now that AI makes code generation cheap. Their answer: let agents drive more of the lifecycle, not just codegen. The post introduces @cloudflare/ci, local OTel traces for Wrangler, Agent Traces, and a set of primitives meant to turn the SDLC into an 'Agent Development Lifecycle' for software factories. It includes Workflow code that parallelizes lint/test/typecheck/build and then deploys, plus guidance that CI/CD is just one kind of Workflow—workflows can spawn containers, agents, and browsers and persist state for days. The article also lists seven platform requirements for agent-driven delivery: programmatic, horizontally scalable, reproducible, push-based, atomic, permissioned, and self-improving. Useful for engineers building agent infrastructure on Cloudflare or exploring autonomous delivery pipelines.

blog.cloudflare.com · 14 min · Agent Engineering · AI Agents · Cloudflare

08-03

When Coding Is Not the Bottleneck: Three Levels of Software Autonomy

This article adapts a position paper by UC Berkeley RDI researchers, proposing a three-level framework for autonomous software development: code autonomy, pipeline autonomy, and demand autonomy, plus three orthogonal dimensions—specification granularity, temporal autonomy, and oversight mode. It contrasts a concrete win (16 parallel Claude agents building a working C compiler for under $20k) with the observation that frontier agents still degrade sharply on benchmarks that test continued evolution rather than isolated tasks. The authors argue that the immediate industry risk is skipping levels: teams claim level-1 review but merge AI code unchecked, or adopt pipeline autonomy without the needed verification and governance. As coding stops being the bottleneck, requirement specifications, agent audits, and accountability mechanisms displace raw coding skill. Useful for engineers and engineering leaders thinking about agent-driven development and governance.

www.pingwest.com · 8 min · Agents · AI Engineering · LLM

07-11

Agentic test processes: from chip design to AI workflows

Drawing from his experience at chip company Centaur, the author compares test processes that scale well with LLM agents: no code review by default, heavy reliance on fuzzing, and a dedicated test team. He argues that while LLMs are poor at writing tests directly, directed fuzzing with LLMs can find real bugs in minutes. The article highlights the high variance of LLM outputs—benchmark rankings often flip with minor task changes—and cautions against over-reliance on aggregated metrics. Through examples like building a superhuman board game AI, he advocates systematic data-driven iteration over prompt tricks. Targeted at engineers interested in AI-assisted development, testing, and agent workflows.

danluu.com · 91 min · AI Engineering · Benchmarks · Developer Tools

06-30

How To Make Codebases AI Agents Love

This article argues that codebase structure matters more than prompts or AGENTS.md files for AI agent output quality. The core idea is applying 'deep modules' from A Philosophy of Software Design: each module exposes a simple interface controlling lots of implementation. The author introduces 'grey box modules'—developers own and test the interface, AI owns the implementation inside. This improves feedback loops (tests are feedback), navigability (filesystem mirrors mental model), and reduces cognitive load (developers only track 7-8 module boundaries). The article notes TypeScript's difficulty enforcing boundaries and recommends the Effect library. For engineers optimizing AI coding workflows.

www.aihero.dev · 5 min · Agent Architecture · AI Engineering · Code