When I returned to blogging in May 2025, I was making room for thoughts I had mostly kept to myself for twenty years. The early posts were experiments and observations: side projects, new tools, the pleasure of learning something unfamiliar. Over the following sixteen months, a different question gradually took over the archive.
What happens to engineering when producing the code stops consuming so much of the work?
At first, the answer looked like speed. An application built over a weekend. A feature that no longer required several evenings at the keyboard. More ideas surviving the distance between thinking about them and trying them.
Then the questions got harder. What if the specification was wrong? What if the tests approved a behavior nobody wanted? What if the agent finished its task while the developer inherited an afternoon of platform problems? Who understood the system after it shipped?
AI is moving the constraint in software engineering. As implementation gets cheaper, the quality of our intent, our platforms, and our judgment determines how much of that speed becomes useful progress.
I first concentrated on making intent explicit and enforcing it through the delivery system. Experience widened the question. A precise specification and passing checks could still leave me with the wrong software, and my argument still needed to account for the people who would operate what shipped.
That is the journey I can trace through this work. It draws on two connected settings: years leading cloud and platform teams, and personal projects where I can put new methods under pressure myself. The lessons travel between them. Their results need to keep their original labels.
How the emphasis in my writing evolved. The overlapping periods reflect a learning process; each stage adds obligations that the next one still has to carry.
We already had a delivery problem
Before AI · Day zero
The story starts before the agents.
Across two cloud builds in financial services over fifteen years, I had already watched the same pattern repeat. Infrastructure became easier to acquire. Delivering software responsibly remained a negotiation among identity, security, networking, deployment, cost, and the people who knew how each piece worked.
We could create another environment. We could not create shared understanding with an API call.
In Building Cloud From Zero, I looked back at the bets that helped. Centralized landing zones put identity, logging, network controls, and tagging underneath the first workloads. A common infrastructure workflow reduced the number of systems engineers had to learn. Golden paths gave ordinary services a supported route to production, with escape hatches for work that needed something different.
Those choices were contested. Application teams wanted to get moving. Leaders wanted to know whether the platform team was creating the bottleneck it claimed to remove. Building the foundation before the first workload imposed a visible delay in exchange for benefits that would take years to become obvious.
Some decisions also aged badly. We let too many teams choose their own delivery tools, then paid for that variability whenever a control changed. We carried multi-cloud aspirations longer than their practical value justified. We treated cost optimization as a later phase, which meant spending engineering time recovering money we could have avoided spending.
The most recent FinOps push I described reached a 46% effective optimization rate across our cloud estate. That was a result worth being proud of, alongside a lesson about putting cost discipline into the foundation. It was a cloud operating result; I have no basis for presenting it as an AI savings figure.
That is the technical debt underneath this story: accumulated exceptions, repeated low-value decisions, and knowledge that only worked when the right person was available. It lived in the organization as well as in the code.
By the time AI arrived in the development workflow, we had a useful precedent. A powerful capability becomes broadly useful when people can inherit the conditions for using it well. Cloud access had needed a platform. AI access would need one too.
Writing the problem down was the beginning of trust
August-December 2025
My early AI writing carried real enthusiasm. I was building things I might otherwise have left in a notebook. I was also acquiring enough subscriptions to make curiosity look like a billing problem.
By August, From Vibe Mode to Spec Mode was already pointing toward structure. Requirements, design, and an implementation plan gave the model something better to work from than an enthusiastic request. September's craftsmanship essay brought familiar engineering expectations into that interaction: small changes, clear responsibilities, tests, and maintainable code.
There was a tradeoff. Writing down the problem consumed some of the time the tool appeared to save. For an experiment, that could feel excessive. For software someone would depend on, it was the beginning of being able to trust the result.
The experiments were beginning to act on the world, too. In September, a small agent watching my personal AWS spending emailed me when I crossed a budget threshold. It was a modest result, but it made the shift tangible: the system could watch for something I cared about and bring it to my attention without waiting for a question.
The skepticism deserved a hearing too. In September's adoption essay, I acknowledged the distance between my own enthusiasm and what other developers experienced. Change fatigue, unfamiliar workflows, and uncertainty about output quality were real constraints. A leader's successful side project did not settle the adoption question for a team maintaining a large existing system.
My productivity app offered a smaller corrective. The original appeal was simplicity and local control. User requests pushed it toward optional encrypted sync and an interface agents could use. The technology opened possibilities; people still determined which possibilities mattered.
By November, my confidence rested more explicitly on acceptance criteria, review, and testing. Delegating implementation did not make the result someone else's responsibility.
That was the first foundation: make intent explicit, give it standards, and keep learning from what actually happens. The same leadership instincts appearing in my posts about teams and continuous improvement belonged here. Listen to skepticism. Make disagreement useful. Fix the conditions around the work instead of treating every difficulty as a person's failure to adapt.
Corrections started compounding
January-April 2026
Early 2026 supplied concrete reasons to keep going.
In February, I built the TravelTimes notification system in a day. In March, I reported an Android version built in about eight hours over a weekend, using the existing iOS application, screenshots, and coding standards as the reference. At the time of that post, the Android app was awaiting store review.
Those were meaningful outcomes in my own work. They were also bounded ones. I brought years of engineering experience, a working product, and a clear idea of its behavior. Eight hours was the reported effort for that port, not a controlled comparison establishing how much faster every engineer could become.
In my own repositories I held the whole mental model: the intent, the edge cases, and the deployment target. Every prompt carried that context without my noticing. In an enterprise system that context is spread across years of commits, tickets, and the memory of whoever built the service. What worked on a weekend project could not be repeated across an enterprise codebase without infrastructure to supply what my own head had been providing.
What mattered architecturally was the reference. The agent had an answer to what the application should do. I could spend more of my attention on behavior, edge cases, and whether the implementation belonged on the target platform.
By March and April, I was trying to make those conditions repeatable. Coding standards moved from text I pasted into conversations into reusable instructions. Frequent checks became automated feedback. Focused agents took on bounded review tasks. Lessons from mistakes went into files the next session could read.
The same instinct appeared in Pipeline-First and The Agentic SDLC. A collection of capable tools still leaves someone carrying intent, decisions, and evidence between them. The Context Spine was my name for the continuity the workflow needed: enough durable state that each stage could understand what had been decided and what remained to be proved.
By the end of April, I could describe my working method in three words: spec, standards, specialists. Define the behavior. Establish the engineering bar. Assign focused work inside those boundaries.
This was the inflection point. A correction could improve the next run, because it became part of the system rather than another conversation I had to remember to repeat. The compounding mechanism was better defaults and reusable knowledge. In March, I reported fewer review cycles, easier onboarding, and growing reviewer trust across projects and teams. Those were qualitative observations, but they pointed toward something more durable than a fast first draft.
That also clarified the platform opportunity. Asking every engineer to assemble a personal collection of instructions, hooks, permissions, and integrations would reproduce the fragmentation we had already paid for in cloud. Shared workflows needed owners, maintenance, and a supported path for exceptions.
The platform had another product to build.
The system started arguing back
April-July 2026
The encouraging results were real. So were the failures.
In April, I documented an audit hook that had been broken for nine days before I noticed. The automation I relied on to make activity visible had quietly stopped doing its job.
The more consequential failure was a database migration whose mocked tests passed while the real behavior failed in production. A user lost local task data. The mocks conformed to my code rather than to the database, so the tests confirmed my assumptions instead of the system's behavior. The tests had declared success, and someone who trusted the software had lost part of their work. That consequence was still mine to own. I changed the testing approach to exercise an in-memory IndexedDB implementation rather than mocking away the boundary that mattered.
There was a less dramatic lesson in the feedback loop itself. Running the full test suite after every agent response added roughly thirty seconds each time. I replaced that with a fast type check of about three seconds and kept the full suite before pushing. A safeguard that made every interaction expensive was becoming an incentive to disable the safeguard.
Then, in May, I rejected a refactor with a clean diff and passing tests. It solved the problem I had written down. It did not solve the problem we actually had.
That failure sharpened the specification argument. A detailed spec can still encode the wrong understanding. Good framing requires knowledge of the situation: the constraint that cannot move, the dependency that matters, the behavior customers rely on even though nobody documented it. Tests can check a mistaken requirement with perfect consistency.
My language about automation needed the same scrutiny. The dark-factory metaphor helped me describe repeatable delivery. My actual practice remained more conditional. While rebuilding TravelTimes in April, I still described reading every generated line. By July, my personal pipeline had shifted toward reviewing meaningful plans, testing running previews, and auditing samples of merged work. The scope of delegation changed as the surrounding evidence improved.
In Two Gates and a Night Shift, that became a concrete arrangement: human approval of consequential plans, then release approval after testing the preview. Agents built, reviewed, and handled bounded maintenance between those decisions. Low-risk work had a lighter path. The builder could not approve its own release, and the maintenance routine escalated questions of intent.
Even that arrangement had a known weakness: agents from the same model family could share blind spots. I described spot-checking roughly one in ten merged pull requests and withdrawing autonomy if the checks stopped supporting it. The telemetry was newly added; the post explicitly deferred outcome numbers until there was enough evidence to report them.
That is a more useful account of trust than confidence in a particular model. Delegation has a scope, evidence, and a way to be reduced.
The platform became part of the AI experience
August-September 2026
By August, the argument had moved beyond the individual coding session.
The modernization essays asked what becomes possible when translation and implementation cost less. They also identified the limit: before replacing an old system, we need evidence of what it actually does. Characterization tests, representative workloads, and comparisons between old and new behavior preserve knowledge that a fluent rewrite can otherwise erase. Cheaper generation raises the value of a trustworthy answer key.
Agents were exposing another kind of missing knowledge inside the developer platform. A developer can work around incomplete documentation by asking a colleague. An agent encounters the same gaps differently: a retired example, an ambiguous capability, an approval boundary that exists only in someone's memory.
That makes agent readiness a useful test of developer experience. When the supported path cannot be discovered without tribal knowledge, the platform has work to do.
Asking every developer to reassemble that knowledge for every session made less sense as adoption grew. Trusted context belonged in the platform: authoritative standards, service ownership, supported patterns, and access rules. Each answer needed an owner and a version; obsolete answers needed to be retired. More retrieval would not settle which conflicting source the organization stood behind.
With that foundation, the interface could move up. I proposed letting developers express the workload they need, its data sensitivity, availability requirements, and ownership. The platform would turn that into structured, reviewable intent, and an agent would map it to approved capabilities.
The golden path remains underneath. The engineer still has to understand the consequences of the availability target and the data classification. Remembering an internal module name is a different kind of knowledge, and the platform can carry more of that burden.
There was a hole in the argument, though, and in Nobody Pages the Agent I named it. Too much of my writing ended at deployment. A passing gate did not establish that someone could diagnose the running service, restore its data, or execute its rollback.
Operability had to travel with the specification: ownership, service objectives, failure modes, recovery paths, and evidence from exercising them. A generated runbook still needed to be tried. The midnight incident in that essay was hypothetical. The obligation to prepare for it applies to every service we ship.
A proposed platform-supported journey. Human decisions depend on risk and evidence, and operating lessons return to the context that guides the next change.
By September 1, I could describe a practical direction and an honest current boundary. For most failure categories, help was explaining the problem where it occurred. For a narrow set, the platform was handling the failure itself. The August essays set out an agenda for broader intent interfaces and systematic operability checks; they did not report a completed rollout.
The ownership rule made the direction concrete. Repair what belongs to the platform. Propose changes to a developer's code and leave the decision with its owner. A successful retry needs a diagnosis, and repeated repairs need to stay visible to the platform team so that temporary recovery does not become permanent hidden work.
The measurable gains in this account remain specific: the day spent building notifications, the roughly eight-hour port, the shorter local feedback loop. I do not yet have a published before-and-after series showing enterprise deployment frequency, recovery time, or net developer effort attributable to this AI work. That missing evidence determines what I should measure next.
The cultural direction is clearer. In my own workflow, corrections increasingly become changes to standards, and autonomy has to keep earning its scope. For teams, the leadership obligation is to make it safe to challenge output, report friction, and ask for help. A dashboard that improves because engineers become reluctant to escalate would be measuring a retreat from trust.
Give the time back, and prove it came back
Next horizon
The next phase begins with a more demanding unit of progress: a completed, verified journey.
Take a developer trying to create and deploy a service. Follow the work through configuration, policy checks, review, platform support, and a deployment that meets its operating requirements. The agent finishing is one event inside that journey. Any saving needs to survive what happens afterward.
This is where The AI Operating Ledger and Where the Saved Hour Goes lead me. Measure elapsed time separately from active human effort. Include verification, rework, coordination, support, model usage, and the cost of maintaining the automation. Compare similar work and keep failed attempts in view. Ask developers whether the experience improved, because interruptions and uncertainty do not always leave useful timestamps.
Count changes across all roles, including reductions outside implementation. The added effort is relative to comparable work before the change. A positive remainder creates a choice about how to use it; elapsed time and financial cost need their own measures.
I would start with one frequent journey and one accountable platform owner. Establish the baseline with the teams using it, fix the most expensive recurring obstacle, and repeat the comparison. Sometimes the remedy will involve an agent. Sometimes it will be a canonical example, a better error, or a clearer decision about ownership.
The architectural agenda follows from that discipline. Trusted context needs freshness checks and access controls. Agent capabilities need bounded permissions and traceable actions. Model changes need evaluation against real tasks. Legacy modernization needs behavioral evidence before large-scale replacement. Autonomous delivery needs a pace the service and its operators can sustain.
There is an organizational agenda too, and it may be harder.
My writing on apprenticeship identifies a tension we cannot solve with better prompts. We want experienced engineers exercising judgment over automated work. Much of that judgment was learned by implementing, debugging, reviewing, and living with consequences. Removing those experiences without replacing their learning value consumes the capability the new system depends on. If an organization delegates all its mundane implementation to models, it risks creating a dangerous seniority cliff: plenty of senior engineers directing agents today, but no pipeline cultivating the next generation of engineers who can spot when a generated architecture is quietly flawed.
So give engineers supported opportunities to predict a failure, explain a generated change, inspect a production trace, and practice recovery. Let them work with someone who can challenge their reasoning. Fund that time as part of delivery. Reducing the burden of platform trivia should leave more room to understand systems.
The same honesty belongs in the economic conversation. Lower implementation cost changes the price of some work; it does not decide who receives the benefit. The essays about AI economics, open source, and the human bargain keep returning to that distinction. Maintenance, evaluation, and learning still need people and investment. A vendor's attractive price is not an operating strategy.
When time does come back, decide with the team what it is for. It might fund reliability work, a modernization experiment, mentorship, or a day with fewer interruptions. Immediately filling every recovered minute with another assignment is a choice about output. We should say so plainly.
I began this stretch of writing excited about how much more I could build. I remain excited. The possibility has become more interesting as its conditions have become clearer.
The work ahead is to make good engineering easier to inherit: clear intent, reliable platforms, evidence that survives delivery, and people with enough time and understanding to make the next decision well.
I want the measure of this change to be the software we can trust and the engineers who have more room to think.
