DEV Community: CodeMonkeyG

An Agentic AI Investigation of Disputed Online Reviews

CodeMonkeyG — Thu, 15 Oct 2026 00:00:00 +0000

Publication note. This case study has been deliberately de-identified. The business sector, location, names, dates, quotations, amounts, and case-specific URLs have been removed or generalized. Certain event descriptions have also been simplified to reduce the possibility of identifying individuals through searching. The workflow and technical methods are authentic to the project; the details retained are those necessary to explain the system rather than the parties.

Executive summary

A local service business undergoing a management transition wanted to know whether several inherited negative online reviews might be fabricated, posted to the wrong location, or connected to competitors. The question looked like a straightforward web search. In practice, it required an investigation spanning conflicting narratives, multiple review platforms, public business information, platform moderation policies, unavailable primary sources, and missing private operational records.

We built a multi-agent research workflow rather than asking a language model to decide whether the reviews were fake. A coordinating agent developed a neutral investigation specification, delegated bounded work to specialist agents, evaluated their returns, and maintained an evidence trail. Browser and web-retrieval tools collected public information; Python performed reproducible text alignment; structured files linked claims to sources; and document-generation tools produced both a technical handoff and an owner-facing explanation.

The clearest result was a greater-than-90% similarity in the wording of two reviews published on different platforms. That showed substantial shared or derivative text, but did not prove a fabricated transaction, a common author, or a coordinated campaign. A narrow, conditional platform-policy question was identified. The other disputed experiences remained unverified without internal business records. No reviewers were contacted and no takedown requests were submitted.

The larger result was a repeatable approach to evidence-sensitive work: AI accelerated the investigation without being delegated the authority to decide what had happened.

1. Translating suspicion into testable questions

The initial business request was informal: could these negative reviews be fake? That framing carried an obvious risk of confirmation bias. The owner’s suspicion was a reason to investigate, not evidence supporting the conclusion.

We therefore separated three distinct questions:

Text provenance: Is the published narrative independently written, closely copied, or derived from another source?
Underlying event: Did a customer interaction occur, and are the factual allegations supported?
Platform rules: Does the review fall within a specific removable-content policy, regardless of whether the underlying event happened?

These are not interchangeable. A copied description can concern a real event. A genuine customer can make a factual mistake. A business can dispute a complaint without establishing a violation of a platform’s rules. The investigative specification required each case to state its evidence, its limitations, plausible alternatives, and its action threshold.

The final work products were defined at the outset: separate case assessments, a structured evidence register, a cross-platform comparison, a policy matrix, an action register, and an owner-facing report. Defining deliverables before delegating work made omissions and incomplete research more visible.

2. System architecture: coordinating agent and specialist workstreams

The project used a coordinator-worker architecture. The coordinating AI agent handled task planning, delegation, source reconciliation, interpretation, quality control, and final reporting. A first wave of specialist agents covered distinct review allegations, cross-platform history, and moderation/ownership context. Once more complete text became available, a second, narrower wave revisited the affected findings. Across the two waves, there were six specialist agent assignments; these were work assignments, not six independent confirmations.

The logical data flow was:

Human business question
        |
        v
Research specification and evidence standard
        |
        v
Coordinating AI agent
        |
        +--> Specialist: disputed service event ------+
        +--> Specialist: other disputed interaction --+--> Source/evidence register
        +--> Specialist: cross-platform text/history -+
        +--> Specialist: platform rules/context ------+
                                                      |
                          Human supplies fuller text  |
                                      |               v
                                      +--> Targeted second-pass agents
                                                      |
                                                      v
                                     Source reconciliation + Python analysis
                                                      |
                                                      v
                                Case findings + policy mapping + limitations
                                                      |
                                                      v
                                Owner report + technical evidence package
                                                      |
                                                      v
                                  Human authorization for any outside action

This was not a permanently deployed application with a unified database and custom APIs for every component. Coordination took place through structured agent instructions, browser results, files, and subsequent handoffs. That is still a meaningful agentic workflow: the system decomposed an objective, used external tools, examined the outputs, revised tasks, and assembled artifacts suitable for human decision-making.

A critical architectural distinction was that agent agreement did not count as corroboration. Several agents finding the same mirrored page still represented one underlying source. The coordinator was responsible for deduplicating evidence and evaluating provenance.

3. Integrating browser research and public sources

The first pass attempted to inspect the original online reviews on their publishing platforms. Those attempts encountered two types of access failure: a restricted map interface that omitted the relevant full reviews, and a review site that rejected page retrieval with an HTTP 403 response.

The access limitations changed what the system could claim. It had not obtained the complete platform originals, so it could not reliably establish edit history, exact publication metadata, account activity, or every word of the comments. Its first report should have made this limitation more prominent. When that weakness was challenged, the process explicitly acknowledged the missing originals rather than implying that an inaccessible expansion control had been used successfully.

The agents then searched lawful public alternatives: indexed search results, third-party review directories, public organizational information, general incident-record access routes, and official moderation-policy documentation. Searches used combinations of account information, business context, and distinctive concepts. They did not attempt to bypass access controls or access private accounts.

Each retrieved item was assigned an appropriate evidentiary role:

Source category	What it could establish	What it could not establish alone
Live platform capture	Displayed content and visible metadata at capture time	Truth of the event described
Human-supplied review extract	Exact content furnished to the investigation	Independent authenticity of the live page
Third-party mirror	Public circulation or listing association of text	Independent confirmation of the incident
Historical public comments	Context concerning prior operations	Personnel records or a particular transaction
Official platform policy	Relevant moderation rules and reporting process	Whether an individual review violates them
Authorized internal records, if supplied	Potentially stronger transaction or incident verification	Complete truth unless scope and completeness are evaluated

A failed public-record search was recorded as a non-result within the searched sources, not as proof that no underlying event occurred. An unsuccessful court query, for example, could not establish that litigation never existed. A generic mechanical advisory could not diagnose an unidentified vehicle.

4. Human evidence changed the research trajectory

After the initial handoff, a human participant supplied fuller review text and business responses. The investigation preserved these extracts as supplied and labeled them accordingly. They expanded the available evidence, but were not silently promoted to authenticated live-platform originals.

This new material enabled a second wave of targeted research and a direct comparison of two previously incomplete narratives. One agent revisited the disputed operational incidents; another investigated the overlapping cross-platform reviews and historical context. The coordinator checked the claims made in those returns before merging them into the assessment.

A public directory was found carrying text corresponding to some supplied complaints. After normalization, the circulated wording matched the supplied material. This supported the presence of the narratives in a listing associated with the business; it did not independently verify the reported customer events.

Historical customer comments and secondary organizational records likewise helped explain why different management periods might matter. They did not supply a verified personnel roster or a definitive transfer date. These boundaries were retained in the report.

This is a concrete example of human-in-the-loop correction: the human supplied missing evidence, the AI re-ran scoped tasks, and the results were updated without concealing the prior limitations.

5. Python-based text comparison

The most substantive computational task was comparing two reviews on different platforms that appeared to describe the same experience. Their narratives were extremely similar, but the perspective of the speaker changed in places.

The analysis isolated the two review bodies, normalized casing and apostrophes, tokenized words, and aligned the sequences with Python’s standard-library difflib.SequenceMatcher, using autojunk=False. This avoided relying on a model’s impression that two texts “looked copied.”

A simplified version of the method is:

import re
from difflib import SequenceMatcher


def tokenize(text: str) -> list[str]:
    normalized = text.lower().replace("’", "'")
    return re.findall(r"[a-z0-9]+(?:'[a-z0-9]+)?", normalized)


a = tokenize(review_a)
b = tokenize(review_b)
comparison = SequenceMatcher(None, a, b, autojunk=False)

print(f"word-sequence similarity: {comparison.ratio():.1%}")
# Result in this investigation: over 90%

SequenceMatcher.ratio() is defined as twice the number of aligned matching sequence elements divided by the combined sequence lengths. It is sensitive to order, unlike a simple overlap of word sets. The working investigation also preserved matching blocks and manually checked changed pronouns, unusual phrasing, and narrative order.

Interpretation was deliberately narrower than the number. The greater-than-90% score measured wording similarity in the supplied transcriptions. It was not a probability of deception or common authorship. Both reviews might derive from one genuine incident, a shared draft, a repost, or another explanation. Neither the code nor the source material established which account posted first.

The computational step added reproducibility; the interpretive step protected against overclaiming.

6. Mapping findings to platform policy

The project included a separate research track for official review policies and reporting procedures. That prevented a common reasoning error: treating anything suspicious, inaccurate, or unfair as automatically removable.

The paired text raised a qualified policy question on the platform where the review appeared to discuss another person’s experience. But possible direct involvement by the reviewer meant that an automatic conclusion would have been premature. The recommendation was limited to considering a narrowly documented policy inquiry after obtaining authenticated full captures and reviewing the complete context.

The other disputed reviews did not have sufficient evidence to justify reporting them as fake. The business’s own repair, diagnostic, correspondence, and other operational records would be needed to test the underlying factual allegations more rigorously. The research specification included searches that could accommodate alternate customer names, other payers, older record systems, and different operators.

No external action was automated. No reviewer was contacted, no public accusation was made, and no platform complaint was filed. Preparing a possible report and deciding to submit it were explicitly different stages, separated by human authorization.

7. Evidence management, artifacts, and quality control

The process produced more than a chat response. It generated an agent-facing research specification, case-level handoffs, a machine-readable evidence register, an annotated cross-platform comparison, a policy/action matrix, draft owner reports, and packaged supporting files.

A structured evidence item connected an observation to a case identifier, source location, collection time, source type, supporting attachment, and limitation. This made it possible to distinguish between what agents found, what the human participant supplied, and what remained inferential.

Quality control included re-running the text comparison, checking preserved extracts, reviewing references and attachment paths, and testing archive readability. The supporting agent reported an evidence register with unique entries and verified links to the cases. During a later packaging handoff, a different visible CSV snapshot had a smaller record count. That discrepancy reinforces the need to version and reconcile artifact inventories rather than treating a count in a summary as automatically authoritative.

These checks establish internal consistency and traceability, not factual truth. A valid archive does not authenticate the reviews inside it; a precise similarity score does not resolve the customer transaction; and a citation confirms source attribution, not necessarily source accuracy.

The reporting stage also used AI to adapt one evidence base for different readers: technical handoff documents for investigators, a more formal decision report, and a direct, accessible explanation for the nontechnical business owner. The underlying conclusions remained the same even as the tone and structure changed.

8. What AI handled, and what remained with people

AI- and tool-assisted	Human or authorized-record responsibility
Task decomposition and specialist-agent delegation	Define the objective and permitted investigation scope
Public searching, browsing, source discovery, and policy retrieval	Supply unavailable material and approve any private-record access
Text normalization, alignment, and reproducible comparison	Interpret authorship and real-world involvement
Evidence register, case files, and report generation	Review consequential statements and legal/privacy implications
Citation, attachment, and archive checks	Decide whether and when to pursue external platform action

The separation was intentional. The value was not that the AI replaced an investigator or arbitrator. The value was that it performed much of the expensive organizational and analytical work while leaving sensitive access and consequential decisions with people.

9. What worked, what failed, and what changed

What worked: bounded delegation accelerated research; a neutral specification reduced confirmation bias; deterministic Python analysis made one important finding reproducible; and structured evidence artifacts enabled handoffs between agents, technical reviewers, and the business owner.

What failed initially: limitations in accessing the full primary-source reviews were not conspicuous enough in the initial presentation. That made the first report easier to overinterpret than it should have been. The subsequent user challenge revealed the problem.

What changed: fuller human-supplied extracts triggered a second agent wave. The research moved from a suspected textual relationship to a measured one, while maintaining the distinction between shared words and a genuine or fabricated experience.

What remained unresolved: direct authentication of the platform originals, complete reviewer histories, the underlying customer transactions, and some historical organizational details. These limitations were not repaired by adding more prose or more agents.

10. A reusable pattern for novel business workflows

The approach can generalize to vendor diligence, incident review, contract compliance, warranty disputes, customer escalations, procurement research, and other evidence-sensitive tasks.

A practical reusable design has six layers:

Specification: define claims, evidence standards, scope, output requirements, and prohibited actions.
Orchestration: decompose work into bounded specialist assignments and set rules for reconciling results.
Retrieval: use appropriate public or authorized data sources and preserve access failures.
Processing: normalize content, apply deterministic analysis when useful, and maintain provenance.
Validation: test alternative explanations, check artifacts, and map findings to decision thresholds.
Delivery and authorization: produce audience-specific reports and require human approval before consequential actions.

This is a more useful mental model than “adding AI” to a business process. It treats AI as part of an operating workflow, with explicit interfaces between probabilistic reasoning, deterministic tools, external information, and human accountability.

Conclusion

A request to investigate online reviews became a small but substantial exercise in agentic system design. Multiple agents researched bounded problems; browser tools exposed real access constraints; public sources supplied partial corroboration; human-provided evidence corrected the initial analysis; Python quantified an important textual relationship; and structured artifacts carried the evidence into a decision report.

The investigation did not prove that the reviews were fabricated. It established a narrower technical finding, identified a limited policy question, and documented precisely what would be required to go further.

That is the central lesson: effective AI integration is not about producing a confident answer to every question. It is about designing a workflow that can make useful progress, show its evidence, admit its limits, and stop before claiming authority it does not possess.

Learning Python After PHP

CodeMonkeyG — Sat, 10 Oct 2026 00:00:00 +0000

PHP is still one of the best answers to a very specific question: how do we get useful web software into production without making every decision from first principles? It has earned its place there. Modern PHP, especially with a framework like Laravel, offers a practical path from a request to a secure, testable application without requiring a team to invent an entire platform along the way.

But learning Python after spending years in the PHP world has been a useful reminder that a language can feel familiar while changing the shape of the problems you reach for.

The Difference Is Not Just Syntax

Python is not magic, and I am not interested in pretending it is. The things that make software durable still matter: clear boundaries, explicit failure handling, tests, useful logging, and an understanding of what happens after code leaves a laptop.

What has been interesting is how quickly Python gets out of the way once the problem is not fundamentally a web page. Data transformation, system integration, file processing, lightweight operational tools, and automation all feel close at hand. A script can start as a focused utility and grow into part of a repeatable workflow without demanding much ceremony.

That makes it easy to see the division of labor that has emerged over time. PHP was chosen for the web because it makes the web approachable. Python has been chosen for so much else because it makes a broad range of technical work approachable.

FastAPI Makes an Excellent First Stop

Most of my recent experimentation has been with FastAPI. It is a good fit for someone who already thinks in terms of endpoints, validation, authorization, and service boundaries. The familiarity is there, but the ergonomics are different.

Type hints are a good example. In PHP, modern typing has become a meaningful part of writing maintainable code. In FastAPI, type information also directly shapes request validation, serialization, API documentation, and the development experience. A well-defined model does more than communicate intent to the next engineer; it helps the framework enforce the contract at the edge.

That does not mean every API should be split into a standalone Python service. It means Python gives me another credible option when an API needs to sit near a data workflow, an automation process, or a computational task.

Scripts Become Workflow Building Blocks

The bigger draw has been using Python scripts to create workflow pipelines. A small script can collect inputs, normalize them, call an external service, generate an artifact, and hand off a clean result to the next step. Once those pieces are explicit, they can be scheduled, retried, observed, and composed.

That is useful far beyond “automation” as a vague buzzword. It is a way to remove repeated manual work while making the work easier to inspect. A pipeline should not just save time; it should make failures visible and leave a trail that explains what happened.

Python has a mature ecosystem for this kind of work, but the ecosystem is only part of the story. The language encourages small, legible tools. That is a productive default when the goal is to connect systems rather than build a large application for its own sake.

Learning in the Age of AI Requires Some Friction

There is one complication to learning a new language now: every editor wants to write it for you.

Inline AI suggestions are useful when you already understand the language and are trying to move through familiar work faster. They are much less useful when the point is to build a mental model. If an IDE keeps offering the entire block, it is easy to accept code that looks reasonable before you understand its imports, control flow, error behavior, or idioms.

My recommendation is simple: turn off inline suggestions right away when learning something new. Keep an AI assistant available for questions, explanations, code review, or a second opinion, but create enough space to struggle through the first version yourself. That small amount of friction is where the syntax becomes instinct, the standard library becomes discoverable, and the trade-offs become visible.

Later, turn the suggestions back on. By then, they will accelerate your work instead of substituting for the learning.

A Broader Toolbox

Learning Python has not made me less interested in PHP or in well-structured monoliths. It has made the toolbox clearer. PHP remains an excellent choice when the job is a web application that needs to become useful quickly and stay understandable as it grows.

Python is compelling when the job extends beyond the request-response cycle: building an API around a data process, orchestrating a workflow, investigating a pile of documents, or writing the small piece of software that removes an entire category of manual work.

The joy of moving into a new language is not discovering that the old one was wrong. It is recognizing more clearly which tool belongs in which hand.

Learning React After Vue

CodeMonkeyG — Thu, 08 Oct 2026 00:00:00 +0000

Vue is one of the easiest frameworks to recommend to someone who wants to build an interface without first absorbing an entire ecosystem. Its templates read naturally, its conventions are clear, and the path from a simple component to a working application is remarkably direct.

Coming from Vue, React feels more open-ended. That is both its cost and its advantage.

Vue Makes the First Steps Clear

Vue gives developers a well-lit path. Templates, reactive state, computed values, and component conventions fit together in a way that is easy to explain and easy to revisit after time away from a project. For teams that want a productive, coherent front-end framework, that clarity is a real strength.

React asks for more decisions. JSX blends markup and behavior. State management can range from a few hooks to a broader application architecture. Routing, data fetching, form handling, and build tooling all have strong options, but not always one officially prescribed answer.

That can feel like unnecessary complexity until the application has to fit into a larger organization.

Why React Remains King

React has remained the industry standard not because it is always the simplest option, but because its ecosystem solves an enormous range of real production problems.

The talent pool is deep. The component ecosystem is mature. Documentation, examples, integrations, and experienced opinions are plentiful. When an application needs to connect to an established design system, analytics platform, API client, authentication provider, or testing tool, there is usually a well-traveled React path already available.

That matters to businesses. A framework decision is not only about how fast one developer can create a component today. It is also about hiring, onboarding, support, long-term maintenance, and the probability that the next team can understand the codebase without starting from scratch.

React's flexibility also works well when a front end has to grow beyond a single interface. It can support a focused embedded widget, a full application, server-rendered experiences, and shared component libraries. The same fundamentals travel across all of them.

The Shift in Mental Model

The most useful transition from Vue to React is not memorizing hook signatures. It is getting comfortable with rendering as a function of state.

In Vue, the framework's reactivity system handles much of the connection between changing data and changing markup in a very approachable way. In React, it is worth being deliberate about what state belongs where, what should be derived rather than stored, and how component boundaries communicate.

Those questions exist in every framework. React simply makes them harder to ignore. That can be a benefit. A team that is clear about state ownership and component responsibilities tends to produce interfaces that are easier to evolve.

Vue Is Not the Wrong Choice

None of this makes Vue a lesser framework. Vue remains an excellent choice for teams that value its conventions, for products where its development experience is a natural fit, and for developers who want to move quickly without losing structure.

The better question is not which framework wins every comparison. It is which ecosystem best supports the product, the team, and the work that comes next.

For many organizations, React wins that question because it has become the common language of front-end hiring and tooling. Learning it is therefore less about following a trend and more about being able to operate comfortably in the broadest part of the web-development market.

The Next Step: React Native

One reason React is especially worth learning is that it creates a credible path toward React Native. The rendering primitives change, and mobile development introduces its own concerns around navigation, devices, deployment, and platform behavior. But the component model, state-management instincts, and much of the development workflow carry forward.

That does not mean web developers can treat mobile applications as a free byproduct. Good mobile software deserves the same attention to user experience, performance, accessibility, and operational support as any other product. It does mean React provides a practical bridge: learn the core model on the web, then apply that foundation to native mobile work when the problem calls for it.

Vue made it easy to get productive in component-based development. React is making the wider ecosystem easier to navigate. Both are useful tools; React is simply the one that opens the most doors right now.

The Shape of a Career

CodeMonkeyG — Sat, 26 Sep 2026 00:00:00 +0000

With a birthday approaching and one long professional chapter recently closed, I have been thinking less about what a career looks like on paper and more about the shape it takes while you are living it.

Résumés prefer straight lines. They turn years into dates, responsibilities into bullets, and hard decisions into tidy transitions. That is useful. A résumé needs to make sense quickly to someone who was not there. But it cannot capture the detours: the project that taught you something your title did not, the customer conversation that changed how you design systems, or the role that looked temporary and became foundational.

Looking back, my own path has not been especially straight. I started by building custom applications and commerce systems for a wide range of clients. That work required wearing every hat before I had names for most of them: discovery, design, development, deployment, support, and the uncomfortable but necessary work of explaining trade-offs to people who did not care what framework I preferred.

Later came security products, public-sector modernization, enterprise identity, and eventually hospitality technology. On a spreadsheet, that can look like a collection of unrelated industries. In practice, the work kept returning to the same questions: What is the real problem? Which system actually owns the data? Where does the handoff fail? What has to be true for a solution to survive contact with production and the people who depend on it?

Detours Build a Different Kind of Depth

At different points, I have been asked to make an interface usable, stabilize an integration, enter an unfamiliar codebase, build a demonstration that could survive serious questions, or turn an operational process into software. None of those tasks were interchangeable. Together, they built a way of working.

That is the advantage of a career that does not follow a perfectly prescribed track. You begin to see patterns that are hard to learn from one specialty alone. A technical issue is often a communication issue in disguise. A customer request may be a data-model problem. A beautiful architecture that nobody can deploy or support is not complete. A quick fix without a clear operating model becomes tomorrow's incident.

The deeper lesson is not that every detour is good. Some are expensive. Some teach the same lesson twice because we were not ready to learn it the first time. But a route that looks inefficient from far away can still produce judgment, range, and resilience. Those are not always the easiest strengths to list, but they are often the ones that matter when the requirements are ambiguous and the stakes are real.

What a Decade of Ownership Clarifies

The most recent chapter lasted long enough to make that idea concrete. Building and operating a hospitality platform from its earliest days meant living with the full arc of technical work: discovery sessions, proofs of concept, executive demonstrations, integrations with legacy systems, production incidents, performance constraints, and the quiet maintenance work that keeps a product trustworthy.

It also meant learning that ownership is not the same as control. A founding engineer can build a great deal, but no one person owns the market, the company, the timing, or every decision that shapes the next phase. There is a particular kind of honesty required when a long partnership comes to an end. You can acknowledge what was built, be grateful for the people and problems that made you better, and still recognize that it is time to move on.

Leaving a company after years of shared effort is not a clean subtraction. There is loss in it, even when the separation is the right one. There is also room. The end of a role removes familiar responsibilities, but it can return questions that routine had pushed aside: What do I want to learn now? Which problems do I want to solve? What kind of team and product deserve the next stretch of attention?

The Value of Not Being Easily Reduced

There is a Chinese proverb that says, “A crooked tree lives its own life, while a straight tree is turned into wood.” I have found that image useful lately, not as an argument against being useful, but as a reminder that usefulness is bigger than fitting neatly into one narrow category.

The career version of that idea is not to become difficult for its own sake. It is to resist becoming so optimized for one job that you cannot recognize the next one. The ability to move between customer conversations and code, architecture and operations, legacy constraints and new tools has sometimes made for a less conventional title. It has also made it possible to contribute where the boundary lines are unclear.

That range is why I still care about a pragmatic monolith when it is the right starting point, and why I am spending time with Python, FastAPI, workflow pipelines, and React rather than treating the tools that built the last decade as the only tools worth knowing. Technologies change. The underlying habit is more durable: understand the work in front of you, choose the simplest reliable path, and keep learning before the environment forces you to.

Carrying the Right Things Forward

As this birthday gets closer, I am less interested in making a case for a single, polished career narrative. I am more interested in taking inventory.

I want to carry forward the patience required to understand complicated systems, the confidence to speak plainly with customers and executives, and the humility to investigate before declaring a solution. I want to keep building things that reduce real friction for people doing real work. I want to continue learning languages and frameworks without confusing novelty for progress.

Most of all, I want to keep enough of the irregular shape that got me here. Not every useful life or career is built in a straight line. Sometimes the bends are evidence of adaptation. Sometimes they are where the most interesting work begins.

The next chapter does not need to erase the previous one to be meaningful. It only needs to make honest use of what came before.

Why I Still Start With Monoliths

CodeMonkeyG — Tue, 22 Sep 2026 00:00:00 +0000

Nowadays, everyone with access to AI can build an app. Which is basically everyone at this point. But what happens when your brilliant idea that you vibe coded in a couple of hours needs to get deployed? How will you handle real network traffic? How will you make sure things are secure? This is where an actual software engineer has to step in and take over.

When it's my turn to start a new project, sure, I prompt along with the rest but if it's more than just a couple of scripts, I always set the start point as a monolith.

I understand that it is a controversial opinion in a world where everything is about micro services and moving as quickly as possible. However, I argue that if the goal is to build something useful as quickly as possible that the monolith will get you there first and much more securely than a mesh of microservices that each require its own management, deployment, and maintenance.

When Microservices Make Sense

Microservices still have a place. If you look around at what the big tech companies are doing you will see that if they haven't already moved to a microservices-based architecture, it is likely because they are still in the process of doing so or because they tried it, got burned by the complexity, and pulled back toward something more modular but still unified. Startups and big companies aren't optimizing for the same thing, and pretending they are is how people get into trouble.

How The Monolith Wins

But just as Alphabet and Meta got their start, when the team is small (or even just one person) the monolith lets everyone work and test together with a much smaller iteration cycle. While the most time consuming part may be to make sure your local repository is up to date, you also don't have to worry about multiple repositories, multiple orchestrations with environments or containers. You don't even have to wait for someone else to fix a bug that is blocking you because everything is in the monolith and you can go fix the bug yourself. The monolith provides the grounding point that allows the team to explore and move quickly.

As an example, my current go-to is Laravel. One battle tested and hardened framework with the support of an entire community of software engineers and the backing from businesses that depend on it. One framework providing all the authentication, authorization, database modeling, API endpoints, front-end interface, testing harness, etc. It's all there when you take the monolith out of the box. This means a team from one to many can get to work on their idea right away and know that they are standing on the shoulders of giants. They can focus on building their best airplane instead of having to discover flight all over again.

As the project scales the monolith is deployed to a group of auto-scaling servers. Each server handles whole transactions and network requests. As more machines are added, the monolith is duplicated in its entirety so newly added machines can handle more network traffic without needing autoscaling configurations for various services within your application, leading to dev-ops complexity. That simplicity has limits, though. The trade-off is that you can't split the load the way a microservice mesh can: if a single hot endpoint starts eating resources, you still have to put the whole thing on bigger machines. That's fine until it isn't. And when it stops being fine, you'll know, because the pain will be concrete instead of hypothetical.

What a Monolith Leaves on the Table

Of course, as with anything in software, there is a cost to every decision. In order to reap the benefits of building with a monolith you will be giving up some other things. One thing you will have to set aside for later is the hyper-optimization of various services within the app. When you deploy the monolith to a new server you deploy the whole thing. This means, for example, if the CRUD endpoints for "user_comments" are getting hammered and eating up system resources you can't deploy new machines just big enough for just the "user_comments". You have to deploy on machines big enough to support the whole monolith. Something else you may leave on the table is easily swapping small modules when a new framework or piece of tech is available. With a monolith, you have to commit. Lean in to what you have until you have something that generates enough financial or human resources on its own that you can decide later to update, upgrade, or carve up the monolith into its respective microservices.

The flip side of all that commitment is that the boundaries between pieces of your code get blurry over time. A change in one place can have effects somewhere else, and the person who wrote the original feature may not be around to know which wire you're about to cross. That's the part people often forget when they talk about monoliths being "easy". Easy to deploy, yes, but the mental model of the whole thing has to fit in one team's head, and that only works up to a point. When it stops working, you'll feel it as a slowdown in how fast you can move without breaking something. That slowdown is the real signal that it's time to think about carving things apart.

Where Can You Deploy the Monolith

One of the advantages of the monolith is also deploy-ability. Because it is all one single asset to be deployed, you can choose. Do you want to run on the bare metal of the machine? No big deal since the machine doesn't have anything else to worry about, you can install all necessary dependencies, update the code on the machine and sudo service start. Feel like you would prefer to take advantage of containerization? That's just as easy, because the same run list applies to your containers and now you have a deploy-able package you can take to any server. No large orchestration required. A microservice might be a single container too, but with a monolith there's only one of them to worry about instead of a whole mesh.

Who Cares?

Anybody getting started on a new project. If it's an internal project for your company that has any chance of being spun off into a standalone tool or product. Frankly, in my experience the monolith has served me well. I have been part of several successful start-ups using monoliths (including one I built the tech for from the ground up). If you are looking to get serious and you are looking to actually push for real growth, nothing beats the maintainability, stability, and flexibility of the monolith.

Launching the CodeMonkeyG Tech Blog

CodeMonkeyG — Fri, 18 Sep 2026 00:00:00 +0000

Welcome to the CodeMonkeyG blog!

For years, my web home at codemonkeyg.com has served as an interactive resume and showcase of my work as a Systems Architect and Founding Engineer. But as systems grow and architectures evolve, having a dedicated space to write in-depth technical breakdowns, share architectural post-mortems, and document hard-earned lessons has become essential. So I spun up codemonkeyg.com/blog It will also be place where I share some life philosophies that I feel influence the way I do what I do.

Why Astro for Markdown Blogging?

When deciding how to build this blog, I evaluated several static site generators and frameworks. I chose Astro for several key reasons:

Zero-JS by Default: Astro renders pure HTML/CSS by default. For content-heavy technical blogs, this yields unbeatable lighthouse scores, sub-second load times, and minimal resource usage.
First-Class Markdown & Content Collections: Content collections provide strict TypeScript type safety for Markdown frontmatter at compile time, eliminating broken links or malformed metadata.
Seamless Design Integration: By utilizing Tailwind CSS configured with the same color palette as the main CodeMonkeyG resume (#0099ff, #ff9900, and #181818), the blog feels like an organic extension of the primary site.
Clean Subpath Routing: With Astro's base: '/blog' configuration, the blog lives cleanly under the /blog subdirectory.

This lines up with my philosophy of using the right tools for the right job. With Astro I can connect to my server and write an article as markdown file. No need for whole admin panel. I can keep everything versioned in a git repository and back it up as easy as git push.

While it may not be a tool for everyone, it was the right one for me to set up this blog.

Docker Architecture

Just like the main CodeMonkeyG site, the Astro blog runs inside Docker. An Nginx reverse proxy terminates SSL on the frontend and handles upstream traffic delegation:

Root / → Served by containerized Nginx.
Subpath /blog → Reverse-proxied to the Astro container running on port 4321.

"Simplicity is prerequisite for reliability." - Edsger W. Dijkstra

What to Expect Next

Upcoming articles will dive into:

Architectural patterns for high-concurrency systems
Docker and container orchestration strategies
Practical database optimization and caching layers
Modernizing legacy enterprise software

Stay tuned, and feel free to reach out via LinkedIn or GitHub