I can’t be the only person who thinks, when they read Boris Cherny describing that he merged 300 PR’s in a day, or Steve Yegge talking about orchestrating dozens of agents with Gas Town, or even to a lesser extent Mitchell Hashimoto saying that your agents should be busy 24/7 that there’s this gap between what the picture thought leaders are painting, and the experience us normies have sitting down to work with AI. I think Anil Dash expressed some of this in a recent interview:

“I’m sure there are some people that are like, ‘no, no, this is unlike anything else before. And you have to treat it as a magical special thing.’ But overwhelmingly, 99.9% of coders I talk to, of product people I talk to, designers I talk to are all like, ‘can we just be normal about this?’

There’s quite a few interesting posts out there, and I think if you squint you can see some decisions coming together, but there’s a lot of noise that has AI Assisted coding mostly defined by it’s name via the supreme courts process. So this and future posts are an attempt to synthesize that.

This post is also fundamentally advice for humans - not how can all of these tools and processes work in theory, but how should you think about - as an engineer yourself or coach, how you approach this field. How do you keep your skills up to date? How do you get past skepticism? How do you deal with failure? This is a sustainable path to AI assisted development.

Despite a relative wild west, I think there are a few principles that ground this document.

My personal experience with AI has been amazing, especially in platform engineering, vibe coding custom scripts, electron apps, dashboards in Backstage has been incredible. Specifically - there are so many ideas I would like to have disproved where I had to decide which one to invest in to get the proof of concept. AI let’s me test so many ideas with just a few prompts.

Additionally, the capacity to have an expert to ask questions to? I philosophically never ask AI to write or draft writings. Every word in here came from my fingers. But the back and forth?

It changed the game in ways every previous revolution did, by making new things possible, not by making everything before irrelevant.

We can’t throw the baby out with the bath water.

Summary -

Bionics with robotics. Stay in the drivers seat. Act with intention. If you feel like you’re mindlessly prompting away without understanding it, get up and get a coffee (this like most advice echos, you can write code and mindlessly troubleshoot as well.)

Points:

  • Keep Writing code - Most people still learn by doing.

  • 70-20-10

  • How I would learn to code if I could start over again. Modquiz Archive Browser. Pagination is hard.

  • The best engineers have always gone one step deeper than they need to. write down every principle you want the post to assert, one sentence each, no explanation yet. Then order them by “which one does the reader need to believe before they can accept the next one.”

What is Code and when should we AI-assist?

I don’t think the industry as one settled way the word “code” is used. There are two types of code. “Intentional” code and “empirical” code. And I think alot of the “vibe code straight to production without reading diffs” and other AI advice is around intentional code.

  1. What is Code? Mitchell Hashimoto, AI isn’t used on code that provides value.
  2. Working software over comprehensive documentation Software engineering is change management. We need something that says - I can clearly see it used to do A and now it does B and I approve.

One theme of this article is “everything changes, everything stays the same. A lot of the points here will just be “don’t lose your head, we’re still doing X.”

“If you’re not doing all your coding with AI right now, you’re falling behind”

Bionics Robotics.

There’s more to the question of “How should I use AI?” then, “Can AI write good code?”. If you’re going to engineer software for the long haul, you need to know how to read code. You need to develp your engineering skills. You need to understand the ecosystem of how code is written - libraries, frameworks, github issues. There will always be obscure new problems that the AI hasn’t been trained on yet, and there will always be ideas you have about how something should work that won’t be right.

And a universal that hasn’t changed is:

Most of us learn by doing.

I mean, you might be able learn the nature of thinking like a software developer by reading a bunch of books, or maybe doing logic problems. But alot of the higher level thought process that make up “real software engineering” around architecture and guiding LLMs comes from having spent time wrestling with code.

Here’s a quote from Django creator Simon Willison:

I think the job of being paid money to type code into a computer will go the same way as punching punch cards […] I do not think anyone will be paid to just do the thing where you type the code. I think software engineering will still be an enormous career. I just think the software engineers won’t be spending multiple hours of their day in a text editor typing out syntax.

Quoted in this article, that Simon said it in a podcast.

But I think actually grokking what this means for the lay developer is confusing.

If you learned to code by hand and are now learning to code this new AI assisted way, it’s really hard to understand all the mental models that you build writing code by hand. Boris Cherney’s prior job was maintaining code quality at facebook pre-AI years. That is a metric shit ton of practical experience most of us will never get. We’ve always observed that the best way to do software engineering is through practice, I don’t think that changes.

The most important principal I’m trying to excoriate here is:

If you’re not in the drivers seat, put the keyboard down.

I think there’s a narrow but critical gap between flow and mindlessness and I think it’s easy to flop over. I think that all the “You should use AI Agents this way” arguments some of the psychological steps which is how do you stay in the drivers seat? And I think one of the ways you stay in the drivers seat is to continue to write code. A few recommendations I’m taking from my own experience:

I vibe coded this entire electron app to help me browse, catalog and download files from Archive.org. It’s worked pretty incredibly, but alot of the details are hard to get just right. I think if I had stayed in the drivers seat rather than just vibe coded and not read any of the code, I’d be more prepared to deal with a bunch of inefficiencies in how it deals with where it stores data, pagination (which is like a bizarely universally hard problem)[/pagination-is-really-hard.md]. Instead I just keep saying “It’s slow make it fast!” or “Why is this piece of data I expect to be here not here!” ‘Why does clicking the delete button not ‘delete’ in the UI’. This works, basically, but because caching and pagination and other technical details are hard problems, I think it helps to know how the LLM decided to implement them, so you know where to go and ensure you don’t prompt it in ways that go in the wrong direction.

  • For your main code bases, don’t have an agent do full-stack multi-file changes. Instead have it do one or the other:
  1. Find where the code should go, read that code to get a broad sense of what it does to stay familiar, and then prompt the agent to change it, maybe one file at a time.
  2. Ask the agent where the change should be made and change it.

I think an important principal here is time scales. Here’s another thing I think that doesn’t change: As a manager, I expect when I give someone a task, they will both accomplish it in a timely fashion, but also approach it holistically; learn something about it. Be able to support it. Document if this is an edge case or needs a runbook. It is never acceptable to submit a change and not be able to explain it. I always assume there’s some flex time in task accomplishment. What this means going forward I think is like don’t spend 3 hours troubleshooting library incompatibility issues that AI can figure out for you in a few seconds, but it’s ok to spend 10 minutes seeing what you can figure out.

I think this has the benefit of:

  1. Keeping the mind flexible
  2. Keeping your skills up to date
  3. Staying in the details, having a mental model for engineering discussions or code review.

I think this means a balance between three things, and the bulk of your time should continue to be in part 1:

  • ~70% Stay in the driver’s seat. AI can generate code, but more in the style of autocomplete, figure out what it’s changing and why, maybe direct it where to make the change.
  • ~20% AI Generate tools, libraries, etc.
  • ~10% Vibe Code proof of concepts.

The driver’s seat however doesn’t just have to be code, as (alluded to by Charity Majors)[* https://charity.wtf/2026/06/15/ai-demands-more-engineering-discipline-not-less-xpost/], I think the drivers seat can be your observability tools, your infrastructure UI. But I think this stays the same context - don’t ask your observability AI to find the problem, query your data, learn how it’s laid out, learn the query engine.

The balance of how much AI vs how much manual code should shift over your career - more manual as you’re learning, more AI as you get higher level, but. for instance - One way I stay current is doing a quick google esearch and browsing observability tools every time someone pastes a weird error or bug into Slack. Learning is often about intentional friction. The best engineers have always gone one step deeper than they need to.

When should we use AI-assisted code.

Let’s just get right to it:

  • AI should never be trusted to generate code that is central to the value of your team/product/company.

The above definition is a bit tautological. If code is central to the value of your team / product / company, I am definitionally arguing that AI can’t generate it, because AI can only expand on things that don’t require additional details.

Let’s start by challenging the definition of code. Because while at a shallow level I agree that writing code is no longer the job In a deep way I disagree, and I think it starts with something Mitchell Hashimoto observed in how people understood what “Infrastructure-as-code” was.

I’ve always personally defined the “as code” suffix in “X as Code” to mean “a system of principles or rules”. This is in contrast to the popular interpretation of “as code” to mean “as programming.”

I think the Agile principle “Working software over comprehensive documentation.” is more important than ever, but the way we talk about Vibe-Coding or AI driven development kind of implies a reversal. But what do I mean code that is central to the value of your team / product / company?

If you’re an insurance company and you have a formula that defines risk, the code for that formula is critical to the value that you provide. But I don’t think value and “code” have to be defined at one level.

For example, in a small business, the business owner may be vary cognizant of the prices of things. Accidentally losing money on just one or a handful of products could move the needle in devastating ways. Those prices are “code” and go through a human reviewed change management process.

Amazon probably doesn’t care so much about the price of one thing, but wants to optimize their pricing changes strategically so they make money. That pricing algorithm then may be the code that provides value.

Paradox in reading code - reading code is an antipattern,

Software engineering is change management. We need something that says - I can clearly see it used to do A and now it does B and I approve.

Rings of a kernel - https://mkdshare.dev/d/review-the-spec-not-the-diff-how-ai-changes-the-way-we-NTdScTRg

You can’t auto approve changes to the auto approval layer - which may be the “code that provides value” to Boris.

You may have created enough tests and harness code that you really can vibe code things straight to production, but then those tests and harness code become the “code that generates value”.

I don’t know exactly what the solution is, spec-driven development? but it probably includes something akin to protection rings ala the Linux Kernel. Outer rings can be changed freely by the AI, inner rings can’t.

Which is a good segway into our next section:

Engineering is Change Management.

What all the above is trying to say is that when changing some core piece of business logic that is central to how the whole system works it should be very easy to:

  • See what it used to be.
  • See what it is changing to and how.
  • Have a record of these critical changes.

I am convinced that software engineering should continue to be the art of safely and intentionally transitioning code from one state to another state.

But the thing is - where they hype gets it right. So much code isn’t important. So much code can be regenerated blindly.

Conclusion

This is the guide to give you confidence to sit and learn without anxiety.
Write the conclusion as: here’s the maturity model version 1 — here’s the floor, not the ceiling. Anxiety comes from comparing your floor to someone else’s ceiling. The Archive.org story is the emotional proof of this.

“Maybe in 3 years, software engineering will be solved and we’ll be out of a job, but assuming it’s not, we need a sustainable way to keep being engineers, and a system that doesn’t respect how people learn is not sustainable.” Look, you want to go read a bunch of other articles to tell you you should drop out of software engineering and become a plumber? Be my guest. But I think if you’re going to stick around, this is basically the only way to do it.

“Stay calm, stay confident, act with intention” If ai automates us all out of a job then fuck it, but assuming it doesn’t, here’s my sense of what your futur should look like.

I think the next step might be to think of this as a maturity model. I think for those who are just lost in the sea of hype, the above advice is a good place to start. Stay calm, stay confident, act with intention, don’t get pulled from place to place.

But there are next steps. Agent Harnesses, Orchestration - meta-engineering is an important thing to learn once you’ve gotten comfortable with your initial workflow? So that might be part 2 of this post - once I’ve figured it out.

“this is the guide to give you confidence to sit and learn without anxiety.”