Software has always been built by the software engineer. Not the designer, not the PM (most of the time), not the CEO, not even the architects themselves.
The reason? Software is specific. Machines do exactly what you ask for. It’s the coniving genie waiting for your three wishes. Mis-specify the million dollars you desire, a huge bag weighing over a thousand pounds lands on your head.
The Workflow
As the engineer, I have a new dream. I want everyone the ability to build on top our product line. Currently, this is almost impossible. Too many places for failure. Some of our platforms have over a million lines of code. Some are old, a lot of them are varied in the architecture.
I’ve started to build out a new workflow for our team. It goes something like this:
In today’s world, with AI, this is now completely possible. It opens up an entirely new world; a different way to work.
This is just an experiment that I’ll be playing with in the background as I push along other pieces of our product line, but I’d be curious if other teams are already playing with these workflows: opening up the product line for your team to build on top of existing software.
A man can dream! Love this idea & I think we’re getting closer and closer to this being a reality.
I’m curious though, does the review process at some point just create more overhead for you, than you executing on it yourself? Nonetheless, I think the future is blurred lines for development & the peeps touching it.
Imagine you have several junior engineers. Instead of you (as an example) coming to me (the lead engineer) for a feature request, you go straight to one of them.
The process is simple. The junior will ask you a few questions, figure out what the request is, do some research in the codebase, and get a feel for how tricky the problem is.
If it’s too tricky, they pass along the details, research, request over to me, with most if not all of the necessary context.
If it’s not tricky, they will confirm with me, then I’ll let them execute. All that is needed is for me to review the code once they’re finished.
Typically, I’ll receive several of these bugs and small update requests. Also, note that context switching is rough, especially for engineering when solving challenging problems.
I am curious what teams’ worries might be when implementing something like this. I could definitely see how some could be fearful, worried that changes will make it through without approval, or that it would decrease quality in some way.
I think my first question would be is it focused on the right areas. Creating value in some areas of a business is about doing the same thing repeatedly…
… in cases you need to create business value, doing the same thing over and over will leave future states out of sight.
Peter Drucker said businesses are always in fluctuation. An intelligent system would need to keep questioning the outputs, or forcing people to answer new questions.
I think the piece I worry most about is actually in your described scenario.
In this case, I may not feel confident that the junior engineer has captured the request. Many (most?) junior engineers will be focused on the implementation problem, and often don’t ask many questions to clarify.
That’s not necessarily to put it on the agent to address my feedback correctly, but often a complex bug or request requires some dialog, especially when coming from a non-technical actor.
True, which is exactly why I’m the human in the loop.
If we do this right, I would claim Claude as a mid-level engineer when it comes to building the context. Typically, if it dives into the code and asks questions at the same time, it does a tremendously good job at understanding where the issue is.
Great callouts @EricZ . I’ll have to keep this in mind!
