Just a couple of opinions and takes on the current state of the industry since I’ve started using AI commercially, where I think we’re headed, reflections, and what I’ve found effective in my own work. Enjoy, and throw me a clap if you did! 😊
Natural language is the next programming language
“The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.” — John V. Guttag, Computer Scientist
Abstractions are everywhere — driving the car, using Google maps, making your morning coffee. All of these things that seem so simple to us do some incredibly complex things under the hood, but to the average consumer we couldn’t care less about how any of it works so long as we’re getting the desired output from our actioned intent, click button to get coffee, drive car to get to location, use map to see where you need to go.
The best part about an abstraction is we don’t need to understand how to get the thing we want, abstractions set expectations due to how commodified the things we take for granted have become, and how we’ve progressed as a human race to work smarter not harder — to not re-invent wheels. No one is raising a cow for 6 years if they want a cheeseburger, they’re just gonna buy the cheeseburger.
Cows aside, the same can be said about agentic engineering: the syntax no longer matters, being competent in a programming language no longer matters, being competent in architecture matters more than ever, there are no blockers or excuses to shipping anything you want in 2026. With the right guardrails in place, you just need to supply your agents with enough intent and with a well written prompt and enough planning, you can build anything at substantial pace and quality to your favourite flavour of engineering without even reading the output.
The code doesn’t matter anymore, what do I mean by this? I mean the process by which the human needs to care about and understand every single line of their implementation, patterns, and primitives of the language in order to achieve a tangible output is obsolete. Agents can already write great code when used effectively and that doesn’t matter if you’re writing a compiler in Rust or building an app in React — the act of respecting your engineering standards or how the language works becomes the agents problem, not yours.
Of course the languages we all love will still exist: JavaScript for the browser, SQL for databases, C++ for native desktop etc. (unless we get one mega language that can do everything which is purpose built for agents). Either way the more frontier models continue to get capable, the better engineers get at becoming more efficient at building their “software factories” results in a deeper thought of mine “What engineering teams build becomes limited to how quick businesses can move and make decisions instead of how many tickets an IC can ship in a sprint. The act of punching code into a keyboard yields no value anymore, worrying about engineering velocity is a thing of the past.”
And that transaction has always been true — the input (requirements) go in and the output (software) comes out, it’s just our journey and experience from 0–1 that has substantially changed, it’s about taking our already wired engineering brain and changing where we direct our technical focus now. You’ve got to be open to discomfort, being wrong, change, growth, and more importantly willing to leave some of the attached ways of working behind that worked. That can be difficult to let go of at first.
Writing code was never what made anyone special
“Engineering fundamentals are your biggest advantage” — Matt Pocock
The needle has moved completely from writing code to putting as much of our eggs in the basket of optimising the AX (agent experience). The better the experience of your agents, the better quality outputs you get from them, this has always been true for humans even before the advent of AI — we’d do this by optimising the DX (developer experience). After years of building software and being part of many different brilliant teams whether I was working internally or forward deployed, it’s the people who put care and effort into the developer experience who yield a much higher RoI for the business comparatively against those who don’t. Agents are no different.
That said I used to think writing code was what made me special, I could do a thing other people couldn’t do. Growing up my parents would say “how do you understand all those numbers and colours on the screen??” and it gives you a bit of a chip on your shoulder.
In hindsight though, it was never the labour of writing code that made me a valuable engineer. It was the chicken not the egg, what makes me a valuable engineer is the ability to map business problems direct to technical solutions and that isn’t changing, you still need to sit in a room to tell an executive or VP how their problems are going to be solved with technology and more importantly confidence, the HITL step of managing a stakeholder expectation isn’t going away and that’s something no amount of agents can compete with.
If you have core engineering fundamentals and a solid understanding of how the systems you’re contributing to work, regardless of complexity, whether that’s a monolith, a distributed microservices architecture, an event-driven system, or even a simple client-server model, there’s nothing stopping you from meaningfully contributing across the stack anymore.
I’ve never written a line of HCL code in my life, yet I’ve shipped and provisioned production infrastructure with Terraform for a live AWS estate that scales from day 1 for over 400,000 users whilst re-platforming the user base to a new subdomain. Whilst simple, I don’t need to know the intricacies of how HCL works in order to complete this task, Terraform already lends itself to being agent-native due to it being an IaC solution, something that agents benefit greatly from so instead I learned the useful parts needed to conjure the result — that being Terraform and the AWS services required to fit together architecturally and satisfy the business requirement.
I put more of my effort into deep technical thinking, planning, and architecture instead of worrying about the syntax being right or if I’ve made a typo somewhere, agents give me the ability to focus my effort on doing the useful work right — fitting the jigsaw pieces together is one of the funnest parts about being an engineer, to learn and do things that would of otherwise taken me months of work is really great thing.
Think how an agent would for better results
I remember back in the day before AI if you were valuable engineer at your company and took full ownership of a production application or core parts of it, it could be a difficult conversation taking leave, finding someone competent to cover for you, and you’d be first protocol if sh*t hit the fan.
That’s all gone, sure we have documentation but documentation is only agent-native if you make it so, and lets be honest engineers don’t like writing documentation or have the time. Agents LOVE documentation, they guzzle it up like gummies, just put your documentation close to your source as markdown files and you’re on your way.
If your standards, architecture, codebase etc are well documented in whatever consumable agent medium your company is comfortable with then there’s really no excuses to be blocking contributions because “important employee number 3 isn’t around” — agents pick up that load, code must still ship, tokens must continue flowing, the business must continue getting built.
And it’s really not complicated, agents are dumb and once you understand how they work it becomes incredibly easy to be efficient with them. If I had to distill effective agent usage into a few points it would be:
- Power your agents with good relevant context, good context is a well written
AGENTS.mdwith progressive disclosure, a/docsfolder for detailed documentation,adr's (architecture decision records) for a collection of important architectural decisions, and someskillsthat are both user and agent invocable that benefit you/your team - Give them access to all the CLI’s! If agents were sharks and you had to decide to put the shark in an environment it’s effective in and you had a choice between a fish tank or the ocean you’re gonna go ocean each time. The CLI is the ocean, it acts as the powerhouse of tools your agent has access to, think of the things a computer is naturally good at and expose those capabilities to your agents (especially great if your cloud provider exposes a great CLI like AWS CLI)
- Agents have memories like a sieve so keep iterating and to make your context better, what are repeatable mistakes they’re making across tasks, tweak your context, the quicker an agent can get up to speed in a new context window the better your agentic workflow
- Whilst I don’t think git worktrees (or git itself) is a great tool for agents, they are really useful in parallelising tasks, this adds a layer of cognitive load but it’s vastly better than babysitting one agent as that’s just not efficient
- Use MCP servers to automate workflows, I’ve found Figma and Atlassian to be really good in day to day work
- Accompany CLI and MCP usage in skills so that your agents naturally use them where relevant automatically in your workflow
Spec-Driven Development is great btw
The best source I’ve found for understanding spec-driven development is this markdown file that describes it in detail part of the open source library spec-kit (https://github.com/github/spec-kit), whilst I haven’t used the library before it’s a phenomenal way to convey the goal of the methodology. Below is an excerpt of this:
“The gap between specification and implementation has plagued software development since its inception. We’ve tried to bridge it with better documentation, more detailed requirements, stricter processes. These approaches fail because they accept the gap as inevitable. They try to narrow it but never eliminate it. SDD eliminates the gap by making specifications and their concrete implementation plans born from the specification executable. When specifications and implementation plans generate code, there is no gap — only transformation.”
What a beautifully written piece of text! Once we have our codebase powered with all the relevant context our agents need to be useful we can begin being really ambitious, SDD is something I’ve been using heavily in my day to day workflow to not only be more efficient but to equally ensure I understand the implementation before the agent cuts a single line of code. If I’m introducing large infrastructure changes, building features that touch all layers of the stack, or even architecting something completely new I always start with a plan first.
You could use plan mode in Claude Code to achieve this or better yet there’s so many great skills that do this too, you could even build your own. One thing I learned quickly when I first started building with agents was the ambiguity tax I’d pay surrounding implementation work, which would result in either a shoddy naive implementation or frequent iteration cycles to tame the work into something I wanted to contribute.
I care a deep amount about confidence, both in myself and in the teams I’m apart of or leading. For me it’s not just about caring about the things that used to give us confidence like static code analysis checks in CI (tests/types etc.) — but the confidence that the engineer actually knows what they’re doing, and the verification steps following an implementation that ensure we aren’t just prompting into oblivion.
It’s hard for me to buy-in to an engineer who can’t explain what their change is doing but filed a 20+ file change PR, to be clear that doesn’t mean needing to understand every single line of code we’ve already touched on that being pointless, and it’s never been scalable really. But I’d expect an IC to understand the intent of it enough such that they can still confidently navigate the implementation, communicate it to me and peers so we all know the contribution made is a sound one that can be maintained. In saying that, you should still treat the code as if it could be thrown away tomorrow because the cost of a meaningful contribution is gone compared to when we weren’t building with agents.
It also allows you to tame your thoughts and just get something on black and white: starting with a vague plan at first from a user story, producing the plan, breaking the plan down into atomic sub-tasks to log in an issue tracker, and kicking off parallel sub-agents to implement it whilst you do something else.
Below is what my high-level workflow looks like using SDD, even looking at this now I’m already thinking of ways the HITL step of reviewing the plan can be automated out 😅 but here’s roughly what I’m rocking with right now!
Concluding
So what can we conclude from all of this madness happening in our industry? Well, it’s a lot. As an engineer keeping up today it’s ridiculous, and its really not good for the nervous system to always be adopting the shiny new thing because you want better efficiency gains — if I’m being honest I’ve found it exhausting at times. The only reason I have kept up somewhat is because my bread and butter is web development, and I lived and worked through the whole era of MVC, Webpack, SPA’s, server rendered apps, JavaScript on the server, new frameworks every other week — all of it, and that required quite an amount of willpower to get through 😂 AI is on a completely different level.
That’s all, keep building cool stuff and look after yourself! Thanks ☺️