When you’re skilled at AI Engineering, your best work won’t be merely implementing a product that someone else spec’ed out. Instead, you will actively shape the build.
Before modern AI tools accelerated and expanded what a single developer could do, tech companies established the practice of having product managers (PMs) and designers specify what should be built and then developers build it. Perhaps a project manager additionally drives the timeline. However, these roles are blurring. A developer who is skilled at AI engineering not only builds software but participates in these other roles. (Similarly, product managers and designers are gaining AI Engineering skills and participating in building software.)
This change is vastly accelerating software development. When you know how to shape the build, you can move faster without waiting for a PM to figure out what to do.
The key skills for shaping the build are:
Driving the build loop
Making product decisions
Communicating and leading
High-agency ownership
Driving the build loop. Most software is built via a loop in which you write some code, then get some feedback, and decide what to do next. As a skilled AI engineer, you play a key role in driving this loop, repeatedly deciding on the next step to move your project forward. You have a bias for action, and drive this loop at the high velocity that AI has made possible.
For example, you might decide to build a quick prototype to test a technical concept or user feature, build an MVP (minimum viable product) to take to users to demonstrate value, add features, or invest in an enterprise-grade system. You frequently ship in small batches to keep up velocity. You know when to get feedback from users or other stakeholders, or when to run a technical experiment (such as train a model) to gather information to decide the next step. You make these decisions taking into account the product vision, stage of the project, technical feasibility, key risks, effort, and budget. For more mature projects, you know how to define key metrics and project-manage to drive improvements to those metrics.
Making product decisions. Developers don’t have to become PMs, but you will make decisions the product spec doesn’t cover. If you are asked to build without a spec, you know how to develop one.
You have product sense that enables you to pick a product direction that meets real user needs, without having to wait for a PM to make every decision. You also have at least a basic design sense, and can build things that aren’t just functional but pleasing to use. You also have some basic business sense, so you can think through issues like go-to-market, market size, unit economics, and profit and loss (P&L) and make tradeoffs that are economically sensible. Your ability to make product decisions is rooted in your user empathy. Further, you continually hone this empathy using a wide range of methods, such as quick informal interviews with 2-3 users, surveys of hundreds of users, large-scale A/B tests, or analyzing the behaviors of thousands or millions of users. You use the resulting input to improve your understanding of users.