Four months ago, a front-end engineer on my team looking to make upgrades to a product or feature would have filed a ticket and waited for the infrastructure group to unblock them. They might have lost a day, sometimes a week. Today, that same engineer makes changes themselves. The code is occasionally brittle, but it works, and the end result ships in a fraction of the time it used to take.

That small story is unfolding inside nearly every engineering organization right now. While some celebrate the sudden fact that one person can do the work of five, others are focused entirely on tech industry layoffs. Both perspectives skip the question I find more interesting: What happens to mastery when every engineer can suddenly do everything?

For two decades, we have described strong engineers as T-shaped. The horizontal bar represents breadth, which is a working familiarity across many areas. The vertical bar represents depth, the real command of one domain earned over years. Agent tooling has stretched that horizontal bar wider than ever before. My concern is the vertical bar, which is quietly getting shorter.

Consider what is now possible in a single quarter. With the right agent harness, one engineer can stand up a billing system, a data connector framework, regional and organizational tenancy infrastructure, or a consumption-based pricing implementation. The pull requests pass review. The tests are green. All looks good. But green tests cannot tell you if the person who shipped that work understood why the system needs redundancy in one specific place, where its failure modes are hiding, or which trade-offs the model made silently on their behalf. The pattern recognition that comes from watching systems fail over many years is suddenly weighted differently than it was even 12 months ago. Our industry has not caught up to that shift.

When the interview stops measuring judgment

The first place this surfaces is hiring, a trend that should concern anyone who has built a team. Traditional coding interviews were always an imperfect proxy for engineering judgment, but agent tooling completely obliterates them. If a candidate can produce a working solution in 20 minutes that would have taken two hours a year ago, the exercise no longer measures technical competence. It just measures how well a coder can prompt an agent.

At Thread AI, we have responded by widening what we look at when we interview job candidates. Our process moves across coding exercises, problem decomposition, system architecture, and behavioral components, with the weighting shifting by role. We allow AI assistance only in specific sections because our engineers still need to be able to operate without it. Some of our work happens in secure environments where you cannot lean on an agent to debug for you. What we’re really testing for now is judgment under ambiguity — the ability to notice when an agent’s output is confidently wrong — and the depth to predict where a system will break before it breaks.

Hiring teams that fail to make this shift will fill their rosters with false positives. They will hire people who interview like experts but struggle the first time a system behaves in a way the model did not anticipate. Ultimately, these companies will miss out on top-tier talent, and they won’t discover the misstep until it’s too late.

Confusing velocity with understanding

That brings me to a larger risk: the rise of false expertise as a category of its own. Historically, the reasoning has gone, “I built a proof of concept, therefore I am an expert.” I have watched versions of this appear in technical leadership, in investment decisions, and in policy conversations about AI. It travels well because the artifact looks real. A working demo is highly persuasive, even when the person behind it only half-understands how it functions.

The problem is bigger than one false expert shipping one bad product; an organization can absorb that. The real risk is a generation of consequential decisions being made by people who have confused velocity with understanding. You can already see the cultural scaffolding being built around this with the celebration of the “idea guy,” and the sudden fashion for invoking “taste” as a substitute for knowing how a system actually works. Those of us shaping tooling, hiring norms, and regulations have a narrow window to set better defaults before this pattern hardens into the way the industry operates.

Depth and breadth, held together

This is the path we’ve been walking at Thread AI since before the latest wave of tooling arrived.

To ground this in a specific example: I have spent 15 years building complex systems. I worked at Goldman Sachs through the financial crisis and the early Dodd-Frank infrastructure, moved critical payment systems into the cloud at The New York Times when that ground was still new, and built the system of record for model training and evaluation at Palantir across highly regulated environments in defense, health, and finance. This experience is the superpower that lets me course-correct an agent when it produces confident-but-wrong output.

I felt this sharply not long ago while scoping consumption-based pricing in a single quarter. The agents did an enormous amount of the heavy lifting, and at some point, I realized that my largest contributions to the effort were knowing where the system would fail and steering around it before we got there. I have also seen how organizations have built large teams around efforts like these in the past. Someone earlier in their career or relying purely on AI guidance would not have had that instinct to draw on. That is the part the public conversation keeps missing.

Every engineer at Thread AI, regardless of seniority, is expected to be a builder at heart. Our people own outcomes across compute, data, and the organizational and identity primitives that hold the product together, all without the traditional product-manager and project-manager scaffolding around them. Our model works only because the people in those seats have the depth to know what they do not know, and the breadth to fill the gaps with agents. They use the tooling instead of being used by it.

AI doesn’t replace deep understanding

The core issue facing organizations today is not whether AI will replace engineers. That question has been answered dozens of times this year with varying degrees of nuance, and it has stopped being interesting. The more useful question for anyone running a company is whether we are protecting the people who understand our systems deeply enough to recognize when the machines are wrong.

In our company, the answers have been to move toward explicit end-to-end ownership, and to hire for depth and breadth together rather than treating them as a trade-off. Layoffs dominate the headlines because they are an easy narrative, but they describe a symptom rather than the actual choice in front of us. The real choice is whether we let breadth quietly stand in for mastery, or whether we build organizations that keep human judgment in the loop on purpose.

In an era when software can be generated faster than it can be understood, the companies that hold onto what is human, verifiable, and deeply understood will be the ones still standing when the brittle parts give way.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Four months ago, a front-end engineer on my team looking to make upgrades to a product or feature would have filed a ticket and waited for the infrastructure group to unblock them. They might have lost a day, sometimes a week. Today, that same engineer makes changes themselves. The code is occasionally brittle, but it works, and the end result ships in a fraction of the time it used to take.

That small story is unfolding inside nearly every engineering organization right now. While some celebrate the sudden fact that one person can do the work of five, others are focused entirely on tech industry layoffs. Both perspectives skip the question I find more interesting: What happens to mastery when every engineer can suddenly do everything?

For two decades, we have described strong engineers as T-shaped. The horizontal bar represents breadth, which is a working familiarity across many areas. The vertical bar represents depth, the real command of one domain earned over years. Agent tooling has stretched that horizontal bar wider than ever before. My concern is the vertical bar, which is quietly getting shorter.

Consider what is now possible in a single quarter. With the right agent harness, one engineer can stand up a billing system, a data connector framework, regional and organizational tenancy infrastructure, or a consumption-based pricing implementation. The pull requests pass review. The tests are green. All looks good. But green tests cannot tell you if the person who shipped that work understood why the system needs redundancy in one specific place, where its failure modes are hiding, or which trade-offs the model made silently on their behalf. The pattern recognition that comes from watching systems fail over many years is suddenly weighted differently than it was even 12 months ago. Our industry has not caught up to that shift.

When the interview stops measuring judgment

The first place this surfaces is hiring, a trend that should concern anyone who has built a team. Traditional coding interviews were always an imperfect proxy for engineering judgment, but agent tooling completely obliterates them. If a candidate can produce a working solution in 20 minutes that would have taken two hours a year ago, the exercise no longer measures technical competence. It just measures how well a coder can prompt an agent.

At Thread AI, we have responded by widening what we look at when we interview job candidates. Our process moves across coding exercises, problem decomposition, system architecture, and behavioral components, with the weighting shifting by role. We allow AI assistance only in specific sections because our engineers still need to be able to operate without it. Some of our work happens in secure environments where you cannot lean on an agent to debug for you. What we’re really testing for now is judgment under ambiguity — the ability to notice when an agent’s output is confidently wrong — and the depth to predict where a system will break before it breaks.

Hiring teams that fail to make this shift will fill their rosters with false positives. They will hire people who interview like experts but struggle the first time a system behaves in a way the model did not anticipate. Ultimately, these companies will miss out on top-tier talent, and they won’t discover the misstep until it’s too late.

Confusing velocity with understanding

That brings me to a larger risk: the rise of false expertise as a category of its own. Historically, the reasoning has gone, “I built a proof of concept, therefore I am an expert.” I have watched versions of this appear in technical leadership, in investment decisions, and in policy conversations about AI. It travels well because the artifact looks real. A working demo is highly persuasive, even when the person behind it only half-understands how it functions.

The problem is bigger than one false expert shipping one bad product; an organization can absorb that. The real risk is a generation of consequential decisions being made by people who have confused velocity with understanding. You can already see the cultural scaffolding being built around this with the celebration of the “idea guy,” and the sudden fashion for invoking “taste” as a substitute for knowing how a system actually works. Those of us shaping tooling, hiring norms, and regulations have a narrow window to set better defaults before this pattern hardens into the way the industry operates.

Depth and breadth, held together

This is the path we’ve been walking at Thread AI since before the latest wave of tooling arrived.

To ground this in a specific example: I have spent 15 years building complex systems. I worked at Goldman Sachs through the financial crisis and the early Dodd-Frank infrastructure, moved critical payment systems into the cloud at The New York Times when that ground was still new, and built the system of record for model training and evaluation at Palantir across highly regulated environments in defense, health, and finance. This experience is the superpower that lets me course-correct an agent when it produces confident-but-wrong output.

I felt this sharply not long ago while scoping consumption-based pricing in a single quarter. The agents did an enormous amount of the heavy lifting, and at some point, I realized that my largest contributions to the effort were knowing where the system would fail and steering around it before we got there. I have also seen how organizations have built large teams around efforts like these in the past. Someone earlier in their career or relying purely on AI guidance would not have had that instinct to draw on. That is the part the public conversation keeps missing.

Every engineer at Thread AI, regardless of seniority, is expected to be a builder at heart. Our people own outcomes across compute, data, and the organizational and identity primitives that hold the product together, all without the traditional product-manager and project-manager scaffolding around them. Our model works only because the people in those seats have the depth to know what they do not know, and the breadth to fill the gaps with agents. They use the tooling instead of being used by it.

AI doesn’t replace deep understanding

The core issue facing organizations today is not whether AI will replace engineers. That question has been answered dozens of times this year with varying degrees of nuance, and it has stopped being interesting. The more useful question for anyone running a company is whether we are protecting the people who understand our systems deeply enough to recognize when the machines are wrong.

In our company, the answers have been to move toward explicit end-to-end ownership, and to hire for depth and breadth together rather than treating them as a trade-off. Layoffs dominate the headlines because they are an easy narrative, but they describe a symptom rather than the actual choice in front of us. The real choice is whether we let breadth quietly stand in for mastery, or whether we build organizations that keep human judgment in the loop on purpose.

In an era when software can be generated faster than it can be understood, the companies that hold onto what is human, verifiable, and deeply understood will be the ones still standing when the brittle parts give way.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

For a long time, I thought of observability as something mainly owned by backend, platform or site reliability teams. Frontend engineers built the interface, handled browser behavior and called APIs. When something failed deeper in the system, another team looked at server logs and infrastructure dashboards.

That division works until the application is technically available, but the user experience is not.

A page may load while its most important data arrives several seconds late. A request may succeed after multiple retries, leaving the user staring at a spinner. One cloud service may slow down while the rest of the page continues working. From an infrastructure perspective, nothing may qualify as an outage. From the user’s perspective, the application is already failing.

As I gained more experience building applications that depended on cloud services and APIs, my view of frontend ownership changed. A frontend team does not need to operate every service it depends on, but it does need enough visibility to understand how those services affect the experience it delivers.

Observability gives frontend engineers that visibility. It helps connect what happens in the browser with what happens across the systems behind it. More importantly, it gives teams evidence they can use not only to debug problems, but also to make better decisions about how the frontend should behave when dependencies are slow, unavailable or inconsistent.

The browser sees a different version of the system

Server-side monitoring tells us what happened inside a service. It does not always tell us what happened across the user’s complete journey.

A backend dashboard might show that an API responded in 300 milliseconds. The browser may still take much longer to display useful content because of network latency, JavaScript execution, rendering work or additional requests. A successful response can also produce a broken experience if the returned data is incomplete or the interface fails while processing it.

This is why client-side telemetry matters. Browser error reporting can capture exceptions that never reach a server. Performance measurements can show how long users wait for content to become visible or interactive. Request data can reveal which dependencies are slow, unreliable or frequently retried.

Standard browser APIs provide useful starting points. The W3C User Timing API allows developers to mark and measure meaningful operations in an application. A team can measure how long it takes to load a dashboard, complete a search or render a critical section of a page.

Web Vitals can also help teams examine loading performance, responsiveness and visual stability using measurements tied more closely to the user experience. These metrics are useful because they move the conversation beyond whether a request succeeded. They help answer whether the page became useful quickly and respond when the user tried to interact with it.

The goal is not to collect every browser event. That can produce a large amount of data without producing much insight. It is better to begin with a small set of questions.

How long does the user wait before the main content appears? How often does a form submission fail? Which request prevents a page from becoming usable? Are users on certain devices or network conditions affected more often?

These questions make telemetry easier to design and easier to interpret. “The API is available” is a service-level statement. “The user can complete the task without an unexpected delay” is an experience-level statement. Frontend observability helps connect the two.

Logs and traces connect the frontend to its dependencies

Client-side logs are most valuable when they include enough context to reconstruct what the user was doing. A useful error record might include the application version, route, operation, request status and a correlation identifier. Browser information may also help when an issue affects only certain environments.

At the same time, frontend telemetry should be designed carefully. Logs should avoid form contents, authentication tokens, passwords and other sensitive information. Collecting more data does not automatically make an investigation easier. The right context is more useful than a large amount of unstructured information.

Correlation identifiers are particularly helpful. When the frontend includes an identifier with a request and that identifier continues through downstream services, teams can connect a browser failure to backend logs and distributed traces. Instead of comparing timestamps across several dashboards, engineers can follow one request across the system.

A distributed trace can show that a user action triggered an API gateway, an application service, a database call and another cloud dependency. It can also show where the request spent most of its time or where an error first appeared.

OpenTelemetry provides a vendor-neutral approach for generating and connecting telemetry such as traces, metrics and logs. It also supports JavaScript and browser instrumentation, which makes it relevant to frontend teams that want to connect browser activity with backend services.

Frontend engineers do not need to become observability platform specialists. They do need agreement with backend and platform teams on basics such as trace propagation, naming conventions, safe logging fields and where telemetry can be reviewed during an investigation.

Consider a page that occasionally loads without its main data. The frontend may record that a critical request timed out after several seconds. A correlation identifier from that request may lead to a trace showing that the gateway responded normally, but a downstream dependency exceeded its timeout.

Without connected telemetry, the report might remain, “The page sometimes does not load.” With connected telemetry, the team has a specific failure path, a measurable delay and enough evidence to decide what needs to change.

That evidence can support two actions. The service team can investigate the slow dependency. The frontend team can improve the experience by adding a timeout state, retry option or partial fallback. Observability makes both responses more precise.

Observability should influence architecture, not only debugging

The immediate benefit of observability is faster incident investigation. The larger benefit is better architectural decision-making.

When telemetry repeatedly shows that one dependency is slow, the frontend team can reconsider how tightly the interface depends on it. The page might render primary content first and load secondary information later. Cached data might be acceptable for a noncritical section. A timeout might lead to a smaller fallback instead of blocking the entire screen.

Observability can also expose hidden coupling. If unrelated components fail whenever one shared request slows down, the page may have been designed as a single loading unit. Breaking the experience into independently recoverable sections can make the interface more resilient.

The same evidence can improve retry behavior. Automatic retries may help with a temporary network failure, but they can also add more traffic to an already slow service. Telemetry can show whether retries recover requests, how long the recovery takes and whether users leave the page before it succeeds.

Service-level visibility matters as well. Frontend teams should understand the availability and latency expectations of the services they use. They should also understand what those services return during partial failures.

If a dependency may respond slowly, the interface needs a loading strategy. If data may be stale, the interface needs to communicate freshness. If a service is optional, the page should not collapse when it is unavailable.

Good observability also improves conversations between teams. Instead of saying, “The page feels slow,” frontend engineers can explain which user action is affected, how often it happens and where the delay appears. Debugging becomes a discussion based on evidence rather than guesswork.

A practical starting point can be small. Capture unhandled browser errors. Measure a few important user journeys. Record failures for critical network requests. Propagate a correlation identifier across frontend and backend systems. Review those signals with the teams that own dependent services.

From there, instrumentation should grow in response to real questions. Add a measurement when a workflow is difficult to understand. Add a trace when a request crosses several systems. Add a dashboard when a signal is important enough to review regularly.

Frontend observability is not about turning every frontend engineer into an operations engineer. It is about recognizing that the browser is part of the production system and often the only place where the complete user experience is visible.

When frontend teams can connect what users experience with the services behind it, they can debug more effectively, design interfaces that degrade gracefully and make better architectural decisions. Observability becomes more than a way to explain incidents. It becomes an input into how frontend systems are designed.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

I was blessed with a terrific high school English teacher. Ms. Jewel was funny, kind, interesting, and tough on us. I can still spell “ecstasy” on the first try because of her. One of the more memorable lessons she taught was a “Hemingway and Fitzgerald” module. 

I loved the short stories of both, but Hemingway’s work always stuck out for me. It’s cliché to say that Hemingway was terse, but we only say it because it is true. He could pack more into a page than most writers. He didn’t waste a syllable. 

Software developers are soon going to have to take a lesson from Hemingway.

It’s not hard to be concise in code. You have to be, by design. The compiler won’t put up with any throat-clearing and jibber-jabber. You can’t meander. You have to use a very strict set of words and symbols, and you have to use them in a defined way. 

Thanks to agentic development, we don’t write code anymore. But we are writing for the agents. A lot. 

All about the spec

Let me explain. Claude Code, Codex, Copilot, and the rest all love to be “spoken” to in Markdown. We used to define our code with unit tests and specifications written for humans. Now, it’s all about the spec. And the spec needs to be both complete and concise. 

It needs to be complete in the sense that if you leave something out or forget to define something, the agent will very likely fill in the gaps for you. Forget a feature or requirement, and the agent will go off confidently and almost certainly in the wrong direction.

At the same time, you need to be concise. Because if you are too effusive, you may give the agent ideas that you don’t want it to have. If you write like Fitzgerald — lush and expansive —  the agent will be off and running in a direction you can’t be sure about. 

Our compilers will stop cold if we aren’t precise and concise. Our agents? They will proceed with confidence, diligently producing a result that looks great but isn’t what we want.

So we need to learn to write like Hemingway and pack as much meaning into as few words as possible. Or, as Paul Graham said:

Let’s be clear

For years, we’ve been writing semi-vague Jira tickets and expecting our fellow humans to fill in the gaps and “get the gist” of what we were trying to do. We don’t have that luxury anymore. Developers who aren’t able to move on from “Jira-speak” to “Agent-speak” are going to struggle. If we don’t follow Graham’s advice in writing those specs, who knows what we’ll get.

Maybe someday agents will know the ins and outs of our business well enough to “know what we mean,” but they can’t today. The time we used to spend coding now needs to be spent perfecting our new craft of writing precise specifications for our agents to execute.

Every listicle ever written on “How to be a Great Developer” says you need to be a great communicator — but that was communication with other humans. 

Ms. Jewel always taught us that our writing is only as clear as our thinking. Our compilers forced us to write clearly. Our coding agents won’t do that. I’m sure there are many developers out there now who wish they had listened more closely to their high school English teacher.