Approach
AI where it's useful. Rules where they're needed. People where it matters.
I don't start with a model. I start with the process, then decide step by step what should be AI, what should be code, and what needs a person. Pick a case to see where it goes. Every example comes from a real project.
Unstructured / ambiguous
→ AI
Interpretation, classification, summarizing language.
Known rule
→ Code
Calculations, thresholds, validation, state changes.
Uncertain / high-risk
→ A person
Exceptions, policy-sensitive calls, anything that needs responsibility.
Pick a case above.
What I can help build
-
Operational automations
Connect tools, APIs, data and business rules into workflows that actually run, instead of people copying between tabs.
Seen in
-
AI inside workflows
A model where interpretation or classification helps, boxed in by rules so the rest of the system stays predictable.
Seen in
-
Small internal tools
Focused apps that remove a specific piece of repetitive work: review queues, checkers, dashboards people actually open.
Seen in
-
Reliability & human review
Exception paths, review states and evidence, designed in from the start rather than pretending automation never fails.
Seen in ,
A bit about me
I'm Zara. I study Human-Centered Informatics & Psychology and spend most of my time building things: workflows, small tools and a lot of experiments, most of them on GitHub.
I learn best through real implementations, and I'm still going deeper on the backend side: databases, deployment, running things long-term. What I can already do is take a messy process, figure out how it really works, and build something that handles it.
- I like understanding messy systems before touching them.
- I care about what happens when the automation fails.
- I test with real workflows, not just the happy path.
- I'd rather build useful AI than impressive-looking AI.
Have something messy that should be a system?
Start a conversation