DEV Community: CodeMonkeyG

Did the AI Bubble Just Pop?

CodeMonkeyG — Wed, 28 Oct 2026 00:00:00 +0000

For a few weeks, the AI trade looked unstoppable. SpaceX jumped 7% in a day, tech executives demanded another hundred billion dollars for data centers, and Nvidia kept describing AI chip demand as insatiable. Then the market turned. CoreWeave, the former crypto mining company that became a major GPU rental business, fell to about a third of its value from the start of the month.

The financing behind the boom is even stranger. Nvidia invests in companies that buy Nvidia GPUs. Those companies borrow more money using the chips as collateral, then rent the hardware back into the same ecosystem. Wall Street calls this circular financing. In plainer English, it is a circle jerk with billions of dollars in debt. Everyone gets to report growth as long as nobody asks where the actual outside revenue is coming from.

That is the problem facing the so-called neocloud companies. They are built around AI workloads, expensive hardware, and borrowed money. Elon Musk reportedly warned that more than 200 of them could fail. CoreWeave's reported $52 billion debt, combined with interest rates near 15%, makes that warning feel less like internet drama and more like basic arithmetic.

Anthropic's proposed public offering adds another layer of absurdity. The company is reportedly seeking a $100 billion valuation while carrying enormous losses and depending on infrastructure providers to keep supplying its computing power. Its filing also discusses models that may improve themselves faster than the company can fully understand. That is a remarkable risk disclosure for a company asking investors to believe in unlimited growth.

The technology is real, but that does not make every company built around it a good business. The internet was real too, and plenty of dot-com companies still deserved to disappear. AI developers are already benefiting from cheaper tokens, better open models, and a brutal fight between providers. A market correction could make hardware cheaper and force investors to care about customers instead of spending plans.

I would like to see the bubble pop, or at least lose enough air for the market to find equilibrium. AI would survive. The useful companies would survive. Maybe then a GPU could go back to being a piece of equipment instead of a financial instrument.

The Work Before the Work

CodeMonkeyG — Mon, 26 Oct 2026 00:00:00 +0000

Getting into painting cars has reminded me that the visible part of a project is often the smallest part of the process. Before paint touches the surface, there is cleaning, sanding, repairing, masking, priming, and inspecting. Each step affects the next one. If the surface is not prepared properly, a better gun, more expensive paint, or extra coats will not solve the underlying problem. The finish reflects the care taken before the finish was visible.

That connection made me think about how we work with AI agents. A complex task also needs preparation before execution begins. The agent needs to understand the objective, the current condition of the project, the available tools, the constraints, and what a successful result actually means. A vague prompt is like painting over dirt or rust. It may produce something that looks finished at first, but the flaws remain underneath and become more difficult to correct later.

My mind tends to move between subjects and notice relationships that may not be obvious at first. Painting a car and designing an agent workflow seem unrelated, but the underlying principle is universal: good results come from respecting the process. You prepare the surface, choose the right materials, apply each layer carefully, allow time for it to set, and inspect the work before continuing. With an agent, that means gathering context, breaking down the task, setting boundaries, reviewing intermediate results, and verifying the final output instead of assuming that completion means correctness.

The lesson is not that every task needs unnecessary complexity. It is that care should be applied where it matters. Preparation creates a reliable foundation, and deliberate execution protects the work built on top of it. Whether I am trying to achieve a clean automotive finish or asking an agent to solve a difficult problem, the goal is the same: do not rush past the steps that make quality possible. Surface-level effort can produce activity, but thoughtful preparation is what gives the result a chance to be as good as it can be.

Grateful for the Road That Led Here

CodeMonkeyG — Sun, 25 Oct 2026 00:00:00 +0000

I recently had the chance to speak with Jeff Magloire and Daniel Cai about my experience building integrations, working with product teams, and solving problems inside complicated production environments. They are researching ProductOS, a tool intended to help connect customer needs, product decisions, engineering work, documentation, and delivery.

I want to start by saying thank you.

Thank you for reaching out. Thank you for taking the time to listen. Thank you for asking questions that made me think about work I have been doing for years, often without having a clear name for it.

I went into the conversation expecting to talk about integrations. I did not expect to come away feeling so grateful for the road that brought me there.

A conversation that made me look back

It is easy to describe a career after the fact as if it were a plan. Mine was not.

I started by building custom applications and working with clients who needed something made, fixed, or explained. I learned by taking on work that was sometimes bigger than my experience at the time. I worked across different companies, products, and industries. I spent years building a hospitality platform from the ground up, working closely with a founder, customers, vendors, executives, and engineers.

Much of that work happened before I knew the term forward deployed engineer. I was doing discovery, building proofs of concept, explaining technical decisions, connecting systems, helping close deals, deploying software, and supporting it after the launch. I was often the person standing between what a customer needed and what the systems could actually do.

The title came later. The work came first.

The interview helped me see that more clearly. When I talked about legacy systems, undocumented APIs, version differences, production failures, and the slow process of finding the truth inside an unfamiliar environment, I was also describing the education my career gave me.

It was not a formal education. A lot of it had to be built on my own.

What it took to get here

There were many years when I had to figure things out without a clear path or a person standing over my shoulder to show me what to do next. I had to learn how to build companies, find customers, make promises carefully, deliver what I promised, and keep going when the work became more difficult than expected.

I had to learn technologies because a customer needed a solution, not because a course had been prepared for me. I had to understand systems by reading incomplete documentation, testing boundaries, looking at code, and asking questions that sometimes exposed how little anyone knew about the system as a whole.

There were times when doing it on my own felt empowering. There were other times when it was simply hard. Building something from the ground up can be lonely, especially when the people around you only see the finished product and not the years of uncertainty underneath it.

Still, that experience shaped me.

It taught me to be resourceful without pretending to know everything. It taught me to keep investigating when the answer was not obvious. It taught me that a working system is more than code. It has to make sense to the people using it, survive contact with production, and remain understandable when someone else has to support it.

Those lessons came from many places. Some came from success. Some came from mistakes. Some came from projects that took far longer than expected. Some came from having no choice but to learn the next thing and keep moving.

I am grateful for all of it, even the parts I would not choose to repeat.

What we talked about

During the interview, we talked about the friction that appears when engineers, architects, product managers, and business leaders each work from a different understanding of the same project.

We talked about technical documentation and the difficulty of integrating with systems that have been running for years. Sometimes the documentation is incomplete. Sometimes it describes another version. Sometimes the people who built the system are no longer available to explain why it behaves the way it does.

In those situations, the work becomes a form of investigation. You gather what exists, test what you can, compare the behavior against the written specifications, and build a clearer picture one piece at a time.

We also talked about AI agents and the work they may be able to take on. An agent can research documentation, compare products, organize notes, prepare an executive summary, or suggest priorities. That can remove a great deal of repetitive work.

It cannot remove responsibility.

The person who understands the customer, the company, the risks, and the consequences still has to make the final decision. That is the part I care about. I am interested in using AI to prepare better information, not in handing over judgment simply because the result looks polished.

The best version of that workflow is still human. The agent does the heavy preparation. The person reviews it, corrects it, adds context, and decides what happens next.

Thank you for reminding me

What stayed with me after the call was not one particular product idea. It was the feeling of being seen for work I had sometimes treated as ordinary because I had been doing it for so long.

I have spent years connecting systems and people. I have translated customer problems into technical work, then translated technical limitations back into language that a customer or executive could use. I have entered unfamiliar codebases, built demonstrations, worked through production incidents, and tried to leave systems better documented than I found them.

Those things do not always fit neatly into a job title. They are easy to overlook when you are busy doing them. Being asked about them made me stop and recognize how much experience had accumulated over time.

That recognition came at a meaningful point in my life. After leaving a long professional chapter, I have been rebuilding my sense of direction. I have been learning again, experimenting with new tools, preparing for interviews, and thinking about what I want the next part of my career to look like.

The conversation gave me a little of my fire back.

Not because it confirmed that I have everything figured out. I do not. It helped because it reminded me that I have already done difficult work without having everything figured out. I have learned before. I have built before. I have found a way through problems that looked unreasonable at the beginning.

I can do that again.

Carrying the gratitude forward

I am grateful to Jeff and Daniel for the invitation and for the thoughtful conversation. I am grateful for the opportunity to explain what I have learned, but I am even more grateful for the chance to remember where those lessons came from.

They came from customers who trusted me with important problems. They came from teammates, founders, and engineers who challenged my assumptions. They came from long nights, difficult decisions, failed approaches, and the next morning when the work still had to continue.

They also came from having to do a lot of it on my own.

That independence was not always easy, but it gave me a kind of confidence that no title can provide. I know how to start with an unclear problem. I know how to learn the system in front of me. I know how to build a first version, listen to the people using it, and keep improving it.

That is what I want to carry into the next chapter: gratitude for the experience, humility about what I still need to learn, and the willingness to build again.

For more background, see The Shape of a Career, Learning Python After PHP, and my forward deployed engineering resume. I also share shorter reflections on LinkedIn.

Finding the Opportunity After the AI Workshop

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

I did not attend the workshop because I needed someone to teach me how to use AI. I attended because I wanted to understand how people with less technical experience were being introduced to it.

What I saw clarified the opportunity in front of me: many people do not need another tool. They need someone who can help them turn AI into something useful in their actual lives.

That realization connected the session to the work I have already done, the business I am building, and the kind of work I want to do next.

The insight was not the template

The session introduced beginners to agent templates they could adapt without starting from a blank screen. That is a sensible way to lower the barrier to entry. I would probably choose a different path. After years of building companies, software, and integrations, I want to understand what is happening underneath the result.

That difference helped me see the audience more clearly. Many capable people are interested in AI but do not know how to connect it to their actual work. They do not need to become programmers. They need help identifying a useful problem, choosing a reasonable starting point, and knowing where human judgment still belongs.

I left thinking less about the template and more about the person who needs help deciding what the agent should do.

Experience changes how I see AI

I have spent much of my career translating between business needs and technical reality. I see AI as more than prompts and new tools. I see workflows, handoffs, scattered information, and hours lost to tasks that could be organized or automated.

I also see the limits. An agent can draft, summarize, research, or prepare a plan. It cannot decide whether the workflow is worth building, understand every consequence, or take responsibility for the outcome. Someone still has to ask good questions, check the result, and make sure the system fits the way people work.

That is where my experience can help. I want to help people find one real problem, build a practical first version, and learn what the system can and cannot do before adding more complexity.

From ideas to useful work

My next step is to turn the automated workflows I have already been developing into clear demonstrations. A potential client should be able to see what a workflow does, what information it uses, where a person remains involved, and how it improves the work.

I also want to test a practical community session where people can bring ordinary problems and explore how AI or automation might fit into their lives. Those problems might involve small-business operations, marketing, personal financial organization, or life planning. The method stays the same: listen first, understand the work, and build only what helps.

A good solution may be modest. It could be better lead follow-up, a system that turns scattered notes into a plan, or an assistant that prepares information for a decision without making the decision itself.

A familiar kind of work

This feels like forward deployed engineering applied beyond traditional software teams. The work begins close to the person using the system. You understand the environment, build something that fits, and stay involved long enough to see whether it helps.

That is familiar territory for me. The difference is that modern tools are becoming accessible to people who would never have built a traditional software system for themselves. My role can be to translate their frustration into a workable process, then help them use it with confidence.

The value is not determined by how impressive the technology sounds. It is determined by whether the person's day becomes easier or more effective.

The opportunity requires action

I left the session hopeful and excited about the future, but enthusiasm is only the beginning. The real work is choosing one idea, building it, testing it with real people, and changing it when the first version is not good enough.

I do not need to pretend that I am starting from zero. I also cannot assume that experience alone is enough. I still have to listen, build, test, and earn trust one result at a time.

That is the opportunity I see now. AI may give me more leverage, but the meaningful part is still human: understanding what matters to someone and helping make it better.

For examples of how I have been exploring this already, see Building an AI-Assisted Carousel Pipeline and An Agentic AI Investigation of Disputed Online Reviews. Those projects taught me that AI becomes more useful when it is placed inside a workflow with clear boundaries, human review, and a result that someone can actually use.

How Stacked Convertible Notes Can Eliminate Common-Stock Proceeds in an Acquisition

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

General information only. This article describes common financing mechanics and an illustrative acquisition waterfall. Actual outcomes depend on the company's charter, financing documents, debt agreements, applicable law, taxes, and transaction terms. It is not legal, tax, or investment advice. A stockholder considering an inspection demand or transaction should consult qualified counsel.

Multiple rounds of convertible notes without a priced equity round can create a substantial liquidation overhang: claims that must be resolved before common stock participates in an acquisition. In a modest exit, the acquisition headline can look healthy while the amount available to common stockholders is small or zero.

The result is not automatic. It depends on the precise note agreements, capitalization, senior debt, liquidation-preference terms, and merger agreement. But the mechanics are straightforward enough that every stockholder should understand the waterfall.

1. Unconverted notes may sit ahead of equity

A convertible note begins as debt. If an acquisition occurs before a qualifying financing causes conversion, the note agreement generally determines whether the holder is repaid, converts into shares, or may choose between those outcomes.

Where repayment applies, principal and accrued interest are claims that must be satisfied from transaction consideration before distributions to equity holders. Existing secured debt, transaction expenses, taxes, and other liabilities may rank ahead as well. Preferred and common stockholders do not share in the residual until those obligations are resolved.

This is why the label "convertible" should not obscure the underlying risk: until conversion, a note can function as a senior claim on exit proceeds.

2. Change-of-control provisions can increase the claim

Convertible-note agreements commonly include a change-of-control provision for an acquisition before a qualified financing. The exact language varies, but it may give the holder a choice between:

repayment of outstanding principal plus interest, sometimes with a premium or multiple;
conversion immediately before closing at a discount, valuation cap, or other formula; or
another contractually defined treatment.

A multiple has a direct effect on the waterfall. For example, $5 million of principal subject to a 2.0x cash payout would require $10 million of consideration before the remaining distribution is shared with equity holders, subject to the agreement and any senior claims. That is very different from a conversion that turns the noteholder into an equity participant.

The governing documents, not an assumed market norm, control. A cap, discount, maturity date, interest rate, and change-of-control election should all be reviewed together.

3. Interest adds to the overhang over time

Notes usually accrue interest until they are repaid or converted. The longer a company delays a priced financing or exit, the greater the repayment amount may become.

As a simplified example, $3 million accruing simple interest at 7% annually reaches approximately $4.05 million after five years and $4.26 million after six years, before any change-of-control premium. Whether interest compounds, converts, or is paid in cash depends on the note.

An illustrative acquisition waterfall

Assume a company completed a $2.4 million seed preferred round and later issued $6 million of convertible notes. The following example assumes the notes are repaid for $7.5 million including accrued interest, the seed investors receive a $2.4 million non-participating liquidation preference, and there are no other senior claims beyond those shown.

Step	Distribution	Remaining proceeds
Acquisition sale price	$15,000,000	$15,000,000
Transaction and legal fees	-$1,000,000	$14,000,000
Convertible notes: principal and interest	-$7,500,000	$6,500,000
Seed preferred liquidation preference	-$2,400,000	$4,100,000
Corporate liabilities and taxes	-$1,000,000	$3,100,000

Under those assumptions, only $3.1 million remains for common stock and any other participating equity. If the notes instead have a 2.0x cash change-of-control payment based on $6 million of principal, the note claim alone becomes $12 million. With the same fees, preference, and liabilities, the proceeds available for common stock are reduced to zero.

This is only a model, not a valuation conclusion. A real waterfall can change materially if notes convert, preferred holders elect conversion, preferences are participating or stacked, debt is secured, option holders participate, escrow or indemnity holdbacks apply, or consideration includes stock rather than cash.

Why the capitalization records matter

Public fundraising filings may show an early equity round but not the full financing picture. The cap table and note or SAFE register are the practical records needed to understand the senior stack.

For a Delaware corporation, a properly scoped inspection demand under DGCL Section 220 may be a way for a stockholder with a proper purpose to seek relevant books and records. Counsel can advise on entitlement, purpose, scope, and the appropriate recipient. Useful records to request may include:

the current and historical capitalization table, including fully diluted ownership;
every outstanding note and SAFE, together with amendments and side letters;
principal amounts, interest rates, maturity dates, valuation caps, discounts, and change-of-control terms;
the certificate of incorporation and each preferred-stock financing document; and
board materials or transaction analyses addressing an acquisition or recapitalization, where appropriately within scope.

Establish the senior-claim floor

Once the records are available, the analysis starts with a simple question: how much consideration must be paid or allocated before common stock receives anything?

Build the calculation from the executed documents:

Identify secured debt, working-capital adjustments, fees, taxes, and other non-equity obligations.
Calculate each convertible instrument's repayment amount, accrued interest, and change-of-control treatment.
Model conversion outcomes using the relevant cap, discount, and capitalization definitions.
Apply preferred-stock liquidation preferences and conversion elections.
Compare the resulting residual with the total common shares and options entitled to participate.

The result is a break-even threshold: the transaction value at which common stock begins to have a meaningful cash outcome. Knowing that threshold is essential before relying on a headline acquisition valuation or assuming that a large common-share position will translate into proceeds.

Conclusion

Convertible financing can be useful when it bridges a company to a priced round. The risk arises when notes accumulate for years without conversion and then meet a sale price that is insufficient to satisfy debt-like claims, premiums, accrued interest, and preferred preferences.

For common stockholders, the important work is documentary rather than speculative: obtain the governing records through appropriate channels, model the contractual waterfall carefully, and obtain legal and financial advice before drawing conclusions about an exit.

Patching a Critical PHP Runtime Vulnerability Across Seven Environments

CodeMonkeyG — Wed, 21 Oct 2026 00:00:00 +0000

Publication note. This case study has been deliberately anonymized. Organization names, domains, repository names, container names, network details, credentials, and infrastructure-specific paths have been removed or generalized. The version thresholds, remediation approach, validation steps, and operational obstacles are retained because they are useful without exposing the affected environments.

Executive summary

A newly disclosed pair of critical PHP runtime vulnerabilities required a rapid review of several containerized web applications. The important question was not whether a repository declared support for a particular PHP major version. The question was: what PHP version is actually executing public requests right now?

The review found seven public-facing PHP services built from mutable container tags. Source files did not prove that any live service was vulnerable, but they did show that the deployed patch level could drift whenever an image was rebuilt. Runtime verification confirmed that all seven active services were below their applicable security fix threshold.

The remediation did not require compiling PHP from source. Each application container was rebuilt from an official, fixed PHP base image pinned both to an exact release tag and an immutable image digest. The services were then recreated one at a time, leaving proxies, databases, and unrelated application services running. Final checks inside every active PHP worker confirmed the fixed versions.

Two builds initially failed because Docker could not read root-owned runtime directories that had been included in their build contexts. Narrow .dockerignore rules excluded only those non-build artifacts. After rebuilding, all seven services ran fixed PHP versions.

1. Start with deployed reality, not framework requirements

The affected applications used a mix of PHP-FPM-backed frameworks and a content-management workload. Their dependency manifests expressed broad compatibility ranges such as PHP 8.3 or later. That is useful for application development, but it does not prove that the operating container has received a particular runtime security release.

The same distinction applies to a Dockerfile line such as:

FROM php:8.3-fpm

That tag is convenient, but mutable. A build performed at one time may produce a different image than a build performed later, and a running container may still be based on an older cached image. The corresponding risk was even less visible where a content-management image used a generic, unversioned runtime tag.

The initial static review established three facts:

Each affected service accepted PHP requests through a public web path.
Each runtime image tag was mutable or did not identify a PHP patch release.
A source-only review could classify exposure as possible, but could not establish the live runtime version.

That last boundary mattered. Treating an image reference as proof of the running runtime would have been an assumption, not a finding.

2. Define the version policy before deployment

The disclosed issues were fixed in specific PHP patch releases. The response policy treated these versions as the minimum acceptable upstream releases:

PHP branch	Minimum fixed version
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

An environment running an older distribution-maintained PHP package may have a vendor backport. In that case, the package maintainer's advisory and changelog must establish that the fix is present. This fleet used official container images, so the operational rule was simpler: move each service to the published fixed patch release or later.

We first queried the executing process in every active PHP container:

docker exec <php-container> php -r 'echo PHP_VERSION, PHP_EOL;'

All seven returned versions below their branch threshold. This converted a potential exposure based on source review into a confirmed patching requirement.

3. Pin both the release and the image identity

The permanent source change was intentionally small. Each generic PHP image tag was replaced by an exact fixed patch release plus its immutable registry digest:

FROM php:8.3.36-fpm@sha256:<verified-image-digest>

Services on the next supported branch used the equivalent fixed release:

FROM php:8.4.27-fpm@sha256:<verified-image-digest>

The content-management service and its associated command-line image received the same treatment: an explicit image variant with a verified fixed PHP runtime and a pinned digest.

Tags make source files readable and state the intended release. Digests bind that declaration to the exact multi-platform image manifest that was inspected. Together they prevent a future rebuild from silently receiving a different image under the same tag.

Before changing application source, the candidate images were pulled and inspected locally. The PHP executable inside each image was queried directly:

docker run --rm --entrypoint php <image-reference> -v

This validated the runtime carried by the selected image rather than trusting the tag name alone.

4. Rebuild application containers, not PHP from source

There are two very different meanings of "rebuild PHP":

Action	What it means	What we did
Compile PHP from source	Download PHP source, compile it, and manage build flags and patches	No
Rebuild an application image	Run the application's Docker build again, using an updated PHP base image	Yes

The latter was the correct response for this fleet. It preserved each application's existing extension installation and startup behavior while replacing its underlying, vulnerable PHP runtime with the fixed image.

The normal deployment sequence was:

docker compose build --pull <php-service>
docker compose up -d --no-deps --force-recreate <php-service>

--pull makes the build retrieve the declared digest if it is not already present. --no-deps limits the restart to the patched service. --force-recreate ensures that Compose does not keep an existing, vulnerable container merely because its service configuration appears otherwise unchanged.

This was performed one service at a time. Reverse proxies, databases, caches, and front-end services were not rebuilt or restarted as part of this runtime-only response. That reduced the change surface and made troubleshooting clearer.

5. Roadblock: runtime files leaked into the build context

The first four application image builds completed. Two later builds failed before executing their Dockerfiles because the Docker daemon could not stat directories inside the build contexts. Those directories were root-owned runtime artifacts under application storage paths.

The failure was not a PHP compatibility issue. It came from Docker sending the entire project directory as build context. A root-owned directory that is useful at runtime does not need to be sent to the builder, especially when the Dockerfile does not copy it into the image.

The fix was a narrow .dockerignore entry in each affected repository:

storage/framework/testing/disks/public/<runtime-directory>/

and:

application/storage/app/private/<runtime-directory>/

These exclusions were deliberately specific. We did not delete runtime data, change ownership recursively, or ignore broad application storage trees. The directories remain available through the services' runtime volume mounts; they are simply excluded from an image build that does not need them.

After adding the exclusions, both application images built successfully from their fixed base images and the corresponding PHP-FPM services were recreated.

6. Roadblock: a stale auxiliary PHP container

One environment also had a long-running, ad hoc command-line PHP container that was separate from the primary PHP-FPM service. Its image was older than the new runtime policy, and it was not replaced when the main web worker was recreated.

This was a useful reminder that a service inventory cannot stop at the primary web process. One-off jobs, administrative command-line containers, workers, scheduled tasks, and temporary debug shells can all retain an older runtime image.

The response was to stop the stale auxiliary container and update the declared command-line image reference alongside the web runtime. Subsequent ad hoc jobs will use the pinned, fixed image. For teams with recurring operational jobs, this should become an explicit deployment check rather than a manual cleanup step.

7. Verify the running container after every recreate

A successful image build does not prove that traffic is using the new image. A successful docker compose up does not prove that the application process started correctly. We validated the active runtime in every recreated service:

docker exec <php-container> php -r 'echo PHP_VERSION, PHP_EOL;'

The final state was:

Service group	Active runtime after rollout
Four PHP 8.3 services	PHP 8.3.36
Two PHP 8.4 services	PHP 8.4.27
One PHP-FPM content service	PHP 8.4.27

We also rendered each Compose configuration before deployment to catch YAML, interpolation, and image-reference errors:

docker compose config -q

The application image builds completed successfully after the build-context exclusions were added. Because the change was deliberately limited to the PHP base images and ignored build-only runtime artifacts, a full application test suite was not a substitute for, or prerequisite to, the key security assertion: the running PHP interpreter met the patched threshold.

8. What made the response effective

Several practices turned a fleet-wide response into a controlled maintenance task:

Separate static evidence from runtime evidence. Dockerfiles identified where to investigate; php -v established what was actually exposed.
Use fixed versions and immutable digests. Exact tags address patch level; digests protect against future tag drift.
Change only the affected service. Recreating PHP workers without their dependencies reduced disruption.
Treat build failures as deployment problems, not reasons to defer patching. The inaccessible runtime paths had a small, scoped solution.
Include auxiliary processes in the inventory. A forgotten command-line PHP container can undermine an otherwise complete rollout.
Verify after deployment. The only authoritative completion check was the version reported by each active container.

9. Follow-up controls

The immediate exposure was remediated, but the process should not depend on a manual emergency review every time a runtime advisory appears. The next controls are straightforward:

Maintain an inventory of public PHP workers, scheduled jobs, queue workers, and administrative containers.
Require exact PHP patch versions and registry digests in Dockerfiles and Compose files.
Add a deployment check that fails builds or releases below the approved PHP minimum.
Record the image digest and php -v output as a release artifact.
Review access and application logs during the relevant exposure window, then follow the incident-response process if compromise indicators appear.
Schedule regular base-image maintenance so urgent updates remain small, familiar changes.

Conclusion

The technical fix was not exotic: identify the active runtimes, select patched base images, rebuild application containers, recreate the affected services, and verify the live interpreter. The difficult part was maintaining the distinction between repository intent and runtime reality while responding quickly across multiple environments.

The result was a complete, verified rollout from vulnerable PHP patch levels to fixed releases, plus a more durable image-pinning and build-context practice. The next vulnerability response should begin with a clearer inventory, more deterministic image references, and fewer surprises between a successful build and a secure running service.

Building an AI-Assisted Carousel Pipeline Without Canva or Adobe

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

Executive summary

I wanted a repeatable way to create Instagram marketing carousels for a client. I had campaign ideas, SVG templates, and JPG backgrounds. I wanted to keep control of those assets, improve the writing through review, and produce images without depending on Adobe, Canva, or a hosted design editor.

Working with an AI coding agent, we built a file-based pipeline: source notes became reviewable Markdown, Markdown became JSONL, and Python placed the approved text into SVG templates. Inkscape rendered the SVGs into PNGs. The finished batch contained 14 campaigns and 69 slides, with an editable SVG and a flattened PNG for each slide.

Getting there required more than connecting a model to a renderer. Early versions pulled from the wrong source directory, treated production labels as copy, shortened sentences badly, and produced slides that passed layout checks but did not read well together. A later template revision exposed another mistake: the renderer treated example bullet lines as a hard capacity limit.

Those failures helped define the architecture. AI handles editorial reasoning and task coordination. Python performs mechanical transformations. Templates define the visual design. People approve the message and decide what to publish.

The rendering path runs locally and does not call a language model or image-generation service. The editorial workflow is designed to be portable across models, although model quality and tool support still matter. Running the entire agent workflow with a local model would require configuration and validation; that was not established by this project.

1. The requirement was ownership, not another image generator

The images in this project are composed from existing artwork and text. We did not ask a diffusion model to invent a new picture for each slide.

That choice matters for business content. A supplied SVG can preserve the brand's typography, colors, text positions, shadows, background crop, and footer across an entire campaign. The writing can change without asking an image model to reproduce a logo or spell a headline correctly.

I also wanted files I could keep using outside the original workflow. The outputs needed to include editable masters, not just images exported from an account I might later stop paying for.

The working materials were ordinary files:

Material	Purpose
Campaign notes	Source ideas, practical advice, and business context
SVG templates	Layout, typography, branding, and editable text layers
JPG backgrounds	Supplied visual assets
Compiled Markdown	Human-readable campaign copy for review
JSONL	Structured input to the renderer, one campaign per line
Generated SVGs	Editable slide masters
PNGs	Flattened images for posting

The source notes lived in Obsidian, but the pipeline used their Markdown files. Obsidian was a convenient writing environment, not a required rendering service.

2. Separating writing from rendering

The final data flow was:

Campaign idea or source note + supplied SVG/JPG assets
                         |
                         v
              AI-assisted editorial draft
                         |
                         v
             Human-reviewable Markdown
                         |
                  Review and revision
                         |
                         v
             Mechanical Python compiler
                         |
                         v
          JSONL: one campaign object per line
                         |
                         v
             Mechanical Python renderer
                         |
                Editable SVG masters
                         |
                         v
                  Inkscape export
                         |
                         v
                     PNG slides
                         |
                         v
         Technical checks + visual/editorial review
                         |
              Revise upstream if needed

Each boundary has a different responsibility. The SVG defines appearance. The Markdown defines what the audience reads. JSONL carries that content into the renderer. Python should not decide whether a sentence sounds persuasive.

A follow slide's Markdown uses three explicit fields:

## Slide 03

### Title

Google may already list you

### Details

You may not control what locals see there.

### Bullet Points

- Photos may not show your storefront.
- The category may not fit your shop.
- Service areas may be missing or wrong.
- The listing may still appear in a search.

The corresponding JSONL record contains campaign metadata and an ordered slides array. Each slide has a number, title, details, and an array of bullet sentences. This gives the renderer a predictable input without asking it to interpret a loosely formatted brief.

It also makes changes traceable. If a sentence needs work, I can read and edit the Markdown rather than hunt through SVG markup or modify a finished image.

3. The early failures were useful specifications

The initial source selection was wrong. The agent read a broader Instagram folder instead of the direct campaign notes. That produced work outside the intended scope. Correcting the directory narrowed the set to 14 campaigns.

Other failures happened inside the content. Source notes mixed headings, design instructions, and actual audience copy. Labels such as "The Pitfalls" and "How to do it" sometimes became bullets. Long text was shortened into incomplete or awkward phrases.

The tempting response was to add more Python rules: detect a bad phrase, replace it, remove another label, shorten another sentence. I pushed back on that approach. The compiler was accumulating editorial decisions that belonged in the writing stage.

We moved those decisions upstream. The agent had to prepare finished, reviewable copy before conversion. The scripts could reject invalid structure or text that did not fit, but they were not supposed to repair weak writing.

This was our garbage-in, garbage-out rule in practical terms. A parser should not conceal a bad draft by substituting generic advice. If the input is wrong, fix the input.

4. Passing a layout check did not make the carousel good

One batch passed technical checks and visual layout review, yet the slides still felt disconnected. The titles, explanatory text, and bullets concerned similar subjects without consistently building one argument.

I had also asked for five bullets per follow slide. That made the output look consistent, but encouraged filler and checklist writing. We changed the editorial rule to two to five complete, concise bullets when the slide needed them.

We then revised one campaign before applying the style to the others. Campaign 1 compared fiber and cable internet through familiar situations: streaming shows, frozen video calls, upload speed, and Wi-Fi dead zones. Rather than declaring one service universally better, it helped a reader distinguish different problems and consider what their household needed.

The revised progression was:

Ask which plan fits the home.
Explain download and upload speed.
Connect upload speed to a video call that freezes.
Acknowledge when cable may already be sufficient.
Separate Wi-Fi coverage from the speed of the purchased plan.
Check availability at the actual address.
Invite a specific conversation about the reader's situation.

That pilot became the approved reference for the remaining campaigns. We delegated bounded groups of campaign rewrites, then checked the files and rebuilt the outputs. Delegation spread the work; it did not remove the need to reconcile the results.

The important improvement was editorial. Each slide had to carry one thought, and the next slide had to give the reader a reason to keep going.

5. The renderer preserved the design instead of inventing one

The Python renderer reads the structured content, chooses the title or follow template, inserts text, assigns the background, and calls Inkscape to export the PNG.

The templates included separate visible and shadow text elements. Replacing only the visible title would leave the old words in its shadow. The renderer therefore updates the paired elements together, using their exact IDs and preserving their styling and placement.

Unused bullet lines remain empty. XML-sensitive characters are escaped. The generated SVG retains editable text rather than flattening the entire slide into a bitmap.

In this project's templates, the scripts also used explicit line-length and wrapping limits. Those limits were implementation choices for this design, not universal rules for Instagram. A different font, text box, or canvas requires inspecting the new template and checking its actual render.

The scripts were kept directly on the Desktop for inspection and editing. They were small project tools, not a hosted application or a service that needed an account to produce each image.

6. A one-word wrap showed why the loop matters

Visual review found a heading in the Google Business Profile campaign that wrapped poorly:

A listing can exist without
you

Every word was visible. The copy matched the structured data. The heading still looked unbalanced because "you" sat alone on the second line.

Under the review rules at that point, the agent reported the issue rather than silently changing the slide. I then authorized a revision through the full process.

We returned to the source context and compiled Markdown, changed the headline to "Google may already list you," regenerated JSONL, and rerendered all seven slides in that campaign. The revised headline fit on one line. We visually checked the campaign again.

We did not patch the PNG or change the generated SVG alone. Doing that would leave the underlying copy out of sync and allow the defect to return on the next run.

That small correction demonstrated why the intermediate files were worth keeping. The same workflow handled both initial production and a targeted editorial revision.

7. The template revision exposed an overly rigid assumption

Later, I changed text from point text to area text in the design editor to define its boundaries, then asked for Campaign 1 to be rendered again without changing its copy.

The title slide rendered, but the next slide failed. The exported follow template contained three example bullet spans. The renderer expected five and refused the mismatch.

The initial diagnosis treated those three lines as the template's capacity. That was too literal. They were examples, not a request to reduce the campaign's bullet count.

Inspection of the exported SVG showed positioned <text> and <tspan> elements. The relevant text did not expose shape-inside or inline-size boundaries. Whatever the editor displayed as area text, the file presented to this renderer still required handling explicit line positions.

We corrected the mechanical assumption. For this template, the renderer can clone additional bullet spans using the measured vertical spacing of the example lines, preserving their attributes and doing the same for the shadow layer. It rejects spacing it cannot safely derive rather than guessing.

A regression test covered two through five data bullets against the three-line example template. The tests passed, and the campaign rendered successfully. Subsequent checks compared output text with JSONL, checked main/shadow agreement, and inspected the PNGs.

This fix supports the template structure we inspected. It is not a claim that the renderer understands every SVG area-text implementation or automatically respects arbitrary text-box boundaries. Export formats still need inspection and testing.

8. Model portability comes from the interfaces

The workflow does not encode a particular model's private output format into the production files. Its working contracts are Markdown, JSON, SVG, and image files. The Python scripts do not call a model at all.

That makes the production pipeline largely independent of which model helps write the copy or coordinate the tools. A model capable of following the schema can prepare the same inputs; a person can also edit those inputs directly.

This does not make models interchangeable in practice. Writing quality, context handling, tool use, and image inspection can vary. During the work, image-analysis calls also failed with service errors. A failed visual check is a missing check, not a pass, even when the files render successfully.

A fully local version is a reasonable deployment option, with work still required:

Configure the agent to use a suitable local model and tool interface.
Provide local image inspection capability if automated visual review is required, or have a person inspect the PNGs.
Check hardware capacity and validate the model against the actual writing and tool tasks.
Adapt the project-specific paths, fonts, assets, and renderer assumptions to that installation.

We demonstrated local file processing and image rendering. We did not benchmark a fully local model deployment or establish equal results across all models. The portable interfaces make that deployment possible to pursue without replacing the entire content pipeline.

9. No required Adobe or Canva account

The image-production path uses Python, SVG files, JPG assets, fonts, and Inkscape. It does not require an Adobe subscription, a Canva workspace, a proprietary template API, or a cloud image-generation endpoint.

This is the independence I wanted. I can keep the source copy, change the code, move the files, use another SVG editor, and regenerate outputs locally. The editable master is a file I possess rather than an object available only inside a vendor's service.

That independence has limits worth stating. Fonts and background artwork still have licenses. Software still has maintainers. Hosted models remain external dependencies when I choose to use them. Publishing to Instagram still depends on Instagram.

The narrower, defensible claim is that creating these images does not require a proprietary design platform. That removes a specific dependency without pretending the whole workflow exists outside the software ecosystem.

10. Verification and the resulting artifacts

We used several checks because each catches different failures:

Check	What it establishes	What it does not establish
Markdown validation	Required fields, numbering, bullet counts, and configured fit limits	Whether the copy is engaging or accurate
JSONL parsing and count reconciliation	Structured data is readable and accounts for the expected campaigns and slides	Whether every claim is justified
SVG text and shadow comparison	Rendered text matches the intended content and paired layers	Whether the typography looks balanced
PNG dimensions and text bounds	Files have expected dimensions and text stays within checked margins	Whether contrast or wording works for a reader
Individual visual and editorial review	Visible layout defects and narrative problems can be identified	Guaranteed quality or marketing performance

The completed campaign set contained 69 slides across 14 campaigns, producing 69 SVGs and 69 PNGs. We later deleted and regenerated the slide outputs from the retained inputs. For that final bulk rerender, I explicitly requested that visual inspection be skipped. The successful render and file counts established regeneration, not a fresh visual approval of every image.

We also distilled the procedure into a standalone workflow skill. It describes asset inspection, campaign writing, the Markdown-to-JSONL boundary, mechanical rendering, verification, and source-level revision. It avoids assuming this machine's paths or a particular business's contact details so another agent can use it with a new set of assets and a different idea.

There are no measured conversion results in this case study. The carousels were written to generate leads, but producing them does not prove they generated engagement or customers. We also did not run a controlled cost or time comparison against a design subscription.

Conclusion

This project began as a request for marketing images and became a practical exercise in separating judgment from execution.

The agent was useful for drafting, revising, coordinating batches, and working through tools. It also made mistakes that needed human correction. Python became more reliable as we removed editorial guesswork from it. The SVG templates gave the design a stable form, while Markdown and JSONL let us revise the message without rebuilding the artwork manually.

I now have campaign copy, editable masters, posting images, local rendering tools, and a documented process I can move to another agent. The workflow still needs editorial judgment and honest verification. It does not need a proprietary design service to turn approved words and supplied assets into images.

For a related case study on evidence handling and human oversight, see An Agentic AI Investigation of Disputed Online Reviews.

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.