What does the future look like for me (us) in a world with AI in it?
This is a prickly subject. It's current. It's bittersweet. It's impacting every one of us in tech for mixed reasons. I would say I'm a fairly positive and optimistic person, "living the dream". But, admittedly, the future looks kind of bleak right now and I'm not immune to this.
There are plenty of stories in various forms out there giving voice to the pros and cons of the situation in each person's individual circumstance or perspective. I wrote one about the death spiral which touches on doom slop and the notion of having an overwhelming stream of anxiety-inducing digital garbage.
Unfortunately, for my algorithms at least, it appears that I always see the extremes in the spectrum of the AI agenda.
I'm either seeing people wallowing about how it's dismantling the meaning of what an engineer is, the destruction of years of credible experience each person has built, or the negative impacts on the software development life cycle (SDLC).
On the other side, people are enjoying the freedom to be able to think solely about the product and create apps in a day, non-techies being able to run analytics or spin up dashboards without needing to ask engineers where the data is, or migrations of codebases because the skill gap has shrunk.
Thoughts and feelings
To try to answer the opening question, I'm looking at the people around me who work with AI every day. They sit somewhere between these two extremes, so I'm going to add to the spectrum in a balanced way. I personally believe that AI is made to augment our experience, like most tools and frameworks created in the last several decades.
I've created several personas on how I see various people work alongside AI. I'm not listing out every example here, just whimsical takes on various engineers or people and how those groups work. These are purely my own observations, with some satire, and as with the growth of AI, my perspective is changing weekly, if not daily.
The technical one
There are a handful of engineers I notice flitting around like hummingbirds, constantly moving between tickets, shifting swathes of code, and possibly making the rest of us look bad based on pull requests per person. They are usually the more experienced engineers, and one cause for concern is how quickly they have adopted AI, then baked it into literally everything they consume. Going further, the concern isn't their impact on themselves but the impact on the sphere of influence they have around them.
You can ask them what their workflow looks like and they will tell you they hardly write code anymore, and the speed of output comes from the tickets being pre-specced. Like a feeding frenzy at an all-you-can-eat buffet line, they are just handing off tickets to multiple agents and churning out pull requests (PRs) at a rate that is impossible to keep up with or truly review properly.
This leads to a bottleneck (more on that later), and the human is the cause. This raises the question of what processes have regressed to allow for this speed and which parts this person owns themselves. I have stated before that the engineers still have to own the risk; that shouldn't be delegated to the agents as well. In my opinion, senior engineers can get away with using AI the most because they have built up the experience to be mostly if not entirely hands off. But I always think about Newton's third law of action and reaction, the idea being that the speed of output creates an equal burden of review.
Has the level of experience blurred now if the agent is doing all the work? These types surely hold no more context on what the ticket is doing or the code than a junior engineer; what they do have, however, is more experience and understanding of why the agent did it a particular way, and that seems to be the difference. In discussions with these engineers, I've heard them say they don't need specific context on domains outside their knowledge base because the agent can read and solution-ise what's needed quicker than they can.
So here we have opted to have our most talented engineers loosen processes, hand over the reins to agents, and delegate domain knowledge, all in the name of more productivity. Except they may have unknowingly regressed their own roles, and they have clearly moved the bottleneck elsewhere. To be fair, they are still shipping real work, and the speed isn't an illusion.
The cautious one
Next, we have what I would call a cautious engineer. The conversations I've had with these types usually result in them questioning several aspects of the agentic workflow and the impact it can have on the SDLC, as well as their own workflows. They don't see the point in convoluted agentic files, the handful of pre-rolled skills that the company keeps telling them to use, or see a need to keep changing things for the sake of it when they believe what they have is good enough.
They are using AI for large parts of their workload, but unlike the 'technical one', they are cautious about the changes being made, don't over-automate everything about their process, and haven't gone all in out of fear of losing context.
From the outside, they will appear to move at the same pace they had done before AI took over the world. But talking with them, you will still find they are hesitant and not quickly adapting to changes because they are happy in the approach they have. They are still creating PRs with the hallmark which validates they are indeed using AI like everyone else, signed "generated with Claude Code".
Does this show diligence in their work, or are they missing the point of what AI can optimise? They may have retained context, but at a cost to productivity. It's uncertain whether they are less aware of what AI can do, or if the cacophony of robot agency is slowly making them despondent about the direction of travel. Or perhaps they're simply enjoying the craft whilst they can and adopting the change reluctantly.
The adaptive one
This type of user is similar to the 'cautious one' in many ways; they have some reluctance. But they differ in that they are largely open to the change that AI has brought. They treat AI more like a partner, somewhat like having pair programming on tap at all hours, using iterative approaches rather than accepting the first answer, deconstructing complex tasks into manageable checkpoints, and formulating their own collection of agentic practices.
Again, they aren't necessarily following the crowds and adopting everything wholesale; instead they are picking and choosing what works for them. They integrate MCPs as needed, use plugins if they make their life easier or because there's a need, and attend workshops in hopes of gaining insights around how others are using agentic workflows to better themselves.
When I speak with these types, it is clear they have their opinions but they are weakly held. They can see the pros and cons of both sides and are able to balance their decisions in how they ultimately work with AI in the best ways that benefit their effectiveness and productivity.
I suspect most people sit here. They are definitely striking the balance: they haven't gone all in on AI, but they aren't shying away from the change it is bringing. They aren't running on the bleeding edge, but will adopt the best practices quickly when they see an opportunity to address pain points in their workflows. I lean this way myself: it matches my optimism and my hope that people will learn to use AI well, for their own benefit and others'.
The non-technical one
Not everyone affected by AI is an engineer. This next type is someone we have all seen and probably helped. They are generally non-technical, but they focus on what they do know and use it to drive the change they are after.
The zero-to-one ideology suddenly becomes proof-of-concept to minimum viable product within a week or several days. They ask a couple of simple questions around several functional areas and disappear like a Homer Simpson meme, only to reappear on Monday with a prototype telling you how easy it was to build with AI, but you know full well that the product has holes in it like a bad Netflix drama.
Give them credit; they have managed to corral the pesky robots and sling a thing. They've vibed their way through and produced something where a picture is worth a thousand words, which is better than the days of them trying to articulate a feature through misunderstandings. They no longer need to chase you late in the afternoon to dig out which dashboards or services have what data they need when they can now just toss it to their agent (at the cost of a few thousand tokens) to find and connect the dots.
Juniors now sit in a similar position: able to ship something that appears to work, but without the experience to know why it works or when it won't. The gap here is technical experience. A product manager will know the product and features, but implementation and best practices are where they will fall short. Likewise, a junior hasn't yet built up an understanding of trade-offs and patterns. So how do they learn this if they outsource the learning part to an agent?
The casual one
This is the type of person I tend to come across outside the workplace, and they likely aren't what you would call technical at all. They are probably still coming to you about fixing the printer because you work in "IT". They've discovered AI like a caveman discovering fire. It's an almost abusive relationship as they now ask AI to do everything for them but most likely are causing a drought somewhere by creating a funny image of their pet dog.
Some positive use cases:
- Finding the cheapest offers for an item by screenshotting something then asking AI to scour the interwebs.
- Replying to school and asking AI to tone down the anger after a run-in with the teacher at drop-off.
- Reports or presentations, replacing those fabulous clip art and poorly timed animations with something that actually looks professional.
At the same time I'm reminded of this short, which pokes fun at how casual users approach AI. How people use these tools depends a lot on what they've been exposed to.
Hopefully they aren’t burning through tokens the way the tech industry does, because that’s where the environmental cost really adds up, with the monstrous data centres popping up globally.
Review fatigue and bottlenecks
It's an understatement to say that I'm in a constant review cycle, either reading responses from my army of agents or handling requests via Slack asking for reviews on a handful of PRs where the descriptions are overwhelmingly verbose and file changes have exploded.
I wouldn't call these slop grenades exactly, but they aren't human either. They've lost their succinctness and human touch. It's tiring to keep up. It's no longer an ebb and flow; it's just a tsunami that is leading to review fatigue and burnout. This is saturation for the sake of productivity and the consensus feels like you either need to get on board or be left behind. The answer to managing the bottlenecks is to automate more, add more agents, and integrate more ways to interact with them.
There is always a bottleneck (theory of constraints). When you fix one thing, your system simply produces another. Right now there are two constraints, and they're worth treating separately.
Attention (the human constraint)
We can't think or perceive as fast as a machine. This is the psychological bottleneck theory: our brains can only process so much at once, so they naturally filter stimuli. However fast machines get, human attention limits how much we can take in and act on.
Process (the structural constraint)
Separately from our cognitive limits, the way we work is still shaped by processes designed for a slower world. A PR review gate assumes a human can read every change before it merges, and a two-week sprint assumes work arrives in human-sized chunks. When an agent can open a dozen PRs before lunch, those assumptions start to break. We need to unravel them before new approaches can take hold, no matter how good the tools become.
Direction of travel
What I'm predominantly seeing is companies spending heavily on AI, and I wonder whether, having already invested so much, they are falling into a sunk cost fallacy. It still seems wild to me that they will throw thousands at enabling engineers to use AI and then buy new agentic SaaS products on top, to solve small to medium problems that might previously have been engineered in house.
Productivity and output appear to be what everything is being measured by, whether that is the token spend (tokenmaxxing), the increase in PR velocity, or the amount you can automate or offload onto your swarm of agents. All organisations have their own measurements but I feel it's all about proving that the spend on AI is worth it to the shareholders.
The risk is a loss of context and of true domain experts, and possibly a generation of juniors who never get the chance to build either. Reviews are quicker, and there's heavy reliance on agentic code review. AI is now writing the code and reviewing it too, with the human on standby to push the button to accept or merge.
What's working
Not everything I see is concerning. Many engineers around me are adapting readily. There's constant communication about what's working and what isn't, with water-cooler moments about personal AI setups. We're questioning whether moving compute to the cloud is efficient, migrating repetitive tasks to automated workflows where it makes sense, and sharing the best parts as teams figure out what works.
A recent example for me is developer tooling. I built an app called Baton. It solved a problem I had around testing whilst using agents, where they were consuming too many resources and kept colliding with each other. It started as a local harness, then grew to handle some repetitive tasks I kept taking on. Then I realised I had a half-baked product that would be useful to the community, so I productionised it. All of this took less than two weeks, because I could run agents concurrently alongside my other work. What made it work was that I owned the whole loop, from deciding what to build to reviewing what came back, so the speed didn't outrun my ability to check it.
Our ways of working are shifting too. Agents can handle much of the code now, so the engineering we've always known around the code doesn't exist in the same shape. The thinking hasn't gone away; it has moved to the processes around the code. More 'Product Engineer' roles are appearing, which makes sense, because we should always have been thinking about the product and the end user.
The difference now is that agents are end users in a different form. We need to include them in how we design our processes. If you want efficiency, it starts with how you engage with AI and embed it in your workflows. It doesn't remove you from the process; it moves you to a different part of it.
Looking outside of tech, there are positives too. AI is already helping unlock healthcare and scientific discoveries, with Google DeepMind's AlphaFold predicting the 3D structures of over 200 million proteins, work that would have taken years of expensive research. PwC forecasts that AI adoption could boost global GDP in the coming years, and we may even start seeing the fabled four-day working week thanks to AI efficiencies. None of that is guaranteed, but it's a reminder that the story isn't only about engineering teams.
I think we should be focusing on areas within our control that aren't immediately solved problems by the agent. We should continue to think about impact and what it provides for the user. Use AI where it makes sense to provide engineering efficiency and optimisations. Focus on valuemaxxing, which means judging AI by the outcomes it delivers rather than the tokens it burns. Baton and the workflow examples above are valuemaxxing in practice. Where AI augments these efficiencies, we can reduce spend in equally responsible ways.
Open questions
We should continue to explore how this is going to impact the future of engineering, and here are some questions, with my initial thoughts, to leave you with:
- What does mentorship look like where agents take on the workload of tasks a junior would previously have done to gain experience?
- This is the point I raised earlier about juniors: if the agent does the grunt work, where do they build the judgement to know when it's wrong? I suspect mentorship shifts from learning by doing grunt work to learning through more meaningful tasks. The old model may well break, and mentorship will need to adapt to bridge the new experience gap.
- At what point does it all become homogenised, with everything starting to look or feel the same?
- The reality is that real-world scenarios aren't concrete; they're messy. There is never a one-size-fits-all solution. Ideas are formed from constraints, context changes, human judgement, and uniqueness. As everything becomes similar, that's when uniqueness becomes more desirable. There are also theoretical limits here. Rice's theorem says that, in general, no tool can reliably decide non-trivial questions about what a program will do, and the halting problem is the classic case: no program can tell, for every program and input, whether it will finish or run forever. That matters when agents review agents' code, because there's no guarantee automated checking catches everything, which is where human judgement still matters.
- What does the future look like when our day-to-day work becomes a solved problem for AI?
- Imagine a future where your to-do list is permanently empty, having been quietly picked up by a team of agentic helpers who keep the world turning. While society basks in the ultimate freedom of universal basic income and abundance, we also risk a strange, collective brain fog as our hard-earned problem-solving skills slowly wither away from lack of use. Ultimately, it's a utopian landscape where the terrifying loss of human utility is perfectly balanced by the delightful freedom to spend our days mastering sourdough, tending to our gardens, and learning how to connect without an inbox getting in the way. There is, of course, a dystopian version of this, which I'll save for another time.
Where that leaves me
So, what does the future look like for me (us)? I don't think it's the doom or the hype I keep being served. It looks more like the adaptive middle: using AI where it helps, owning the risk and the judgement ourselves, and being deliberate about how the next generation learns, and about how we adapt in the next phase. The tools will change weekly. The "I" is the part that stays: the person deciding what's worth building and whether it's right.