Harder Now, Not Optional Now

What humanistic engineering leadership actually requires in an AI-augmented organization.

It’s been a wild six to eight months in software engineering, and I’ve had the unusual vantage point of watching it from the outside while between roles. Distance has a way of making the shape of things clearer.

Here’s the shape I see: the loudest voices in the room right now on agentic implementation belong to Meta, OpenAI, Anthropic, Google, Amazon, Microsoft, Cursor, and xAI. They are producing thought leadership and implementation guides at a remarkable pace. What they are not producing, in any serious quantity, is guidance on how to operate an engineering organization in a world where those tools are in use. That gap is not accidental. Every one of those companies is in a race to capture as much market share as possible before the field consolidates and the winners become clear. The marketing, the thought leadership, and the guides all serve that goal. Operating guides don’t.

I want to be honest that I can’t prove the causation there. But I’ve been in enough rooms to recognize when the advice being offered serves the advisor as much as it serves me.

What I can speak to is what’s actually changing at the team level. Engineers are shipping features faster. They’re doing it with less shared understanding of the code being built, with junior engineers developing fewer of the foundational instincts that used to come from writing the thing yourself, with specifications getting more detailed and front-loaded in ways we spent a decade moving away from, and with QA coming back in some form after years of pretending code review was an adequate substitute for it. Production stability remains exactly as hard as it has always been, if not harder.

And here’s what none of that disruption changes: the business still needs the correct prioritization, well-built products, stable production environments, and predictable delivery from its Engineering organization. It needed those things before agents. It needs them now. The question worth asking is whether the practices that produced those outcomes still apply, and if so, what it actually takes to maintain them when half your team is prompting agents instead of writing code.

I can answer that from my own workflow, because I’ve been running one.

I’m still using a ticketing system, because tickets track units of work and they remain the best reflection and communication tool of delivered value for the rest of the business. All tickets still get story points. An agent attaches the points, but the scale is human. Agile has spent years trying to convince us that story points are not time, and Agile is technically right and practically wrong. Human beings think in time. We guess at the amount of time needed based on what we know, then we pad for risk and unknown. The human-scale estimation is useful for exactly two things: understanding the size and scope of an effort during prioritization, and curating a velocity measure that recognizes not all items are the same size.

I’m still doing two-week sprint planning, because I need to make deliberate decisions about what I think is going to get done and what the current priorities actually are. I still make trades within a sprint when something higher-priority surfaces, because capacity is not infinite even when execution is faster. I still try to hold to a predictable velocity, because the business needs to trust that what I say will get done will get done. That doesn’t change because an agent is doing the implementation.

What does change is what the velocity numbers reveal. If you have historical data from a pure-human team and you keep the same estimation scale after introducing agents, you will see an inflection point. You didn’t change the ruler. You changed how fast the work moves through the development phase. The result should be a visible lift in throughput. It also creates an artifact to key other metric changes against, positive and negative.

The question is what that lift does to everything downstream. Code review still takes time. QA still takes time. Deployment still takes time. Each phase of your process that isn’t agent-powered is now a potential bottleneck, and the velocity data will tell you where the next constraint is sitting. If your review process was already slow or inconsistent before you introduced agents, the agent didn’t fix it. It made it the most visible problem you have. That’s not a problem the implementation guides are talking about, because the implementation guides are focused on the development phase. They’re selling you on what the agent can do in that phase. They’re not telling you what happens to your cycle time distribution when one phase gets dramatically faster.

My code review process is fully agentic, and in many situations it’s slower than the implementation phase it’s reviewing. I architected it deliberately: three different models review each change independently, then a final pass collects all the feedback, triages it, and verifies the findings, because agents hallucinate and the findings need a layer of validation. My role is to evaluate what they surfaced, make my own decisions about what should be addressed and what can be deferred, and guide the model through those findings.

Almost nothing gets through on a first pass. Most changes require three to four rounds because the models will always find something new, often finding something new in the change that was just made to address the previous round. The question is whether what they’re finding is real and whether it matters. Eventually you can get to a state where everything surfaced is informational, but the agent’s job is to find something, so something always gets surfaced. I’ve never had a code review return no findings.

I still go look at the code myself when a proposed solution conflicts with my mental model of the system. What I usually find when I do is that the model is proposing something more complex than necessary. It has a bias toward complexity. It wants to solve the problem thoroughly, and thoroughly often means elaborately.

I have two concrete examples of what that looks like from the last 48 hours.

In the first example, the agent proposed a mapping system in onboarding and admin to handle how customers configure their Jira columns, which it had decided was necessary for tracking cycle time and SLAs correctly. Eight to thirteen points of new work, well-reasoned on its face. The signal that something was off was that it was proposing to treat one ticket type differently than every other ticket type in the system. That inconsistency didn’t fit my mental model, so I stopped and asked why before the work started. What we found when we dug in was that the premise was wrong. The data we needed was already there. We already had the statuses. We didn’t need to map anything. The agent had previously built complexity to solve a problem that didn’t exist, and then used that complexity as the justification for more complexity. The cost of unwinding the initial unnecessary implementation was 32 points of cleanup work.

In an organization where nobody feels safe questioning a well-reasoned ticket, that work gets built. The cleanup already cost 32 points and the agent was more than eager to add another 13 points on top of it. The psychological safety to say “wait, why are we doing this differently” is not a soft culture concern. It is a direct cost control mechanism. If that safety didn’t exist before the agents arrived, the agents aren’t bringing it with them.

The second example happened this morning, and it’s the harder case. I was working on a ticket to standardize empty state handling across the application. The agent proposed a four-part solution: a shared UI primitive, a custom hook to wrap sync status logic, per-screen wiring across eleven screens, and tests for each. The hook, the primitive, the wiring, the test coverage all hung together. It was well-reasoned and easy to accept.

The detail that triggered my Spidey-Sense was eleven screens. Eleven screens to update. If eleven screens need the same change, the change shouldn’t live in eleven places. I asked why we weren’t routing everything through a single source. The answer, once we looked at it that way, was three new files and eleven one-line route wrappers instead of eleven pages of surgery.

The agent wasn’t wrong in any obvious way. It was wrong in the way that only becomes visible when you’ve built enough systems to recognize sprawl before it exists. DRY and SRP are foundational heuristics of software engineering. The agent can explain what DRY and SRP mean. It still proposed a solution that violated both, because it was reasoning about the ticket rather than the system. A junior engineer accepts that proposal. It’s coherent, it’s defended, it covers all the cases. They build it. Eighteen months later someone needs to change the empty state behavior and finds it in eleven places.

My role in this process is that of a shepherd. I’m attempting to be a teacher, though I recognize that the model’s ability to retain what I teach is limited and non-deterministic. What it learned in one session may or may not be present in the next. The teachings don’t compound the way they do with people.

This has a direct implication for how Engineering organizations need to think about institutional knowledge. The knowledge that used to accumulate in your senior engineers, in their intuitions, their pattern recognition and their understanding of why the system is shaped the way it is, can’t accumulate in the agent. It has to be encoded somewhere that persists. Every engineer with an agent is now responsible for that encoding.

This also changes the shape of the organization in a way I don’t think we’ve fully reckoned with. Every engineer with an agent is now doing something that looks a lot like management: setting direction, reviewing output, catching what slipped through, deciding what to accept and what to push back on. They didn’t sign up for that role and most of them haven’t been trained for it.

As a leader, I used to be a shepherd of shepherds. Now every engineer is a shepherd, which changes the coaching problem in ways I’m still working out. It’s not that I’m more removed from the work. At the companies I’ve led, I was never fully abstracted from it, and agents have given me back some individual contribution capacity. It’s that the thing I need to coach has changed. Teaching someone to write good code and teaching someone to direct an agent well are related but not the same skill, and most engineers are figuring out the second one on their own right now.

I spent most of my career telling teams that the only real source of truth in a codebase is the code itself. Documentation goes stale. Comments go stale. The code is what the system actually does, and anything that claims to describe the code is a lossy, time-decaying representation of it.

I’ve had to revise that position, and not because documentation suddenly became a good idea in the abstract.

The agent trusts documentation more than it trusts code. It reads the comments, the docstrings, the README, and it builds its understanding of the system from those artifacts first. Which means stale documentation doesn’t just mislead the humans anymore. It actively degrades the agent’s next output. And the agent is generating documentation at volume, confidently, in prose that looks authoritative. When that documentation drifts from what the code actually does, the agent will work from the documentation. The code review process catches some of it. A significant amount of what my agentic reviewers flag is exactly this: documentation that no longer agrees with the code because the agent either forgot to update it or updated it incorrectly.

I’m building Ometo as a greenfield project, with documentation generated by the same agents that write the code. I already have this problem. I can only imagine what it looks like when you point an agentic workflow at a five-year-old codebase with three engineering teams and no documentation culture. If documentation hygiene was an afterthought before, the agent just made it a liability.

There’s a conversation happening in engineering communities right now about how to measure the value of agentic processes. How much more value are we putting out? What’s the ROI on the tooling investment?

I’m befuddled by this question. The value was never in how the code got written. It was always in whether the thing you built moved the metric you thought it would move. Did the feature you shipped change user behavior in the direction you hypothesized? Did it produce the revenue impact you expected? Did it reduce the support volume you were targeting? Did it reduce your maintenance costs? That’s how you measure value. The agent didn’t change any of that. It just made the question faster to ask and more expensive to get wrong.

I watched a team spend six months building a feature that was supposed to make a core workflow sexier and more modern. It was originally estimated at 3 months. At six months, they shipped it. Conversion dropped. New activity dropped significantly. They spent the next four to five months trying to get back to baseline. Almost a year of Engineering capacity to end up approximately where they started. The failure wasn’t in the execution. The team shipped. The failure was that nobody had a clear vision for how the new flow would look before work began and an incorrect hypothesis about what the new experience would do to the metrics, and nobody vetted it before committing resources to it.

Run that same scenario with an AI-augmented team. You might get to the wrong place in one month instead of six. Which sounds like progress until you realize you’ve compressed the timeline for finding out you built the wrong thing, not the timeline for building the right thing. And if the prioritization discipline isn’t there, you can run two or three of those cycles in the time it used to take to run one.

There’s a real upside buried here. Getting to the wrong answer faster means you can also get to the right answer faster, if you treat the effort as a risk and frame it as a learning exercise from the start. The problem is that framing rarely survives contact with a roadmap. What starts as an intentional experiment becomes a feature, gets deprioritized before it’s validated, and ends up on the maintenance pile regardless of whether it ever moved a metric. The agent didn’t create that pattern. It just runs it faster.

The agent amplifies whatever prioritization culture you already have. Good prioritization discipline gets more leverage. Bad prioritization discipline gets more damage, faster. Product research still matters. Hypothesis formation and post-delivery measurement still matters. Ironically, you can now get to a prototype faster than ever before, which makes the research conversation easier to have. The bottleneck shifted to finding the right people to put the prototype in front of, not building the prototype itself. But if your organization never had the discipline to define what a successful feature looks like before building it, the agent didn’t install that discipline. It just gave you more rope.

The thing that bites me more often than I’d like to admit is this: even when you specify your business rules in detail before the agent implements them, the heuristics are being implemented in darkness. What you get on the other side may not be what you put in. I’ve heard people argue for the move to spec-based development, that the specification becomes the source of truth and you validate against the specification. But the validation is also agentic, and agentic validation is non-deterministic. You can handwrite the test cases, but if the agent implements them, there’s no guarantee it implemented all of them as you specified. It’s entirely possible to reach production with a different set of business rules than what you specified.

I work in small, constrained chunks. Two-, three-, and five-point tickets. Frequent review. Appropriate scope. I’m running this workflow across roughly a hundred points of work spanning the product build and other projects. Things still escape me. I’ll put my head down for a week or two, cranking through work with the agent, and when I come up to test something I find that somewhere in the last week something changed in a way I didn’t intend. Something that requires me to go back and figure out how to unwind it.

Yesterday, I was validating a bug fix for an issue where the authorization provider was sending two login validation codes. We fixed it. The fix introduced a different problem: a user without an organization could end up on an organizational view. Nothing loaded. It was an empty screen. But the user should have been rejected before they got there, and they weren’t. I found it because I happened to be validating the original fix and walked into the right edge case. That’s not a process. That’s luck.

The non-determinism doesn’t announce itself. The automated test suite missed it because the agent missed the test case. The code review agents missed it because that’s what they do. It doesn’t fail loudly and I almost missed it staring right at it. It produces an empty organization screen that a user might never hit, or might hit on their first day, and you find out about it in a support ticket six weeks later if you find out at all. On an early-stage product, that specific class of failure doesn’t just cause a bug report. It ends the conversation with the customer.

There are variants of a phrase circulating right now that I think accurately describe agentic adoption: agents only magnify the problems with your processes and culture.

Every example in this piece is an illustration of that. The misframing of your review process as your QA process is now the most visible problem you have. The complexity that nobody questioned before is now 32 points of cleanup work. The documentation nobody maintained is now actively degrading your agent’s output. The features that were never validated against a hypothesis are now being built at three times the speed in the wrong direction. The business rule errors that slipped through are slipping through faster.

This is the part that connects to culture in a specific way. Ron Westrum’s research on organizational typologies, the work that DORA later validated empirically, demonstrated that the cultural type of an organization is one of the strongest predictors of its software delivery performance. Generative cultures, the ones characterized by high trust, shared responsibility, and the safety to surface problems, outperform bureaucratic and pathological ones not because their people are smarter but because information flows to where it can be acted on. An engineer in a generative culture stops and asks why before building 13 points of unnecessary work. An engineer in a pathological one builds it because the ticket said to and asking questions feels dangerous.

Agents don’t change that dynamic. They accelerate it. If your culture was already generative, the agent gives your team more leverage to do good work faster. If it wasn’t, the agent gives your team more capacity to build the wrong things, miss the edge cases, and accumulate the kind of debt that doesn’t show up until a customer hits an empty screen on their first day.

The practices that most of us talked about more than we implemented in the old world are the practices that the agent exposes. Sprint discipline. Quality focus. Hypothesis-driven development. Documentation hygiene. Psychological safety. A culture where surfacing problems is rewarded rather than punished.

None of these are new ideas. They have been on conference slides for twenty years. The agent doesn’t care about the slide deck or your organizational aspirations. It amplifies what’s actually true about how your organization works, and it does it faster than the organization can absorb.

The implementation guides will tell you how to prompt the agent. Nobody is going to send you the operating guide. You’re going to have to write it yourself. And the first chapter of that guide isn’t about tooling. It’s about whether your organization is ready for what the agent is going to reveal.

Raleigh Schickel is a VP/Head of Engineering with 15+ years of experience leading Engineering organizations through growth, crisis, and acquisition. He is building Ometo, an engineering health diagnostic platform designed as a coaching tool. He writes about Engineering leadership, team health, and the practices that actually matter at raleighschickel.com.