My amazon orgs leadership has been obsessed with spec driven development while individual engineers tell me the only use they have is to placate leadership. I'm tired
I'm an engineer at Amazon - we use Kiro (our own harness) with Opus 4.6 underneath.
Most of my gripes are with the harness, CC is way better.
In terms of productivity I'm def 2-4X more productive at work, >10x more productive on my side business. I used to work overtime to deliver my features. Now I work 9-5 and am job hunting on the side while delivering relatively more features.
I think a lot of people are missing that AI is not just good for writing code. It's good for data analysis and all sorts of other tasks like debugging and deploying. I regularly use it to manage deployment loops (ex. make a code change and then deploy the changes to gamma and verify they work by making a sample request and verifying output from cloudwatch logs etc). I have built features in 2 weeks that would take me a month just because I'd have to learn some nitty technical details that I'd never use again in my life.
For data analysis I have an internal glue catalog, I can just tell it to query data and write a script that analyzes X for me.
AI and agents particularly have been a huge boon for me. I'm really scared about automation but also it doesn't make sense to me that SWE would be automated first before other careers since SWE itself is necessary to automate others. I think there are some fundamental limitations on LLMs (without understanding the details too much), but whatever level of intelligence we've currently unlocked is fundamentally going to change the world and is already changing how SWE looks.
We built a messaging platform for exactly this use case and instruct claws to check in with each other or share context with each other at regular intervals.
One can imagine a manager given an outcome to achieve or a director and then a team of agents carrying out the task. Perhaps the agents are adversarial to some extent so they get reasonable pushback on their decisions (ex one agent always sides on taking a long term approach, another agent wants to be scrappy, another agent is on a PIP and approves everything etc).
Delivering a software solution is often tantamount to reading multiple codebases, getting some alignment with a team on a proposal and then writing the code and deploying. Most of which can be done by calling APIs (apart from aligning a team of humans)
I've worked jobs where I'm paid 60-80k and where I'm paid 100k plus.
I can tell you for sure I cared much less about the job where I wasn't getting paid as much. I would never answer an after work call or go out of my way to follow up organizational or systemic issues. For me working overtime is part of the package when I get paid loads more.
I went this route and got taken over by hackers multiples times. It was very worth it. I got taken over by hackers because my password for ssh was "mars". Me and my little brother were sharing it and wanted an easy password (yeah we have ssh keys now).
Anyways, we both learnt a lot (htop tmux etc) . I'm always jealous that he got to learn everything earlier than me. But if he's not better than me then I consider myself a failure wrt being an older brother.
The only drawback is that this doesn't work if you want to do ai stuff. For those use cases I rent a machine on paper space for a cheap hourly rate.
Very cool but will the threads necessarily wake up deterministically? One may wake up before another but not get cpu before it correct? (forgive me if I'm misunderstanding the code)
Not sure if it answers your question but the paper notes something similar in its discussion of limitations:
> the linear attention of RWKV
leads to significant efficiency gains but still, it may
also limit the model’s performance on tasks that
require recalling minutiae information over very
long contexts. This is due to the funneling of information through a single vector representation
over many time steps, compared with the full information maintained by the quadratic attention of
standard Transformers. In other words, the model’s
recurrent architecture inherently limits its ability to
“look back” at previous tokens, as opposed to traditional self-attention mechanisms. While learned
time decay helps prevent the loss of information,
it is mechanistically limited compared to full self-
attention.
> Another limitation of this work is the increased
importance of prompt engineering in comparison to
standard Transformer models. The linear attention
mechanism used in RWKV limits the information
from the prompt that will be carried over to the
model’s continuation. As a result, carefully designed prompts may be even more crucial for the
model to perform well on tasks