I am not a developer. I also build and maintain working software. Here is how that is possible, and the discipline that keeps it from becoming a liability.
I am not a developer. I run operations and support executives. I also build and maintain a portfolio of working software, and I want to describe how that is possible without overstating it.
What actually changed, and what did not
The barrier that dropped was writing code. That was never the hardest part of software; it was simply the part that excluded people who had not spent years learning syntax.
What did not change is everything around it. Knowing precisely what should be built. Recognising when the answer you got is subtly wrong. Testing properly before anyone depends on it. Understanding what happens when it fails at two in the morning. Those were always the difficult halves, and they are now the entire job.
The tool removed the typing. It did not remove the responsibility, and the responsibility was always where the difficulty lived.
How I work, and the discipline that makes it survivable
1. Write a brief before opening anything
What the thing does, what it must not do, what already exists, and how I will know it works. Every session that has gone badly for me started with a vague instruction and a hope. This is the same discipline as any other operations work, and skipping it fails the same way.
2. Build the smallest slice that actually runs
Not the whole feature. One working piece I can execute and inspect. Long unverified stretches accumulate mistakes that are far more expensive to unpick than to prevent.
3. Read what comes back, and question it
This is the part that separates building something from generating something. If I cannot follow the logic, I ask for it to be explained or simplified until I can. Code I do not understand is code I cannot maintain, and I am the only person here to maintain it.
4. Run it myself and try to break it
Empty inputs, wrong dates, duplicate submissions, the record that does not exist. The failure cases are where real systems fail and where generated code is most often thin.
5. Make everything fail loudly
Every scheduled job I run reports its own errors somewhere I read. A silent failure in something a business depends on is worse than never building it.
6. Write down why, not what
The code will be legible in six months. The reason a threshold is seven days rather than five will not. One comment saves the next person, who is always me.
What this is good for, and where it stops
| What it is good for | Where it stops | What it costs me |
|---|---|---|
| Internal tools and automations | Well within reach, and this is where most of the value for a small business sits. | Time to specify properly, which is the real cost. |
| A working product I use and support | Achievable, and it takes considerably longer than the demos suggest. | Ongoing maintenance, which nobody mentions. |
| Anything touching money or personal data | Reachable, and it needs genuine care and outside review. | I do not treat my own confidence as sufficient here. |
| Anything I could not debug at all | Out of scope, deliberately. | I do not ship what I cannot fix. |
What it is honestly worth
For an operations person, the practical effect is that the gap between identifying a problem and fixing it collapsed. The recurring report that took ninety minutes, the intake form that needed wiring to a tracker, the checklist that needed to reset on reopen: all of those used to require a developer, a budget and a queue. Now they require an afternoon and a clear specification.
That is a genuine change in what an operator can do, and it is the change I would point to rather than any claim about productivity multiples.
What I would caution against is the assumption that this makes software cheap. It makes the first working version fast. Maintenance, edge cases, security and the long tail of things going wrong are unchanged, and they are most of the actual cost of software over its life.
How it breaks
Shipping something you do not understand. It works, until it does not, and then nobody can fix it. This is the failure I am most careful about.
Confidence outrunning testing. Generated code is fluent and looks finished. Looking finished and being correct are different properties.
Skipping the brief. Every bad session I have had traces back to this.
Becoming a single point of failure. If I build things only I understand, I have recreated the key-person risk I write about elsewhere. Readable code and short comments are the mitigation.
How to tell whether it is working
Does it still run when you are not watching? That is the whole test. Anything that only works while you are supervising it is a demonstration rather than a system.