AI Moves the Bottleneck - Are You Ready for What That Means For Your Career?

Summary

In this episode of Developer Tea, host Jonathan Cuttrell examines the profound impact of AI on the software engineering industry, focusing not on specific tools or techniques, but on how the fundamental shift in capability will change organizational structures and career paths.

Cuttrell begins by drawing a historical parallel to the shift from physical software delivery (like Windows 95 on disks) to continuous online delivery. This earlier change made software updates and bug fixes cheaper, which in turn altered business decision-making—organizations invested less in pre-release testing and risk mitigation because the cost of failure decreased. The key insight is that when a bottleneck in the delivery pipeline is removed or reduced, the entire economic calculation around that process changes.

He then applies this framework to the current AI revolution. The core change is that coding—the act of producing software—has become significantly cheaper and faster. This means the engineering function is becoming less of a bottleneck in the product development lifecycle. For organizations whose processes were built around engineering being the slow, expensive step, this creates a disruption. The immediate effect is likely that upstream bottlenecks (like product specification, decision-making, or risk assessment) will become more visible as engineering capacity increases.

Cuttrell argues that intelligent organizations will respond by redesigning their pipelines. They may reduce emphasis on extensive upfront risk mitigation because the cost of engineering failure is now lower. This could lead to shipping more features with higher uncertainty, accepting more bugs, or consolidating decision-making power to increase speed. The role of the software engineer will evolve from being primarily a code producer to someone who operates within this new, faster system—potentially making more product decisions directly or working in tighter, more integrated loops with product and design.

He concludes by urging engineers to adopt a systems-thinking mindset. Being an engineer is not defined by the specific act of coding, but by a problem-solving approach. In this new era, engineers should focus on understanding how the bottleneck shift affects the entire system of software delivery and proactively shape their roles within it, rather than passively reacting to change.

Recommendations

Books

The Goal — Referenced as a source for understanding bottleneck theory. The book discusses the pattern that once you release one bottleneck, you inevitably find a new one, causing problems to shift and change shape.

Tools

Unblocked — A sponsored tool presented as a context layer for AI coding agents. It synthesizes organizational data (PRs, docs, Slack, JIRA) to give agents better understanding, aiming to produce higher quality code with fewer tokens and correction loops.

Topic Timeline

00:00:00 — Introduction to AI’s impact on software engineering careers — Jonathan Cuttrell introduces the episode’s theme: how AI is fundamentally changing the software industry and what this means for individual careers. He states the goal is to look beyond faster coding or cool tools to examine the broader organizational and economic shifts caused by AI’s core capability changes.
00:02:14 — Historical analogy: The shift from physical to digital delivery — Cuttrell recalls the era of Windows 95 and physical software distribution. He explains how the difficulty and cost of patching post-release shaped industry practices, leading to heavy investment in pre-release testing and risk mitigation. The subsequent shift to ubiquitous internet access made updates cheap, which changed the economic calculations for businesses and reduced the cost of bugs.
00:11:09 — Sponsor message from Unblocked — An advertisement for Unblocked, a tool described as a context layer for AI coding agents. It claims to synthesize PRs, docs, Slack messages, and JIRA issues to give agents better organizational context, leading to higher quality code, fewer tokens used, and fewer correction loops.
00:12:49 — Defining the current AI-driven capability shift — Cuttrell identifies the major change: coding has become a very cheap activity. While fundamental coding skills remain useful, the expense of implementing features, integrating libraries, or upgrading packages has dropped significantly. This makes the engineering function less of a bottleneck in the software development lifecycle.
00:16:00 — The implications of removing the engineering bottleneck — The host explores what happens when a key bottleneck is released. In organizations built around engineering being the slow, expensive step, the immediate effect is likely the discovery of a new upstream bottleneck (e.g., product specification). Engineers may find themselves waiting for work. The long-term effect is a pipeline redesign where businesses may lessen risk mitigation to increase volume and decision speed.
00:22:55 — How organizations will adapt to the new bottleneck — Cuttrell predicts organizations will lessen the criticality of risk mitigation, shipping products with a higher likelihood of bugs or failure because the increased volume compensates for the risk. The pipeline may change so that decision-making is consolidated, enabling faster, more iterative development similar to early-stage startups where builders and decision-makers are closely aligned.
00:27:57 — The enduring value of an engineering mindset — In conclusion, Cuttrell emphasizes that engineers must maintain their core mindset. Being an engineer is defined by systems thinking and a problem-solving approach, not by the specific act of coding. He encourages listeners to proactively engage with these changes, talk with teammates, and take control of their career trajectory in this new era.

Episode Info

Podcast: Developer Tea
Author: Jonathan Cutrell
Category: Technology Business Careers Society & Culture
Published: 2026-03-03T10:00:00Z
Duration: 00:29:52

References

URL PocketCasts: https://pocketcasts.com/podcast/developer-tea/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/ai-moves-the-bottleneck-are-you-ready-for-what-that-means-for-your-career/8ef48e91-59c8-47fd-8b0e-637af084f271
Episode UUID: 8ef48e91-59c8-47fd-8b0e-637af084f271

Podcast Info

Name: Developer Tea
Type: episodic
Site: http://www.developertea.com
UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263

Transcript

[00:00:00] these might be some of the biggest changes in our industry’s history and it’s up to you to

[00:00:13] figure out what that means for your career no one else can do that for you and in today’s episode

[00:00:19] we’re going to talk about how the industry is changing how it’s going to affect from a macro

[00:00:24] perspective most organizations and where do we fit in all of that as software engineers my name

[00:00:31] is jonathan cuttrell you’re listening to developer t and my goal on the show is to help driven

[00:00:35] developers like you find clarity perspective and purpose in your careers we’re talking about ai

[00:00:40] everyone is talking about ai and it’s not because it’s a buzzy topic it’s because it is genuinely

[00:00:46] changing what we do it’s changing how we perform our jobs but it’s not just

[00:00:54] changing the practice of writing code of course it’s not of course you know that this is changing

[00:01:02] much more than that but in today’s episode i don’t want to just talk about how much faster

[00:01:09] you can go or how cool agentic flows are or how likely it is for ai to produce a bug and we’re

[00:01:18] not also not going to talk about the latest models or anything like that uh instead i want to talk

[00:01:24] talk about some of the impact that this core capability shift, first of all, what is the

[00:01:34] capability shift from a business perspective? And how does it change business? How does it

[00:01:42] change most organizations and how they operate? And what will it do to your role? What will it

[00:01:48] do to your team, to your career? So we’re going to talk about this bigger pattern,

[00:01:59] one important driver for what’s going to happen organizationally as AI continues to make

[00:02:05] a huge impact on our world. So I want to kind of go back in history. I was alive for this. Many of

[00:02:14] you may have been as well.

[00:02:18] Early days of personal computing. And specifically, I’m thinking of like Windows 95,

[00:02:28] right? In the mid 90s, you would see Windows 95 on a shelf. And in fact, you’d even see,

[00:02:37] you know, AOL hours on a disk on a shelf as well. But thinking of something like an operating

[00:02:44] system. And if you just think about,

[00:02:48] what that implies. Shipping software was in many respects, similar to sending a rover,

[00:02:58] the Mars rover into space. You know, you can update that software, you could release a patch,

[00:03:04] for example. But certainly not everyone even had the internet, had access to the internet.

[00:03:11] If they did, they probably had very limited access to fast enough internet,

[00:03:18] to download an entire OS might take days.

[00:03:23] Patches would probably not necessarily auto download. So you’d have to choose to,

[00:03:31] to go and get the patch probably.

[00:03:34] Right, it was unlikely that it was like a call home or something in these early versions. And,

[00:03:41] you know, so for this reason, iteration, and, you know, iterating in public or iterating

[00:03:48] posts,

[00:03:48] delivery was not a simple task. And so you can imagine that every bug fixed before delivery

[00:03:58] was the league’s cheaper, was significantly cheaper to fix that bug than if it was,

[00:04:07] if it was found post delivery. And probably most bugs found post delivery never got fixed.

[00:04:14] Right, because it was just the ROI of even fixing that bug,

[00:04:18] trying to distribute that software again, was probably enormously in favor of not fixing in

[00:04:27] most cases, right? So maybe high severity bugs or something, you could imagine. But,

[00:04:32] you know, it’s unlikely that people even had this conceptual model at the time, because they just

[00:04:41] bought a completed product. And most of the time when you buy a completed product, you expect it to

[00:04:46] work as it was intended.

[00:04:48] And so the market at the time and the economics of software delivery at the time preferred a lot

[00:04:59] of testing, and a lot of risk mitigation, far more than what we have, what we have had

[00:05:09] for many years. Right? So, you know, front loading all the testing, you know, going above and beyond

[00:05:18] on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on,

[00:05:18] on this test delivery, because if you were to think about, and the reason I compare this to the

[00:05:22] Mars Rover is because once the Mars Rover is delivered, sure, you could send a patch, but it’s

[00:05:28] not easy. In fact, it may even be easier to patch the Mars Rover than it would be to patch Windows

[00:05:35] 95. I don’t know exactly what those numbers would net out to, but they’re certainly similar in terms

[00:05:42] of difficulty of dealing with, you know, issues after the fact, right?

[00:05:47] And so there’s something about the shape of that delivery pattern, or, you know, the way the market

[00:05:54] was shaped, the way the underlying technology, what it enabled, what it restricted, some of the

[00:06:02] actual logistics that shaped the industry, that changed the decision making for the pipeline of

[00:06:09] software delivery for companies like Windows in the mid 90s. Right? For companies like Microsoft,

[00:06:15] building Windows in the mid 90s. So, you know, of course, if you fast forward, even 10 years later,

[00:06:23] things had changed drastically, we were delivering software updates, you know, as often as daily

[00:06:30] websites, more, more broadly speaking, were constantly updated, sometimes, you know, every,

[00:06:40] every load that you would load a website, you might get something different, right? And,

[00:06:45] you know, software was no longer stuck in the physical delivery realm, because access to the

[00:06:52] internet, especially on personal computers became essentially ubiquitous, right? We no longer have

[00:06:57] to worry with sending physical disks, you know, CDs, hard disks, floppies, those don’t have to go

[00:07:05] out, we can just send a patch, and the person is going to update all their software. And in fact,

[00:07:13] you know, culturally speaking, we’ve gotten

[00:07:15] to the place where updates are, we, most people have things set to automatically update now,

[00:07:21] anyway. So, whether you’re talking about web application delivery, which people don’t even

[00:07:28] explicitly have to say that they want to update, or native software, as a, as a broad generalization,

[00:07:37] sending updates for that software is very, very simple. The actual update, you know,

[00:07:43] release process is fairly cheap.

[00:07:45] So, this changed the market, it changed the way that we think about delivering software. And

[00:07:55] specifically, what it changed was, there was less, you know, risk and less cost in shipping a bug.

[00:08:05] Right? If you think about what this really means, it means that bugs become cheaper.

[00:08:12] Okay, bugs become cheaper.

[00:08:14] Now,

[00:08:15] you probably wouldn’t phrase it that way, you might think, well, really, all it means is that

[00:08:19] we can deliver software easier. Yes, but if bugs become cheaper, that means that the ROI of trying

[00:08:28] to eliminate all of the bugs early, or before you release, that ROI equation changes as well.

[00:08:37] Right? You know, and when I say bugs, I don’t just mean, you know, bad software, it could also mean

[00:08:45] more bugs.

[00:08:46] Right? And that’s the offering, the software last time you did the training.

[00:08:47] Right now, you’ve got a bonafide feel, this approach, the software that the market doesn’t

[00:08:50] like as much as you hope, right if a feature that doesn’t land,

[00:08:52] well, that also becomes cheaper, that the failure risk becomes cheaper, because the delivery practice of

[00:08:57] software, that particular part of the bottleneck, right, the pipeline of delivery, that particular

[00:08:59] bottleneck of getting the software onto our customers computers onto their machines, onto their

[00:09:06] devices, or even software personalities.

[00:09:08] Right? As we go forever faster, that will give LeadB league the chance, this is something that we throw into our

[00:09:11] swing decisions, animal gears will also want to go faster so that they can do more怎么样 80 you want to

[00:09:12] וב

[00:09:15] devices that bottleneck was lifted essentially right it’s essentially gone uh you know maybe

[00:09:23] it still provides some friction in some cases but drastically better than it was in the mid 90s

[00:09:30] delivering windows so because the fundamental pipeline changed the calculations changed

[00:09:41] that means that a intelligent business owner would change the way they make decisions

[00:09:51] where previously they would have invested in you know copious large numbers of qa engineers for

[00:10:00] example they may have invested in much longer timelines they may have even invested in a lot

[00:10:08] more marketing for the release itself

[00:10:10] you know

[00:10:11] okay if you think about how all of those decisions they shift they shift and now you can do soft

[00:10:18] releases you can do beta releases you can release partial features you can release whatever you want

[00:10:23] to almost whenever you want to to whoever you want to and so all of the decisions around building up

[00:10:31] to a single large release they change now it doesn’t mean that people don’t benefit from doing

[00:10:37] a market push that’s not what i’m saying it also doesn’t mean that people don’t

[00:10:41] benefit from having a qa team i want to be clear that i’m not calling for you know the eradication

[00:10:47] of qa teams and by the way all of what was going to happen in this particular shift in the industry

[00:10:53] has essentially already happened uh but this shift caused the decision-making frameworks to change

[00:11:02] now i’m going to talk about the most recent shift and how it’s going to change decision making right

[00:11:09] after we talk about today’s sports

[00:11:11] this episode of developer t is sponsored by unblocked your coding agents have access to

[00:11:22] your code base and and probably more uh maybe you’ve connected other tools via mcps maybe you

[00:11:28] can push up to github or something uh and it can pull down changes and and read that stuff but it’s

[00:11:34] not easy to keep up with all of those and access doesn’t just translate directly into context it’s

[00:11:41] not easy to keep up with all of those and access doesn’t just translate directly into context agents can’t reason across mcps very well they don’t know

[00:11:46] your architectural decisions your team patterns or why the api was shaped the way it is so agents

[00:11:53] often look in the wrong place and end up delivering bad outputs based on bad assumptions then you spend

[00:11:59] time correcting wasting time and tokens unblocked is the context layer your agents are missing

[00:12:07] it synthesizes your prs your docs your slack messages and your geo accesses and also your

[00:12:11] JIRA issues into organizational context that agents actually understand.

[00:12:15] So they make better plans, write higher quality code, use fewer tokens, and require fewer

[00:12:21] correction loops.

[00:12:22] If you’re currently running clogged code, cursor, or any other agentic workflow, Unblocked

[00:12:28] is worth a look.

[00:12:29] Get a free three-week trial at getunblocked.com slash developer T. That’s getunblocked.com

[00:12:37] slash developer T.

[00:12:38] Thanks again to Unblocked for sponsoring today’s episode of Developer T.

[00:12:49] So what exactly is the big change in the industry that we’re talking about?

[00:12:56] And why is it so important?

[00:12:57] How is it going to change the way we do business?

[00:13:00] I don’t want to get into too many of the specifics because one, you all are probably hearing

[00:13:06] this all the time.

[00:13:07] And you don’t need to hear it again.

[00:13:09] But two, because it’s changing so fast that it’s very likely that this is going to be

[00:13:13] out of date almost as fast as you hear it.

[00:13:16] But I do want to talk about some of the trending directions for some of the big pieces that

[00:13:22] are probably not going to change as quickly as the specific skills and techniques are.

[00:13:30] The major change that has occurred is that coding has become a very cheap activity.

[00:13:37] And I say that as carefully as I can because I want to respect the fact that all of us really built

[00:13:46] our careers on learning how to code well.

[00:13:49] And on this show, on many occasions, I’m sure I’ve talked about the criticality of keeping

[00:13:55] those skills.

[00:13:56] And I do believe that fundamental coding skills will continue to be a useful thing to have.

[00:14:03] But in a different way than it has been in the past.

[00:14:07] So, and again, I don’t want to dive into why specifically.

[00:14:12] We can talk about that in another episode maybe.

[00:14:15] But coding and putting together code, putting features together, bringing together calls

[00:14:21] of libraries and even migrating or upgrading a package, something as simple as that.

[00:14:29] But the expense incurred to do those activities is significantly lower.

[00:14:37] All right, so there are lots of signals that even one step higher, so executing on a series

[00:14:50] of design decisions when given direction or given specification, for example, those tasks

[00:15:00] are becoming simpler to do.

[00:15:03] They’re becoming cheaper.

[00:15:04] And as a broad generalization.

[00:15:07] If you’re looking at the typical software development lifecycle pipeline front to back, where

[00:15:14] engineering is somewhere towards the end of that lifecycle and release and even maintenance might be

[00:15:20] considered a part of this lifecycle as well, depending on how you draw it out, the engineering

[00:15:27] function is becoming less of a bottleneck.

[00:15:31] I don’t want to say that it’s largely becoming cheaper yet because the jury is still out on some of

[00:15:37] this.

[00:15:37] On whether we’re actually going to see improved ROI, et cetera.

[00:15:44] But what is pretty clear is that engineering is less of a bottleneck.

[00:15:51] Okay.

[00:15:53] It’s important to recognize though, why this matters so much and why it’s going to change things.

[00:16:00] If you think about what do we mean when we say bottleneck?

[00:16:05] And how do we kind of realize that?

[00:16:07] And how do we kind of realize that?

[00:16:07] react to bottlenecks. Previous to this kind of explosion in agentic coding, for example,

[00:16:16] previous to that, and, you know, let’s say 2020, 2022, sometime around then,

[00:16:23] you know, a lot of our processes, a lot of our planning, a lot of our preparation and

[00:16:29] specifications and all of the things that we worked on as software engineers with our product

[00:16:34] partners or with, you know, our stakeholders, a lot of them were centralized on the idea

[00:16:41] of clarifying the work that we want to engage, right? And in fact, many times we would refer

[00:16:51] to this pipe as a funnel, the product pipeline or product development pipeline, product development

[00:16:59] funnel, where a lot of ideas would start at the top of that funnel.

[00:17:04] And then we would winnow those ideas down as much as possible before we would act on them.

[00:17:11] With the assumption that the high part of this funnel is actually the cheap part,

[00:17:17] right? That it’s easy to talk about ideas. It’s cheap to talk about ideas.

[00:17:21] It’s cheap to put them on, you know, a brainstorm board, but it’s very expensive

[00:17:27] to actually execute and deliver and, you know, put all of that stuff into production.

[00:17:34] It’s expensive to maintain that code. And so we want to do as little of that as necessary

[00:17:41] to continue to function as a business. The more code we have, the more liability we have,

[00:17:48] the more code we have to write, you know, generally speaking, the more expense we have

[00:17:54] in paying engineers to write that code. And the expense also comes in terms of risk. It comes in

[00:18:01] a lot of other factors as to why we’re doing this. And so we want to do as little of that as

[00:18:03] necessary to continue to function as a business. And so we want to do as little of that as necessary

[00:18:04] to continue to function as a business. And so we want to do as little of that as necessary

[00:18:04] engineering would, generally speaking, would be considered a costly step in this process, right?

[00:18:12] And so, again, a lot of our processes were optimized for eliminating work as early as possible in the funnel so that it never hit engineers’ plates in the first place.

[00:18:28] It’s unclear, and it kind of depends on your business and how you operate for your specific pipeline, whether engineering is still the bottleneck for you.

[00:18:41] It may not be, but it is less of a bottleneck, right?

[00:18:48] It is becoming less expensive to engage in engineering, at least in the early kind of evidence that we have.

[00:18:58] A lot of the things that previously may have taken significantly more time, the timelines are shorter.

[00:19:05] There’s a lot of effects that would lead people to that conclusion, that engineering is less expensive.

[00:19:11] Okay, so as we release this bottleneck, what happens?

[00:19:17] What are businesses going to do?

[00:19:19] You might think, okay, well, it just means we’re going to deliver more, right?

[00:19:23] And while that’s kind of partially true, it’s actually one part of it that we’re going to talk about.

[00:19:29] It’s not the main effect.

[00:19:32] The main effect in a well-oiled machine, a business that has kind of built its pipeline around the engineering bottleneck,

[00:19:41] is that it’s going to deliver more.

[00:19:41] The main effect is that the pipeline is going to break in some way first.

[00:19:46] And usually what happens with bottlenecks, if you release a bottleneck, you find a new one, right?

[00:19:52] This is actually very typical.

[00:19:54] It’s kind of like a long-running, you know, if you read The Goal, for example,

[00:20:01] they talk about this specific pattern of once you release one bottleneck, you’re going to then find a new bottleneck.

[00:20:08] And then your problems will shift and change shape.

[00:20:11] And so, depending on how well, you know, sized all of your other functions are,

[00:20:19] when your engineering function suddenly increases capacity and throughput potential,

[00:20:26] then the rest of your bottlenecks or the next, you know, smallest bottleneck is going to become more visible.

[00:20:35] Now, this is especially important if your other bottlenecks are upstream of you.

[00:20:41] Right?

[00:20:41] So, in that funnel, if suddenly something above you in that funnel becomes slower than the throughput that you have,

[00:20:52] then you’re going to end up as an engineering team waiting.

[00:20:56] You’re going to end up waiting on whatever is upstream.

[00:20:59] So, the early effect here is most likely that teams are going to recognize that there’s an upstream bottleneck.

[00:21:08] And also, the naive…

[00:21:11] thought is that engineers should be delivering more.

[00:21:16] And so, you’re going to have engineers who are asking,

[00:21:18] what exactly are we supposed to be delivering here?

[00:21:21] You know, because the upstream of our funnel is not giving us anything to work on.

[00:21:28] It’s unclear exactly what we’re supposed to do with all this new firepower that we have.

[00:21:33] Right?

[00:21:34] So, that’s an early effect that will happen.

[00:21:36] But eventually, that pipeline bottleneck will move.

[00:21:41] And…

[00:21:42] attention will move.

[00:21:43] And then the pipeline will get redesigned.

[00:21:46] Right?

[00:21:46] So, what will happen is, most likely, if it’s upstream,

[00:21:50] engineers and other people upstream are going to change the way they work so that more can flow through.

[00:22:00] Now, what does this actually mean for delivery?

[00:22:03] It means that, very likely, those functions that were being served upstream to mitigate risk,

[00:22:11] as much as possible,

[00:22:12] now, we either have to figure out how to mitigate the same amount of risk faster,

[00:22:18] right?

[00:22:18] More throughput.

[00:22:19] Or, if we shift our thinking to avoid optimizing for the wrong things,

[00:22:29] in other words, you know, if previously we were trying to mitigate risk because engineering is so expensive,

[00:22:35] now engineering is less expensive than our previous assertion that risk mitigation was,

[00:22:41] is important because engineering is expensive, is no longer valid, right?

[00:22:44] So, now, do we still need to mitigate as much risk?

[00:22:50] What can we do?

[00:22:51] What might we change about our strategy?

[00:22:55] And, very likely, most organizations, what’s going to happen, you’re already seeing this happen, by the way,

[00:23:01] most organizations are going to lessen the criticality of risk mitigation.

[00:23:11] Okay, what does that actually mean in practice?

[00:23:13] It means that people are going to ship products that are less likely to succeed.

[00:23:19] They’re going to ship products that have a higher likelihood of a bug.

[00:23:23] And the reason for this is because the volume increase that they get

[00:23:28] by removing some of these more expensive new bottlenecks, by the way,

[00:23:32] more expensive risk mitigation strategies, that’s how they’re going to relieve that bottleneck, right?

[00:23:38] The volume increase.

[00:23:41] Is going to, in most cases, make up for,

[00:23:45] it’s going to make up for the potential loss that you could see from, you know,

[00:23:53] a feature that was delivered that just kind of flopped, right?

[00:23:57] You know, we should be very clear here and be very careful that there are some versions of this that end in bugs that are catastrophic, right?

[00:24:10] That might cause a huge amount of damage, right?

[00:24:11] is a huge data breach for example or loss of majorly important ip uh there there’s a lot of

[00:24:18] potential for that pipeline because it’s shaped in a different way now we should be looking at

[00:24:26] that pipeline for a new type of risk the risk profile changes right but it’s not um it’s it’s

[00:24:34] unlikely that things will stay the same and suddenly engineering is just faster right

[00:24:42] if we are indeed seeing things like 50 improvement or even 100 improvement on throughput

[00:24:49] for engineers then it’s likely that you know those those uh the things that kind of got shelved or

[00:24:59] fell below the line the cut line and product now those things are going to get

[00:25:03] a

[00:25:04] a

[00:25:04] a green light right the other potential here is that the pipeline will change entirely

[00:25:10] so that the only source uh point for work shifts to multiple source points most likely the person

[00:25:19] who is driving the agentic uh you know machine whatever that is is going to have more decision

[00:25:25] power so this person may be able to make decisions on the fly to improve the quality of product

[00:25:34] in a way that is more responsive and iterative than going back to another human right and and

[00:25:41] trying to improve it with that other human this is uh you know one of the effects that you see in

[00:25:46] early startups where the person who’s building the product is also the person who’s making all

[00:25:51] the decisions about that product and they’re very in touch with you know what the product needs to

[00:25:56] be or or they’re very in touch with the stakeholders they’re playing multiple roles well there’s little

[00:26:01] translation um the product needs to be in touch with the stakeholders and they’re playing multiple

[00:26:04] roles well there’s little translation and they’re playing multiple roles well they’re playing multiple

[00:26:04] roles well there’s little translation and it’s good for you know moving from one phase to the

[00:26:06] next phase in product development it’s all kind of one uh uh effort and we are likely going to

[00:26:12] see more of that kind of effort from software engineers who are using uh who are given a little

[00:26:19] bit more latitude right latitude uh to make decisions on the fly you’re probably going to see

[00:26:26] you know pair coding sessions but it’s going to be between a product manager a designer and

[00:26:31] an engineer and the engineer is

[00:26:33] is uh producing prompting or or they are collectively prompting uh the machine and

[00:26:40] looking at outputs and you know driving things from that angle as well uh so the the big shift

[00:26:47] here is the pipeline though and and i think that’s the important thing the mental model for you to

[00:26:52] carry forward is what happens when this bottleneck shifts and how can i be ready for higher volume

[00:27:00] throughput right how can i kind of reacquaint or or uh reconfigure my mindset to avoid believing

[00:27:08] that engineering is the most expensive step in the process and now consider it uh consider

[00:27:15] optimizing for something different than just risk mitigation uh you know we we may be optimizing

[00:27:21] for example for decision speed right how quickly can we make decisions if we consolidate the

[00:27:28] decision making into fewer people

[00:27:30] for example that’s very likely uh to be a you know a much faster decision making process and

[00:27:37] you’re probably going to deliver significantly more and now your pipeline starts to get balanced

[00:27:42] again right uh you’re able to make faster decisions upstream of engineering at that point

[00:27:48] overall i think it’s important for us to maintain our engineering mindset throughout all of this

[00:27:57] engineers think in systems engineers

[00:28:00] think in terms of uh how our changes affect the system not just a single component right

[00:28:07] if you approach this new kind of um we could call it a new era for software engineers

[00:28:16] approach it with the mindset of an engineer

[00:28:20] uh coding is not what makes you an engineer reviewing code is not what makes you an engineer

[00:28:27] you know in the same way you’re not making a difference between the two you’re not making a

[00:28:30] that punching cards didn’t make people engineers

[00:28:33] um in the same way that knowing how to manage memory manually and garbage collect is not

[00:28:43] the one thing that makes you an engineer your way of approaching problems is what makes you an

[00:28:50] engineer and i know this is a uh this this is a time when anxiety is high for all of us because

[00:28:59] our jobs are changing and we’re not making a difference between the two we’re not making a

[00:29:00] and with change comes anxiety but i encourage you to take a step back and look at this like an

[00:29:07] engineer and then decide how you’re going to engage thank you so much for listening to today’s

[00:29:13] episode of developer t i hope you’re encouraged by this i hope you’re challenged by it i hope

[00:29:18] that you can go and talk to your product partners talk to your teammates

[00:29:22] talk about how this is changing your career and what to do about it don’t just sit back

[00:29:28] and uh you know

[00:29:30] and and let it all hit you uh um be in the driver’s seat and take control of of the career

[00:29:38] that is only yours to drive thanks so much for listening and until next time enjoy your tea

Vox

Explorador