How I work in software engineering now

My workflow is specific to my job role - I work heavily on algorithms and processing of large data to determine optimal results. I also must monitor my deployed code as tightly on prod as I can - we replan 100s or 1000s of flights in a short time, so performance, optimality, throughput, and accuracy all trade off.

Some of this requires inspecting code, but not all of it.

I have found that there is a large gap between “hand written” and “vibed” that I fall into, and I want to defend and define my position on AI-enabled engineering, with the caveat that it’s “only” late 2026 at the time of this writing.

Let’s look at this top-down.

Generally speaking, you write software to perform some operation on a piece of data. The data is specified, the steps are unknown, and the desired effect is known.

You can define tests to make sure the output is correct for a given input, and you can define inspections that QA people should do (often yourself!) to ensure it looks right.

Inside the black box is the algorithm design, the performance requierments, and so on, and finally the code itself.

Legend has that software engineering enlightenment is achieved when the s/w eng can design the whole of the black box over days, then sit down and “oneshot” the code.

See [1-3] below.

I don’t think that definition of a good software engineer has changed one iota!

Let’s dig in.

I’m going to highlight portions of this process, who does what, and what I think their job title is for those portions.

• Feature definition: Product manager
• Specification, invariants, and (sometimes) tests : Systems engineering
• Black box algorithm: Softare engineering
• Tests and insepction: QA specialist
• Code development: Software dev

Break to 2026. Let’s redefine these roles based on what parts above they “own”.

Let’s get the much-maligned title out of the way: A vibe coder owns feature definition and inspection only.

A Lode Coder owns everything except the black box. (need link and verification)

A software engineer has lost the coding portion, but guess what, it was never their key skill anyway (despite the plethora of syntax vocabulary interviews), unless that engineer was really a coder in disguise.

Now here’s a summarized / example query from the last couple days, for a feature I was working on:

(write up a detailed description of problem)
We're going to use Zhou, et al 2016 (link) to map Foos to Bars, the optimal assignment of which will ....
We will depart in a few ways, since Zhou used ...
Partition the space into XXX using YYY algorithm (this is still Zhou)
Along the boundaries, assign ZZZ using AAA algorithm (still standard)
In our case, because of ... AAA has three failure cases, they are (write them down).
For failure A we should ...
For failure B ...
The output will be an assignment vector of Foos to Bars.
For each Foo, we will refine the result by ...
After three or so iterations, this should converge.

Your first task is to scan Zhou et al to make sure this maps properly. We'll iterate on misunderstandings.

For testing, see Blah.md for instructions on how to fetch run-ids that satisfy ...
For each, get the input from the fields ...
Run the algorithm and plot the results.
Assert that <invariant> is maintained for each.

and so on.

This is not vibe coding. It is also not coding. It’s just engineering software according to the normal definition. This is how I would have written this feature before, except I would write this down in notes and a flowchart, instead of a description for an agent. After a few sleep cycles, I would become the agent to implement and test it. Then I’d switch back to the engineer/QA role to test and I’d iterate.

I am not concerned about how agents have affected this loop. While I miss the flow state associated with polishing code and challenging myself to map the solution onto syntax, my role as a resarch-type engineer was always in the specification of the algorithms. It’s what I loved first and foremost.

I still work this way, but I delegate the code generation to agents more often than not. I will scan to make sure they haven’t cheated and implemented something other than what I asked for (they’ll do this), and I watch the thought traces and edit sequences for something that stands out - but generally speaking this saves me much work. Once the thinking is done, most the work is done anyway, in my understanding of engineering.

I have tried to allow agents to first specify the solution. Generally they don’t do well here, or at least not well enough for my tastes, but not always. Sometimes I am genuinely suprised and delighted to learn about a technique I didn’t know about - but I then fold it in prior to implementing, or do a comparison study at the end.

For some work, the black box is the code. It’s just a copy-structure-a-to-structure-b-and-call-function-c type work. I generally only specify the ambiguous bits and let agents sort out the mechanics. This makes bugfixes very fast. A bad result comes down from users, I know what part of the black box when wrong or what failure case this maps to, so I specify a workaroudn/fallback and press “GO”.

This is not vibe coding, and it’s not traditional softawre engineering. It’s truly a new paradigm closer to “algorithm specification” and it’s not so bad!