Looking at this year’s list surprised even me: a metering portal, a console service, three corporate sites, an online shop, two mobile apps, four simulation engines, a voice assistant, a diagnostic tool, two server builds.
I am not working more. The way I work changed.
The difference between a chat box and a terminal
For a long time I used it like everyone else: open a window, ask, copy the answer, paste into the editor, and if it fails go back and explain.
There is one thing that loop never solves: the model cannot see your project. It knows what you told it. Everything you forgot to mention does not exist — and in any project, the thing you forget is always the critical one.
Now Claude works inside the project: it opens files, searches, runs the test, reads the output, triggers the deploy script and verifies the result.
# before
me → this table looks like this, that function like that… what should I do?
model → (based on what I said) a suggestion
me → paste, run, get an error, go back, explain again
# now
me → run radar against essentekstil.com.tr, put the findings in arastirma.md
model → node cli.js essentekstil.com.tr (42 s)
31 findings · score 38/100 · 6 categories measured, 2 not verified
works/essen/radar-bulgular.md written
A project’s brain is a file
The biggest gain came not from the model’s ability but from where the memory lives.
Every project has a rules file at its root. No conversation in it; decisions. In the folder that produces client work, these are written down:
Never invent — data that cannot be found is left blank, every finding carries a source.
No prices in the presentation — price is given in a separate conversation.
Internal files never ship — the client receives only the portal link.
These are my decisions. But I do not have to repeat them each session. For a new job I open a session and say “prepare a proposal for this address” — and what comes out obeys all of them.
The second layer: keeping what it learned
The rules file holds what the project is. Separate small files hold what the project learned. Each one is a single fact:
- “Default
phpon this machine is 7.1; 8.3 is at this path — lint with that one.” - “
site_statuscodes are counter-intuitive: 1 is not active, it means deleted.” - “Don’t write the deploy command, give me the file list — I run it.”
- “This rsync over WSL makes files 777 on the server; set permissions explicitly.”
All of them were born from a mistake. It happened once, it was written down, it never happened again.
This feels less like software development and more like teaching a colleague how the company works. Except this colleague does not forget, and you can point at where it was written.
The “measure it” rule applies to both of us
The most insidious property of an AI is fluency. It can state something it does not know in exactly the tone it uses for something it does.
I caught this once, live: it proposed an endpoint name for reading an ERP’s bill of materials. Entirely plausible name. No such endpoint existed — the truth was in the controller source. I wrote that up separately.
After that day the rule was written for both of us: every field carries its source; a field without one never reaches the screen.
Tools start appearing on their own
An unexpected side effect: repetition in the workflow turns itself into tooling.
I used to run the same technical audit by hand for every client — certificate, headers, SPF/DKIM, technology version, privacy texts. Then I turned it into an engine: Globya Radar. Now one command scans and writes straight into the client folder.
It took half a day to write. That half day came back across three clients.
The same happened on my own desk: a full disk became a disk analyser, a full inbox became a mail tool. Things I used to say “I don’t have time for” now get done — because half a day became two hours, and a two-hour idea is cheap to try.
Where I stop it
A few boundaries, all born from pain:
| boundary | reason |
|---|---|
| No broad commands on shared hosting | dozens of projects live there; one restart takes them all down |
| I trigger the deploy | the SSH key is in my session; the last look should belong to a person |
| Secrets never enter code | key file separate, outside version control |
| Code in English, conversation in Turkish | code will belong to someone else one day; the conversation is mine |
The real gain
People think of this as “writing code faster”. For me speed is third.
First: the cost of starting drops. Trying an idea became cheap, so ideas get tried. Half of this year’s projects would otherwise still be “I’ll look at it sometime”.
Second: context stops evaporating. I do not have to remember why I changed a server setting three weeks ago; it is written down.
Third: speed. And even that comes mostly from not going backwards.
And one more, hard to measure but real: for someone who works alone, this is having somebody there. Someone you can explain a thing to out loud, someone you can say “try this” to. In a team of one, that is what is most missing.