The work didn't disappear. It moved.

Something interesting has happened to the way I work with technology.

I'm building, changing and operating more software than I would once have imagined doing myself. Not because I've become an expert in every technical discipline, or because software engineering has become trivial.

It's because the tools have changed. Dramatically.

I've spent much of my career in technology delivery, bringing together developers, architects, testers, infrastructure specialists and project managers to turn ideas into working services. I know how much effort goes into the work, and how much goes into coordinating everything around it.

Today, an idea can become a working implementation remarkably quickly. I can explore an approach with AI, write and inspect code, develop tests, review changes, deploy infrastructure and observe the results. Sometimes within a single working session.

Increasingly, without needing another person to perform every step.

The work hasn't disappeared. But how it gets done, and where I apply my experience, have changed considerably.

It's not just AI

Much of the conversation about AI and software development centres on code generation. How quickly can an assistant produce working software? Will developers become less important? Is everyone now 'vibe coding'?

I think that misses the bigger change.

AI is arriving alongside an extraordinary ecosystem of accessible technology. GitHub provides version control, pull requests, testing, security tooling and delivery workflows. Cloudflare provides hosting, networking, DNS, security and edge computing. Supabase provides managed databases and application services.

These capabilities aren't new in themselves. What's different is how readily one person can access them, connect them and put them to work. Specialist infrastructure tasks, repeated administration and much of the coordination between components can be reduced or handled by managed services.

The result isn't simply faster coding. It's a much shorter path from an idea to something useful that can actually be operated.

I find that genuinely liberating.

A practical example: .auDO

One example is the .au Domain Observatory (.auDO), an independent public-interest project that repeatedly observes technical trust signals across a fixed panel of 100 Australian domain names.

Behind the public website are collection and analysis processes, stored evidence, scheduled automation and published reports. GitHub, Cloudflare and Supabase provide much of the underlying capability; AI assists with development, investigation, testing and review.

I still write and inspect code, make architectural choices, investigate failures and decide how the service evolves. But I'm not provisioning database servers or manually coordinating every step between collecting observations and publishing findings.

That reduction in effort makes a project like this practical for me to maintain. It doesn't mean every change should move into production as quickly as the tools allow.

When preparing .auDO's Infrastructure Atlas and refreshed homepage for release in October, I held the candidate for two additional daily processing cycles. Automated tests, code reviews and browser checks were important, but I also wanted evidence that the normal collection and publication process behaved as expected before releasing. The Atlas subsequently went live.

The work raised another question: how should publicly observed infrastructure relationships be presented without implying contracts, control or conclusions the evidence couldn't support? Disclosure safeguards and the risk of inference across published data became part of the release decision.

Those are not just coding problems. A successful pipeline cannot answer them for me.

Beyond vibe coding

I understand the appeal of 'vibe coding'. Describing an idea and seeing software emerge is remarkable, especially for experimentation and learning.

But it doesn't adequately describe how I work when I intend to operate and maintain the result.

I'm deciding what to write myself, what to delegate to AI, what to automate and where direct inspection adds the most value. Sometimes I'm in the code. Sometimes I'm investigating a failing test or challenging an implementation. Sometimes I rely on automated evidence and move on.

The level of scrutiny depends on the consequences. A small, reversible experiment is different from a public-facing service or a system that publishes evidence others might rely on. A private system holding sensitive information may deserve even more care.

It's a question of risk, reward and reversibility.

The goal isn't maximum automation or maximum governance. It's proportionate effort for a trustworthy outcome.

Have we automated delivery or improved it?

This is where my background in technology delivery makes me particularly curious.

Agile, DevOps, continuous integration and delivery, automated testing and infrastructure as code have made real contributions. They've also made it possible to build remarkably elaborate processes around processes.

A pull request can trigger tests, security scans, AI-assisted review and deployment workflows. That's useful when the checks address meaningful failure modes. It's less useful when the existence of a workflow becomes a substitute for understanding what it proves.

A green CI pipeline tells me the configured checks passed. It doesn't establish that the right tests exist, that the implementation solves the problem or that the change is appropriate to release.

Continuous delivery can make software releasable on demand. It doesn't oblige us to release immediately. For .auDO, observing actual processing cycles added assurance that another test run couldn't. For a low-risk change with a safe rollback, the same delay might add nothing.

If AI and managed platforms reduce implementation and coordination effort, we should be prepared to question hand-offs, approval rituals and measures of success that reward throughput over outcomes.

Automation should remove unnecessary friction, not give it a new interface.

Operations didn't disappear either

The same tension exists in operations.

Cloudflare can operate infrastructure. Supabase can manage a database platform. GitHub can execute workflows. Monitoring services can alert me when a check fails. That's substantial operational capability without maintaining a conventional infrastructure team.

A provider can keep a database available while the information in it becomes incomplete. A deployment can succeed while the application behaves incorrectly. A website can respond normally while an important collection process has stopped.

For .auDO, reliability isn't only whether the website loads. It's whether observations are collected consistently, analysis completes correctly and the published evidence retains its meaning.

The platform provider doesn't know why that evidence matters, what failure means to readers or when a service should be recovered, changed or withdrawn. I still need to understand the dependencies and make those decisions.

Managed services shift the operational boundary. They don't remove accountability for what happens across it.

I'm not interested in recreating an enterprise operations function around a relatively small project. That would squander much of the benefit. But outsourcing the mechanics of a service is not the same as outsourcing responsibility for it.

What happens to the traditional delivery model?

If an experienced technology practitioner can orchestrate work that once crossed several disciplines, how should we organise technology delivery?

Specialist teams are not suddenly redundant. Critical systems, enterprise environments and complex products need deep expertise, collaboration and independent challenge. I work in those environments and understand their demands.

But some of our traditional delivery machinery exists to coordinate people and activities that technology can now connect more directly.

Which hand-offs still add value? Which controls provide evidence, and which simply document that a step occurred? Are we measuring useful outcomes, or the volume of work moving through a pipeline?

DevOps challenged the separation of development and operations. There's an irony if we dissolve those boundaries only to recreate them as automated ceremony.

We should be willing to redesign the work, not merely accelerate the existing process.

The role of the steward

Making software easier to create also makes it easier to create more of it: more applications, integrations, dependencies and services that someone will eventually need to maintain, secure or retire.

The ability to build something doesn't establish a reason to build it.

That brings me back to stewardship: understanding the problem, choosing sensible architecture, judging evidence, accepting risks consciously and taking responsibility after deployment. Sometimes it means deciding not to build at all.

I haven't moved away from being hands-on. These tools have allowed me to get closer to implementation while giving me more discretion about where my effort goes.

I can write code, direct an AI assistant, inspect a pull request, challenge a dependency, examine a failed run or decide that a release needs more evidence. They are different activities, but all part of the same responsibility.

The work moved

I don't think we're witnessing the disappearance of software engineering or the end of experienced technology teams.

We're seeing a substantial shift in the accessibility of technical capability, the economics of execution and the way human effort can be applied. That should excite us. It should also make us question old assumptions about delivery and operations.

For me, the greatest benefit isn't that AI can write code or a platform can deploy it. It's that I can bring ideas to life, exercise technical judgement and remain accountable for the result, with far less effort spent coordinating the machinery in between.

---

Related: A deployment is not a delivered change