That was the wrong angle.

Today I ask the opposite. Why do we need an IDE, now that we have Claude Code?

What I actually built

A few months ago I started an experiment. One small VM per project. Each VM carries the exact environment that project needs: the runtime, the database, the credentials, the test data. Nothing shared.

On each VM, an agent. It gets a task, works in a branch, and opens a merge request when it is done. The pipeline takes over from there. SonarQube runs. The e2e suite runs. Coverage is checked.

Then my phone buzzes. A merge request is waiting for final validation. I read the diff, the pipeline report, the agent's summary. I approve or I send it back with a comment.

That is the whole loop. The phone is not a gimmick. It is the last step of the pipeline, and the only step that still needs me.

Why I started, and why I stayed

I started to offload work. R&D spikes, debugging sessions that eat an afternoon, the small tickets nobody wants. The goal was to free my hours, not to change how I program.

The turn came a few weeks in. I was reviewing a merge request on my phone, at a café, and I realised I had not opened my IDE in days. The project had moved every one of them. Nothing was blocked on me except approval.

I had not stopped working on the project. I had stopped typing in it.

The IDE was built for a job I no longer do

An IDE is a machine for writing code. Autocomplete, refactoring, go to definition, inline errors. Every feature exists to help a human produce text faster and with fewer mistakes.

But I don't produce the code anymore. I review it.

Review needs different tools. A clear diff. The pipeline verdict next to it. The reasoning the agent followed. A way to say "no, try again" in one sentence. My phone does all of that, anywhere. My IDE does most of it too, and only while I am sitting in front of it.

The terminal question was never the point. Claude Code did not move programming from the IDE to the terminal. It moved programming from writing to reviewing. The terminal was just where that shift happened to appear first.

What this changes for a team

The question I hear from engineers is the same one I asked at launch, in a different form. "If the agent writes the code, what do we do?"

We do the part that was always the hard part.

We decide what to build. We design the systems, the loops and the graphs. We define the environment the agent works in, and that environment is now the real codebase. We write the pipeline that decides what is acceptable. We read the diff and we say yes or no.

Those are senior skills. They are the skills of an architect and a reviewer, not a coder. The engineers who struggle in this model are not the juniors. They are the people who measured their value in lines written.

The downside

My screen time went up. Not the laptop. The phone.

The loop I built rewards checking. A merge request can land at any moment, and every buzz might be one. So I look. At lunch. In the car. At night, when nothing is waiting and I look anyway.

I traded hours at a desk for a habit in my pocket. That is not a clean win. The desk had edges. The phone has none.

The questions it opens

If review fits in a pocket, what is a workday? What does a team look like when nobody shares a screen, a room, or a schedule? Who is responsible for a line that no human typed?

And the one I keep coming back to. If the phone is where I say yes or no, how long before that step goes away too?

I don't have the answers. I have a pipeline that works and a phone that buzzes too often. That is enough to keep going, and not enough to go back.

What Joule Code is not

It is not here to replace Claude Code or Codex. If you want an interactive pair programmer for your daily work, those tools are excellent, and Joule already plugs into them through its MCP server.

Joule Code answers a different question: what happens when the task is longer than your session?

A DevOps agent that watches a deployment and reacts, not one that observes and reports. A worker that runs a migration overnight. A node in a workflow graph that gets an environment, a goal and the freedom to use both until the job is done. That is where Joule Code lives.

It also handles lightweight development. Small features, fixes, scripted changes. But the design center is long-running, unattended work.

What it connects to

Joule Code is a client of the Joule platform. Link it to a Joule server and it gets three things a standalone coding tool does not have:

• Knowledge attached to your agents.
• The work already in progress on the platform: tasks, workflows, conversations.
• Preconfigured agents you can hand a job to instead of describing it from scratch.

Models come from wherever you want. Go through your Joule server, or point Joule Code straight at Anthropic, OpenAI or whatever provider you already pay for, with your own keys. Attaching a server gives you the platform. It does not decide which model answers.

Run it alone and it is a coding agent. Run it attached and it is a hand on the platform.

Sessions that outlive the terminal

Joule Code runs its conversations behind a daemon. Quit the terminal and the session does not die. Configure an agent, give it the task, close the laptop. It keeps going.

Session state is owned by the daemon and bound to your account, not to the client that started it. Reconnect from the terminal or open the same conversation in the Console web; either way you attach to the same running session, with its full history and current state. Switching clients is not a resume. Nothing was interrupted.

Skills, plus Knowledge

Joule Code supports skills, the same way every coding tool does now. Skills stay. They are the right way to teach an agent a procedure.

What skills do not solve is context. The usual pattern is to ship a folder of markdown files into the repository and hope the agent reads the right one. It goes stale, it duplicates across repos, and it grows until nobody wants to maintain it.

Joule Code adds the Knowledge feature of the platform on top of skills. You move the heavy part of that context, architecture notes, domain rules, API references, past decisions, into Knowledge and keep the repository light. The agent runs RAG over the knowledge attached to its Joule server, so that context lives in one place, stays current, and is shared across every session and every project that needs it. Skills tell the agent how to do the work. Knowledge tells it what it is working with.

Checkpoints

A checkpoint is a saved state of a conversation. Start a new session from it and the agent already knows the project, the conventions and the decisions made so far. No re-reading the folder tree, no rebuilding context from markdown files.

There is a second benefit. Checkpoints make requests cacheable, so the same grounded context does not get paid for twice.

Session pools

Real work is several features at once, in several conversations, and one of them usually depends on another.

Sessions are independent by default. When they belong together, you group them into a pool: the same feature, a shared subsystem, a set of related tasks. Inside a pool, a session can sneak peek another one: its status, its tasks, where it stands. Enough to know whether the thing you depend on is done, without merging the two conversations or asking a human to relay.

The search engine

Joule Code has access to the search engine we run on Joule. When the task needs fresh data, a new API version, a changelog, a breaking change from last week, the agent goes and gets it. It does not have to guess from training data.

Interfaces

The daemon owns the session, so the interface is your choice. The TUI, the Console web, and a VS Code extension, now in preview, all attach to the same running session. Pick the one that fits the moment, or use several at once.

Built with Lumen

Joule Code is written in Lumen, our programming language. TypeScript syntax, native binary. The same language that runs the Joule backend and the workflow engine. One stack, one mental model, end to end.

Early adopters

We are looking for early adopters. There is a Telegram group where we discuss features, bugs and releases, and you are invited.

joule.sh/code

Ask. Search. Make.

Your developers pay for Claude Code themselves and ship with it. The tool you are still evaluating is already in production. It is just not on your invoice.

The tooling debate is over. What remains is an adoption gap, and it widens every quarter.

I have not written a line of code in 2026. My team ships to production every week. Not prototypes. Not demos. Customer-facing code, reviewed and deployed.

The companies pulling ahead did one thing differently. They put agentic workflows inside delivery, not inside a pilot. Startups got there first because they had no committee to ask. Everyone else has a choice: do the same, or watch the gap become a moat.

This is not the end of software engineering. It is the best the job has been in years. Engineers design, review, and decide. Agents type.

If most of your engineers are not building with agents today, you do not have a tooling problem. You have a leadership problem. Buying a license will not fix it.

Neither will an AI committee. You know the one. It writes the standard CLAUDE.md, picks the approved tools, hands out scripts, and schedules meetings to encourage adoption. That is top-down, and this does not work top-down. Find the engineer who ships the highest quality code with the least effort. Give them the mic. Let them show the team what they do, with no committee validation and no meetings in between.

By 2027 the teams running agent-native delivery will not be faster than you. They will be playing a different game. You will still be choosing a tool.

If you keep rebuilding the same thing, at some point it should become a product.

What Joule is

Joule is an AI platform and workspace for individuals and enterprises to build, maintain and deploy AI workflows and agents.

Each word in that sentence is deliberate.

Platform, because the components work together as one system, not as a bag of SDKs you have to glue yourself.

Workspace, because it is where you actually operate day to day, not a control panel you visit once a month.

Build, maintain and deploy, because most AI tools stop at the demo stage and leave the operational reality to you.

Workflows and agents together, because real systems need both: agents for judgment, workflows for structure.

The distinction matters. The market is full of chatbots with plugins on one side and low-level frameworks on the other. The chatbots cap what you can build. The frameworks hand you a box of parts and a wish of good luck. Joule sits in the space between: the pieces every serious AI system needs, already built, already integrated, already running in production.

The main components

Lumen Agents

The backend and the core of the platform. It orchestrates agents and manages all configuration around them. It is open source, part of the Lumen standard contrib packages: Lumen - std-contrib

The workflow engine

Written in Lumen as well, it serves as the backbone of every agent workflow. Every step an agent takes runs through it. One core, one mental model, one place to look when something breaks.

The search engine

It provides RAG context to the models. We index 1 million pages each day and growing, with a fallback strategy born from a cost problem that turned into a product of its own. We never planned to build it. It is now one of the strongest parts of the platform.

The frontend

It runs on our own full stack web framework and design system. Owning the UI layer end to end means the platform evolves at the speed we decide, not at the speed of a dependency's release cycle.

The MCP server

It lets you integrate Joule directly into coding agents like Claude Code and Codex, and deploy or manage workflows and agents from inside your coding session. Everything through natural language.

Tasks

Tasks let agents work without a human in the loop. A task runs on a schedule or on a trigger, executes its workflow, and delivers the result. You do not prompt it. You define it once, and it works while you do something else.

Document generation

It turns agent output into real deliverables. Not text in a chat window, but actual documents, produced through a self-correcting loop where the agent fixes its own failures. The reliability comes from the loop design, not from prompt engineering.

Knowledge

Knowledge gives every agent its own grounded context through a file sync model. Folders attach to agents, agents become specialists, and specialists compose as sub-agents inside the workflow graph.

Connectors

Connectors link Joule to Atlassian, Asana, Linear and other platforms where work already happens. The difference from every chat product: connectors in Joule are not only conversation features. They are tasks and nodes in the workflow itself.

Discover

A feed of fresh, synthesized content, in the spirit of Perplexity's feed. It is the direct fruit of combining two components we already had: our own search engine, which knows what is fresh and in demand, and our agents, which turn that signal into substance. Nobody planned it. The architecture produced it.

Live environments

Live environments give agents a real place to execute. You define an environment per project: runtime, dependencies, credentials and tools, and everything that runs in that project runs inside it. Agents stop working in the abstract and start working in your actual context.

Joule is live at joule.sh. Try it, break it, tell me what's missing.

Ask. Search. Make.

You can throw the device away, but then you downgrade yourself. You block access to things that actually work, and you make life harder for no real gain.

Some people carry sensors that talk to their phone. A CGM sensor on the arm, glucose numbers on the screen. Some live far from their family and the phone is the only line back. Going flip phone is going backward. That is not the answer.

None of that justifies how much we use it. None of it justifies the hooks.

Detox does not work either. You go clean for a week, then you come back and use it more than before. I ran all the tricks. Grayscale screen. App limits. Empty home screen. They buy you a few days.

What changed this time is simple. I am done.

Same feeling I had in 2019 when I quit social media. Not a plan, not a challenge, not a streak. A decision.

This year the decision was about how I use the phone, not whether I own one. I worked on it constantly because it was there. Accessible. Which meant I was in working mindset every waking hour. Work does not end when the laptop closes if the work fits in your pocket.

I have said this before. This time it feels different. The phone sits on my desk and I look at it with no appetite. Nothing pulls.

What made the difference is attention. Being conscious of where it goes, deliberately, all day. That is the best thing you can do for yourself. Focus on one task. Live it fully. Not half your mind on the work and the other half digesting what is happening on the screen in the background.

I still use blocking tools on the iPhone. They add friction. They do not lock me out. The lock has to come from me, otherwise I just find the way around it.

The other change is in how I handle ideas. I used to execute first and decide later. That built knowledge fast, and it built experience I still use. It also burned attention on things that did not deserve it.

Now I let an idea sit before I build it. Cognitive load is a real budget. With everything happening right now, you have to be selective about what you consume, and more selective about what you let occupy your head.

The battle continues. The difference is that I am no longer fighting the device. I am protecting my attention, and the phone is just one of the things trying to take it.

I love how Zig and Rust are fast and flexible. The control, the performance, the fact that what you ship is a real native binary. No runtime hiding behind it, no engine deciding things for you at 2am in production.

But every time I sat down to actually build something, I felt the tax.

More ceremony. More time fighting the compiler over things that had nothing to do with the problem I was solving. And a smaller pool of people who could read my code back to me.

Then I looked at the other side.

TypeScript's syntax is something most of the industry already speaks fluently. Interfaces, generics, async/await, arrow functions. Expressive without being exotic. Nobody needs a course to read it.

And that's when it clicked: the syntax was never the hard part of Rust or Zig. The runtime was.

TypeScript's problem was never how it looked. It was everything underneath it: a JS engine, a garbage collector, dynamic prototypes, and an npm install that pulls in a universe of transitive dependencies you never asked for.

So I started asking a different question.

This isn't the first time I've written a lexer, an AST, a type checker, a compiler. I've built that pipeline before. I know what it costs and I know what it takes. So this wasn't a leap into the unknown. It was pointing something I already knew how to build at a problem I'd actually felt.

What if you kept the syntax everyone already knows, and swapped out everything underneath it for something with Zig's discipline?

That's Lumen.

What it actually is

Lumen type-checks familiar TypeScript syntax, emits Zig, and compiles that straight to a small, dependency-free native binary. No VM. No garbage collector. No runtime.

You write this:

And you get a native executable. Not a bundle. Not a container with Node inside it. A binary.

Zig is the backend. Your TypeScript is type-checked, emitted as Zig, and compiled to a native binary from there.

The syntax you already know is all there: records and interfaces, generics, classes with extends and #private fields, template literals, try/catch/finally, async/await, map/filter/reduce. But it's a deliberate, static subset. No prototypes. No eval. No dynamic shapes that make the compiler guess.

The decisions that make it different

Generics are monomorphized. Write once over a type parameter, and each instantiation compiles to specialized code. No boxing, no runtime type juggling.

Closures compile. Capture your locals, and they get lowered to a heap environment, with no garbage collector waiting behind them.

Concurrency is real. Worker.run(fn) spawns an actual detached OS thread and hands you back a Promise. Genuine CPU parallelism, not a simulated one, because there's no per-thread interpreter overhead to pay in the first place.

It talks to C directly. Write a declare function, link a C library, and call it. No bindings generator, no FFI ceremony. Strings and scalars marshal across the boundary for you.

And because there's no interpreter in the middle, some of this ends up faster than the runtime it borrows its syntax from. Anchored regex patterns compile to specialized native matchers at build time, around 3× faster than V8 on checks like semver and identifiers. A typed EventEmitter runs about 3.5× faster than Node's on a tight emit loop.

The standard library lives in the open, in std-contrib. Take the markdown package. Rendering a typical 3 KB document in a tight loop, it does about 6,775 renders/sec, against 2,020 for markdown-it and 1,064 for marked. That's roughly 3.4× faster than markdown-it and 6.4× faster than marked on the same document. Same reason every time: it compiles the parser instead of interpreting one.

Standard library: github.com/lumen-lang-org/std-contrib

A package is just a URL

There's no package manager. No install step. No node_modules.

A simple module is just an import over HTTPS:

Lumen import with url

The .ts is fetched over HTTPS and inlined at compile time. A remote module can pull in its own siblings by relative path, fetched recursively, each URL fetched once per build. Only https:// is allowed, and remote code runs at build time. So you import from sources you trust, and you know exactly what went into your binary.

And it's not just source modules. You can pull in a C library the same way. The quickjs package embeds a full QuickJS sandbox through Lumen's FFI:

A C engine, embedded and running, imported from a URL. No build script, no bindings step, no package manager. That's the whole point.

What I'm deliberately not doing

I'm building out the standard library piece by piece: crypto, filesystem, networking, worker threads, all backed by real OS primitives, not polyfills.

But I'm being deliberate about what not to bring over from Node.js. I'm not chasing 100% API parity for its own sake.

Parity was never the goal. Discipline was.

std - lumen

The same source, native or in the browser

Lumen compiles to a native binary, or to WebAssembly, from the same source. The standard library is honest about the line between them: every function is marked for its target, so you know up front what runs everywhere and what's native-only. Pure computation, crypto, string and URL work, the event emitter, runs identically on both. The things that can't cross, raw syscalls, threads, direct filesystem access, are labeled, not silently broken.

This is also why the playground works the way it does. When you compile to WASM, a C dependency like the QuickJS engine gets linked straight into the compiled module. The whole program becomes one self-contained wasm file. So the QuickJS example above, a full JavaScript sandbox embedded through the FFI, runs in your browser with nothing installed. You're not looking at a simulation of the language. You're running the real compiler output.

The full standard library surface is at lumen-lang.org/stdlib.

The bet

The core bet is simple: remove the runtime tax without asking anyone to learn a new mental model.

You already know the syntax. You shouldn't have to trade it away to ship a real binary.

There's a playground. Write Lumen and watch it compile in the browser, no install:

https://lumen-lang.org/play

It's still early, and it's open. If that's a problem you've felt too, come look at the rest:

I'd love to hear what you think.

Code used to be the only thing we wrote, the only thing we reviewed, the only thing we shipped. Process and ceremony existed because code was expensive to produce and hard to change. That cost has dropped. A description of what we want can now generate working code in seconds, and we can iterate on the description faster than we used to iterate on the code itself.

So the loop has two artifacts now. The description, and the code generated from it. Both have to be right. Neither one replaces the other.

Which forces two questions to the surface. Is what the agent produced actually a reply to what we asked? And is the input we gave it clean enough to be worth replying to?

The first question I will cover in another article. This one is about the second. The spec.

Spec-driven is not vibe coding

The opposite of spec-driven is not test-driven. It is vibe coding. Describe the goal, get a block of code back, hope it is what you meant. Fast, fun, and unreliable the moment the system has more than one moving part.

Spec-driven changes the order. You write the description first. The agent generates code from it. You review the code, you test it, you ship it. Both artifacts are real, both have to be right. The spec is what you start from. The code is what runs.

What changes is the relationship between them. The spec is the source the code is generated from, and the place fixes start. The code is still the thing that runs in production, and it still earns the same review and the same tests as anything you wrote by hand. Neither one carries the system alone.

The canonical workflow

Two tools have made spec-driven a real workflow rather than a philosophy.

Spec Kit, from GitHub, formalized the approach. It splits the description into four artifacts: a constitution for non-negotiable principles the agent must respect across every feature, a spec for the what, a plan for the how, and a tasks breakdown for execution. The flow runs /constitution → /specify → /plan → /tasks → /implement, with clear phase gates. Thorough, opinionated, greenfield-friendly. The cost is weight. A Spec Kit change can generate eight hundred lines of markdown before any code is written.

OpenSpec, from Fission AI, is the lighter cousin. TypeScript instead of Python, npm install instead of toolchain setup, no rigid phase gates. Its distinctive idea is the delta spec. Instead of rewriting the whole description on every change, you describe what is being added, modified, or removed, and the deltas merge into the main specs after the change ships. Specs live alongside the code in the repository, which makes it brownfield-friendly in a way Spec Kit is not. Same change, around two hundred and fifty lines.

The two tools are not competing philosophies. They are different points on the same curve. Spec Kit treats specification as a first-class engineering phase with its own ceremony. OpenSpec treats it as a lightweight layer that sits next to the code and evolves with it. Same source-of-truth idea, different appetite for process.

Both are designed for the same shape of problem: one project, one codebase, one target. The spec exists so the agent does not drift, so requirements survive past the chat session, so the team aligns before code is written. That is the canonical use case.

Where we pushed it further

The methodology has a principle inside it that is bigger than the tooling. The spec is the source of truth. The code is regenerated output. Fix the spec, not the code.

Once you internalize that principle, a question follows. If the code is regenerated output, why does there have to be only one of it?

We were writing a native mobile application. Android and iOS, sharing one project. For some features iOS owned its own behavior. Fine at first, the diff stayed small. Then it grew. Each platform needed its own visual identity, its own feel. The "shared project with platform branches" model started to bend.

The standard alternatives were the usual ones. Own three codebases and pay the synchronization cost forever. Or pick a cross-platform framework (Flutter, React Native, Kotlin Multiplatform) and accept the shared runtime, the shared idioms, the not-quite-native feel.

We tried a third path. One description. Multiple targets. Same source of truth, regenerated as native code for each platform. The agent writes idiomatic code for each one because it is generating, not transpiling. The spec never runs. There is no shared runtime. The cost is a regeneration step instead of a compile step, and the discipline of keeping the description honest across all three.

This is not what Spec Kit or OpenSpec ship out of the box. Neither tool advertises multi-target generation as a feature. We took the principle they encode (intent as source, code as output) and pushed it past the canonical workflow. The tools gave us the discipline. The discipline gave us the architecture.

We applied it to Android, iOS, and eventually web. Same description, three outputs. The agent is the compiler. That arrangement was not realistic three years ago. It is now.

Where we landed on the artifacts

We did not start with Spec Kit or OpenSpec. We started with one file and let it grow. As the project grew, the file split itself almost naturally. Principles drifted into their own document, the architectural how drifted into another, feature behavior stayed in the middle, change-by-change deltas appeared on their own. By the time we read the docs of both tools, we recognized most of what was already on disk. The shape is convergent because the pressures are real.

The rest of this article uses "spec" loosely. It means the full description, across whatever files it ended up in.

What goes in the spec

The first instinct is to put everything in. Resist it.

A spec is not documentation. Documentation describes what exists for a human reader. A spec describes what should exist for an agent that will build it. Different audience, different rules.

What goes in:

• Behavior. What the feature does, in plain language. Not what it looks like, not how it is implemented. What it does, when, in response to what.

• Abstractions and data shapes. The objects the feature works with, the contracts between them, the invariants the agent must respect. This is the part the agent leans on hardest.

• Algorithm snippets. Small, high-density pieces of logic the agent should not reinvent. Sorting rules, eligibility checks, pricing formulas. If it has subtle correctness requirements, it belongs in the spec.

• Platform-divergent behavior. When iOS and Android genuinely diverge in what the feature does, name it once and explain why. Not a list of differences. A rule the agent can apply.

What stays out:

• UI pixels. Spacing, colors, exact paddings. That belongs in a design system the agent reads separately. Mixing them turns every spec change into a visual review.

• Prose explanation of why decisions were made. Useful for humans, noise for agents. Keep it in a sibling doc if you need it.

• Platform-idiomatic UI and gestures. Navigation patterns, gesture handling, animation curves, lifecycle quirks. These live in per-platform layers the agent reads alongside the spec. The spec owns behavior and contracts. The platform layer owns feel.

The test I use: would removing this line make the agent's output worse? If yes, keep it. If no, it does not belong.

What broke first

Drift between platforms. A prompt-driven change to one platform's code does not automatically update the spec, and does not automatically propagate. You patch iOS, the spec is now a lie, Android falls behind, the next web regeneration is wrong. The rule we landed on: a change starts in the spec, the spec updates first, then the agent regenerates each platform from the new source. The regenerated code goes through the same review and tests as anything else.

That sounds obvious until you watch yourself break it. The agent will happily edit the generated code in place if you ask. Sometimes that is the right move for a one-off fix. But if the change has any chance of being relevant to the other platforms, it has to start at the spec, or the divergence is back. Discipline has to be wired into the prompt and the workflow. It is not the default.

Context window pressure. As the spec grew, the agent started going back and forth before committing to a solution. Propose, second-guess, re-read, propose again. Useful in small doses, expensive when the spec is large and most of it is irrelevant to the task at hand.

We started scoping which parts of the spec load for which task. Keep the relevant section dense, keep the rest out of the way. Code generation went back to working like before. Sometimes better, because the agent was not drowning in spec it did not need.

What actually changes

You now have two artifacts to keep right instead of one. The spec, and the code generated from it.

Reviews split along that line. You review the spec for intent. Does it describe the system you want, in a way an agent can build from. You review the generated code for correctness. Does it do what the spec says, does it run, does it pass the tests. Both reviews matter. Skipping the code review because the spec is good is how regressions ship. Skipping the spec review because the code looks fine is how the next regeneration silently breaks something.

You stop owning three implementations of the same feature and start owning one description of it. You stop arguing about which platform got it right and start arguing about what right means, once, in the spec. The code still has to be read. It just gets read against the spec instead of against itself.

When something is wrong, you check both. If the spec is wrong, you fix it there and regenerate. If the spec is right and the code drifted, you regenerate. If the spec is right and the code is right but the behavior is wrong, the spec was incomplete. Fix the spec, regenerate. The fix almost always lands in the spec, but the code is what tells you it landed.

If you are running a spec-driven loop and have hit different walls than these, I want to hear about it.

• Loaders
• Subscribe
• Socket
• llms.txt

Every component on a page costs JavaScript. Most of the time that cost is invisible. But on content-heavy pages (blog posts, dashboards, feeds), it adds up. You end up shipping and executing code for components the user may never scroll to.

Lazy hydration solves that.

Lazy Hydration

Wrap any component in and its JavaScript module is code-split out of the page bundle. As long as nothing else imports the module statically, the bundler ships it in its own chunk. Instead of arriving with the page, you choose when it loads: on page load, on scroll, when the browser is idle, or when a media query matches.

Everything outside hydrates normally. SSR is unchanged, with one caveat: for the component inside the island to render server-side, its module still has to be in the page's import graph (through a page or layout import). The import attribute on is a client-side URL only. What the island defers is when the JavaScript arrives on the client.

Hydration strategies

Four strategies, each with a clear purpose.

client:load - loads immediately on page load. Use it for interactive content visible on first paint.

client:visible - defers loading until the component scrolls into the viewport. A comments block, a reactions widget, a heavy chart none of them need JavaScript until the user actually reaches them.

client:idle - loads when the browser is idle. Good for low-priority components that should hydrate soon but are not critical for first interaction.

client:media - loads only when a CSS media query matches. Perfect for components whose JavaScript is only useful at certain screen sizes, a desktop sidebar, a mobile-only drawer.

How it works

When the chosen strategy triggers, the module is dynamically imported and the custom element registers itself. From that point on, the component behaves like any other element on the page.

No config flag. No setup. The runtime is included on every page and only activates when elements are present. Observers and listeners are one-shot. They release themselves after hydration fires.

Escape hatches

A few details matter once you start using islands in real pages.

data-hydrated lands on the element once the module loads. Useful for E2E tests waiting on hydration, for CSS that should only apply after the component is live, and for debugging which islands have fired.

island-hydrated is a bubbling, composed event dispatched at the same moment. Listen for it on any ancestor when you need to chain behavior: preload an analytics module, kick off a second island, mark a region as ready.

window.__nk_islands is a registry the runtime checks before doing a dynamic import. If a host has populated it with a loader for the import path, the island uses that loader. Otherwise the runtime falls back to import(path). This gives a project an escape hatch to wire islands into its bundle graph instead of relying on raw URL imports.

In practice

A content-heavy page where the reactions widget only loads when the user scrolls to it:

The page renders fully on the server. The article content hydrates immediately. The reactions widget waits. First paint is fast, interaction cost is deferred.

Composing with component loaders

LumenJS lets any Lit component, not just a page, export its own loader(). The data is fetched server-side, stripped from the client bundle, and inlined into the SSR'd HTML. The component owns its data dependency.

Pair that with an island and the two principles compose on a single component. The component loader runs on the server and produces the reactions count. The widget is rendered into HTML with that data and shipped. No client JavaScript. When the user reaches the widget, the island imports its module, the element registers, and the component takes over the SSR'd region, now interactive.

Server work runs only for pages that include the widget. Client JavaScript runs only for users who scroll to it. Each layer defers what it controls. The page composes them.

Conclusion

Lazy hydration in LumenJS is one custom element, , that defers a dynamic import() until a trigger fires: page load, viewport intersection, browser idle, or media query match. The server-rendered DOM stays visible in the meantime. The component module replaces it when it arrives.

The cost is not free. Each island adds a custom element to the DOM and, depending on the strategy, an observer or listener until the trigger fires. For above-the-fold critical UI, plain hydration is faster: the JS would have shipped anyway, and the extra element is overhead. The win shows up below the fold, on long pages, where most of the component tree is JavaScript the user may never reach.

Lazy hydration is not a default. It is a tool you reach for when a component does not need its JavaScript on first paint. Used in the right places, the page becomes lighter without the user noticing anything changed.

• Loaders
• Subscribe
• Socket

We build LumenJS to be agent-ready. Not as a feature - as a principle. One small example of that is how we handle /llms.txt.

llms.txt

Every LumenJS project automatically serves a /llms.txt endpoint. No config. No setup. An AI tool hitting that URL gets a plain text map of your entire application pages, routes, data, features.

The idea comes from the llmstxt.org convention. We just made it automatic.

When a request hits /llms.txt, LumenJS scans every page and API route in your project, calls their loaders, expands dynamic routes by discovering all entries, and renders everything as readable plain text.

Why it matters

An agent working on your codebase does not need to read every file to understand what the application does. It reads /llms.txt and gets the full picture in seconds - routes, data shapes, active features.

This is the same reason we built loaders the way we did. Colocation. Every unit tells the full story of what it contains. /llms.txt is that principle applied at the application level.

Dynamic routes

For routes like /blog/:slug, LumenJS does not just list them. It calls the parent loader to discover all entries, then calls each dynamic page's loader to render the full content. The result is a real map of your data, not just your code structure.

If the database is empty or a loader fails, the route falls back to - Dynamic route. No crash, no incomplete output.

Routes that export auth = true are excluded. The expansion mechanism detects the auth flag and skips them private data stays private, even in a public endpoint.

Override

If you need a hand-crafted version, place a file at public/llms.txt. LumenJS detects it and serves it as-is, skipping auto-generation entirely.

Conclusion

/llms.txt is a small feature with a clear purpose. It makes your application readable to the tools that will work on it agents, assistants, pipelines. Zero configuration because it should not require any. The framework knows your routes, your loaders, your data. It does the work.

Agent-ready is not a mode you turn on. It is how the framework is built.

To ship production, that's not enough.

Vendors will sell you anything. They'll tell you they put agents in their pipeline and ship production code. Not true yet. I'm working across multiple projects, from products and tooling used inside big tech companies to startup R&D. I invest heavily in coding agents and live coding. Here's what I've learned so far.

Code is cheap. That doesn't mean you should buy it.

A beautifully generated piece of code is compelling. Watching it build, run, ship on the first try feels great.

Then ask yourself: from that moment, what's the drift from version one? 50%? 60%? I'd say 80%.

Why? Because the first version is never mature. And now you're in the rewrite loop.

Even with a clean instruction.md or claude.md, you still get code duplication. You still get drift. You still get the "yes, you're right…" message. And you start losing track of what state your code is actually in.

Say you land on a good version. You wrote unit tests. You feel solid. Then you read through the full thing and decide it could be more maintainable. Even if you asked for maintainable code from the start. Another rewrite. Update the tests. Run QA again.

You're in a cycle. You're not shipping.

The code is cheap. The rewrite is cheap too. Nothing feels stable anymore.

What you gain, what you lose

You do learn. New patterns. New ways of doing things. That's real.

But that's not the point. The point is to ship a working, maintainable application.

I lived this on one of my own projects. The agent generated a working module on the first pass. I ran it. It built. It passed tests. Then I read it and saw three places where the same logic was reimplemented with different names. I asked for a refactor. The refactor introduced a new pattern that conflicted with how the rest of the codebase handled errors. Another pass. By the time the module looked clean, the test suite needed a rewrite to match the new shape.

Net progress: zero features shipped. Net learning: a lot. Net feeling: busy.

Right now everyone feels busy and building. A small portion is shipping real production. Incremental shipping has never been easier, and yet the loop is so compelling it pulls you away from shipping.

When the loop works

It would be dishonest to stop here. The loop does work. I've seen it.

On my own agentic coding pipeline, I built two workflows that handle GitHub issues end to end. One for immediate bug fixes. One for plan-first feature work. Both run with quality gates, Docker testing, and notifications back to me. The agent does the heavy lifting. I review and merge.

The reason it works isn't the agent. It's the surrounding infrastructure. The pipeline has clear contracts. The quality gates are non-negotiable. The agent operates inside a frame I designed before I let it touch anything.

Same story with LumenJS, the framework I open-sourced this year. Web components on web standards, file-based routing, server boundaries the framework physically enforces. Half the reasons I built it that way exist because an agent is the primary developer. Less room to go wrong. The framework is the structured surface. The agent is the worker. The structure came first.

That's the pattern. The agent isn't the system. The agent works inside one.

So how do you survive

You stick with a stack you actually know. The moment you let the agent pick everything, you lose ownership. You also lose the ability to debug it when it breaks.

You resist the buzz from the magic generation. That feeling is a fake sense of accomplishment. Too good to be true. 99% of the time, the real work is still ahead of you. The build passing is not the finish line. It's barely the start.

You invest in infrastructure more than before. Start with a solid layer: architecture, must-use and must-not-use patterns, data flow, component responsibilities, testing infrastructure, CI. Everything from day one. That's what lets you plug in a coding agent and actually get value out of it. Small, validated, incremental steps. You leverage the agent and you keep ownership and control.

This is the part most teams skip. They want the agent first and the structure later. It doesn't work in that order. The structure is what makes the agent useful.

You still need to learn how to code, more than before. You still need to try patterns and learn their tradeoffs. You still need to master the agent's tools and make them work for you. The skill ceiling went up, not down. The agent makes the floor higher and the ceiling further away at the same time.

And you still own the agent's output. If you ship code you don't understand and it breaks, that's on you. Not the agent. Not the vendor. You.

What this means for engineering leaders

If you run a team and you're being pitched on agent-driven development as a productivity multiplier, ask one question: what's the infrastructure my team needs in place before the agent makes us faster?

If the answer is "none, just turn it on," walk away.

The teams getting real leverage from coding agents right now are not the teams with the most agents. They're the teams with the cleanest contracts, the strictest quality gates, and the engineers who still read every diff before it merges.

Code is cheap. Judgment is not. Infrastructure is not. Ownership is not.

• Loaders
• Subscribe

subscribe() solved one direction. Server pushes, client listens. But some features need both sides talking. Chat, collaborative editing, presence, games. For that we added socket().

Socket

Same pattern, different primitive. Each page can export a socket() function. It runs on the server, sets up event listeners, and gives you a two-way channel — the client can send, the server can respond or broadcast.

The server listens with on(). It pushes back with push(). It broadcasts to a room with room.broadcast(). The cleanup function runs when the client disconnects.

On the component side, the framework injects an emit() method automatically, no wiring, no import.

That's the full loop. Client emits, server receives, server broadcasts, components update.

Rooms

Rooms are first-class. Join on connect, leave on disconnect, broadcast to everyone or everyone except the sender.

broadcast() excludes the sender. broadcastAll() includes everyone. Pick what fits.

When to use subscribe vs socket

The decision is simple. If the data only flows one way, server to client, use subscribe(). It uses native SSE, zero dependencies. If the client needs to send events too, use socket(). It uses Socket.IO, installed separately with lumenjs add socketio.

No overhead either way. Socket.IO client is only loaded on pages that export a socket() function.

When socket grows

Same rule as loaders and subscribe. Move the handler out to _socket.ts in the page folder. LumenJS picks it up automatically.

Conclusion

Three primitives. loader() for initial data. subscribe() for server push. socket() for bidirectional communication. Each one follows the same convention, a named export, collocated with the component, stripped from the client bundle.

The tradeoff here is infrastructure. Socket.IO needs a stateful server with sticky sessions. Traditional serverless functions don't fit. Plan for it before you reach for it.

We faced these exact problems. Here's how we overcame them using coding agents.

Humans are mission-driven. So are our agents.

At work, at home, in life we each operate around a set of missions. We applied the same model to our agents. We built an agentic team around our tools and gave each agent a defined set of missions to carry out over time.

Our job as humans doesn't disappear it shifts. We create missions, specify timing and frequency, and let agents execute. Then we observe for drift, update missions that are complete, and retire ones that no longer fit the current state of the project.

Start small. Start safe.

We began by identifying mission types with low risk and clear scope: daily improvements, security checks, bug detection. The kind of work a single agent can handle with little chance of going off course.

The code flow: GitHub as source of truth

Here's the pipeline we use to develop and maintain both LumenJS and the Nuraly platform.

1. Issue creation A mission scans the codebase and creates a ticket for a specific task. If a similar ticket already exists, the agent skips it.

2. Implementation Another mission picks up the ticket, creates a branch, implements the fix or feature, opens a PR, and iterates until checks pass build, tests, and SonarQube pipelines. If something breaks, a separate agent takes over to fix it.

3. PR review On our SaaS, we maintain a next branch before anything goes live. A review agent inspects each PR: if the changes are small and obvious, it merges to next. Otherwise, it leaves a comment requesting improvements. The cycle stays open another agent picks up the PR, evaluates the feedback, and either pushes back (if the change isn't worth it) or implements what's requested. To avoid burning tokens, we cap the number of retry attempts.

4. Human validation Once the PR is green, a human steps in to validate what the agent has done before anything ships.

Missions are scoped by project.

Each project has its own set of missions. What we've found: small, incremental changes over time give us more control and visibility than large codebases nobody has the bandwidth to manage.

The human role doesn't disappear, it shifts.

This is the part people often misunderstand about agentic systems. Agents don't replace human judgment. They replace human execution of repetitive, well-defined tasks.

Here's how the responsibility actually divides:

• Humans define the mission its scope, timing, retry limits, and success criteria. Humans observe for drift and decide when a mission is stale or needs updating. Humans do the final validation before anything ships.

• Agents execute they create tickets, open branches, push code, iterate through fix loops, and auto-merge small obvious changes. They work continuously, within the boundaries they've been given.

The key insight: as long as missions stay small and well-scoped, agents stay predictable. The human overhead doesn't scale with the number of agents it scales with the number of missions you define, which is a much smaller number.

The shift is worth it.

We didn't need more developers or more sprints. We needed a different model small missions, running continuously, with humans staying in the loop at the right moments.

What surprised us most wasn't what the agents could do. It was the clarity the mission model forced on us. When you define work precisely enough for an agent to execute it, vague tickets stop being acceptable.

Small changes compound. Drift is the real risk. And the loop never fully closes without a human that's not a limitation, it's the point.

Subscribe

The same colocation principle behind loaders applies here. Each page can export a subscribe() function. It runs on the server, stays alive for the entire duration the user is on the page, and pushes data to the client over SSE, Server-Sent Events, native to the browser, zero dependencies.

The function starts when the user lands on the page. Every call to push() delivers data to the client. Each key in the pushed object becomes a reactive property on the component - same pattern as loader(). The function ends when the user navigates away.

Cleanup

subscribe() is not a one-shot handler. It is a persistent process. Which means you are responsible for what you start. Always return a cleanup function — it runs when the client disconnects.

No cleanup means leaked connections and dangling intervals. The framework gives you the hook - use it.

Loader and subscribe together

They are designed to work on the same page. loader() handles the initial data. subscribe() handles what changes after. The component declares the properties once and receives data from both sources.

Page loads with real data. Updates arrive as they happen. No client-side fetching logic, no state management, no polling.

When subscribe grows

Same rule as loaders. When the handler gets complex, move it out. Place a _subscribe.ts file in the page folder and LumenJS picks it up automatically.

The page stays focused on rendering. The server logic lives where it belongs.

Conclusion

Subscribe extends the loader idea into the time dimension. Loaders answer the question: what does this page need to render? Subscribe answers: what does this page need to stay current?

Both follow the same principle server logic collocated with the component that needs it, stripped from the client bundle, with no wiring required.

The tradeoff is the same too. A subscribe handler is a persistent server process. Every active user keeps it alive. For pages with heavy watchers or expensive streams, that cost adds up. Design for it.

Loaders

Grouping related logic into a single unit is one of the best architectural decisions you can make. It helps with maintenance, onboarding whether that's a human or an agent.

For the web, we have components. Angular, React, Vue, and also Web Components the native browser primitive. What we did is take Web Components, enhance them with server-side logic, and add loaders.

Each page can export a loader(). It runs on the server, on every request, and the returned properties are injected into the component. It's a layer on top not a rewrite. The component keeps working exactly as before, with either injected properties from the parent or data loaded from the server.

Each key in the return object becomes a reactive property on the component. No wiring. No boilerplate.

When loaders grow

When everything lives in one file, it grows fast. For pages with complex server logic, this becomes unmaintainable. Two options:

Split logic into service functions inside the same file. Or move the loader out entirely place a _loader.ts file in the page folder and LumenJS picks it up automatically. No import, no wrapper.

The page file stays clean. The loader lives where it belongs.

The same idea, at component scale

Page loaders solve the data-fetching problem at the route level. But the same pattern works for any component in your project.

A sidebar needs user preferences. A dashboard widget needs its own slice of data. Each of these can export a loader() same syntax, same server-side guarantees, automatically stripped from the client bundle. No mixin, no wiring.

Where it gets interesting is with lazy components. A heavy comments section think Disqus-style, loaded only when the user scrolls down can own its backend logic too. The loader runs when the component enters the viewport, not on page load. The database query, the auth check, the pagination all of it stays collocated inside the component and executes only when needed. You save execution time and keep the first paint fast.

Conclusion

The boundary between "page data" and "component data" disappears. Every unit owns its server logic collocated, self-contained, deferred until needed.

Co-location at every scale: page, component, viewport. The tradeoff is real though you give up the familiar separation of frontend and backend files. And loaders can be misused. A component with a loader rendered inside a map triggers one server call per instance. N+1.

The rule is simple: loaders are for components that own their data independently. If the data belongs to the list, load it in the page loader and pass it down.

When used in the right place, the tradeoff is worth it.

Loader examples : https://github.com/Nuralyio/lumenjs/tree/main/examples/loaders

Documentation: https://lumenjs.dev

That distinction matters more than it sounds.

LumenJS is a full-stack web component framework and platform built with TypeScript. File-based routing, server loaders, SSR, authentication, real-time communication, database, storage - everything you need to build a production application, in one coherent system built on web standards.

We Didn't Guess. We Observed.

We paid close attention to how coding agents actually behave in practice - what they struggle with, where they drift, what structures they naturally produce correct output in.

That feedback is embedded in every design decision LumenJS makes. When a pattern caused agents to go wrong, we changed the framework. When agents reliably produced clean output in a certain structure, we made that structure the default.

We've Done This Before

Back in 2019 before LLMs, before any of this we built SustainJS. Same instinct: something about how web apps were being structured felt wrong, so we built what we thought was right.

Then the LLM era arrived. While building Nuraly, we went through framework after framework React, Astro, separate frontend and backend projects. Each one had the same problem: designed for humans writing deliberately, not agents generating at speed.

So we concluded, for the second time, that we had to build our own. Except this time, we had coding agents to help us build it.

Native Technologies. By Conviction.

We've said this before: we build on native and near-native technologies because they last.

We chose Lit Element as the renderer for NuralyUI. Now LumenJS takes web components to the next level a full-stack platform where routing, server data, and real-time subscriptions are all built around the same browser standard.

No deprecation dates. No migration guides waiting to be written. Just the platform.

pages/dashboard.ts auth, data, and real-time in one file

A Platform, Not Just a Framework

LumenJS ships with production-ready modules built in. Authentication with 2FA. A full communication stack with chat, conversations, and WebRTC calls. Not integrations to wire up. Not tutorials to follow. They are there, they work, you use them.

The difference between a framework and a platform is whether you spend the first week building infrastructure or building your product.

Proof of Concept? We Call It Production.

We are rewriting Nuraly on top of LumenJS. Not a demo. Not a side project. The full platform - calls, shared workflows, collaborative session building, live execution. Everything we needed it to handle, it handles.

When something breaks, we fix it. That is the only kind of reliability test that matters.

The Visual Editor

We started with a low-code studio. Low-code has a ceiling.

So we pivoted to an augmented code visual editor a visual layer on top of real code, not a replacement for it. LLM coding agents work alongside it, accelerating the writing while the editor makes output legible.

Same philosophy as LumenJS: don't hide the code. Structure it better.

Click any element on the page. A properties panel shows its attributes, styles, and matching CSS rules from the component source. Edit a value and it writes directly to the TypeScript source through the AST - not the DOM, the actual file.

The AI is part of the editor. Select an element, open the chat, describe what you want. It reads the source, applies the change, and you can roll back if it gets it wrong. Claude Code and OpenCode are both supported.

Nothing from the editor ships to production

Lumenjs editor mode

What Ships With It

• File-based routing, SSR, server loaders, API routes

• Real-time subscriptions over SSE and Socket.IO

• Authentication with OIDC, native email/password, and TOTP 2FA

• Full communication module: chat, conversations, WebRTC calls, end-to-end encryption

• Email with built-in templates and multiple provider support

• File storage with local and S3 adapters

• Database layer that works identically on SQLite and PostgreSQL

• Permissions, i18n, SEO, rate limiting middleware

This is not a list of planned features. It is what exists today.

The APIs are not stable yet. We are moving fast and things will change. We expect to reach v1 by Q4. Build on it with that in mind.

Conclusion

We are excited to launch LumenJS - not only because it represents how we practice augmented code, but because we have a team of coding agents as maintainers keeping the project alive, secure, and stable.

This is not a side project waiting for attention. It is a living framework, maintained the same way it was built.

https://lumenjs.dev

https://github.com/nuralyio/lumenjs

https://nuraly.io

The Demo Trap

Most agent projects start the same way. A simple UI. A simple API interface with an LLM. It works beautifully in the demo.

Then comes the real use case.

Suddenly, the team expects great results from the same setup they prototyped in a weekend. They start gluing UI to API, connecting endpoints, building wrappers, and wondering why the results are mediocre at best.

Here's the problem: there's not much value in that layer. The chatbot interface, the API wrapper, the prompt template: these are commodity components now. Everyone has them. They're table stakes, not differentiators.

Before you touch any of that, you need to deeply understand how to interface with the LLM, what components relate to it, and how they all connect with each other.

When you do that, when you truly understand the system, something shifts. You stop treating the LLM like a piece of code and start thinking about it as a system. You stop solving technical problems and start solving real ones.

Agents Are Simple in Tech, Brutal in Operations

The building blocks of an agent are simple. An LLM, tool calling, a feedback loop: the concepts are well-documented and the primitives are accessible.

But the system behavior is not. Tool calling is not reliable tool execution. A feedback loop is not correct state handling. Multi-step agents break in subtle, hard-to-reproduce ways. Here's the framing that makes it click for anyone who's run production infrastructure: agents are distributed systems with nondeterministic planners. If you've ever dealt with eventual consistency, partial failures, or observability gaps in microservices, multiply that by a component that makes different decisions every time you run it.

Building agents encompasses many technical and non-technical areas that most demos conveniently skip. Before your agent can do anything meaningful in production, you need to consider:

Access management. Who can the agent act on behalf of? What permissions does it inherit? If your client has a cloud environment, how do you connect to it securely?

Data governance. What data can the agent access? What can it store? What are the compliance requirements? This gets especially complex with European clients under GDPR.

Security. An agent that can take actions is an agent that can take wrong actions. An agent with cloud credentials that rotates a resource instead of tagging it can take down a staging environment. An agent with database access that misinterprets "clean up old records" can wipe production data. The attack surface is fundamentally different from a read-only chatbot, and the blast radius is real.

Monitoring. How do you know what your agent is doing? An agent that silently retries a failed API call 40 times before your alerting catches it is not a hypothetical; it's a Tuesday. How do you catch failures before your client does? How do you audit decisions the agent made autonomously?

Infrastructure. Local or remote providers? Self-hosted or cloud? How do you handle latency, failover, and scaling for long-running agent tasks?

User experience. How do you surface what the agent is doing in a way that builds trust rather than anxiety? How do you handle the cases where the agent needs to ask for clarification?

Integration. The agent doesn't live in a vacuum. It needs to connect to existing systems, APIs, databases, and workflows that were never designed for autonomous actors.

You need all of these pieces in place before you can design and distribute a working agent. Not after. Before. That's what makes this an operations problem, not a technology problem.

The Delegation Problem

Are the clients, are we as developers, actually ready for delegation?

We used to do everything ourselves. As developers, it's not easy to delegate code writing. We built our careers on it. We had fun doing it. We got deep satisfaction from shipping something we wrote with our own hands.

Then you start delegating to AI. And the results are mixed.

Sometimes the model isn't good enough for the task. Sometimes your prompting isn't precise enough. Sometimes both. And when you hit those walls, something interesting happens.

You start shifting your focus. From writing to planning. From coding to architecture. From execution to design.

You start a new kind of race: you think more and type less.

This is the real transformation that agents bring. Not replacing developers, but changing what it means to be one. The role evolves from writing code to orchestrating systems, from executing tasks to leading missions.

The Generation Trap

We now know that almost any piece of software can be generated relatively easily. AI can write code, scaffold applications, generate entire features from a description. This creates an enormous, and misleading, promise around delivery.

"If code can be generated in minutes, surely delivery is easy now."

It's not. And believing this is a trap.

Because it was never about writing code. It was always about understanding what the client actually means. Then executing on that understanding. Then iterating based on what you learn.

It's about infrastructure. It's about security. It's about integration. It's about all the things that code generation doesn't touch.

We absolutely need expertise. More than ever, in fact. But the expertise we need is not for executing tasks. It's for planning, reviewing, managing, and leading.

Not to type. To think.

Not to execute. To lead the mission.

Stop Chasing Frameworks

The market is crowded. Every week brings a new framework, a new wrapper, a new "agent builder" that promises to make everything easy.

None of them solve the actual problems.

Frameworks don't solve trust. Frameworks don't solve accountability. Frameworks don't solve blast radius. They solve wiring, and wiring was never the hard part.

The teams that will fail are the ones chasing the next wrapper, shipping demo-driven agents, and confusing "it works on my laptop" with production readiness. The teams that will fail are startups optimizing for speed of generation while ignoring speed of recovery.

The teams that will succeed, especially in the enterprise, are the ones treating agents like what they are: production systems that happen to include a nondeterministic component. They invest in governance, security, monitoring, and integration before they write a single line of agent code. They build operational maturity first.

The real value was never in the chatbot UI. It was never in the framework. It was in the ability to design, deploy, and operate a system that earns trust.

That's the mission. Lead it.

The Workflow

It starts with a GitHub ticket, created by a PM or QA. Claude Code with the Ralph Wiggum plugin activated spins up a fresh environment, initializes it with the latest codebase, and analyzes the ticket. It loads the relevant Claude Code skills and gets to work.

It creates a branch. It starts coding. When needed, it commits progressively and updates the checklist in GitHub to keep the status visible especially if other agents are working on related issues at the same time.

Once the work is ready, the agent creates a pull request and starts collaborating with other agents. GitHub Copilot steps in for a diff model review a second pair of AI eyes on the code.

At the end of each execution, a summarized version of the conversation is saved. So when work continues on the ticket through a PR comment or a follow-up task the agent picks up the compact context from the previous run. This way, we keep working on the ticket without losing context.

Quality Gates

This is where SonarQube enters. It analyzes the PR and flags the pipeline status. If it fails, Claude Code reads the issues and quality gate results, creates a separate branch to fix them, validates the fixes, then merges them back into the ticket branch.

If the pipeline passes, a Telegram message is sent to the collaborators who worked on the ticket this also doubles as a way to test our own workflow engine in a real scenario.

Why Telegram? Because we've made a deliberate choice about where our developers spend their time. The old model has engineers glued to screens, refreshing CI dashboards, waiting for pipelines, context-switching between Slack threads and terminal windows. We don't want that. We want our team talking to clients, understanding problems firsthand, sitting in the room where decisions are made. The agents handle the waiting. The notifications come to you not the other way around. Build the feedback loop around people, not around screens.

Then comes the human review. We still keep this step. We value the human eye.

After the Merge

Once the ticket is merged, Claude Code spins up a dedicated QA VM for that specific ticket launched from a pre-built image, which makes it extremely fast. After validation, the VM is carefully destroyed. Clean in, clean out.

We chose this over resetting environments because resets are fragile. You can miss something a stale config, a leftover dependency or add a feature and forget to update the reinit script. Starting from a fresh image for QA removes that risk entirely. It was one of our best decisions.

The deployment itself is triggered from the GitHub issue. When the issue is flagged as ready for test, an agent worker detects it, prepares the environment, and comments back on the issue with the VM details. Everything stays in the ticket no separate workflows, no context switching.

With this cycle, a QA engineer can test a ticket before the code review is even done — and continue working on it by adding comments directly on the issue. No need to wait on an engineer, no getting blocked. The feedback loop between QA and the agent stays continuous.

Why We Still Read Every Line

This is how we ship working code at Nuraly while keeping quality and ownership intact. Every agent code is reviewed. SonarQube's pipeline needs to be green. But after all, we still read the new and modified code line by line.

Not because we don't trust the tools but because the code is ours. Agents accelerate the work. The ownership stays with us.

What It Actually Is

OpenClaw is an LLM running in a loop with tools. A workflow that calls an LLM node, gives it access to your file system, browser, shell, and messaging apps, then loops until the task is done. It can also accept commands from long-running nodes like Telegram or WhatsApp, which makes it feel interactive and always-on.

That's it.

I'm not saying it's bad. The engineering is solid. But let's call it what it is: a well-packaged agent loop. An LLM node connected to tools, running over iterations, with persistent memory and messaging integrations. This pattern has existed for a while. Workflow engine, LLM nodes, tool access, long-running connections. The architecture is not new.

What Actually Matters

What actually matters right now and what OpenClaw confirms is everything around the LLM. The tools you give it. How you manage context. How you handle memory between sessions. How you set guardrails so the agent doesn't go rogue. That's where the real engineering challenge lives.

We already know this. The LLM is the brain. But the tools, the context management, the memory persistence — that's the body. And without a good body, the brain just hallucinates in the dark.

The Access Paradox

There's something worth sitting with here. The more data and control you hand to an AI agent, the more it can do for you. But that same access is exactly what lets it hurt you. It's the same lever, pulled in two directions. Give it your email, your calendar, your file system, your shell — and yes, it becomes powerful. But now the cost of a bad decision scales with the access you gave it.

Fragile and Expensive

Here's my honest concern with investing in this pattern right now: autonomous agents are still either fragile or expensive to run. One user mentioned hitting their entire Claude Max daily limit within hours just by letting the agent loop autonomously (before Anthropic blocked users from routing their subscription through third-party tools like this). Another had their agent accidentally start a fight with an insurance company. These aren't edge cases — they're the current state of autonomous AI.

The Real Blocker

And this is where it gets interesting. I think the real blocker for broad adoption isn't the models, isn't the tooling, isn't even the cost. It's security. Until we solve the agent security problem — how to give an AI meaningful access without exposing everything to a single bad reasoning step — autonomous agents will stay in the hands of early adopters willing to absorb the risk. Enterprises won't touch this. They can't afford an agent that emails a client the wrong thing, deletes the wrong file, or leaks sensitive data because it misunderstood a prompt.

Where This Leaves Us

In the absence of a genuine research breakthrough — something on the level of what we saw with Claude's leap in reasoning — we're essentially optimizing the loop. Making the tools better. Managing context smarter. But the fundamental limitation remains: the model reasons well enough for short, bounded tasks, and starts breaking down on anything truly complex or long-running.

Would I invest in building on OpenClaw right now? No. Not because it's bad, but because the value isn't in the loop itself. The value is in the platform layer underneath — the workflow engine that sets boundaries, the persistence layer that maintains state, the permission system that controls access. That's what enterprises actually need, and that's what doesn't come for free with an open-source agent loop.

Build the infrastructure. The agent patterns will keep evolving. But the foundation? That compounds.

Persistence management is one of those features that quietly sinks to the bottom of the backlog. We all want it. We all know we need it. But the priority stays low, pushed aside by urgent customer requests and deadlines. "One day, when we have time, we'll implement it properly." There's a good chance that day never comes.

So we decided to stop waiting.

The Solution: A Dedicated KV Service

At Nuraly, we built a separate service, a simple key-value store that serves our other microservices. It can hold encrypted values when needed, and it runs independently from everything else.

What can you store? More than you'd expect:

• API keys and secrets
• Database connection strings
• User-specific settings per service
• Feature flags and configuration overrides
• Agent state

That last one surprised us too. We now use the KV service to hold the state of our AI agents, their context, progress, and memory between sessions. What started as a configuration store became the backbone of our agent persistence.

All of this sits behind a dedicated permission service, so access stays controlled and auditable.

Why This Works

The beauty of a standalone KV service is isolation and simplicity. You don't need to manage persistence inside each microservice anymore. No more duplicating the same storage logic across services. No more spinning up separate databases just to hold configuration for each one.

Instead, the feature is one HTTP request away.

Each microservice pulls only what it needs, nothing more. No hardcoded values buried in deployment scripts. No redundant persistence layers bloating every service. Just a clean API call.

It's a small architectural decision, but it compounds. Onboarding new microservices becomes faster. Rotating credentials becomes trivial. Debugging configuration issues becomes possible. And every new service you spin up inherits the same persistence capability without implementing storage logic from scratch.

Where This Leads

I've started thinking of persistence not as a feature to implement later, but as infrastructure to build early. The cost of doing it right upfront is low. The cost of doing it wrong, or not at all, accumulates invisibly until it doesn't.

If you're building a platform, don't let persistence sink in your backlog. Build the KV layer now. Your future self will thank you.

At ReactConfg 2018 Event, Dan Abramov explained the Logo of React, he said that the user interface can be splitted into small independent units called components - similar to an Atom - and they will focus, in the next few years, on Hooks: “Electrons” as he named them.

On the other side of the Javascript world, Angular started focusing on smaller units as Component, Directive and Pipes rather than modules.

Starting from Angular 14, Components can be standalone and imported into modules or other components without the need for a dedicated module.

Standalone Component in Action.

To test this feature, I created a blank project and activated the routing option.

Then, I created a basic component UserDetailComponent , the metadata looks like the following.

Then, created a service for the User. For the sake of the demo, this service is not provided in the root providedIn: 'root'

So now, all we have to do is to use the service in the component. Before Angular 14, we had to create a module that defines all providers components and other dependencies or import everything in the AppModule.

Now, we can declare Components as standalone and provide the service directly into the Component

In the Route Module, we can directly import the component rather than the Module.

Github Srouce

You can play with the demo directly on Stackblitz

Motivation

Have you ever thought: why a framework like Angular started to review their vision about modularity?

In most Angular applications we are used to find some CoreModule, SharedModule and others that contain the common unit which is used in more than one module.

Everytime the application grows, there's a chance that these modules will grow too.

That's fine until we start thinking about performance.

In the chart below, we will demonstrate the use of a common NgModule and how to import a component directly inside another module without the middle man, Thanks to Angular 14 of course.

Sharing standard component

In this case we have three components, two services and more than two modules.

These units are used in more than one place, so we created a SharedModule to package them. This ShareModule has been imported in the two modules.

When lazyloading the module with LazLoading routes, the SharedModule alongs with the components and services and every unit exported, will be loaded in each module.

Sharing standalone component

In this case we have the same unit (components, pipes, services and modules) but we ditched the SharedModule.

We transformed the component in Standalone mode, which means that every component will load the needed providers.

The FormatDatePipe load the DateTimeService and DocumentViwerComponent load DocumentService.

Now When lazyloading a Component, only the component that is directly linked to it will be loaded.

Conclusion

Angular started approaching ReactJS with the small independent unit approach by introducing Standalone Component, which seems a big step toward enhancing web application performance and building a better and more maintainable web.

Personally, I'm not fan of the idea of working with only one Framework, since we can explore multiple paths at the same time then adopt what was a success in each Framework.

As Front-end Architect, choosing the right Framework can impact the whole company even the group, that’s why we choose carefully the technologies that we adopt.

For many years Angular prove how stable, it is, and when braking change happens, it will be accompanied by a great documentation.

Even there a tool to assist you when updating project. ng update

Angular CLI auto completion

Bootstraping Component, Pipe and Service is a daily task when starting a new feature with Angular projet. So we use ng command to generate our static files.

If you use VS Code or Intellij or any IDE there's extentions that execute ng generate command for you. But if you want use the command line in your Terminal you will have hard time to remember the arguments to pass.

That's why Angular has introduce CLI auto completion

To use this feature on Winsows you need to activate WSL(Windows Subsystem for Linux) or Use GIT Bash.

Double check if the command has added the command to the .bashrc

And than we can use TAB key to autocomplete, it's a bit slow on windows but it works.

We can go even further with the list of available flags.

Conclusion

Tools make the life of developers easier, every improvement can affect their productivity. This makes us sometimes choose a framework among others in order to get a richer toolkit.

In our case, we need to find out if there's a special character in the string to convert them,  and this was made by checking the decimal code of each character and check if it is above 127 or not,

why 127?

Because the ASCII table told us that the characters code starts from 0 (NULL) and ends at 127(DEL)

So we made this function.

bool isASCII(const std::string& s) { return !std::any_of(s.begin(), s.end(), [](char c) { return static_cast(c) > 127; }); }

And this how we used it

#include #include #include

bool isASCII(const std::string& s) { return !std::any_of(s.begin(), s.end(), [](char c) { return static_cast(c) > 127; }); }

int main(){ std::string testString = "not a valid Ãscii"; std::cout << "Is valid ASCII " << isASCII(testString.c_str()) << std::endl; }

And the output will be:

Is valid ASCII 0

0 as NULL is C++

PS: Will share snippets as I'm learning C++

Being a web developer using JavaScript frameworks consumes a lot of energy.

The JavaScript meant to be for the front-end development and to add some interaction to static pages, like display images on click, validate forms and load async portion of data.

Look around you now, JavaScript is everywhere. every month or a week there a new framework or library that want to change the world appears.

Let's look at some history:

At first, there's plain JavaScript, at that age, you need to write more for less, then it comes the libraries like jQuery, MooTools, and YUI( Yahoo! UI Library )

Then Angular.js has appeared at 2009, followed by Knockout, Backbone.js, Ember.js, and others.

After a while React has been introduced by Facebook at 2013, a component-based frontend framework

Then in 2016, it comes Angular 2+ a complete Javascript framework for the front-end.

But Ryan Dahl let the front-end developer be a full-stack developer by making Node.js

After 2009 developers start making web application and services with Javascript and new JavaScript frameworks start popups.

Starting from 2017-2018 people start choosing a path to follow, like Angular developer, React Developer and so on.

Also me, I'm known as Angular developer,  That's the main framework that I work with but you need also to master other Frameworks if you want to be laways fresh.

Following everything is the perfect option to lose focus. for me, I'm really aware of what I should consume to prevent the distraction, and also I create a routine to keep up with what should I know.

Again have you felt the JavaScript fatigue before? Share your experience with us ?.

When everything goes right, everybody is happy, but when one thing goes wrong, not nesserely everybody should feel sad.

To keep the good relationship we need to remove all the confusing things from the workflow and everybody should speak the same language.

Let's pick a case that everybody will pass on :

You create a view with Angular, Vue or React, you consumed mock services and everything looks OK,

Then it comes the moment of truth when you will connect the frontend view with the backend service/API, you implemented it and it didn't work you will contact the backend developer and he will tell you that his service work like a charm.

You invite him to look at the result and he admitted that there's a bug need to fix.

After he fixes his code, two things can happen :

The bug fixed and everything goes right.

The bug persists and you show him the scenario again and we loop through this until we get everything OK, if we did not break other parts of the App.

That's Ok but, this takes time and energy.

Here's I start a searching for automation, then to end to end testing, to simulate everything, and here's my experience :

I found Cypress and start writing my tests for my views and after each view or service implementation, then the worrying start decreasing.

With the (e2e) end to end testing, you stop worrying about regression and focusing on the new functionalities that need to implement.

With that, the relation between the front and back Team start recovering.

If the test fails I made a video of the issue and send it the concerned person, otherwise I invite him to watch the scenario fails ?

I start being less exhausted as a Front-end developer.

Next step, is to add the e2e test, to the DevOps pipeline.

And you, how are you dealing with the regressions?

First of all, I'm a consultant and I have a startup which means I work on lots of things with a lot of things.

And to keep it up without loses I need to isolate each thing from the other things. and here's where I start using Docker.

I hear people talking about Docker on the DevOps field but this is not the case for me, I start using Docker in the development environment, and here's how.

In the last mission, I was working on a frontend application using the Angular framework, and it's not just me, we were a team working on the same project trying the make things happen, really fast.

But this is not the case when we have a different version of Node.js and @angular/cli.

This start occurring when building success in some machine and fail in other, and here we start using Docker in the development environment, we choose a Node.js version that matches with the production server and we create an image for the environment, then we all start using the same image.

Besides all of that, any new member can use the same image without installing any of other tools than Docker, and it makes the integration of new members easy and smooth.

Then I start controlling the CPU and the Memory of the container to keep the host machine cool and prevent battery drain when I'm walking around with my MacBook Pro

That does not end here.

I start exploring new applications that were hard to install especially when I was using Windows, but with Docker, I just need to pull an image and run it.

I use Docker, how about you?