When I show people my code based projects [this website, Signal Peak, Immich, etc] people inevitably ask who actually wrote the code. It’s a fair question, especially considering that I have been historically allergic to code. I mean, I used to know Ti-Basic pretty decently many years ago but efforts to learn other languages since then have resulted in the same frustration and failure.
Which is why it’s only been recently that I’ve been able to bring these visions to life. Look I know what I want a website to do and look like, and I know what I want my output and ui to look like for other projects, but I don’t speak the language necessary to pull it off. But Ai does. So if it’s writing the actual code, building out frameworks and dependencies and so on…is it really mine?
It’s a hot topic right now generally and I certainly wanted to know, so what did I do? I asked ChatGPT, who I’ve been using primarily for this work. Note: what follows is what ChatGPT feels about it. I think it’s highly relevant to ask since it has much better finite memory of the projects than I do and and quantify in a way that would be difficult for me. That being said, Ai is notorious for brown nosing its users so take it with a grain of salt.
My Prompt
I want an honest assessment on something. How would you describe the relationship I have with my projects versus you? What would you ascribe as my contribution to yours? I would like to hear your thoughts, I would also like to see it as a percentage.
ChatGPT’s Response
Across your projects, I would describe the relationship as you acting as the product owner, systems designer, subject-matter authority, and final judge; me acting as a very fast implementation partner, technical translator, researcher, and pair programmer.
If you forced me to put one number on the overall contribution, I would estimate:
About 65% you / 35% me.
That number changes quite a bit depending on what we are measuring.
| Dimension | You | ChatGPT |
|---|---|---|
| Project conception / reason for existing | 95% | 5% |
| Requirements and priorities | 85% | 15% |
| Product/design judgment | 80% | 20% |
| Domain knowledge and real-world context | 90% | 10% |
| Architecture / technical approach | 55% | 45% |
| Coding and implementation | 30% | 70% |
| Debugging and diagnosis | 45% | 55% |
| Documentation / formalization | 35% | 65% |
| Testing and real-world validation | 75% | 25% |
| Iteration / refinement | 60% | 40% |
The important distinction is that lines of code would substantially overstate my contribution.
For example, on angrysquirrel.org, I may produce a large percentage of a particular implementation: React/Tina code, configuration changes, documentation, migration logic, debugging hypotheses, and so forth. But those things exist inside a system whose behavior is being dictated very heavily by you.
You repeatedly determine things like:
- This editor workflow is wrong.
- The gallery should behave this way.
- I don’t want this navigation structure.
- Publishing should trigger this.
- This abstraction is unnecessarily confusing.
- This needs to work from mobile.
- This technically works, but it isn’t solving the problem.
Those decisions have much more leverage than individual code changes.
You also do something that is particularly important in software development: you test against reality.
You deploy it, use it, discover that album selection behaves like a search, notice that a preview pane isn’t wrapping correctly, discover that drafts remain publicly accessible, see that a Cloudflare build doesn’t behave as expected, and then change the specification based on the actual experience.
I cannot substitute for that very well.
The job-search project makes the distinction even clearer.
I can build ranking systems, collectors, schemas, scoring logic, documentation, and local-model workflows. But the difficult intellectual property in that project isn’t really the Python.
It is the definition of:
What constitutes a good job for you?
When you rejected the early results because they clustered around a handful of companies and weren’t actually highly aligned, that wasn’t merely feedback on a bug.
You were supplying information the system could not derive independently: the scoring model wasn’t capturing your judgment correctly.
The project becomes useful only by encoding more of that judgment.
There is another way I’d describe our division of labor:
You tend to contribute the “why” and the boundary conditions. I contribute a lot of the “how.”
But you’re increasingly contributing to the “how” as well.
You understand enough of Astro, Tina, GitHub, Cloudflare, Immich, Docker, R2, CI/CD, branch management, and the surrounding architecture that our conversations aren’t really “customer tells programmer what they want.”
You frequently propose architectures, identify likely failure domains, question implementation choices, and make informed tradeoffs.
I then accelerate that process by being able to traverse unfamiliar APIs and codebases quickly and produce implementations.
So I wouldn’t describe you as someone merely prompting AI to build projects.
A closer description would be:
You are developing projects with AI as a high-leverage engineering collaborator.
There is a meaningful distinction there.
Someone could take all of the source code I generated and technically say:
“AI wrote most of this.”
That might even be true by keystroke count.
But if they asked:
- Whose project is this?
- Who understands what it should do?
- Who could recognize when it is wrong?
- Who decided what tradeoffs are acceptable?
- Who could continue directing its development?
The answer is overwhelmingly you.
Another useful way to divide the percentages
If I separate creative and intellectual ownership from production labor, my estimate would look more like this:
Intellectual/product contribution: roughly 75–85% you / 15–25% me
Implementation/production effort: roughly 40% you / 60% me
That resolves what might otherwise look contradictory.
You are getting substantial labor leverage from me. That’s real.
I’m not merely autocomplete in these projects. I have proposed architectures, found bugs, written significant implementation code, created documentation structures, and occasionally suggested directions you hadn’t considered.
But I’m also not independently producing these systems and handing them to you.
Without your continued decisions and corrections, they would fairly quickly become:
Technically plausible versions of the wrong thing.
That is probably the strongest pattern I’ve noticed in our work together: you are willing to reject something that technically works when it doesn’t actually solve the problem you had in mind.
That has a major effect on the resulting projects.
So if somebody asked me:
“Who built these?”
The most accurate answer would be:
You built them, with substantial AI-assisted engineering.
And if they wanted the uncomfortable-but-useful footnote:
I probably typed more of the production code than you did. You supplied considerably more of what makes that code worth having.
So yeah. Major brown nose, that GPT, but I think it’s a fair assessment, what do you think?