Is kiro platform agnostic, or tied into AWS? I'll check that out, thanks

Big as in an application with more than one scope. Yeah don't go by their marketing material. I hate the agentic coding trend, but I'm not losing my job by not being able to adopt to it. I already have a reputation of AI hater in my company lol.

I have been building a system, it's hitting 2m lines of code soon (backend + frontend).

Currently, I have landed in a flow where I maintain a roadmap of releases. Each release is a featureset that I can test, verify, and demo. Most releases are planned through a PRD document which contains user stories, other constraints, and implementation phases. Then, I create as many ADRs and TDs as necessary.

Tbh, all these are for me to keep track of what I am building. I am having agents write the bulk of these documents by rumbling to a microphone for a good deal of time and then reviewing ruthlessly. You have much more control over small and steady increments.

When I feel adequetly prepared, I start coding, most of the time I will lay the foundation and then have agents fill in the implementations.

I don't really worry about future proofing my architecture. It's not like I have a massive database that will take multiple days to create an index, most of the changes are cheap.

Nothing of the above is new, they are well established tools mostly used by larger organizations, the only thing that changes with AI is the scale in which you can use them.

The above apply only fo projects I am serious with (2 projects atm), the rest I just ask AI to build what I need and send it the bugs until it works as expected.

In Kiro that sort of thing would go in project steering, rather than a specific task/feature spec.

[Speckit] For decades, code has been king — specifications were just scaffolding we built and discarded

WTF? New devs seem to forget that, for decades, the waterfall style of coding was all about writing specs for months before any code was written.

how do you handle your big applications?

What is "big" to you? I don't think a 20 years old application that has 100 millions of lines of code can be vibe-coded like that.

The networking advice is right, but here's the part you can actually control while you wait for that to pay off. Most fresh-grad applications look the same from the other side of the desk, a degree and a list of tutorials. What made me put someone through to interview was evidence of judgment: one or two small projects that are genuinely finished, with tests and a readme, ideally deployed somewhere I can poke at. Not a half-built clone of something. And in the cover note, one specific trade-off you made and why you made it. That reads as someone who has actually shipped, which is rarer than it should be.

I've used spec-kit and also rolled my own lighter version of the same idea. The framework matters less than the habit it forces, which is writing down what 'done' looks like before the agent starts. When I just prompt without that, I get something plausible that I then argue with for an hour. When the spec has acceptance criteria the agent can check itself against, most of that back-and-forth goes away. The caveat is that spec-kit can be heavier than a small change needs, so for quick work I'll write the criteria in a comment and skip the ceremony. Worth trying. For me the habit of writing the criteria first is what stuck, more than the tooling around it.

Essentially, the idea you need a master’s degree to do what your parents were doing with a high school diploma.

credential inflation?

yes, I have been active but lately too exhausted for meaningful contributions, would start again.

yeah

Like the name of this sub suggests, most companies that are hiring developers want someone with existing real-world experience building things. If you just went and got a degree and have nothing else to show, then you have the training but you don't have experience.

I would suggest meaningfully contributing to open-source projects, and/or making your own projects, so that you have something to show on your resume as "experience" until you get real projects at a real job.

Make your CV interesting, a good option to do that is work on small functional projects that you can host (e.g on GitHub) and attach links to your CV. Go to job events in your area to talk to recruiters, get an idea of the companies in your area, get comfortable talking to recruiters by practicing.

You take an entry level position and suffer for at least a year or until you have the requisite experience for a job change. Truth of the matter is that there’s a lot of credential inflation; it’s gotten so bad that it’s become a bipartisan issue in the US.

Also, fun fact: getting a job is about who you know not about what you know. My husband and I have the same amount of experience, but he’s an executive, and I had peaked at middle management, but am currently working entry level because I can’t find another management position (and we don’t need more income). He’s the luckiest person you’ll ever meet; every time he gets fired, he gets a huge promotion and raise for looking on the job market because he knows a few good references. (he works in finance, which is prone to office politicking, thus easier to be fired)

If you do not have any network, your start of the career looks like this old meme.

Network, make connections, know someone, get your foot in the door and prove yourself. Call anyone you know in your industry, talk to them and ask if they know of any opportunities. Use your voice to talk to humans over the telephone or in person instead of sending DMs or emails.

To be honest I always struggled with writing code from scratch. Most of the tasks happen inside in already existing code, or are things where you can reference already existing similar things.

The author made this story available to Medium members only.

Please either update the post with the URL that gets around this login-wall; or, remove the post because the article is not on the public web.

Yeah, this should be common software engineering problem for a senior engineer

In the beginning, there is only one data model used both externally and internally, to keep things simple. Now that they're diverging, it's time to draw an abstraction boundary that translates between internal and external models.

I'm not super strong with Java, but subclassing to handle v1/v2/vX doesn't sound like the right thing to do. I'd detach the old model from the API while otherwise keeping it unchanged, implement a new pathway to connect with the new API, then translate in/out of the old model before it passes into the existing system. This way, the surface area of change and of integration is isolated and decoupled from everything else.

One thing that is often overlooked in enthusiastic architecture is lines of concern. If you have two APIs, you have two data models. They might be the same today, but they will diverge eventually. A customer in the AR system is different from a customer in the CRM system.

But also, an API is an API. As long as it is a serializes and deserializes on both ends, you are implementing the contract. In this case, author just made their own class, but nonsensically and uselessly tied it to something different. Just ignore the [non-]standard model and create your own DTO. Because in the end if the model is updated and the contract is changed, you aren't going to be following it anyway until you (painfully) update your own.

That said, I understand business often imposes wrong-headed requirements because the wrong people are making the decisions. If there was a hard requirement to use the standard data model, the author failed in any event.

On the other hand, it kinda reads like the DTO is being used within the business logic instead of having a data model separate from the DTO. Don't do that. You have a request model, a response model, a business object, and then often either a persistence model (entity) or upstream service request and response models. Lots of times those can be identical but I've seen a lot of code where tying the entity to a response model creates a hell of a lot of headaches down the road.

By using different classes, you allow them to diverge naturally and only need to update the mapping layer. Don't do that shit because the longer it goes on the more painful it is to separate later.

lol if that were true then yes there absolutely are replaceable by anything that can ensure they’re getting the right requirements. Of course it isn’t true, because LLMs are nowhere near the level of actual proper development standards but here we are.

Isn't everybody?

I often use LLMs to give me code snippets in a language I don't know.

When I started programming (back in the dark days when StackOverflow was helpful), it took me months to learn a language well enough to do what I wanted, and I had several weeks where I would be frustrated that I just couldn't find what I was doing wrong, or what was the name for what I wanted so I could search for it.

AI has allowed me to drastically speed up my learning time for new languages, at the expense of me not really understanding much. I'll accept that compromise if I just want one script, but it's a hard habbit to drop when actual understanding is needed.

Aside from telling me what language features exist, or showing me the correct syntax (exactly what a language model is designed for), I have found AI is mostly just confidently wrong.

One of the main problems I found was that AI would sometimes write code that looked good, was well documented and even worked flawlessly. But it would take 15-20 complicated lines to perform a task that happened to be a language feature and could have been done with a single function call.

Other times it would write code that appeared to work at first glance, and after a reasonable inspection also seemed good. Only after trying to re-write that task myself did I realize the AI had missed a critical but subtle edge case. I wouldn't have even thought to test for that edge case if I hadn't tried to design the function myself.

I've also heard someone else mention that AI will often rewrite code (often with subtle differences) instead of writing a function once and calling it several times. The AI code may look clean, but it's not nearly as maintainable as well written code by humans.
I do have to admit that it is significantly better than poorly written code by overworked and underpaid humans.

All of this is ignoring the many times the code just didn't compile, or had basic logic errors that were easy to find, but very difficult to get the AI to fix. It was often quicker to write everything myself than try to fix AI code.

I've had poor luck with it's debugging, where I think it shines right now is when I need to code something that's basically standalone iin a language I don't really know.

Give me git hook to X or right a bash script to Y.