AI and the way I work

Work has already changed

AI has revolutionised the way we work. For me, it is part of everyday work and has changed how I move from a need to a proposal I can test. I can explore more options and spend less effort on tasks that used to take up a significant share of the time available.

The change also affects how work is organised. A loosely defined need usually takes conversations, analysis and several revisions before it becomes something people can act on. AI can help organise that information and prepare options for discussion. That affects what we decide to do, as well as how quickly we do it.

This is where I see the scale of the change. As the effort needed to build a first version falls, different ideas become worth trying. Work we would once have ruled out because of its cost can become feasible. More of the difficulty moves towards choosing well and checking that what we build is useful.

Claude and ChatGPT in my daily work

I am an expert user of Claude and ChatGPT. I use both extensively, every day, to develop technical and organisational solutions. That experience has made them part of how I approach work, from exploring a need to reviewing the results.

On a technical assignment, the help might involve comparing ways to solve a problem, preparing an implementation or reviewing existing work. For organisational work, it might mean structuring a proposal, clarifying dependencies or turning scattered information into a plan people can discuss. Context and acceptance criteria matter in both cases.

I want to use that capacity to examine the work more thoroughly while spending less time on repetition. An initial instruction is usually only the beginning. The response needs reviewing, omissions need spotting, and the tool may need context it does not yet have. Knowing how to use it includes recognising when an answer sounds convincing but still misses the need.

Greater capacity still needs judgement

I see AI as a tool that amplifies my skills. It helps me make better use of time and resources, but a complete solution still needs direction and validation. Producing an answer is one part of the work. Deciding whether it is appropriate requires an understanding of the problem.

In software, an implementation can work for the example in front of us and fail when an operation is repeated or unexpected data arrives. It can also pass the available tests while missing a condition nobody considered. Checking those situations takes technical knowledge and an understanding of where the software will be used.

An organisational proposal has similar limits. A well-written plan can depend on information that does not exist or capacity the business does not have. A clear document is no proof that a plan can be carried out. It needs to be checked with the people who understand the operation and will take on the work.

That is why I retain responsibility for decisions and results. The tool can suggest alternatives and speed up their development. Choosing, reviewing and delivering remain part of my contribution. The more I can produce with its help, the more attention I need to give to whether the work is heading in the right direction.

What remains of the pure developer

To me, the pure developer role, understood as someone whose job is limited to turning instructions into code, no longer makes sense as a professional proposition. I believe the most mechanical tasks will eventually be automated. Basing someone’s value on performing them faster and faster will be hard to sustain.

Engineering still requires understanding a need and taking responsibility for how it is met. Choosing a boundary between components, investigating an intermittent failure or deciding how much complexity a product should carry all require more context than an isolated specification. AI can help with that work, which is precisely why I want to use it.

My view of the profession increasingly centres on that broader responsibility. It includes talking to product and operations, understanding business constraints and taking part in implementation. Programming knowledge lets us assess what is being built and its consequences. We still need to deepen that knowledge, even as the way we write code changes.

What I expect in the coming years

I believe this is only the beginning. I expect more mechanical work to disappear from our working day and more assignments to become practical as the time they require falls. I am excited by the prospect of spending more effort on difficult problems and trying solutions that would previously have been costly to explore.

I also expect us to reconsider how we learn the profession. If tools take over tasks through which we used to gain experience, we will need ways to develop that judgement: reading code, investigating failures and checking why a decision works in one set of conditions and fails in another. Delegating execution does not remove the need to understand it.

I want to keep working with that combination of technical knowledge and increasingly capable tools. I want to reach something testable sooner and spend the time saved checking how it works in practice. I also want to explore alternatives that, without that help, would be ruled out before anyone tried them.