When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time.
So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet.
We're finding cases where fast coding really does seem to be super helpful though:
* Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)
* Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual)
* Times where the path forward is simple but also a lot of work (tedious stuff)
* Dealing with edge cases after building the happy path
* EDIT: One more huge one I would add: anywhere where the thing you're adding is a complete analogy of another branch/PR the agent seems to do great at (which is like a "simple but tedious" case)
The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).
> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
I've already passed through this phase and have given up on it. I'm sure everyone's experience will vary, but I just find it introduces either sufficiently more context switching or detracts sufficiently enough mental engagement that I end up introducing more errors, feeling miserable, or just straight up losing productivity and focus. This type of workflow is only viable for me if the cost of mistakes is low, the surface area for changes is small, or the mental context is the same between activities.
The expectation that this is a serviceable workflow—I fear, and am experiencing—will ultimately just create more compressed timelines for everything, while quality, design, and job satisfaction will drop. Yes the code can be written while I look at a PR, but if it's a non-trivial amount of code or a non-trivial PR (which tends to become more frequent as more code generation and larger refactors are happening) then I'm just context switching between tasks I need to constantly re-zone in on, which is less gratifying and more volatile in a way that just hurts my mind and soul and money doesn't change in a meaningful way.
That's not to say I'm not using them or seeing no productivity gains, but I'm not reclaiming that much time due to being able to anything concurrently, it's mostly reclaiming time I'd otherwise have procrastinated on something.
For years I worked at a large company with so many blockers for everything that I always worked like this all the time - have 5 projects so when one becomes blocked for external deps, you have one to pull out and work on. There is a context switch (which lead me to context preservation habits like checking everything I write into git; using tmux so that the context is sitting around in the bash history of the shell where I was working, that sort of thing; lots of org files and Mac stickies with TODOs etc).
I still do this, and don't really think it's avoidable, but when the expectation around compressed timelines because of the imaginary ability to rapidly do synchronous non-trivial tasks in parallel, that's both things get sone poorly.
Feels akin to something like driving in stop and go traffic while playing chess with a passenger who's shit talking me.
I've tried the "4 agents running at the same time in different projects/features" and I felt literally dizzy. I still do the "check something else while the agent runs", and I often forget about that terminal window for many minutes, only to remember about it several tasks later.
> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced
Ugh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out.
The human element in all of this never seems to be discussed. Maybe this will weed out those that are unworthy of the new process but I simply don't want to be "on" all the time. I don't want to be optimized like this.
Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another.
Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.
Insightful and helpful to peer into another company's experience. Mostly agree with your highlighted points.
> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
This is where unnerving exhaustion comes from though.
I know myself to be on the side of craftsmen. It does takes tons and tons of time to code, but I didn't get exhausted the way I do with AI. AI is productive, I am pro-AI. But boy is it a different kind of work beast.
> Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)
This has helped me a lot. Normally I'd feel really attached to big refactors because of sunk costs, but when AI does a huge refactor it's easier to honestly decide that it wasn't worth it and unnecessarily increased complexity.
Very much agree for the type of software I've worked on my whole career. I've seen way more time and energy wasted by people trying to predict the future than fixing bugs. In practice I think it's common to realize something didn't "possibly work" until after it's already deployed, but keeping things simple makes it easy to fix. So this advice also ends up basically being "move fast break things".
We attempt to address this problem at work with an extra caveat to never add code "in the wrong direction" -- so it's fine (usually preferable) to have a partial implementation, as long as it's heading in the direction we'd like the more complete implementation to go in. Basically "KISS, but no hacks".
Yes, this is an excellent rule. I read an essay years ago (which I can't find now) about technical debt whether the author separate tech debt into two flavors which he analogized to a mortgage (good) and credit card debt (bad). Basically, getting the right design but only partially implementing it is like a mortgage, you're making a down payment on the full implementation and you can pay down the debt over time. But doing terrible hacks to "get something working" is like credit card debt. You're buying some time but will have to pay that back later (with a lot of interest).
Just curious, how would that be applied to the xslx namespace problem example given? If the full fix is to implement namespacing, what would the KISS approach be in the right direction?
This avoids the endless whack-a-mole that you get with a partial solution such as "assume namespaces are superflous", which you almost certainly will eventually discover weren't optional.
Or some other hapless person using your terrible code will discover at 2am at night sitting alone in the office building while desperately trying to do something mission critical such as using a "simple" XML export tool to cut over ten thousand users from one Novel system to another so that the citizens of the state have a functioning government in the morning.
Ask me how I know that kind of "probably won't happen" thing will, actually, happen.
We've been using Elasticsearch + PG and it's pretty nice and fast, but it adds a whole layer of extra stuff to deal with when your data is in PG but then also needs to be indexed into an external server outside of those PG transactions. In our case I'm pretty convinced it hasn't been worth the effort. I think we could've optimized PG to be as fast as we needed with a lot less overhead than dealing with an external search index.
We moved our queues to PG and it cuts out the same kind of overhead to be able to wrap an update and start a job in a transaction. PG has been plenty fast to keep up with our queue demand.
Ultimately I think being able to do things transactionally just avoids a whole class of syncing issues, which are basically caching issues, and cache invalidation is one of the 2 hard things.
Is there some way to normalize the amount spent on education per student with the need per student? NYC is also the most expensive place to live in the US, so conceivably the amount spent per student doesn't go as far towards their educational outcome. Baltimore is very poor, so conceivably the gap between the amount spent per student and the need per student is still high. Wealthy suburbs in Washington DC might already have so much support per student that their education system would do fine spending even less per student.
Or I suppose in other words: do education spending numbers actually cover what it takes to provide good educational outcomes? And if not, and we wanted to specifically improve education outcomes, could increased education spending still do that by offsetting other deficits? In more concrete terms: if we did something like give schools way more money could they pay for more things like after school tutoring and recreational opportunities to improve educational outcomes that might be happening in places like wealthy suburbs of Washington DC but not as much in Baltimore?
I think it's possible that your numbers of amount spent per pupil don't take into account the total benefit to that pupil towards their education. If Norway say also helps comparatively more with housing, food, and medicine, then that might also factor into the educational outcome of their pupils, especially if it means parents can spend more time helping their children.
Anecdotally the smallish town I grew up in had good public schools, and many of my teachers lived in nice homes nearby the schools they taught at. The HCOL city I currently live in has (supposedly) poor public schools and one of the issues I hear is that teachers can't afford to live anywhere near them and don't want to commute hours to work, so they have high turnover. If housing weren't so expensive the public schools here might be better while appearing to spend the same amount on education.
I started out freelancing and eventually built a consulting firm w/ a partner, I left around 50 people because selling time for money just never got fun.
Took a business partner, a couple engineers, and one of the products we had built for an old customer from the consulting firm (on good terms!) and built an enterprise SaaS product out of it, much happier working working with a small team on a product.
For me the value of working on lots of things was meeting lots of people I'd like to continue working with and getting product ideas.
The argument would be that the marketing done by the label(s) she has signed with is a big part of why she has 7.5M monthly Spotify listeners (and the related fame is why so many people will pay to see her feet).
Not sure if that's a good argument, maybe she would've grown just as popular w/o help from a label, but that's why artists sign.
So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet.
We're finding cases where fast coding really does seem to be super helpful though:
* Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)
* Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual)
* Times where the path forward is simple but also a lot of work (tedious stuff)
* Dealing with edge cases after building the happy path
* EDIT: One more huge one I would add: anywhere where the thing you're adding is a complete analogy of another branch/PR the agent seems to do great at (which is like a "simple but tedious" case)
The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).