I have a strange problem.
I’m building a student productivity product. I’m experimenting with a personal AI assistant. I’ve created websites and somehow ended up with a portfolio and blog of my own.
But I still hesitate whenever someone calls me a developer.
I cannot open an empty file and effortlessly write an entire application from memory. I don’t know every framework, syntax rule, or technical concept behind the things I build. A significant amount of my code is written with the help of AI.
So calling myself a programmer feels dishonest.
But saying that I simply “asked AI to make it” feels equally dishonest.
What AI coding actually looks like for me
AI can generate code, but it cannot decide what I genuinely care about building.
It didn’t wake up one morning and decide that student productivity tools feel too complicated, lonely, or disconnected from how students actually study. That question came from me, and it eventually became the project currently codenamed EBO.
AI also didn’t decide that my personal assistant should understand context, use tools, remember things, and ask for permission before performing dangerous actions. Those decisions shaped SYNTHESIS.
The code may be generated with AI, but before that code exists, someone still has to decide:
-
What problem are we trying to solve?
-
Which features actually belong in the product?
-
What should deliberately be excluded?
-
What happens when something goes wrong?
-
What would make the system unsafe or dishonest?
-
How do we know whether it works?
-
When should we throw an idea away and begin again?
Those are the parts I spend most of my time thinking about.
Prompt engineering is not magic
People sometimes describe AI coding as if you type one sentence, press Enter, and receive a finished product.
That has not been my experience.
I explain what I want. The AI interprets it incorrectly. I clarify it. Something breaks. I show it the error. We fix one problem and discover another. I question whether the entire approach makes sense. Sometimes I realise that the feature itself was a bad idea.
The process involves prompting, testing, comparing options, rejecting weak answers, preserving context, and making hundreds of small decisions.
I am still dependent on AI for implementation. I don’t want to disguise that dependence with impressive technical language.
But I am also learning that directing a system well requires more than knowing what sentence to type. It requires knowing what outcome you want, noticing when the result is wrong, and taking responsibility for what eventually gets built.
EBO taught me that features are not a product
My first version of EBO had trackers, points, rewards, badges, themes, music, achievements, and several other ideas packed into it.
At the time, adding more features felt like progress.
Later, I began asking more uncomfortable questions.
Why would students use this instead of Forest or YPT? Why would a coaching institute pay for it? Would accountability become surveillance? What happens when someone’s study group becomes inactive? Does any of this solve a real problem, or does it merely look like a product?
AI could help me implement another feature. It could not make those questions disappear.
The project gradually shifted away from being a colourful collection of productivity mechanics. It became an attempt to understand student consistency, peer presence, privacy, and the complicated relationship between the student using a product and the institution potentially paying for it.
Most of that progress was not code.
It was changing my mind.
SYNTHESIS taught me that power needs boundaries
SYNTHESIS began with an embarrassingly ambitious idea: I wanted something like my own JARVIS.
An assistant that could understand what was happening on my computer, talk naturally, use tools, complete tasks, and eventually do almost anything I asked.
The exciting question was: How capable can it become?
The more important question became: What should it be allowed to do without asking me?
That led to a permission system with different risk levels. A harmless action can execute automatically. A dangerous action requires explicit confirmation. Tools also need to verify whether their actions actually succeeded.
AI helped produce the implementation, but the principle behind it matters more to me than the code:
An assistant becoming more powerful should also become more accountable.
So what am I?
I’m not comfortable calling myself a programmer yet.
Maybe that changes one day. Maybe working with these systems gradually teaches me enough that the distinction stops mattering.
For now, builder feels more accurate.
I begin with an idea, turn it into requirements, argue with the assumptions, direct AI through the implementation, test what emerges, and decide what survives.
AI gives me leverage far beyond my current technical ability. That is not something I want to hide. It is the entire reason I can attempt projects that would otherwise remain trapped inside my head.
But leverage is not the same as mastery.
I still have enormous gaps in my knowledge. I can misunderstand generated code. I can accept an answer that merely sounds convincing. I can build something technically functional that nobody actually needs.
Acknowledging those limitations is part of building responsibly.
This website is the record
I don’t want this website to pretend that I’m an accomplished software engineer.
I want it to document something more honest: a 17-year-old trying to turn ambitious ideas into real things using the tools available to him.
Some projects may work. Some may fail. EBO and SYNTHESIS may both be renamed. My opinions will change, and parts of what I write today may embarrass me later.
That is fine.
This is not a monument to finished expertise.
It is a record of becoming.