Good morning,

An AI demo can make a task look straightforward. Put it inside a real business, and the questions multiply. Where does the data come from? Which exceptions matter? Who takes over when something goes wrong?

Answering those questions takes engineering—and time spent understanding the people doing the work.

This week, we look at a growing investment in engineers who work closely with customers to turn AI capabilities into working systems, and what that could mean for the profession.

On 8 September, Accenture and Google Cloud announced a new Gemini Enterprise business group, including plans to establish a 1,000-person forward-deployed engineering workforce. The stated focus includes customer implementations, industry-specific solutions and adoption across organizations. This is a planned workforce, not a claim that 1,000 engineers are already deployed.

“Forward-deployed engineer” needs a little unpacking. Think of an engineer working close enough to a customer’s operations to understand the problem, build the solution and help make it work in practice.

Consider a hypothetical customer-support team. A demonstration shows an AI agent reading a complaint, finding the relevant policy and drafting a helpful response. It looks promising.

Then implementation begins.

Customer details live in one system. Order history lives in another. The refund policy has exceptions that experienced staff know but nobody has documented clearly. Some actions require a supervisor’s approval. A failed integration could leave a customer with a reassuring message and no actual refund.

The model’s ability to write a good response is useful. Getting this workflow to function requires considerably more work.

An engineer close to the customer can observe how staff handle difficult cases, identify which system holds the authoritative information, connect the necessary services and define when the agent should hand work back to a person. After deployment, someone must investigate failures and check whether customers actually get their problems resolved sooner.

That combination of technical implementation and operational understanding is the part worth watching.

My reading of the Accenture–Google Cloud announcement is that major providers see enough demand for this work to invest in dedicated engineering capacity. Model access gives customers a starting point; implementation determines what they can do with it.

There is a fair objection: haven’t good consultants, integration engineers and solutions architects always worked this way?

Often, yes. The title alone tells us very little. The meaningful questions are whether these engineers write and maintain production software, have access to the people doing the work, and remain accountable beyond a successful demonstration. A new label attached to the same distant handoffs would change little.

The announcement also does not establish that embedded teams consistently outperform other delivery models. Close customer involvement can reveal important requirements, but extensive customization can create expensive systems that are difficult to maintain or reuse.

For working engineers, I would take this as a reason to strengthen a combination of skills: understanding a business process, integrating systems, evaluating AI behavior and operating the result reliably.

You do not need a new job title to practise that. On your next AI project, spend time with the person who will use it. Ask them to show you an exception, a workaround and a case where getting the answer wrong would matter.

Those conversations can reveal engineering requirements that a polished demo never encounters.

A September revision of an NBER study covering more than 500,000 GitHub developers reports a striking gap. Autonomous coding-agent adoption was associated with estimated increases of 240% in commits, 80% in projects and 30% in releases. In other words, the increase in recorded code changes was much larger than the increase in released software.

The study is observational, and releases do not directly measure customer value. It also cannot tell your team exactly where work is getting stuck. But it suggests a useful measurement habit: put coding activity beside delivery time, review queues and rework. If implementation speeds up while changes wait longer for integration or release, that is where the next improvement may be needed.

Google’s latest threat report documents attackers manipulating coding-assistant configuration files and compromised software packages. It also describes malicious instructions intended to make AI security scanners skip or refuse analysis of malicious code. These are observed techniques, although the report does not establish how widespread they are.

Why do configuration files matter? An assistant may read them to learn how to build a project, which tools to use or which commands to run. That makes them a way to influence its actions. Review changes to agent instructions, startup hooks and tool configurations alongside application code—especially when they introduce commands, dependencies or permissions. A file that looks like setup guidance can still affect what executes on your machine.

NASA and IBM released a lunar foundation model on 10 September, alongside a dataset combining more than 30 aligned data layers from nine instruments across four missions. Researchers can adapt it to tasks such as identifying craters and potential ice deposits.

The useful engineering detail is the shared starting point. Observations collected by different instruments, at different resolutions, have been brought into a common representation that researchers can reuse across questions. That reduces the need to rebuild the data preparation and modeling approach for each task. Reported benchmark improvements come from the developers, and predicted features still need scientific validation. But the broader lesson travels well: making fragmented data usable together can be a substantial part of an AI system’s value.

This week, while setting up registration for a Software Signal learning session, I considered building the email-capture flow into my website.

At first, it looked like a small engineering task: show a form, collect an email address and store the registration.

But that description left out most of the responsibility.

Someone registering also needs confirmation. They need the joining details and a reminder before the session. I need a usable attendee list and a way to manage the event without spending the morning troubleshooting registration.

Once we considered that whole flow, the decision changed. We chose Luma to handle registration and event communications, with the website directing people to it.

The useful lesson was in how we framed the choice. Comparing a custom form with an event platform made building look straightforward. Comparing the complete operational responsibilities made the trade-off clearer.

Building can still be the right decision when requirements justify the ownership. But before estimating the code, ask:

What has to keep working after someone clicks Submit—and who will be responsible for it?

That question helped me keep the implementation aligned with the actual goal: delivering the session.

Researchers asked: Does AI help professionals develop skills they can use later without it, or mainly improve their work while the tool is available?

They studied 133 patent lawyers across 11 firms, randomly assigning access to an AI drafting assistant. They compared drafting quality after 10 days and three months. Then everyone reviewed a patent application without AI. Expert assessors scored the work without knowing who had received AI access.

AI improved drafting quality, especially for junior lawyers. But on the later test without AI, improvements were concentrated among senior lawyers. Juniors showed no average improvement—not an average decline. Better assisted output had not translated into equal learning gains.

Read MIT’s research summary.

The findings concern lawyers, but the question matters for engineering mentors too: What can someone now explain or judge independently after working with AI?

If this week’s story left you wondering what these engineering roles involve—and what you would need to learn—I’m exploring that in a free live online session next Saturday.

5 AI Engineering Roles Growing in 2026 — and What You Actually Need to Learn

We’ll look at Forward Deployed Engineer and four related roles, the skills behind them, and where tools such as Python, RAG and MCP fit.

Saturday, 19 September · 11:00–11:30 AM IST

See the session details and register free.

I’d be glad to have you join me.

Suyog