Internal engineering acceleration
I use AI as a disciplined engineering tool for codebase exploration, drafting, synthesis, structured review, and reducing startup friction on scoped work.
AI Automation
I use AI and automation in two lanes: internal engineering acceleration and shipped operational workflows.
Those lanes are related, but they are not interchangeable. One helps me move faster as an engineer. The other has to hold up inside real products, real data flow, real failure cases, and real operator decisions.
The useful work is not AI theater. It is production-minded engineering: event-driven workflows, orchestration, summaries, routing, support context, and decision-support layers built on top of actual system truth.
How I split the work
Shipped product and operational workflows
I build automation and AI support into real systems where triggers, state, side effects, guardrails, and human review paths matter more than the model headline.
Stack
These are the platforms and tools I actively use in AI and automation work.
The core stays rooted in software engineering: application code, integration logic, data flow, and operational guardrails. These are the tools that show up most often.
LLM / Model Platforms
These are the model platforms I actively use for shipped workflows, engineering support, and applied automation work.
- OpenAI
- Claude
- Gemini
- DeepSeek
Voice / Audio AI
I use voice and transcription tooling when the workflow needs speech input, transcription, or audio output.
- AssemblyAI
- ElevenLabs
Image / Multimodal
For image or multimodal workflows, I use Gemini image models, including Nano Banana, when the system actually benefits from them.
- Gemini image models / Nano Banana
Automation / Integrations
These are the integration and orchestration tools that show up most often in real workflow implementation.
- n8n
- Make
- Zapier
- GoHighLevel
- Webhooks
- Slack
- Linear
Supporting system layers
These are tools I work with when the workflow needs memory, retrieval, evaluation, or durable execution.
Memory / Context
- LangGraph
- Mem0
- Zep
Retrieval / Knowledge
- PostgreSQL + pgvector
- Pinecone
- Airtable
Observability / Evaluation
- LangSmith
Durable Workflow Runtime
- Temporal
Workflow patterns
The repeated pattern is simple: deterministic backbone first, AI where interpretation helps, humans where judgment matters.
Event-driven workflows triggered from business truth
Trigger / input: A real product event happens: an order changes state, stock moves, a support case appears, or a system status crosses a threshold.
What happens: The system emits the downstream signal, orchestration handles notifications, reporting, follow-on tasks, or operator updates, and the core app remains the source of record.
Where AI is used: Usually none at the trigger level. AI becomes useful later for summarizing, explaining, or prioritizing the operational state created by the event stream.
What stays deterministic: State changes, side effects, and integration calls stay deterministic and traceable.
Human control: Operators still decide on interventions that change money, service flow, customer communication, or operational policy.
Guardrails: Idempotency, retry discipline, visible failure logs, and no hidden business truth inside the automation layer.
AI summaries tied to real operational data
Trigger / input: A user, operator, or support workflow needs a fast explanation of what happened across a noisy set of records or events.
What happens: The system gathers the relevant operational context, prepares a constrained input, and generates a summary or explanation that helps a person understand the state faster.
Where AI is used: AI handles condensation, synthesis, and explanation where raw records are too dense to scan quickly.
What stays deterministic: Record selection, business calculations, and filtering rules remain deterministic.
Human control: Humans read the summary, verify it against source state when needed, and make the actual decision.
Guardrails: Ground the prompt on known records, keep the input narrow, and expose the underlying source data when the summary matters.
Classification, routing, and exception handling
Trigger / input: An incoming request, issue, message, or workflow state needs triage.
What happens: A classifier or rules layer tags the item, proposes a route, and sends it into the right queue, team, or next step. Exceptions break out to a visible review path instead of silently failing.
Where AI is used: AI is useful for soft classification, extraction, and suggestion when the input is messy or semi-structured.
What stays deterministic: Routing rules, escalation conditions, and hard-stop scenarios stay explicit.
Human control: Humans remain in the loop for ambiguous cases, destructive actions, and policy-sensitive paths.
Guardrails: Confidence thresholds, fallback buckets, and auditability on why something was routed a certain way.
Ticket-driven engineering acceleration with AI support
Trigger / input: A scoped engineering ticket exists with enough context to execute.
What happens: I use AI to inspect codebases, draft changes, synthesize context, and accelerate review, but the work still moves through scoped implementation, verification, and explicit ownership.
Where AI is used: Exploration, drafting, summarization, review support, and startup acceleration on well-bounded tasks.
What stays deterministic: Source control, tests, verification steps, and release flow remain standard engineering process.
Human control: I still own architecture, tradeoffs, correctness, and whether the generated output is worth merging.
Guardrails: Ticket scope, isolated branches or worktrees, verification before and after changes, and no blind acceptance of generated code.
Concrete examples
The important part is not abstract belief. It is where these patterns show up in real work.
Dumadine operational reporting and support context
Context: A hospitality operating system only becomes automation-ready when ordering, kitchen flow, stock movement, and accounting behavior live in coherent system state.
Implementation shape: The engineering value is in preserving those boundaries so reporting, summaries, operator explanations, and support tooling can pull from actual product truth instead of stitched-together side systems.
AI role: AI fits at the explanation and synthesis layer: helping operators or support staff understand what happened across dense operational activity.
Engineering value: This reduces manual reconstruction work and makes downstream tooling more credible because it is grounded in the real system.
Issue-to-ticket-to-fix engineering flow
Context: A problem starts as an issue, support report, or implementation request and needs to become shippable engineering work.
Implementation shape: I use Linear, Git, isolated worktrees or branches, and AI-assisted exploration to turn vague reports into scoped execution, then verify changes before they move forward.
AI role: AI helps with codebase inspection, synthesis, draft implementation, and review support, not final authority.
Engineering value: The gain is less startup drag and cleaner execution without losing ownership or verification discipline.
Engineering review, synthesis, and planning flows
Context: Complex work often arrives as scattered code, docs, tickets, comments, and operational notes.
Implementation shape: I use AI to compress that mess into structured plans, review lenses, and implementation sequences, then execute through normal engineering controls.
AI role: The model helps with synthesis and candidate structure. The engineering judgment stays with me.
Engineering value: This is valuable because it converts vague or distributed context into faster, more reliable delivery.
Event-driven downstream actions from core system truth
Context: Operational systems need follow-on actions after the main transaction, but those actions should not become a second source of business truth.
Implementation shape: I prefer application state changes or domain events to trigger downstream workflows in n8n, Make, Zapier, or direct integration layers.
AI role: AI is optional here. The backbone is deterministic orchestration. AI is only added when a human-facing interpretation layer helps.
Engineering value: This keeps the system shape sane: the product owns truth, automation owns execution, and operators can still trace what happened.
Boundaries
I am not selling research credentials. I am selling applied engineering judgment.
The value is in building systems that can safely use automation and AI without letting either one become a hidden, unreviewable mess. That means clear ownership, narrow model responsibilities, deterministic system edges, and visible fallback behavior.
Practical outcomes
The point is better system behavior, less coordination drag, and clearer operational visibility.
I use automation and AI where they reduce manual reconstruction work, clarify system state, or speed up disciplined engineering execution. If they make the system harder to reason about, they do not belong there.