People are starting to coin the term ADLC or Agentic Development Lifecycle. A lot of this seems to be combining two things:
I don't think we need yet another acronym, but let's talk about how things are changing in general and what some of the bottlenecks are.
One of the overarching changes, leading to an explosion in lines of code, merge requests and more, is that the cost of software engineering has dramatically decreased. So much so that all of us can now do the job of multiple engineers without hiring them. As part of this change, our daily workflows have changed completely. We no longer open an IDE and work on a single task, start to finish. Instead, our roles have become a lot more exploratory and, quite frankly, fun.
My workflow, for example, has shifted towards opening multiple chat sessions, often separate threads on the same topic. I get to spar like some sort of boxer with AI over a few variations of how I've been looking at the same problem. After a while, I'll start to narrow that down to one or two threads containing the desired architecture or strategy to solve the goal. From that point, I'm running this smaller set of agents end-to-end with validation criteria until a passing merge request is opened for each.
Running this same process in parallel across 3-4 topics leads to 8-10 merge requests within a day. And because this process has become so easy, these merge requests are often meaty. Not just one-liners.
Previously, you'd dedicate your day to working on a particular problem over a longer horizon, whereas now the amount of output (whether it's valuable output or not) has dramatically increased.
If you frame software engineering as problem solving, where most problems contain local minima, not absolute minima (a metaphor about gradient descent), then the really fun part is being able to now explore many different paths that you previously would not have been able to take.
This means having more possible answers to the same question and being able to choose the answers you feel best solve the problem at hand.
Unsurprisingly, the largest implication is that more code than ever is being generated. I used to wince at the sight of a merge request with tens of thousands of lines of code (both removed and added), and now it's becoming more and more common.
The honest truth, whether we like it or not, is that this benefit of massive parallelisation means letting go of reading the code. At least reading all of it.
And if you don't believe that point, let's talk about the practicalities of where software engineering is going, whether we like it or not. The overwhelming wave behind AI and the force of these frontier labs are turning the literal act of writing code into a cheap commodity and less of an "artisanal form of work". As more and more lines of code get written, either with our oversight or without, the blockers are our attention spans and working hours.
Fundamentally, we've built parts of the SDLC with humans in the loop: reviewing code, deploying code, observing code, fixing its problems and iterating (excluding new features and other product-management-related tasks). At the scale at which humans used to do this BC (Before ChatGPT), this was scalable. But as we move towards this more shotgun-style exploration to find the best solutions to problems, it needs to change.
To continue the analogy around graph functions, we've become really good at the first part... We can come up with ideas to solve a problem, explore that problem space using coding agents and AI, and post some prospective solutions on GitHub. But what happens next? How do we continue to optimise towards a local minimum for a problem we're solving? Generating code is not enough.
My first post dealt with the review problem and how to build a quick code review bot with Tilde, which we now use internally to review all our merge requests with custom prompts and skills. That post was quick and dirty, so I do intend to follow it up with a more detailed dissection. But this is the start.
The idea is that a well-structured code review agent should help deal with the first constraint: when thousands of lines of code are generated daily, how can you review the work to determine what should make it into production, understand the risks and multiplex the feedback loop to your coding agents so they can refine their work?
The next post, coming out later this week, covers what happens next. Once you're in production, how do you respond to performance issues and bugs in code you didn't read or write? We'll focus on building an agent that is wired to your observability and error-reporting platforms and can respond in real time.
In later parts of the series, we'll uncover a few more interesting patterns we're using at Tilde for very narrow wedges and features in the code-generation phase. These will mainly focus on how to build narrow, 24/7 coding agents designed for specific features that follow a repeatable pattern.
Personally, as someone who's worked as a software engineer for many years, I feel the pain of an industry changing beneath me and the concern that all my professional habits of yesterday are quickly becoming irrelevant. But if I reflect on the reason I originally decided to write code, to build things, I've never felt more empowered. It's time to get back to building.