+1. I’m seeing this so much every day while working with some reputed engineering teams. hard to believe how much the quality bar to pushing stuff to production has lowered because of this belief that anyone with a claude plan is “engineering”. Production experience and intuition is worth its weight in gold for anything serious.
Makes me want to work more closely with juniors and new engineers, more so than before. And ask myself if I am being a slave to the past - sometimes the answer is a resounding yes.
Some observations after meeting (a lot of) engineering leaders and engineering middle management -
- almost everyone i met is reactive to coding agent phenomenon, very few are proactively attacking customer problems with novel solutions. sometimes I feel that unlearning and age creates this situation where senior leaders are still not able to break through the ceilings that their experience has created
- almost every senior dislikes how new engineers are wholly dependent on coding agents, privately they disparage even. small mistakes from juniors with coding agents are treated with apocalyptic alarms and doom prophecies. this is also clouding their judgement and strategies, unfortunately
- hiring is still the biggest problem, and once again, almost no one has changed the way they hire - still over-indexing on college degrees and previous jobs. they know the problem but are unable to solve it.
- while most didn't vocalise this as their biggest concern, but work prioritisation seems to be a huge problem for them. backlogs for many have grown exponentially, and so have expectations. strong leaders are able to navigate, weaker ones are feeling the stress from both directions - CEOs and engineers.
- almost everyone is floating over agents, basically if an agent makes something that is like 90% correct, they are ok with it. no one is looking at code. craftsmanship has moved up a level of abstraction and I am not yet clear as to what it means in 2026
Some observations after meeting (a lot of) engineering leaders and engineering middle management -
- almost everyone i met is reactive to coding agent phenomenon, very few are proactively attacking customer problems with novel solutions. sometimes I feel that unlearning and age creates this situation where senior leaders are still not able to break through the ceilings that their experience has created
- almost every senior dislikes how new engineers are wholly dependent on coding agents, privately they disparage even. small mistakes from juniors with coding agents are treated with apocalyptic alarms and doom prophecies. this is also clouding their judgement and strategies, unfortunately
- hiring is still the biggest problem, and once again, almost no one has changed the way they hire - still over-indexing on college degrees and previous jobs. they know the problem but are unable to solve it.
- while most didn't vocalise this as their biggest concern, but work prioritisation seems to be a huge problem for them. backlogs for many have grown exponentially, and so have expectations. strong leaders are able to navigate, weaker ones are feeling the stress from both directions - CEOs and engineers.
- almost everyone is floating over agents, basically if an agent makes something that is like 90% correct, they are ok with it. no one is looking at code. craftsmanship has moved up a level of abstraction and I am not yet clear as to what it means in 2026
slow, measured steps. learn, steady up, then accelerate!
at @base14io we started 2026 ready for the next on reliability engineering.
in the last quarter, we have added new customers, and with their help, we have built some really cool and valued products -
👉 AI SRE pair - work with it to do RCAs, manage incidents with our slack integration, automate repeated tasks and reports (soon on Teams and CLI)
👉 Context Graph - a graph that summarises the whole system, real time
👉 Scout MCP - agent access to the context graph and telemetry data, customer report debugging time from ~15 minutes to seconds.
👉 Scout CLI - human and agent access the context graph and telemetry data
the context graph and telemetry data
👉 Scout CLI - validate and optimise your otel configs like a boss (open source)
👉 Scout Flutter instrumentation - by far the simplest and easiest way to instrument your flutter apps, 0 maintenance needed
👉 RUM - pinpoint issues, analyse user behaviour, trace from clicks to DB calls. easy UX, and already available to agents that PMs use.
👉 Prompt Management - improve your harness and multi-agent interactions with prompt management built-in Scout (evals coming soon)
👉 AWS monitor - monitor all your AWS assets and costs in one place, right next to where you observe how your apps are performing, no switching
👉 Scout on Azure - ready for the enterprise
👉 eBPF - zero code instrumentation for golang, python, rust, .Net and many more
and a lot of other interesting customisations, system improvements to ensure uptime and scale, 2 new cloud regions. This quarter is going to be even more exciting!
this perhaps is an India/SEA specific issue - VPs/CTOs generally do not consider the human cost and cost of salaries/personnel as part of their operational costs. I wonder why this is ?
for eg-
- our cost of "x" is zero because we use open source product (while 4 of the best engineers are busy managing it)
- i don't think we should pay N dollars for this (but we are hiring a couple of experts who will cost 5-10 times N)
contrary to popular belief - it is not the ability to express, but the ability to patiently read and comprehend, that will prove to be very advantageous for software engineers using coding agents.
almost everyone told me that in early-stage startup sales, founders are the product. i bought into it. and i think its incomplete advice that can be quite dangerous if not understood well.
it helped us get our 1st set of design partners. but last 12 months have taught me one more thing - the market does not care about your resume/past.
"founders are the product" is a statement about founders' expertise, vision and passion. not the resume.
Thanks. Indeed, service profile and dependency graph are quite helpful. Fetching and storing locally once a session.
Service profile - Current prod props like stats on spans, last few alerts and internal metrics, infra it’s hosted on etc.
Dependency graph - service map including internal & external services, components etc.