LiveAI Systems
MORPH
Teach software a decision by making it yourself. It writes the code, the tests, and the questions it still can’t answer.
Open it and try itericjokl.com / indexAvailable for engineering workLocal --:--:--
Product Engineer / AI Systems Builder
I design and build software from the interface through the systems underneath it, with a focus on AI, automation, verification, and products that hold up in the real world.
- 01AI Systems
- 02Product Engineering
- 03Production Software
- 04Open Source
- Build
- ca43bd1 · 2026-09-29
- Pointer
- x —.——— y —.———
- Depth
- 000%
02/Featured work
Three systems you can open, run, or clone.
03/What I build
Four areas I can own end to end.
01
AI Systems
I build the infrastructure around models rather than calls to them: routing, caching, program synthesis and planning. Then I build the verification that decides whether the output can be trusted enough to act on.
- LLM routing
- pgvector
- Program synthesis
- Automated planning
- Test generation
Proven byMORPHContextGate
02
Product Engineering
I take a product from an unclear brief to a shipped interface, including the hard UI most builds route around. The data model comes first and the screens follow it.
- React 19
- Next.js
- TypeScript (strict)
- Design systems
Proven byPresenceNew England Event Planners
03
Backend & Infrastructure
Typed services, versioned schemas and queues that survive a restart. Correctness is a command anyone can run, and CI blocks the merge when it fails.
- Python / FastAPI
- PostgreSQL
- Redis
- Docker
- GitHub Actions
04
Production Web Systems
Sites with real traffic and revenue riding on them, built to load fast, rank and convert. Search and conversion are engineering problems, not copy applied after launch.
- Technical SEO
- Core Web Vitals
- Structured data
- Analytics
Proven byCT Party Busericjokl.com
04/Featured interactive system
MORPH. Teach software a decision by making it yourself.
Every team has decisions that run on rules nobody wrote down: who gets access, which deploy ships, which lead goes to sales. MORPH learns them from a person doing the work, then turns them into tested, versioned code that refuses to guess outside what it was shown.
- 01DemonstrateDo the task. It watches what you read and what you press.
- 02SynthesiseIt rebuilds the decision as a state machine.
- 03VerifyIt writes tests, replays every past case, and names what it still doesn't know.
- 04ExportYou get TypeScript, a test suite and a portable policy file.
Release gates are tribal knowledge. The senior engineer who holds them is the bottleneck on every merge.
3 demonstrations inrules out
if linesChanged <= 44.5→ Shippedif linesChanged > 735.5→ Blockedif touchesAuth == true→ Sent for reviewanything else → refuses to decide and asks a person
Synthesised by the engine during the site build from one teach, one contrast and one correction. Nothing in this panel was written by hand.
05/Real-world proof
I don't only build demos.
I've built software tied to real businesses: customers, traffic, revenue and the operational constraints that come with them.
- 01New England Event PlannersProduct EngineeringAn event platform built around a tested revenue path and build gates that block a bad ship.In build
- 02CT Party BusProduction SystemsA live booking business that wins competitive local search and turns it into enquiries.Commercial
- 03FactorFlowProduct EngineeringA decision tool that turns a vague choice into weighted factors and a score you can argue with.Live
06/How I work
Build. Measure. Verify.
01
Build
Get the real thing running
A working system teaches more in a day than a spec does in a month. I get the real path running end to end first, then make it good.
02
Measure
Expose what actually happens
Opinions about performance are not evidence. Latency, errors, conversions and load times get measured on the running system and shown, not quoted.
03
Verify
Prove it, don't assume it
Important behavior gets a test that fails for a specific reason and a gate that blocks the merge. If it can't be checked, it isn't finished.
07/About
The person behind the work.
United States · remote
I'm Eric. I build software end to end: I pick a problem up before anyone has decided exactly what it is, and carry it through architecture, code, tests and deployment to the part where you find out whether it worked.
I've done the design, the engineering, the copy and the launch myself, then watched what real traffic did to it. That's why I care most about whether a system can be checked, and why I'm quick at spotting which technical decision the business outcome actually depends on.
Right now I'm focused on AI systems and automation, and on the verification that decides whether software can be trusted to act on its own.
08/Writing
How I think about the work.
Engineering6 min read
Give the Revenue Path Its Own Test Suite
Most applications test every route to roughly the same standard. But one path carries the money, and when it breaks quietly you find out from a slow month — not from CI.
Read →Engineering7 min read
What Makes a Semantic Cache Safe Enough to Ship
A semantic cache that is too eager does not return an error. It returns a confident, well-formed, wrong answer. Here is how I tested for that while building ContextGate.
Read →Strategy6 min read
Website vs. Lead Generation System: The One Thing That Matters
Most websites fail because they're built as digital brochures with no clear purpose. A lead generation system is structured differently—it removes friction and guides visitors toward a single outcome.
Read →09/Contact
Building something difficult?
I'm interested in product engineering, AI infrastructure, automation, and systems where correctness matters.