The allocation of time to different tasks will of course vary depending on the composition of the workflow being automated, but I expect the general trend will remain, as it reflects the strengths and weaknesses of today’s LLMs.
The User Interface and User Experience5%
This used to be the difficult part — endless faffing around with designs and control libraries, nudging pixels and grappling with the latest tech. Now, if you wire things up right, the LLM will get you 75% of the way there on the first shot.
This was my workflow: start with research and find the latest and greatest UI libraries that best suit your task. I fell back on a single UI library, plus separate chart and table libraries that supported infinite scrolling and complex charting. The next thing you need is a design system — the set of fonts, colours, badges, gradients and so on that communicate your brand. Claude will design that for you with a bit of iteration. Put the design system in your repo and point your agent at it. Now everything you make will look the same.
Every time you build a new UI component, make sure it is centralised and extensible. Continually evolve components, and get your agent to check the library first.
Really, the UI it was the easiest part. Getting high-density UIs looking good on a mobile device is the only hard bit. I think if you have a good eye and a do a bit of critical evaluation then there is very little reason to pay for independant UX advice, the LLM knows most things if prompted correctly.
Domain Expertise30%
Knowing what is important in the real world. Knowing how entities relate to each other. Understanding the ifs, buts and maybes that are being analysed. Knowing where to find good data and what to avoid. Knowing what is doable and what isn’t. Understanding what you should be building — i.e. where the value is, what your customers want.
Thinking BIG, thinking beyond the present into awhole new competitive domain, because if the data is there then everything is easy, so why not just do it?
Domain knowledge has always been a source of competitive advantage, and it has just got more important. The domain subject matter experts in your organisation should be your agent orchestrators, the software engineers of the future. They have the vision, and they no longer need somebody to implement it for them.
Codifying domain knowledge into scalable system level logic is a big chunk of the time.
The Service Layer30%
The service layer is ‘old school’ programming, but it can now be built faster than ever. It contains the tools that power the system.
I built a dedicated and reusable service layer to ensure quality and speed. I had over 180 services in my service layer performing tasks like PDF processing, entity persistence, entity resolution, searching, scraping, numerical computation, merging datasets, splitting data, quality checks and normalisation — from the mundane (slug_service, excel_exporter) the multimodal (audio_transcriber, image_classification) the domain-specific (capex_inflator) to the slightly paranoid (source_quotation_verifier, which makes the agent prove it actually read the page it cited). Some of these were exposed as MCP, others not.
Essentially this layer should contain anything you need more than once that has a level of complexity such that there is a risk in not using the service layer. To my mind this is the new role of the IT department — ensuring that the service layer supports all the requirements of the domain experts and enables them to build the solutions of the future. The service layer needs robust tests, and it is where costs, performance and quality are optimised.
The Persistence Layer5%
This is where the data is stored. I use a couple of stores — MongoDB and Postgres. It’s important to use the right tool for the job: is your data highly structured in the real world, or is it flexible?
You must retain the ability to extend your data model at a moment’s notice. Keep the architecture shallow and you can rapidly support new features in your model. Migrations become a piece of cake. Thanks to LLMs, you can now model far more complex data than was previously possible, so long as you keep a grip on quality with a good service layer — I chose to put all writes through the service layer, the home of centralised quality control. Extensibility warning: agents love cruft.
If you cannot quickly evolve your persistence layer to meet new requirements then you will not evolve your business and you will be overtaken by those who can. And by quick I mean idea on Monday, product on Friday
The Processing Layer30%
This is why we built all of the above: to process data through a pipeline — from noise to order and meaning. I used a range of tools for processing data. They combined one or more of deterministic code, determinism with reasoning support, fully agentic reasoning loops (mostly ReAct) and human-in-the-loop style skills, e.g. using Claude Code Skills. Each would interact with the service layer. I put quality control in this layer too, although often I would run a separate post-process for it. It overlaps significantly with domain expertise.