AI/CI/CD
Claude and Codex have convinced me (at least this year) that programmers, as we used to know them, are no longer essential in quite the same way. More precisely, you no longer have to write every single line of code yourself. Programming skills have become part of the education needed to understand how systems work. In practice, we increasingly need versatile professionals who can frame problems, visualize unconventional user journeys, design architectures, and evaluate the results.
My idea is that parts of software evolution could be fully automated, driven by actual customer and user experience during day-to-day operation. And I do not mean just fixing bugs. I mean identifying the need for new features without waiting for someone to request them. Let me explain.
To be fair, when I started researching this, I discovered I had reinvented the wheel yet again. IBM proposed Autonomic Computing back in 2003: self-managing systems that monitor their own state and take corrective action (https://doi.org/10.1109/MC.2003.1160055). Today, Sentry Seer (https://sentry.io/product/seer/) can analyze errors and prepare code fixes. PostHog Self-driving (https://posthog.com/self-driving), introduced in 2026, goes further: it analyzes user experience, identifies problems, and uses AI agents to prepare pull requests. So a substantial part of my idea already exists. But I think this concept can be taken much further in complex enterprise information systems.
Imagine any enterprise recordkeeping system. It has screens, functions, and specialized user workstations. Statistical methods tell us how people actually work: how long they spend on each screen, which paths they follow, what mistakes and service warnings appear. We capture exceptions, meaning unexpected errors, and ask for feedback at the end of an action: Was it easy? How would you rate it? Any suggestions?
As the system runs, it accumulates data on user journeys, errors, and experience, and can automatically route that data to AI agents for improvement. The agents categorize findings, identify recurring issues, and propose technical solutions. Essentially, they write standardized, machine-readable specifications that an architect reviews and approves. A business owner joins the process when necessary, particularly if the change affects business logic.
There is an important catch. To produce a good specification, agents need more than a clickstream and time-on-task metrics. They need to understand the domain: business processes, roles, data structures, constraints, and operating rules. A long financial approval process, for example, may be a mandatory control rather than a bad interface. So I propose combining operational telemetry with machine-readable business-process descriptions and engineering knowledge about the system itself. That would let agents do more than spot friction; they could form evidence-based hypotheses for improving functionality.
Approved specifications undergo automated architectural review. From them, the system creates an acceptance-test plan and procedures, generates new test cases or updates existing ones, builds a deployment plan, generates code, and deploys it to a test environment for execution. It is essential to verify not only new features but also existing business rules, access permissions, and compatibility with other modules. The solution then goes to the architect and business owner for acceptance testing. A release is approved based on the results. Some of these steps can be automated for simple fixes; critical changes must remain under human control.
But the really interesting part starts after deployment. The system should determine for itself whether the change actually solved the original problem. Suppose a task used to take ten minutes and now takes three, errors have declined, and user satisfaction has risen. The hypothesis is probably confirmed. If not, the agent analyzes why and proposes another solution. That closes the loop: operation → analysis → specification → development → testing → deployment → outcome evaluation → further evolution.
Users affected by a change receive onboarding when needed, including a personalized introduction to the new functionality, and the system collects feedback on their satisfaction. It decides who only needs a quick tip and who needs a full walkthrough. And this happens continuously.
Obviously, we cannot give AI agents unrestricted permission to rewrite the system they operate in. We need separation of duties, independent checks, architectural guardrails, and rollback capabilities. But CI/CD does not mean a lack of oversight today, either. My proposal is to automate not only the writing and delivery of code, but the very process by which changes are discovered, justified, and implemented.