Field Notes

Notes from running an engineering org where AI writes most of the code. Not predictions about one.

Everything here started as something I worked out in production and then wrote down. The specifics are real: the tools, the gates, the org changes, and the arguments I lost before I won them. Where the industry data supports or complicates the argument, I have said so and linked the source.

Where the Bottleneck Moved

Architecture review became the constraint, and we stopped trying to fix it.

I spent a good part of this year arguing that AI made judgment the whole job. The fair follow-up question was what that actually changes on a Monday morning. Here is what changed in my org.

When implementation goes from days to hours, the review queue backs up. That part is predictable. The instinct that follows is the dangerous one: speed review up, approve faster, batch more, trust the tests. That is how you generate technical debt at machine speed and call it velocity.

We went the other way. Review got slower and more expensive on purpose, because it is now the only place a human decision actually enters the system.

Quality gates got stricter, not looser

SonarQube thresholds, coverage floors, and pull request review that actually blocks. When code volume goes up 5x, gates stop being bureaucracy and start being the load-bearing wall. Every gate we relaxed to keep the queue moving, we paid for later at a worse exchange rate.

The expensive conversation moved earlier

Not "review this PR," but "should this exist, and where does it sit." Ten minutes of that conversation saves a week of generated code pointed at the wrong abstraction. The cost of a bad architectural call compounds at machine speed now, which means the cheapest place to spend human attention is before the code exists, not after.

QA stopped being downstream

I taught the quality team to generate Playwright suites with Claude directly. They went from receiving work to producing coverage in parallel. That is not a tooling change, it is an org chart change - and it is the single highest-leverage thing I did all year, because it removed the team that was structurally guaranteed to become the next bottleneck.

The uncomfortable version: if your senior engineers are still spending most of their time producing code, you are paying architect rates for something that got cheap. Their expensive skill is now review, boundaries, and saying no.

That is a harder job than writing the code was. It is also the one that does not get automated next. I unpack the upstream and downstream mechanics of this on the AI Bottleneck Shift section of the home page.

Work With Agents Like Senior Engineers

Prompt engineering is the old conversation.

It is table stakes now. You do not get credit for writing a better prompt. That is how this technology moves: yesterday's magic trick becomes today's login screen.

What actually changed is the agents. They hold more context. They call tools better. They stay with a task longer. They reason across code, tests, docs, tickets, and architecture decisions in one pass. But most teams are still using them like autocomplete with a hoodie, and that gap is the bottleneck.

Last year you prompted an agent like a junior engineer. Tight scope, explicit spec, small task, and you owned all of the thinking. That is no longer the right ceiling. Three things change when you treat one like a senior engineer instead.

Give direction without over-specifying

Lead with your thesis, not just a task. "I think our auth coupling is slowing deployment. Investigate the service boundaries and show me the tradeoffs" beats "Refactor auth." One is leadership. The other is a Jira ticket wearing a fake mustache.

Ask it to wrestle with what good looks like

Not everything fits in an eval. Architecture decisions, modernization paths, platform tradeoffs, migration sequencing, and engineering debt all require judgment. So ask better questions. What are we optimizing for? What are we risking? What breaks first? What would you challenge in this plan? Where am I wrong? That is where the value shows up.

Force it across the full context

Do not let the agent tunnel into one file and declare victory like it found Atlantis in a helper method. Point it at the working set: code, tests, docs, tickets, recent changes, product constraints, operational pain, and your own opinion. Then make it reason across the whole system.

This is the same pattern strong technical leaders already use with senior engineers. Autonomy with accountability. Context before commands. Room to push back. Clear ownership of the outcome.

Prompt engineering was never really about the words. It was about intent, and intent is best expressed as a sharp series of questions backed by enough context for the agent to do real work.

Adoption Is a Trust Problem, Not a Tooling Rollout

It is a behavior change, a workflow change, and a trust problem wearing a hoodie.

Increasing AI adoption is not about buying more tools. It is about removing the friction between "I should try this" and "this actually helps me ship better software."

Most engineering teams do not have an adoption problem because engineers are resistant. They have an adoption problem because leadership rolls out AI like a corporate wellness program.

Start where the pain already has budget

Do not lead with "here is our AI strategy." Lead with where we are losing time, where reviews are slow, where tests break trust, where onboarding hurts, and where developers are doing repetitive work a machine can handle badly at first and well with guardrails.

Make it part of the workflow

If engineers have to leave the IDE, context switch, paste code into five tools, and reconcile the output by hand, adoption dies. The best AI tooling feels like infrastructure, not homework. It lives inside the SDLC - requirements, architecture, coding, testing, review, security, CI/CD, documentation, incident response - not as a demo, as a pipeline stage.

Guardrails, not handcuffs

Engineers need clear rules about what data can be used, what tools are approved, what requires review, and what must be verified before merge. The goal is not to move fast and hallucinate things. The goal is to move faster with evidence.

Measure outcomes, not vibes

Adoption is not measured by license count. Cycle time, review speed, test coverage, escaped defects, onboarding time, incident triage, toil, developer flow - those are measures. If the metric is "we bought 200 seats," congratulations, procurement had a sprint.

Treat skepticism as a feature

A skeptical engineer is not blocking progress. They are protecting production. Bring them in early, let them test the limits and find the sharp edges, then use that feedback to make adoption safer and more useful. The next section is what that looks like when it works.

Adoption does not scale through hype. It scales through trust, workflow integration, visible wins, and engineering judgment.

If There's So Little Risk, Why Wait?

I asked a software architect on my team that question. It did more than any rollout plan.

He was, by his own description, risk averse and cautious with change. Exactly what you want in someone guarding a production codebase. He had run a few small experiments, saw a lot of noise and mixed opinions online, and parked it there.

He was not wrong to be cautious. He was wrong about where the risk actually was.

So I did not hand him a mandate, a license, or a 47-slide adoption deck dressed up as strategy. I showed him. I sat down and demonstrated how I was using the tools in my own work. Real code, real pull requests, real tradeoffs. Not a vendor demo where everything works because the codebase has no trauma.

Then I found the places where his caution had quietly become the bottleneck, and challenged him forward with one question: if the downside is this small, what exactly are we protecting by waiting?

He jumped in feet first. Within weeks he was proficient. He later described his own AI journey as having two phases, before that shift and after it - and he wrote it down publicly, which is why it appears in the recommendations on the home page rather than only in mine.

The impact compounded. The team moved faster on static analysis gates in CI. CI/CD automation improved. Quality conversations got sharper. The stability and velocity we had been trying to unlock for years finally started showing up in the system. Not because AI replaced engineering judgment, but because it helped one of our strongest engineering minds remove friction from work he already knew needed to happen.

The blocker to adoption is rarely the model. It is the gap between an engineer's perceived risk and the actual risk.

Senior engineers protect quality by default. That instinct is a feature, not a bug. The job is not to override it, it is to recalibrate it with evidence and then champion the ideas they were already trying to push through. You do not accelerate adoption by being louder. You do it by being the first one in the water.

Remote Was Never the Variable

I have led remote engineering teams since 2012. Not 2020. 2012.

Eight years before the world was forced into it, and back when "we have a team in Eastern Europe" was something you explained to your board rather than something they assumed. That is not a flex. It is a long, expensive education in what actually breaks when people are not in a room.

Distance does not kill teams. Ambiguity does. Colocated teams survive vague ownership because someone overhears the confusion and fixes it. Distributed teams do not get that accident. Every unclear decision quietly becomes two people building two different things across a nine-hour time gap.

So the fix was never more meetings. It was writing things down and naming the person.

Name the person, not the channel

RACI is boring. It is also the difference between a team in Eastern Europe shipping the right thing and shipping something reasonable that nobody asked for. One name on the decision. Not a committee, not a channel, a name.

Async means decisions have to survive being read

Async does not mean slow. It means decisions have to survive being read. If a decision only makes sense when you explain it out loud, it is not a decision yet. It is a vibe with a Jira ticket attached. This is also why context-first development works: a decision written down well enough for a colleague in another time zone is a decision written down well enough for an agent.

You cannot manage a distributed team by watching

You can only manage it by defining what done looks like and then getting out of the way. Every leader who moves to remote and reaches for activity metrics is trying to recreate the view from their old desk. It does not work, and the good engineers leave.

Twenty years in, working across Eastern Europe, the Philippines, India, Ukraine, and China, the pattern has never changed. The teams that work are the ones where autonomy and accountability arrive together.

Autonomy alone is abandonment. Accountability alone is surveillance.

The industry spent 2020 discovering remote work and 2023 declaring it dead. Both takes missed it. Remote was never the variable. Clarity was.

What the Data Says in August 2026

The industry research has caught up with the argument. It is worth being precise about what it actually says.

Adoption is near-universal. Trust is not.

The most recent Stack Overflow Developer Survey put AI tool usage at over 84% of professional developers while trust in those same tools fell to 29%, an 11-point drop year over year. The most experienced developers are the most skeptical of all. That is not a contradiction waiting to be resolved. It is the correct response to a tool that is confidently wrong at a low but non-zero rate, held by the people who carry the accountability when it is.

AI is an amplifier, not a fix

DORA's 2025 State of AI-assisted Software Development, drawn from roughly 5,000 practitioners, landed on the finding that matters most: AI magnifies what your organization already is. It makes strong delivery systems faster and weak ones worse. Adoption now correlates with higher throughput and higher instability, and DORA is blunt that AI adoption "not only fails to fix instability, it is currently associated with increasing instability." The report also found that time saved in code creation gets reallocated to auditing and verification.

That last sentence is the bottleneck shift, measured by someone other than me. If the savings move to verification, then verification is where the system needs to be rebuilt, and that is an organizational decision rather than a tooling purchase.

The short loop is close to solved. The long arc is not.

METR's time-horizon research tracks the task length at which an agent succeeds half the time, and that number has been roughly doubling every seven months. Agents are close to reliable on work that takes a human minutes. They degrade sharply on work measured in hours, where mistakes compound across many steps and no one is checking the direction. The model is strong inside the task and weak about which task, in what order, against what architecture.

This is why I keep putting the human decision at the boundary rather than inside the loop. The boundary is exactly where the models are weakest, and it is the part that does not improve on a seven-month doubling schedule.

The money is under scrutiny

Big Tech AI capital expenditure is running past $600 billion a year and has climbed to roughly 23% of revenue. Meanwhile Forrester has enterprises deferring about a quarter of planned AI spend into 2027, and a Gartner survey found fewer than a third of decision-makers could name a specific financial outcome attributable to their AI investment. Bain's summary of the pattern is the one I would put on a wall: the technology worked, the value did not arrive.

None of this is an argument against AI. It is an argument that the remaining constraint is organizational, not technical.

The teams getting real value are the ones that rebuilt review, verification, and ownership around the new code volume. The teams that bought seats and waited are the ones filling out the ROI surveys. That gap is not going to be closed by a better model, and every data point above says the same thing from a different direction.

Who Is Writing This

I am RJ Lindelof, Senior Director of Engineering, AI and Automation at SteadyIQ, where I lead the engineering organization for an income and employment verification platform used by state benefit agencies. Twenty-plus years in regulated B2B SaaS across GovTech, HealthTech, EdTech, and FinTech, and I still write code.

More on the approach behind these notes is on the home page, and there is a fuller professional background at RJL.dev. If you are working through the same problems, compare notes with me.