I Was a DevOps Engineer. Then AI Started Writing Working Software

I probably noticed the potential of AI-generated software later than many people.

My background is in system and network administration, followed by DevOps. For most of my career, code was something developers provided so it could be tested, deployed, monitored, and hosted. The code I wrote myself was usually a script, or a set of infrastructure definitions capable of deploying an entire environment.

I was not thinking about building applications.

My early experiences with AI coding did not give me much reason to reconsider. You could spend days prompting, receive a huge amount of code, and still have nothing useful at the end. Then, in what felt like a very short period, that changed. The same general category of tools went from producing impressive-looking failures to producing working web and mobile applications.

Not necessarily good code. Not necessarily secure code. But working code.

That surprised me enough to start experimenting.

Finding a workflow that felt familiar

I tried several available tools, including Replit and Cursor. At the time, more than a year ago, Replit worked best for the kind of web application I wanted to build. It felt mature, and its GitHub integration was especially important to me.

The GitHub part made the whole idea seem practical.

I did not need to trust an AI platform with the entire software lifecycle. I could use it to build, push the result to GitHub, and continue with procedures I already understood: test, deploy, test again, fix, redeploy, monitor.

The biggest problem at the beginning was prompting.

Like many people, I started reading articles about how to prompt properly. There were guides, lists of tricks, and plenty of confident advice. Eventually, I realized something obvious: I could ask AI to help me create better prompts too.

That became the working method. I would give one AI system the full context, discuss the feature or problem, and use that conversation to prepare a detailed prompt for the tool building the application. While the application grew, the prompting process improved with it.

The goal was not to become better at asking for random code. The goal was to reduce ambiguity before any code was generated.

The first real application

The first application I built this way was InvoShift, an invoicing system with a built-in time tracker.

The main application functionality appeared surprisingly quickly. After roughly a week of non-intensive work, the essential product was there. Users could track time and generate invoices. The app worked.

That does not mean the development process was smooth.

Replit could fix one bug and create several others. Sometimes it would work for twenty minutes after receiving a prompt, then finish without making a single detectable change. Even familiar procedures, such as configuring a GitHub Actions workflow, did not always work on the first attempt.

Still, the central fact was difficult to ignore: I had a functioning application that I would not have built myself in the traditional way.

Once the application existed, my attention moved to the areas I knew best. I started thinking about automation, then security, deployment, monitoring, backups, and customer support. I did not advertise InvoShift until those surrounding systems were in place.

That sequence became important later. The application was only one part of the product.

Realizing I was no longer doing much coding

Two or three months into the project, I noticed that my role had changed.

I was not manually writing most of the application. I was describing situations and features, discussing them with AI, preparing prompts, reviewing the results, and moving the code through a familiar delivery process.

The loop looked something like this:

1. 1.Discuss the requirement.
2. 2.Turn it into a detailed prompt.
3. 3.Let the coding agent implement it.
4. 4.Push the result.
5. 5.Test and deploy it.
6. 6.Find what is wrong.
7. 7.Return to the discussion.

At some point, it started to feel less like an experiment with AI and more like a delivery system.

It combined AI tools with Git-based workflows, automated checks, deployment procedures, monitoring, and operational controls. A few months later, once it became clear that most of this system worked reliably, I began thinking that it could become a service.

Not a service that simply promises to generate code quickly. A service that builds an application and takes responsibility for everything around it.

That was the beginning of ARAG.

Why design became part of the process

There was another problem I wanted to solve.

I do not enjoy working with visuals. Website design, logos, font comparisons, and trying colors one by one have never been the parts of a project I wanted to spend time on.

Fortunately, we are at a point where almost everything seems to involve AI, almost everything is becoming a platform, and almost everything has an API.

That led me to explore what I thought of as design as code. Figma became part of the workflow. In the current process, a design can be generated programmatically and then reviewed as an actual visual system.

This matters for more than my personal dislike of visual work.

A friend of mine runs a marketing agency that also builds websites. Their projects often follow the same pattern. Everyone agrees on features and menus, then arguments begin after implementation:

"The menu is correct, but I wanted it on the other side."

"I wanted a different red."

"It does what we discussed, but I thought it would shine when it did that."

A design should show more than colors and fonts. It should show arrangement, placeholders, interactions, hover states, and the expected behavior of the page. This is why ARAG plans to provide three design directions before development and before the first payment.

The client should see what they are getting, not try to reconstruct it from notes in an email.

AI is only the coding part

ARAG means "fast" in Armenian, and speed is part of the idea. But speed alone is not the service.

AI is used for coding because it can dramatically reduce implementation time. Everything else comes from nearly twenty years of experience in IT, beginning in corporate system administration and continuing through DevOps and infrastructure work.

The real offer is a controlled process around the code: requirements, design, automated checks, deployment, monitoring, backups, maintenance, and support.

I still have a negative view of vibe coding when it is treated as a complete development process. Asking an AI to build an app and seeing the app work is not enough. Like any beginner, an AI coding agent needs careful supervision, checking, and rechecking before its work reaches production.

The useful part is not that AI can write code.

The useful part is that AI-generated code can be placed inside a disciplined system operated by someone who knows what must happen before software can be trusted.