Coding is dead. Long live software engineering

For decades, coding and software engineering were interchangeable terms. Thinking back on my career as a software engineer, I spent most of it writing and re-writing code. Other tasks like code review, architecture, and turning specs into implementable work blobs took mere hours of my forty- to fifty-hour week.

At Baz, founded in late 2023, AI coding has always been there. Baz provides a set of agents that create a good foundation for AI SDLC, such as AI code review, skills maintainer agent and others. Some of these agents were born directly from our internal need, while others came from customer demand or experiments we did. As the co-founder & CTO of a 3-year-old, 10 engineer team I’ve had a front row seat to how the industry is changing. When we started out GitHub Copilot was all the rage. Since then, AI agents have taken over coding. I saw a clear inflection point in December 2025 (like many others), where I found myself switching more and more into the auto-accept mode and letting Claude rip through my local file system. My engineering team being more or less on par, some pushing for --dangerously-skip-permissions while others found async agents more comfortable.

What does that mean for software engineering as we approach 2027? I’d argue that software engineering is still a creative and necessary craft. We just have to reclaim it by shifting our definition of it and attention within it. Rather than focusing on the hands-on writing of characters, we need to focus on clarifying the intent and how it fits within the whole system. We need to promote ourselves into a greater place of authority where we get to approve when reality meets the requirements or we get to decide the crucial parts of the system that deserve disproportionate investment.

Coding as a profession is dead

I vividly remember hunching over my desk and hitting Enter through blocks of code modified by Claude Code, as if craning my neck a few inches forward could somehow dissipate the suspicion I held. That was in early 2025. The coding agents and models at the time were mediocre at best, but automated away a lot of the repetitive stuff I hated like boilerplate code and templates.

But, slowly, over the next year things started to change. I recently cancelled my IDE subscription (sorry Jetbrains, still love you though!), revamped my terminal experience (shout out to cmux), and I look at diffs in the web UI only if I have to. That’s a dramatic and sudden shift in the toolset I used to rely on every day for years, and it’s had a downstream impact on who I am as a software engineer. Today I write React code, have services in Rust, Typescript and Python, and everything gets written at the same high velocity. I leveled up!

It’s not just me. Last month my semi-technical co-founder wrote a completely new Slackbot for our company. It’s sophisticated. It supports shortcuts, replies in DMs and in channels, has an identity, and talks with the existing baz BE. Is he a coder? No, but thanks to AI, he doesn’t need to be a coder to write code. That’s what makes agents magical.

However, being able to produce code doesn’t make you an engineer. That’s obvious when things start to break in reality. For example, when he needed to integrate his new slackbot with Slack and found out that the permissions are suddenly off. And the routing is messed up so the webhooks aren’t received by the app. And a secret was supposed to be set, but was missed and the agent’s defensive coding quietly slips through to the logs.

Coding is writing code. Engineering is understanding the system around a piece of code: how the systems connect (troubleshooting permissions) or what makes sense (dropping messages not aimed at the bot) vs what should not be acceptable (missing signing key so all webhook events get dropped).

Democratizing coding in the organization

As agents democratize once coveted skills (whether that’s design, writing, or coding), roles and responsibilities across teams are starting to blur. We’re experiencing this at Baz.

Our engineers are free to use whichever agent they like, whether that’s Claude, Cursor, Codex, and even Slack-based coding agent. With coding off their plates, you’d think engineers would have copious amounts of time on their hands. Nope. What I didn’t expect was that agents will still require a lot of steering. That’s hard to do in a remote messaging app’s UX! It’s so much faster in a local terminal. That’s why there are so many engineers pouring endless amounts of time into “meta coding”: honing agentic skills, fine tuning the ARCHITECTURE.md and other sources of truth, and building the layer that’ll improve agent success. With little time they have leftover, engineers are doing what was historically the role of product managers: prototyping, shaping features, and making decisions based on text rather than code. At the same time, everyone else is moving in engineering’s direction.

When we started investing time in skills, we suddenly realized that our different tools load skills from different places in the file system. Some of it due to the fact that each tool tries to lock you in on their convention. Some of the tools even went ahead and put skills on the specific engineer’s personal computer, changing how that specific engineer does his things (horrible!) vs the rest of the team. But the worst was that when non-engineers / less experienced engineers (product managers / designers for example) started using coding agents, their slop generation rate was very high because our setups and best practices were not shareable.

What started small and innocent with Claude Desktop, has turned into one of our coolest enablers: our product managers and designers today are contributing code by proxying their requests to coding agents via slack. Since the release of Claude Tag followed by our internally built Zee, the floodgates have opened. Zee drew a lot of the UX from Claude Tag, a Slack agent fleet with an identity per channel, but managed in git and running on our infra so it has read access to our database and other internal resources. Like many other internal Slack-based coding agents, Zee is able to research production errors in #prod-alerts, troubleshoot customer issues raised in #customer-issues, and allow directly handling feedback received in #mvp-feedback channel. Because it lives in Slack, everyone can use it. Suddenly, product managers, designers and even sales are asking for features that eventually become a PR. That PR has to be reviewed by an engineer, but that’s a lot faster than letting the designer open a ticket with fixes that an engineer spends time fixing and then the designer reviews by itself before it becomes a PR and wastes another engineer’s attention span.

We’re seeing the same shift in data analysis. For important proof of concepts we’d pull away an engineer to scrape the database, find indication markers of Baz’s performance, and troubleshoot issues quickly before making their way to the final customer presentations. At first, we thought Zee would be the solution but then we found out that there are many different ways to ask a question, and Zee would answer each one differently. It was proof that statistics is a sort of a lie. So after we opened it for everyone, we had to do a rollback internally saying “Zee was not to be trusted!”. My VP of R&D then took 2-3 days to finetune SQL queries and skills, put them inside Zee’s file system, and instructed Zee to always denote the sources it used for the response. That last small addition of citation really helped in restoring the trust in Zee. Today Zee has removed this bottleneck completely, letting product managers and sales get direct, publicly auditable access to this customer success data. Text-to-SQL was once a holy grail, but writing SQL is one of the strengths of all frontier models today.

One by one, jobs that passed through engineering no longer do, opening some serious questions. If a PM can throw any feature he or she wants at an agent and get a working environment in less than 30 minutes, what do we need a backlog for? If it’s urgent, build it now. If it’s rejected, why waste disk space on it? If the feature is debateable, discuss it, make a decision, and move on.

My prediction is that by 2028, the process of backlog grooming and prioritization will disappear. The barrier to produce code is low, giving every idea (good, bad, and terrible) a chance to become real. That means we need strong judgement when reviewing it all.

That means the real skill is no longer building features. It’s knowing what should get built in the first place.

Make the SDLC go brrrr

When PRs started getting created at the speed of tokens per second, our bottleneck shifted to reviewing and deploying them. I think back to three years ago when I was fanatically reviewing every line of every PR and laugh at how naive I was. Humans simply can’t review at the same scale that code is being produced today. Like coding, PRs or code review is on its way to the slaughterhouse.

Baz may be an AI-pilled company from day 1, but we’re just like you. We suffer from the same challenges as everyone else: the PR bottleneck. We broke this problem down into two parts:

• Preventing low-quality PRs from being created in the first place

• Streamlining the good PRs as much as possible

The mistake a lot of the guys on the team made was that we were trying to make PRs better after they existed. The real leverage is in defining the context agents use to make decisions in the first place. That starts with fine tuning your AGENTS.md / CLAUDE.md / SKILL.md files or, dare I say, bringing them into existence. The biggest challenge is that those files suffer the same staleness curse that has long plagued README.md and other docs pages. Agents will update the code and will easily search for references to a function, but they won’t find the markdowns that need to change with it. We’ve solved for it with a three step process:

Own the skill

The first step is to get engineers “meta coding”, which is writing and updating the skills that steer coding agents. This is a must because vanilla LLMs come with tendencies that may not align with how your codebase works. A Claude going into a Codex codebase or a GPT Sol going into a GPT Luna codebase could introduce new patterns, dependencies, and unnecessary refactors than you bargained for just because different models have different leanings. Just like we prompt with “You are an expert in …” when we want to set the right framing for how a model should approach a problem, our coding agent should load crucial context about our codebase before it does anything else.

Share the skill

The second step is sharing those skills. Each user can create their local skills, but those live locally only and can vary dramatically between devs, even those on the same team. Every engineer codes differently, with different preferences and tolerances. If an organization is relying on agents to produce work, the instructions guiding them should be consistent. Aligning skills across the org is just as important as running the same ESLint ruleset across your codebase.

Update the skill

The third step is keeping skills current. Engineers can’t manually capture every change. An auto-updating harness helps automatically find where your skills have drifted, identify new patterns based on developer feedback, and propose updates to skills. We called this skills maintainer, it does a weekly review of the code changes in the codebase and suggests fixes. This doesn’t replace the engineer’s responsibility to own skills. Instead, it helps catch all the edge cases and adjustments that are made over time, so the agents’ context doesn’t go stale and holds the collective knowledge of the entire team.

This is a change in the process of engineering. Instead of engineers sharing “FAQ” files (we had ours unpinned from the on-call channel 3 months ago), they document their findings in the on-call skill. Instead of engineers finding their ways around Datadog on their own time, the skill tells the agent how to use the MCP. And if the developer does not have it set up, the skill helps him set it straight. Alignment of the tools and knowledge in the team has never been more straightforward.

The goal for this internal process was to stop teaching engineers and agents the same lesson one PR at a time. When our engineers own, share, and update the skills, everything we taught our agents made the next cycle better across the entire organization. Not to mention the gain new engineers on the team have from this process, becoming a seasoned on-call engineer through… using agents with prebuilt skills.

This took care of most of the bad PRs, which is the first half of the problem.

What to build now

Baz is three years old and our engineering team hasn’t grown beyond ten employees. What started out as a single team under me, split to two teams, then three. We’ve been hovering around ten engineers, not because of budget or churn, but because we haven’t needed more. The two pizzas rule worked when humans did the coding. In today’s world, two pizzas might be too much.

The team split is an interesting one to me. As we initially searched for what to build, we wanted the agility to mount multiple engineers on specific tasks at specific times to really push and test them. But as features started to ship to customers and our skinny MVP turned beefy and full of configurations and knobs we needed engineers to dive deeper into the feature and the customer mindset while sacrificing some of the agility we had. What we lost in engineering firepower we made up in agents, and today it really feels like that team of 3 engineers ships like 10, but in a rather specific area of the product.

Today our teams are split according to Harnesses, Context and Data. Harnesses team builds out harnesses, chooses the right models and owns the agentic workflows that solve different problems in our product. Context team connects these harnesses to the users or agents that need them via MCP, via GitHub comments, etc. The Data team is where we finetune the data structures, choose the right tools for every job and benchmark what we build.

These teams do not exist independently of the others, but most tasks can be easily routed to their respective owners. Adding a linear integration is the Context team, creating repo indices and adding it as a tool is the Data team, and building the security review agent is the harnesses team. That way each team can ship features end to end, but also build on the other team’s work.

Before AI, software companies used to be constrained by how much code they can push out. That’s changed. Tiny teams with a healthy token budget like ours can build entire products in days because the coding burden no longer exists. That burden, though, got replaced with a new one. As engineers move from owning individual features to entire products, the context they’re responsible for expands with it. They need to understand their customer, the requirements, the architecture, the technical decisions, and how it all ties together.

We leaned into the magical number 3 again here, listing 3 steps to streamlining good PRs.

Define the intent

If engineers are responsible for the entire system, they need to write what they want (intent!) in a document. We called that document the plan. The key step is to make sure that agents are a part of the planning process, and an engineer is part of the review and validation process. Engineers provide the steer on what to build next, but your agent needs to be working through all the details and the gruntwork to make sure your vision makes sense. Before writing code, make sure your wishes can become reality. I still believe in “measure twice, cut once”

Verify the implementation

Once the plan is approved, the intent needs to follow the work downstream. As the agent builds, the implementation must be verified that what’s being built actually matches what was agreed upon upstream. If it doesn’t, an engineer is brought back into the loop. A separate agent in charge of this approve-or-escalate-to-human does VERY well.

Merge seamlessly

By the time the PR is ready to merge, an engineer shouldn’t have to whiteboard the system’s architecture to understand if and how the proposed code won’t work. The plan has been checked against the system and approved, the implementation has been checked against the plan, and the code has been checked against your engineering standards. If everything aligns, it’s a no-brainer merge.

That’s when we finally eliminated the bottleneck, rather than passing it around. Not by reviewing faster or praying that production doesn’t break, but by defining the boundaries agents can autonomously operate within and giving them the context to know when they’ve crossed them.

Closing words

Like fashion, what’s new is old again, and while I do think that we need to rethink the SDLC for agentic development, a lot of the adages still hold true.

Here’s what we’re learning and relearning:

• Continuous delivery → Continuous verification. DevOps made delivery continuous. AI SDLC is making the case for continuous review.

• Shift left → Shift all the way left. Don’t just keep adding more testing at the PR. Start review at planning and architecture.

• Context is king → Context is still king. Agents need context that evolves with your architecture, codebase, standards, and decisions. Smarter models won’t compensate for missing context.

• Close the feedback loop → Close the review loop. Agents need feedback from engineers and production to make the next review better and keep up with the explosive number of PRs that are generated

As an engineering-led organization, agentic coding is a revolution that redefines the role of software engineers, as well as others like product managers, product designers etc. What we’ve found out to be true is that you need to invest time in AI to enjoy its many fruits. You need to trust but verify your agents, as you rely on them more and more. And you need to share the learnings and baby-step improvements both with your team and with your agent (via skills). AI is a proven piece of technology but it needs to be crafted and honed to fulfill its promise.