Good vibes, bad vendors

When I was thirteen or fourteen I had a really comfortable sweatshirt that I wore to school all the time — but it did have a few inherent problems. For one thing, it had a great big target on it, and wearing a literal target to high school was just asking for it. For another, on top of that, in Looney Tunes writing, was the confident phrase: “It’s a good vibe!”

I was bullied as mercilessly as one might expect, but I honestly think it might have killed in the AI era. I’d like to think I was just ahead of my time.

Andrej Karpathy, an early OpenAI researcher who now works at his own startup, coined the phrase vibe coding last year. To vibe code is to use an LLM like Claude or ChatGPT to generate source code instead of writing it yourself. He meant it as a way to loosely prototype code or to make progress on a weekend project. LLMs, at least at the time, could not be fully trusted to write well-written, working code. It was an out-there idea.

What a difference a year makes. Today, it’s a mainstream conversation that is rapidly reshaping technology strategy — and informing layoffs across industries.

AI conversations are always fraught, for good reasons that include the underlying power dynamics and the bad behavior of most of the AI vendors. At the same time, the whole AI landscape is changing incredibly rapidly, and it’s become a cliché to point out that any discussion of what LLMs can and can’t do today will probably be invalid two or three months from now. And, of course, millions of words have been written about it at this point. But even despite all that, I still think it’s worth talking about.

If you’re running technology in a small, resource-constrained environment — like a newsroom or a non-profit — how should you think about AI-enhanced software engineering? Come to that, how should I?

Let’s talk about it.

First things first: does it work?

It didn’t, and then it did.

Six months ago, LLMs could generate a certain amount of code, but they would often make inefficient decisions or hallucinate libraries and API endpoints, and you’d need to babysit them a lot. Their use was mostly passive: they would generate code snippets based on immediate user prompts, and engineers would have to spend a bunch of time debugging the output. And in terms of security, it was the Wild West; there were essentially no security considerations. LLMs are famously stochastic (their output is randomly determined, not deterministic) and prone to hallucinations. The result was unreliable code.

A lot has changed since then. In particular, the models released in February, 2026 are a sea change in reliability: given the right prompt, they often genuinely can write decent code in one shot. Tools like Claude Code can go off, spawn multiple agents, investigate a problem, build a reasonable plan, and then execute on it, while working in a safely sandboxed environment.

It’s not just about improved models, although they obviously have a central part to play. An ecosystem is developing around doing AI-assisted software engineering well. Plugins like Jesse Vincent’s Superpowers encourage good decision-making based on principles of excellent software architecture design and product management. Structured frameworks like spec-driven development similarly help lead the agent to sensible outcomes; both are incorporated in all-in-one coding lifecycle toolkits like Metaswarm. A rigorous process is preserved, and throughout, there are far more safety guardrails to prevent security incidents (although it’s easy to overcome them, or they’re sometimes not on by default), and using AI to generate code is much safer than it was.

Claude Code absolutely can write the code, build a plan, and document its work. I have been an AI skeptic, but in my experiments I’ve found that it really can feel like magic. You can reasonably object to AI for any number of reasons, but this is no longer one. It works.

The thing to understand is that this is a tool for engineers — and senior engineers will get the best results. It takes real engineering skill to craft a prompt that will do the right thing and result in a strong architecture.

The process changes the center of gravity from writing source code in a programming language to crafting goals, understanding your user, being crystal clear about the experience and the value you want to convey, and thinking about architectural implications. That probably means talking to people, forming a hypothesis about what they need, testing it with them, and considering the ongoing technical implications of the work.

Those are things that senior engineers already spend much of their time doing — indeed, I’d argue that it’s what separates a great senior engineer from a mid-level one. The core question a senior engineer navigates well comes down to: lots of people can write code, but should they? Why, and for whom? Those questions only become more important in a world where AI is writing the source code. When implementation is faster, problem selection and scoping become the scarce skills.

Friction is training: we learn how to engineer software through our terrible experiences. When things go wrong, we learn. When we have to refactor, we learn. When we talk to our peers about our work, we learn. AI removes most of this friction and hides the complexity away from us: it obscures failure, compresses the process of debugging, and automates refactoring. When these hard-earned skills are the reason we can make good software engineering decisions with AI, but the AI doesn’t offer newcomers the ability to build those skills, who will train the AI once we are gone?

Opinions on that change in center of gravity will be intensely divided. I stand by this New Year’s Day thought about Claude Code:

It has the potential to transform all of tech. I also think we’re going to see a real split in the tech industry (and everywhere code is written) between people who are outcome-driven and are excited to get to the part where they can test their work with users faster, and people who are process-driven and get their meaning from the engineering itself and are upset about having that taken away.

I’m very much an outcome-driven developer, and to me it’s a giant relief. Not everyone will feel the same way.

Resource-constrained environments must be outcome-driven. They can’t spend their time on the process of software engineering; the best way for them to move forward is to start small, release a valuable core that solves a problem for some set of users as early as possible, and then continually iterate around it, using user feedback as a guide.

There’s no alternative to having empathetic, human-centered senior engineers on your team — with or without AI. But AI engineering tools may have an interesting side effect: I can see a world where pushing these product and spec questions to the forefront helps more engineers build those skills more quickly. The first step, after all, is understanding that those answers are needed to begin with.

It’s worth saying that there will be many managers who hope that tools like Claude Code will mean they can do away with engineers or dramatically cut their workforces. Of course there will. They may even see engineers as gatekeepers, and there may be resentment that they’re needed at all — and a hope that this work can be done directly by managers or other key employees. In a newsroom, for example, can’t the journalists produce tools now?

For non-engineers, they can be a useful prototyping tool: for a product manager, for example, it may help assess a user interface or experiment with an idea. But those prototypes are not enduring software; nor are they projects that can be “handed off” to engineers to support.

To properly architect a system, there’s a lot you need to consider. This includes performance, scalability, and the ongoing overhead of maintaining a project and keeping it safe: nobody wants to rely on software that proves to be slow, insecure, or impossible to update. You also need to assess the technical implications of a project: are there technical standards that the project should be adhering to, or battle-tested best practices that the design should take into consideration? For all these reasons, an engineer must be involved from the beginning.

These tools can’t replace technical staff, and they shouldn’t. Like I said, these tools are for engineers, not a replacement for them.

Okay, but what about those power dynamics?

Consider an individual, indie developer. Over the last few decades, they’ve become more and more empowered: developer tools have become cheaper and more of them are open source. Power and control have been devolved to the individual; you can run the tools you want on your own hardware, configure or recode them to your needs, use them for free, and share any of your changes. Engineering has become more and more of an open collective built on radical collaboration. That allows developers with fewer resources to build more easily, widening the pool of people who can build startups, create useful tools, and learn these skills to begin with.

AI-assisted engineering centralizes power back in the other direction. Claude Code, Codex, and so on are all centralized, proprietary tools that become harder to move away from the longer they’re relied upon. They’re also expensive: while open source tools are decentralized and free, it’s incredibly easy to spend large amounts on Claude. Based on my own experimentation and anecdotes from friends and peer companies, any engineer that relies on Claude Code as part of their daily work is likely to spend hundreds of dollars a week; these are new costs that didn’t previously exist.

Those extra costs could theoretically be offset by significant performance or efficiency gains. The thing is, those gains aren’t as strong as you might expect given the apparent magic of automatically generated code. A study recently published in Harvard Business Review indicated that adding AI actually intensified the workload, putting engineers at risk of burning out:

The changes brought about by enthusiastic AI adoption can be unsustainable, causing problems down the line. Once the excitement of experimenting fades, workers can find that their workload has quietly grown and feel stretched from juggling everything that’s suddenly on their plate. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making. The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems.

These can be mitigated by good work hygiene: enforcing breaks and sensible work hours. But the employers who are most enthusiastic about introducing AI may also be the ones that are least enthusiastic about benefits that center employee well-being over productivity.

I’ve already mentioned that some managers may hope that AI can reduce their investment in software engineers. One can easily imagine that the presence of AI — or, rather, the threat of being replaced by it — could be used as a cudgel to depress engineer salaries. It gives managers more leverage beyond money, too: those longer hours and more intense workloads that the HBR study found could burn engineers out might be more likely in a world where engineers fear for their jobs.

The long-term implications are even starker. Consider a world where the recentralization of power from individuals to large, centralized companies continues at the current pace. When AI writes most source code, fewer and fewer engineers will be capable of doing this work themselves, which will lead to even more dependence and lock-in.

It’s been noted in the past that while generative AI robs artists of the interesting work and leaves them with the mundane bits, for outcome-oriented engineers it robs them of the mundane bits and leaves them with the interesting parts. I’d argue that the real value is in the intersection between coding and the higher-level work; they’re inseparable. By improving the way we code, we improve the way we can solve problems for real people. (How can you solve a problem if you don’t really understand how the solution works?) By improving the way we think about solving problems, we improve the way we code. (How can you code something well if you don’t know who it’s for or why it needs to exist?) They aren’t two separate processes; they’re parts of the same thing. Removing one makes the other less effective.

Without concerted effort, an entire industry will be de-skilled and de-valued, their human expertise replaced with software that charges by the token.

So let’s put in the effort

AI isn’t going away, and AI-assisted software engineering is a permanent addition to the way we build software. But that’s not the same thing as saying that the way we use AI today won’t change.

Any policy for AI-assisted engineering has to take into account risks of various kinds. I’d loosely separate them into the following categories:

• Employee risk: preventing burnout, staff turnover, and poor morale.
• Security risk: preventing data leaks and security incidents that compromise customers, sources, employees, or other members of the community.
• Quality risk: preventing low-quality code that impacts the efficiency, experience, or perceived quality of the organization’s work.
• Supplier risk: reducing the potential impact of potentially harmful choices made by AI vendors.

While I’m not going to go into a full framework here — that’s part of what I do at my day job — let’s talk about how we might think about addressing them together.

Employee risk

In that Harvard Business School report about AI-driven burnout in engineers, the authors suggested some sensible mitigations. These included creating, as team norms, structured time for quiet reflection on the project at hand, and limiting interruptions; intentional processes for limiting the work that can move forward, to prevent engineers from taking on (or being asked to take on) too many tasks just because they think they can; and creating more space for empathetic human connection as a team.

Those are all things that every team should do, whether or not they use AI! But they become even more important on an AI-accelerated team. If you don’t have any norms about tightly controlling when work moves forward, for example, adding a tool that accelerates the work will result in a higher volume of work getting processed, but not necessarily any strategic selection about the most important work to do.

Perhaps most importantly, engineers are worried that they’ll be replaced at the hands of managers who may not understand what they do. They need to have the emotional safety and security that comes from knowing that they won’t. It needs to be communicated to them that the importance of their skills is understood. They are experts in their fields, and they’ve just gained another tool to help them; they are not interchangeable with the tool.

Security and quality risk

It turns out that you go a long way towards addressing a lot of security, quality, and efficiency issues — as well as some of the morale issues that lead to employee risk — by placing engineers at the center of the process. Some AI processes talk about “human in the loop”. That term was borrowed from more traditional machine learning processes; in the case of anything where AI takes an action in the world on behalf of a user, like engineering, I’d prefer to reframe it as a tool that is always directly under human control.

In that light, all code must have a human owner who will take responsibility for it. It’s their code, just as if they’d written it in an integrated development environment; they just happened to use a different tool. If all generated code must ultimately be owned and reviewed by a human, that person is able to tune the results for safety, efficiency, and quality.

Most well-run engineering teams have a peer review process where code written by an engineer must be officially reviewed by a second engineer before it can be merged into the main codebase. If we assume that generated code is owned by Engineer A, that means there must be a human Engineer B to give it a second pair of eyes. They might also be using automated tools to help their review along, but they’re the ones who ultimately take responsibility for a review.

This isn’t enough. All projects need to have comprehensive automated testing: tests that must run on code that is about to be merged into the main codebase in order to make sure everything still functions. Tests for efficiency, adherence to style guidelines, and security issues can be run here too. What’s kind of fun is that when these are in place, tools like Claude Code will look at the test output, make corrections when something doesn’t pass, and try again — all automatically.

Supplier risk

The centralization that removes power and agency from engineers also introduces a serious business risk. If a core part of an organization’s value comes from software development, inexorably placing a centralized service in the middle of your process makes you heavily dependent on their decision-making. They can increase their prices, make changes to their stack, or change the way they think about keeping your data and source code safe, and there’s very little you can do about it.

The good news is that, right now, no AI vendor can lock you into their services, because your source code itself and your infrastructure stack are independent of your AI tools. Your code is managed, stored, and hosted in different places, and you can think of source code itself as being a kind of open protocol: because it’s plain text, you can use virtually any tool with it. Source code still has the devolved, open, decentralized properties of the open source ecosystem that has put power in engineers’ hands for decades. That provides at least some protection against an AI vendor suddenly increasing their prices or changing their privacy stance: you can always vote with your feet.

If you’re uncomfortable using one of the major model providers, open source alternatives are available. Tools like Aider and Cline can provide agentic coding using any model, including local models that could theoretically be run on an organization’s own infrastructure. In practice, though, this requires more powerful hardware than most smaller organizations can afford; this may become less of an issue over time, as new hardware emerges, but it certainly is one now. Still, local models could help prevent lock-in — and may prevent some security issues, too.

This inherent openness could change as AI vendors look for ways to increase their revenue and reduce churn. We may see AI-specific alternatives to git and GitHub; I can even imagine programming languages that are “optimized for AI” but that just happen to be proprietary and locked in to a vendor. Every company that builds software should watch for these forms of lock-in and reject them.

We should also be wary of marketing that tells us to just let the AI write code autonomously. These are ideas that cement vendors as a full replacement for the software development process, moving a center of expertise that was previously owned by an organization into a centralized technology owned by someone else. It’s a trap: that world is one where the source code can’t be moved between agents and your products are fully locked into their services without a credible exit.

Do we want to invite these companies into our workplaces?

A ton has been written on the issues surrounding AI. Last summer, I wrote a broader guide to navigating AI that I think still holds up. In it, I noted:

A lot of money has been spent to encourage businesses to adopt AI — which means deeply embed services provided by these vendors into their processes. The intention is to make their services integral as quickly as possible. That’s why there’s heavy sponsorship at conferences for various industries, programs to sponsor adoption, and so on. Managers and board members see all this messaging and start asking, “what are we doing with AI?” specifically because this FOMO message has reached them.

My approach to evaluating AI remains through two main lenses: the technology itself and the vendors who make it. The further reading section of that earlier piece is a good place to start.

The thing that I didn’t mention then, but is worth calling out now, is the sheer precarity of these vendors. AI vendors are offering their services for below cost and have struggled to articulate value in a way that could credibly lead to profitability. Apparently feeling this gap, OpenAI is experimenting with ads and porn, while finding itself under scrutiny for putting teen wellbeing at risk through choices it made to boost engagement. Anthropic was sued by Reddit last year for scraping Reddit data for training without authorization, and had to settle a high-profile lawsuit brought by book authors whose work it stole for training data. I’ve mentioned Claude Code a bunch in this piece, because it works really well, but it was trained using stolen work.

Meanwhile, from a technical standpoint, there has been some research that there are diminishing returns to new LLM development and we’re already past the peak.

There’s no guarantee these companies will make it. If an organization has invested in agentic coding processes that don’t substantially keep humans in the loop and the vendors that power them disappear, they will be left in a bind, with no in-house expertise, and company strategies that depend on AI. That makes it a dangerous gamble. We will have lost internal skill while increasing our dependence on very fragile external suppliers.

So how should you think about it?

AI coding works. It shifts the center of gravity from implementation to judgment, which increases the value of senior engineering skills. It also introduces significant power, labor, and supplier risks. That means that solid guardrails and cultural norms are non-optional.

Even if you haven’t rolled it out yet, your engineers are almost certainly using it. In conversations with my peers, I’ve heard countless stories of organizations that banned it but discovered that its workforce had just taken matters into their own hands. While there are many engineers who refuse to touch it, many more are eager to have it.

You could ban it, but it’d likely be fruitless: those engineers who use their own accounts will probably keep doing so. It’s better to have the tools in a place that’s under your control and observable than used in the shadows in a way that might put your data at risk. Given that, it’s better to roll it out than to not. But you need to do it with your eyes wide open and with a sense of intentionality. Be aware of the risks, and mitigate them in advance with common sense cultural norms like the ones I discussed earlier: pay attention to your employee and supplier risks in particular. Don’t let AI push to production without oversight. And keep humans not just in the loop but fully in control.

I don’t think it’s productive to mandate the use of AI-assisted engineering, which runs the risk of alienating some engineers — the split between AI skeptics and those who are excited about the technology is real — and preventing nuanced discussions about how the technology can be used inside your workplace. What happens in practice when you just let it roll out to anyone who wants to try it is that people do try it; they find that it’s useful for some tasks, and then quickly find its limitations. That’s a healthy exploration.

How should I think about it? I’m still figuring it out. Jesse Vincent compares the process of hating “agentic” development and pushing through it to discover that code was never the most important part of building software to the process of being a manager and asking your team to build things instead of coding them yourself. I agree that these experiences rhyme — but of course, when you lead a team, you’re investing in human beings, working alongside them, and helping them to grow in the process. That’s exponentially more rewarding than leading software agents built to provide value for a megacorporation.

But it doesn’t need to be that way. You can do both. If you treat the technology as a tool, albeit one that has been made by genuinely problematic companies, you can roll it out to a real, human team and continue to build things together. You can invest in and support them while you navigate new kinds of software problems; together, you can figure out how to shape the culture of an engineering team that is undergoing a paradigm shift. You can train the next generation of software engineers, both keeping the long history of software development in mind, and taking into account these new skills. And you can look for the next thing that properly devolves power down the stack to the individual, for the benefit of everyone.

Software development is still human. You can work together towards a shared mission, pick and choose the pieces of this new technology that make sense according to your strategy and values, and build community in the process.

That’s a good vibe.