DEV Community: Joel Milligan

Re-thinking DevOps practices to handle accelerating dev throughput

Joel Milligan — Mon, 23 Feb 2026 11:45:58 +0000

In the age of AI orchestration, gitflow and other dev-centric models just can't keep up with the throughput of pull requests. "Continvoucly morging" breaks down quickly when each dev has migrations, rewrites, SOPS edits, renames, new CI pipelines, and agent file updates. I'd worked for nearly 10 years under such development flows and I already knew when I started as a Founding Engineer at Neno that we would need a new approach to stay competitive and on the cutting edge.

I'm going to walk you through exactly how we did it, why the old way is killing your velocity, and what I think the future of deployment looks like. We call it PReFlow.

Red Tape and Broken Environments

GitFlow can honestly be a great development approach. The pitch sounds reasonable: you have a dev branch, a staging branch, and main (or prod). Code flows through each stage like a responsible assembly line. Merge to dev, deploy, test. Promote to staging, deploy, test. Promote to prod, deploy, pray.

In practice? I've found it to be a traffic jam with no cops.
Here's what actually happens. Engineer A merges a feature to dev. Engineer B merges a different feature to dev ten minutes later. Engineer A's feature depends on a migration that hasn't been tested against Engineer B's schema change. Dev breaks. Now neither of them can test. Engineer C, who was about to merge something completely unrelated, is blocked too. Everyone stops shipping and starts debugging the shared environment.

Multiply this by a team of four with ambition, the kind of team where everyone has multiple PRs open at once, and you get gridlock. Not the productive kind of friction that catches bugs early, but the soul-crushing kind where engineers spend their mornings in Slack figuring out whose turn it is to deploy to dev.

The merge conflicts alone are brutal. When five branches are all targeting dev, and each one touches overlapping files, you're resolving conflicts that have nothing to do with your actual work. You're doing merge archaeology, except the artifacts are three hours old and already stale.

And the worst part? None of this has anything to do with building the product. It's pure organizational overhead. Red tape dressed up as engineering process.

Gitflow was designed for a different world in a different time. We don't live in that world anymore thanks to git worktrees and multiple agent sessions.

The Dev Environment Trap

Dev, staging, and prod environments are a logical approach. Engineering teams need some buffer between "I think this works" and "customers are seeing this." However, this setup has been, in my own belief, one of convenience rather than the right setup for most teams. It is easier to "copy and paste" the setup for a cloud environment multiple times than to invest in better pipelines.

While this works, I would caution that dev environments don't scale the way you need them to.

Every new developer added to the team increases the contention on that shared environment. Every open PR is another potential conflict. And database migrations? Those are the real killers. When two PRs both need to alter the same table, or even when they alter different tables but in conflicting orders, your shared dev environment requires meetings, syncs, and other work that reduces velocity just to make a feature push.

You end up with coordination overhead that has nothing to do with code quality:

"Hey, can I deploy to dev? I need to test my migration."
"Hold on, I'm in the middle of testing something."
"Who ran migrate last? The schema doesn't match what I expected."
"Dev is broken again. Who deployed last?"

These are not engineering problems. These are scheduling problems. You've turned your development workflow into a shared calendar.

At Neno, we had four engineers all moving fast. AI-assisted development meant we were producing PRs at a rate that would've been unthinkable two years ago. We regularly had 20 to 30 PRs in flight at the same time. Gitflow would have buried us. A shared dev environment would have been a full-time job just to keep running.

I saw this coming as I had seen it before and knew there was a better way.

PReFlow: One Environment Per PR

Here's what we built instead, and it's deceptively simple.

When an engineer opens a pull request against main, a unique preview environment spins up automatically. That environment is theirs. It has its own database, its own services, its own URL. It's a complete, isolated copy of the application running their branch — and only their branch.

No conflicts with other engineers. No waiting for someone else to finish testing. No broken shared state. You open a PR, you get an environment. Done.

The full flow looks like this:

Branch from main — always from the latest main, always targeting main. No dev branch. No staging branch. Just good, clean, trunk-based development.
Open a PR — this triggers the creation of a dedicated preview environment. CI runs. The engineer (or their AI agent) tests against a real, running instance of the app with their changes applied.
Merge to main — when the PR is approved and merged, it doesn't go straight to customer-facing production. Instead, it first deploys to an internal sandbox — a production-like environment that our team uses.
Sandbox succeeds → deploy to prod — if the sandbox deployment is healthy, the pipeline automatically promotes the change to production.

Here is a helpful diagram:

That's it. No dev branch. No staging branch. No environment scheduling. No merge archaeology.
Every PR is independent. Every engineer is unblocked. And the pipeline from "code written" to "code in production" is as short as it can possibly be without being reckless.

We get the safety of staged deployments without the organizational overhead. The sandbox acts as our canary — if something breaks there, it never reaches customers, and only the offending merge needs to be investigated, not a tangled mess of five developers' changes landing simultaneously.

The Numbers

This isn't theoretical. We've been using this system at Neno for 4 months now with a team now consisting of 6 devs.

Here's what it looked like:

30-35 PRs merged per week across the team with an average of 3,000 LoC
30-35 deployments to production per week — each one isolated, tested, and promoted through the pipeline
0% of total production downtime over the past 4 months attributable to deployment issues
0 broken shared environments — because there are no shared environments to break
6 minute average time from PR merge to production — including the sandbox validation step

The point is that this system removed an entire category of work from our engineers' plates. Nobody at Neno spent time debugging dev. Nobody waited for their turn to deploy. Nobody resolved merge conflicts caused by a shared integration branch. That time went back into building product.

When you're a small team competing against companies with ten times your headcount, that reclaimed time is everything.

Our Setup

Now for the important part, telling you how to replicate this.

We have quite the simple setup, I'll hit the main points:

Cloud Provider: GCP
Infrastructure as Code: Pulumi in typescript, self-hosted on a GCP bucket
Frontends: Deployed from react project as static sites through Cloudflare
Git and CI Platform: GitHub, though we aren't thrilled with them

We did follow the same approach as GitFlow, whereby we used pulumi to create preview (dev), sandbox (staging), and production environments. However we don't use the default Cloud Run instance we've setup for preview. Instead we take another approach.

Here's the blow-by-blow:

Step 1 (~28 seconds): We begin the CI pipeline by spinning up a new database within our Cloud SQL instance with the PR name: api_pr_xxx
Step 2 (~1-2 minutes): Next, we calculate all the domains for the preview environments and inject them into the builds. At this point we build the API docker image from our monorepo. We also separately build the frontends in parallel. Also during this step we run any DB migrations.
Step 3 (~1 minute): We deploy the new API image through the gcloud CLI directly in our CI. Frontends are pushed to preview deployments in Cloudflare
Step 4 (~4 seconds): We comment on the PR with links to all the domains to access the services.

And that's IT.

Working on a new feature and you want to share it with someone? Just share the preview frontend link. It's that easy.

We also run a cleanup action on merge, but I'll not cover that now.

Clues We're on the Right Track

If you think this is niche: a cute optimization for a small startup — I'd ask you to look at what's happening in the industry right now.

In February 2026, OpenAI's VP of Engineering Srinivas Narayanan revealed that internal teams had shipped a beta product with zero human-written code. The entire thing was generated by Codex agents. Not scaffolded by AI and polished by humans; fully AI-authored, start to finish.

Around the same time, Fortune reported that engineers at both Anthropic and OpenAI said AI now writes 100% of their code. The humans are reviewing, directing, and architecting — but the actual code production is machine-speed.

Think about what that means for deployment infrastructure.

If your engineers (or their AI agents) can produce code at 10x the previous rate, your deployment pipeline needs to handle 10x the throughput. Gitflow couldn't handle 5 PRs a day gracefully. What happens when AI agents are opening 50?
Shared dev environments that buckle under four engineers will collapse under the weight of AI-generated pull requests. The bottleneck won't be writing code anymore: it already isn't. The bottleneck will be getting that code tested, validated, and into production without everything falling over.

That's exactly the problem PReFlow solves. Every PR gets its own isolated world. It doesn't matter if a human wrote it or an AI agent did. It doesn't matter if there are 5 PRs open or 50. The system scales horizontally because each PR is independent.

This is where software development is headed. The teams that figure out deployment at AI speed will ship circles around the teams still debating whose turn it is to deploy to dev.

Build for Throughput

Your deployment pipeline is your competitive advantage. Not your framework choice. Not your cloud provider. Not whether you're using the latest AI model. The thing that determines how fast you ship — and therefore how fast you learn, iterate, and win — is how quickly a change can go from "written" to "live" without breaking anything.

Gitflow was a good answer to a 2010 problem. Shared dev environments were a reasonable compromise when teams were small and PRs were infrequent. But we're in a different era now. AI is writing code at top speed. Small teams are producing enterprise-level output. And the old deployment models are buckling.

If you're a founder, an engineering lead, or just someone who's tired of spending their mornings debugging a shared dev branch, consider this: kill your dev environment. Kill your staging branch. Give every PR its own world, validate through an internal sandbox, and ship to prod with confidence.

It's simpler than it sounds. And it's faster than you think.

Joel is a Founding Engineer of Neno. He writes about engineering velocity, AI-assisted development, and the systems that make small teams dangerous.

Symbol Extraction - Killing Modular Monoliths

Joel Milligan — Thu, 29 May 2025 14:53:29 +0000

Let’s be honest: rewriting legacy systems sucks.

It’s expensive. It’s slow. It’s risky. And it often fails.

At NanoAPI, we’re building a new way forward—one that lets you evolve your system by extracting functionality instead of rewriting everything from scratch. Our goal is to help teams innovate, scale, and adapt without the weight of technical debt dragging them down.

Because legacy systems shouldn’t be anchors - they should be launchpads.

2. Why Is This a Problem?

Most modern software systems weren’t designed—they evolved. Over time, teams change, frameworks become outdated, and business logic sprawls across thousands of lines of code.

The result? Monoliths that no one fully understands. You touch one thing and something else breaks. A single function call could be trivial—or it could power your entire payments pipeline. Good luck figuring out which.

This complexity kills velocity. It paralyzes decision-making. And for leadership, it’s nearly impossible to assess what parts of the system are fragile, valuable, or safe to change.

3. How Do People Solve This Today?

There are two dominant approaches on the market today, and both are painful:

Rewrite Everything (a.k.a. "The Big Rewrite")
Tools like Claudia.js or the Modular Monolith pattern encourage extraction though rebuilding around modern paradigms (e.g. serverless), but this typically demands a full migration and deep re-architecting. Even if it starts small, it spirals into years of work. Rewrites introduce regressions, delay product roadmaps, and often stall out before delivering value. A middle-ground approach often used here is the manually-driven Strangler Pattern, which still requires years of effort.
Apply AI to Understand Codebases
The promise is tempting: use LLMs to analyze your code and tell you what’s important-or even better, rewrite the whole damn thing for you. But there’s a catch—context windows are too small for real-world monoliths. AI tools may hallucinate, struggle to maintain consistency across files, and miss deeper structural relationships. You end up with surface-level insights, not surgical extractions.

Both options feel like hacking through a jungle with a butter knife.

4. NanoAPI's Solution – Symbol Extraction

At NanoAPI, we believe the right abstraction layer is the symbol.

We built a platform that helps teams extract critical functionality from legacy codebases by analyzing symbols—functions, classes, and variables—mapped into an architectural graph.

This process, which we call symbol extraction, lets you isolate self-contained pieces of your system, see how they depend on each other, and surgically extract or modularize them with confidence.

No rewrites. No guesswork. Just precision tooling for technical debt.

5. What Are Symbols?

In software, a symbol is any named element in your code: a function, class, variable, or module. These are the building blocks of your system’s logic.

Think of them like DNA for your application. Each symbol contains business logic, and together they form complex, interdependent behavior.

By analyzing symbols and how they reference each other, we can reconstruct a living architecture of your codebase—one that’s often more accurate than documentation or diagrams ever were.

6. What Is the Benefit of This Approach Over Other Tools?

Symbol extraction has several key advantages over conventional methods:

It’s deterministic. We don’t guess. We analyze. Our system maps your code’s actual behavior, not just inferred patterns.
No need to rewrite. Our tool is integrated in 5 minutes: instead of migrating everything over years, you selectively extract what matters right away.
Architecture lives in code. Forget stale diagrams—your architecture becomes queryable, visual, and up-to-date.
Safe, modular extraction. You can break down a monolith into clean components without introducing regressions.
Clarity at scale. From a single function to a sprawling app, you get an interactive map of what your code is doing and why.

This is not just code transformation—it’s code as architecture.

7. What Are the Outcomes for Teams and Tech Leadership?

For engineering teams, NanoAPI means:

Understanding dependencies instantly
Knowing what’s safe to extract and what’s tightly coupled
Preserving core logic while shedding dead weight
Making real progress on tech debt without fear

For tech leadership, it means:

Accelerating innovation without rewriting from scratch
Unlocking architectural visibility across teams and services
Bridging the gap between today’s monoliths and tomorrow’s modular systems
Making informed decisions on investment, risk, and scaling

As companies shift toward serverless or modular monolith architectures, NanoAPI becomes the evolution engine—not a rip-and-replace tool, but a precision scalpel.

8. How You Can Help

We’re building NanoAPI in the open—with engineers, architects, and teams like yours in mind.

Here’s how you can get involved:

Try our open-source tool and give us feedback: github.com/nanoapi-io/napi
Join the community on Discord
Contribute use cases or PRs
Talk to us about using NanoAPI in your migration or modernization efforts

Together, we can turn legacy systems from roadblocks into runways—and bring architecture in line with reality.

Want More Information or Help Get Involved?

If you’re facing architectural bottlenecks, uncertainty in legacy systems, or need help guiding technical transformation, NanoAPI can help.

We’d love your feedback, ideas, and contributions.

🌐 nanoapi.io
🔍 docs.nanoapi.io - Our documentation
🐙 GitHub Repo — star us ⭐
📬 Reach out via email — we’re always happy to connect
👾 Join our Discord community!

NanoAPI v1.0.9: Migration to Deno & Performance Boost 🚀

Joel Milligan — Mon, 26 May 2025 08:45:40 +0000

We're excited to announce the newest release of NanoAPI v1.0.9! This release represents a massive architectural overhaul with our migration from Node.js to Deno, which delivers substantial performance improvements and a streamlined development experience.

🎯 What's New in v1.0.9

Deno Migration & Performance Revolution

We've rebuilt NanoAPI to leverage Deno's modern capabilities:

Native Deno modules to replace all Node.js dependencies, dramatically reducing bundle size
Migrated from Express to Oak framework (JSR:@oak/oak) for seamless Deno compatibility
Eliminated some external dependencies (uuid, express, http-proxy-middleware, octokit) in favor of Deno's built-in modules
Adopted JSR registry for standard libraries (@std/path@^1.0.9) to leverage Deno's ecosystem

The improved performance is noticeable immediately, due to faster startup times and a reduction in the overall memory footprint.

Why We Opted for Deno

Deno takes a more modern approach than Node.js, because it enables direct URL imports, which eliminates the need for a package manager
Deno has a commitment to web platform compatibility, and allows browser APIs like Fetch and Web Workers to work natively on the server, creating a unified development experience.
Security is key for Deno - it has a permission-based security model which restricts system access by default, allowing for a more granular control over what applications can do.
Furthermore, it offers built-in testing, formatting, linting, and bundling tools to mean fewer dependencies and a more cohesive development workflow.

A More Streamlined Build & Deployment

We've revamped how NanoAPI is distributed:

The release is now shiiped as Deno executables published on GitHub, instead of the npm registry
A more convenient installation script
Optimized GitHub Actions with faster build times and reduced complexity
Improved our installation documentation to guide you through the upgrade

Enhanced API & Developer Experience

Every aspect of the developer experience has been refined:

Smart version checking with native fetch API and 5-second timeout protection
GitHub-first version verification (goodbye npm registry dependencies)
Cross-platform browser launching using Deno.Command for consistent behavior
Native port detection leveraging Deno's networking APIs

Frontend Modernization

The user interface has received a complete refresh:

Improved Integration:

Seamless API communication between frontend and backend
Optimized routing that works perfectly with Oak middleware
Enhanced file explorer with improved dependency graph connectivity

Modern Components:

Upgraded from bare Radix UI to the comprehensive Shadcn/UI component library
Streamlined UX flows for intuitive user interactions
Better visual feedback and responsive design patterns

🚀 Getting Started with v1.0.9

Ready to experience the new NanoAPI? Here's everything you need to know:

Installation

# Quick install via our convenience script
curl -fsSL https://raw.githubusercontent.com/your-repo/nanoapi/main/install.sh | sh

# Or download directly from GitHub releases
# Visit: https://github.com/your-repo/nanoapi/releases/latest

Migration from Previous Versions

If you're upgrading from an earlier version:

Backup your current configuration - While v1.0.9 maintains API compatibility, it's always good practice
Update your scripts - Replace any Node.js-specific calls with Deno equivalents
Review permissions - Deno's security model may require explicit permission flags

What's Next?

This release sets the foundation for exciting features coming in future versions. We're already working on enhanced TypeScript support, additional built-in utilities, and expanded deployment options.

Do You Have Any Questions or Feedback?

Join our community discussions on GitHub or reach out on our Discord server. We'd love to hear about your experience with the new Deno-powered NanoAPI!

🌐 nanoapi.io
🔍 docs.nanoapi.io - Our documentation
🐙 GitHub Repo — star us ⭐
📬 Reach out via email — we’re always happy to connect
👾 Join our Discord community

We’d love your feedback, ideas, and contributions!

🚀 Introducing NanoAPI v1.0.6 — Our First Stable Release!

Joel Milligan — Wed, 30 Apr 2025 13:54:07 +0000

We’re excited to announce NanoAPI v1.0.6, the next release of our source-available developer tool focused on building better software architecture in the AI age. In comparison with traditional refactoring tools, NanoAPI gives developers full visibility and control over their architecture, making refactoring easier, safer, and more efficient for everyone.

Whether you’re refactoring legacy code, managing rapid growth, or just aiming for architectural clarity, our open-source tool NanoAPI (napi) is aimed at helping developers, software and solution architects to understand, audit, and evolve their systems—safely and confidently.

Included in this release is support for the following programming languages:

Python
C-sharp

Our documentation is available here.

What is NanoAPI (napi)?

NanoAPI is a versatile tool designed to help to map architectural complexity and enable modular extraction of functionality from large codebases.

Historically, tools like this used to live behind expensive consulting fees. NanoAPI democratizes them, enabling teams of any size to:

🚨 Audit: Pinpoint areas of your code that need refactoring or cleanup.
📝 Refactor: Extract functionality using the UI to improve architecture.
🏗️ Build: Generate modular microservices ready for deployment.
🔍 Architecture: Get a live view of all your software and their interactions; scoped to a specific moment in time.

No more black-box tools. Just open, inspectable, source-available application architecture.

✨ What’s New in v1.0.6?

🔍 Core Engine & Extraction

Improved Python symbol extraction with better handling of partial imports
C# metrics now available for enhanced architectural insights
Enhanced visual representation of nodes for large codebases
Updated highlighting mechanism for better code navigation
New extraction mode with API integration + editable symbol metadata
Fixed Python error AST node cleanup for more reliable extraction

CLI Enhancements

Better version checking with in-terminal update instructions
Fixed static file serving and CLI shebang handling
Streamlined build process for faster execution

Build & Packaging

Moved from external @nanoapi.io/shared to bundled CLI integration
Switched to tsup for more reliable bundling and build performance
Refined workspace configuration and dependency versions

🔧 Core Features (v1.0.6)

✅ Multi-language support (Python, C# — more on the way)
✅ Auto-generated system & code-level diagrams
✅ Audit, refactor, and modularize monoliths
✅ Full visibility into code written by AI or past contributors
✅ Deterministic and inspectable — no black-box logic

Want More Information or Help Get Involved?

If you’re facing architectural bottlenecks, uncertainty in legacy systems, or need help guiding technical transformation, NanoAPI can help.

We’d love your feedback, ideas, and contributions.

🌐 nanoapi.io
🔍 docs.nanoapi.io - Our documentation
🐙 GitHub Repo — star us ⭐
📬 Reach out via email — we’re always happy to connect
👾 Join our Discord community!

We’re source-available first because trust matters, especially when your team’s software architecture is on the line.

The Value of Using Numbers to Convince Your PO/PM to Approve Refactoring

Joel Milligan — Thu, 24 Apr 2025 14:21:09 +0000

Why should we refactor? Every dev has their experience with technical debt, but convincing a PO/ (PM) to prioritize refactoring is often a battle. The issue is that POs/PMs think in terms of measurable business value but without hard data, and as technical debt is an invisible cost, refactoring sounds like an unnecessary cost. By presenting measurable metrics, you can prove that refactoring saves time, reduces costs, and improves stability, then POs/PMs, could be convinced otherwise.

Why Refactoring Is Hard to Justify

Why the resistance against refactoring? Because time spent improving “old” features or functionality is time taken away from developing new features. In the age of 2-week time-to-market thanks to AI, it’s now harder than ever to convince management of the need to delay new work.
The “if it's not broken, don’t fix it” mantra within business logic, does not agree with the reality that the more code you have, the more expensive it is to maintain. The issue is that poorly maintained code leads to slower development, higher bug rates, and increased long-term costs.

The Hidden Costs of Technical Debt

Real costs of technical debt:

Technical debt can have significant financial implications. A 2022 study estimated that enterprises face approximately $1.52 trillion in software technical debt. (Tonic Technical Debt 2022)
Increased onboarding time for new engineers due to confusing code architecture.
Scalability bottlenecks causing performance issues.

Make Refactoring Make Sense to POs/PMs

Refactoring isn’t just for the developers, it’s a business decision waiting to happen. Convince your PO/PM by speaking the language that they do- show them the numbers.
Accomplishing this requires changing the conversation by showing your PO/PM the right metrics, by using data-driven reasoning tools:

Incident reports & downtime caused by legacy code.
Time spent debugging vs. building new features (e.g., 40% of sprint time is spent fixing old code).
Overall architectural quality of both the codebase and the entire system, which can be tracked over time as a KPI. Having access to these metrics is not only valuable for PO/PMs to make decisions, it also allows developers to build the software in a way which makes the company acquirable in the future.

"NanoAPI clarified our codebase, cut technical debt, and sped up releases." - Mahdi Pourismaiel CTO Unideck

Acquisition and Customer Readiness

Large customers and potential buyers of a business will both want to assess the architectural quality of your software. If your company doesn’t pass these audits, it could lead to millions lost in client and acquisition deals.

Because this has a direct impact on the technical and non-technical leadership, this is a powerful bargaining chip for teams to use to get their refactoring efforts assigned into sprints.

How NanoAPI Helps

Then what we offer at NanoAPI:

Automated Refactoring Insights – Get hard data on bottlenecks, dead code, and API inefficiencies.
Architecture-level Visualizations - Spend less time during refactors by seeing exactly where the tech debt lies.
Faster Onboarding - Get new developers up to speed 55% faster.
Understand AI Code - Shine a light on AI-generated code within your systems to better understand how it affects your technical debt.
Visual Reports & Metrics – Easily present refactoring benefits to management.
Incremental Improvements – Refactor without disrupting active development.

We believe software should be an open book, instead of a black box. Our open-source tool is aimed at helping teams to visualize, refactor, and modernize their architecture. Thereby making complex systems more transparent, maintainable, and efficient. We built NanoAPI because we’ve felt the pain of technical debt firsthand, digging through legacy systems, trying to make sense of tangled dependencies. That’s why we’re on a mission to give developers clarity and control over their codebase, without compromising security or performance.

We’re creating a community by embracing open-source principles. Join our space, where developers, architects, and tech leaders can collaborate, share knowledge, and shape the future of software together. If you care about scalability, maintainability, and smarter software architecture, join us. Let’s build better systems, together.

If your organization is suffering from these problems, please reach out to us via email or on https://nanoapi.io.

Please star us on GitHub!⭐

Why AI Refactoring Is a Rug Pull – The Hidden Risks of Automated Code Changes

Joel Milligan — Thu, 27 Mar 2025 15:15:55 +0000

Nowadays, with the rise of Copilot and ChatGPT, and other AI-powered code refactoring tools, we should be more efficient, but is it, but is it saving us time and improving software quality? Even though AI refactoring gives us the promise that we now have less grunt work, it introduces risks for software developers in terms of quality, control, and unintended consequences. Often it is necessary to clean up the mess of a Copilot refactoring, or clarify the error to ChatGPT multiple times, while being drowned in word vomit code. It generates so much code, it is hard to see the small changes.

Furthermore, a contact in a large Copenhagen-based enterprise gave us the following insight into their troubles with AI:

“The quality of code of junior developers has dropped by 54% in the years since the launch of ChatGPT”.

This contact has asked to remain anonymous, and that should key us into another portion of the issue at hand:
Companies don’t want to admit when they are using AI to write code.

Well why not?

The Problem with AI Training Data and Stochastic Systems

We all know that AI models are trained on vast amounts of data and code, but even though the AI may understand how to predict code, we don’t know whether the training set of code was actually any good.

There is a lack of transparency on which code it was trained on, and it is very likely that a large amount of the code is either legacy, not functional or just plain badly written code.

As the age-old adage goes: Garbage in, garbage out, if the AI just keeps recycling garbage from inconsistent or outdated codebases, it can risk introducing suboptimal patterns into refactored code.

Basically, even though our code should be refactored, it still incomprehensible how useful or efficient the refactoring was. It has been shown that Copilot and other AI models sometimes produce error-prone or insecure code snippets📌 GitHub Copilot & Security Concerns

We need a non-AI-controlled approach that keeps developers in charge.

AI will always lack context – either through a context window that is too small, or by missing out on some bigger picture – thereby creating unintended consequences.

While AI can predict isolated improvements, but it doesn’t see the entire codebase or long-term impact, and it completely fails at multi-repo tasks. Refactoring isn’t just about “rewriting” code - it’s about understanding its role within the entire system.

Thought Experiment:

I’d like you to join in a thought experiment with me. Imagine I hand you a book, and ask you to memorize its contents. So you do. You take the book and read it again and again until all the information is safely locked away in your memory, and you feel confident to answer any question asked about the contents. Later, I come back and ask:

“From what tree was the paper of that book made?”

You would not and could not ever know the answer to this question by only examining the code, and that’s the exact issue with using AI for architectural tasks: AI lacks context about the entire system that doesn’t exist in the code in any practical or meaningful sense.

Refactoring Without Full Visibility May Lead To:

Breaking dependencies
Removing "unused" but necessary functions
Performance regressions

And this is just the functional side.

Business Logic in Large Systems

AI does not understand your organization’s logic which leads to subtle regressions of your user flows. Edge cases may not be considered and can break things in unexpected ways, hurting user trust in your products and brand.

Refactoring without context is like moving furniture around in a dark room - you might trip over something critical.

We all, as developers, rely on understanding the code structure for debugging, to be able to improve and to be able to maintain the codebase. The issue is that with AI refactoring is that we don’t know why it made changes.

This makes debugging harder, as logic and intent are not always translated well. AI refactoring is like “word vomit” in code - how can you filter essential changes from unnecessary noise?

Also, AI might change too much at once, which leads to overcomplicated logic, unexpected behavior and performance regression.

This means that developers lose control over incremental, intentional improvements.

For example, AI-based refactoring may remove necessary but "unused" functions that were crucial for future updates. AI refactoring is like a junior dev on autopilot - excited to rewrite everything, but unaware of long-term consequences. The goal should be that AI should augment and aid developer decision-making, instead of replacing it.

Overall, AI refactoring introduces risks due to lack of quality control, context, and developer insight. What is critical is that developers need full visibility and incremental changes to ensure code maintainability.

The Alternative

You probably expected this, but here is the part where I suggest another solution: NanoAPI. A developer tool designed to help teams understand, refactor and modularize their codebases without the pain of major rewrites. Because of our CLI and UI, NanoAPI helps to identify dead endpoints in code, detect bottlenecks, and generate system-level interaction maps.

In comparison with traditional refactoring tools, NanoAPI gives developers full visibility and control over their architecture, making refactoring easier, safer, and more efficient for everyone.

Here is a list of the core features at the time of writing:
✅ Multi-language support (Python, C#, with more languages on the roadmap)
✅ Auto-generated diagrams of system- and code-level interactions to pinpoint tech debt, bottlenecks, and the risk levels of refactors on various parts of the system.
✅ Deeper insights into code written by AI or former employees.
✅ Git history-style exploration of your architecture over time.
✅ KPIs and insights into how your technology transformations are progressing.

And we have so much more on the way.

If your organization is suffering from these problems, please reach out to us via 📧email or on https://nanoapi.io.

We’re building this tool not only to put a collar on AI-refactoring, but also to build trust with developers. That’s why we’re source-available first. Please check out the project on GitHub and star us⭐!

Quick Time Events: How to Align a Team in One Meeting

Joel Milligan — Tue, 26 Nov 2024 14:02:19 +0000

Whether at a large corporate or a small start up there exists a problem you've likely encountered: how to get people to align and "buy-in" to a decision. For developers this can be especially tricky, as they are the ones who are building your product and need to have the most buy-in by definition. At NanoAPI, we’ve developed an unconventional yet highly effective way to strike the perfect balance between decisive leadership and team buy-in: Quick Time Events (QTEs).

This post covers the first of many NanoAPI-isms: things we do to stand out and change the way companies operate by thinking critically about what our goals are.

The CEO (or Leader) as a "Tolerant, Benevolent Dictator"

In our time at Techstars Berlin we've had the opportunity to learn from some truly amazing voices in the startup space.

One such person clued us in to market research which consistently shows that the best startups are often led by a CEO who acts as a "tolerant, benevolent dictator"—someone who is ultimately responsible for making tough calls but still respects the input and expertise of their team. This approach ensures that decisions align with a strong vision and strategic goals.

However, the “dictator” model runs the risk of alienating team members if they feel left out of the process. Left unchecked, this can lead to quiet quitting and other forms of team opt-out. To prevent this we've created Quick Time Events (QTEs).

What Are Quick Time Events?

Borrowed from the gaming world, a Quick Time Event is a brief, interactive sequence where players must act decisively to achieve a specific outcome. In the NanoAPI context, a QTE is a structured, high-energy meeting designed to rapidly gather input and achieve consensus on key decisions. Think of it as a "decision sprint" that happens all in one meeting.

Especially for startups, having alignment on efforts can save hundreds of hours of time in the long rung.

How NanoAPI Implements Quick Time Events

Here’s how we run QTEs to accelerate decision-making while keeping our team engaged and aligned:

1. Define the Problem in Advance

Before a QTE, the leadership team clearly defines the problem or decision that needs to be made. This includes any necessary context or background, so the team comes in ready to contribute.

2. Set a Time Limit

The hallmark of a QTE is urgency. We allocate a strict time limit—often no more than 30–45 minutes. This forces everyone to focus on what’s truly important and avoid getting bogged down in unnecessary details.

3. Gather Focused Input

In the meeting, we present the problem and outline potential options. Each team member gets a brief window (e.g., 1-2 minutes) to share their perspective. This ensures every voice is heard while keeping the discussion moving quickly.

4. Facilitate Rapid Consensus

Once input is gathered, the CEO synthesizes the feedback and makes a decision—live, in the meeting. This step emphasizes accountability and decisiveness while showing the team that their input directly influenced the outcome.

5. Document and Act

Immediately after the QTE, we document the decision and any action items. Everyone leaves the meeting knowing exactly what’s happening next and who’s responsible for what. For implementation of new features, this is where a follow up meeting would be scheduled to create and refine tickets.

Why It Works

Speed: By focusing discussion and enforcing time limits, QTEs ensure decisions are made quickly.
Clarity: The process removes ambiguity, making it clear how and why a decision was reached.
Buy-In: Team members feel valued and heard, even when the final call rests with leadership.
Momentum: With decisions made on the spot, we can move forward immediately, maintaining our startup’s velocity.

The Results

Since adopting Quick Time Events, NanoAPI has seen a significant improvement in our decision-making speed and team alignment. Whether it’s choosing a product direction, deciding on a technical architecture, or setting our go-to-market strategy, QTEs help us maintain our startup’s agility without sacrificing team cohesion.

Closing Thoughts

Startups are inherently chaotic, but with the right systems in place, you can turn that chaos into a competitive advantage. At NanoAPI, Quick Time Events have become a cornerstone of our culture, allowing us to combine the decisiveness of a “benevolent dictator” with the collective wisdom of our team.

If you’re looking for a way to turbocharge decision-making at your startup, consider giving QTEs a try. Who knows—they might just become your team’s secret weapon, too.

What’s your take on this approach? Drop a comment below, or reach out to share how your team tackles the decision-making challenge!

This is the first of many posts on how we run our devtools company. If you're looking to see more of this, give us a follow.

We're building fast and looking for help. Please consider:

Credit to u/magickdinopx for the cover art.

Microservices Traffic Should Be I-Shaped, Not L-Shaped

Joel Milligan — Thu, 07 Nov 2024 15:34:09 +0000

In the last decade, microservices have become the poster child for scalable software architecture. Companies like Netflix and Amazon champion the model, attributing their ability to scale to microservices. This rise in the use and reported benefits of microservices have led to greater adoption amongst many companies. But as with every shiny new toy, there’s a dark side to watch out for—particularly when it comes to how microservices communicate.

In this post, we’ll explore why your microservices traffic should resemble an “I” and not an “L” (in most cases, of course). This might sound like an odd analogy, but it’s one that can save you from an architecture that spirals into chaos.

The Problem with L-Shaped Traffic

Microservices rely heavily on network communication to function. When one service depends on another, requests are sent across the network. This dependency tree grows as your system scales. In an ideal world, this traffic pattern would be predictable, resembling an “I”—a single line from the client to the relevant service, with minimal dependencies on other microservices.

But in many cases, we see an “L” shape emerge:

A client request hits one service.
That service needs to talk to another, which talks to yet another, and so on.

In the above image, it's easy to spot, but in real-world examples like the one below, it's much harder to spot.

As you can see, a single request fans out into multiple downstream calls. This might not sound bad in theory, but in practice, it can result in a nightmare scenario:

Latency multiplies: Each additional network hop introduces latency, slowing down your system.
Failure cascades: A single service failure can ripple across the architecture, causing widespread outages.
Observability issues: Tracing what went wrong forces the inclusion of distributed tracing and logging tools like Jaeger and New Relic, increasing costs.

This is the dreaded L-shaped traffic. It’s complex, fragile, and a performance killer.

The Hidden Cost of Over-Communication

Let’s dig deeper into why L-shaped traffic is particularly harmful. Each microservice call consumes network bandwidth, requires serialization/deserialization, and introduces potential for errors. This creates a compounding effect where:

Performance deteriorates: Even a system designed for high throughput struggles under the weight of excessive inter-service communication.
Costs balloon: Your cloud provider charges you for every byte sent and received. With L-shaped traffic, your operational expenses can skyrocket.
Developer experience suffers: Debugging a chain of service calls with dozens of logs, traces, and metrics can overwhelm your team.

In many ways, you’re defeating the purpose of microservices and you would be better off with a monolith. You can of course tackle some of these issues by building in retry logic when making HTTP, gRPC, or other network requests, but this functionally further reduces the actual usability of the system. To prevent flooding the network you then have to implement exponential backoffs, to solve the process getting stuck from long backoffs you need to cancel the request at some point, so on and so on, ad nauseam. By the end of it, you've delivered a mess of code that adds no direct business value. It doesn't even make the system more robust, as any changes to the contract of an endpoint will break all of its consumers anyways.

How L-shaping Sneaks up on Your System

As much as every engineer hates to admit it, there is only one thing allowing us to continue going into the office and working for any of the companies in tech right now: making money. This drive to make money creates sub-drives within a company that seriously harm the ability to correctly architect a system. From fast time-to-market, to product people making time promises that aren't possible, the functionality must always be improving.

In reality this results in developers taking shortcuts.

"Oh," they may say, "I have to deliver this functionality soon, but the service I work in doesn't have the data I need. I see in the Swagger doc for service B that there's an endpoint that exposes exactly what I need. Hot dog! I'll have it done in an hour!"

There's so much wrong with this. To focus up:

Implementing against the API of a service owned by another team without telling them means that both teams will have to be on the 3am call to discuss the break in production whenever team B changes the contract or deprecates the API.
A (possibly critical) flow now contains a sub-dependency that can be a single point of failure.
No real design effort went into this solution; it was simply the quickest option.

Even worse, you have entire frameworks like loopback built around this pattern (which I'm still convinced exist only to increase pricing on IBM's load balancers).

Why I-Shaped Traffic is the Solution

In contrast, I-shaped traffic emphasizes simplicity:

Direct, minimal communication paths: Services are designed to fulfill requests without relying on multiple downstream services.
Focused responsibilities: Each service handles its domain independently, limiting the need for coordination.
Improved reliability: By reducing the number of network hops, you reduce the probability of failure.

I-shaped traffic is lean and predictable. It’s the kind of architecture that keeps your system running smoothly even as you scale.

A good I-shaped architecture based on the complex L-shape example from before might look something like the following:

In the above example, the conscious choice was made not to send a response to the user right away during the purchase flow. Instead, they are notified later via email.

In cases like these, it can be both good for the user and the developer experience.

The Business Case for I-Shaped Traffic

Beyond technical benefits, I-shaped traffic has real business implications:

Better user experience: Faster response times lead to happier users.
Lower operational costs: You save on cloud bills by minimizing unnecessary data transfer and resource usage.
Reduced risk: A simpler system is easier to maintain and less prone to catastrophic failures.

How to Achieve I-Shaped Traffic

At the core of the problem is a simple question that can be asked to determine how data should be shared among services: "Does the data this service is working with need to be up to date? Or can it be a few minutes or hours stale?"

That's it, determining the trade-off between strongly-consistent and eventually-consistent data retrieval or operation methods helps to clarify if inter-service http traffic is really needed. It's not a silver bullet, but it's a good start that I see many engineers completely ignore when designing service interactions.

Below are some steps you can take while determining how up-to-date your data should be:

Flatten Your Dependencies: Avoid deep chains of service calls. If Service A consistently requires data from Services B and C, ask whether A should own or cache that data directly. This reduces the need for repeated HTTP calls, improving performance and ensuring that A can operate independently. For strongly-consistent data, direct ownership may be necessary, whereas eventually-consistent data can rely on periodic synchronization or caching.
Adopt Event-Driven Architectures: Synchronous HTTP calls often impose strong consistency guarantees, which can lead to L-shaped traffic patterns. Instead, consider asynchronous communication through queues or pub/sub systems. This approach aligns well with eventually-consistent operations, allowing services to react to events without blocking or waiting for immediate responses. Strongly-consistent actions should remain synchronous but limited to where they are absolutely necessary.
Choose the Right Read Strategy: Build specialized read models that aggregate and cache data across services. This approach minimizes the need for real-time dependency chains. If your system can tolerate eventual consistency, read models can be asynchronously updated via queues. For scenarios requiring strong consistency, ensure the read model is tightly coupled to the source of truth but designed to minimize cascading calls.
Evaluate Communication Patterns: Not all data retrieval justifies an HTTP call. Use HTTP for operations where strong consistency is critical and the cost of failure is high (e.g., payment transactions). For less critical operations or where eventual consistency suffices (e.g., analytics, reporting), favor queues or caching mechanisms to reduce synchronous dependencies.

It may be obvious, but these improvements will likely take time and not happen overnight. That begs the question:

Are Microservices Bad?

Its a serious question to ask. Especially considering all the bad news that seems to be coming out month-by-month of all the companies moving back to monolithic architecture.

The short answer is no. But like any tool, they need to be used correctly. Microservices excel when services are loosely coupled and highly cohesive. Problems arise when teams overlook the communication overhead and design sprawling dependency graphs.

If you’re struggling with an architecture that feels more like a liability than an asset, it’s time to rethink your microservices traffic. Aim for I-shaped patterns, and you’ll avoid the pitfalls that plague so many teams.

Conclusion

Microservices are here to stay, but their success depends on how you structure their communication. By adopting an I-shaped traffic pattern, you can ensure your architecture remains scalable, reliable, and cost-effective.

Don’t let your microservices turn into a web of tangled dependencies. Focus on simplicity, and body will thank you with each full night's sleep you get.

Thanks for reading!

I'm Joel, CEO of NanoAPI and I've been fighting the good fight with and against microservices for almost 10 years now. If you found this post helpful, or you'd like to give back, please star our repo on GitHub ⭐. It really helps out.

We're currently building napi for companies who are looking to move their monolithic APIs into microservices. It addresses many of the pitfalls associated with the transition to microservices and helps developers and architects understand exactly what their system is doing today. With this tool, we're aiming to create "microlithic development", a new approach where a team writes a monolith, and breaks it up into microservices at deploy time.

If you think this could be for you, or you'd like to become a design partner, send me an email.

Rise of the "Microlith": Rethinking Microservices for Modern Developers

Joel Milligan — Mon, 28 Oct 2024 09:00:49 +0000

Hey dev.to community!

We're excited to announce that after two years of development, our project napi is going open-source! We've been building something that we believe will fundamentally change how developers approach building and deploying applications. Here's a quick dive into what we're doing, why we're doing it, and how you can be a part of it from day one.

TL;DR

🛠️ We're building to help companies reduce early technical trade-off, and late refactoring efforts, by offering a new way of writing large API codebases.
🚀 Initial focus on NodeJS ecosystem, but quickly expanding outward to PHP, Java, and more.
👉 Star the project on GitHub to follow along with our progress.

A New Approach to Development: Build Monoliths, Deploy Microservices

The traditional struggle between monolithic architectures and microservices is one every developer knows. With our project, we aim to bridge the gap by providing developers a seamless way to write monolithic applications that can be deployed as microservices. Because of this, we have coined the term "Microlith" This approach brings the best of both worlds — allowing you to work faster in development while benefiting from the flexibility and scalability of microservices in production. This method means no more early architectural compromises; it's all about flexibility and making what you've already built even better.

Starting with Node.js, Expanding Quickly

Our initial focus is the Node.js ecosystem. You may say: "but Joel, the companies that really need to refactor are all in Java" and you would be 100% correct. JS/TS is simply the best place to start until we get community feedback on which languages are most important to you.

Our roadmap is focused on expansion into PHP, Python, C#, Java, and more. If there is a specific language you want to see first, please star us and contribute!

We have some additional features planned on the roadmap as well:

Auto-detect "dead" API endpoints that no longer see traffic.
Automatic flagging of bottlenecks within your APIs.
Codebase metrics for understanding legacy systems faster.
System-level interaction mapping between multiple services.
And much more!

Open Tooling for Devs, with Enterprise-level features for Architects and CTOs

We're committed to supporting developers with free, powerful tools while offering additional paid features tailored to solution architects and enterprise environments. By combining an open-core model with additional enterprise-ready features, we can maintain an ecosystem that's both accessible to individual developers and robust for larger organizations with more complex needs.

Going Fair-Source: Why Now?

We've spent two years fine-tuning this project, including gathering valuable feedback and honing in on exactly what developers need most. Based on this feedback we learned that developers really don't want a black-box auto-refactoring tool that works on their code without seeing how it works. (Fair warning to you, AI-based refactoring companies!)

Because of this, the time felt right to open up our code, share our work with the community, and let developers see what we're building. By going open-source, we're creating an ecosystem where everyone can contribute, improve, and shape this project to make it the best it can be.

A Bit About Us & Our Journey

Our team is driven by a vision to improve developer workflows and make large-scale application management easier for everyone. We're a fast-growing and multinational team of 3 going on 4.

🇺🇸 Joel is an American abroad; he's worked as a SWE in both enterprises and startups and seen all the technical debt companies struggle with around their APIs.
🏳️ Florian is our resident Frenchman. With a background in mechanical engineering, his switch to software brings unique insights into our approach.
🇳🇱 Justus is our business guy. Always direct, he keeps us on track by being our "Dutch Uncle".

We plan to continue expanding as we gain traction, and plan to start looking to fill DevRel, DevExp, and other roles in the very near future. If you think this could be you, the best way to get our attention is to join the community and interact with us.

Join Us and Follow Along!

⭐ Star the project on GitHub

Justus Goes Bald

We really want to build a strong community of developers and an amazing project, but Justus:

^ This guy. Doesn't believe we can get developers on board with our project. To prove it, he made a bet with the rest of the team: if NanoAPI gets 1,000 stars on Github in the first week of the project, he will shave his hair off and donate it to charity.

What do you think? Can we make him go bald? 👨🏻‍🦲

Give us a star to make it happen! → ⭐