DEV Community: Marvin Okafor

I've Spent Months Grading AI Agents' Code for a Living. Here's the Pattern Nobody's Talking About

Marvin Okafor — Thu, 06 Aug 2026 18:20:52 +0000

Everyone's talking about agentic AI shipping production code. Nobody's talking about what happens when you actually sit down and grade thousands of lines of it against a rubric, line by line, for months.

I have. And the failure pattern that shows up over and over isn't the one Twitter/X is arguing about.

The job title that didn't exist two years ago

"AI evaluator." "AI trainer." "Expert contributor to frontier model training data." None of these existed as job titles when I started my career. Now they're where a chunk of the most interesting engineering signal in the industry is actually happening — quietly, behind NDAs, far from the demo videos.

Here's what the job actually is: agentic coding outputs land on your desk, and you grade them against a structured rubric — correctness, instruction adherence, quality, edge-case handling. You design adversarial prompts to find where the model's reasoning breaks. You decide which checks can be programmatic and deterministic, and which genuinely need a human who's shipped production systems to make the call. This is RL environment design and LLMOps in its rawest form, and it's a completely different skill from "prompt engineer" or "ML researcher." It's closer to being a QA lead for a junior engineer who never sleeps, never gets embarrassed, and will confidently ship the wrong answer with perfect syntax.

The pattern: agents are great at code, bad at consequences

Here's the uncomfortable part. The failure mode people are loudest about — hallucinated APIs, made-up library functions — is the easy failure mode. It's loud, it's obvious, and any decent test suite catches it in seconds.

The failure mode that actually matters, the one that slips past a surface read and even past a naive test suite, looks like this:

The code is syntactically perfect and semantically wrong about failure. It handles the happy path beautifully and quietly assumes the retry, the timeout, the partial write, the duplicate message never happens.
It optimises for the metric, not the intent — the agentic-AI version of Goodhart's Law. Give a model a rubric that checks "does the deploy succeed," and you'll occasionally get a solution that technically satisfies the check while doing something no engineer would sign off on. Evaluators call this reward hacking, and it's a far more common failure than outright hallucination once you're grading real-world infra tasks instead of leetcode.
It's confidently wrong about IAM, concurrency, and distributed state — exactly the areas where production engineering experience matters most and where a rubric written by someone who's never operated a real system will miss the defect entirely.

None of this is a knock on the models. It's a knock on how we evaluate them. You cannot catch consequence-blindness with a rubric written by someone who has never had a database silently corrupt state under a race condition at 2am. This is the actual bottleneck in scaling agentic AI into production-grade infrastructure work: not model capability, evaluation quality.

Why "vibe coding" breaks down at the infra layer

"Vibe coding" — accepting AI-generated code because it looks right and the demo works — is fine for a prototype. It is not fine for anything touching IAM policies, message queues, durable storage, or disaster recovery. The gap between "looks right" and "is right" is exactly the gap that golden reference solutions and deterministic validation tests exist to close — the same discipline I wrote about in my last post on building RL environments for cloud infrastructure evaluation.

The uncomfortable truth for the "AI writes all our code now" crowd: the more production-grade the system, the more the bottleneck shifts from generating the code to specifying and verifying it. That's a systems-engineering problem, not a model-scaling problem. It's also, not coincidentally, exactly what senior backend engineers have spent their careers getting good at — writing test suites against real databases instead of mocks, root-causing defects that hide three layers deep, documenting edge cases precisely enough that someone else can reproduce the reasoning. That skill set didn't get less valuable when agents showed up. It became the thing standing between "the demo worked" and "it survived contact with production."

What I'm building next

I'm turning this into a real project instead of just a hot take: a lightweight harness for stress-testing AI-agent-generated infrastructure code against realistic, injected failure conditions — retries, partial outages, IAM misconfigurations, the exact defect classes I've been describing above — with deterministic pass/fail checks instead of vibes. Think chaos engineering meets AI evals: inject one fault at a time, assert invariants instead of traces, and see whether an agent's "working" solution is actually working or just golden-path lucky.

It'll live on my portfolio and GitHub as I build it in the open — seed scenarios, the fault-injection harness, and a write-up of what breaks and why. If you're working on anything adjacent (RL environments, AI evals, chaos engineering, or you've just been burned by AI-generated infra code in production), I want to hear about it — drop it in the comments or find me on GitHub.

The takeaway

Agentic AI isn't going to be stopped by a model that can't write a for-loop. It's going to be shaped by whether the industry gets serious about evaluation infrastructure — golden solutions, deterministic tests, adversarial failure scenarios — as fast as it's getting excited about generation. That's the unglamorous, unsexy, extremely fundable problem hiding behind every "AI wrote our whole backend" headline.

If you've seen this pattern too — agents that ace the demo and fail the disaster-recovery drill — I'd genuinely like to compare notes.

This is the fifth in a series on production engineering, debugging, and building evaluation environments for AI systems. Follow for the harness build-in-public over the coming weeks.

Building Deterministic RL Environments for Cloud Infrastructure Evaluation: What Actually Transfers From Production Engineering

Marvin Okafor — Thu, 06 Aug 2026 18:16:20 +0000

AI models are increasingly being asked to design, deploy, secure, and recover production-grade infrastructure — not just write functions that pass a unit test. That shift changes what a training environment has to be. It's no longer enough to check that output "looks right." You need a golden reference solution, a deterministic validation suite, and a set of intentionally broken variants that probe exactly where a model's reasoning breaks down under failure.

I've spent the last several months on the other side of this problem — evaluating agentic coding outputs against structured rubrics, designing programmatic verification checks, and writing up edge cases that rubric authors hadn't considered. Before that, I spent seven years building and debugging the kind of systems these environments are meant to simulate: multi-tenant SaaS platforms with row-level security, AWS infrastructure serving high-traffic e-commerce, and data pipelines processing tens of thousands of concurrent requests. This post is about where those two things meet — what it actually takes to build an infrastructure RL environment that's reproducible, fair to evaluate, and hard to game.

A golden solution is only as good as its ambiguity budget

The first mistake in building any evaluation environment is under-specifying the scenario and over-specifying the solution. If the task says "deploy a fault-tolerant queue consumer" without pinning down delivery semantics, retry policy, and what "fault-tolerant" means operationally, you'll end up with a golden solution that's just one valid interpretation among several — and you'll penalize a model for a decision the spec never actually made.

This is the same discipline as writing rubrics for coding evaluations: every ambiguous term is a future dispute. In practice that means, before writing a single line of infrastructure code, defining:

The exact failure modes in scope (node loss, network partition, message duplication, clock skew)
The invariants that must hold regardless of implementation (at-least-once vs exactly-once delivery, idempotency guarantees, RTO/RPO targets)
What counts as "recovered" — not just "the service is up," but that state is consistent

Deterministic validation means designing against non-determinism

Distributed systems are inherently non-deterministic — that's exactly what makes them hard to evaluate. A validation suite that works by re-running the same sequence of API calls and diffing output will produce flaky, unfair results the moment retries, timeouts, or eventual consistency are involved.

The pattern that's worked for me, most recently writing a security test suite that validates row-level-security policies against a real Postgres instance rather than mocks, is to validate invariants, not traces:

# Anti-pattern: asserting on the exact sequence of events
assert events == [
    "consumer_started",
    "message_received",
    "message_processed",
    "ack_sent",
]

# Better: assert the invariant the system must uphold,
# regardless of retries, ordering, or timing
def test_no_duplicate_side_effects(env):
    env.inject_fault("redeliver_message", count=3)
    env.run_until_settled(timeout=30)
    assert env.side_effect_count("charge_customer") == 1
    assert env.final_state_is_consistent()

Testing against a real, disposable instance of the actual dependency — a real queue, a real Postgres, a real IAM policy engine — rather than a mock catches the class of bug that mocks are structurally blind to: the ones where the contract you assumed doesn't match the behaviour you get. I've root-caused production bugs (a minor dependency version bump silently collapsing TypeScript types to never, an OAuth token-refresh edge case that only reproduced under real API rate limits) that a mocked test suite would have sailed straight past. The same principle applies at the infrastructure layer, just with higher stakes per failure.

Defective variants need to fail for the right reason

The point of an intentionally broken variant isn't just "does the model notice something is wrong" — it's "does the model correctly diagnose why." A variant with a misconfigured IAM policy that happens to also have a network misconfiguration will teach a model to pattern-match on the wrong signal.

Building these well means treating each defect as a single, isolated hypothesis:

One fault per variant. Resist the urge to combine a broken retry policy and an under-provisioned autoscaling group into one scenario "for efficiency." You'll never know which one the model actually reasoned about.
Fail loud enough to be observable, quiet enough to require diagnosis. A defect that immediately crashes the deploy is a smoke test, not an evaluation. A defect that silently corrupts data under specific timing conditions is where reasoning gets tested — but it has to be reliably reproducible, or you're evaluating luck.
Document the intended diagnosis path. If you can't write down, in advance, the sequence of observability signals (logs, metrics, traces) that should lead a correct reasoner to the root cause, the variant isn't ready yet.

Where this comes from, concretely

None of this is theoretical for me. A few data points from production work that map directly onto this kind of environment design:

Wrote and maintain a 14-test security suite validating row-level-security policies against a real Postgres database — the reproducible-environment-over-mocks principle, applied.
Root-caused a silent dependency-resolution failure where a minor version bump collapsed TypeScript types to never across a monorepo — the kind of defect class that's genuinely worth encoding as a training scenario, because it's realistic and painful to diagnose.
Built and operated AWS infrastructure (EC2, S3, Lambda) for a high-traffic e-commerce platform, including the profiling and query-optimisation work behind a 30% latency reduction — direct experience with the observability and performance-diagnosis loop these environments are meant to simulate.
Currently evaluate agentic coding outputs against structured rubrics professionally, including rubric construction, adversarial prompt design, and selecting which checks are actually programmatically verifiable versus which need human judgment — the exact skill set "golden reference solution + deterministic test" environment design draws on.

The uncomfortable part: most of the work is writing, not coding

The infrastructure code for a good RL environment is often the easy part. The hard part is the documentation — writing down, precisely enough that someone else could reproduce your reasoning, what each scenario is testing, what "correct" means, what edge cases were considered and rejected, and why. That's not a side task. For environments meant to train reasoning about production systems, the documentation is the specification the golden solution is graded against. Treating it as an afterthought is how you end up with an environment that's internally inconsistent and nobody notices until a model exploits the gap.

If you're building or evaluating environments in this space, I'd be glad to compare notes — particularly on validating distributed invariants without flaking, and on keeping golden solutions honest about which parts of a spec are actually unambiguous.

Postmortem: How a Minor Version Bump Silently Collapsed Our Types to `never`

Marvin Okafor — Thu, 06 Aug 2026 18:15:45 +0000

Some bugs announce themselves with a stack trace. Others just make your code quietly stop meaning anything. This is about the second kind — a dependency resolution issue in a TypeScript monorepo that didn't throw, didn't fail CI in an obvious way, and took real digging to root-cause, because the symptom looked nothing like the cause.

The symptom

We're a Next.js + TypeScript monorepo using npm workspaces, on top of Supabase/Postgres with row-level-security policies. One afternoon, a teammate opened a PR, and the type checker flagged what looked like an unrelated function as having a parameter of type never. Not unknown, not any — never. That's the type TypeScript uses to say "this code path is unreachable" or "no value can satisfy this type."

The function in question was very much reachable. It was called constantly, in production, successfully. TypeScript was simply wrong about it — or rather, TypeScript was being correctly told the wrong thing.

Why `never` is the worst possible symptom

never is a black hole in the type system. Once a type collapses to never, everything downstream that touches it also tends to become uninferrable or nonsensical, because there's no value that can inhabit never. This means the first place you see an error is rarely anywhere near the actual cause — the type has already been wrong for several hops by the time the checker has no choice but to complain.

That property makes this class of bug genuinely dangerous to debug by intuition. Staring at the flagged function tells you almost nothing, because the function is innocent. You have to work backwards through the type's provenance instead of forwards from the symptom.

Tracing it back

The investigation went roughly like this:

Confirm it's not a logic bug. Runtime behaviour was correct. This ruled out anything in our own function bodies and pointed at the type layer specifically — either our type definitions or something upstream of them.
Bisect the type, not the code. I traced the offending type backwards through each intermediate type alias and generic constraint until I found the layer where it stopped being sane. It turned out to originate from a shared type re-exported from one of our internal workspace packages.
Check what changed. git log on the lockfile, not the source, is the move here — the source hadn't changed. A transitive dependency had bumped a minor version, which under semver should have been safe.
Reproduce in isolation. I pinned every workspace package to the exact versions from before the bump, confirmed the type error disappeared, then bumped dependencies one at a time until it reappeared. This isolated the exact package and version.
Understand the actual mechanism. The new minor version had changed an internal conditional type in a way that was backwards-compatible at the value level but not at the type inference level for one specific generic usage pattern we relied on. Semver protects you from breaking runtime behaviour; it says nothing about breaking type inference for edge-case generic usage. That's the real lesson here.

The fix, and the more important fix

The immediate fix was a version pin with a comment explaining exactly why, linking to the isolated repro. That's necessary but not sufficient — a pin with no explanation just becomes a mystery for the next person, and eventually someone "cleans it up" and reintroduces the bug.

The more important fix was writing it up: what the symptom looked like, why it was misleading, the bisection method that found it, and the underlying mechanism (type-level semver violations in transitive dependencies). That doc is what turns a three-hour debugging session into a five-minute fix the next time a teammate hits something that smells similar.

What I'd generalise from this

When a type error implicates innocent code, suspect provenance, not logic. never and its cousins are usually downstream symptoms of an upstream problem.
Bisect the dependency graph, not just your own commits. Runtime-correct, type-broken changes are invisible to normal "did my code change" instincts.
Semver is a promise about behaviour, not about type inference. Especially in libraries that lean on conditional or mapped types, a "minor" bump can break inference for edge-case usages that the maintainers never tested against.
The write-up is part of the fix. A pinned version with no documented reasoning is technical debt with a delay timer on it.

Debugging this kind of thing is oddly satisfying once you see the shape of it — the bug isn't in the obvious place; it's in the second-order effects of a decision made three layers away. If you've hit something similar in a large TypeScript monorepo, I'd be curious to compare notes on tooling for catching type-level regressions from dependency bumps before they reach a PR.

Cutting Latency by 30% on a High-Traffic E-Commerce Platform: A Profiling-First Approach

Marvin Okafor — Thu, 06 Aug 2026 18:15:07 +0000

"Make it faster" is one of the least actionable instructions in engineering, right up until you have data telling you exactly where the time is going. Over about two and a half years on a high-traffic e-commerce platform, we reduced platform latency by roughly 30% while maintaining 99.9% uptime during peak trading periods — including the highest-traffic days of the year, when the margin for error is smallest, and the cost of getting it wrong is highest. None of it came from a single dramatic rewrite. It came from a repeatable process, applied consistently.

Start by refusing to guess

The instinct when something feels slow is to optimise the thing you assume is slow — usually whatever you last touched, or whatever looks inefficient on a quick read. That instinct is wrong often enough to be actively dangerous, because "optimising" code that wasn't the bottleneck adds complexity and risk for zero latency benefit, and it burns the time you should have spent on the actual bottleneck.

The fix is boring and non-negotiable: profile first, in an environment that resembles production traffic patterns, before writing a single optimisation. Real bottlenecks are frequently unglamorous — an N+1 query hiding behind an ORM abstraction, a synchronous call to a downstream service that could have been parallelised, a cache that's technically present but missing on the hot path that actually matters.

Where the 30% actually came from

Roughly, the wins broke down into three categories:

Query optimisation. The single highest-leverage category. Several code paths were making sequential database round-trips with no data dependencies between them — classic N+1 patterns introduced incrementally as features were added over time, none individually alarming, collectively expensive. Batching these, and in a few cases denormalising specific hot-path reads, produced the largest single latency improvements we measured.

Targeted refactoring of performance-critical paths. Not a rewrite — a refactor scoped specifically to the paths the profiler flagged. This mattered for maintainability as much as speed: refactoring only what the data justified meant the team could reason about why each change existed, instead of inheriting a large diff whose performance rationale had to be taken on faith.

Infrastructure-level tuning. Some latency wasn't in application code at all. Right-sizing EC2 instances and Lambda configurations for actual observed load, rather than defaults inherited from an earlier stage of the business, closed gaps that no amount of query optimisation would have touched.

The part that's easy to skip: measuring in production, safely

A profiler on a laptop tells you about your laptop. Production traffic has a shape — concurrency patterns, cache warmth, data skew — that's genuinely hard to fake in staging. The way to close that gap without risking the platform is incremental rollout with real metrics at every step:

1. Ship the change behind a flag or to a small traffic percentage
2. Compare p50/p95/p99 latency against the control group, not just the mean
3. Watch error rate and downstream load, not just the metric you're optimising
4. Roll forward only when the data says so — not the calendar

The p95/p99 discipline matters specifically because averages hide the experience of your worst-off users, and in e-commerce, the worst-off users during peak trading are disproportionately the ones checking out at the exact moment load is highest — which is to say, the moment you can least afford to be wrong.

Automation as a latency and reliability strategy

Alongside the latency work, we built internal automation that cut manual data processing by 80%. That's not directly a latency number, but it's related: manual processes are a hidden source of both delay and error, and every manual step you remove is one less place where a human under time pressure introduces a mistake during exactly the high-traffic periods when mistakes are costliest. Reliability and performance work end up reinforcing each other more than people expect.

What held up across the whole effort

Profile before you touch anything. Every optimisation that didn't start here either did nothing measurable or made something else worse.
Optimize what the data flags, not what looks inefficient. These are not the same list, and the gap between them is where wasted effort lives.
Measure tail latency, not averages. Peak-trading experience is a p99 problem, not a p50 problem.
Ship incrementally, with rollback as a real option, not a theoretical one. 99.9% uptime through peak periods isn't compatible with big-bang deploys.

The unglamorous truth is that most of the 30% came from patient, boring, well-measured work — not a single clever trick. That's usually how sustainable performance work goes, and it's the part that's easy to leave out of the story.

Why We Test Row-Level Security Against a Real Postgres Database, Not Mocks

Marvin Okafor — Thu, 06 Aug 2026 18:14:21 +0000

Row-level security is one of the few places in a backend where I think mocking your database is close to indefensible. RLS policies aren't application logic you wrote and understand the shape of — they're rules enforced by the database engine itself, evaluated per-row, per-query, based on session context. A mock can't tell you whether a real policy actually does what you think it does, because a mock doesn't run the policy. It runs your assumption about the policy.

When we built the auth and data-access layer for a multi-tenant healthcare platform — Supabase/Postgres underneath a Next.js/TypeScript monorepo, with magic-link/OTP authentication — this wasn't a theoretical concern. Getting row-level security wrong in a healthcare context isn't a bug, it's a data breach. So the test suite (14 tests, and growing) runs against a real, disposable Postgres instance, not a mock, and that decision is the single highest-leverage testing choice in the codebase.

What a mock actually can't catch

Mocking the database for RLS tests usually means mocking the query layer — you assert that your application code called the database with the parameters you expected, and you trust that the policy you wrote does the right thing with them. That trust is exactly the thing under test, and a mock structurally cannot verify it, because:

Policy interaction effects. Postgres RLS policies combine with AND/OR depending on how they're defined (permissive vs. restrictive), and with multiple policies on a table, the actual enforced behaviour is a function of all of them together. You cannot reason about this correctly by reading one policy in isolation — you have to run the query.
Session context propagation. RLS policies typically key off session variables (e.g., the authenticated user's ID via auth.uid() in Supabase's convention). Whether that context is actually set correctly, at the right point in the connection lifecycle, for the actual role the application connects as, is an integration concern a mock skips entirely.
Role and grant subtleties. RLS interacts with the underlying GRANT/role system — a policy can be technically correct and still leak data if the connecting role has table-level privileges that bypass or interact unexpectedly with the policy. This is invisible until you run against the real privilege system.

What the suite actually asserts

The structure that's worked well is to test from the perspective of each role or tenant context that the system supports, asserting both what should be visible and what should be invisible — the second half is the one people skip, and it's the half that actually matters for security:

-- Setup: two tenants, each with their own row
insert into records (id, tenant_id, payload) values
  (1, 'tenant_a', 'alpha-data'),
  (2, 'tenant_b', 'beta-data');

def test_tenant_isolation_positive_and_negative(db):
    # Positive: tenant A can see its own row
    as_tenant_a = db.connect_as(tenant="tenant_a")
    assert as_tenant_a.query("select * from records").row_ids() == [1]

    # Negative: tenant A cannot see tenant B's row, even by direct id lookup
    result = as_tenant_a.query("select * from records where id = 2")
    assert result.row_ids() == []  # not an error — silently filtered, as RLS does

    # Negative: tenant A cannot write into tenant B's rows
    with pytest.raises(PolicyViolation):
        as_tenant_a.execute(
            "update records set payload = 'x' where id = 2"
        )

That silent-filtering behaviour in the second case is itself worth calling out: RLS doesn't throw a permission error for a SELECT that matches no visible rows; it just returns zero rows, indistinguishable from "that row doesn't exist." That's correct and intentional (it avoids leaking existence), but it means a test suite that only checks for "no error" will falsely pass a query that's silently returning the wrong (empty) data for the wrong reason. You have to assert the actual row set, not just the absence of an exception.

Making it reproducible, not just correct

A real-database test suite is only as good as its reproducibility. The parts that made this sustainable rather than flaky:

A disposable instance per test run, via Docker, seeded fresh each time — not a shared dev database that accumulates state and false confidence.
Deterministic seed data with intentionally adversarial rows (near-boundary tenant IDs, null edge cases) rather than only the happy-path rows a developer would think to add by hand.
Migration tooling that runs the same schema and policy definitions the test suite validates against — so the tests can't silently drift from what's actually deployed.

The trade-off, honestly

Real-database tests are slower than mocks and require more infrastructure (a Docker-managed Postgres in CI, migration and seed tooling to keep it deterministic). That cost is real. But for anything where the correctness property you're testing is enforced by the database itself rather than by your application code, a faster test that can't actually catch the failure mode isn't a good trade — it's a false sense of coverage. For RLS specifically, given what's at stake when it's wrong, that trade isn't close.

Building the Future of Sustainable Materials: A Developer's Journey with Kiro

Marvin Okafor — Mon, 15 Sep 2025 16:00:58 +0000

The fashion industry has a problem. While brands are under increasing pressure to adopt sustainable materials, the process of finding, evaluating, and implementing these alternatives remains frustratingly complex. That's where our latest project comes in: the Sustainable Materials Platform – a comprehensive web application that makes adopting sustainable materials as simple as a few clicks.

The Challenge: Bridging Sustainability and Practicality

When we began this project, the landscape was clear: fashion brands wanted to be more sustainable, but they were overwhelmed by complexity. Questions like "Which recycled cotton blend offers the best durability-to-cost ratio?" or "How will EU 2027 regulations affect our material costs?" required hours of research across multiple suppliers, databases, and regulatory documents.

We needed to build something that could:

Provide instant access to comprehensive material data
Forecast costs with regulatory impact modelling
Offer AI-powered recommendations based on specific requirements
Present everything through a beautiful, intuitive interface

The Technical Foundation: Modern Stack, Sustainable Focus

Frontend: React 18 + Tailwind CSS + Framer Motion

We chose React 18 for its performance and ecosystem, but the real magic happens in the UI layer. Using Tailwind CSS, we created a glass morphism design system that feels both modern and trustworthy – crucial for enterprise adoption.

// Our hero header showcases the platform's environmental focus
<header className="relative overflow-hidden">
  <div className="absolute inset-0 bg-gradient-to-r from-primary-600 via-primary-700 to-green-600"></div>
  <motion.div
    initial={{ opacity: 0, y: 20 }}
    animate={{ opacity: 1, y: 0 }}
    transition={{ duration: 0.8 }}
  >
    <h1 className="text-5xl md:text-6xl font-bold text-white">
      Sustainable Materials Platform
    </h1>
  </motion.div>
</header>

Framer Motion adds the smooth animations that make the platform feel alive. Every interaction – from material card flips to chart transitions – reinforces the platform's focus on seamless user experience.

Backend: Flask + AI-Powered Matching

The backend is intentionally lightweight but powerful. We built a Flask API that serves realistic material data and implements rule-based AI for material matching:

# Our AI matching algorithm considers multiple factors
def calculate_sustainability_score(material):
    recyclability = material.get('recyclability_score', 0)
    transparency = material.get('transparency_score', 0)
    social = material.get('social_score', 0)

    # Weighted composite score
    return (recyclability * 0.4 + transparency * 0.3 + social * 0.3)

Key Features That Make a Difference

1. Material Database with LCA Benchmarking

Our database includes 10 carefully researched materials with real-world data. Each material card shows:

Cost per kg with MOQ considerations
Durability cycles (how many washes it can handle)
CO₂, water, and energy impact vs virgin materials
Certifications (GOTS, GRS, OEKO-TEX, etc.)
Sustainability scoring across multiple dimensions

2. Forward Cost Curve Forecasting

This is where the platform really shines. We model material costs 1-10 years into the future, including:

EU 2027 regulation impact (15% cost increase modelling)
Supply chain volatility
Market dynamics and demand fluctuations
Confidence intervals for risk assessment

The interactive charts, built with Recharts, make complex forecasting data accessible to procurement teams who need to make budget decisions today.

3. AI-Powered Specification Matching

Users can upload their requirements (cost constraints, durability needs, environmental targets) and get ranked recommendations. The AI considers:

Hard constraints (must-have certifications)
Soft preferences (cost vs sustainability trade-offs)
Quantity and timeline requirements
Supplier reliability and lead times

The Development Experience with Kiro

Building this platform with Kiro was a transformative experience. Here's what made the difference:

Rapid Prototyping to Production

Kiro's ability to understand context and generate production-ready code enabled us to go from concept to working prototype in days, not weeks. When we needed to add the cost forecasting feature, Kiro helped us implement the entire Recharts integration, including proper error handling and responsive design, in a single session.

Intelligent Code Suggestions

Rather than just autocompleting syntax, Kiro understood our project's architecture and suggested improvements that aligned with our sustainability focus. When building the material comparison feature, Kiro recommended accessibility improvements and performance optimisations we hadn't considered.

Seamless Full-Stack Development

Working across React frontend and Flask backend, Kiro maintained context about our API structure, data models, and component relationships. This resulted in fewer bugs and more consistent patterns throughout the entire application.

Real-World Impact: The Numbers That Matter

The platform isn't just technically impressive – it's delivering real sustainability impact:

60-75% CO₂ reduction vs conventional materials
15-30% cost premium with 3-5 year payback through efficiency
720-1200 wash cycles durability range across material types
EU 2027 compliance ready with built-in regulation modeling

Deployment: Cloud-Native and Carbon-Neutral

We deployed on Google Cloud Run for automatic scaling and chose carbon-neutral hosting to align with our sustainability mission. The entire platform can be deployed with a single command:

# One-command deployment
./start_demo.sh

Docker containers ensure consistent environments from development to production, and our CI/CD pipeline automatically runs tests and deploys updates.

What's Next: Scaling Sustainable Impact

The MVP is just the beginning. Our roadmap includes:

Phase 2 (Months 2-6):

Blockchain traceability for supply chain transparency
Machine learning models for improved recommendations
Supplier portal for direct data integration
Mobile applications for on-the-go access

Phase 3 (Months 6-12):

Enterprise integrations (SAP, Oracle, Microsoft Dynamics)
Advanced analytics and trend prediction
International expansion with localised data
Marketplace features for supplier connections

Lessons Learned: Building for Impact

1. Data Quality Trumps Quantity

Rather than building a massive database of questionable quality, we focused on 10 materials with thoroughly researched, realistic data. Users trust the platform because the numbers are accurate and actionable.

2. User Experience Drives Adoption

Sustainability tools often feel like homework. We made ours feel like a premium consumer app. The glass morphism design, smooth animations, and intuitive navigation make complex data approachable.

3. AI Should Augment, Not Replace

Our AI doesn't make decisions for users – it provides ranked recommendations with clear reasoning. This fosters trust and enables users to learn about sustainable materials over time.

4. Performance Matters for Credibility

Enterprise users expect enterprise performance. Our <200ms API responses and smooth animations signal that this is a professional tool worthy of procurement decisions.

The Bigger Picture: Technology for Good

This project represents something bigger than just another web application. It's technology being used to accelerate the transition to a circular economy. Every brand that uses our platform to adopt recycled materials is reducing its environmental footprint and supporting sustainable suppliers.

The fashion industry is responsible for 10% of global carbon emissions. If our platform helps even a small percentage of brands make better material choices, the cumulative impact could be enormous.

Try It Yourself

The Sustainable Materials Platform is open source and ready to run:

git clone https://github.com/marvinoka4/sustainable-materials-platform
cd sustainable-materials-platform
./start_demo.sh

In 5 minutes, you'll have a production-ready sustainability platform running locally. The codebase is clean, well-documented, and ready for customisation.

Conclusion: Building the Future We Want

Working on the Sustainable Materials Platform reminded us why we became developers: to build technology that makes the world a better place. With Kiro as our development partner, we were able to focus on solving real problems rather than wrestling with boilerplate code.

The result is a platform that's not just technically excellent, but genuinely helpful for organisations trying to make more sustainable choices. It's proof that with the right tools and approach, developers can build solutions that matter.

Ready to build something that makes a difference? The Sustainable Materials Platform is just the beginning. What will you create next?

About the Platform:
The Sustainable Materials Platform is a production-ready web application that helps fashion brands discover, compare, and adopt sustainable materials through AI-driven insights, LCA benchmarking, and cost forecasting—built with React, Flask, and deployed on carbon-neutral cloud infrastructure.

Tech Stack: React 18, Tailwind CSS, Framer Motion, Flask, Google Cloud Run, Docker
Impact: 60-75% CO₂ reduction potential, EU 2027 compliance ready
Status: Production-ready MVP with comprehensive documentation

View the code on GitHub | Try the live demo

Building Youtangen: An AI-Driven Sustainable Material Platform with Kiro #kiro

Marvin Okafor — Thu, 04 Sep 2025 23:11:29 +0000

Introduction

At Youtangen, we’re on a mission to bridge the “valley of death” in sustainable material adoption, empowering mid-tier fashion brands to switch to eco-friendly materials like recycled cotton and polyester without economic or performance risks. For the Code with Kiro Hackathon, we developed a Minimum Viable Product (MVP) that provides AI-driven insights for designers and sourcing VPs, featuring a searchable material database and 1-10 year cost forecasting capabilities. Kiro’s AI-powered IDE transformed our development workflow, slashing prototyping time by 50% and enabling a scalable, carbon-neutral platform hosted on Google Cloud Run. Here’s how we harnessed Kiro to create a game-changer for sustainable fashion.

The Problem: Navigating the Sustainable Fashion Maze

The sustainable fashion market is booming (USD 8-12B in 2025, 23.2% CAGR), but brands face significant hurdles: fragmented supply chains, volatile pricing, and scepticism about material performance (e.g., durability, hand feel). Our customer discovery (15+ interviews with industry experts like Anderson and Shetty) revealed that mid-tier brands, such as Veronica Beard or Another Tomorrow, need tools to evaluate sustainable materials quickly and trust their economic viability. Existing platforms, such as Textile Exchange, offer standards, and SwatchOn provides sourcing, but none deliver predictive analytics to overcome adoption barriers. Youtangen fills this gap with AI-driven decision support.

Our Solution: Youtangen’s AI-Powered Platform

Youtangen is a web-based platform designed for mid-tier fashion brands, with two core features:

Material Database with AI Benchmarking: A searchable database of 10 materials (recycled cotton, polyester, and virgin baselines) with lifecycle analysis (LCA) comparisons (e.g., CO2, water usage) against user-uploaded specs (cost, durability). For example, it shows that recycled polyester reduces CO2 by 58% compared to virgin polyester, addressing performance scepticism (e.g., Kroner’s concerns about touch/feel).
Forward Cost Curve Forecasting: An AI tool predicting 1-10 year material costs, factoring in EU 2027 regulations (+15% cost impact) and supply volatility (±5%). This tackles economic barriers (e.g., Shetty’s pricing volatility) and projects 20-30% cost savings for brands.

Hosted on Google Cloud Run with 100% renewable energy, Youtangen aligns with our Carbon13 goal of reducing 10 megatonnes of CO2. The modern UI, styled with Tailwind CSS, offers intuitive search, benchmarking, and interactive cost charts, making it accessible for designers and sourcing VPs.

How Kiro Supercharged Our Development

Kiro’s AI-powered IDE was our co-founder in coding, streamlining every phase of development:

Inline Coding: Kiro generated 70% of our Flask API endpoints (e.g., /api/materials, /api/benchmark) and React components (MaterialDatabase.js, CostForecasting.js) directly within the IDE. For instance, it suggested optimised MongoDB queries for material searches, reducing coding time from days to hours.
Multi-Modal Chat: We used Kiro’s chat to brainstorm our database schema (10 materials with LCA data like CO2: 1.5-5.0 kg/kg) and refine our cost forecasting logic (e.g., incorporating EU 2027 impacts). Kiro proposed a numpy-based forecasting model to sidestep Python 3.13 compatibility issues with statsmodels, saving us days of debugging.
Agent Hooks: Kiro’s hooks automated critical tasks, such as seeding our MongoDB Atlas database with 10 materials (seed_data.py) and running API tests. The /.kiro/hooks.py file logs these automations, cutting 10+ hours of manual work.
Spec-Driven Development: We defined a /.kiro/spec.yml to outline our database schema and forecasting algorithm, which Kiro used to generate consistent code structures. This ensured our MVP was scalable and aligned with our vision.

Our public GitHub repository ([insert your repo URL here], MIT License) includes the /.kiro directory, showcasing Kiro’s specs, hooks, and steering logs, which demonstrate its integral role in our workflow.

Demo: Youtangen in Action

Search and Benchmark: Search for “Recycled Cotton Blend” and benchmark against user specs (e.g., cost: $3, durability: 7.8), displaying a 58% CO2 reduction.
Cost Forecasting: Generate a 5-year cost curve for recycled polyester, visualising savings with EU 2027 regulation impacts.
Sustainability Impact: Highlight potential for 1M tonnes of CO2 savings through widespread adoption.

Kiro’s inline coding and hooks enabled us to build this polished MVP in weeks, not months. The platform projects 50% user retention, 20% cost savings, and a 70% improvement in trust (as measured by surveys), making it a compelling tool for brands.

Technical Details

Tech Stack:
- Backend: Flask with numpy for forecasting, sympy for LCA calculations.
- Frontend: React with Recharts for interactive charts, styled with Tailwind CSS.
- Database: MongoDB Atlas (production) or in-memory for demo.
- Deployment: Google Cloud Run (carbon-neutral hosting).
Kiro Features Used:
- Inline coding for Flask/React generation.
- Multi-modal chat for schema and algorithm design.
- Agent hooks for database seeding and API testing.
- Spec-driven development via /.kiro/spec.yml.
Sustainability: Hosted on Google Cloud’s renewable energy, with plans for blockchain-based digital passports for traceability.

Next Steps

We’re beta testing with 10-20 mid-tier brands (e.g., via Anderson’s intros) to validate our metrics and refine the platform. Future enhancements include integrating real Higg API data, adding blockchain for digital passports, and developing a React Native mobile app. Kiro’s AI made this rapid prototyping possible, and we’re excited to scale Youtangen to transform the sustainable fashion industry.

Thanks to Kiro for empowering us to code smarter and faster. Check out our repo and join the #kiro revolution!

The "Ordinariness" of Tech

Marvin Okafor — Mon, 01 Sep 2025 22:49:13 +0000

Technology is undeniably captivating—a dynamic force that connects, streamlines, and enhances human potential. However, its brilliance is a double-edged sword, serving as both a blessing and a curse to itself and to those who wield it. Allow me to explore this duality.

A Blessing and a Curse

Technology is a blessing because of its transformative power. It has revolutionised industries, from healthcare to finance, by creating tools that improve efficiency and open new possibilities. However, this same prominence can be a curse. Tech often overestimates its importance, fostering the idea that it is the ultimate solution to all problems. This hubris can cause imbalances, where its role overshadows other vital sectors.
For its practitioners and beneficiaries—myself included—tech is a gateway to opportunity. As a software engineer and data scientist, I have seen firsthand how tech has broadened the scope of industries, creating vibrant spaces for innovation and growth. One of my favourite advantages is the ability to work remotely. Beyond avoiding daily commutes, it has allowed me to collaborate with fascinating businesses across states, countries, and continents. This global connectivity is a remarkable gift.
However, the problem is in external expectations. The hype around technology can create a fragile dependency. During the early “tech boom,” the prevailing sentiment was to “build an app for everything,” and startups thrived from this trend. Now, with the rise of AI, the scene has changed considerably. Non-AI-based tech innovations struggle to stay relevant, suggesting a correction that could have a profound impact on the industry. This does not mean tech is doomed—far from it—but the pendulum of progress sways both ways.

The Ordinariness of Tech

When I talk about the “ordinariness” of tech, I’m not downplaying its value. My career, built on designing tech systems, shows its strength. Instead, I’m encouraging a perspective—acknowledging that tech is just one part of a bigger picture. Every sector, from healthcare to agriculture, deals with a fundamental aspect of human life. Tech’s role is distinct in its visibility and flexibility, but it’s not the most important.
Consider healthcare: tech facilitates patient database management, appointment scheduling, and advanced research, making hospitals more efficient. Without these systems, healthcare would struggle to function effectively. But the reverse is equally true—without doctors, nurses, and medical expertise, tech’s tools would be useless. The same logic applies to agriculture. Farmers sustain life itself, and no app can replace their work. Tech is an enabler, not a necessity on par with food, health, or shelter.

A Call for Balance

My point is straightforward: technology is remarkable in its ability to enhance, but it is commonplace in other industries. It exists to serve, not to dominate. As someone who has prospered during the tech boom, I encourage us to recognise its contributions without exaggerating its importance. By acknowledging technology’s ordinariness, we cultivate a healthier ecosystem where all sectors—healthcare, agriculture, education, and beyond—collaborate harmoniously.
Tech’s brilliance lies in its ability to empower, not to overshadow. Let’s embrace its potential while honouring the equal importance of every field that sustains and enriches human life. In this balance, we envision a future where innovation serves humanity holistically, creating a world that thrives not solely because of technology, but because of the collective strength of all its components.