DEV Community

Cover image for How My Medicine Student Girlfriend Completed Simple Development Tasks for Me
Süleyman Özgür Özarpacı
Süleyman Özgür Özarpacı

Posted on

How My Medicine Student Girlfriend Completed Simple Development Tasks for Me

I have a girlfriend who is studying medicine. She has no background in programming, but she is highly adaptive and curious. One day, I decided to give her some of my development tasks and see what would happen.

The development environment was already running, so I simply handed my computer to her. I explained at a high level how to interact with the Cursor's UI, how to prompt the AI, and how to review results. After that, I went off to do my chores.

Some time later, she came back and showed me the result. It was surprisingly acceptable. I reviewed the code and found no major issues. She had even generated an AI-based commit message, which was reasonable, and then committed her first piece of code.

Encouraged by this, I gave her another task. This one was more complex: it involved APIs, SSR, and Tailwind—in short, a frontend task. It was clearly too large to be solved with a single prompt, so I gave her one key piece of advice:

Don’t give the whole task at once. Break it into smaller steps.
Start with a static frontend, then integrate the API, and finally make it SSR-compatible.

With that guidance, I went back to my chores.

When I returned, she had completed the task. Once again, she generated an AI commit message and committed the changes herself.

She continued this process and completed all five of my tasks in about 1 to 1.5 hours. At the end, she looked at me and said,

“Is this your job? You just explain what you need, and after some time it’s done? That’s too easy.”

At that point, I had nothing to say.

She enjoyed “vibe coding,” I finished my chores, and everyone was happy.

Observations and Reflections

I’m not entirely sure where this fits from an ethical perspective, but I genuinely enjoyed the experience. What made it interesting was not productivity, but observation.

I was able to see how a non-programmer approaches software development using modern AI-assisted tools. I saw the struggles: understanding abstract concepts, translating vague requirements into concrete steps, and deciding whether the output was actually correct. I also saw the enjoyment: fast feedback, visible progress, and a sense of accomplishment despite having no traditional programming background.

Watching this process made one thing very clear: the real challenge was never typing code. It was breaking the problem down, sequencing tasks, and knowing when something was “done enough” versus technically correct.

A More Realistic Take on AI in Development

I don’t believe that modern software development is shifting from writing code to directing systems. That framing feels misleading.

What I do believe is this: AI is becoming extremely good at helping us solve well-scoped, basic problems, often with one or two prompts. For larger or more complex tasks, it still requires clear, step-by-step instructions. And those instructions do not come from the AI; they come from the engineer.

In highly abstracted or well-separated projects, you are still the engineer of the system. You define the architecture, the constraints, the trade-offs, and the long-term direction. AI does not replace that role. It acts as a companion.

A very capable one.

AI helps by:

  • Implementing routine or repetitive code quickly
  • Improving existing code through refactoring
  • Writing tests and suggesting edge cases
  • Surfacing relevant documentation and context
  • Bootstrapping features or even entire applications

But none of this removes the need for engineering judgment. AI does not understand business context, long-term maintainability, or non-obvious constraints unless those are explicitly provided, and even then, it cannot own those decisions.

In practice, AI behaves more like an always-available junior-to-mid-level collaborator. It can move fast, but it still needs guidance, boundaries, and review.

Conclusion

This small experiment reinforced something important for me: AI is not replacing software engineers, but it is reshaping how we work.

The value of an engineer is increasingly found in problem decomposition, system design, and critical evaluation, not in typing speed or memorizing syntax. When those skills are present, AI becomes a powerful multiplier. When they are not, AI output quickly degrades into noise.

Seeing a medical student, someone completely outside the software world, successfully complete development tasks was both impressive and grounding. It showed how accessible tooling has become but also highlighted how much invisible expertise still sits behind “simple” instructions.

And yes, it also means I might outsource more development tasks at home, at least when chores are involved.

Top comments (0)