Help, My Boss Started Programming with LLMs (mo42.bearblog.dev)

Non-engineering leaders are increasingly using LLMs to write code and open pull requests, accelerating iteration, increasing PR volume, and letting domain experts directly patch small annoyances. This democratization can surface valuable product knowledge and faster feedback loops: sales, support, and finance can propose and implement fixes without waiting for engineers. Many superficial issues—style, naming, formatting—can be auto-fixed by linters and CI, so the surface-level mess isn’t the main concern. The real risk is erosion of the codebase’s implicit architecture and design intent. When contributors don’t share the engineering team’s mental model (the “tree” structure of replaceable components), changes can turn that structure into a fragile graph where edits ripple unpredictably, spawning bugs and slowing future work. Reviewers must catch architectural regressions, which burdens seniors and can allow less confident reviewers to merge harmful changes. The antidote is explicit ownership and governance: treat engineers as architects/curators, maintain clear interfaces and boundaries, invest in review standards and automated checks for design constraints, and invite cross-functional contributors under structured stewardship to preserve maintainability while reaping the benefits of wider participation.