DEV Community: Kilowott

AI Traffic Showing Up as “Direct”? How to Fix Attribution After Gemini Dropped Its UTM Tags

Kilowott — Tue, 10 Nov 2026 09:04:30 +0000

An analytics manager opens her weekly report and notices something odd. Direct traffic has crept up, and much of it is landing on deep blog posts and product guides, pages nobody types into a browser from memory. She has no campaign to credit and no new backlinks. Somewhere in that bucket, she suspects, are visitors who came from an AI assistant that cited her pages.

She is probably right, and the problem has just become harder. At the end of September 2026, Google’s Gemini stopped adding a tracking tag to the links it cites. According to research by Kilowott, the change only came to light a month later.

This matters because reports drive decisions. If a growing source of visitors is hidden inside a catch-all bucket, content that is being cited and recommended can look like it is underperforming. And since click-through from AI answers is often low, every visit you can’t identify costs you more.

What Happened to Gemini’s Tracking Tag

Around the start of September 2026, Gemini began adding the parameter utm_source=gemini to the source links in its answers. Google did not announce it. A Reddit user spotted it, and Google’s John Mueller confirmed in the thread that he could see it too.

Then the tag disappeared. Server logs shared by search consultant Natzir Turrado show it vanishing around September 28 or 29, after about three weeks. Turrado raised it on October 27, and Search Engine Roundtable reported on October 30 that it could no longer find the tag. Google has not commented on either the addition or the removal.

Why AI Visits Land in “Direct”

Without the tag, you depend on the referrer, which is the information a browser passes about where a visitor came from. On desktop and the web, Gemini visits still arrive with a gemini.google.com referrer, so they can be identified.

Mobile is the weak spot. One analysis reports that Gemini’s iOS app opens links in its own in-app browser without passing a referrer, so those visits appear as Direct in Google Analytics 4. The same source says the tag had previously revealed between 16 and 65 extra hidden clicks for every 100 sessions counted through a standard referrer. That comes from a single report, so treat the range as indicative.

The Trap: Fake Trends in Your Data

There is a second problem that is easy to miss. If you looked at Gemini traffic in September, you would have seen it appear, grow for about three weeks and then collapse. That pattern says nothing about interest in your content. It reflects a tag switching on and off.

ChatGPT had a similar wobble. According to reporting, its links lost their utm_source=chatgpt.com tag between about October 7 and 16 before it returned, and the gap was later described as a bug. Comparing October with September could make you read a drop in AI traffic that never happened. Mark these dates in your reports and treat any sharp rise or fall around them as a measurement artefact until proven otherwise. Kilowott makes a similar point about over-reading platform data in its post on Google adding links to AI answers.

A Practical Plan for Measuring AI Referrals

No single step is perfect, but together they give a far better picture than the default reports.

Create an AI channel in your analytics. In GA4, a custom channel group lets you gather known AI sources, such as chatgpt.com and gemini.google.com, into one place. Check which sources actually appear in your own data before you build it.

Look at your server logs. Logs record details analytics tools miss, including the user agent. One analysis reports that Gemini’s iOS visits can be spotted through a particular token in the user-agent string. Ask your developer or host whether that is feasible for you.

Watch landing pages, not just sources. A jump in direct traffic to deep informational pages is a useful clue, though only a clue.

Ask people directly. Add a “How did you hear about us?” field to enquiry and checkout forms, with an option for an AI assistant.

Track brand demand. If AI answers mention you, branded search and direct home page visits often rise.

Tag what you control. For links you place yourself, in newsletters, profiles and partner pages, use your own UTM parameters.

Automate the reporting. A weekly view that combines these sources saves hours and keeps your annotations consistent. This is a natural fit for automation, and Kilowott’s digital marketing team builds this kind of reporting for clients.

What Not to Conclude

Avoid two opposite mistakes. One is deciding AI traffic is negligible because the identifiable slice is small, when much of it may be hiding in Direct. The other is blaming every rise in direct traffic on AI, which without evidence is guesswork. A better stance is to say what you can measure, name what you can’t and estimate the gap honestly. Kilowott’s piece on why agentic AI makes AEO non-negotiable makes the related point that visibility and traffic are different things, and both need tracking.

AI Referral Measurement Checklist

Reports are annotated with the dates Gemini and ChatGPT changed how they tag links
An AI channel grouping exists in analytics, based on sources you actually see
Direct traffic to informational pages is checked against your usual baseline
Your developer or host has been asked about log analysis
Forms include a “how did you hear about us” option for AI assistants
Branded search and direct home page visits are tracked
Every link you place yourself carries your own UTM parameters
A weekly report combines these views

Quick FAQ

Did Gemini stop adding UTM parameters?
Yes, according to server-log data from Natzir Turrado and a Search Engine Roundtable report on October 30, 2026. Gemini added utm_source=gemini for roughly three weeks in September and then stopped, and Google has not commented.

Can I still track Gemini traffic?
Partly. Desktop and web visits still arrive with a gemini.google.com referrer, but mobile app visits may appear as Direct because the app does not pass a referrer.

Should I stop using UTM parameters?
No. Keep using them on links you control, and don’t depend on AI platforms to add them for you.

Final Thoughts

The Gemini change is a small technical event, but it points to something bigger: the way AI assistants send people to your site is still being worked out, and most analytics tools were built for a different era. Teams that cope best build a measurement approach that holds up when tags appear and disappear, and are honest about what they can and can’t see.

If you would like help setting that up, Kilowott’s digital marketing team can build reporting that combines these views, and their automation work keeps it running every week. You can also browse their case studies or get in touch.

Source and further reading: Where Did That Visitor Come From? Fixing Attribution for AI Referrals After Gemini Dropped Its UTM Tags by Kilowott.

Your AI API Key Leaked: What to Do Right Now and How to Limit the Damage Next Time

Kilowott — Tue, 10 Nov 2026 08:43:16 +0000

A developer wakes up on a Saturday to a spend alert from her AI provider. Overnight, someone has been running up charges on a key she pasted into a coding tool weeks ago and forgot about. Her laptop is clean and her passwords are strong. Her own code never leaked. The key was sitting in a vendor’s system, and the vendor was breached.

That is close to what some OpenCode users reported in mid-October 2026, with a few saying they were billed more than $1,700 overnight. It was not a one-off. A security recap cited in research by Kilowott counted 15 well-known companies and projects reporting incidents in October, and in six of them attackers ended up holding secrets such as API keys, tokens or environment variables.

AI keys are an attractive target because they turn directly into money. A stolen database password needs a buyer or a plan, while a stolen AI key can be put to work immediately, running queries at someone else’s expense. Teams now scatter these keys across coding tools, agents, automation platforms and hosted dashboards, so there are far more places for them to leak than there used to be.

What Happened at OpenCode

On October 17, 2026, the open-source AI coding project OpenCode told some users of its hosted Console that third-party provider keys saved in their workspaces may have been exposed. It said 1.4% of Console users were affected, specifically those who had linked providers such as OpenAI, Anthropic and Google.

According to reporting, the attackers got in through a legacy system that the project was preparing to shut down. Anthropic and Google blocked keys believed to be exposed, and one report says OpenAI was refunding affected customers. OpenCode’s public statement does not explain how the attackers got in or how many keys were involved, so some details are still unknown.

Two things stand out. The keys were in a hosted service because users had chosen to link them for convenience, and the weak point was a forgotten system that nobody was watching.

The Wider Pattern

The same recap describes several other incidents with a similar shape. Railway found unauthorised access to the systems that store customer environment variables and told customers to rotate their credentials. Attackers used stolen GitHub tokens from LiteLLM engineers to publish a malicious package release that was live for about an hour and forty minutes. The maker of TiDB Cloud reported an intruder using stolen service account credentials to copy a table of encrypted API keys.

The causes differed, but the shape is the same. One stolen secret opens a door, and a door opened with a valid secret often looks like normal use. That is why it makes sense to assume some secret, somewhere, will eventually leak, and to build so that a leak is survivable.

If a Key Leaks: Six Steps in Order

First, revoke the key. Log in to the provider, delete or disable it, create a replacement and update the applications that use it. Every minute the key stays live is a minute it can be abused, so do this before anything else.

Second, check your usage. Look at the provider’s dashboard for requests, models or charges you do not recognise, and note the times, since they help you work out when the misuse began.

Third, contact the provider. In the OpenCode case, providers blocked exposed keys and refunds were reported, so it costs nothing to ask what they can do for you.

Fourth, rotate related secrets. If one key leaked from a tool, assume the others stored beside it may have leaked too.

Fifth, find the cause. Work out whether the key was in a hosted tool, a committed file or a CI setting, and close that gap so it does not happen again.

Sixth, write it up. Record what happened and update your practices. If personal data may have been involved, involve your legal advisers. This is general information and not legal advice.

Making the Next Leak Survivable

You cannot prevent every leak, especially from tools you did not build. What you can do is make leaks small, and the first way is to use short-lived secrets. A long-lived key that leaks in January still works in October, whereas a credential that expires on its own has a narrow window of use even if it is stolen. Where your platform supports it, prefer short-lived credentials over static keys. Some teams run a small gateway that holds the real provider key, so applications authenticate with an expiring token and never see the key itself. Where you must use a static key, rotate it on a schedule and whenever someone leaves or a tool is retired.

The second way is hard spend limits. Short-lived keys reduce the chance of a problem, and spend limits reduce its cost. According to the summaries in Kilowott’s post, OpenAI offers monthly limits at the organisation or project level with an option for a hard limit. Anthropic offers monthly limits per workspace, though not on the Default Workspace. Google announced project spend caps for the Gemini API in March 2026, which are described as experimental and can lag by around ten minutes. Provider details change often, so check each one’s current documentation.

Notice what is missing from that list. None of the sources describes a cap on a single key. The practical workaround is to give each tool its own project or workspace with its own cap, so one leaked key can only ever spend one budget.

The third way is to separate and scope your keys. Use one key per tool, per project and per environment, so that a staging key does not work in production and a coding assistant does not share a key with your customer-facing application. If every tool shares one master key, one breach exposes everything.

The fourth way is to detect problems early. Most of the damage in these incidents happened overnight, so set an alert at a level that would be unusual for you and well below your hard cap. An alert tells you something has gone wrong, while a hard limit stops it going further, so use both.

Questions to Ask Before You Store a Key With a Vendor

Any hosted tool that holds your keys inherits your risk. Before you hand one over, ask how keys are stored and encrypted and who inside the company can access them. Ask what happens to legacy systems and whether they are included in security reviews. Ask whether you can use scoped or short-lived credentials instead of a master key, how quickly you will be told if something goes wrong, and whether you can revoke a key from your side and see what it was used for. The OpenCode case is a reminder of why the legacy-system question matters, because a system being decommissioned is still a live system until it is switched off.

Where to Start This Week

If you only do a few things, begin by finding every place your AI provider keys are stored, including tools, code, CI settings and shared documents. Then set a hard monthly limit on every provider project or workspace, and move any tool out of a default workspace where limits are not available. Make sure each tool has its own key, and retire any that are shared. Finally, create a spend alert at a level that would be unusual for you, so you hear about a problem in hours and not weeks.

Final Thoughts

It is tempting to respond to news like this by promising to be more careful. Care helps, but it is not a plan. Keys will leak from tools you did not build, systems you did not know existed and accounts you did not think about. The teams that stay calm when that happens made the leak small in advance, with short-lived credentials that expire, separate keys that contain the damage, caps that stop the bill and alerts that tell them quickly.

If you would like help putting that structure in place, Kilowott offers Kilowott Intelligence for reviewing how AI tools are connected and governed, and automation for key rotation and spend monitoring. Their web and e-commerce team can also check the credentials behind your sites. You can browse their case studies or get in touch.

Source: Short-Lived Secrets and Spend Limits: How to Protect Your AI Keys After October’s Breaches by Kilowott.

The AI Tooling Problem Nobody Talks About

Kilowott — Tue, 01 Sep 2026 09:11:38 +0000

Every engineering team I've talked to in 2026 has some AI in their stack: a coding assistant, a review bot, an agentic PR generator. Almost none of them can tell you, with a straight face, what that tooling is actually saving them.

That's not an AI capability problem. It's a sequencing problem. Teams install tools first and figure out the workflow around them second, which means the tool ends up bolted onto whatever process already existed, often making it noisier, not faster.

The teams getting real, measurable throughput gains are doing the opposite: they map the workflow, then decide where AI belongs in it, then build guardrails so the output doesn't need a human to re-check everything anyway. That's the whole idea behind a framework we use at Kilowott called Intelligence → Automation → Control, and it maps cleanly onto how a software team should actually roll out AI.

Why "Just Add AI" Keeps Failing

A few patterns show up over and over when AI adoption stalls on an eng team:

No prioritization. AI gets applied to whatever's most visible (usually code generation) instead of whatever's most expensive (usually code review, triage, or onboarding new engineers to a codebase).
No human-in-the-loop design. Either a human checks 100% of AI output (no time saved) or 0% (quality drops, trust drops, tool gets abandoned).
No ownership. Nobody's accountable for whether the AI-assisted process is actually better than the old one, so it just quietly underperforms forever.

Each of those maps to one part of the framework.

Step 1: Intelligence: Map Before You Automate

Before touching a workflow, rank your team's recurring tasks on two axes: impact (time or money it currently costs) and effort to automate (how structured/repeatable the task is).

High-impact, low-effort tasks are the ones worth automating first. For most engineering orgs, that's usually not greenfield code generation. It's things like:

First-pass PR review (linting logic, obvious edge cases, style consistency)
Writing and maintaining test coverage for existing code
Summarizing incident postmortems and turning them into action items
Onboarding docs that stay in sync with the actual codebase

Code generation is high-impact but also high-variance: it's the flashiest use case and the hardest to get reliable ROI from without the next two steps.

Step 2: Automation: Human-in-the-Loop, Not Human-Out-of-the-Loop

This is where most teams either over-automate (ship AI output straight to prod) or under-automate (AI drafts, human rewrites from scratch, net time cost is negative).

The pattern that actually works is a checkpoint model: AI handles the first draft, a human makes one specific type of decision, and the loop closes automatically.

Concretely, that can look like a PR pipeline where an AI agent runs first and flags specific concerns (logic gaps, missing tests, style issues), a human reviewer only has to approve or reject the flagged items instead of re-reading the whole diff, and the PR auto-merges once that single approval comes through.

The key design decision isn't "how much can AI do"; it's "what's the one judgment call a human still needs to make, and how do we get the AI's output in front of them fast enough that checking it is cheaper than doing it themselves."

Step 3: Control: Guardrails That Don't Kill Velocity

Automation without ownership decays. Three months in, nobody remembers why a rule exists, the AI model's behavior has drifted, and quality issues get blamed on "the AI" instead of the process around it.

Control means:

Someone owns each automated workflow, not "the team," a named person.
You measure the thing you claimed would improve: cycle time, review turnaround, defect escape rate, not just "we use AI now."
You review the automation itself on a schedule, the same way you'd review any other piece of infrastructure.

Teams that skip this step tend to see an initial productivity bump that quietly erodes over two or three quarters as the automation stops matching how the team actually works.

What This Looks Like End to End

A mid-sized product team applying this framework might land here:

Intelligence: PR review and test-writing ranked highest for impact/effort, not feature code.
Automation: AI drafts tests and flags review issues; a human approves or overrides flagged items only.
Control: Engineering lead owns the workflow, reviews false-positive/negative rates monthly, and cycle time is tracked before/after.

Nothing about this requires exotic tooling. It requires sequencing the rollout instead of dropping a tool into an unstructured process and hoping.

FAQ

Is AI actually replacing software engineers in 2026?
No. The evidence points toward AI absorbing specific sub-tasks (review, test-writing, docs, triage) rather than eliminating engineering roles. Teams that see the biggest gains are reallocating engineer time toward judgment-heavy work, not shrinking headcount.

How do you measure ROI on an AI-assisted dev workflow?
Pick one metric that existed before you added AI: cycle time, review turnaround, defect rate, onboarding time, and track it before and after. If you can't name the metric, you're not ready to claim ROI yet.

What's the difference between "automation" and "AI adoption"?
AI adoption is using the tools. Automation is redesigning the workflow so the tool's output moves through the system with minimal redundant human effort. You can have heavy AI adoption and zero automation. Most teams do.

Where should a team start if they only have time for one thing?
The Intelligence step. Ranking tasks by impact vs. effort before choosing a tool prevents almost every common failure mode listed above, and it costs nothing but a meeting.

Key Takeaways

AI tooling fails most often from bad sequencing, not bad tools.
Map impact vs. effort before automating anything (Intelligence).
Build one clear human checkpoint per workflow, not full handoff or full oversight (Automation).
Name an owner and a metric for every automated workflow, and review it on a schedule (Control).

Vibe Coding Is Everywhere. But Is It Actually Good Software Engineering?

Kilowott — Thu, 13 Aug 2026 11:40:52 +0000

Software development is changing. AI can now write code, build prototypes, generate tests, debug issues, and take on tasks that once took developers hours to complete.

At Kilowott, we’ve seen this shift firsthand. AI-assisted development can help teams move from an idea to a working prototype faster, explore solutions more efficiently, and take some of the repetitive work out of software development. But the biggest value doesn’t come from simply producing more code. It comes from knowing how and when to use AI as part of a proper engineering process.

That distinction is becoming increasingly important.

There’s a difference between using AI as a development tool and letting AI take over the development process. And that’s where vibe coding enters the conversation.

Vibe coding, prompting an AI to write software and accepting the output with little or no manual review can be useful for experimentation and rapid prototyping. But when it becomes a substitute for engineering judgment, testing, security reviews, and code ownership, things can quickly become complicated.

AI can produce working code. That doesn’t always mean it has produced good software.

For developers, the real question isn’t whether AI should be part of the development process. It’s how to use it without losing the engineering discipline that makes software reliable, maintainable, and scalable.

In this article, we’ll look at where AI-assisted coding can genuinely help, where it can fall short, and what developers and the teams building with them need to keep in the loop.

What Is Vibe Coding, Exactly?

The term comes from a February 2025 post by Andrej Karpathy, and it has since split into two very different things that get talked about as if they're one:

AI-assisted development, a professional developer uses tools like Copilot, Cursor, or Claude Code inside a normal engineering workflow: architecture is planned, output is reviewed, tests are written.
Vibe coding proper, you describe what you want, accept the output with minimal scrutiny, and iterate by re-prompting rather than by reading and reasoning about the code.

Most of the discourse, the hype and the backlash alike is actually about #2.And the confusion between the two is a big part of why every "vibe coding is amazing" post and every "vibe coding is a disaster" post can both be citing real experiences.

Why It Took Off

The appeal isn't mysterious. When it works, it's genuinely fast:

Boilerplate, CRUD scaffolding, and standard API integration have shown time savings as high as 81%
A February 2026 McKinsey study of 150 enterprises found routine coding tasks saw a 46% average time reduction, with code review cycles shortening by 35%
Prototypes that used to take weeks now take hours

If your job is "get something working to show someone," this is close to magic. That's exactly why dev.to's own trending page, GitHub's explore feed, and Hacker News all skew toward projects that look finished, polish is cheap to generate now, and platforms reward what looks complete over what's actually well-built.

That gap between looks done and is done is the whole story.

The Part the Demos Don't Show You

Vibe coding is honest about the easy 80% of a feature and quiet about the hard 20%. Generating a checkout flow, an admin dashboard, or a CRUD panel takes minutes. What quietly falls apart is:

The payment call that partially fails halfway through
Two admins editing the same record at the same time
Auth edge cases that only show up under real traffic
Data validation that a demo never needed

The apps that look the most finished in a screenshot are often the most fragile underneath because AI is extremely good at producing something that reads as production-ready, and only a trained eye can tell the difference between "looks done" and "is done."

The Numbers Nobody Wants Attached to Their Launch Post

If you strip out the vibes and just look at the research from 2025–2026, a pretty consistent picture shows up:

Around 45% of AI-generated code samples fail security tests, including critical OWASP Top 10 vulnerabilities, per Veracode's 2025 analysis
An independent December 2025 audit of five major vibe-coding platforms across 15 test apps turned up 69 vulnerabilities, several critical
A real-world case: a 2025 CVE tied to a popular vibe-coding platform exposed over 170 production apps through a missing database access-control setting — full user data exposed to anyone with the public key
92% of U.S. developers now use AI coding tools daily but only 29% trust the code those tools produce. That trust gap is the whole crisis in one stat
Projects with a high "vibe score" (polished presentation, little underlying substance) were found to be 3.2x more likely to be abandoned within 18 months, with 42% higher rates of critical vulnerabilities

Meanwhile, Gartner is projecting that ungoverned prompt-to-app development could increase software defect rates by 2,500% by 2028 if organizations don't put quality controls in place. That's not a typo, that's the scale of the gap between adoption speed and governance maturity.

Experience Level Changes the Outcome - A Lot

Not everyone gets the same result from the same tool, and this is where "vibe coding is great" vs. "vibe coding is a disaster" often comes down to who's holding the wheel:

Senior developers (10+ years) report the strongest gains around 81% productivity improvement because they use AI to offload routine work while keeping architecture and review under their own judgment
Mid-level developers see solid gains too, but spend meaningfully more time reviewing and correcting generated output
Junior developers get the most mixed results, a notable share admit they ship code they don't fully understand

That last point is the actual engineering risk. AI-assisted coding doesn't remove the need for engineering judgment, it just moves where that judgment has to happen, from writing to reviewing. If nobody in the loop has the judgment to review, the judgment simply doesn't happen.

So - Is It Good Software Engineering?

Software engineering, as a discipline, isn't really about how fast code gets typed. It's the set of practices, architecture, testing, review, security thinking, maintainability, that make software reliable over time, not just functional in a demo. By that definition:

Vibe coding, on its own, is not software engineering. It's a prototyping technique that happens to produce runnable code.

That's not necessarily an insult, sketching, prototyping, and fast iteration have always been valuable. The mistake is treating the sketch as the deliverable. The 63% of vibe-coding tool users who identify as non-developers (PMs, founders, designers) aren't doing anything wrong by building an internal tool this way the risk shows up when that prototype's code quietly becomes the production system with nobody applying engineering discipline to it retroactively.

Where AI Coding Adds Real Value

AI coding tools are at their best when they accelerate work without replacing engineering judgment.

They can be particularly effective for:

Rapid prototyping: Turn an idea into a working proof of concept before committing significant development resources.
Boilerplate and repetitive tasks: Generate common components, API structures, test cases, documentation, and other predictable code.
Exploration and experimentation: Try different approaches, libraries, or architectures quickly before deciding which direction makes sense.
Internal tools: Build lightweight dashboards, scripts, automations, and single-purpose applications where the risk and complexity are relatively low.
Developer productivity: Let experienced developers delegate routine implementation while they focus on architecture, problem-solving, and review.

The common thread is simple: AI handles more of the execution while developers remain responsible for the decisions.

Where Human Expertise Still Matters Most

The equation changes when the cost of getting something wrong becomes high.

AI-generated code deserves significantly more scrutiny when it involves:

Security-critical functionality: Authentication, authorization, payments, sensitive data, and access control require careful human review.
Complex business logic: AI may produce technically valid code that doesn't correctly reflect the rules or requirements of a business.
High-concurrency systems: Distributed systems, real-time applications, and concurrency-heavy code can fail in ways that aren't obvious from a simple code review.
Production-critical infrastructure: Code responsible for reliability, performance, deployment, or core services needs to be understood and tested by engineers who own the system.
Long-term architecture: AI can generate a solution that works today but creates unnecessary complexity, technical debt, or maintenance problems tomorrow.
Code nobody understands: The biggest risk isn't AI-generated code itself. It's shipping code that the team cannot explain, test, debug, or confidently change.

The Real Divide Isn't AI vs. Developers

The question shouldn't be “Should developers use AI?”

The better question is:

“Which parts of software development should we delegate to AI, and which decisions should remain human?”

AI can dramatically reduce the time it takes to produce code. But production software requires much more than code generation. It requires architecture, context, security, testing, accountability, and long-term thinking.

The strongest engineering teams aren't removing humans from the development loop.

They're using AI to make experienced engineers more effective.

The Bottom Line

Vibe coding isn't the villain the backlash makes it out to be, and it isn't the free lunch the hype promised either. It's a fast way to produce a shape of software. Whether that shape becomes real software engineering still depends on the same things it always did review, testing, architectural judgment, and someone in the loop who actually understands what shipped. The tools got faster. The bar for good engineering didn't move.

AI is changing how software gets built. The teams that benefit most won't simply be the ones using the most AI tools, but the ones that know where AI adds value, where human expertise matters, and how to bring the two together responsibly.

For more thoughts on AI, software development, and how the industry is evolving, follow Kilowott on LinkedIn and Instagram.

From Code to Outcome: How AI-Augmented Teams Are Redefining Software Delivery in 2026

Kilowott — Thu, 25 Jun 2026 11:57:46 +0000

"The future of software belongs to teams that combine human expertise with AI-powered execution."

For over a decade, we've helped brands and agencies turn ideas into software that delivers real business impact.

Along the way, we've learned that success happens when strategy and execution work hand in hand.

The gap between strategy and execution is closing, not because developers work faster, but because teams work differently.

This post explores what we're seeing across Manufacturing, Retail, E-commerce, Fintech, EdTech, Telecom, and Energy and what it means for structuring, equipping, and measuring modern software teams.

In this article, we'll explore:

How AI is changing the makeup of software teams
What the best teams are doing differently
Where human expertise still creates value
The tools and workflows enabling faster delivery
How success should be measured in the AI era

The Shift Nobody Fully Prepared For

A year ago, the conversation was still "should we use AI coding tools?" Today, that question is obsolete.

With over 92% of US developers using AI coding tools daily, the question has flipped: how do you build a team that uses AI well, not just one that uses it?

Today's AI-powered developers can:

Analyze entire codebases
Plan multi-file changes
Generate and run tests
Detect and fix failures
Iterate before human review

We're not talking about Copilot suggestions anymore.

We're talking about agentic systems that can read a codebase, plan changes across multiple files, write tests, catch failures, and iterate, all before a human reviews the output.

The 10x developer is becoming the 100x developer, not by writing more code, but by orchestrating systems that do.

What an Outcome Team Actually Looks Like

Traditional delivery teams are organized around roles: frontend, backend, QA, DevOps.

Outcome teams are organized around results: onboarding conversion, API response time, feature adoption, deployment frequency.

Here's what we've seen work across our software and application engagements in 2026:

1. AI as an Async Collaborator, Not a Tool

The best teams have stopped treating AI as a tab in the IDE. They treat it as an async collaborator with a specific role in the sprint.

It gets assigned tasks. It produces reviewable output. It gets feedback.
This changes how you write tickets, how you structure code, and how you run retros.

Typed, predictable systems matter more now, not because humans demand them, but because agents do.

When ambiguity is expensive, "boring" architecture becomes a competitive advantage.

2. MCP Is the Integration Layer Nobody's Talking About Enough

The Model Context Protocol (MCP) is quietly becoming the connective tissue of modern software stacks.

Think of it as a USB-C port for AI, a standardized interface that lets LLMs communicate with your APIs, internal tools, databases, and workflows.

If you're building developer tools, internal platforms, or anything that might be invoked by an agent, you should already be asking: is this MCP-compatible?

If it's not, you're building for a model of software delivery that's already passing.

This is especially critical for teams working on web and ecommerce platforms, where the surface area for agent-driven interactions (inventory queries, personalization, checkout flows) is growing rapidly.

3. TypeScript Didn't Win by Accident

GitHub's Octoverse confirmed what many of us had already felt: TypeScript overtook both Python and JavaScript to become the most-used language on GitHub as of August 2025.

That's the most significant language shift in over a decade.

The reason isn't just developer preference. It's that typed systems are easier to reason about for humans and agents alike.

When you're reviewing AI-generated code, type safety is your first line of defense. Predictability compounds at scale.

The Delivery Problem That AI Alone Can't Fix

Here's the honest part:

AI doesn't solve delivery problems caused by unclear ownership, misaligned stakeholders, or poor requirements. It amplifies whatever process you already have.

We've seen teams use AI to ship bad software 10x faster. That's not a win.

What actually works is pairing AI capability with human oversight at the right checkpoints. The teams winning right now:

Establish governance policies for what agents can do autonomously vs. what requires approval
Measure AI's actual impact on delivery metrics, velocity, defect rates, rework, not just vibes
Design systems for AI from the start, not as an afterthought. If your architecture isn't legible to an agent, you're leaving productivity on the table

This is the work. Not the tooling selection, the governance, the measurement, the system design.

"The biggest gains from AI don't come from better tools. They come from better systems."

What We're Building Toward

At Kilowott, our Kilowott Intelligence practice is built around exactly this challenge: helping businesses harness AI systems that streamline workflows and scale efficiently, combining smart technology with human oversight to deliver measurable results.

That means we're not just building software. We're building the operating model around it.

Some things we're actively working on with clients right now:

Agentic QA pipelines that catch regressions before they reach staging
MCP-connected internal tools that let AI surface the right data at the right moment in the delivery cycle
Cross-functional outcome teams through our software and applications practice that blend our specialists with client stakeholders, structured around KPIs rather than deliverables

Where This Goes Next

Success in the AI era belongs to developers and organizations that know how to work alongside intelligent systems—not compete with them.

The same is true at the organizational level.

The companies winning right now aren't the ones with the most AI tools, they're the ones who've built the processes, governance, and team structures to use them with intention.

We're a decade into helping businesses navigate exactly this kind of transition. Technology changes. The fundamentals don't.

If you're thinking about how to evolve your delivery model, whether you're an agency, a growing product company, or an enterprise navigating transformation, we'd love to compare notes.

"Tools will continue to change. The organizations that thrive will be the ones that learn faster than the technology evolves."

Let's talk, we call this the shift from execution teams to outcome teams. The difference is subtle but massive in practice.

Stay updated with the latest trends in development, AI, and digital innovation, follow us on: LinkedIn | Instagram