--- theme: none colorSchema: light title: "AI-Assisted Software Engineering: Building Moltis as a Solo Founder" info: | Non Fungible Conference / NFC Summit Lisbon, June 4, 2026 class: text-left transition: slide-left mdc: true drawings: persist: false ---
NFC Summit Lisbon • June 4, 2026
Moltis logo
AI-Assisted
Software Engineering
Building Moltis as a solo founder
Fabien Penso · https://pen.so · @fabienpenso
https://www.moltis.org
--- # Who I am
I have been building internet products, infrastructure, and developer tools since the late 1990s.
Founder / CTO
LinuxFr, Stuart, Kard
Open-source communities, logistics, and fintech products used at scale.
Principal engineer
Beam, Constellations, Dango
Rust systems, encrypted sync, Cosmos infrastructure, exchanges, and production indexing for Stargaze.
Solo builder
Constellations -> Moltis
Two serious solo Rust projects: before and after daily AI-assisted engineering.
This talk comes from day-to-day AI-assisted work on software I have to maintain and ship. Later this month I am joining Microsoft AI and moving to California.
--- # What Moltis is
A local-first persistent personal agent server: one Rust binary between you, your tools, your memory, your channels, and multiple LLM providers.
GitHub stars
2.7K
moltis-org/moltis
Issues
367
49 open · 318 closed
Pull requests
679
12 open · 667 closed
Merged PRs
566
shipping velocity
Gateway
One place for agents
Streaming chat, provider routing, coding agents, tools, sessions, and APIs.
Memory
Persistent context
Durable sessions, long-term memory, workspace files, project context, hooks, and cron.
Control
Runs on your machine
Password/passkey auth, encrypted vault, sandboxing, local data, and self-hosted deploys.
--- # Before AI: Constellations was not a toy
A production Cosmos indexer I built before the current AI-assisted workflow.
Workload
3,500h
about 2 years full-time
Codebase
118K
current tokei LoC
Traffic
15M+
Stargaze requests/day
What it did
Indexed CosmWasm contracts and on-chain data for Stargaze, Osmosis, Neutron, Noble, dYdX, Kujira, and more.
Why it mattered
Stargaze pages went from loading in >30 seconds to <500ms through a real-time API.
This is my baseline for "before AI": a serious solo Rust infrastructure project, running real production traffic.
---
What changed in output
Same person. Same solo-founder pattern. Plain tokei code lines in checked-out repositories.
Codebase size by elapsed project time
Same 18-week window: 26.1x more LoC with Moltis
linear scale
Moltisafter 18 weeks with AI
474.6K LoC
Constellationsafter the same 18 weeks
18.2K LoC
Constellationsafter 126 weeks of solo work
118.2K LoC
0
100K
200K
300K
475K
--- # Rewrites are no longer sacred
The cost of generating code is collapsing. The cost that remains is deciding, verifying, and maintaining it.
Bun: Zig → Rust
first → last commit: 9d 18h
Bun PR #30412
6,755
commits merged into main for the Zig → Rust rewrite.
Bun PR #30412
1M
lines rewritten across 2,188 changed files.
Test suite
99.8%
of Bun's pre-existing tests reportedly passing.
Jarred Sumner wrote that the port fixed memory leaks and flaky tests, and gave Bun compiler-assisted tools for memory bugs that had cost enormous debugging time.
When code is cheap, rewriting becomes a product decision, not an engineering impossibility.
--- # My actual workflow
Human loop
1. Define the user outcome
2. Ask AI to inspect the codebase first
3. Make the smallest correct change
4. Review every diff
5. Run tests, linters, and builds
6. Ship, then listen to users
Collaboration
Share prompts, not patches
Other solo founders ask similar things. A prompt is faster to share than a PR, and safer because I can rerun it through my guardrails.
AI workflow
I barely touch the IDE
Most changes start from agent sessions now. I open the IDE only a few times a week.
--- # My parallel issue workflow
The goal is not one giant AI session. It is many isolated, reviewable workstreams.
Queue
Issues first
Bugs first, because I want Moltis to be stable.
Isolation
One workspace per PR
Separate workspace for each issue or pull request.
Agents
OpenCode + Claude
Both 20x memberships, more than 10B tokens/month.
Adversarial review
Agents check agents
One model reviews another for fixes or simpler approaches.
External reviewer
Greptile on GitHub
Agents work through feedback until it reaches 5/5.
Human owner
Fast final review
I review, merge, then E2E and release gates catch regressions.
This keeps multiple issues moving at once. I am building Polyphony to automate more of this: https://polyphony.to
--- # Add determinism around the AI
AI is non-deterministic. Surround it with deterministic systems so bad output cannot land quietly.
Old lesson
Stop debating taste
Spaces vs tabs taught me: put RuboCop, formatters, and linters in CI, then move on.
New lesson
Bound the agent
In Moltis, CI is the immune system that keeps AI output from drifting away from the project.
Language choice
Rust helps AI
Types, ownership, and memory safety turn whole classes of mistakes into compiler errors.
--- # Moltis CI is the immune system
These gates turn taste, architecture, and release risk into executable constraints.
Shape
rustfmt, Biome, i18n parity, install docs sync, 1,500-line file limit.
Rust behavior
Clippy with -D warnings, nextest, coverage, contract tests.
Frontend
TypeScript check, Vite build, Playwright E2E, no JS-error assertions.
Integrations
Live provider tests, provider E2E scenarios, OpenAI/Ollama/sandbox E2E.
Release gates
Provider release checks, package builds, tag validation, changelog guard.
Local parity
local-validate.sh publishes PR statuses: fmt, lint, test, E2E, macOS, iOS.
The AI can generate code quickly. CI decides whether the project accepts it.
---
Release safety: what users install
Faster code increases the blast radius of a bad release. The artifact needs proof attached to it.
Signatures
Sigstore + my GPG key
Keyless CI signatures plus detached maintainer GPG signatures for release assets.
Integrity
Checksums + verification
SHA256/SHA512 checksums; verify-release.sh pins my GPG fingerprint.
SBOM
CycloneDX + SPDX
Release SBOMs are generated, signed, checksumed, uploaded, and attested.
Attestations
GitHub provenance
Artifacts, container images, and SBOMs link back to the workflow run.
---
Release safety: where it came from
Supply-chain safety is not only signatures. It is also protecting the factory and recording source provenance.
CI protection
Zizmor guards workflows
CI, release, docs, Homebrew, and benchmark workflows are scanned for attack paths.
Release gates
Tests before packages
Clippy, tests, E2E, and live provider checks must pass before packaging.
Source provenance
Pin GitHub origins
Skills/plugins pin GitHub commit SHAs; source drift requires re-trust.
Audit trail
Leave evidence behind
Trust, install, source-drift, enable/disable, and dependency events are logged.
--- # How I talk to the AI
Weak
Build auth
Useful
Add password reset using the existing auth middleware. Persist tokens in the current credential store. Add tests for expiry and invalid tokens. Keep existing routes compatible.
Prompting is delegation. Context is management.
--- # The PR workflow is the next bottleneck
AI did not just make typing faster. It changed the volume, shape, and cadence of software work.
GitHub Octoverse 2025
65M -> 82M
monthly code pushes from 2024 to 2025, a 25% jump.
GitHub Octoverse 2025
39.5M -> 47.5M
monthly PRs created from 2024 to 2025, +20.4% YoY.
GitHub workflow report
11.5B
Actions minutes running tests in 2025, +35% year over year.
Source: GitHub Octoverse 2025 and GitHub workflow report. Supplemental GitHub search snapshot: 2026 PR creation was 2.55x the same May week in 2025.
The old loop was designed for scarce code
Issue → branch → PR → human review → merge works when changes are relatively expensive.
new problem
attention scarcity
The tooling of the last 20 years needs to be rethought: review, ownership, validation, and product intent have to become more continuous than a GitHub PR page.
--- # What changed for me as a solo founder
More surface area
I can touch frontend, backend, docs, tests, CI, and releases in one session.
Faster recovery
When I hit a compiler error or broken build, I lose less time getting unstuck.
Higher standards
Because code is cheaper, tests, docs, and polish are less optional.
The job becomes less "can I build this?" and more "is this worth building, and can I keep it coherent?"
--- # Beginner rules that actually help
1. Learn enough code to review the output
2. Keep tasks small
3. Use version control from day one
4. Ask AI to explain the change
5. Run the app and test the unhappy paths
6. Never paste secrets casually
7. Prefer boring architecture
8. Let users, not demos, judge progress
If you cannot tell whether the result is good, slow down. The tool is not the adult in the room.
AI is great for builders, but it also exposes the next bottlenecks: good ideas, distribution, taste, and stamina. Coding was never the only hard part.
--- # Thank you
Moltis
https://www.moltis.org
https://github.com/moltis-org/moltis
Fabien Penso · https://pen.so · @fabienpenso
--- # Appendix: if the slot becomes 20 minutes
Show a real workflow
Issue, isolated workspace, agent pass, review feedback, tests, merge.
Open Moltis briefly
Use it only to make the talk concrete, not as a product tour.
Security guardrails
Explain why CI, signatures, SBOMs, and provenance matter more when code moves faster.
Audience Q&A
Ask what they are building and where AI currently breaks their workflow.