Posts

AI Coding Assistants Need Faster Feedback, Not Bigger Promises

-
Generated Code Is Only the First Step AI coding assistants can reduce the effort required to draft code, tests, documentation, and configuration. That matters, but typing has rarely been the main constraint in software delivery. Code still has to be understood, reviewed, integrated, secured, deployed, and operated. If those feedback loops are slow or unreliable, generating more code simply moves the queue downstream. Technology leaders should therefore treat AI adoption as a delivery-system change, not a tool rollout. The goal is not to maximize suggestions accepted. The goal is to improve the safe flow of valuable changes into production. Find the New Bottleneck Once teams produce changes faster, existing weaknesses become more visible. Test suites may take too long. Review queues may grow. Environments may be difficult to obtain. Security checks may generate noisy findings. Deployment pipelines may require manual coordination. These constraints will limit the value of AI regard...
Post a Comment
Read more

Platform Exceptions Are Signals, Not Policy Failures

-
Platform teams often treat exceptions as a governance problem. A team requests a different deployment pattern, runtime, or security control, and the immediate response is to defend the standard. Standards matter. They reduce cognitive load, improve supportability, and make controls easier to automate. But a platform that cannot learn from exceptions will eventually become a constraint rather than an accelerator. Separate valid constraints from avoidable preferences Not every exception deserves approval. Some requests are simply attempts to preserve familiar tools or bypass reasonable controls. Platform teams should ask for the engineering constraint behind the request, not just the requested solution. A useful exception process should capture: The requirement the standard path cannot meet The operational and security risks introduced The owner and expected duration of the exception The evidence needed to remove or renew it This creates accountability without turning the conv...
Post a Comment
Read more

Incident Reviews Should Change the System, Not Grade the People

-
Incident reviews often begin with the right intention and drift into the wrong question. Instead of asking how the system allowed a failure to reach customers, teams start evaluating whether individuals followed the expected process. That shift produces cautious meetings, shallow conclusions, and action items focused on reminders or training. It may create the appearance of accountability, but it rarely improves reliability. Look Beyond the Last Human Action An engineer’s mistake may be the final event before an incident, but it is seldom the complete cause. Reliable systems assume that people will mistype commands, misunderstand alerts, overlook documentation, and make decisions with incomplete information. The useful question is not, “Why did someone make that mistake?” It is, “Why was one ordinary mistake able to create this level of impact?” That question directs attention toward weak deployment controls, unclear ownership, unsafe defaults, missing observability, excessiv...
Post a Comment
Read more

Documentation Is Part of the Platform Contract and Makes Your Agents Better

-
Platform teams often treat documentation as the final step before launch. That is backwards. If developers cannot understand, evaluate, and safely use a capability, the capability is not finished. Good documentation is more than a collection of setup instructions. It is part of the interface between a platform team and its users. Like any interface, it needs clear ownership, predictable structure, and ongoing maintenance. That has always mattered for developers. In an AI-enabled engineering organization, it matters even more. Documentation exposes platform complexity When a basic task requires a long guide filled with exceptions, the documentation is not necessarily the problem. It may be revealing unnecessary complexity in the product. That makes documentation work valuable design feedback. Ask an engineer unfamiliar with the service to follow the guide. Watch where assumptions appear, terminology shifts, or required decisions lack context. Those points often indicate that the platfor...
Post a Comment
Read more

Standardize Delivery Outcomes, Not Every Team’s Workflow

-
Engineering leaders often pursue standardization by asking every team to use the same workflow. The intent is reasonable: reduce risk, simplify support, and make delivery easier to govern. But identical workflows are rarely the right goal. A mobile application, a shared library, and a regulated backend service have different release constraints. Forcing them through one rigid process creates workarounds, manual exceptions, and resentment toward the platform. The better approach is to standardize the outcomes that matter while allowing teams flexibility in how they achieve them. Define the delivery contract A delivery contract describes what must be true before software reaches production. It should focus on observable controls rather than a prescribed sequence of tools and pipeline stages. For example, the contract might require: Traceable source, build, artifact, and deployment records Automated security and policy checks A tested rollback or recovery mechanism Clear service...
Post a Comment
Read more

Make Toil Reduction Part of Capacity Planning

-
Most engineering organizations say they want to reduce toil. Far fewer reserve capacity to do it. That gap matters. Repetitive operational work rarely disappears through good intentions. It competes with product delivery, security requirements, incidents, and customer commitments. Unless leaders account for toil during planning, teams will keep absorbing it as an unofficial tax. Toil is a capacity problem Manual access changes, recurring deployment fixes, repetitive incident recovery, and routine environment maintenance consume real engineering time. They also interrupt concentration and make delivery less predictable. Leaders often treat this work as the cost of operating a system. Some of it is. The mistake is accepting the same cost indefinitely without deciding whether automation, simplification, or removal would be a better investment. Do not ask teams to eliminate toil alongside a fully committed roadmap. Make the tradeoff visible. If reducing a recurring task requires ...
Post a Comment
Read more

The Best Deployment Approval Is the One You Can Remove

-
Manual deployment approvals often begin as a reasonable response to risk. Over time, they become permanent fixtures, even when they add little protection. A person clicks a button, but rarely has enough context to independently validate the change. The approval delays delivery while creating the appearance of control. Leaders should ask a harder question: what evidence would allow us to remove this step? Replace permission with evidence Approval gates are most useful when judgment is genuinely required. They are less useful when reviewers simply confirm that automated checks passed or that a ticket contains the expected fields. Those conditions should be enforced by the delivery system. Build pipelines can verify test results, security policies, artifact provenance, change windows, and deployment readiness more consistently than a hurried reviewer. The objective is not to eliminate accountability. It is to make accountability explicit and repeatable. Define an approval remo...
Post a Comment
Read more