Comment by simonw
3 months ago
> We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent.
Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
14% used to feel about right for me - I'd spend the rest of the time researching approaches and libraries, planning things out in issues, or sometimes just thinking really hard about problems I ran into.
Now... I still do those things, but I'm doing many of them faster - and I'm often doing them while my coding agents are churning away on code.
There's also this weird effect where the harder a problem is the more I can get done in parallel with it, because an agent might need to spend 20 minutes on it without my involvement.
You read my mind. I suspect it is a transient spike while I blow through the backlog and I'll run out of things that AI can vastly accelerate in, say, 6 months. But right now? I'm spending 80-90% of my time blasting through implementing features, finding bugs, fixing old bugs, writing and improving my tools... Code was never the majority of my job. But right now the bar to doing things is so low and the sheer joy of blasting through some previously tedious, low to medium hanging fruit is thrilling.
And when you are done, what will happen with all that code you wrote?
>> We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent.
> Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
Not really, as once it is time to write code, the problem has been defined/understood (to the degree possible with knowledge acquired at the time), and encoding it is largely an exercise in typing along with verifying assumptions via test suites.
Does GenAI quicken some portions of the above workflow? Sure, in the same way IDEs with contextual code snippet suggestions can make encoding faster.
I used it to write SQL and make dashboards. Back in the day, I would spend a lot of time doing that, then I changed roles. I dipped my toe in it recently and used AI exclusively. I would send a prompt, see the output, decide if that is what I wanted or not. I kept my brain in "what-if mode" and I let the LLM handle the technical specs.
'What-if' mode is a game changer. And underrated.
The cost of prototyping has crashed. So you can A/B/C... various ideas, test them in the real world or by personal preference, to taste, and converge on designs that work for you.
This used to very hard and expensive. Now it's so cheap it makes the idea -> test -> refine loop much tighter and faster.
>The cost of prototyping has crashed. So you can A/B/C... various ideas)
Oh yes! I would think "I wonder how the data would look if I did X" and feel the pain of complicated SQL... but then the LLM would just do it and I got to see if I liked or not! It was a delight
Does the code get reviewed? How do you deal with increased amount of code that may need to be looked at?
I review the code that matters - anything security adjacent or that's an API that will be used by other code in the future.
I don't review code that either works or doesn't - most HTML and CSS layout code for example. There I test it on desktop and mobile and commit it if it works.
Ditto for stuff that's simple. A JSON endpoint that runs a SQL query and returns some JSON? If it works and a glance at the tests looks OK then I trust my agents wrote it properly.
I'm getting more confident with my judgement over what needs a close look and what doesn't over time, as so far I haven't been majorly burned my any mistakes that snuck through.
Honestly, it's similar to being an engineer on a larger team. You don't review every line of code written by every one of your coworkers.
I think this is THE issue of our time as programmers to be honest: do you review every line of code an agent writes?
An increasing number of expert programmers are moving in the direction of NOT reviewing every line. It's working out OK for a lot of them.
I've found that engineers on a large team do read every line, mainly due to the fact that the skill levels run the gamut from intern to lead, and only 1 or 2 people out of 12 might have knowledge of the application being modified.
It's actually getting worse due to "AI code bloat", for example I have 16k lines of code to review across 3 apps by the end of this week. Normally it would be a quarter of that, but what Claude produces is extremely verbose in some places and anemic in others, and I can't tell at a glance what's right and what looks right with that much ground to cover.
4 replies →
> I don't review code that either works or doesn't - most HTML and CSS layout code for example. There I test it on desktop and mobile and commit it if it works.
Good example of what not to review if you're working on your hobbies. Also exploratory can sometimes be done this way. However, this ultimately boils down to how you approach programming as an engineering discipline, including your responsibility for the outcome.
> I'm getting more confident with my judgement over what needs a close look and what doesn't over time, as so far I haven't been majorly burned my any mistakes that snuck through.
This doesn't generalize well. If you drink raw milk, or if you don't wear your seatbelt, or if you don't escape your user input correctly, you'll probably be fine, but I really hope aspiring programmers/engineers don't take this attitude towards any serious task. One should always examine their biases, tools' failure modes, etc. regardless of how many times something didn't fail.
> Honestly, it's similar to being an engineer on a larger team. You don't review every line of code written by every one of your coworkers.
One [should] review the code they're responsible for. In a team, people usually assign you (or ask you) to review code, and the work is divided accordingly. If the code isn’t reviewed by the code owners, it’s a problem, not something inspiring!
> An increasing number of expert programmers are moving in the direction of NOT reviewing every line. It's working out OK for a lot of them.
Have you considered that the sheer amount of code being generated is what makes thorough review infeasible, not that it’s a desirable approach?
3 replies →
> Ditto for stuff that's simple. A JSON endpoint that runs a SQL query and returns some JSON? If it works and a glance at the tests looks OK then I trust my agents wrote it properly.
That is *exactly* the sort of area I *wouldn’t* blindly trust AI, there’s a huge security boundary there. What if the AI is doing string concatenation with user-provided data???
7 replies →
I think it also depends on what you're building. Some solo project or basic html thing? Sure no need to review every line. It's a bit different when you're working on foundational libraries that a business relies on, anything touching a production database, etc.
> Honestly, it's similar to being an engineer on a larger team. You don't review every line of code written by every one of your coworkers.
We don’t because everyone is accountable for his or her own mistakes. So everyone is incentivized for their recklessness to not be the root cause of some bug.
> An increasing number of expert programmers are moving in the direction of NOT reviewing every line. It's working out OK for a lot of them.
Have you ever asked your users? What about bug reports? Is the amount and rate decreasing?
lol I think you’re setting yourself up for failure. Why? Just because something works doesn’t necessarily know you the boundaries of it. What scale does it work for? Will it crumble under load in prod? It works but allows cross tenant access (security issue) because security checks weren’t in the location you thought… Dangerous!
3 replies →
[dead]
If you're going to be reading the code you might as well write it by hand instead of using AI.
Yeah. I spend most of my day driving agents to write code, verifying the results, orchestrating work streams, and so on. The rest of the time, a Fable agent is organizing work in Linear/Jira and making sure coworkers are getting their stuff done in a way that won’t conflict.
[flagged]